From bhavesh.x.patel at oracle.com Thu Jan 2 02:17:42 2014 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Thu, 02 Jan 2014 10:17:42 +0000 Subject: hg: jdk8/tl/langtools: 8029143: javadoc standard doclet should add Functional Interface blurb when @FunctionalInterface annotation is present Message-ID: <20140102101745.F3C9D62FD7@hg.openjdk.java.net> Changeset: 4a6f853f8721 Author: bpatel Date: 2014-01-02 02:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a6f853f8721 8029143: javadoc standard doclet should add Functional Interface blurb when @FunctionalInterface annotation is present Reviewed-by: jjg ! src/share/classes/com/sun/javadoc/ClassDoc.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java ! test/com/sun/javadoc/testLambdaFeature/pkg/A.java ! test/com/sun/javadoc/testLambdaFeature/pkg1/FuncInf.java + test/com/sun/javadoc/testLambdaFeature/pkg1/NotAFuncInf.java From chris.hegarty at oracle.com Thu Jan 2 22:58:37 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 03 Jan 2014 06:58:37 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20140103065950.CE6EF62FEB@hg.openjdk.java.net> Changeset: 18080cca998a Author: dl Date: 2014-01-03 06:22 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18080cca998a 8031133: AbstractMap should specify its default implementation using @implSpec Reviewed-by: chegar, alanb ! src/share/classes/java/util/AbstractMap.java Changeset: 33a60ce1e35d Author: chegar Date: 2014-01-03 06:23 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33a60ce1e35d Merge ! src/share/classes/java/util/AbstractMap.java From sean.coffey at oracle.com Fri Jan 3 08:47:54 2014 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 03 Jan 2014 16:47:54 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20140103164849.42D2E62FFC@hg.openjdk.java.net> Changeset: 46c727d6ecc2 Author: aefimov Date: 2013-12-30 16:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46c727d6ecc2 8025051: Update resource files for TimeZone display names Reviewed-by: okutsu, mfang ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/sun/util/resources/TimeZone/Bug6317929.java + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_de.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_de_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_es.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_es_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_fr.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_fr_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_it.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_it_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ja.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ja_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ko.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ko_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_pt_BR.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_pt_BR_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_sv.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_sv_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_CN.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_CN_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_TW.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_TW_short.properties Changeset: c0970860803e Author: coffeys Date: 2014-01-03 16:45 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0970860803e Merge From kevin.walls at oracle.com Fri Jan 3 09:42:54 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 03 Jan 2014 17:42:54 +0000 Subject: RFR 8028623: SA: hash codes in SymbolTable mismatching java_lang_String::hash_code for extended characters. Message-ID: <52C6F69E.4010107@oracle.com> Hi, This problem means you can't use the SA if the target app contains a symbol which uses a non-ascii character. The SA tool will fail with an error, the JVM itself and the SA having calculated different hashes for such Strings. bug: https://bugs.openjdk.java.net/browse/JDK-8028623 webrev: http://cr.openjdk.java.net/~kevinw/8028623/webrev.00/ Thanks Kevin From christian.thalinger at oracle.com Fri Jan 3 11:42:31 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 3 Jan 2014 11:42:31 -0800 Subject: RFR(L): 8028468: Add inlining information into ciReplay In-Reply-To: <52BE343C.8030500@oracle.com> References: <529E92AB.9060901@oracle.com> <52BE343C.8030500@oracle.com> Message-ID: <2D5B6C39-5ED3-4FD5-A185-614A3A83D7C8@oracle.com> Why are we using a different file for the inline data? On Dec 27, 2013, at 6:15 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8028468/webrev/ > > https://bugs.openjdk.java.net/browse/JDK-8028468 > > Add inlining information into Compilation Replay data to correctly inline methods during recompilation. > Add ability to use Replay data to replay compilation DURING normal execution of a program (in debug VM only because ciReplay is defined only in debug VM). Currently a program is not executed when we do recompilation. > Allow dump and replay inlining for specified method during a program execution. > > Thanks, > Vladimir > From joe.darcy at oracle.com Fri Jan 3 11:39:28 2014 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 03 Jan 2014 19:39:28 +0000 Subject: hg: jdk8/tl/jdk: 8030212: Several api.java.util.stream tests got "NaN" value instead of "Infinity" or "-Infinity" Message-ID: <20140103193957.9AB6C6235D@hg.openjdk.java.net> Changeset: 68de5492a06d Author: darcy Date: 2014-01-03 11:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68de5492a06d 8030212: Several api.java.util.stream tests got "NaN" value instead of "Infinity" or "-Infinity" Reviewed-by: mduigou, psandoz ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DoublePipeline.java ! test/java/util/stream/TestDoubleSumAverage.java From martinrb at google.com Fri Jan 3 13:30:46 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 3 Jan 2014 13:30:46 -0800 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52B82FBC.3080704@oracle.com> References: <52B82FBC.3080704@oracle.com> Message-ID: In the past, when I've needed to check for thread state and have to wait while staying in RUNNING, I just spin instead of sleeping, e.g. AtomicInteger count = ...0 count.increment whlle (count.get() < 2) Thread.yield(); which works well in tests, although of course not appropriate for "real" code. On Mon, Dec 23, 2013 at 4:42 AM, Jaroslav Bachorik < jaroslav.bachorik at oracle.com> wrote: > Please, review the following test fix: > > Issue : https://bugs.openjdk.java.net/browse/JDK-8030847 > Webrev: http://cr.openjdk.java.net/~jbachorik/8030847/webrev.00/ > > The root cause of the intermittent failures of this test is the fact that > there is a lot of hidden places in JDK classes when the checked thread can > get BLOCKED - and it will distort the blocked count and the test will fail. > The ones identified in this case were: > > - ThreadMXBean.getThreadInfo() > - System.out.println() > - Phaser.arriveAndAwaitAdvance() > > Whether the thread gets blocked or not depends on many variables and this > makes the failure very intermittent. > > The fix consists of: > - not using ThreadMXBean.getThreadInfo() from within the tested thread > - not using System.out.println() (or any other kind of output) in the > tested thread > - not using Phaser to synchronize the tested thread and the control thread > > The toughest part is to replace Phaser for the synchronization purposes > with a similar construct which would not block the thread when waiting for > the other party. CyclicBarrier didn't work either as probably wouldn't not > any other solution based on java.util.concurrent locks. > > The TwoPartySynchronizer provides the block-free synchronization and is > based on atomics and Thread.wait(). It is not a general purpose replacement > for Phaser or CyclicBarrier but it works very well for exactly two parties > needing progress synchronization and not wanting to block any of the > parties. > > Thanks, > > -JB- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140103/39f1cf2a/attachment.html From john.coomes at oracle.com Fri Jan 3 14:18:31 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 22:18:31 +0000 Subject: hg: hsx/hotspot-rt/corba: 5 new changesets Message-ID: <20140103221841.5700C62393@hg.openjdk.java.net> Changeset: eb5d3f8ca0ca Author: mfang Date: 2013-12-17 22:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/eb5d3f8ca0ca 8026741: jdk8 l10n resource file translation update 5 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp Changeset: 2a8fa4da6ad3 Author: lana Date: 2013-12-23 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/2a8fa4da6ad3 Merge Changeset: 5ca1b4c282b8 Author: ssides Date: 2013-12-23 18:42 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/5ca1b4c282b8 8029231: Update copyright years for files in corba repository for 2013 Reviewed-by: mchung, coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/io/OutputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java ! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyImpl.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/StubDelegateImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator.java ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/DefaultSocketFactoryImpl.java ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp ! src/share/classes/javax/rmi/CORBA/Stub.java ! src/share/classes/javax/rmi/CORBA/Util.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/sun/rmi/rmic/iiop/CompoundType.java Changeset: 0cd687347540 Author: lana Date: 2013-12-25 10:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/0cd687347540 Merge Changeset: 1ecd4619f60c Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/1ecd4619f60c Added tag jdk8-b122 for changeset 0cd687347540 ! .hgtags From john.coomes at oracle.com Fri Jan 3 14:19:50 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 22:19:50 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 7 new changesets Message-ID: <20140103222041.01DED62395@hg.openjdk.java.net> Changeset: 3e5bf0372a93 Author: joehw Date: 2013-12-12 11:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/3e5bf0372a93 8029895: XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification Reviewed-by: alanb, dfuchs, lancea ! src/javax/xml/stream/XMLOutputFactory.java Changeset: 9c7e3a68dc77 Author: lana Date: 2013-12-12 19:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/9c7e3a68dc77 Merge Changeset: fad4b4d28599 Author: lana Date: 2013-12-23 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/fad4b4d28599 Merge Changeset: 1bedbbce236a Author: joehw Date: 2013-12-20 09:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/1bedbbce236a 8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars Reviewed-by: dfuchs, lancea, ulfzibis ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java Changeset: 9a3986b21be4 Author: joehw Date: 2013-12-23 11:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/9a3986b21be4 8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013 Reviewed-by: lancea, mchung ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/FeatureManager.java ! src/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.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/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java ! src/com/sun/xml/internal/stream/Entity.java ! src/com/sun/xml/internal/stream/StaxXMLInputSource.java ! src/com/sun/xml/internal/stream/XMLEntityStorage.java ! src/com/sun/xml/internal/stream/writers/WriterUtility.java ! src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java ! src/javax/xml/XMLConstants.java ! src/javax/xml/parsers/SAXParser.java ! src/javax/xml/validation/Validator.java ! src/javax/xml/xpath/XPathException.java ! src/javax/xml/xpath/XPathFactory.java ! src/org/xml/sax/helpers/NewInstance.java ! src/org/xml/sax/helpers/ParserAdapter.java ! src/org/xml/sax/helpers/ParserFactory.java ! src/org/xml/sax/helpers/SecuritySupport.java ! src/org/xml/sax/helpers/XMLReaderFactory.java Changeset: 93bf25903af0 Author: lana Date: 2013-12-25 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/93bf25903af0 Merge Changeset: 4e35b5b6d2e5 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/4e35b5b6d2e5 Added tag jdk8-b122 for changeset 93bf25903af0 ! .hgtags From john.coomes at oracle.com Fri Jan 3 14:21:37 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 22:21:37 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b122 for changeset bc622ba563f9 Message-ID: <20140103222151.9794062396@hg.openjdk.java.net> Changeset: 91f5c542ccad Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/91f5c542ccad Added tag jdk8-b122 for changeset bc622ba563f9 ! .hgtags From john.coomes at oracle.com Fri Jan 3 14:17:48 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 22:17:48 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b122 for changeset 347009c58816 Message-ID: <20140103221748.4891662391@hg.openjdk.java.net> Changeset: ff1478785e43 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/ff1478785e43 Added tag jdk8-b122 for changeset 347009c58816 ! .hgtags From john.coomes at oracle.com Fri Jan 3 14:42:29 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 22:42:29 +0000 Subject: hg: hsx/hotspot-rt/nashorn: 8 new changesets Message-ID: <20140103224246.08CDF623BA@hg.openjdk.java.net> Changeset: 752554d45a07 Author: sundar Date: 2013-12-09 09:48 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/752554d45a07 8029612: the typeErrorThrower field in ScriptFunctionImpl cannot be static and common to all Globals Reviewed-by: attila, hannesw ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java Changeset: 739f3abdfa55 Author: sundar Date: 2013-12-09 09:53 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/739f3abdfa55 Merge Changeset: 4706897b4dec Author: attila Date: 2013-12-09 10:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/4706897b4dec 8029467: Widening of booleans causes bad results Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8029467.js + test/script/basic/JDK-8029467.js.EXPECTED Changeset: 18edd7a1b166 Author: lagergren Date: 2013-12-11 18:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/18edd7a1b166 8029780: "ant externals" broke our test harness with the latest version of the octane benchmarks Reviewed-by: attila, sundar ! make/build-benchmark.xml ! test/script/basic/compile-octane-splitter.js.EXPECTED ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js Changeset: e452a3797290 Author: sundar Date: 2013-12-12 09:18 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/e452a3797290 Merge Changeset: 0225a7ca37ab Author: lana Date: 2013-12-12 19:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/0225a7ca37ab Merge Changeset: 9d112a0e7df7 Author: lana Date: 2013-12-23 14:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/9d112a0e7df7 Merge Changeset: 688f4167f921 Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/688f4167f921 Added tag jdk8-b122 for changeset 9d112a0e7df7 ! .hgtags From john.coomes at oracle.com Fri Jan 3 14:41:14 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 22:41:14 +0000 Subject: hg: hsx/hotspot-rt/langtools: 12 new changesets Message-ID: <20140103224210.B0A5E623B8@hg.openjdk.java.net> Changeset: 2d0a0ae7fa9c Author: ksrini Date: 2013-12-06 09:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/2d0a0ae7fa9c 8029504: Regression: TestDocRootLink test fails on Windows Reviewed-by: bpatel, jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java Changeset: 5bf0af735c61 Author: vromero Date: 2013-12-09 19:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/5bf0af735c61 8029569: internal javac cast exception when resolving varargs ambiguity Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/T8029569/VarargsAmbiguityCrashTest.java + test/tools/javac/T8029569/VarargsAmbiguityCrashTest.out Changeset: 847cc0cccfa1 Author: rfield Date: 2013-12-11 11:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/847cc0cccfa1 8029558: java.lang.VerifyError: Bad return type when lambda's body is in parentheses Summary: properly type convert the body of a lambda expression Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/lambda/LambdaParenGeneric.java + test/tools/javac/lambda/LambdaParenGenericOrig.java Changeset: d80c3d6f4f05 Author: lana Date: 2013-12-12 19:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d80c3d6f4f05 Merge Changeset: 8832b6048e65 Author: vromero Date: 2013-12-13 14:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8832b6048e65 8029721: javac crash for annotated parameter type of lambda in a field Reviewed-by: rfield, jfranck ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java ! test/tools/javac/lambda/LambdaScope05.out Changeset: 6d1f9d1fd585 Author: darcy Date: 2013-12-17 10:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6d1f9d1fd585 8030080: Correct misstatement in JSR 269 MR (in javax.lang.model) Reviewed-by: jfranck ! src/share/classes/javax/lang/model/type/IntersectionType.java ! src/share/classes/javax/lang/model/util/Types.java Changeset: f1be939b49f6 Author: mfang Date: 2013-12-17 23:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f1be939b49f6 8026741: jdk8 l10n resource file translation update 5 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties ! src/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties Changeset: b8ebde062692 Author: bpatel Date: 2013-12-18 19:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b8ebde062692 8016549: jdk7 javadocs are hard to read Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java ! test/tools/javadoc/api/basic/APITest.java Changeset: 56943b19c119 Author: lana Date: 2013-12-23 14:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/56943b19c119 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif Changeset: 998b10c43157 Author: ksrini Date: 2013-12-24 09:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/998b10c43157 8029230: Update copyright year to match last edit in jdk8 langtools repository for 2013 Reviewed-by: ksrini Contributed-by: steve.sides at oracle.com ! make/Makefile ! src/share/classes/com/sun/javadoc/AnnotationDesc.java ! src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/share/classes/com/sun/tools/sjavac/CleanProperties.java ! src/share/classes/com/sun/tools/sjavac/CompileChunk.java ! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java ! src/share/classes/com/sun/tools/sjavac/CompileProperties.java ! src/share/classes/com/sun/tools/sjavac/CopyFile.java ! src/share/classes/com/sun/tools/sjavac/JavacState.java ! src/share/classes/com/sun/tools/sjavac/Log.java ! src/share/classes/com/sun/tools/sjavac/Module.java ! src/share/classes/com/sun/tools/sjavac/Package.java ! src/share/classes/com/sun/tools/sjavac/ProblemException.java ! src/share/classes/com/sun/tools/sjavac/Source.java ! src/share/classes/com/sun/tools/sjavac/Transformer.java ! src/share/classes/com/sun/tools/sjavac/Util.java ! src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java ! src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java ! src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java ! src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java ! src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java ! src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java ! src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java ! src/share/classes/com/sun/tools/sjavac/server/PortFile.java ! src/share/classes/com/sun/tools/sjavac/server/SysInfo.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/element/package-info.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! test/com/sun/javadoc/testAbstractMethod/TestAbstractMethod.java ! test/com/sun/javadoc/testAbstractMethod/pkg/A.java ! test/com/sun/javadoc/testAbstractMethod/pkg/B.java ! test/com/sun/javadoc/testAbstractMethod/pkg/C.java ! test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java ! test/com/sun/javadoc/testDocRootLink/pkg1/C1.java ! test/com/sun/javadoc/testDocRootLink/pkg2/C2.java ! test/com/sun/javadoc/testLegacyTaglet/C.java ! test/com/sun/javadoc/testNavigation/pkg/A.java ! test/com/sun/javadoc/testNavigation/pkg/C.java ! test/com/sun/javadoc/testNavigation/pkg/E.java ! test/com/sun/javadoc/testNavigation/pkg/I.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/C.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeRegDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/D.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/NonSynthDocContainer.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegArryDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/C.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValNotDoc.java ! test/tools/javac/T6725036.java ! test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedBase.java ! test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedContainer.java ! test/tools/javac/annotations/typeAnnotations/TargetTypes.java ! test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java ! test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java ! test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java ! test/tools/javac/cast/intersection/IntersectionTypeParserTest.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/cast/intersection/model/ModelChecker.java ! test/tools/javac/defaultMethods/static/Static01.java ! test/tools/javac/defaultMethods/static/Static02.java ! test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java ! test/tools/javac/defaultMethods/static/import/StaticImport1.java ! test/tools/javac/defaultMethods/static/import/StaticImport2.java ! test/tools/javac/defaultMethods/static/import/StaticImport3.java ! test/tools/javac/defaultMethods/static/import/pkg/A.java ! test/tools/javac/defaultMethods/static/import/pkg/B.java ! test/tools/javac/defaultMethods/static/import/pkg/C.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java ! test/tools/javac/diags/MessageFile.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java ! test/tools/javac/diags/examples/IllegalStaticIntfMethCall.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java ! test/tools/javac/diags/examples/NotInProfile.java ! test/tools/javac/diags/examples/RepeatableAnnotationsNotSupported.java ! test/tools/javac/diags/examples/StaticIntfMethodNotSupported.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/generics/odersky/BadTest4.java ! test/tools/javac/lambda/DoubleStaticImport.java ! test/tools/javac/lambda/Intersection01.java ! test/tools/javac/lambda/Intersection02.java ! test/tools/javac/lambda/LambdaCapture06.java ! test/tools/javac/lambda/LambdaConv01.java ! test/tools/javac/lambda/LambdaExpr15.java ! test/tools/javac/lambda/MethodReference25.java ! test/tools/javac/lambda/MethodReference26.java ! test/tools/javac/lambda/MethodReference59.java ! test/tools/javac/lambda/MethodReference60.java ! test/tools/javac/lambda/TargetType51.java ! test/tools/javac/lambda/lambdaExecution/InInterface.java ! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java ! test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java ! test/tools/javac/lambda/methodReference/BridgeMethod.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReference/SamConversionComboTest.java ! test/tools/javac/lambda/typeInference/InferenceTest2b.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/multicatch/Pos05.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/resolve/Pos.java ! test/tools/javac/resolve/ResolveHarness.java ! test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java ! test/tools/jdeps/APIDeps.java ! test/tools/jdeps/p/Foo.java Changeset: 232b9cf6303a Author: lana Date: 2013-12-25 10:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/232b9cf6303a Merge Changeset: a345cf28faca Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a345cf28faca Added tag jdk8-b122 for changeset 232b9cf6303a ! .hgtags From john.coomes at oracle.com Fri Jan 3 14:26:02 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 22:26:02 +0000 Subject: hg: hsx/hotspot-rt/jdk: 41 new changesets Message-ID: <20140103223543.228B562399@hg.openjdk.java.net> Changeset: c8c4aef922ff Author: vadim Date: 2013-12-13 11:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c8c4aef922ff 8029628: Many graphic artifacts Reviewed-by: prr, bae ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: 6ecbfe5e211b Author: lana Date: 2013-12-19 10:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6ecbfe5e211b Merge Changeset: 9e0e8eed676a Author: pchelko Date: 2013-12-06 17:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9e0e8eed676a 8029565: java.awt.dnd.InvalidDnDOperationException: data translation failed on file drop Reviewed-by: anthony, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/solaris/classes/sun/awt/X11/XDataTransferer.java + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/InterprocessMessages.java + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/SourceFileListFrame.java + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/TargetFileListFrame.java + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.html + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.java + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListTransferable.java Changeset: 152cf399f16f Author: serb Date: 2013-12-11 22:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/152cf399f16f 8029045: Regression - Unsatisfied Link Error when the Java Access Bridge is started Summary: Rename native function name; fix make to rebuild jni header file Reviewed-by: erikj, tbell Contributed-by: peter.brunet at oracle.com ! make/CompileJavaClasses.gmk Changeset: 06c655658b89 Author: serb Date: 2013-12-12 16:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/06c655658b89 8001472: api/java_awt/Window/indexTGF_* tests fail because expected colors aren't equal Reviewed-by: anthony, azvegint ! src/solaris/classes/sun/awt/X11/XWindow.java + test/java/awt/Window/BackgroundIsNotUpdated/BackgroundIsNotUpdated.java Changeset: 78d395c7c479 Author: lana Date: 2013-12-12 20:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/78d395c7c479 Merge - make/data/cryptopolicy/limited/LIMITED - make/data/cryptopolicy/unlimited/UNLIMITED - test/com/sun/jmx/snmp/NoInfoLeakTest.java - test/com/sun/tools/attach/AgentSetup.sh - test/com/sun/tools/attach/ApplicationSetup.sh - test/com/sun/tools/attach/BasicTests.sh - test/com/sun/tools/attach/CommonSetup.sh - test/com/sun/tools/attach/PermissionTests.sh - test/com/sun/tools/attach/ProviderTests.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh - test/java/rmi/reliability/benchmark/runRmiBench.sh - test/java/rmi/reliability/benchmark/runSerialBench.sh Changeset: 20d504a20a87 Author: azvegint Date: 2013-12-13 14:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/20d504a20a87 8029923: Many Swing tests and SwingSet2 are failing under Solaris using GTK LaF - "Unable to load native GTK libraries" Reviewed-by: anthony, serb ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h Changeset: c8ec5c070592 Author: azvegint Date: 2013-12-18 11:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c8ec5c070592 8029263: user's default browser can not launch after we click the button, and there is an IOException shown in the log text (java.io.IOException) Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XDesktopPeer.java ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/xawt/awt_Desktop.c ! test/java/awt/Desktop/OpenByUNCPathNameTest/OpenByUNCPathNameTest.java Changeset: 4ee27281d27d Author: lana Date: 2013-12-19 10:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4ee27281d27d Merge Changeset: f8da1f34c65c Author: darcy Date: 2013-12-06 11:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f8da1f34c65c 8023471: Add compatibility note to AnnotatedElement Reviewed-by: smarks, jfranck, abuckley ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java Changeset: d6c4ae56c079 Author: juh Date: 2013-12-06 11:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d6c4ae56c079 8007967: Infinite loop can happen in sun.security.provider.certpath.SunCertPathBuilder.depthFirstSearchForward() Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java Changeset: 9e579a2329c0 Author: michaelm Date: 2013-12-09 13:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9e579a2329c0 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname Reviewed-by: alanb, chegar ! src/share/classes/java/net/URLPermission.java + test/java/net/URLPermission/OpenURL.java ! test/java/net/URLPermission/URLPermissionTest.java Changeset: 23a7524d930c Author: mfang Date: 2013-12-09 15:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/23a7524d930c 8025974: l10n for policytool Reviewed-by: naoto, leifs, yhuang ! src/share/classes/sun/security/tools/policytool/Resources_de.java ! src/share/classes/sun/security/tools/policytool/Resources_es.java ! src/share/classes/sun/security/tools/policytool/Resources_fr.java ! src/share/classes/sun/security/tools/policytool/Resources_it.java ! src/share/classes/sun/security/tools/policytool/Resources_ja.java ! src/share/classes/sun/security/tools/policytool/Resources_ko.java ! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/policytool/Resources_sv.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java Changeset: fe3383582427 Author: rriggs Date: 2013-12-11 16:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fe3383582427 8029551: Add value-type notice to java.time classes Summary: Add warning about identity of value types and reference to ValueBased.html Reviewed-by: briangoetz, smarks, scolebourne ! 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/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/ZonedDateTime.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java Changeset: 1298e476729c Author: michaelm Date: 2013-12-11 15:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1298e476729c 8029944: Primitive Stream reduce method documentation pseudo code misidentifies apply method Reviewed-by: mduigou Contributed-by: michael.mcmahon 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 Changeset: 1970e3c3d202 Author: michaelm Date: 2013-12-11 15:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1970e3c3d202 8029696: Broken doc links to package-summary.html#NonInterference in java.util.stream Reviewed-by: mduigou ! src/share/classes/java/util/stream/StreamSupport.java ! src/share/classes/java/util/stream/package-info.java Changeset: 01b11184bcf9 Author: mfang Date: 2013-12-11 21:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/01b11184bcf9 8026115: [zh_CN] inproper translation in output of jarsigner command Reviewed-by: naoto, yhuang ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java Changeset: 23b89bd740e9 Author: lana Date: 2013-12-12 19:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/23b89bd740e9 Merge Changeset: a7ed72627c3f Author: mduigou Date: 2013-12-13 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a7ed72627c3f 8029055: Map.merge implementations should refuse null value param Reviewed-by: briangoetz, dl ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! test/java/util/Map/Defaults.java Changeset: 26028cb56c68 Author: mduigou Date: 2013-12-13 13:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/26028cb56c68 8030016: HashMap.computeIfAbsent generates spurious access event Reviewed-by: psandoz, bchristi ! src/share/classes/java/util/HashMap.java + test/java/util/LinkedHashMap/ComputeIfAbsentAccessOrder.java ! test/java/util/Map/Defaults.java Changeset: 6c343d3d2721 Author: smarks Date: 2013-12-13 18:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6c343d3d2721 8027536: rmic: add deprecation warning message when generating JRMP static stubs/skeletons Reviewed-by: mchung, dmocek ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/rmi/rmic/resources/rmic.properties Changeset: 8e133b86b9f8 Author: mduigou Date: 2013-12-17 09:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8e133b86b9f8 8029795: LinkedHashMap.getOrDefault() doesn't update access order. Reviewed-by: psandoz ! src/share/classes/java/util/LinkedHashMap.java ! test/java/util/LinkedHashMap/Basic.java Changeset: 4fa27233a3e9 Author: mfang Date: 2013-12-17 14:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4fa27233a3e9 7090826: Newly added codes need to be localized into pt_BR in LocaleNames Reviewed-by: okutsu ! src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 68c31754f925 Author: vinnie Date: 2013-12-17 23:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/68c31754f925 8029788: Certificate validation - java.lang.ClassCastException Reviewed-by: xuelei, mullan, weijun ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 9211877b25ba Author: mfang Date: 2013-12-17 23:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9211877b25ba 8026741: jdk8 l10n resource file translation update 5 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/java/util/jar/pack/DriverResource_ja.java ! src/share/classes/com/sun/java/util/jar/pack/DriverResource_zh_CN.java ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/sun/security/tools/keytool/Resources_de.java ! src/share/classes/sun/security/tools/keytool/Resources_es.java ! src/share/classes/sun/security/tools/keytool/Resources_fr.java ! src/share/classes/sun/security/tools/keytool/Resources_it.java ! src/share/classes/sun/security/tools/keytool/Resources_ja.java ! src/share/classes/sun/security/tools/keytool/Resources_ko.java ! src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/keytool/Resources_sv.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties Changeset: 8d35f0985dd7 Author: xuelei Date: 2013-12-18 16:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8d35f0985dd7 7093640: Enable client-side TLS 1.2 by default Reviewed-by: weijun, mullan, wetmore ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/IllegalProtocolProperty.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/SSLContextVersion.java - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: e2bdddb8bedf Author: dl Date: 2013-12-19 10:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e2bdddb8bedf 8026155: Enhance ForkJoin pool Reviewed-by: chegar, alanb, ahgross ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java Changeset: c841815be720 Author: chegar Date: 2013-12-19 10:38 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c841815be720 Merge Changeset: a2339db970e0 Author: lana Date: 2013-12-19 10:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a2339db970e0 Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: 2f31ddf65e74 Author: lana Date: 2013-12-23 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2f31ddf65e74 Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: 75142ce752da Author: malenkov Date: 2013-12-23 16:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/75142ce752da 8030118: Document listeners fired outside document lock Reviewed-by: art, serb ! src/share/classes/javax/swing/text/AbstractDocument.java - test/javax/swing/text/AbstractDocument/7146146/bug7146146.java + test/javax/swing/text/AbstractDocument/8030118/Test8030118.java Changeset: 8b5985f1a0b5 Author: lana Date: 2013-12-25 11:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8b5985f1a0b5 Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: 73473e9dfc46 Author: joehw Date: 2013-12-20 09:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/73473e9dfc46 8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars Reviewed-by: dfuchs, lancea, ulfzibis + test/javax/xml/jaxp/parsers/8029955/EntityScannerTest.java Changeset: 7186275e6ef1 Author: rriggs Date: 2013-12-20 13:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7186275e6ef1 8030002: Enhance deserialization using readObject Reviewed-by: sherman, chegar, scolebourne ! 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/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/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.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/temporal/ValueRange.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! test/java/time/tck/java/time/AbstractTCKTest.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java ! test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java ! test/java/time/tck/java/time/serial/TCKDurationSerialization.java ! test/java/time/tck/java/time/serial/TCKInstantSerialization.java ! test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java ! test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKMonthDaySerialization.java ! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKPeriodSerialization.java ! test/java/time/tck/java/time/serial/TCKYearMonthSerialization.java ! test/java/time/tck/java/time/serial/TCKYearSerialization.java ! test/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java ! test/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java ! test/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java ! test/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java ! test/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java Changeset: 39a02b18b386 Author: rriggs Date: 2013-12-20 13:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/39a02b18b386 8029909: Clarify equals/hashcode behavior for java.time types Summary: Document the behavior of equals and hashcode in java.time.chrono date types Reviewed-by: sherman, scolebourne ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java Changeset: aef6c726810e Author: mullan Date: 2013-12-23 14:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/aef6c726810e 8030813: Signed applet fails to load when CRLs are stored in an LDAP directory Summary: Skip JNDI application resource lookup to avoid recursive JAR validation Reviewed-by: vinnie, herrick ! src/share/classes/com/sun/naming/internal/ResourceManager.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java Changeset: f3c714eeef6c Author: mullan Date: 2013-12-23 14:05 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f3c714eeef6c Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: 71ce5e56ca60 Author: lana Date: 2013-12-25 10:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/71ce5e56ca60 Merge Changeset: 1a3de3cdc684 Author: lana Date: 2013-12-26 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1a3de3cdc684 8029235: Update copyright year to match last edit in jdk8 jdk repository for 2013 Summary: updated files with 2011, 2012 and 2013 years according to the file's last updated date Reviewed-by: tbell, lancea, chegar ! make/BuildJdk.gmk ! make/Bundles.gmk ! make/CompileJavaClasses.gmk ! make/CompileLaunchers.gmk ! make/CopyIntoClasses.gmk ! make/CopySamples.gmk ! make/GenerateData.gmk ! make/Makefile ! make/data/characterdata/CharacterData00.java.template ! make/data/characterdata/CharacterData01.java.template ! make/data/characterdata/CharacterData02.java.template ! make/data/characterdata/CharacterData0E.java.template ! make/data/characterdata/CharacterDataLatin1.java.template ! make/data/characterdata/CharacterDataPrivateUse.java.template ! make/data/characterdata/CharacterDataUndefined.java.template ! make/data/charsetmapping/DoubleByte-X.java.template ! make/data/charsetmapping/SingleByte-X.java.template ! make/data/dtdbuilder/html32.dtd ! make/data/jdwp/jdwp.spec ! make/data/swingbeaninfo/SwingBeanInfo.template ! make/data/swingbeaninfo/javax/swing/SwingBeanInfoBase.java ! make/data/swingbeaninfo/sun/swing/BeanInfoUtils.java ! make/data/tzdata/gmt ! make/data/tzdata/jdk11_backward ! make/gendata/GendataFontConfig.gmk ! make/gendata/GendataHtml32dtd.gmk ! make/gensrc/GensrcBuffer.gmk ! make/gensrc/GensrcCLDR.gmk ! make/gensrc/GensrcCharacterData.gmk ! make/gensrc/GensrcCharsetCoder.gmk ! make/gensrc/GensrcCharsetMapping.gmk ! make/gensrc/GensrcExceptions.gmk ! make/gensrc/GensrcJDWP.gmk ! make/gensrc/GensrcJObjC.gmk ! make/gensrc/GensrcLocaleDataMetaInfo.gmk ! make/gensrc/GensrcMisc.gmk ! make/gensrc/GensrcProperties.gmk ! make/gensrc/GensrcSwing.gmk ! make/gensrc/GensrcX11Wrappers.gmk ! make/mapfiles/launchers/mapfile-sparc ! make/mapfiles/launchers/mapfile-sparcv9 ! make/mapfiles/launchers/mapfile-x86 ! make/mapfiles/launchers/mapfile-x86_64 ! make/mapfiles/libattach/mapfile-linux ! make/mapfiles/libattach/mapfile-solaris ! make/mapfiles/libawt/mapfile-mawt-vers ! make/mapfiles/libawt/mapfile-vers ! make/mapfiles/libawt/mapfile-vers-linux ! make/mapfiles/libawt_headless/mapfile-vers ! make/mapfiles/libawt_xawt/mapfile-vers ! make/mapfiles/libdcpr/mapfile-vers ! make/mapfiles/libdt_socket/mapfile-vers ! make/mapfiles/libfontmanager/mapfile-vers ! make/mapfiles/libfontmanager/mapfile-vers.openjdk ! make/mapfiles/libhprof/mapfile-vers ! make/mapfiles/libinstrument/mapfile-vers ! make/mapfiles/libj2gss/mapfile-vers ! make/mapfiles/libj2pcsc/mapfile-vers ! make/mapfiles/libj2ucrypto/mapfile-vers ! make/mapfiles/libjaas/mapfile-vers ! make/mapfiles/libjava_crw_demo/mapfile-vers ! make/mapfiles/libjawt/mapfile-vers ! make/mapfiles/libjdga/mapfile-vers ! make/mapfiles/libjdwp/mapfile-vers ! make/mapfiles/libjli/mapfile-vers ! make/mapfiles/libjpeg/mapfile-vers ! make/mapfiles/libjpeg/mapfile-vers-closed ! make/mapfiles/libjsdt/mapfile-vers ! make/mapfiles/libjsound/mapfile-vers ! make/mapfiles/libjsoundalsa/mapfile-vers ! make/mapfiles/libkcms/mapfile-vers ! make/mapfiles/liblcms/mapfile-vers ! make/mapfiles/libmlib_image/mapfile-vers ! make/mapfiles/libnet/mapfile-vers ! make/mapfiles/libnio/mapfile-linux ! make/mapfiles/libnio/mapfile-macosx ! make/mapfiles/libnio/mapfile-solaris ! make/mapfiles/libnpt/mapfile-vers ! make/mapfiles/libsctp/mapfile-vers ! make/mapfiles/libsplashscreen/mapfile-vers ! make/mapfiles/libsunec/mapfile-vers ! make/mapfiles/libt2k/mapfile-vers ! make/mapfiles/libunpack/mapfile-vers ! make/mapfiles/libunpack/mapfile-vers-unpack200 ! make/mapfiles/libverify/mapfile-vers ! make/mapfiles/libzip/mapfile-vers ! make/netbeans/common/architectures/arch-x86_64.properties ! make/netbeans/common/architectures/name-Macosx.properties ! make/netbeans/common/closed-share-sources.ent ! make/netbeans/common/demo-view.ent ! make/netbeans/common/make.xml ! make/netbeans/common/properties.ent ! make/netbeans/common/share-sources.ent ! make/netbeans/common/shared.xml ! make/netbeans/common/unix-sources.ent ! make/netbeans/common/windows-sources.ent ! make/netbeans/j2se/build.xml ! make/netbeans/jmx/build.properties ! make/non-build-utils/reorder/Makefile ! make/non-build-utils/reorder/tests/Exit.java ! make/non-build-utils/reorder/tests/Hello.java ! make/non-build-utils/reorder/tests/IntToString.java ! make/non-build-utils/reorder/tests/JHello.java ! make/non-build-utils/reorder/tests/LoadFrame.java ! make/non-build-utils/reorder/tests/LoadJFrame.java ! make/non-build-utils/reorder/tests/LoadToolkit.java ! make/non-build-utils/reorder/tests/Null.java ! make/non-build-utils/reorder/tests/Sleep.java ! make/non-build-utils/reorder/tools/Combine.java ! make/non-build-utils/reorder/tools/MaxTime.java ! make/non-build-utils/reorder/tools/mcount.c ! make/non-build-utils/reorder/tools/remove_mcount.c ! make/non-build-utils/sharing/tests/GHello.java ! make/non-build-utils/sharing/tests/Hello.java ! make/non-build-utils/sharing/tests/JHello.java ! make/non-build-utils/src/build/tools/commentchecker/CommentChecker.java ! make/non-build-utils/src/build/tools/dirdiff/DirDiff.java ! make/src/classes/build/tools/addjsum/AddJsum.java ! make/src/classes/build/tools/buildmetaindex/BuildMetaIndex.java ! make/src/classes/build/tools/charsetmapping/DBCS.java ! make/src/classes/build/tools/charsetmapping/EUC_TW.java ! make/src/classes/build/tools/charsetmapping/HKSCS.java ! make/src/classes/build/tools/charsetmapping/JIS0213.java ! make/src/classes/build/tools/charsetmapping/Main.java ! make/src/classes/build/tools/charsetmapping/SBCS.java ! make/src/classes/build/tools/charsetmapping/Utils.java ! make/src/classes/build/tools/classfile/RemoveMethods.java ! make/src/classes/build/tools/cldrconverter/BundleGenerator.java ! make/src/classes/build/tools/cldrconverter/Container.java ! make/src/classes/build/tools/cldrconverter/CopyrightHeaders.java ! make/src/classes/build/tools/cldrconverter/Entry.java ! make/src/classes/build/tools/cldrconverter/IgnoredContainer.java ! make/src/classes/build/tools/cldrconverter/KeyContainer.java ! make/src/classes/build/tools/cldrconverter/MetaZonesParseHandler.java ! make/src/classes/build/tools/cldrconverter/NumberingSystemsParseHandler.java ! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! make/src/classes/build/tools/cldrconverter/StringArrayElement.java ! make/src/classes/build/tools/cldrconverter/StringArrayEntry.java ! make/src/classes/build/tools/cldrconverter/StringEntry.java ! make/src/classes/build/tools/cldrconverter/SupplementDataParseHandler.java ! make/src/classes/build/tools/compilefontconfig/CompileFontConfig.java ! make/src/classes/build/tools/compileproperties/CompileProperties.java ! make/src/classes/build/tools/dtdbuilder/DTDBuilder.java ! make/src/classes/build/tools/dtdbuilder/DTDInputStream.java ! make/src/classes/build/tools/dtdbuilder/DTDParser.java ! make/src/classes/build/tools/dtdbuilder/PublicMapping.java ! make/src/classes/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java ! make/src/classes/build/tools/generatebreakiteratordata/CharSet.java ! make/src/classes/build/tools/generatebreakiteratordata/CharacterCategory.java ! make/src/classes/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java ! make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java ! make/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java ! make/src/classes/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java ! make/src/classes/build/tools/generatecharacter/GenerateCharacter.java ! make/src/classes/build/tools/generatecharacter/PrintCharacterRanges.java ! make/src/classes/build/tools/generatecharacter/PropList.java ! make/src/classes/build/tools/generatecharacter/SpecialCaseMap.java ! make/src/classes/build/tools/generatecharacter/UnicodeSpec.java ! make/src/classes/build/tools/generatecharacter/Utility.java ! make/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java ! make/src/classes/build/tools/generatenimbus/AbstractGradient.java ! make/src/classes/build/tools/generatenimbus/Border.java ! make/src/classes/build/tools/generatenimbus/Canvas.java ! make/src/classes/build/tools/generatenimbus/ComponentColor.java ! make/src/classes/build/tools/generatenimbus/Dimension.java ! make/src/classes/build/tools/generatenimbus/Ellipse.java ! make/src/classes/build/tools/generatenimbus/Generator.java ! make/src/classes/build/tools/generatenimbus/Gradient.java ! make/src/classes/build/tools/generatenimbus/GradientStop.java ! make/src/classes/build/tools/generatenimbus/Insets.java ! make/src/classes/build/tools/generatenimbus/Layer.java ! make/src/classes/build/tools/generatenimbus/Matte.java ! make/src/classes/build/tools/generatenimbus/ObjectFactory.java ! make/src/classes/build/tools/generatenimbus/Paint.java ! make/src/classes/build/tools/generatenimbus/PainterGenerator.java ! make/src/classes/build/tools/generatenimbus/Path.java ! make/src/classes/build/tools/generatenimbus/Point.java ! make/src/classes/build/tools/generatenimbus/RadialGradient.java ! make/src/classes/build/tools/generatenimbus/Rectangle.java ! make/src/classes/build/tools/generatenimbus/Shape.java ! make/src/classes/build/tools/generatenimbus/SynthModel.java ! make/src/classes/build/tools/generatenimbus/Typeface.java ! make/src/classes/build/tools/generatenimbus/UIColor.java ! make/src/classes/build/tools/generatenimbus/UIComponent.java ! make/src/classes/build/tools/generatenimbus/UIDefault.java ! make/src/classes/build/tools/generatenimbus/UIFont.java ! make/src/classes/build/tools/generatenimbus/UIIconRegion.java ! make/src/classes/build/tools/generatenimbus/UIProperty.java ! make/src/classes/build/tools/generatenimbus/UIRegion.java ! make/src/classes/build/tools/generatenimbus/UIState.java ! make/src/classes/build/tools/generatenimbus/UIStateType.java ! make/src/classes/build/tools/generatenimbus/UIStyle.java ! make/src/classes/build/tools/generatenimbus/Utils.java ! make/src/classes/build/tools/hasher/Hasher.java ! make/src/classes/build/tools/icondata/osxapp/ToBin.java ! make/src/classes/build/tools/jarreorder/JarReorder.java ! make/src/classes/build/tools/jdwpgen/AbstractCommandNode.java ! make/src/classes/build/tools/jdwpgen/AbstractGroupNode.java ! make/src/classes/build/tools/jdwpgen/AbstractNamedNode.java ! make/src/classes/build/tools/jdwpgen/AbstractSimpleNode.java ! make/src/classes/build/tools/jdwpgen/AbstractSimpleTypeNode.java ! make/src/classes/build/tools/jdwpgen/AbstractTypeListNode.java ! make/src/classes/build/tools/jdwpgen/AbstractTypeNode.java ! make/src/classes/build/tools/jdwpgen/AltNode.java ! make/src/classes/build/tools/jdwpgen/ArrayObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/ArrayRegionTypeNode.java ! make/src/classes/build/tools/jdwpgen/ArrayTypeNode.java ! make/src/classes/build/tools/jdwpgen/BooleanTypeNode.java ! make/src/classes/build/tools/jdwpgen/ByteTypeNode.java ! make/src/classes/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/ClassObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/ClassTypeNode.java ! make/src/classes/build/tools/jdwpgen/CommandNode.java ! make/src/classes/build/tools/jdwpgen/CommandSetNode.java ! make/src/classes/build/tools/jdwpgen/CommentNode.java ! make/src/classes/build/tools/jdwpgen/ConstantNode.java ! make/src/classes/build/tools/jdwpgen/ConstantSetNode.java ! make/src/classes/build/tools/jdwpgen/Context.java ! make/src/classes/build/tools/jdwpgen/ErrorNode.java ! make/src/classes/build/tools/jdwpgen/ErrorSetNode.java ! make/src/classes/build/tools/jdwpgen/EventNode.java ! make/src/classes/build/tools/jdwpgen/FieldTypeNode.java ! make/src/classes/build/tools/jdwpgen/FrameTypeNode.java ! make/src/classes/build/tools/jdwpgen/GroupNode.java ! make/src/classes/build/tools/jdwpgen/IntTypeNode.java ! make/src/classes/build/tools/jdwpgen/InterfaceTypeNode.java ! make/src/classes/build/tools/jdwpgen/LocationTypeNode.java ! make/src/classes/build/tools/jdwpgen/LongTypeNode.java ! make/src/classes/build/tools/jdwpgen/Main.java ! make/src/classes/build/tools/jdwpgen/MethodTypeNode.java ! make/src/classes/build/tools/jdwpgen/NameNode.java ! make/src/classes/build/tools/jdwpgen/NameValueNode.java ! make/src/classes/build/tools/jdwpgen/Node.java ! make/src/classes/build/tools/jdwpgen/ObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/OutNode.java ! make/src/classes/build/tools/jdwpgen/Parse.java ! make/src/classes/build/tools/jdwpgen/ReferenceIDTypeNode.java ! make/src/classes/build/tools/jdwpgen/ReferenceTypeNode.java ! make/src/classes/build/tools/jdwpgen/RepeatNode.java ! make/src/classes/build/tools/jdwpgen/ReplyNode.java ! make/src/classes/build/tools/jdwpgen/RootNode.java ! make/src/classes/build/tools/jdwpgen/SelectNode.java ! make/src/classes/build/tools/jdwpgen/StringObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/StringTypeNode.java ! make/src/classes/build/tools/jdwpgen/TaggedObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/ThreadObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/TypeNode.java ! make/src/classes/build/tools/jdwpgen/UntaggedValueTypeNode.java ! make/src/classes/build/tools/jdwpgen/ValueTypeNode.java ! make/src/classes/build/tools/spp/Spp.java ! make/src/classes/build/tools/stripproperties/StripProperties.java ! make/src/classes/build/tools/swingbeaninfo/DocBeanInfo.java ! make/src/classes/build/tools/swingbeaninfo/GenDocletBeanInfo.java ! make/src/classes/build/tools/swingbeaninfo/GenSwingBeanInfo.java ! make/src/native/add_gnu_debuglink/add_gnu_debuglink.c ! make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c ! src/macosx/bin/java_md_macosx.c ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m ! src/macosx/classes/apple/applescript/AppleScriptEngine.java ! src/macosx/classes/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/apple/laf/JRSUIControl.java ! src/macosx/classes/apple/laf/JRSUIFocus.java ! src/macosx/classes/apple/laf/JRSUIState.java ! src/macosx/classes/apple/laf/JRSUIStateFactory.java ! src/macosx/classes/apple/laf/JRSUIUtils.java ! src/macosx/classes/com/apple/eawt/AboutHandler.java ! src/macosx/classes/com/apple/eawt/AppEvent.java ! src/macosx/classes/com/apple/eawt/AppEventListener.java ! src/macosx/classes/com/apple/eawt/AppForegroundListener.java ! src/macosx/classes/com/apple/eawt/AppHiddenListener.java ! src/macosx/classes/com/apple/eawt/AppReOpenedListener.java ! src/macosx/classes/com/apple/eawt/Application.java ! src/macosx/classes/com/apple/eawt/ApplicationAdapter.java ! src/macosx/classes/com/apple/eawt/ApplicationBeanInfo.java ! src/macosx/classes/com/apple/eawt/ApplicationEvent.java ! src/macosx/classes/com/apple/eawt/ApplicationListener.java ! src/macosx/classes/com/apple/eawt/FullScreenAdapter.java ! src/macosx/classes/com/apple/eawt/FullScreenListener.java ! src/macosx/classes/com/apple/eawt/FullScreenUtilities.java ! src/macosx/classes/com/apple/eawt/OpenFilesHandler.java ! src/macosx/classes/com/apple/eawt/OpenURIHandler.java ! src/macosx/classes/com/apple/eawt/PreferencesHandler.java ! src/macosx/classes/com/apple/eawt/PrintFilesHandler.java ! src/macosx/classes/com/apple/eawt/QuitHandler.java ! src/macosx/classes/com/apple/eawt/QuitResponse.java ! src/macosx/classes/com/apple/eawt/QuitStrategy.java ! src/macosx/classes/com/apple/eawt/ScreenSleepListener.java ! src/macosx/classes/com/apple/eawt/SystemSleepListener.java ! src/macosx/classes/com/apple/eawt/UserSessionListener.java ! src/macosx/classes/com/apple/eawt/_AppDockIconHandler.java ! src/macosx/classes/com/apple/eawt/_AppEventLegacyHandler.java ! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java ! src/macosx/classes/com/apple/eawt/_AppMiscHandlers.java ! src/macosx/classes/com/apple/eawt/event/GestureAdapter.java ! src/macosx/classes/com/apple/eawt/event/GestureEvent.java ! src/macosx/classes/com/apple/eawt/event/GestureListener.java ! src/macosx/classes/com/apple/eawt/event/GesturePhaseEvent.java ! src/macosx/classes/com/apple/eawt/event/GesturePhaseListener.java ! src/macosx/classes/com/apple/eawt/event/GestureUtilities.java ! src/macosx/classes/com/apple/eawt/event/MagnificationEvent.java ! src/macosx/classes/com/apple/eawt/event/MagnificationListener.java ! src/macosx/classes/com/apple/eawt/event/RotationEvent.java ! src/macosx/classes/com/apple/eawt/event/RotationListener.java ! src/macosx/classes/com/apple/eawt/event/SwipeEvent.java ! src/macosx/classes/com/apple/eawt/event/SwipeListener.java ! src/macosx/classes/com/apple/laf/AquaBorder.java ! src/macosx/classes/com/apple/laf/AquaButtonBorder.java ! src/macosx/classes/com/apple/laf/AquaButtonCheckBoxUI.java ! src/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java ! src/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java ! src/macosx/classes/com/apple/laf/AquaButtonRadioUI.java ! src/macosx/classes/com/apple/laf/AquaButtonToggleUI.java ! src/macosx/classes/com/apple/laf/AquaButtonUI.java ! src/macosx/classes/com/apple/laf/AquaCaret.java ! src/macosx/classes/com/apple/laf/AquaComboBoxButton.java ! src/macosx/classes/com/apple/laf/AquaComboBoxPopup.java ! src/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java ! src/macosx/classes/com/apple/laf/AquaEditorPaneUI.java ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/macosx/classes/com/apple/laf/AquaFileSystemModel.java ! src/macosx/classes/com/apple/laf/AquaFileView.java ! src/macosx/classes/com/apple/laf/AquaFocus.java ! src/macosx/classes/com/apple/laf/AquaFocusHandler.java ! src/macosx/classes/com/apple/laf/AquaFonts.java ! src/macosx/classes/com/apple/laf/AquaGroupBorder.java ! src/macosx/classes/com/apple/laf/AquaHighlighter.java ! src/macosx/classes/com/apple/laf/AquaIcon.java ! src/macosx/classes/com/apple/laf/AquaImageFactory.java ! src/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java ! src/macosx/classes/com/apple/laf/AquaInternalFrameBorderMetrics.java ! src/macosx/classes/com/apple/laf/AquaInternalFrameDockIconUI.java ! src/macosx/classes/com/apple/laf/AquaInternalFrameManager.java ! src/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java ! src/macosx/classes/com/apple/laf/AquaInternalFrameUI.java ! src/macosx/classes/com/apple/laf/AquaLabelUI.java ! src/macosx/classes/com/apple/laf/AquaListUI.java ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/AquaMenuBarBorder.java ! src/macosx/classes/com/apple/laf/AquaMenuBarUI.java ! src/macosx/classes/com/apple/laf/AquaMenuBorder.java ! src/macosx/classes/com/apple/laf/AquaMenuItemUI.java ! src/macosx/classes/com/apple/laf/AquaMenuPainter.java ! src/macosx/classes/com/apple/laf/AquaMenuUI.java ! src/macosx/classes/com/apple/laf/AquaMnemonicHandler.java ! src/macosx/classes/com/apple/laf/AquaNativeResources.java ! src/macosx/classes/com/apple/laf/AquaOptionPaneUI.java ! src/macosx/classes/com/apple/laf/AquaPanelUI.java ! src/macosx/classes/com/apple/laf/AquaPopupMenuSeparatorUI.java ! src/macosx/classes/com/apple/laf/AquaPopupMenuUI.java ! src/macosx/classes/com/apple/laf/AquaProgressBarUI.java ! src/macosx/classes/com/apple/laf/AquaRootPaneUI.java ! src/macosx/classes/com/apple/laf/AquaScrollBarUI.java ! src/macosx/classes/com/apple/laf/AquaScrollPaneUI.java ! src/macosx/classes/com/apple/laf/AquaScrollRegionBorder.java ! src/macosx/classes/com/apple/laf/AquaSliderUI.java ! src/macosx/classes/com/apple/laf/AquaSpinnerUI.java ! src/macosx/classes/com/apple/laf/AquaSplitPaneDividerUI.java ! src/macosx/classes/com/apple/laf/AquaSplitPaneUI.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneTabState.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java ! src/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java ! src/macosx/classes/com/apple/laf/AquaTableHeaderUI.java ! src/macosx/classes/com/apple/laf/AquaTableUI.java ! src/macosx/classes/com/apple/laf/AquaTextAreaUI.java ! src/macosx/classes/com/apple/laf/AquaTextFieldBorder.java ! src/macosx/classes/com/apple/laf/AquaTextFieldFormattedUI.java ! src/macosx/classes/com/apple/laf/AquaTextFieldSearch.java ! src/macosx/classes/com/apple/laf/AquaTextFieldUI.java ! src/macosx/classes/com/apple/laf/AquaTextPaneUI.java ! src/macosx/classes/com/apple/laf/AquaTextPasswordFieldUI.java ! src/macosx/classes/com/apple/laf/AquaToolBarSeparatorUI.java ! src/macosx/classes/com/apple/laf/AquaToolBarUI.java ! src/macosx/classes/com/apple/laf/AquaToolTipUI.java ! src/macosx/classes/com/apple/laf/AquaTreeUI.java ! src/macosx/classes/com/apple/laf/AquaUtilControlSize.java ! src/macosx/classes/com/apple/laf/ClientPropertyApplicator.java ! src/macosx/classes/com/apple/laf/ScreenMenuBar.java ! src/macosx/classes/com/apple/laf/ScreenMenuBarProvider.java ! src/macosx/classes/com/apple/laf/ScreenMenuItem.java ! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java ! src/macosx/classes/com/apple/laf/ScreenMenuItemUI.java ! src/macosx/classes/com/apple/laf/ScreenMenuPropertyHandler.java ! src/macosx/classes/com/apple/laf/ScreenMenuPropertyListener.java ! src/macosx/classes/com/apple/laf/ScreenPopupFactory.java ! src/macosx/classes/com/apple/laf/resources/aqua.properties ! src/macosx/classes/com/apple/laf/resources/aqua_de.properties ! src/macosx/classes/com/apple/laf/resources/aqua_es.properties ! src/macosx/classes/com/apple/laf/resources/aqua_fr.properties ! src/macosx/classes/com/apple/laf/resources/aqua_it.properties ! src/macosx/classes/com/apple/laf/resources/aqua_ja.properties ! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties ! src/macosx/classes/com/apple/laf/resources/aqua_pt_BR.properties ! src/macosx/classes/com/apple/laf/resources/aqua_sv.properties ! src/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties ! src/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties ! src/macosx/classes/java/net/DefaultInterface.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/awt/FullScreenCapable.java ! src/macosx/classes/sun/awt/fontconfigs/macosx.fontconfig.properties ! src/macosx/classes/sun/font/CCharToGlyphMapper.java ! src/macosx/classes/sun/font/CFont.java ! src/macosx/classes/sun/font/CFontConfiguration.java ! src/macosx/classes/sun/font/CFontManager.java ! src/macosx/classes/sun/font/CStrikeDisposer.java ! src/macosx/classes/sun/java2d/BackBufferCapsProvider.java ! src/macosx/classes/sun/java2d/CRenderer.java ! src/macosx/classes/sun/java2d/CompositeCRenderer.java ! src/macosx/classes/sun/java2d/DataBufferNIOInt.java ! src/macosx/classes/sun/java2d/IntegerNIORaster.java ! src/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java ! src/macosx/classes/sun/java2d/OSXOffScreenSurfaceData.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java ! src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java ! src/macosx/classes/sun/lwawt/PlatformComponent.java ! src/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/macosx/classes/sun/lwawt/macosx/CAccessible.java ! src/macosx/classes/sun/lwawt/macosx/CAccessibleText.java ! src/macosx/classes/sun/lwawt/macosx/CClipboard.java ! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java ! src/macosx/classes/sun/lwawt/macosx/CCustomCursor.java ! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java ! src/macosx/classes/sun/lwawt/macosx/CDesktopPeer.java ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java ! src/macosx/classes/sun/lwawt/macosx/CImage.java ! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java ! src/macosx/classes/sun/lwawt/macosx/CInputMethodDescriptor.java ! src/macosx/classes/sun/lwawt/macosx/CMenu.java ! src/macosx/classes/sun/lwawt/macosx/CMenuBar.java ! src/macosx/classes/sun/lwawt/macosx/CMenuComponent.java ! src/macosx/classes/sun/lwawt/macosx/CMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/CMouseDragGestureRecognizer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPopupMenu.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterDevice.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterDialog.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterGraphics.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterGraphicsConfig.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterJobDialog.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterPageDialog.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterSurfaceData.java ! src/macosx/classes/sun/lwawt/macosx/CRobot.java ! src/macosx/classes/sun/lwawt/macosx/CSystemTray.java ! src/macosx/classes/sun/lwawt/macosx/CTextPipe.java ! src/macosx/classes/sun/lwawt/macosx/CThreading.java ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/NSPrintInfo.java ! src/macosx/classes/sun/lwawt/macosx/event/NSEvent.java ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/macosx/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/macosx/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/macosx/native/com/apple/laf/AquaFileView.m ! src/macosx/native/com/apple/laf/AquaLookAndFeel.m ! src/macosx/native/com/apple/laf/AquaNativeResources.m ! src/macosx/native/com/apple/laf/JRSUIConstantSync.h ! src/macosx/native/com/apple/laf/JRSUIConstantSync.m ! src/macosx/native/com/apple/laf/JRSUIFocus.m ! src/macosx/native/com/apple/laf/ScreenMenu.h ! src/macosx/native/com/apple/laf/ScreenMenu.m ! src/macosx/native/com/apple/laf/ScreenPopupFactory.m ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiIn.c ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiOut.c ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiUtils.c ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiUtils.h ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Utils.cpp ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Utils.h ! src/macosx/native/java/util/SCDynamicStoreConfig.m ! src/macosx/native/jobjc/src/core/native/SEL.m ! src/macosx/native/sun/awt/AWTSurfaceLayers.h ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/ApplicationDelegate.h ! src/macosx/native/sun/awt/ApplicationDelegate.m ! src/macosx/native/sun/awt/CClipboard.h ! src/macosx/native/sun/awt/CClipboard.m ! src/macosx/native/sun/awt/CCursorManager.m ! src/macosx/native/sun/awt/CDataTransferer.h ! src/macosx/native/sun/awt/CDataTransferer.m ! src/macosx/native/sun/awt/CDesktopPeer.m ! src/macosx/native/sun/awt/CDragSource.h ! src/macosx/native/sun/awt/CDragSource.m ! src/macosx/native/sun/awt/CDragSourceContextPeer.m ! src/macosx/native/sun/awt/CDropTarget.h ! src/macosx/native/sun/awt/CDropTarget.m ! src/macosx/native/sun/awt/CDropTargetContextPeer.m ! src/macosx/native/sun/awt/CFRetainedResource.m ! src/macosx/native/sun/awt/CFileDialog.h ! src/macosx/native/sun/awt/CGraphicsConfig.m ! src/macosx/native/sun/awt/CGraphicsEnv.m ! src/macosx/native/sun/awt/CImage.m ! src/macosx/native/sun/awt/CInputMethod.m ! src/macosx/native/sun/awt/CMenu.h ! src/macosx/native/sun/awt/CMenu.m ! src/macosx/native/sun/awt/CMenuBar.h ! src/macosx/native/sun/awt/CMenuBar.m ! src/macosx/native/sun/awt/CMenuComponent.h ! src/macosx/native/sun/awt/CMenuComponent.m ! src/macosx/native/sun/awt/CMenuItem.h ! src/macosx/native/sun/awt/CPopupMenu.h ! src/macosx/native/sun/awt/CPopupMenu.m ! src/macosx/native/sun/awt/CPrinterJob.m ! src/macosx/native/sun/awt/CRobot.m ! src/macosx/native/sun/awt/CSystemColors.h ! src/macosx/native/sun/awt/CSystemColors.m ! src/macosx/native/sun/awt/CTextPipe.m ! src/macosx/native/sun/awt/CTrayIcon.h ! src/macosx/native/sun/awt/CTrayIcon.m ! src/macosx/native/sun/awt/CWrapper.h ! src/macosx/native/sun/awt/DnDUtilities.h ! src/macosx/native/sun/awt/DnDUtilities.m ! src/macosx/native/sun/awt/GeomUtilities.h ! src/macosx/native/sun/awt/GeomUtilities.m ! src/macosx/native/sun/awt/ImageSurfaceData.h ! src/macosx/native/sun/awt/ImageSurfaceData.m ! src/macosx/native/sun/awt/InitIDs.h ! src/macosx/native/sun/awt/InitIDs.m ! src/macosx/native/sun/awt/JavaAccessibilityAction.h ! src/macosx/native/sun/awt/JavaAccessibilityAction.m ! src/macosx/native/sun/awt/JavaAccessibilityUtilities.h ! src/macosx/native/sun/awt/JavaAccessibilityUtilities.m ! src/macosx/native/sun/awt/JavaComponentAccessibility.h ! src/macosx/native/sun/awt/JavaComponentAccessibility.m ! src/macosx/native/sun/awt/JavaTextAccessibility.h ! src/macosx/native/sun/awt/JavaTextAccessibility.m ! src/macosx/native/sun/awt/LWCToolkit.h ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/awt/OSVersion.h ! src/macosx/native/sun/awt/OSVersion.m ! src/macosx/native/sun/awt/PrintModel.h ! src/macosx/native/sun/awt/PrintModel.m ! src/macosx/native/sun/awt/PrinterSurfaceData.h ! src/macosx/native/sun/awt/PrinterSurfaceData.m ! src/macosx/native/sun/awt/PrinterView.h ! src/macosx/native/sun/awt/QuartzRenderer.m ! src/macosx/native/sun/awt/QuartzSurfaceData.h ! src/macosx/native/sun/awt/QuartzSurfaceData.m ! src/macosx/native/sun/awt/awt.m ! src/macosx/native/sun/awt/awt_DrawingSurface.m ! src/macosx/native/sun/awt/jawt.m ! src/macosx/native/sun/awt/splashscreen/splashscreen_config.h ! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m ! src/macosx/native/sun/font/AWTFont.h ! src/macosx/native/sun/font/AWTFont.m ! src/macosx/native/sun/font/CCharToGlyphMapper.m ! src/macosx/native/sun/font/CGGlyphImages.h ! src/macosx/native/sun/font/CGGlyphOutlines.h ! src/macosx/native/sun/font/CGGlyphOutlines.m ! src/macosx/native/sun/font/CoreTextSupport.h ! src/macosx/native/sun/font/CoreTextSupport.m ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.h ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.h ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.h ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m ! src/macosx/native/sun/java2d/opengl/J2D_GL/cglext.h ! src/macosx/native/sun/java2d/opengl/OGLFuncs_md.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m ! src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c ! src/share/back/SDE.c ! src/share/back/ThreadGroupReferenceImpl.c ! src/share/back/commonRef.c ! src/share/back/eventFilter.c ! src/share/back/export/sys.h ! src/share/back/outStream.c ! src/share/back/transport.c ! src/share/back/util.c ! src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java ! src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java ! src/share/classes/com/sun/beans/decoder/ByteElementHandler.java ! src/share/classes/com/sun/beans/decoder/CharElementHandler.java ! src/share/classes/com/sun/beans/decoder/ClassElementHandler.java ! src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java ! src/share/classes/com/sun/beans/decoder/ElementHandler.java ! src/share/classes/com/sun/beans/decoder/FalseElementHandler.java ! src/share/classes/com/sun/beans/decoder/FieldElementHandler.java ! src/share/classes/com/sun/beans/decoder/FloatElementHandler.java ! src/share/classes/com/sun/beans/decoder/IntElementHandler.java ! src/share/classes/com/sun/beans/decoder/JavaElementHandler.java ! src/share/classes/com/sun/beans/decoder/LongElementHandler.java ! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java ! src/share/classes/com/sun/beans/decoder/NewElementHandler.java ! src/share/classes/com/sun/beans/decoder/NullElementHandler.java ! src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java ! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java ! src/share/classes/com/sun/beans/decoder/ShortElementHandler.java ! src/share/classes/com/sun/beans/decoder/StringElementHandler.java ! src/share/classes/com/sun/beans/decoder/TrueElementHandler.java ! src/share/classes/com/sun/beans/decoder/VarElementHandler.java ! src/share/classes/com/sun/beans/decoder/VoidElementHandler.java ! src/share/classes/com/sun/beans/finder/Signature.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java ! src/share/classes/com/sun/crypto/provider/PCBC.java ! src/share/classes/com/sun/demo/jvmti/hprof/Tracker.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPConstants.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java ! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormat.java ! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormatResources.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/share/classes/com/sun/jarsigner/ContentSignerParameters.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyleFactory.java ! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsProgressBarUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/Accessible.java ! src/share/classes/com/sun/jdi/ArrayReference.java ! src/share/classes/com/sun/jdi/ArrayType.java ! src/share/classes/com/sun/jdi/BooleanType.java ! src/share/classes/com/sun/jdi/BooleanValue.java ! src/share/classes/com/sun/jdi/Bootstrap.java ! src/share/classes/com/sun/jdi/ByteType.java ! src/share/classes/com/sun/jdi/ByteValue.java ! src/share/classes/com/sun/jdi/CharType.java ! src/share/classes/com/sun/jdi/CharValue.java ! src/share/classes/com/sun/jdi/ClassLoaderReference.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/ClassObjectReference.java ! src/share/classes/com/sun/jdi/ClassType.java ! src/share/classes/com/sun/jdi/DoubleType.java ! src/share/classes/com/sun/jdi/DoubleValue.java ! src/share/classes/com/sun/jdi/Field.java ! src/share/classes/com/sun/jdi/FloatType.java ! src/share/classes/com/sun/jdi/FloatValue.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/IntegerType.java ! src/share/classes/com/sun/jdi/IntegerValue.java ! src/share/classes/com/sun/jdi/InterfaceType.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/LocalVariable.java ! src/share/classes/com/sun/jdi/Locatable.java ! src/share/classes/com/sun/jdi/Location.java ! src/share/classes/com/sun/jdi/LongType.java ! src/share/classes/com/sun/jdi/LongValue.java ! src/share/classes/com/sun/jdi/Method.java ! src/share/classes/com/sun/jdi/Mirror.java ! src/share/classes/com/sun/jdi/MonitorInfo.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/ObjectReference.java ! src/share/classes/com/sun/jdi/PathSearchingVirtualMachine.java ! src/share/classes/com/sun/jdi/PrimitiveType.java ! src/share/classes/com/sun/jdi/PrimitiveValue.java ! src/share/classes/com/sun/jdi/ReferenceType.java ! src/share/classes/com/sun/jdi/ShortType.java ! src/share/classes/com/sun/jdi/ShortValue.java ! src/share/classes/com/sun/jdi/StackFrame.java ! src/share/classes/com/sun/jdi/StringReference.java ! src/share/classes/com/sun/jdi/ThreadGroupReference.java ! src/share/classes/com/sun/jdi/ThreadReference.java ! src/share/classes/com/sun/jdi/Type.java ! src/share/classes/com/sun/jdi/TypeComponent.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/Value.java ! src/share/classes/com/sun/jdi/VirtualMachine.java ! src/share/classes/com/sun/jdi/VirtualMachineManager.java ! src/share/classes/com/sun/jdi/VoidType.java ! src/share/classes/com/sun/jdi/VoidValue.java ! src/share/classes/com/sun/jdi/connect/AttachingConnector.java ! src/share/classes/com/sun/jdi/connect/Connector.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/LaunchingConnector.java ! src/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/share/classes/com/sun/jdi/connect/Transport.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/connect/spi/Connection.java ! src/share/classes/com/sun/jdi/connect/spi/TransportService.java ! src/share/classes/com/sun/jdi/event/AccessWatchpointEvent.java ! src/share/classes/com/sun/jdi/event/BreakpointEvent.java ! src/share/classes/com/sun/jdi/event/ClassPrepareEvent.java ! src/share/classes/com/sun/jdi/event/ClassUnloadEvent.java ! src/share/classes/com/sun/jdi/event/Event.java ! src/share/classes/com/sun/jdi/event/EventIterator.java ! src/share/classes/com/sun/jdi/event/EventQueue.java ! src/share/classes/com/sun/jdi/event/EventSet.java ! src/share/classes/com/sun/jdi/event/ExceptionEvent.java ! src/share/classes/com/sun/jdi/event/LocatableEvent.java ! src/share/classes/com/sun/jdi/event/MethodEntryEvent.java ! src/share/classes/com/sun/jdi/event/MethodExitEvent.java ! src/share/classes/com/sun/jdi/event/ModificationWatchpointEvent.java ! src/share/classes/com/sun/jdi/event/MonitorContendedEnterEvent.java ! src/share/classes/com/sun/jdi/event/MonitorContendedEnteredEvent.java ! src/share/classes/com/sun/jdi/event/MonitorWaitEvent.java ! src/share/classes/com/sun/jdi/event/MonitorWaitedEvent.java ! src/share/classes/com/sun/jdi/event/StepEvent.java ! src/share/classes/com/sun/jdi/event/ThreadDeathEvent.java ! src/share/classes/com/sun/jdi/event/ThreadStartEvent.java ! src/share/classes/com/sun/jdi/event/VMDeathEvent.java ! src/share/classes/com/sun/jdi/event/VMDisconnectEvent.java ! src/share/classes/com/sun/jdi/event/VMStartEvent.java ! src/share/classes/com/sun/jdi/event/WatchpointEvent.java ! src/share/classes/com/sun/jdi/request/AccessWatchpointRequest.java ! src/share/classes/com/sun/jdi/request/BreakpointRequest.java ! src/share/classes/com/sun/jdi/request/ClassPrepareRequest.java ! src/share/classes/com/sun/jdi/request/ClassUnloadRequest.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/EventRequest.java ! src/share/classes/com/sun/jdi/request/EventRequestManager.java ! src/share/classes/com/sun/jdi/request/ExceptionRequest.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/jdi/request/MethodEntryRequest.java ! src/share/classes/com/sun/jdi/request/MethodExitRequest.java ! src/share/classes/com/sun/jdi/request/ModificationWatchpointRequest.java ! src/share/classes/com/sun/jdi/request/MonitorContendedEnterRequest.java ! src/share/classes/com/sun/jdi/request/MonitorContendedEnteredRequest.java ! src/share/classes/com/sun/jdi/request/MonitorWaitRequest.java ! src/share/classes/com/sun/jdi/request/MonitorWaitedRequest.java ! src/share/classes/com/sun/jdi/request/StepRequest.java ! src/share/classes/com/sun/jdi/request/ThreadDeathRequest.java ! src/share/classes/com/sun/jdi/request/ThreadStartRequest.java ! src/share/classes/com/sun/jdi/request/VMDeathRequest.java ! src/share/classes/com/sun/jdi/request/WatchpointRequest.java ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java ! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java ! src/share/classes/com/sun/jmx/mbeanserver/StandardMBeanIntrospector.java ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java ! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java ! src/share/classes/com/sun/jmx/snmp/Enumerated.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java ! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java ! src/share/classes/com/sun/jmx/snmp/SnmpString.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgentMBean.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java ! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java ! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java ! src/share/classes/com/sun/jndi/ldap/BerDecoder.java ! src/share/classes/com/sun/jndi/ldap/BerEncoder.java ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/Filter.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java ! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java ! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java ! src/share/classes/com/sun/management/GarbageCollectorMXBean.java ! src/share/classes/com/sun/management/GcInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/com/sun/management/OperatingSystemMXBean.java ! src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/com/sun/management/UnixOperatingSystemMXBean.java ! src/share/classes/com/sun/management/VMOption.java ! src/share/classes/com/sun/media/sound/FastSysexMessage.java ! src/share/classes/com/sun/media/sound/SunFileReader.java ! src/share/classes/com/sun/naming/internal/ResourceManager.java ! src/share/classes/com/sun/net/httpserver/Authenticator.java ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Filter.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpContext.java ! src/share/classes/com/sun/net/httpserver/HttpExchange.java ! src/share/classes/com/sun/net/httpserver/HttpHandler.java ! src/share/classes/com/sun/net/httpserver/HttpPrincipal.java ! src/share/classes/com/sun/net/httpserver/HttpServer.java ! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java ! src/share/classes/com/sun/net/httpserver/HttpsExchange.java ! src/share/classes/com/sun/net/httpserver/HttpsParameters.java ! src/share/classes/com/sun/net/httpserver/HttpsServer.java ! src/share/classes/com/sun/net/httpserver/package-info.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/httpserver/spi/package-info.java ! src/share/classes/com/sun/net/ssl/internal/ssl/Provider.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/com/sun/nio/sctp/AbstractNotificationHandler.java ! src/share/classes/com/sun/nio/sctp/Association.java ! src/share/classes/com/sun/nio/sctp/AssociationChangeNotification.java ! src/share/classes/com/sun/nio/sctp/HandlerResult.java ! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java ! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java ! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/Notification.java ! src/share/classes/com/sun/nio/sctp/NotificationHandler.java ! src/share/classes/com/sun/nio/sctp/PeerAddressChangeNotification.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java ! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/com/sun/nio/sctp/SendFailedNotification.java ! src/share/classes/com/sun/nio/sctp/ShutdownNotification.java ! src/share/classes/com/sun/nio/sctp/package-info.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/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/rowset/WebRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/BaseRow.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/package.html ! src/share/classes/com/sun/security/auth/LdapPrincipal.java ! src/share/classes/com/sun/security/auth/NTDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTNumericCredential.java ! src/share/classes/com/sun/security/auth/NTSid.java ! src/share/classes/com/sun/security/auth/NTSidDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidPrimaryGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidUserPrincipal.java ! src/share/classes/com/sun/security/auth/NTUserPrincipal.java ! src/share/classes/com/sun/security/auth/PrincipalComparator.java ! src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/UnixPrincipal.java ! src/share/classes/com/sun/security/auth/UserPrincipal.java ! src/share/classes/com/sun/security/auth/X500Principal.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/com/sun/security/auth/module/NTLoginModule.java ! src/share/classes/com/sun/security/auth/module/NTSystem.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisSystem.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixSystem.java ! src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java ! src/share/classes/com/sun/security/jgss/GSSUtil.java ! src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java ! src/share/classes/com/sun/security/jgss/InquireType.java ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLM.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/com/sun/tools/attach/AgentInitializationException.java ! src/share/classes/com/sun/tools/attach/AgentLoadException.java ! src/share/classes/com/sun/tools/attach/AttachNotSupportedException.java ! src/share/classes/com/sun/tools/attach/AttachPermission.java ! src/share/classes/com/sun/tools/attach/VirtualMachineDescriptor.java ! src/share/classes/com/sun/tools/attach/spi/AttachProvider.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/HttpReader.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLHelp.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/QueryHandler.java ! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java ! src/share/classes/com/sun/tools/hat/resources/hat.js ! src/share/classes/com/sun/tools/hat/resources/oqlhelp.html ! src/share/classes/com/sun/tools/jconsole/JConsoleContext.java ! src/share/classes/com/sun/tools/jconsole/JConsolePlugin.java ! src/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/com/sun/tools/jdi/SDE.java ! src/share/classes/com/sun/tools/jdi/SocketAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/SocketListeningConnector.java ! src/share/classes/com/sun/tools/jdi/ThreadListener.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/script/shell/messages.properties ! src/share/classes/java/applet/Applet.java ! src/share/classes/java/applet/AppletStub.java ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AWTEventMulticaster.java ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/AWTPermission.java ! src/share/classes/java/awt/AttributeValue.java ! src/share/classes/java/awt/BorderLayout.java ! src/share/classes/java/awt/BufferCapabilities.java ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/CardLayout.java ! src/share/classes/java/awt/Checkbox.java ! src/share/classes/java/awt/CheckboxGroup.java ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Color.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/DefaultFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Event.java ! src/share/classes/java/awt/EventFilter.java ! src/share/classes/java/awt/FlowLayout.java ! src/share/classes/java/awt/FocusTraversalPolicy.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/FontMetrics.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GradientPaintContext.java ! src/share/classes/java/awt/Graphics.java ! src/share/classes/java/awt/Graphics2D.java ! src/share/classes/java/awt/GraphicsConfiguration.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/GridLayout.java ! src/share/classes/java/awt/ImageCapabilities.java ! src/share/classes/java/awt/Insets.java ! src/share/classes/java/awt/JobAttributes.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Label.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/LinearGradientPaintContext.java ! src/share/classes/java/awt/MediaTracker.java ! src/share/classes/java/awt/Menu.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/MultipleGradientPaintContext.java ! src/share/classes/java/awt/PageAttributes.java ! src/share/classes/java/awt/Polygon.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/Rectangle.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/java/awt/Scrollbar.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/java/awt/Shape.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/TexturePaintContext.java ! src/share/classes/java/awt/TrayIcon.java ! src/share/classes/java/awt/WaitDispatchSupport.java ! src/share/classes/java/awt/color/ICC_ColorSpace.java ! src/share/classes/java/awt/color/ICC_ProfileGray.java ! src/share/classes/java/awt/color/ICC_ProfileRGB.java ! src/share/classes/java/awt/color/package.html ! src/share/classes/java/awt/datatransfer/Clipboard.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/datatransfer/FlavorMap.java ! src/share/classes/java/awt/datatransfer/MimeType.java ! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java ! src/share/classes/java/awt/datatransfer/Transferable.java ! src/share/classes/java/awt/datatransfer/package.html ! src/share/classes/java/awt/dnd/DnDEventMulticaster.java ! src/share/classes/java/awt/dnd/DragGestureEvent.java ! src/share/classes/java/awt/dnd/DragGestureListener.java ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSource.java ! src/share/classes/java/awt/dnd/DragSourceContext.java ! src/share/classes/java/awt/dnd/DragSourceDragEvent.java ! src/share/classes/java/awt/dnd/DragSourceDropEvent.java ! src/share/classes/java/awt/dnd/DragSourceEvent.java ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/java/awt/dnd/DropTargetDragEvent.java ! src/share/classes/java/awt/dnd/DropTargetDropEvent.java ! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/share/classes/java/awt/dnd/package.html ! src/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/share/classes/java/awt/doc-files/DesktopProperties.html ! src/share/classes/java/awt/doc-files/FocusSpec.html ! src/share/classes/java/awt/doc-files/Modality.html ! src/share/classes/java/awt/event/ActionListener.java ! src/share/classes/java/awt/event/ComponentAdapter.java ! src/share/classes/java/awt/event/ComponentListener.java ! src/share/classes/java/awt/event/ContainerAdapter.java ! src/share/classes/java/awt/event/ContainerEvent.java ! src/share/classes/java/awt/event/ContainerListener.java ! src/share/classes/java/awt/event/FocusAdapter.java ! src/share/classes/java/awt/event/FocusListener.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/InvocationEvent.java ! src/share/classes/java/awt/event/ItemEvent.java ! src/share/classes/java/awt/event/ItemListener.java ! src/share/classes/java/awt/event/KeyAdapter.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/java/awt/event/MouseAdapter.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/event/MouseListener.java ! src/share/classes/java/awt/event/MouseMotionAdapter.java ! src/share/classes/java/awt/event/MouseMotionListener.java ! src/share/classes/java/awt/event/NativeLibLoader.java ! src/share/classes/java/awt/event/WindowAdapter.java ! src/share/classes/java/awt/event/WindowFocusListener.java ! src/share/classes/java/awt/event/WindowListener.java ! src/share/classes/java/awt/event/package.html ! src/share/classes/java/awt/font/FontRenderContext.java ! src/share/classes/java/awt/font/GlyphMetrics.java ! src/share/classes/java/awt/font/GlyphVector.java ! src/share/classes/java/awt/font/LineBreakMeasurer.java ! src/share/classes/java/awt/font/MultipleMaster.java ! src/share/classes/java/awt/font/NumericShaper.java ! src/share/classes/java/awt/font/OpenType.java ! src/share/classes/java/awt/font/StyledParagraph.java ! src/share/classes/java/awt/font/TextAttribute.java ! src/share/classes/java/awt/font/TextLayout.java ! src/share/classes/java/awt/font/TextLine.java ! src/share/classes/java/awt/font/TextMeasurer.java ! src/share/classes/java/awt/font/TransformAttribute.java ! src/share/classes/java/awt/font/package.html ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/Arc2D.java ! src/share/classes/java/awt/geom/Dimension2D.java ! src/share/classes/java/awt/geom/FlatteningPathIterator.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/geom/Path2D.java ! src/share/classes/java/awt/geom/Point2D.java ! src/share/classes/java/awt/geom/QuadCurve2D.java ! src/share/classes/java/awt/geom/RectangularShape.java ! src/share/classes/java/awt/geom/package.html ! src/share/classes/java/awt/im/InputContext.java ! src/share/classes/java/awt/im/InputMethodHighlight.java ! src/share/classes/java/awt/im/InputMethodRequests.java ! src/share/classes/java/awt/image/BandedSampleModel.java ! src/share/classes/java/awt/image/BufferStrategy.java ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/classes/java/awt/image/ByteLookupTable.java ! src/share/classes/java/awt/image/ColorConvertOp.java ! src/share/classes/java/awt/image/ColorModel.java ! src/share/classes/java/awt/image/ComponentColorModel.java ! src/share/classes/java/awt/image/ComponentSampleModel.java ! src/share/classes/java/awt/image/DirectColorModel.java ! src/share/classes/java/awt/image/ImageFilter.java ! src/share/classes/java/awt/image/ImageProducer.java ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/Kernel.java ! src/share/classes/java/awt/image/MemoryImageSource.java ! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java ! src/share/classes/java/awt/image/PixelGrabber.java ! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java ! src/share/classes/java/awt/image/RGBImageFilter.java ! src/share/classes/java/awt/image/Raster.java ! src/share/classes/java/awt/image/SampleModel.java ! src/share/classes/java/awt/image/ShortLookupTable.java ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/share/classes/java/awt/image/WritableRaster.java ! src/share/classes/java/awt/image/package.html ! src/share/classes/java/awt/image/renderable/RenderableImage.java ! src/share/classes/java/awt/image/renderable/RenderableImageOp.java ! src/share/classes/java/awt/image/renderable/package.html ! src/share/classes/java/awt/package.html ! src/share/classes/java/awt/peer/CheckboxPeer.java ! src/share/classes/java/awt/peer/DesktopPeer.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/share/classes/java/awt/print/Book.java ! src/share/classes/java/awt/print/PrinterJob.java ! src/share/classes/java/awt/print/package.html ! src/share/classes/java/beans/BeanDescriptor.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/NameGenerator.java ! src/share/classes/java/beans/PropertyEditorManager.java ! src/share/classes/java/beans/PropertyEditorSupport.java ! src/share/classes/java/beans/SimpleBeanInfo.java ! src/share/classes/java/beans/XMLEncoder.java ! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java ! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/ByteArrayInputStream.java ! src/share/classes/java/io/ByteArrayOutputStream.java ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/DataOutput.java ! src/share/classes/java/io/EOFException.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/FileSystem.java ! src/share/classes/java/io/ObjectStreamConstants.java ! src/share/classes/java/io/PipedReader.java ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! src/share/classes/java/io/Serializable.java ! src/share/classes/java/io/SerializablePermission.java ! src/share/classes/java/io/StringReader.java ! src/share/classes/java/lang/ArrayStoreException.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/ClassCastException.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java ! src/share/classes/java/lang/instrument/package.html ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/Stable.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/java/lang/management/CompilationMXBean.java ! src/share/classes/java/lang/management/ManagementPermission.java ! src/share/classes/java/lang/management/package.html ! src/share/classes/java/lang/reflect/Array.java ! src/share/classes/java/lang/reflect/Member.java ! src/share/classes/java/lang/reflect/ReflectPermission.java ! src/share/classes/java/lang/reflect/Type.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/Inet4AddressImpl.java ! src/share/classes/java/net/Inet6AddressImpl.java ! src/share/classes/java/net/SocketAddress.java ! src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template ! src/share/classes/java/nio/ByteOrder.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/java/nio/Heap-X-Buffer.java.template ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/StringCharBuffer.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/Channel.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/MembershipKey.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/AbstractSelectionKey.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/CoderResult.java ! src/share/classes/java/nio/charset/CodingErrorAction.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/FileTreeWalker.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/FileTime.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/nio/package.html ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/sql/Array.java ! src/share/classes/java/sql/Connection.java ! src/share/classes/java/sql/DataTruncation.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/DriverPropertyInfo.java ! src/share/classes/java/sql/SQLException.java ! src/share/classes/java/sql/SQLFeatureNotSupportedException.java ! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java ! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java ! src/share/classes/java/sql/SQLNonTransientConnectionException.java ! src/share/classes/java/sql/SQLNonTransientException.java ! src/share/classes/java/sql/SQLRecoverableException.java ! src/share/classes/java/sql/SQLSyntaxErrorException.java ! src/share/classes/java/sql/SQLTransactionRollbackException.java ! src/share/classes/java/sql/SQLTransientConnectionException.java ! src/share/classes/java/sql/SQLTransientException.java ! src/share/classes/java/sql/SQLWarning.java ! src/share/classes/java/sql/Struct.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/sql/Timestamp.java ! src/share/classes/java/text/CharacterIterator.java ! src/share/classes/java/text/Collator.java ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/ArraysParallelSortHelpers.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/ConcurrentModificationException.java ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/DualPivotQuicksort.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Formattable.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/java/util/MissingFormatWidthException.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/PropertyResourceBundle.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/TimerTask.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/function/ToIntBiFunction.java ! src/share/classes/java/util/function/package-info.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/java/util/logging/SocketHandler.java ! src/share/classes/java/util/logging/StreamHandler.java ! src/share/classes/java/util/logging/XMLFormatter.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/java/util/regex/UnicodeProp.java ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/classes/java/util/zip/DeflaterInputStream.java ! src/share/classes/java/util/zip/DeflaterOutputStream.java ! src/share/classes/java/util/zip/GZIPOutputStream.java ! src/share/classes/java/util/zip/InflaterInputStream.java ! src/share/classes/java/util/zip/InflaterOutputStream.java ! src/share/classes/java/util/zip/ZipConstants.java ! src/share/classes/java/util/zip/ZipConstants64.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/javax/accessibility/AccessibleAction.java ! src/share/classes/javax/accessibility/AccessibleContext.java ! src/share/classes/javax/accessibility/AccessibleText.java ! src/share/classes/javax/crypto/JceSecurityManager.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/crypto/spec/IvParameterSpec.java ! src/share/classes/javax/crypto/spec/PBEParameterSpec.java ! src/share/classes/javax/crypto/spec/RC5ParameterSpec.java ! src/share/classes/javax/crypto/spec/SecretKeySpec.java ! src/share/classes/javax/imageio/IIOParam.java ! src/share/classes/javax/imageio/ImageIO.java ! src/share/classes/javax/imageio/ImageReadParam.java ! src/share/classes/javax/imageio/ImageReader.java ! src/share/classes/javax/imageio/ImageTypeSpecifier.java ! src/share/classes/javax/imageio/ImageWriteParam.java ! src/share/classes/javax/imageio/ImageWriter.java ! src/share/classes/javax/imageio/event/IIOReadProgressListener.java ! src/share/classes/javax/imageio/event/IIOReadUpdateListener.java ! src/share/classes/javax/imageio/event/IIOReadWarningListener.java ! src/share/classes/javax/imageio/event/IIOWriteWarningListener.java ! src/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormat.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html ! src/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html ! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java ! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageReadParam.java ! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java ! src/share/classes/javax/imageio/spi/IIORegistry.java ! src/share/classes/javax/imageio/spi/ImageReaderSpi.java ! src/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/share/classes/javax/imageio/spi/ImageWriterSpi.java ! src/share/classes/javax/imageio/spi/ServiceRegistry.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java ! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java ! src/share/classes/javax/imageio/stream/ImageOutputStream.java ! src/share/classes/javax/management/AttributeList.java ! src/share/classes/javax/management/BadAttributeValueExpException.java ! src/share/classes/javax/management/BooleanValueExp.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/DescriptorKey.java ! src/share/classes/javax/management/ImmutableDescriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java ! src/share/classes/javax/management/MBeanParameterInfo.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/MBeanServerFactory.java ! src/share/classes/javax/management/MBeanServerInvocationHandler.java ! src/share/classes/javax/management/MBeanServerNotification.java ! src/share/classes/javax/management/MBeanTrustPermission.java ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/NumericValueExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/PersistentMBean.java ! src/share/classes/javax/management/Query.java ! src/share/classes/javax/management/StandardEmitterMBean.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/loading/MLetParser.java ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java ! src/share/classes/javax/management/monitor/Monitor.java ! src/share/classes/javax/management/monitor/package.html ! src/share/classes/javax/management/openmbean/ArrayType.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/CompositeType.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java ! src/share/classes/javax/management/openmbean/SimpleType.java ! src/share/classes/javax/management/openmbean/TabularType.java ! src/share/classes/javax/management/package.html ! src/share/classes/javax/management/relation/Relation.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/relation/RelationServiceMBean.java ! src/share/classes/javax/management/relation/RelationSupport.java ! src/share/classes/javax/management/remote/JMXConnectionNotification.java ! src/share/classes/javax/management/remote/JMXConnector.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/JMXConnectorProvider.java ! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java ! src/share/classes/javax/management/remote/JMXPrincipal.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java ! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java ! src/share/classes/javax/management/remote/rmi/package.html ! src/share/classes/javax/naming/BinaryRefAddr.java ! src/share/classes/javax/naming/Binding.java ! src/share/classes/javax/naming/InsufficientResourcesException.java ! src/share/classes/javax/naming/directory/Attribute.java ! src/share/classes/javax/naming/ldap/InitialLdapContext.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/PagedResultsControl.java ! src/share/classes/javax/naming/ldap/SortControl.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/SSLContextSpi.java ! src/share/classes/javax/net/ssl/SSLEngineResult.java ! src/share/classes/javax/net/ssl/SSLPeerUnverifiedException.java ! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/share/classes/javax/net/ssl/SSLSession.java ! src/share/classes/javax/net/ssl/SSLSessionContext.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/print/CancelablePrintJob.java ! src/share/classes/javax/print/Doc.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/DocPrintJob.java ! src/share/classes/javax/print/MultiDoc.java ! src/share/classes/javax/print/MultiDocPrintJob.java ! src/share/classes/javax/print/PrintService.java ! src/share/classes/javax/print/ServiceUI.java ! src/share/classes/javax/print/ServiceUIFactory.java ! src/share/classes/javax/print/attribute/AttributeSet.java ! src/share/classes/javax/print/attribute/DateTimeSyntax.java ! src/share/classes/javax/print/attribute/DocAttributeSet.java ! src/share/classes/javax/print/attribute/EnumSyntax.java ! src/share/classes/javax/print/attribute/HashAttributeSet.java ! src/share/classes/javax/print/attribute/IntegerSyntax.java ! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java ! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java ! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java ! src/share/classes/javax/print/attribute/ResolutionSyntax.java ! src/share/classes/javax/print/attribute/Size2DSyntax.java ! src/share/classes/javax/print/attribute/package.html ! src/share/classes/javax/print/attribute/standard/Chromaticity.java ! src/share/classes/javax/print/attribute/standard/Compression.java ! src/share/classes/javax/print/attribute/standard/Finishings.java ! src/share/classes/javax/print/attribute/standard/JobKOctets.java ! src/share/classes/javax/print/attribute/standard/JobStateReasons.java ! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/share/classes/javax/print/attribute/standard/MediaSize.java ! src/share/classes/javax/print/attribute/standard/MediaTray.java ! src/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java ! src/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java ! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java ! src/share/classes/javax/print/attribute/standard/PrinterResolution.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReason.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/Sides.java ! src/share/classes/javax/print/attribute/standard/package.html ! src/share/classes/javax/print/event/package.html ! src/share/classes/javax/print/package.html ! src/share/classes/javax/script/AbstractScriptEngine.java ! src/share/classes/javax/script/CompiledScript.java ! src/share/classes/javax/script/ScriptEngine.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/smartcardio/CardChannel.java ! src/share/classes/javax/smartcardio/CardTerminal.java ! src/share/classes/javax/smartcardio/ResponseAPDU.java ! src/share/classes/javax/sound/midi/Soundbank.java ! src/share/classes/javax/sound/sampled/DataLine.java ! src/share/classes/javax/sound/sampled/ReverbType.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/JoinRowSet.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java ! src/share/classes/javax/sql/rowset/spi/TransactionalWriter.java ! src/share/classes/javax/sql/rowset/spi/XmlReader.java ! src/share/classes/javax/sql/rowset/spi/XmlWriter.java ! src/share/classes/javax/swing/AbstractAction.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/AbstractCellEditor.java ! src/share/classes/javax/swing/AbstractListModel.java ! src/share/classes/javax/swing/Action.java ! src/share/classes/javax/swing/ActionMap.java ! src/share/classes/javax/swing/ActionPropertyChangeListener.java ! src/share/classes/javax/swing/ArrayTable.java ! src/share/classes/javax/swing/BorderFactory.java ! src/share/classes/javax/swing/BoundedRangeModel.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/CellRendererPane.java ! src/share/classes/javax/swing/ClientPropertyKey.java ! src/share/classes/javax/swing/ComboBoxModel.java ! src/share/classes/javax/swing/ComponentInputMap.java ! src/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/share/classes/javax/swing/DefaultButtonModel.java ! src/share/classes/javax/swing/DefaultCellEditor.java ! src/share/classes/javax/swing/DefaultFocusManager.java ! src/share/classes/javax/swing/DefaultListCellRenderer.java ! src/share/classes/javax/swing/DefaultListModel.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DefaultRowSorter.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/DesktopManager.java ! src/share/classes/javax/swing/FocusManager.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/InputMap.java ! src/share/classes/javax/swing/InputVerifier.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JFormattedTextField.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JProgressBar.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollBar.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/KeyboardManager.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/MenuSelectionManager.java ! src/share/classes/javax/swing/MutableComboBoxModel.java ! src/share/classes/javax/swing/OverlayLayout.java ! src/share/classes/javax/swing/Painter.java ! src/share/classes/javax/swing/Popup.java ! src/share/classes/javax/swing/PopupFactory.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/ProgressMonitorInputStream.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/RootPaneContainer.java ! src/share/classes/javax/swing/RowFilter.java ! src/share/classes/javax/swing/ScrollPaneConstants.java ! src/share/classes/javax/swing/ScrollPaneLayout.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/SizeSequence.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/javax/swing/SpinnerDateModel.java ! src/share/classes/javax/swing/SpinnerListModel.java ! src/share/classes/javax/swing/SpinnerModel.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/Spring.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TimerQueue.java ! src/share/classes/javax/swing/ToolTipManager.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java ! src/share/classes/javax/swing/ViewportLayout.java ! src/share/classes/javax/swing/WindowConstants.java ! src/share/classes/javax/swing/border/AbstractBorder.java ! src/share/classes/javax/swing/border/BevelBorder.java ! src/share/classes/javax/swing/border/Border.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/border/EmptyBorder.java ! src/share/classes/javax/swing/border/EtchedBorder.java ! src/share/classes/javax/swing/border/LineBorder.java ! src/share/classes/javax/swing/border/MatteBorder.java ! src/share/classes/javax/swing/border/SoftBevelBorder.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/border/package.html ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserComponentFactory.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultPreviewPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java ! src/share/classes/javax/swing/colorchooser/package.html ! src/share/classes/javax/swing/event/AncestorEvent.java ! src/share/classes/javax/swing/event/CaretEvent.java ! src/share/classes/javax/swing/event/ChangeEvent.java ! src/share/classes/javax/swing/event/DocumentEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/HyperlinkEvent.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameEvent.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/ListSelectionEvent.java ! src/share/classes/javax/swing/event/MenuDragMouseEvent.java ! src/share/classes/javax/swing/event/MenuEvent.java ! src/share/classes/javax/swing/event/MenuKeyEvent.java ! src/share/classes/javax/swing/event/PopupMenuEvent.java ! src/share/classes/javax/swing/event/TableColumnModelEvent.java ! src/share/classes/javax/swing/event/TableModelEvent.java ! src/share/classes/javax/swing/event/TreeExpansionEvent.java ! src/share/classes/javax/swing/event/TreeExpansionListener.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/event/TreeModelListener.java ! src/share/classes/javax/swing/event/TreeSelectionEvent.java ! src/share/classes/javax/swing/event/TreeSelectionListener.java ! src/share/classes/javax/swing/event/TreeWillExpandListener.java ! src/share/classes/javax/swing/event/UndoableEditEvent.java ! src/share/classes/javax/swing/event/package.html ! src/share/classes/javax/swing/filechooser/FileFilter.java ! src/share/classes/javax/swing/filechooser/FileSystemView.java ! src/share/classes/javax/swing/filechooser/FileView.java ! src/share/classes/javax/swing/filechooser/package.html ! src/share/classes/javax/swing/package.html ! src/share/classes/javax/swing/plaf/BorderUIResource.java ! src/share/classes/javax/swing/plaf/ColorUIResource.java ! src/share/classes/javax/swing/plaf/ComboBoxUI.java ! src/share/classes/javax/swing/plaf/ComponentUI.java ! src/share/classes/javax/swing/plaf/DimensionUIResource.java ! src/share/classes/javax/swing/plaf/FontUIResource.java ! src/share/classes/javax/swing/plaf/IconUIResource.java ! src/share/classes/javax/swing/plaf/InsetsUIResource.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/plaf/TextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicArrowButton.java ! src/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java ! src/share/classes/javax/swing/plaf/basic/BasicCheckBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxRenderer.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/javax/swing/plaf/basic/BasicEditorPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/share/classes/javax/swing/plaf/basic/ComboPopup.java ! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java ! src/share/classes/javax/swing/plaf/basic/package.html ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/share/classes/javax/swing/plaf/metal/MetalButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxIcon.java ! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxButton.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/share/classes/javax/swing/plaf/metal/MetalLabelUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalProgressBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollButton.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTextFieldUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToggleButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java ! src/share/classes/javax/swing/plaf/metal/package.html ! src/share/classes/javax/swing/plaf/multi/MultiLookAndFeel.java ! src/share/classes/javax/swing/plaf/multi/package.html ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/nimbus/package.html ! src/share/classes/javax/swing/plaf/package.html ! src/share/classes/javax/swing/plaf/synth/Region.java ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboPopup.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthFormattedTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthListUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuLayout.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPainter.java ! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToggleButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java ! src/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/share/classes/javax/swing/plaf/synth/package.html ! src/share/classes/javax/swing/table/AbstractTableModel.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/table/TableCellRenderer.java ! src/share/classes/javax/swing/table/TableColumn.java ! src/share/classes/javax/swing/table/TableColumnModel.java ! src/share/classes/javax/swing/table/TableModel.java ! src/share/classes/javax/swing/table/package.html ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/AbstractWriter.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/AttributeSet.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/text/BoxView.java ! src/share/classes/javax/swing/text/Caret.java ! src/share/classes/javax/swing/text/ComponentView.java ! src/share/classes/javax/swing/text/CompositeView.java ! src/share/classes/javax/swing/text/DateFormatter.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultFormatterFactory.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/DocumentFilter.java ! src/share/classes/javax/swing/text/EditorKit.java ! src/share/classes/javax/swing/text/Element.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/FieldView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/GapVector.java ! src/share/classes/javax/swing/text/GlyphPainter2.java ! src/share/classes/javax/swing/text/Highlighter.java ! src/share/classes/javax/swing/text/IconView.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/NavigationFilter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/PasswordView.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/PlainView.java ! src/share/classes/javax/swing/text/Position.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleConstants.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/StyledDocument.java ! src/share/classes/javax/swing/text/StyledEditorKit.java ! src/share/classes/javax/swing/text/TabExpander.java ! src/share/classes/javax/swing/text/TabSet.java ! src/share/classes/javax/swing/text/TabStop.java ! src/share/classes/javax/swing/text/TabableView.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/TextAction.java ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/share/classes/javax/swing/text/html/BlockView.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/CSSParser.java ! src/share/classes/javax/swing/text/html/FormSubmitEvent.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/FrameSetView.java ! src/share/classes/javax/swing/text/html/HTML.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/HTMLFrameHyperlinkEvent.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/ImageView.java ! src/share/classes/javax/swing/text/html/InlineView.java ! src/share/classes/javax/swing/text/html/ObjectView.java ! src/share/classes/javax/swing/text/html/Option.java ! src/share/classes/javax/swing/text/html/OptionComboBoxModel.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/TableView.java ! src/share/classes/javax/swing/text/html/package.html ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/DocumentParser.java ! src/share/classes/javax/swing/text/html/parser/Element.java ! src/share/classes/javax/swing/text/html/parser/package.html ! src/share/classes/javax/swing/text/package.html ! src/share/classes/javax/swing/text/rtf/RTFReader.java ! src/share/classes/javax/swing/text/rtf/package.html ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/share/classes/javax/swing/tree/ExpandVetoException.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/TreeCellRenderer.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/tree/TreeNode.java ! src/share/classes/javax/swing/tree/TreePath.java ! src/share/classes/javax/swing/tree/TreeSelectionModel.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/swing/tree/package.html ! src/share/classes/javax/swing/undo/CannotRedoException.java ! src/share/classes/javax/swing/undo/CannotUndoException.java ! src/share/classes/javax/swing/undo/UndoManager.java ! src/share/classes/javax/swing/undo/package.html ! src/share/classes/javax/xml/crypto/KeySelector.java ! src/share/classes/javax/xml/crypto/MarshalException.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java ! src/share/classes/javax/xml/crypto/dsig/TransformException.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureException.java ! src/share/classes/jdk/internal/org/xml/sax/Attributes.java ! src/share/classes/jdk/internal/org/xml/sax/ContentHandler.java ! src/share/classes/jdk/internal/org/xml/sax/DTDHandler.java ! src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java ! src/share/classes/jdk/internal/org/xml/sax/ErrorHandler.java ! src/share/classes/jdk/internal/org/xml/sax/InputSource.java ! src/share/classes/jdk/internal/org/xml/sax/Locator.java ! src/share/classes/jdk/internal/org/xml/sax/SAXException.java ! src/share/classes/jdk/internal/org/xml/sax/SAXNotRecognizedException.java ! src/share/classes/jdk/internal/org/xml/sax/SAXNotSupportedException.java ! src/share/classes/jdk/internal/org/xml/sax/SAXParseException.java ! src/share/classes/jdk/internal/org/xml/sax/XMLReader.java ! src/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java ! src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java ! src/share/classes/jdk/internal/util/xml/XMLStreamException.java ! src/share/classes/jdk/internal/util/xml/impl/Parser.java ! src/share/classes/org/ietf/jgss/GSSContext.java ! src/share/classes/org/ietf/jgss/GSSCredential.java ! src/share/classes/org/ietf/jgss/GSSException.java ! src/share/classes/org/ietf/jgss/GSSManager.java ! src/share/classes/org/ietf/jgss/GSSName.java ! src/share/classes/org/ietf/jgss/package.html ! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! src/share/classes/sun/applet/AppletClassLoader.java ! src/share/classes/sun/applet/AppletPanel.java ! src/share/classes/sun/applet/AppletSecurity.java ! src/share/classes/sun/applet/AppletViewer.java ! src/share/classes/sun/applet/Main.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/CausedFocusEvent.java ! src/share/classes/sun/awt/CharsetString.java ! src/share/classes/sun/awt/DebugSettings.java ! src/share/classes/sun/awt/EventListenerAggregate.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/FontDescriptor.java ! src/share/classes/sun/awt/HToolkit.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerProvider.java ! src/share/classes/sun/awt/ModalityEvent.java ! src/share/classes/sun/awt/NativeLibLoader.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/share/classes/sun/awt/PaintEventDispatcher.java ! src/share/classes/sun/awt/PeerEvent.java ! src/share/classes/sun/awt/ScrollPaneWheelScroller.java ! src/share/classes/sun/awt/SunDisplayChanger.java ! src/share/classes/sun/awt/SunGraphicsCallback.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/UngrabEvent.java ! src/share/classes/sun/awt/datatransfer/ClipboardTransferable.java ! src/share/classes/sun/awt/datatransfer/TransferableProxy.java ! src/share/classes/sun/awt/im/CompositionArea.java ! src/share/classes/sun/awt/im/CompositionAreaHandler.java ! src/share/classes/sun/awt/im/ExecutableInputMethodManager.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/awt/im/InputMethodContext.java ! src/share/classes/sun/awt/im/InputMethodJFrame.java ! src/share/classes/sun/awt/im/InputMethodManager.java ! src/share/classes/sun/awt/im/SimpleInputMethodWindow.java ! src/share/classes/sun/awt/image/ByteBandedRaster.java ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/share/classes/sun/awt/image/BytePackedRaster.java ! src/share/classes/sun/awt/image/ImageRepresentation.java ! src/share/classes/sun/awt/image/IntegerComponentRaster.java ! src/share/classes/sun/awt/image/IntegerInterleavedRaster.java ! src/share/classes/sun/awt/image/JPEGImageDecoder.java ! src/share/classes/sun/awt/image/NativeLibLoader.java ! src/share/classes/sun/awt/image/ShortBandedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/share/classes/sun/awt/image/SurfaceManager.java ! src/share/classes/sun/awt/image/VolatileSurfaceManager.java ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/font/CMap.java ! src/share/classes/sun/font/CreatedFontTracker.java ! src/share/classes/sun/font/ExtendedTextSourceLabel.java ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontManagerFactory.java ! src/share/classes/sun/font/FontManagerForSGE.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/classes/sun/font/GlyphList.java ! src/share/classes/sun/font/LayoutPathImpl.java ! src/share/classes/sun/font/StandardGlyphVector.java ! src/share/classes/sun/font/StandardTextSource.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TextLabelFactory.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/invoke/WrapperInstance.java ! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/SurfaceDataProxy.java ! src/share/classes/sun/java2d/cmm/CMSManager.java ! src/share/classes/sun/java2d/cmm/PCMM.java ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/classes/sun/java2d/loops/Blit.java ! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/share/classes/sun/java2d/loops/MaskFill.java ! src/share/classes/sun/java2d/loops/ProcessPath.java ! src/share/classes/sun/java2d/loops/SurfaceType.java ! src/share/classes/sun/java2d/opengl/OGLBufImgOps.java ! src/share/classes/sun/java2d/opengl/OGLDrawImage.java ! src/share/classes/sun/java2d/opengl/OGLPaints.java ! src/share/classes/sun/java2d/opengl/OGLRenderQueue.java ! src/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java ! src/share/classes/sun/java2d/pipe/BufferedMaskFill.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/classes/sun/java2d/pipe/GlyphListPipe.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java ! src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java ! src/share/classes/sun/java2d/pipe/Region.java ! src/share/classes/sun/java2d/pipe/RegionIterator.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java ! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/AgentConfigurationError.java ! src/share/classes/sun/management/BaseOperatingSystemImpl.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/counter/perf/InstrumentationException.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_pt_BR.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/misc/CRC16.java ! src/share/classes/sun/misc/CharacterDecoder.java ! src/share/classes/sun/misc/ClassFileTransformer.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/PerfCounter.java ! src/share/classes/sun/misc/PerformanceLogger.java ! src/share/classes/sun/misc/URLClassPath.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/misc/Version.java.template ! src/share/classes/sun/misc/resources/Messages_de.java ! src/share/classes/sun/misc/resources/Messages_es.java ! src/share/classes/sun/misc/resources/Messages_fr.java ! src/share/classes/sun/misc/resources/Messages_it.java ! src/share/classes/sun/misc/resources/Messages_ja.java ! src/share/classes/sun/misc/resources/Messages_ko.java ! src/share/classes/sun/misc/resources/Messages_pt_BR.java ! src/share/classes/sun/misc/resources/Messages_sv.java ! src/share/classes/sun/misc/resources/Messages_zh_CN.java ! src/share/classes/sun/misc/resources/Messages_zh_TW.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/TelnetOutputStream.java ! src/share/classes/sun/net/ftp/FtpClient.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/classes/sun/net/smtp/SmtpProtocolException.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/http/ChunkedInputStream.java ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/share/classes/sun/net/www/protocol/http/Negotiator.java ! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/NativeDispatcher.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/ThreadPool.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java ! src/share/classes/sun/nio/fs/Util.java ! src/share/classes/sun/print/PSPathGraphics.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/PathGraphics.java ! src/share/classes/sun/print/PrintJob2D.java ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java ! src/share/classes/sun/reflect/generics/repository/ClassRepository.java ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties ! src/share/classes/sun/rmi/rmic/RMIGenerator.java ! src/share/classes/sun/rmi/rmic/RemoteClass.java ! src/share/classes/sun/rmi/rmic/Util.java ! src/share/classes/sun/rmi/rmic/newrmic/jrmp/StubSkeletonWriter.java ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties ! src/share/classes/sun/rmi/server/Activation.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/classes/sun/rmi/server/resources/rmid_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_es.properties ! src/share/classes/sun/rmi/server/resources/rmid_fr.properties ! src/share/classes/sun/rmi/server/resources/rmid_it.properties ! src/share/classes/sun/rmi/server/resources/rmid_ja.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties ! src/share/classes/sun/rmi/server/resources/rmid_sv.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties ! src/share/classes/sun/rmi/transport/ObjectTable.java ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/WrappedSocket.java ! src/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java ! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/share/classes/sun/security/ec/CurveDB.java ! src/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/ec/NamedCurve.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/jca/GetInstance.java ! src/share/classes/sun/security/jgss/GSSCaller.java ! src/share/classes/sun/security/jgss/GSSManagerImpl.java ! src/share/classes/sun/security/jgss/HttpCaller.java ! src/share/classes/sun/security/jgss/LoginConfigImpl.java ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/krb5/MessageToken.java ! src/share/classes/sun/security/jgss/krb5/ServiceCreds.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! src/share/classes/sun/security/jgss/wrapper/GSSCredElement.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptedData.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/KrbApRep.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/Krb5.java ! src/share/classes/sun/security/krb5/internal/NetClient.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/DesCbcEType.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/krb5/internal/rcache/AuthList.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/pkcs10/PKCS10.java ! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! src/share/classes/sun/security/provider/DSA.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/provider/certpath/AdjacencyList.java ! src/share/classes/sun/security/provider/certpath/CertPathHelper.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHCrypt.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/Krb5Proxy.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SessionId.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java ! src/share/classes/sun/security/timestamp/TSRequest.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/jarsigner/Resources.java ! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/tools/policytool/Resources.java ! src/share/classes/sun/security/tools/policytool/Resources_de.java ! src/share/classes/sun/security/tools/policytool/Resources_es.java ! src/share/classes/sun/security/tools/policytool/Resources_fr.java ! src/share/classes/sun/security/tools/policytool/Resources_it.java ! src/share/classes/sun/security/tools/policytool/Resources_ja.java ! src/share/classes/sun/security/tools/policytool/Resources_ko.java ! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/policytool/Resources_sv.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/DerIndefLenConverter.java ! src/share/classes/sun/security/util/ECKeySizeParameterSpec.java ! src/share/classes/sun/security/util/ECUtil.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/share/classes/sun/security/util/Resources.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! src/share/classes/sun/security/x509/URIName.java ! src/share/classes/sun/swing/DefaultLayoutStyle.java ! src/share/classes/sun/swing/FilePane.java ! src/share/classes/sun/swing/PrintingStatus.java ! src/share/classes/sun/swing/SwingAccessor.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java ! src/share/classes/sun/swing/plaf/synth/Paint9Painter.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/swing/text/TextComponentPrintable.java ! src/share/classes/sun/text/bidi/BidiBase.java ! src/share/classes/sun/text/normalizer/ReplaceableUCharacterIterator.java ! src/share/classes/sun/text/normalizer/UCharacter.java ! src/share/classes/sun/text/resources/th/CollationData_th.java ! src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java ! src/share/classes/sun/tools/jar/JarException.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! src/share/classes/sun/tools/jar/resources/jar.properties ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/java/BinaryConstantPool.java ! src/share/classes/sun/tools/java/ClassDeclaration.java ! src/share/classes/sun/tools/java/MemberDefinition.java ! src/share/classes/sun/tools/java/RuntimeConstants.java ! src/share/classes/sun/tools/jconsole/AboutDialog.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/JConsole.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/share/classes/sun/tools/jconsole/SummaryTab.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/inspector/Utils.java ! src/share/classes/sun/tools/jconsole/inspector/XObject.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jps/Jps.java ! src/share/classes/sun/tools/jstack/JStack.java ! src/share/classes/sun/tools/jstat/ColumnFormat.java ! src/share/classes/sun/tools/jstat/RowClosure.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java ! src/share/classes/sun/tools/serialver/SerialVer.java ! src/share/classes/sun/tools/tree/ExprExpression.java ! src/share/classes/sun/tools/tree/FieldExpression.java ! src/share/classes/sun/tracing/ProviderSkeleton.java ! src/share/classes/sun/tracing/dtrace/DTraceProvider.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/locale/LanguageTag.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/ResourceBundleBasedAdapter.java ! src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/logging/LoggingProxy.java ! src/share/classes/sun/util/logging/LoggingSupport.java ! src/share/classes/sun/util/logging/resources/logging.properties ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java ! src/share/demo/applets/MoleculeViewer/XYZApp.java ! src/share/demo/applets/WireFrame/ThreeD.java ! src/share/demo/java2d/J2DBench/build.xml ! src/share/demo/java2d/J2DBench/src/j2dbench/Destinations.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Group.java ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Modifier.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Node.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ResultSet.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Test.java ! src/share/demo/java2d/J2DBench/src/j2dbench/TestEnvironment.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/HTMLSeriesReporter.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/IIOComparator.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/XMLHTMLReporter.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/MiscTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/RenderTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputStreamTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputStreamTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextConstructionTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextMeasureTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextRenderTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ui/CompactLayout.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ui/EnableButton.java ! src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethod.java ! src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/TableExample/TableExample4.java ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_event.c ! src/share/demo/jvmti/hprof/hprof_init.c ! src/share/demo/jvmti/hprof/hprof_md.h ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! src/share/javavm/export/jawt.h ! src/share/lib/calendars.properties ! src/share/native/com/sun/media/sound/DirectAudioDevice.c ! src/share/native/com/sun/media/sound/Platform.c ! src/share/native/com/sun/media/sound/PlatformMidi.h ! src/share/native/com/sun/media/sound/SoundDefs.h ! src/share/native/com/sun/media/sound/Utilities.h ! src/share/native/java/lang/SecurityManager.c ! src/share/native/java/lang/System.c ! src/share/native/java/lang/fdlibm/src/k_rem_pio2.c ! src/share/native/java/lang/java_props.h ! src/share/native/java/net/Inet4Address.c ! src/share/native/java/net/Inet6Address.c ! src/share/native/java/net/InetAddress.c ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h ! src/share/native/sun/awt/debug/debug_assert.h ! src/share/native/sun/awt/debug/debug_mem.c ! src/share/native/sun/awt/debug/debug_trace.h ! src/share/native/sun/awt/debug/debug_util.h ! src/share/native/sun/awt/image/BufImgSurfaceData.c ! src/share/native/sun/awt/image/DataBufferNative.c ! src/share/native/sun/awt/image/awt_ImageRep.c ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h ! src/share/native/sun/awt/image/cvutils/img_dcm.h ! src/share/native/sun/awt/image/cvutils/img_dcm8.h ! src/share/native/sun/awt/image/cvutils/img_globals.c ! src/share/native/sun/awt/image/cvutils/img_replscale.h ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! src/share/native/sun/awt/medialib/mlib_ImageAffine.c ! src/share/native/sun/awt/medialib/mlib_ImageAffine.h ! src/share/native/sun/awt/medialib/mlib_ImageAffineEdge.c ! src/share/native/sun/awt/medialib/mlib_ImageColorTrue2Index.c ! src/share/native/sun/awt/medialib/mlib_ImageConv.h ! src/share/native/sun/awt/medialib/mlib_ImageConvMxN.c ! src/share/native/sun/awt/medialib/mlib_ImageConvMxN_ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_32nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_D64nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_F32nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageCopy_Bit.c ! src/share/native/sun/awt/medialib/mlib_ImageCreate.c ! src/share/native/sun/awt/medialib/mlib_c_ImageConv.h ! src/share/native/sun/awt/medialib/mlib_image.h ! src/share/native/sun/awt/medialib/mlib_sys.c ! src/share/native/sun/awt/medialib/mlib_types.h ! src/share/native/sun/awt/medialib/safe_alloc.h ! src/share/native/sun/awt/splashscreen/java_awt_SplashScreen.c ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c ! src/share/native/sun/awt/splashscreen/splashscreen_impl.h ! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c ! src/share/native/sun/awt/splashscreen/splashscreen_png.c ! src/share/native/sun/font/AccelGlyphCache.c ! src/share/native/sun/font/DrawGlyphList.c ! src/share/native/sun/font/FontInstanceAdapter.cpp ! src/share/native/sun/font/FontInstanceAdapter.h ! src/share/native/sun/font/fontscalerdefs.h ! src/share/native/sun/font/freetypeScaler.c ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/font/sunfontids.h ! src/share/native/sun/java2d/Disposer.c ! src/share/native/sun/java2d/SurfaceData.c ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/loops/AnyByteBinary.h ! src/share/native/sun/java2d/loops/Blit.c ! src/share/native/sun/java2d/loops/BlitBg.c ! src/share/native/sun/java2d/loops/ByteIndexed.h ! src/share/native/sun/java2d/loops/DrawPath.c ! src/share/native/sun/java2d/loops/DrawPolygons.c ! src/share/native/sun/java2d/loops/FillPath.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/loops/IntArgb.h ! src/share/native/sun/java2d/loops/IntArgbBm.h ! src/share/native/sun/java2d/loops/IntArgbPre.h ! src/share/native/sun/java2d/loops/MaskBlit.c ! src/share/native/sun/java2d/loops/MaskFill.c ! src/share/native/sun/java2d/loops/ProcessPath.c ! src/share/native/sun/java2d/loops/ScaledBlit.c ! src/share/native/sun/java2d/loops/TransformHelper.c ! src/share/native/sun/java2d/loops/Ushort4444Argb.h ! src/share/native/sun/java2d/loops/UshortIndexed.h ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c ! src/share/native/sun/java2d/opengl/OGLContext.c ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLFuncs.h ! src/share/native/sun/java2d/opengl/OGLRenderQueue.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.h ! src/share/native/sun/java2d/pipe/BufferedRenderPipe.c ! src/share/native/sun/java2d/pipe/Region.c ! src/share/native/sun/java2d/pipe/ShapeSpanIterator.c ! src/share/native/sun/java2d/pipe/SpanClipRenderer.c ! src/share/native/sun/management/HotSpotDiagnostic.c ! src/share/native/sun/reflect/Reflection.c ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/jgss/wrapper/NativeUtil.c ! src/share/native/sun/security/jgss/wrapper/gssapi.h ! src/share/native/sun/security/krb5/nativeccache.c ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/npt/npt.h ! src/share/npt/utf.c ! src/share/sample/jmx/jmx-scandir/index.html ! src/share/sample/scripting/scriptpad/src/scripts/memory.sh ! src/share/transport/socket/socketTransport.c ! src/share/transport/socket/sysSocket.h ! src/solaris/back/linker_md.c ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/classes/java/net/DefaultInterface.java ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/UnsafeXDisposerRecord.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XChoicePeerListener.java ! src/solaris/classes/sun/awt/X11/XClipboard.java ! src/solaris/classes/sun/awt/X11/XDataTransferer.java ! src/solaris/classes/sun/awt/X11/XDesktopPeer.java ! src/solaris/classes/sun/awt/X11/XDialogPeer.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XEmbeddingContainer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XInputMethod.java ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XMSelection.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XMenuPeer.java ! src/solaris/classes/sun/awt/X11/XMenuWindow.java ! src/solaris/classes/sun/awt/X11/XPanelPeer.java ! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XRepaintArea.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java ! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java ! src/solaris/classes/sun/awt/X11/XWINProtocol.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11InputMethod.java ! src/solaris/classes/sun/awt/fontconfigs/bsd.fontconfig.properties ! src/solaris/classes/sun/awt/motif/X11JIS0201.java ! src/solaris/classes/sun/awt/motif/X11JIS0208.java ! src/solaris/classes/sun/awt/motif/X11JIS0212.java ! src/solaris/classes/sun/font/DelegateStrike.java ! src/solaris/classes/sun/font/FontConfigManager.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/classes/sun/font/XMap.java ! src/solaris/classes/sun/font/XRGlyphCacheEntry.java ! src/solaris/classes/sun/font/XRTextRenderer.java ! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java ! src/solaris/classes/sun/java2d/jules/TileTrapContainer.java ! src/solaris/classes/sun/java2d/x11/X11Renderer.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/classes/sun/java2d/xr/GrowableRectArray.java ! src/solaris/classes/sun/java2d/xr/MaskTile.java ! src/solaris/classes/sun/java2d/xr/MaskTileManager.java ! src/solaris/classes/sun/java2d/xr/XRBackend.java ! src/solaris/classes/sun/java2d/xr/XRBackendNative.java ! src/solaris/classes/sun/java2d/xr/XRColor.java ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java ! src/solaris/classes/sun/java2d/xr/XRDrawImage.java ! src/solaris/classes/sun/java2d/xr/XRMaskBlit.java ! src/solaris/classes/sun/java2d/xr/XRMaskImage.java ! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java ! src/solaris/classes/sun/java2d/xr/XRPaints.java ! src/solaris/classes/sun/java2d/xr/XRRenderer.java ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java ! src/solaris/classes/sun/java2d/xr/XRUtils.java ! src/solaris/classes/sun/management/OperatingSystemImpl.java ! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EventPortWrapper.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/KQueue.java ! src/solaris/classes/sun/nio/ch/KQueuePort.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixException.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixMountEntry.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixUriUtils.java ! src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java ! src/solaris/classes/sun/print/AttributeClass.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintJob.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/javavm/export/jni_md.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_CommonUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_CommonUtils.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiIn.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiOut.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiUtils.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCMUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCMUtils.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_Ports.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h ! src/solaris/native/com/sun/security/auth/module/Solaris.c ! src/solaris/native/com/sun/security/auth/module/Unix.c ! src/solaris/native/java/lang/ProcessEnvironment_md.c ! src/solaris/native/java/lang/UNIXProcess_md.c ! src/solaris/native/java/lang/java_props_macosx.c ! src/solaris/native/java/lang/java_props_macosx.h ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/linux_close.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/sun/awt/CUPSfuncs.c ! src/solaris/native/sun/awt/VDrawingArea.c ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt.h ! src/solaris/native/sun/awt/awt_AWTEvent.c ! src/solaris/native/sun/awt/awt_Component.h ! src/solaris/native/sun/awt/awt_Font.c ! src/solaris/native/sun/awt/awt_Font.h ! src/solaris/native/sun/awt/awt_LoadLibrary.c ! src/solaris/native/sun/awt/awt_Mlib.c ! src/solaris/native/sun/awt/awt_Mlib.h ! src/solaris/native/sun/awt/awt_Robot.c ! src/solaris/native/sun/awt/awt_UNIXToolkit.c ! src/solaris/native/sun/awt/awt_p.h ! src/solaris/native/sun/awt/canvas.h ! src/solaris/native/sun/awt/fontpath.c ! src/solaris/native/sun/awt/initIDs.c ! src/solaris/native/sun/awt/jawt.c ! src/solaris/native/sun/awt/multiVis.c ! src/solaris/native/sun/awt/multi_font.c ! src/solaris/native/sun/awt/multi_font.h ! src/solaris/native/sun/awt/robot_common.c ! src/solaris/native/sun/awt/splashscreen/splashscreen_config.h ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c ! src/solaris/native/sun/awt/swing_GTKEngine.c ! src/solaris/native/sun/font/X11FontScaler.c ! src/solaris/native/sun/font/X11TextRenderer.c ! src/solaris/native/sun/java2d/j2d_md.h ! src/solaris/native/sun/java2d/loops/mlib_ImageZoom_NN.c ! src/solaris/native/sun/java2d/loops/vis_FuncArray.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.h ! src/solaris/native/sun/java2d/opengl/OGLFuncs_md.h ! src/solaris/native/sun/java2d/x11/X11Renderer.c ! src/solaris/native/sun/java2d/x11/XRBackendNative.c ! src/solaris/native/sun/java2d/x11/XRSurfaceData.c ! src/solaris/native/sun/management/LinuxOperatingSystem.c ! src/solaris/native/sun/management/MacosxOperatingSystem.c ! src/solaris/native/sun/management/OperatingSystemImpl.c ! src/solaris/native/sun/management/SolarisOperatingSystem.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/solaris/native/sun/xawt/XToolkit.c ! src/solaris/native/sun/xawt/XWindow.c ! src/solaris/transport/socket/socket_md.c ! src/windows/back/linker_md.c ! src/windows/classes/com/sun/tools/jdi/SharedMemoryAttachingConnector.java ! src/windows/classes/com/sun/tools/jdi/SharedMemoryListeningConnector.java ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/windows/classes/java/net/DefaultInterface.java ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/classes/java/net/DualStackPlainSocketImpl.java ! src/windows/classes/java/net/PlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/windows/classes/sun/awt/windows/WBufferStrategy.java ! src/windows/classes/sun/awt/windows/WCanvasPeer.java ! src/windows/classes/sun/awt/windows/WClipboard.java ! src/windows/classes/sun/awt/windows/WDataTransferer.java ! src/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/windows/classes/sun/awt/windows/WDialogPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/classes/sun/awt/windows/WKeyboardFocusManagerPeer.java ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/classes/sun/awt/windows/WMouseDragGestureRecognizer.java ! src/windows/classes/sun/awt/windows/WPageDialog.java ! src/windows/classes/sun/awt/windows/WPageDialogPeer.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/awt/windows/WPopupMenuPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialog.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/fontconfig.properties ! src/windows/classes/sun/java2d/ScreenUpdateManager.java ! src/windows/classes/sun/java2d/d3d/D3DRenderer.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java ! src/windows/classes/sun/java2d/windows/GDIRenderer.java ! src/windows/classes/sun/management/OperatingSystemImpl.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/windows/classes/sun/nio/ch/DatagramDispatcher.java ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/windows/classes/sun/nio/ch/FileKey.java ! src/windows/classes/sun/nio/ch/Iocp.java ! src/windows/classes/sun/nio/ch/PipeImpl.java ! src/windows/classes/sun/nio/ch/PollArrayWrapper.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/fs/WindowsConstants.java ! src/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/classes/sun/nio/fs/WindowsSecurity.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! src/windows/classes/sun/print/Win32MediaTray.java ! src/windows/classes/sun/print/Win32PrintJob.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/windows/demo/jvmti/hprof/hprof_md.c ! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiIn.cpp ! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiOut.c ! src/windows/native/java/io/Console_md.c ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/DualStackPlainSocketImpl.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h ! src/windows/native/java/net/SocketInputStream.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/icmp.h ! src/windows/native/java/net/net_util_md.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/sun/awt/splashscreen/splashscreen_sys.c ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/font/lcdglyph.c ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h ! src/windows/native/sun/java2d/d3d/D3DPipeline.h ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/management/OperatingSystemImpl.c ! src/windows/native/sun/net/dns/ResolverConfigurationImpl.c ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c ! src/windows/native/sun/security/krb5/NativeCreds.c ! src/windows/native/sun/windows/CmdIDList.cpp ! src/windows/native/sun/windows/Devices.cpp ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/DllUtil.cpp ! src/windows/native/sun/windows/DllUtil.h ! src/windows/native/sun/windows/ObjectList.cpp ! src/windows/native/sun/windows/ObjectList.h ! src/windows/native/sun/windows/ShellFolder2.cpp ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/alloc.h ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_Button.cpp ! src/windows/native/sun/windows/awt_Checkbox.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h ! src/windows/native/sun/windows/awt_Clipboard.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_Debug.cpp ! src/windows/native/sun/windows/awt_Debug.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.h ! src/windows/native/sun/windows/awt_DnDDT.cpp ! src/windows/native/sun/windows/awt_Font.h ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_List.h ! src/windows/native/sun/windows/awt_Menu.cpp ! src/windows/native/sun/windows/awt_Menu.h ! src/windows/native/sun/windows/awt_MenuBar.cpp ! src/windows/native/sun/windows/awt_MenuBar.h ! src/windows/native/sun/windows/awt_MenuItem.cpp ! src/windows/native/sun/windows/awt_MenuItem.h ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_Mlib.h ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Object.h ! src/windows/native/sun/windows/awt_PopupMenu.cpp ! src/windows/native/sun/windows/awt_PopupMenu.h ! src/windows/native/sun/windows/awt_PrintControl.h ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Robot.h ! src/windows/native/sun/windows/awt_ScrollPane.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_TextField.cpp ! src/windows/native/sun/windows/awt_TextField.h ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Window.h ! src/windows/native/sun/windows/awt_ole.cpp ! src/windows/native/sun/windows/awtmsg.h ! src/windows/native/sun/windows/stdhdrs.h ! src/windows/transport/socket/socket_md.c ! test/com/oracle/net/sanity.sh ! test/com/sun/jdi/ExceptionEvents.java ! test/com/sun/jdi/FilterNoMatch.java ! test/com/sun/jdi/JDIScaffold.java ! test/com/sun/jdi/MethodEntryExitEvents.java ! test/com/sun/jdi/MethodExitReturnValuesTest.java ! test/com/sun/jdi/NativeInstanceFilter.java ! test/com/sun/jdi/NoLaunchOptionTest.java ! test/com/sun/jdi/RepStep.java ! test/com/sun/jdi/TestScaffold.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java ! test/com/sun/jndi/cosnaming/CNNameParser.java ! test/com/sun/jndi/cosnaming/IiopUrlIPv6.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/com/sun/net/httpserver/Test9a.java ! test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java ! test/com/sun/tools/attach/Application.java ! test/com/sun/tools/attach/RedefineAgent.java ! test/com/sun/tools/extcheck/TestExtcheckArgs.sh ! test/demo/jvmti/mtrace/TraceJFrame.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh ! test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java ! test/java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.html ! test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java ! test/java/awt/Choice/NonFocusablePopupMenuTest/NonFocusablePopupMenuTest.html ! test/java/awt/Component/F10TopToplevel/F10TopToplevel.html ! test/java/awt/Component/UpdatingBootTime/UpdatingBootTime.html ! test/java/awt/Container/ValidateRoot/InvalidateMustRespectValidateRoots.java ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html ! test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java ! test/java/awt/FileDialog/FileDialogReturnTest/FileDialogReturnTest.html ! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.html ! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.java ! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html ! test/java/awt/FileDialog/MultipleMode/MultipleMode.html ! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.html ! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.java ! test/java/awt/Focus/6981400/Test1.java ! test/java/awt/Focus/6981400/Test2.java ! test/java/awt/Focus/6981400/Test3.java ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java ! test/java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.html ! test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java ! test/java/awt/Focus/ModalBlockedStealsFocusTest/ModalBlockedStealsFocusTest.html ! test/java/awt/Focus/ToFrontFocusTest/ToFrontFocus.html ! test/java/awt/Focus/TypeAhead/TestFocusFreeze.java ! test/java/awt/Focus/WindowInitialFocusTest/WindowInitialFocusTest.html ! test/java/awt/FontMetrics/StyledSpaceAdvance.java ! test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java ! test/java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html ! test/java/awt/Frame/ShownOnPack/ShownOnPack.html ! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java ! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java ! test/java/awt/Graphics/LineClipTest.java ! test/java/awt/Graphics2D/DrawString/XRenderElt254TextTest.java ! test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java ! test/java/awt/GraphicsDevice/CloneConfigsTest.java ! test/java/awt/JAWT/Makefile.cygwin ! test/java/awt/JAWT/Makefile.unix ! test/java/awt/JAWT/Makefile.win ! test/java/awt/JAWT/MyCanvas.java ! test/java/awt/JAWT/myfile.c ! test/java/awt/JAWT/myfile.cpp ! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java ! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java ! test/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.java ! test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html ! test/java/awt/List/SetFontTest/SetFontTest.html ! test/java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java ! test/java/awt/Menu/OpensWithNoGrab/OpensWithNoGrab.java ! test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java ! test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java ! test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java ! test/java/awt/Mouse/ExtraMouseClick/ExtraMouseClick.html ! test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java ! test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java ! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java ! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java ! test/java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html ! test/java/awt/Multiscreen/TranslucencyThrowsExceptionWhenFullScreen/TranslucencyThrowsExceptionWhenFullScreen.java ! test/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.html ! test/java/awt/PrintJob/Text/stringwidth.sh ! test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java ! test/java/awt/Robot/ManualInstructions/ManualInstructions.java ! test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java ! test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java ! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java ! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java ! test/java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest.html ! test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java ! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html ! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.html ! test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java ! test/java/awt/Toolkit/Headless/ExceptionContract/ExceptionContract.java ! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJob.java ! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJobHeadless.java ! test/java/awt/Toolkit/SecurityTest/SecurityTest2.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java ! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java ! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java ! test/java/awt/Window/Grab/GrabTest.java ! test/java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java ! test/java/awt/Window/TranslucentShapedFrameTest/TSFrame.java ! test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.html ! test/java/awt/dnd/Button2DragTest/Button2DragTest.html ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.html ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDTarget.java ! test/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.html ! test/java/awt/dnd/ImageDecoratedDnD/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnD/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.html ! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.java ! test/java/awt/dnd/ImageDecoratedDnD/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnD/MyCursor.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.html ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/MyCursor.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.html ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/MyCursor.java ! test/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.html ! test/java/awt/dnd/URIListToFileListBetweenJVMsTest/InterprocessMessages.java ! test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java ! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.html ! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java ! test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java ! test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java ! test/java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html ! test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.html ! test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java ! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java ! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java ! test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java ! test/java/awt/event/MouseEvent/FrameMouseEventAbsoluteCoordsTest/FrameMouseEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/MouseClickTest/MouseClickTest.html ! test/java/awt/event/MouseEvent/MouseWheelEventAbsoluteCoordsTest/MouseWheelEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/RobotLWTest/RobotLWTest.html ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.html ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.html ! test/java/awt/event/OtherEvents/UngrabID/UngrabID.java ! test/java/awt/im/4490692/bug4490692.html ! test/java/awt/im/4959409/bug4959409.html ! test/java/awt/im/JTextFieldTest.html ! test/java/awt/image/BufferedImage/TinyScale.java ! test/java/awt/image/GetSamplesTest.java ! test/java/awt/image/IncorrectSampleMaskTest.java ! test/java/awt/image/mlib/MlibOpsTest.java ! test/java/awt/print/PageFormat/PageFormatFromAttributes.java ! test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java ! test/java/awt/print/PrinterJob/Collate2DPrintingTest.java ! test/java/awt/print/PrinterJob/PrintGlyphVectorTest.java ! test/java/awt/regtesthelpers/Util.java ! test/java/beans/Beans/6669869/TestDesignTime.java ! test/java/beans/Beans/6669869/TestGuiAvailable.java ! test/java/beans/EventHandler/Test6277266.java ! test/java/beans/Introspector/6380849/TestBeanInfo.java ! test/java/beans/Introspector/6380849/beans/FirstBean.java ! test/java/beans/Introspector/6380849/beans/FirstBeanBeanInfo.java ! test/java/beans/Introspector/6380849/beans/SecondBean.java ! test/java/beans/Introspector/6380849/beans/ThirdBean.java ! test/java/beans/Introspector/6380849/infos/SecondBeanBeanInfo.java ! test/java/beans/Introspector/6380849/infos/ThirdBeanBeanInfo.java ! test/java/beans/Introspector/6976577/test/Accessor.java ! test/java/beans/Introspector/7122138/pack/Sub.java ! test/java/beans/Introspector/7122138/pack/Super.java ! test/java/beans/Introspector/Test4683761.java ! test/java/beans/Introspector/Test6660539.java ! test/java/beans/Performance/Test7122740.java ! test/java/beans/Performance/Test7184799.java ! test/java/beans/XMLEncoder/6380849/Bean.java ! test/java/beans/XMLEncoder/6380849/BeanPersistenceDelegate.java ! test/java/beans/XMLEncoder/AbstractTest.java ! test/java/beans/XMLEncoder/BeanValidator.java ! test/java/beans/XMLEncoder/Test4631471.java ! test/java/beans/XMLEncoder/Test4679556.java ! test/java/beans/XMLEncoder/java_awt_BorderLayout.java ! test/java/beans/XMLEncoder/javax_swing_DefaultCellEditor.java ! test/java/io/File/GetXSpace.sh ! test/java/io/FileInputStream/OpsAfterClose.java ! test/java/io/FileOutputStream/OpsAfterClose.java ! test/java/io/RandomAccessFile/OpsAfterClose.java ! test/java/io/Serializable/class/run.sh ! test/java/io/Serializable/evolution/AddedExternField/run.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/maskSyntheticModifier/run.sh ! test/java/io/Serializable/packageAccess/run.sh ! test/java/io/Serializable/resolveClass/consTest/run.sh ! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java ! test/java/io/Serializable/resolveClass/deserializeButton/Test.java ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh ! test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java ! test/java/io/Serializable/subclass/run.sh ! test/java/io/Serializable/superclassDataLoss/run.sh ! test/java/io/Serializable/unnamedPackageSwitch/run.sh ! test/java/lang/CharSequence/DefaultTest.java ! test/java/lang/Class/forName/NonJavaNames.sh ! test/java/lang/Class/getEnclosingClass/build.sh ! test/java/lang/ClassLoader/Assert.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/ClassLoader/getdotresource.sh ! test/java/lang/Double/ParseDouble.java ! test/java/lang/Float/ParseFloat.java ! test/java/lang/IntegralPrimitiveToString.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/ExactArithTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Tests.java ! test/java/lang/PrimitiveSumMinMaxTest.java ! test/java/lang/String/Split.java ! test/java/lang/String/ToLowerCase.java ! test/java/lang/StringBuffer/BufferForwarding.java ! test/java/lang/StringBuffer/TestSynchronization.java ! test/java/lang/StringBuilder/BuilderForwarding.java ! test/java/lang/StringBuilder/Supplementary.java ! test/java/lang/System/MacEncoding/ExpectedEncoding.java ! test/java/lang/Thread/GenerifyStackTraces.java ! test/java/lang/Thread/ThreadStateTest.java ! test/java/lang/Throwable/LegacyChainedExceptionSerialization.java ! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh ! test/java/lang/instrument/ManifestTest.sh ! test/java/lang/instrument/ParallelTransformerLoader.sh ! test/java/lang/instrument/RedefineClassWithNativeMethod.sh ! test/java/lang/instrument/RedefineMethodAddInvoke.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/java/lang/invoke/lambda/LUtils.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/lang/invoke/lambda/LambdaAccessControlTest.java ! test/java/lang/invoke/remote/RemoteExample.java ! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java ! test/java/lang/management/CompilationMXBean/Basic.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh ! test/java/lang/management/MemoryMXBean/MemoryTest.java ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/RuntimeMXBean/UpTime.java ! test/java/lang/management/ThreadMXBean/LockedMonitors.java ! test/java/lang/management/ThreadMXBean/LockedSynchronizers.java ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/lang/management/ThreadMXBean/MyOwnSynchronizer.java ! test/java/lang/management/ThreadMXBean/SharedSynchronizer.java ! test/java/lang/management/ThreadMXBean/SynchronizationStatistics.java ! test/java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer.java ! test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java ! test/java/lang/ref/ReferenceEnqueuePending.java ! test/java/lang/reflect/Array/ExceedMaxDim.java ! test/java/lang/reflect/Generics/Probe.java ! test/java/lang/reflect/Method/IsDefaultTest.java ! test/java/lang/reflect/Proxy/Basic1.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/math/BigDecimal/CompareToTests.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java ! test/java/math/BigDecimal/IntegralDivisionTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/math/BigInteger/CompareToTests.java ! test/java/math/BigInteger/DivisionOverflow.java ! test/java/math/BigInteger/ExtremeShiftingTests.java ! test/java/net/Authenticator/B4933582.sh ! test/java/net/BindException/Test.java ! test/java/net/CookieHandler/CookieManagerTest.java ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/Inet6Address/serialize/Serialize.java ! test/java/net/InterfaceAddress/NetworkPrefixLength.java ! test/java/net/MulticastSocket/TestInterfaces.java ! test/java/net/NetworkInterface/Equals.java ! test/java/net/NetworkInterface/IndexTest.java ! test/java/net/NetworkInterface/Test.java ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh ! test/java/net/Socket/LingerTest.java ! test/java/net/Socks/SocksProxyVersion.java ! test/java/net/URI/Test.java ! test/java/net/URL/HandlerLoop.java ! test/java/net/URL/Test.java ! test/java/net/URL/URIToURLTest.java ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/net/URLClassLoader/closetest/Common.java ! test/java/net/URLClassLoader/closetest/GetResourceAsStream.java ! test/java/net/URLClassLoader/getresourceasstream/test.sh ! test/java/net/URLConnection/RequestPropertyValues.java ! test/java/net/URLPermission/nstest/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor ! test/java/net/URLPermission/nstest/SimpleNameService.java ! test/java/net/URLPermission/nstest/SimpleNameServiceDescriptor.java ! test/java/net/ipv6tests/B6521014.java ! test/java/net/ipv6tests/BadIPv6Addresses.java ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java ! test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java ! test/java/nio/channels/DatagramChannel/Connect.java ! test/java/nio/channels/DatagramChannel/ConnectedSend.java ! test/java/nio/channels/DatagramChannel/SendToUnresolved.java ! test/java/nio/channels/Pipe/PipeInterrupt.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/SelectorLimit.java ! test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java ! test/java/nio/channels/SocketChannel/ShortWrite.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java ! test/java/nio/file/Files/CheckPermissions.java ! test/java/nio/file/Files/delete_on_close.sh ! test/java/nio/file/Files/walkFileTree/CreateFileTree.java ! test/java/nio/file/Files/walkFileTree/MaxDepth.java ! test/java/nio/file/Files/walkFileTree/SkipSiblings.java ! test/java/nio/file/Files/walkFileTree/TerminateWalk.java ! test/java/nio/file/Files/walkFileTree/find.sh ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java ! test/java/nio/file/attribute/FileTime/Basic.java ! test/java/rmi/MarshalledObject/compare/Compare.java ! test/java/rmi/MarshalledObject/compare/HashCode.java ! test/java/rmi/MarshalledObject/compare/NullReference.java ! test/java/rmi/Naming/DefaultRegistryPort.java ! test/java/rmi/Naming/LookupIPv6.java ! test/java/rmi/RMISecurityManager/checkPackageAccess/CheckPackageAccess.java ! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java ! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java ! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java ! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java ! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java ! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java ! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java ! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java ! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java ! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java ! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java ! test/java/rmi/activation/Activatable/restartService/RestartService.java ! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java ! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java ! test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java ! test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java ! test/java/rmi/activation/CommandEnvironment/NullOptions.java ! test/java/rmi/activation/log/LogTest.java ! test/java/rmi/dgc/VMID/CheckVMID.java ! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java ! test/java/rmi/dgc/dgcImplInsulation/DGCImplInsulation.java ! test/java/rmi/dgc/retryDirtyCalls/RetryDirtyCalls.java ! test/java/rmi/invalidName/InvalidName.java ! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/server/ObjID/randomIDs/RandomIDs.java ! test/java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java ! test/java/rmi/server/RMIClassLoader/delegateToContextLoader/DelegateToContextLoader.java ! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java ! test/java/rmi/server/RMIClassLoader/getClassAnnotation/NullClass.java ! test/java/rmi/server/RMIClassLoader/getClassLoader/GetClassLoader.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java ! test/java/rmi/server/RMIClassLoader/noSecurityManager/NoSecurityManager.java ! test/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java ! test/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Installed.java ! test/java/rmi/server/RMIClassLoader/spi/InvalidProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Property.java ! test/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java ! test/java/rmi/server/RMIClassLoader/useGetURLs/UseGetURLs.java ! test/java/rmi/server/RemoteObject/notExtending/NotExtending.java ! test/java/rmi/server/RemoteObject/verifyRemoteEquals/VerifyRemoteEquals.java ! test/java/rmi/server/UnicastRemoteObject/changeHostName/ChangeHostName.java ! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport2.java ! test/java/rmi/server/Unmarshal/PrimitiveClasses.java ! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshal.java ! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshalOnStopThread.java ! test/java/rmi/server/Unreferenced/marshalledObjectGet/MarshalledObjectGet.java ! test/java/rmi/server/clientStackTrace/ClientStackTrace.java ! test/java/rmi/server/getRemoteClass/GetRemoteClass.java ! test/java/rmi/server/serverStackTrace/ServerStackTrace.java ! test/java/rmi/server/serverStackTrace/SuppressStackTraces.java ! test/java/rmi/transport/acceptLoop/CloseServerSocketOnTermination.java ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java ! test/java/rmi/transport/readTimeout/ReadTimeoutTest.java ! test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java ! test/java/security/Principal/Implies.java ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/security/cert/CertPathBuilder/selfIssued/generate.sh ! test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java ! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java ! test/java/security/cert/CertPathValidator/indirectCRL/generate.sh ! test/java/security/cert/CertPathValidator/nameConstraints/generate.sh ! test/java/security/cert/CertStore/NoLDAP.java ! test/java/security/cert/CertificateFactory/slowstream.sh ! test/java/security/cert/CertificateRevokedException/Basic.java ! test/java/security/cert/pkix/policyChanges/TestPolicy.java ! test/java/text/Bidi/BidiConformance.java ! test/java/text/Format/DecimalFormat/TieRoundingTest.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java ! test/java/time/test/java/util/TestFormatter.java ! test/java/util/Arrays/ParallelSorting.java ! test/java/util/Base64/TestBase64.java ! test/java/util/Base64/TestBase64Golden.java ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/java/util/Calendar/NarrowNamesTest.sh ! test/java/util/Collection/CollectionDefaults.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collection/testlibrary/CollectionAsserts.java ! test/java/util/Collection/testlibrary/CollectionSupplier.java ! test/java/util/Collection/testlibrary/ExtendsAbstractCollection.java ! test/java/util/Collection/testlibrary/ExtendsAbstractList.java ! test/java/util/Collection/testlibrary/ExtendsAbstractSet.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/EmptyIterator.java ! test/java/util/Collections/ReverseOrder.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/Basic.sh ! 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 ! test/java/util/Iterator/IteratorDefaults.java ! test/java/util/LinkedHashMap/Basic.java ! test/java/util/List/ListDefaults.java ! test/java/util/Locale/InternationalBAT.java ! test/java/util/Locale/LocaleEnhanceTest.java ! test/java/util/Locale/LocaleTestFmwk.java ! test/java/util/Locale/tools/EquivMapsGenerator.java ! test/java/util/Map/BasicSerialization.java ! test/java/util/Map/Collisions.java ! test/java/util/Map/EntryComparators.java ! test/java/util/Map/LockStep.java ! test/java/util/NavigableMap/LockStep.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PriorityQueue/RemoveContains.java ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh ! test/java/util/ResourceBundle/ResourceBundleTest.java ! test/java/util/ServiceLoader/basic.sh ! test/java/util/TimeZone/Bug6912560.java ! test/java/util/TimeZone/CLDRDisplayNamesTest.java ! test/java/util/TimeZone/ListTimeZones.java ! test/java/util/TimeZone/OldIDMappingTest.java ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/java/util/TimeZone/TzIDOldMapping.java ! test/java/util/TreeMap/Clone.java ! test/java/util/concurrent/Executors/PrivilegedCallables.java ! test/java/util/concurrent/FutureTask/Throw.java ! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java ! test/java/util/concurrent/atomic/AtomicReferenceTest.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java ! test/java/util/function/BinaryOperator/BasicTest.java ! test/java/util/jar/TestExtra.java ! test/java/util/logging/CheckLockLocationTest.java ! test/java/util/logging/LoggerSupplierAPIsTest.java ! test/java/util/logging/ParentLoggersTest.java ! test/java/util/logging/Reflect.java ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefFirst.java ! test/java/util/prefs/CheckUserPrefLater.java ! test/java/util/prefs/CommentsInXml.java ! test/java/util/prefs/ConflictInFlush.java ! test/java/util/prefs/ExportNode.java ! test/java/util/prefs/ExportSubtree.java ! test/java/util/prefs/RemoveReadOnlyNode.java ! test/java/util/prefs/RemoveUnregedListener.java ! test/java/util/regex/POSIX_Unicode.java ! test/java/util/spi/ResourceBundleControlProvider/providersrc/UserControlProvider.java ! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java ! test/java/util/stream/bootlib/java/util/stream/TestData.java ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/DeserializeMethodTest.java ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/MapTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/NullArgsTestCase.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java ! test/java/util/zip/3GBZipFiles.sh ! test/java/util/zip/LargeZip.java ! test/java/util/zip/StoredCRC.java ! test/java/util/zip/TotalInOut.java ! test/java/util/zip/ZipFile/Assortment.java ! test/java/util/zip/ZipFile/FinalizeZipFile.java ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/imageio/plugins/gif/GIFPassListenerTest.java ! test/javax/imageio/plugins/gif/GifTransparencyTest.java ! test/javax/management/MBeanInfo/SerializationTest1.java ! test/javax/management/modelmbean/LoggingExceptionTest.java ! test/javax/management/monitor/CounterMonitorThresholdTest.java ! test/javax/management/monitor/NullAttributeValueTest.java ! test/javax/management/remote/mandatory/connection/AddressableTest.java ! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java ! test/javax/management/remote/mandatory/connection/CloseableTest.java ! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java ! test/javax/management/remote/mandatory/connection/ConnectionTest.java ! test/javax/management/remote/mandatory/connection/IIOPURLTest.java ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectionIdTest.java ! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java ! test/javax/print/DialogMargins.java ! test/javax/print/StreamPrintingOrientation.java ! test/javax/print/applet/AppletPrintLookup.html ! test/javax/print/attribute/autosense/PrintAutoSenseData.java ! test/javax/rmi/ssl/SocketFactoryTest.java ! test/javax/script/CauseExceptionTest.java ! test/javax/script/ExceptionTest.java ! test/javax/script/GetInterfaceTest.java ! test/javax/script/Helper.java ! test/javax/script/ProviderTest.sh ! test/javax/script/StringWriterPrintTest.java ! test/javax/script/Test5.java ! test/javax/script/Test6.java ! test/javax/script/UnescapedBracketRegExTest.java ! test/javax/script/VersionTest.java ! test/javax/security/auth/kerberos/KerberosTixDateTest.java ! test/javax/sound/midi/File/SMPTESequence.java ! test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java ! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java ! test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java ! test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java ! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java ! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java ! test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java ! test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java ! test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java ! test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetName.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java ! test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java ! test/javax/sound/midi/Gervill/ModelSource/SetTransform.java ! test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java ! test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java ! test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java ! test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java ! test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java ! test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java ! test/javax/sound/midi/Gervill/SoftChannel/Controller.java ! test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java ! test/javax/sound/midi/Gervill/SoftChannel/Mono.java ! test/javax/sound/midi/Gervill/SoftChannel/Mute.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest2.java ! test/javax/sound/midi/Gervill/SoftChannel/Omni.java ! test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java ! test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java ! test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java ! test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java ! test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java ! test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java ! test/javax/sound/midi/Gervill/SoftChannel/Solo.java ! test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java ! test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java ! test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java ! test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java ! test/javax/sound/midi/Gervill/SoftReceiver/Close.java ! test/javax/sound/midi/Gervill/SoftReceiver/GetMidiDevice.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java ! test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java ! test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestPreciseTimestampRendering.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java ! test/javax/sound/midi/Gervill/SoftTuning/GetName.java ! test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java ! test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java ! test/javax/sound/midi/Gervill/SoftTuning/Load1.java ! test/javax/sound/midi/Gervill/SoftTuning/Load2.java ! test/javax/sound/midi/Gervill/SoftTuning/Load4.java ! test/javax/sound/midi/Gervill/SoftTuning/Load5.java ! test/javax/sound/midi/Gervill/SoftTuning/Load6.java ! test/javax/sound/midi/Gervill/SoftTuning/Load7.java ! test/javax/sound/midi/Gervill/SoftTuning/Load8.java ! test/javax/sound/midi/Gervill/SoftTuning/Load9.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java ! test/javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java ! test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java ! test/javax/sound/midi/Sequencer/SequencerImplicitSynthOpen.java ! test/javax/sound/sampled/AudioFormat/Matches_NOT_SPECIFIED.java ! test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java ! test/javax/sound/sampled/Clip/ClipSetPos.java ! test/javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java ! test/javax/sound/sampled/DirectAudio/bug6400879.java ! test/javax/sound/sampled/FileWriter/AlawEncoderSync.java ! test/javax/sound/sampled/FileWriter/WriterCloseInput.java ! test/javax/swing/JCheckBox/4449413/bug4449413.html ! test/javax/swing/JColorChooser/Test4222508.html ! test/javax/swing/JColorChooser/Test4759306.html ! test/javax/swing/JColorChooser/Test4759934.html ! test/javax/swing/JColorChooser/Test4887836.html ! test/javax/swing/JColorChooser/Test6348456.html ! test/javax/swing/JColorChooser/Test6977726.html ! test/javax/swing/JComboBox/7082443/bug7082443.java ! test/javax/swing/JComponent/4337267/bug4337267.java ! test/javax/swing/JComponent/6683775/bug6683775.java ! test/javax/swing/JEditorPane/4492274/test.html ! test/javax/swing/JEditorPane/6917744/test.html ! test/javax/swing/JEditorPane/bug4714674.java ! test/javax/swing/JFileChooser/6570445/bug6570445.java ! test/javax/swing/JFileChooser/6698013/bug6698013.html ! test/javax/swing/JFileChooser/6698013/bug6698013.java ! test/javax/swing/JFileChooser/6798062/bug6798062.html ! test/javax/swing/JInternalFrame/6726866/bug6726866.html ! test/javax/swing/JInternalFrame/6726866/bug6726866.java ! test/javax/swing/JList/6462008/bug6462008.java ! test/javax/swing/JPopupMenu/4966112/bug4966112.java ! test/javax/swing/JPopupMenu/6694823/bug6694823.java ! test/javax/swing/JSlider/4987336/bug4987336.html ! test/javax/swing/JSlider/6524424/bug6524424.html ! test/javax/swing/JSlider/6587742/bug6587742.html ! test/javax/swing/JSlider/6742358/bug6742358.html ! test/javax/swing/JSplitPane/4885629/bug4885629.java ! test/javax/swing/JTabbedPane/4310381/bug4310381.html ! test/javax/swing/JTable/6788484/bug6788484.java ! test/javax/swing/JTable/8005019/bug8005019.java ! test/javax/swing/JTextArea/7049024/bug7049024.java ! test/javax/swing/JTree/4314199/bug4314199.html ! test/javax/swing/JTree/4908142/bug4908142.java ! test/javax/swing/JTree/6263446/bug6263446.java ! test/javax/swing/SpringLayout/4726194/bug4726194.java ! test/javax/swing/SwingUtilities/7170657/bug7170657.java ! test/javax/swing/border/Test4129681.html ! test/javax/swing/border/Test4243289.html ! test/javax/swing/border/Test4247606.html ! test/javax/swing/border/Test4252164.html ! test/javax/swing/border/Test4760089.html ! test/javax/swing/border/Test6910490.html ! test/javax/swing/border/Test7022041.java ! test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java ! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java ! test/javax/swing/text/html/TableView/7030332/bug7030332.html ! test/javax/swing/text/html/parser/Parser/7003777/bug7003777.java ! test/jdk/lambda/ArrayCtorRefTest.java ! test/jdk/lambda/FDTest.java ! test/jdk/lambda/LambdaTranslationCompoundSamTest.java ! test/jdk/lambda/LambdaTranslationInInterface.java ! test/jdk/lambda/LambdaTranslationTest1.java ! test/jdk/lambda/LambdaTranslationTest2.java ! test/jdk/lambda/MethodReferenceTestInnerDefault.java ! test/jdk/lambda/MethodReferenceTestInnerInstance.java ! test/jdk/lambda/MethodReferenceTestInnerVarArgsThis.java ! test/jdk/lambda/MethodReferenceTestInstance.java ! test/jdk/lambda/MethodReferenceTestInstanceMethod.java ! test/jdk/lambda/MethodReferenceTestKinds.java ! test/jdk/lambda/MethodReferenceTestNew.java ! test/jdk/lambda/MethodReferenceTestNewInner.java ! test/jdk/lambda/MethodReferenceTestSuper.java ! test/jdk/lambda/MethodReferenceTestSuperDefault.java ! test/jdk/lambda/MethodReferenceTestTypeConversion.java ! test/jdk/lambda/MethodReferenceTestVarArgs.java ! test/jdk/lambda/MethodReferenceTestVarArgsExt.java ! test/jdk/lambda/MethodReferenceTestVarArgsSuper.java ! test/jdk/lambda/MethodReferenceTestVarArgsSuperDefault.java ! test/jdk/lambda/MethodReferenceTestVarArgsThis.java ! test/jdk/lambda/TestInnerCtorRef.java ! test/jdk/lambda/TestPrivateCtorRef.java ! test/jdk/lambda/separate/AttributeInjector.java ! test/jdk/lambda/separate/ClassFile.java ! test/jdk/lambda/separate/ClassFilePreprocessor.java ! test/jdk/lambda/separate/ClassToInterfaceConverter.java ! test/jdk/lambda/separate/Compiler.java ! test/jdk/lambda/separate/DirectedClassLoader.java ! test/jdk/lambda/separate/SourceModel.java ! test/jdk/lambda/separate/TestHarness.java ! test/jdk/lambda/shapegen/ClassCase.java ! test/jdk/lambda/shapegen/Hierarchy.java ! test/jdk/lambda/shapegen/HierarchyGenerator.java ! test/jdk/lambda/shapegen/Rule.java ! test/jdk/lambda/shapegen/RuleGroup.java ! test/jdk/lambda/shapegen/TTNode.java ! test/jdk/lambda/shapegen/TTParser.java ! test/jdk/lambda/shapegen/TTShape.java ! test/jdk/lambda/vm/DefaultMethodRegressionTests.java ! test/jdk/lambda/vm/InterfaceAccessFlagsTest.java ! test/jdk/lambda/vm/StrictfpDefault.java ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/invoke/util/ValueConversionsTest.java ! test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java ! test/sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java ! test/sun/java2d/cmm/ColorConvertOp/ColConvDCMTest.java ! test/sun/java2d/cmm/ColorConvertOp/ColConvTest.java ! test/sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest.html ! test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java ! test/sun/java2d/cmm/ColorConvertOp/MTColConvTest.java ! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java ! test/sun/java2d/cmm/ProfileOp/SetDataTest.java ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh ! test/sun/jvmstat/testlibrary/JavaProcess.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java ! test/sun/management/jdp/ClientConnection.java ! test/sun/management/jdp/JdpTestUtil.java ! test/sun/management/jdp/JdpTestUtilTest.java ! test/sun/management/jdp/JdpUnitTest.java ! test/sun/management/jdp/PacketTest.java ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java ! test/sun/misc/Cleaner/ExitOnThrow.java ! test/sun/misc/FloatingDecimal/OldFDBigIntForTest.java ! test/sun/misc/JavaLangAccess/NewUnsafeString.java ! test/sun/net/ftp/MarkResetTest.java ! test/sun/net/ftp/MarkResetTest.sh ! test/sun/net/sdp/sanity.sh ! test/sun/net/www/http/HttpClient/ProxyTest.java ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/file/DirPermissionDenied.sh ! test/sun/net/www/protocol/http/B6299712.java ! test/sun/net/www/protocol/http/ProxyTunnelServer.java ! test/sun/net/www/protocol/http/StackTraceTest.java ! test/sun/nio/cs/EUC_TW_OLD.java ! test/sun/nio/cs/TestIBMBugs.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/X11CNS11643.java ! test/sun/nio/cs/X11CNS11643P1.java ! test/sun/nio/cs/X11CNS11643P2.java ! test/sun/nio/cs/X11CNS11643P3.java ! test/sun/rmi/log/ReliableLog/LogAlignmentTest.java ! test/sun/rmi/log/ReliableLog/SnapshotSize.java ! test/sun/rmi/rmic/RMIGenerator/RmicDefault.java ! test/sun/rmi/rmic/minimizeWrapperInstances/run.sh ! test/sun/rmi/rmic/oldjavacRemoved/sunToolsJavacMain.sh ! test/sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java ! test/sun/rmi/server/MarshalOutputStream/marshalForeignStub/MarshalForeignStub.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java ! test/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java ! test/sun/security/krb5/MicroTime.java ! test/sun/security/krb5/ParseCAPaths.java ! test/sun/security/krb5/ServiceCredsCombination.java ! test/sun/security/krb5/auto/AcceptPermissions.java ! test/sun/security/krb5/auto/AcceptorSubKey.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/DiffNameSameKey.java ! test/sun/security/krb5/auto/DupEtypes.java ! test/sun/security/krb5/auto/DynamicKeytab.java ! test/sun/security/krb5/auto/GSSUnbound.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/KeyTabCompat.java ! test/sun/security/krb5/auto/MoreKvno.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/ReplayCacheTest.java ! test/sun/security/krb5/auto/SaslUnbound.java ! test/sun/security/krb5/auto/TwoOrThree.java ! test/sun/security/krb5/auto/UnboundService.java ! test/sun/security/krb5/ccache/EmptyCC.java ! test/sun/security/krb5/config/dns.sh ! test/sun/security/krb5/etype/WeakCrypto.java ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/krb5/tools/ktcheck.sh ! test/sun/security/pkcs11/SecmodTest.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/provider/PolicyFile/Comparator.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/checkusage.sh ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/crl.sh ! test/sun/security/tools/jarsigner/emptymanifest.sh ! test/sun/security/tools/jarsigner/newsize7.sh ! test/sun/security/tools/jarsigner/onlymanifest.sh ! test/sun/security/tools/jarsigner/passtype.sh ! test/sun/security/tools/jarsigner/samename.sh ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/CloseFile.java ! test/sun/security/tools/keytool/DummyProvider.java ! test/sun/security/tools/keytool/ListKeychainStore.sh ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/tools/keytool/UnknownAndUnparseable.java ! test/sun/security/tools/keytool/console.sh ! test/sun/security/tools/keytool/emptysubject.sh ! test/sun/security/tools/keytool/importreadall.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/readjar.sh ! test/sun/security/tools/keytool/selfissued.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/tools/keytool/trystore.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/sun/security/x509/X509CRLImpl/Verify.java ! test/sun/security/x509/X509CertImpl/Verify.java ! test/sun/tools/jps/jps-V_2.sh ! test/sun/tools/jrunscript/CheckEngine.java ! test/sun/util/calendar/zi/BackEnd.java ! test/sun/util/calendar/zi/Checksum.java ! test/sun/util/calendar/zi/DayOfWeek.java ! test/sun/util/calendar/zi/Gen.java ! test/sun/util/calendar/zi/GenDoc.java ! test/sun/util/calendar/zi/Main.java ! test/sun/util/calendar/zi/Mappings.java ! test/sun/util/calendar/zi/Month.java ! test/sun/util/calendar/zi/Rule.java ! test/sun/util/calendar/zi/RuleDay.java ! test/sun/util/calendar/zi/RuleRec.java ! test/sun/util/calendar/zi/Simple.java ! test/sun/util/calendar/zi/TestZoneInfo310.java ! test/sun/util/calendar/zi/Time.java ! test/sun/util/calendar/zi/Timezone.java ! test/sun/util/calendar/zi/TzIDOldMapping.java ! test/sun/util/calendar/zi/Zone.java ! test/sun/util/calendar/zi/ZoneInfoFile.java ! test/sun/util/calendar/zi/ZoneInfoOld.java ! test/sun/util/calendar/zi/ZoneRec.java ! test/sun/util/calendar/zi/Zoneinfo.java ! test/sun/util/calendar/zi/tzdata/gmt ! test/sun/util/calendar/zi/tzdata/jdk11_backward ! test/sun/util/calendar/zi/tzdata_jdk/gmt ! test/sun/util/calendar/zi/tzdata_jdk/jdk11_backward ! test/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward ! test/sun/util/resources/Locale/Bug6275682.java ! test/sun/util/resources/TimeZone/Bug6317929.java ! test/tools/jar/ChangeDir.java ! test/tools/jar/JarEntryTime.java ! test/tools/pack200/NoBeans.java ! test/tools/pack200/Reflect.java Changeset: e1499442453b Author: lana Date: 2013-12-26 22:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e1499442453b Merge ! src/share/classes/javax/swing/text/AbstractDocument.java Changeset: 7e10ee00fe41 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7e10ee00fe41 Added tag jdk8-b122 for changeset e1499442453b ! .hgtags From daniel.fuchs at oracle.com Mon Jan 6 10:40:18 2014 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 06 Jan 2014 18:40:18 +0000 Subject: hg: jdk8/tl/jdk: 8030850: Setting .level=FINEST in logging configuration file doesn't work Message-ID: <20140106184132.99103623E5@hg.openjdk.java.net> Changeset: d77a1c9fd5b8 Author: dfuchs Date: 2013-12-22 11:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d77a1c9fd5b8 8030850: Setting .level=FINEST in logging configuration file doesn't work Summary: setLevel(INFO) was called too early on root logger, causing the value found in configuration file to be later ignored. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/RootLogger/RootLevelInConfigFile.java + test/java/util/logging/RootLogger/rootlogger.properties From david.holmes at oracle.com Mon Jan 6 18:27:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Jan 2014 12:27:12 +1000 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52B82FBC.3080704@oracle.com> References: <52B82FBC.3080704@oracle.com> Message-ID: <52CB6600.4050804@oracle.com> Hi Jaroslav, On 23/12/2013 10:42 PM, Jaroslav Bachorik wrote: > Please, review the following test fix: > > Issue : https://bugs.openjdk.java.net/browse/JDK-8030847 > Webrev: http://cr.openjdk.java.net/~jbachorik/8030847/webrev.00/ > > The root cause of the intermittent failures of this test is the fact > that there is a lot of hidden places in JDK classes when the checked > thread can get BLOCKED - and it will distort the blocked count and the > test will fail. The ones identified in this case were: > > - ThreadMXBean.getThreadInfo() > - System.out.println() > - Phaser.arriveAndAwaitAdvance() > > Whether the thread gets blocked or not depends on many variables and > this makes the failure very intermittent. > > The fix consists of: > - not using ThreadMXBean.getThreadInfo() from within the tested thread > - not using System.out.println() (or any other kind of output) in the > tested thread > - not using Phaser to synchronize the tested thread and the control thread > > The toughest part is to replace Phaser for the synchronization purposes > with a similar construct which would not block the thread when waiting > for the other party. CyclicBarrier didn't work either as probably > wouldn't not any other solution based on java.util.concurrent locks. > > The TwoPartySynchronizer provides the block-free synchronization and is > based on atomics and Thread.wait(). It is not a general purpose > replacement for Phaser or CyclicBarrier but it works very well for > exactly two parties needing progress synchronization and not wanting to > block any of the parties. I see you actually meant Thread.sleep, which does of course block the thread but doesn't put it into the problematic "blocked" state that affects the blocked-count. That said I don't understand why this problem exists given that by definition the use of any of the synchronizers (based on park()) should not affect the blocked count: getBlockedCount(): Returns the total number of times that the thread associated with this ThreadInfo blocked to enter or reenter a monitor. None of CyclicBarrier/Phaser etc are monitors, so the BlockedCount should not be being updated. If it is then that is a spec or implementation bug in itself :( David From staffan.larsen at oracle.com Tue Jan 7 01:43:36 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 7 Jan 2014 10:43:36 +0100 Subject: RFR 8028623: SA: hash codes in SymbolTable mismatching java_lang_String::hash_code for extended characters. In-Reply-To: <52C6F69E.4010107@oracle.com> References: <52C6F69E.4010107@oracle.com> Message-ID: <67C1E9FA-7680-421F-BAD3-292021231C6B@oracle.com> Kevin, The fix looks good. For tests, we are trying to avoid adding new shell-script based tests since they too often cause problems. Would it be possible to rewrite the test in pure Java code? There are some helper routines in test/testlibrary/com/oracle/java/testlibrary/ that could be useful. /Staffan On 3 jan 2014, at 18:42, Kevin Walls wrote: > Hi, > > This problem means you can't use the SA if the target app contains a symbol which uses a non-ascii character. The SA tool will fail with an error, the JVM itself and the SA having calculated different hashes for such Strings. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8028623 > > webrev: > http://cr.openjdk.java.net/~kevinw/8028623/webrev.00/ > > Thanks > Kevin From staffan.larsen at oracle.com Tue Jan 7 02:09:06 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 7 Jan 2014 11:09:06 +0100 Subject: RFR(M): 8028994 com.sun.management.VMOption is missing the ATTACH_ON_DEMAND origin In-Reply-To: <52B20DA1.1000307@oracle.com> References: <11ED9C97-4496-415A-B66B-74CA87C97F72@oracle.com> <52B20DA1.1000307@oracle.com> Message-ID: <345C94FE-5916-466C-8CE9-FAF22D6E1209@oracle.com> I need a Hotspot Reviewer to look at the (very small) hotspot-specific parts of this fix. Thanks, /Staffan On 18 dec 2013, at 22:03, Mandy Chung wrote: > Looks fine to me. com.sun.management is a supported API and this needs a CCC. > > Mandy > > On 12/17/2013 6:09 AM, Staffan Larsen wrote: >> When getting the origin of a VMOption through the mbean, the ATTACH_ON_DEMAND origin is missing. >> >> This required changes both to hotspot and libs. I will push the hotspot changes first (to hs-rt) and later the libs+test changes (to dev). >> >> webrev: http://cr.openjdk.java.net/~sla/8028994/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8028994 >> >> Thanks, >> /Staffan > From roland.westrelin at oracle.com Tue Jan 7 02:39:54 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 7 Jan 2014 11:39:54 +0100 Subject: RFR(L): 8028468: Add inlining information into ciReplay In-Reply-To: <52BE343C.8030500@oracle.com> References: <529E92AB.9060901@oracle.com> <52BE343C.8030500@oracle.com> Message-ID: <5677FA89-F151-4E24-8857-C6A9717E0C3D@oracle.com> > http://cr.openjdk.java.net/~kvn/8028468/webrev/ Should the agent/doc/cireplay.html be updated? Is there another doc on how to use the replay support somewhere (wiki)? ciReplay.cpp typos: // Use pointer because we may need to retirn inline records // Replay Inlinig vmError.cpp typo: // Do not overwite file during replay compile.hpp Shouldn?t _replay_inline_data be private with an accessor? 1183 // Dump inlining replay data to the stream. 1184 void dump_inline_data(outputStream* out); 1185 void* _replay_inline_data; ciReplay.cpp Why was this changed? Why was it there in the first place? 1052 // Make sure we don't run with background compilation 1053 // BackgroundCompilation = false; Existing fields in class CompileReplay that don?t start with _ make the code confusing: char* bufptr; char* buffer; int buffer_length; int buffer_end; int line_no; etc. Maybe it would be worthwhile to fix that as part of this change? Can buffer be a growableArray? If not factor this code and other similar code in a method? 437 if (pos + 1 >= buffer_length) { 438 int newl = buffer_length * 2; 439 char* newb = NEW_RESOURCE_ARRAY(char, newl); 440 memcpy(newb, buffer, pos); 441 buffer = newb; 442 buffer_length = newl; 443 } Same for: 445 // null terminate it, reset the pointer and process the line 446 buffer[pos] = '\0'; 447 buffer_end = pos++; 448 bufptr = buffer; Shouldn?t the fields below be private? 422 ciKlass* _iklass; 423 Method* _imethod; 424 int _entry_bci; 425 int _comp_level; I think ciInlineRecord* find_ciInlineRecord(Method* method, int bci, int inline_depth) should be implemented by calling: static ciInlineRecord* find_ciInlineRecord(GrowableArray* records, Method* method, int bci, int inline_depth) to avoid duplication of code. Roland. From david.holmes at oracle.com Tue Jan 7 03:27:03 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Jan 2014 21:27:03 +1000 Subject: RFR(M): 8028994 com.sun.management.VMOption is missing the ATTACH_ON_DEMAND origin In-Reply-To: <345C94FE-5916-466C-8CE9-FAF22D6E1209@oracle.com> References: <11ED9C97-4496-415A-B66B-74CA87C97F72@oracle.com> <52B20DA1.1000307@oracle.com> <345C94FE-5916-466C-8CE9-FAF22D6E1209@oracle.com> Message-ID: <52CBE487.7070801@oracle.com> On 7/01/2014 8:09 PM, Staffan Larsen wrote: > I need a Hotspot Reviewer to look at the (very small) hotspot-specific parts of this fix. This all looks fine to me. David > Thanks, > /Staffan > > On 18 dec 2013, at 22:03, Mandy Chung wrote: > >> Looks fine to me. com.sun.management is a supported API and this needs a CCC. >> >> Mandy >> >> On 12/17/2013 6:09 AM, Staffan Larsen wrote: >>> When getting the origin of a VMOption through the mbean, the ATTACH_ON_DEMAND origin is missing. >>> >>> This required changes both to hotspot and libs. I will push the hotspot changes first (to hs-rt) and later the libs+test changes (to dev). >>> >>> webrev: http://cr.openjdk.java.net/~sla/8028994/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8028994 >>> >>> Thanks, >>> /Staffan >> > From staffan.larsen at oracle.com Tue Jan 7 03:32:35 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 7 Jan 2014 12:32:35 +0100 Subject: RFR(M): 8028994 com.sun.management.VMOption is missing the ATTACH_ON_DEMAND origin In-Reply-To: <52CBE487.7070801@oracle.com> References: <11ED9C97-4496-415A-B66B-74CA87C97F72@oracle.com> <52B20DA1.1000307@oracle.com> <345C94FE-5916-466C-8CE9-FAF22D6E1209@oracle.com> <52CBE487.7070801@oracle.com> Message-ID: <2D44C12B-6AF9-42E6-BCC4-0820EB9420E1@oracle.com> Thanks David. /Staffan On 7 jan 2014, at 12:27, David Holmes wrote: > On 7/01/2014 8:09 PM, Staffan Larsen wrote: >> I need a Hotspot Reviewer to look at the (very small) hotspot-specific parts of this fix. > > This all looks fine to me. > > David > >> Thanks, >> /Staffan >> >> On 18 dec 2013, at 22:03, Mandy Chung wrote: >> >>> Looks fine to me. com.sun.management is a supported API and this needs a CCC. >>> >>> Mandy >>> >>> On 12/17/2013 6:09 AM, Staffan Larsen wrote: >>>> When getting the origin of a VMOption through the mbean, the ATTACH_ON_DEMAND origin is missing. >>>> >>>> This required changes both to hotspot and libs. I will push the hotspot changes first (to hs-rt) and later the libs+test changes (to dev). >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8028994/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8028994 >>>> >>>> Thanks, >>>> /Staffan >>> >> From staffan.larsen at oracle.com Tue Jan 7 03:47:58 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 7 Jan 2014 12:47:58 +0100 Subject: RFR(M): 8030812 : Change the solaris DTrace implementation to use USDT2 instead of USDT1 In-Reply-To: <52B4B1AC.9030101@oracle.com> References: <29F99613-1784-409C-98A8-21E1F663B046@oracle.com> <52B4B1AC.9030101@oracle.com> Message-ID: <7F8C6A7C-819F-4193-9DBF-96C96D75AC35@oracle.com> On 20 dec 2013, at 22:07, serguei.spitsyn at oracle.com wrote: > Staffan, > > This is nice change and cleanup. > I do not see any issues. Thanks. > The make/bsd/makefiles/dtrace.make shows that the jhelper.d is disabled for bsd > which means that the jstack action is not supported there. > I'm not very familiar with the BSD DTrace implementation and wonder if you know any details. > Does it mean there is no jstack action there, or just more work is needed to make the jhelper.d functional? > Do we have a bug filed on this? Short answer: I don?t know anything about jstack or jhelper.d. /Staffan > > > Thanks, > Serguei > > > On 12/20/13 3:58 AM, Staffan Larsen wrote: >> The DTrace static probe implementation in Hotspot was written with an earlier version of DTrace. With newer versions, DTrace can create a header file from the contents of the .d file that describes the probes. This newer version (called USDT2) has been used on OS X. Because we have had both versions active, the code has ended up looking ugly because of all the extra macros. >> >> This is a first step in cleaning that up by moving the solaris implementation to use USDT2. The remaining step before USDT1 can be removed is to change the Linux system tap implementation to also use USDT2. >> >> What I have changed is: >> - Update the solaris dtrace.make to generate the header files. I have used the same code as on bsd. >> - While I was there, I removed a lot of commented out code from the bsd dtrace.make file. >> - Updated the hotspot.d files on bsd and solaris so that they have the same contents. >> - Fixed some compilation errors in compileBroker.cpp with const char*. >> - May of the USDT2 macro invocations had an extra line break in them. This both looked ugly and confused the solaris compiler, so I removed them. This lead to a _lot_ of changes in jni.cpp - enough changes so that webrev couldn?t handle it, which is why some of the webrev views are broken for this file. >> - >> >> Testing: I have run the vm.dtrace.testlist on both Solaris and OS X. >> >> webrev: http://cr.openjdk.java.net/~sla/8030812/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8030812 >> >> Thanks, >> /Staffan > From roland.westrelin at oracle.com Tue Jan 7 04:49:00 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 7 Jan 2014 13:49:00 +0100 Subject: RFR(L): 8028468: Add inlining information into ciReplay In-Reply-To: <5677FA89-F151-4E24-8857-C6A9717E0C3D@oracle.com> References: <529E92AB.9060901@oracle.com> <52BE343C.8030500@oracle.com> <5677FA89-F151-4E24-8857-C6A9717E0C3D@oracle.com> Message-ID: <72846F80-2993-4EEB-93E1-90BF20E2D3CE@oracle.com> One more question: When can the code below cause an early return from process_compile()? Can that really happen? 493 if (entry_bci != _entry_bci || comp_level != _comp_level) { 494 return; 495 } 496 const char* iklass_name = _imethod->method_holder()->name()->as_utf8(); 497 const char* imethod_name = _imethod->name()->as_utf8(); 498 const char* isignature = _imethod->signature()->as_utf8(); 499 const char* klass_name = method->method_holder()->name()->as_utf8(); 500 const char* method_name = method->name()->as_utf8(); 501 const char* signature = method->signature()->as_utf8(); 502 if (strcmp(iklass_name, klass_name) != 0 || 503 strcmp(imethod_name, method_name) != 0 || 504 strcmp(isignature, signature) != 0) { 505 return; 506 } 507 } Roland. On Jan 7, 2014, at 11:39 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/8028468/webrev/ > > Should the agent/doc/cireplay.html be updated? Is there another doc on how to use the replay support somewhere (wiki)? > > ciReplay.cpp > typos: > // Use pointer because we may need to retirn inline records > > // Replay Inlinig > > vmError.cpp > typo: > // Do not overwite file during replay > > compile.hpp > Shouldn?t _replay_inline_data be private with an accessor? > > 1183 // Dump inlining replay data to the stream. > 1184 void dump_inline_data(outputStream* out); > 1185 void* _replay_inline_data; > > ciReplay.cpp > Why was this changed? Why was it there in the first place? > 1052 // Make sure we don't run with background compilation > 1053 // BackgroundCompilation = false; > > Existing fields in class CompileReplay that don?t start with _ make the code confusing: > > char* bufptr; > char* buffer; > int buffer_length; > int buffer_end; > int line_no; > > etc. Maybe it would be worthwhile to fix that as part of this change? > > Can buffer be a growableArray? If not factor this code and other similar code in a method? > 437 if (pos + 1 >= buffer_length) { > 438 int newl = buffer_length * 2; > 439 char* newb = NEW_RESOURCE_ARRAY(char, newl); > 440 memcpy(newb, buffer, pos); > 441 buffer = newb; > 442 buffer_length = newl; > 443 } > > Same for: > 445 // null terminate it, reset the pointer and process the line > 446 buffer[pos] = '\0'; > 447 buffer_end = pos++; > 448 bufptr = buffer; > > Shouldn?t the fields below be private? > 422 ciKlass* _iklass; > 423 Method* _imethod; > 424 int _entry_bci; > 425 int _comp_level; > > I think > ciInlineRecord* find_ciInlineRecord(Method* method, int bci, int inline_depth) > should be implemented by calling: > static ciInlineRecord* find_ciInlineRecord(GrowableArray* records, Method* method, int bci, int inline_depth) > to avoid duplication of code. > > Roland. From roger.riggs at oracle.com Tue Jan 7 09:29:07 2014 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 07 Jan 2014 17:29:07 +0000 Subject: hg: jdk8/tl/jdk: 8031103: java.time.Duration has wrong Javadoc Comments in toDays() and toHours() Message-ID: <20140107172936.C23DA6242B@hg.openjdk.java.net> Changeset: 1b503dd54b95 Author: rriggs Date: 2014-01-07 11:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b503dd54b95 8031103: java.time.Duration has wrong Javadoc Comments in toDays() and toHours() Summary: Correct specification for Duration.toDays, toHours Reviewed-by: lancea, alanb ! src/share/classes/java/time/Duration.java From serguei.spitsyn at oracle.com Tue Jan 7 10:24:44 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Jan 2014 10:24:44 -0800 Subject: RFR(M): 8030812 : Change the solaris DTrace implementation to use USDT2 instead of USDT1 In-Reply-To: <7F8C6A7C-819F-4193-9DBF-96C96D75AC35@oracle.com> References: <29F99613-1784-409C-98A8-21E1F663B046@oracle.com> <52B4B1AC.9030101@oracle.com> <7F8C6A7C-819F-4193-9DBF-96C96D75AC35@oracle.com> Message-ID: <52CC466C.7090400@oracle.com> On 1/7/14 3:47 AM, Staffan Larsen wrote: > On 20 dec 2013, at 22:07, serguei.spitsyn at oracle.com wrote: > >> Staffan, >> >> This is nice change and cleanup. >> I do not see any issues. > Thanks. > >> The make/bsd/makefiles/dtrace.make shows that the jhelper.d is disabled for bsd >> which means that the jstack action is not supported there. >> I'm not very familiar with the BSD DTrace implementation and wonder if you know any details. >> Does it mean there is no jstack action there, or just more work is needed to make the jhelper.d functional? >> Do we have a bug filed on this? > Short answer: I don?t know anything about jstack or jhelper.d. The jstack action in a d-script prints mixed java+native stack trace. The jhelper.d is a provider from JVM side (as a part of the DTrace support) that helps the DTrace to translate hexa-decimal pc's to Java symbolic method names. The jhelper.d code is linked into the libjvm.so DOF section where DTrace can find it. Thanks, Serguei > > /Staffan > >> >> Thanks, >> Serguei >> >> >> On 12/20/13 3:58 AM, Staffan Larsen wrote: >>> The DTrace static probe implementation in Hotspot was written with an earlier version of DTrace. With newer versions, DTrace can create a header file from the contents of the .d file that describes the probes. This newer version (called USDT2) has been used on OS X. Because we have had both versions active, the code has ended up looking ugly because of all the extra macros. >>> >>> This is a first step in cleaning that up by moving the solaris implementation to use USDT2. The remaining step before USDT1 can be removed is to change the Linux system tap implementation to also use USDT2. >>> >>> What I have changed is: >>> - Update the solaris dtrace.make to generate the header files. I have used the same code as on bsd. >>> - While I was there, I removed a lot of commented out code from the bsd dtrace.make file. >>> - Updated the hotspot.d files on bsd and solaris so that they have the same contents. >>> - Fixed some compilation errors in compileBroker.cpp with const char*. >>> - May of the USDT2 macro invocations had an extra line break in them. This both looked ugly and confused the solaris compiler, so I removed them. This lead to a _lot_ of changes in jni.cpp - enough changes so that webrev couldn?t handle it, which is why some of the webrev views are broken for this file. >>> - >>> >>> Testing: I have run the vm.dtrace.testlist on both Solaris and OS X. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8030812/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8030812 >>> >>> Thanks, >>> /Staffan From Alan.Bateman at oracle.com Tue Jan 7 12:50:34 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Jan 2014 20:50:34 +0000 Subject: JDK 9 RFR of raw type lint fix to java.lang.management In-Reply-To: <52CC63D4.2010104@oracle.com> References: <52CC63D4.2010104@oracle.com> Message-ID: <52CC689A.3070201@oracle.com> On 07/01/2014 20:30, Joe Darcy wrote: > Hello, > > Please review another minor lint fix of a raw type issues in the core > libraries: Looks good. -Alan. From mandy.chung at oracle.com Tue Jan 7 14:25:15 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 07 Jan 2014 14:25:15 -0800 Subject: JDK 9 RFR of raw type lint fix to java.lang.management In-Reply-To: <52CC63D4.2010104@oracle.com> References: <52CC63D4.2010104@oracle.com> Message-ID: <52CC7ECB.1080309@oracle.com> On 1/7/2014 12:30 PM, Joe Darcy wrote: > Hello, > > Please review another minor lint fix of a raw type issues in the core > libraries: Looks good. cc'ing serviceability-dev as java.lang.management is owned by the serviceability team. Mandy From vladimir.kozlov at oracle.com Tue Jan 7 20:02:44 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Jan 2014 20:02:44 -0800 Subject: RFR(L): 8028468: Add inlining information into ciReplay In-Reply-To: <5677FA89-F151-4E24-8857-C6A9717E0C3D@oracle.com> References: <529E92AB.9060901@oracle.com> <52BE343C.8030500@oracle.com> <5677FA89-F151-4E24-8857-C6A9717E0C3D@oracle.com> Message-ID: <52CCCDE4.4010606@oracle.com> Thank you, Roland On 1/7/14 2:39 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/8028468/webrev/ New webrev: http://cr.openjdk.java.net/~kvn/8028468/webrev.01/ > > Should the agent/doc/cireplay.html be updated? Is there another doc on how to use the replay support somewhere (wiki)? cireplay.html describes how to use SA to extract compilation replay data from core files. Nothing changed there with my changes. I don't think we have any wiki for compilation replay. I added all replay command descriptions and examples into ciReplay.hpp. > > ciReplay.cpp > typos: > // Use pointer because we may need to retirn inline records > > // Replay Inlinig > > vmError.cpp > typo: > // Do not overwite file during replay Typos are fixed. > > compile.hpp > Shouldn?t _replay_inline_data be private with an accessor? > > 1183 // Dump inlining replay data to the stream. > 1184 void dump_inline_data(outputStream* out); > 1185 void* _replay_inline_data; Done. > > ciReplay.cpp > Why was this changed? Why was it there in the first place? > 1052 // Make sure we don't run with background compilation > 1053 // BackgroundCompilation = false; I forgot to uncomment it. It is done only when compilation (not inlining) is replayed. It is special case. Such replaying is done by putting compilation task on compile queue immediately after VM initialization. So we should wait (-Xbatch, -XX:-BackgroundCompilation) until it is finished because we don't need to execute java code (there is no program to execute). And after compilation we exit VM: void ciReplay::replay(TRAPS) { int exit_code = replay_impl(THREAD); Threads::destroy_vm(); vm_exit(exit_code); } > > Existing fields in class CompileReplay that don?t start with _ make the code confusing: > > char* bufptr; > char* buffer; > int buffer_length; > int buffer_end; > int line_no; > > etc. Maybe it would be worthwhile to fix that as part of this change? I added '_' to all fields in this file. > > Can buffer be a growableArray? If not factor this code and other similar code in a method? > 437 if (pos + 1 >= buffer_length) { > 438 int newl = buffer_length * 2; > 439 char* newb = NEW_RESOURCE_ARRAY(char, newl); > 440 memcpy(newb, buffer, pos); > 441 buffer = newb; > 442 buffer_length = newl; > 443 } > > Same for: > 445 // null terminate it, reset the pointer and process the line > 446 buffer[pos] = '\0'; > 447 buffer_end = pos++; > 448 bufptr = buffer; Done. That code is moved to new method get_line(). > > Shouldn?t the fields below be private? > 422 ciKlass* _iklass; > 423 Method* _imethod; > 424 int _entry_bci; > 425 int _comp_level; Done. > > I think > ciInlineRecord* find_ciInlineRecord(Method* method, int bci, int inline_depth) > should be implemented by calling: > static ciInlineRecord* find_ciInlineRecord(GrowableArray* records, Method* method, int bci, int inline_depth) > to avoid duplication of code. Done. I also missed _ci_inline_records field initialization so I added it to CompileReplay constructor. Thanks, Vladimir > > Roland. > From vladimir.kozlov at oracle.com Tue Jan 7 20:09:45 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Jan 2014 20:09:45 -0800 Subject: RFR(L): 8028468: Add inlining information into ciReplay In-Reply-To: <72846F80-2993-4EEB-93E1-90BF20E2D3CE@oracle.com> References: <529E92AB.9060901@oracle.com> <52BE343C.8030500@oracle.com> <5677FA89-F151-4E24-8857-C6A9717E0C3D@oracle.com> <72846F80-2993-4EEB-93E1-90BF20E2D3CE@oracle.com> Message-ID: <52CCCF89.1020101@oracle.com> On 1/7/14 4:49 AM, Roland Westrelin wrote: > One more question: > > When can the code below cause an early return from process_compile()? Can that really happen? When replaying inlining it will skip OSR compilation if you dumped inlining for normal compilation before (entry_bci != _entry_bci). And reverse. Dumping inlining from C2 and run application with Tiered. We need to skip C1 compilations (when we have replay inlining in C1) (comp_level != _comp_level). You can specify several DumpInline commands for different methods and one output inline data file so it will contains several lines of inlining data for different methods. We need to find only related data for current compilation. thanks, Vladimir > > 493 if (entry_bci != _entry_bci || comp_level != _comp_level) { > 494 return; > 495 } > 496 const char* iklass_name = _imethod->method_holder()->name()->as_utf8(); > 497 const char* imethod_name = _imethod->name()->as_utf8(); > 498 const char* isignature = _imethod->signature()->as_utf8(); > 499 const char* klass_name = method->method_holder()->name()->as_utf8(); > 500 const char* method_name = method->name()->as_utf8(); > 501 const char* signature = method->signature()->as_utf8(); > 502 if (strcmp(iklass_name, klass_name) != 0 || > 503 strcmp(imethod_name, method_name) != 0 || > 504 strcmp(isignature, signature) != 0) { > 505 return; > 506 } > 507 } > > Roland. > > On Jan 7, 2014, at 11:39 AM, Roland Westrelin wrote: > >>> http://cr.openjdk.java.net/~kvn/8028468/webrev/ >> >> Should the agent/doc/cireplay.html be updated? Is there another doc on how to use the replay support somewhere (wiki)? >> >> ciReplay.cpp >> typos: >> // Use pointer because we may need to retirn inline records >> >> // Replay Inlinig >> >> vmError.cpp >> typo: >> // Do not overwite file during replay >> >> compile.hpp >> Shouldn?t _replay_inline_data be private with an accessor? >> >> 1183 // Dump inlining replay data to the stream. >> 1184 void dump_inline_data(outputStream* out); >> 1185 void* _replay_inline_data; >> >> ciReplay.cpp >> Why was this changed? Why was it there in the first place? >> 1052 // Make sure we don't run with background compilation >> 1053 // BackgroundCompilation = false; >> >> Existing fields in class CompileReplay that don?t start with _ make the code confusing: >> >> char* bufptr; >> char* buffer; >> int buffer_length; >> int buffer_end; >> int line_no; >> >> etc. Maybe it would be worthwhile to fix that as part of this change? >> >> Can buffer be a growableArray? If not factor this code and other similar code in a method? >> 437 if (pos + 1 >= buffer_length) { >> 438 int newl = buffer_length * 2; >> 439 char* newb = NEW_RESOURCE_ARRAY(char, newl); >> 440 memcpy(newb, buffer, pos); >> 441 buffer = newb; >> 442 buffer_length = newl; >> 443 } >> >> Same for: >> 445 // null terminate it, reset the pointer and process the line >> 446 buffer[pos] = '\0'; >> 447 buffer_end = pos++; >> 448 bufptr = buffer; >> >> Shouldn?t the fields below be private? >> 422 ciKlass* _iklass; >> 423 Method* _imethod; >> 424 int _entry_bci; >> 425 int _comp_level; >> >> I think >> ciInlineRecord* find_ciInlineRecord(Method* method, int bci, int inline_depth) >> should be implemented by calling: >> static ciInlineRecord* find_ciInlineRecord(GrowableArray* records, Method* method, int bci, int inline_depth) >> to avoid duplication of code. >> >> Roland. > From jaroslav.bachorik at oracle.com Wed Jan 8 00:40:22 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 08 Jan 2014 09:40:22 +0100 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52CB6600.4050804@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CB6600.4050804@oracle.com> Message-ID: <52CD0EF6.4010801@oracle.com> Hi David, On 7.1.2014 03:27, David Holmes wrote: > Hi Jaroslav, > > On 23/12/2013 10:42 PM, Jaroslav Bachorik wrote: >> Please, review the following test fix: >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8030847 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8030847/webrev.00/ >> >> The root cause of the intermittent failures of this test is the fact >> that there is a lot of hidden places in JDK classes when the checked >> thread can get BLOCKED - and it will distort the blocked count and the >> test will fail. The ones identified in this case were: >> >> - ThreadMXBean.getThreadInfo() >> - System.out.println() >> - Phaser.arriveAndAwaitAdvance() >> >> Whether the thread gets blocked or not depends on many variables and >> this makes the failure very intermittent. >> >> The fix consists of: >> - not using ThreadMXBean.getThreadInfo() from within the tested thread >> - not using System.out.println() (or any other kind of output) in the >> tested thread >> - not using Phaser to synchronize the tested thread and the control >> thread >> >> The toughest part is to replace Phaser for the synchronization purposes >> with a similar construct which would not block the thread when waiting >> for the other party. CyclicBarrier didn't work either as probably >> wouldn't not any other solution based on java.util.concurrent locks. >> >> The TwoPartySynchronizer provides the block-free synchronization and is >> based on atomics and Thread.wait(). It is not a general purpose >> replacement for Phaser or CyclicBarrier but it works very well for >> exactly two parties needing progress synchronization and not wanting to >> block any of the parties. > > I see you actually meant Thread.sleep, which does of course block the Yes, Thread.sleep(). > thread but doesn't put it into the problematic "blocked" state that Exactly - it puts the thread to "sleeping" state. > affects the blocked-count. That said I don't understand why this problem > exists given that by definition the use of any of the synchronizers > (based on park()) should not affect the blocked count: > > getBlockedCount(): Returns the total number of times that the thread > associated with this ThreadInfo blocked to enter or reenter a monitor. > > None of CyclicBarrier/Phaser etc are monitors, so the BlockedCount > should not be being updated. If it is then that is a spec or > implementation bug in itself :( Indeed, it seems so. I've run the test with JFR enabled and one can distinctively see that the test fails when the thread is parked as it puts the thread into the "blocked" state in the end. I've also patched JVM (the attached monitor-contention.patch; applies to the hotspot repository) to report the thread going into "blocked" state and printing the actual stack trace at that moment and it also shows that the thread goes to "blocked" state somewhere from the "park()" code. I am attaching the JFR recordings - one for the failing test and one for the successful test. IMO, it seems that the ThreadInfo was not updated to reflect the introduction of the park()/unpark() methods. In the current state it mistakenly reports parking a thread as blocking but if the implementation is updated to include only blocking on monitor entry (to correspond to the API docs) we will miss the information about the thread being parked (when the thread also does not execute any user code). This would most probably call for the update of ThreadInfo API. -JB- > > David -------------- next part -------------- A non-text attachment was scrubbed... Name: success.jfr Type: application/octet-stream Size: 174532 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140108/a7fd6a77/success-0001.jfr -------------- next part -------------- A non-text attachment was scrubbed... Name: failure.jfr Type: application/octet-stream Size: 183665 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140108/a7fd6a77/failure-0001.jfr -------------- next part -------------- A non-text attachment was scrubbed... Name: monitor-contention.patch Type: text/x-patch Size: 2271 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140108/a7fd6a77/monitor-contention-0001.patch From roland.westrelin at oracle.com Wed Jan 8 00:41:13 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 8 Jan 2014 09:41:13 +0100 Subject: RFR(L): 8028468: Add inlining information into ciReplay In-Reply-To: <52CCCDE4.4010606@oracle.com> References: <529E92AB.9060901@oracle.com> <52BE343C.8030500@oracle.com> <5677FA89-F151-4E24-8857-C6A9717E0C3D@oracle.com> <52CCCDE4.4010606@oracle.com> Message-ID: <8C0BDE83-8DC7-46C6-B4FD-399344BEEF41@oracle.com> Thanks for the new webrev and explanations. ciReplay.hpp 59 // Replay data file replay_pid%p.log is also created when VM crushes when VM crashes That looks good to me. Roland. On Jan 8, 2014, at 5:02 AM, Vladimir Kozlov wrote: > Thank you, Roland > > On 1/7/14 2:39 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~kvn/8028468/webrev/ > > New webrev: > > http://cr.openjdk.java.net/~kvn/8028468/webrev.01/ > >> >> Should the agent/doc/cireplay.html be updated? Is there another doc on how to use the replay support somewhere (wiki)? > > cireplay.html describes how to use SA to extract compilation replay data from core files. Nothing changed there with my changes. > I don't think we have any wiki for compilation replay. > > I added all replay command descriptions and examples into ciReplay.hpp. > >> >> ciReplay.cpp >> typos: >> // Use pointer because we may need to retirn inline records >> >> // Replay Inlinig >> >> vmError.cpp >> typo: >> // Do not overwite file during replay > > Typos are fixed. > >> >> compile.hpp >> Shouldn?t _replay_inline_data be private with an accessor? >> >> 1183 // Dump inlining replay data to the stream. >> 1184 void dump_inline_data(outputStream* out); >> 1185 void* _replay_inline_data; > > Done. > >> >> ciReplay.cpp >> Why was this changed? Why was it there in the first place? >> 1052 // Make sure we don't run with background compilation >> 1053 // BackgroundCompilation = false; > > I forgot to uncomment it. It is done only when compilation (not inlining) is replayed. It is special case. Such replaying is done by putting compilation task on compile queue immediately after VM initialization. So we should wait (-Xbatch, -XX:-BackgroundCompilation) until it is finished because we don't need to execute java code (there is no program to execute). And after compilation we exit VM: > > void ciReplay::replay(TRAPS) { > int exit_code = replay_impl(THREAD); > > Threads::destroy_vm(); > > vm_exit(exit_code); > } > >> >> Existing fields in class CompileReplay that don?t start with _ make the code confusing: >> >> char* bufptr; >> char* buffer; >> int buffer_length; >> int buffer_end; >> int line_no; >> >> etc. Maybe it would be worthwhile to fix that as part of this change? > > I added '_' to all fields in this file. > >> >> Can buffer be a growableArray? If not factor this code and other similar code in a method? >> 437 if (pos + 1 >= buffer_length) { >> 438 int newl = buffer_length * 2; >> 439 char* newb = NEW_RESOURCE_ARRAY(char, newl); >> 440 memcpy(newb, buffer, pos); >> 441 buffer = newb; >> 442 buffer_length = newl; >> 443 } >> >> Same for: >> 445 // null terminate it, reset the pointer and process the line >> 446 buffer[pos] = '\0'; >> 447 buffer_end = pos++; >> 448 bufptr = buffer; > > Done. That code is moved to new method get_line(). > >> >> Shouldn?t the fields below be private? >> 422 ciKlass* _iklass; >> 423 Method* _imethod; >> 424 int _entry_bci; >> 425 int _comp_level; > > Done. > >> >> I think >> ciInlineRecord* find_ciInlineRecord(Method* method, int bci, int inline_depth) >> should be implemented by calling: >> static ciInlineRecord* find_ciInlineRecord(GrowableArray* records, Method* method, int bci, int inline_depth) >> to avoid duplication of code. > > Done. > > I also missed _ci_inline_records field initialization so I added it to CompileReplay constructor. > > Thanks, > Vladimir > >> >> Roland. >> From david.holmes at oracle.com Wed Jan 8 01:26:03 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Jan 2014 19:26:03 +1000 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52CD0EF6.4010801@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CB6600.4050804@oracle.com> <52CD0EF6.4010801@oracle.com> Message-ID: <52CD19AB.1080307@oracle.com> On 8/01/2014 6:40 PM, Jaroslav Bachorik wrote: > Hi David, > > On 7.1.2014 03:27, David Holmes wrote: >> Hi Jaroslav, >> >> On 23/12/2013 10:42 PM, Jaroslav Bachorik wrote: >>> Please, review the following test fix: >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8030847 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030847/webrev.00/ >>> >>> The root cause of the intermittent failures of this test is the fact >>> that there is a lot of hidden places in JDK classes when the checked >>> thread can get BLOCKED - and it will distort the blocked count and the >>> test will fail. The ones identified in this case were: >>> >>> - ThreadMXBean.getThreadInfo() >>> - System.out.println() >>> - Phaser.arriveAndAwaitAdvance() >>> >>> Whether the thread gets blocked or not depends on many variables and >>> this makes the failure very intermittent. >>> >>> The fix consists of: >>> - not using ThreadMXBean.getThreadInfo() from within the tested thread >>> - not using System.out.println() (or any other kind of output) in the >>> tested thread >>> - not using Phaser to synchronize the tested thread and the control >>> thread >>> >>> The toughest part is to replace Phaser for the synchronization purposes >>> with a similar construct which would not block the thread when waiting >>> for the other party. CyclicBarrier didn't work either as probably >>> wouldn't not any other solution based on java.util.concurrent locks. >>> >>> The TwoPartySynchronizer provides the block-free synchronization and is >>> based on atomics and Thread.wait(). It is not a general purpose >>> replacement for Phaser or CyclicBarrier but it works very well for >>> exactly two parties needing progress synchronization and not wanting to >>> block any of the parties. >> >> I see you actually meant Thread.sleep, which does of course block the > > Yes, Thread.sleep(). > >> thread but doesn't put it into the problematic "blocked" state that > > Exactly - it puts the thread to "sleeping" state. > >> affects the blocked-count. That said I don't understand why this problem >> exists given that by definition the use of any of the synchronizers >> (based on park()) should not affect the blocked count: >> >> getBlockedCount(): Returns the total number of times that the thread >> associated with this ThreadInfo blocked to enter or reenter a monitor. >> >> None of CyclicBarrier/Phaser etc are monitors, so the BlockedCount >> should not be being updated. If it is then that is a spec or >> implementation bug in itself :( > > Indeed, it seems so. I've run the test with JFR enabled and one can > distinctively see that the test fails when the thread is parked as it > puts the thread into the "blocked" state in the end. I've also patched > JVM (the attached monitor-contention.patch; applies to the hotspot > repository) to report the thread going into "blocked" state and printing > the actual stack trace at that moment and it also shows that the thread > goes to "blocked" state somewhere from the "park()" code. > > I am attaching the JFR recordings - one for the failing test and one for > the successful test. > > IMO, it seems that the ThreadInfo was not updated to reflect the > introduction of the park()/unpark() methods. In the current state it > mistakenly reports parking a thread as blocking but if the > implementation is updated to include only blocking on monitor entry (to > correspond to the API docs) we will miss the information about the > thread being parked (when the thread also does not execute any user > code). This would most probably call for the update of ThreadInfo API. park() puts you in Thread.State WAITING which is exposed via ThreadInfo.getWaitedCount, so I don't see any issue there. If parking is causing a change to the blocked count then that is a major bug in the underlying MXBean implementation. David ----- > -JB- > >> >> David > From jaroslav.bachorik at oracle.com Wed Jan 8 01:51:05 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 08 Jan 2014 10:51:05 +0100 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52CD19AB.1080307@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CB6600.4050804@oracle.com> <52CD0EF6.4010801@oracle.com> <52CD19AB.1080307@oracle.com> Message-ID: <52CD1F89.6070607@oracle.com> On 8.1.2014 10:26, David Holmes wrote: > On 8/01/2014 6:40 PM, Jaroslav Bachorik wrote: >> Hi David, >> >> On 7.1.2014 03:27, David Holmes wrote: >>> Hi Jaroslav, >>> >>> On 23/12/2013 10:42 PM, Jaroslav Bachorik wrote: >>>> Please, review the following test fix: >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8030847 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030847/webrev.00/ >>>> >>>> The root cause of the intermittent failures of this test is the fact >>>> that there is a lot of hidden places in JDK classes when the checked >>>> thread can get BLOCKED - and it will distort the blocked count and the >>>> test will fail. The ones identified in this case were: >>>> >>>> - ThreadMXBean.getThreadInfo() >>>> - System.out.println() >>>> - Phaser.arriveAndAwaitAdvance() >>>> >>>> Whether the thread gets blocked or not depends on many variables and >>>> this makes the failure very intermittent. >>>> >>>> The fix consists of: >>>> - not using ThreadMXBean.getThreadInfo() from within the tested thread >>>> - not using System.out.println() (or any other kind of output) in the >>>> tested thread >>>> - not using Phaser to synchronize the tested thread and the control >>>> thread >>>> >>>> The toughest part is to replace Phaser for the synchronization purposes >>>> with a similar construct which would not block the thread when waiting >>>> for the other party. CyclicBarrier didn't work either as probably >>>> wouldn't not any other solution based on java.util.concurrent locks. >>>> >>>> The TwoPartySynchronizer provides the block-free synchronization and is >>>> based on atomics and Thread.wait(). It is not a general purpose >>>> replacement for Phaser or CyclicBarrier but it works very well for >>>> exactly two parties needing progress synchronization and not wanting to >>>> block any of the parties. >>> >>> I see you actually meant Thread.sleep, which does of course block the >> >> Yes, Thread.sleep(). >> >>> thread but doesn't put it into the problematic "blocked" state that >> >> Exactly - it puts the thread to "sleeping" state. >> >>> affects the blocked-count. That said I don't understand why this problem >>> exists given that by definition the use of any of the synchronizers >>> (based on park()) should not affect the blocked count: >>> >>> getBlockedCount(): Returns the total number of times that the thread >>> associated with this ThreadInfo blocked to enter or reenter a monitor. >>> >>> None of CyclicBarrier/Phaser etc are monitors, so the BlockedCount >>> should not be being updated. If it is then that is a spec or >>> implementation bug in itself :( >> >> Indeed, it seems so. I've run the test with JFR enabled and one can >> distinctively see that the test fails when the thread is parked as it >> puts the thread into the "blocked" state in the end. I've also patched >> JVM (the attached monitor-contention.patch; applies to the hotspot >> repository) to report the thread going into "blocked" state and printing >> the actual stack trace at that moment and it also shows that the thread >> goes to "blocked" state somewhere from the "park()" code. >> >> I am attaching the JFR recordings - one for the failing test and one for >> the successful test. >> >> IMO, it seems that the ThreadInfo was not updated to reflect the >> introduction of the park()/unpark() methods. In the current state it >> mistakenly reports parking a thread as blocking but if the >> implementation is updated to include only blocking on monitor entry (to >> correspond to the API docs) we will miss the information about the >> thread being parked (when the thread also does not execute any user >> code). This would most probably call for the update of ThreadInfo API. > > park() puts you in Thread.State WAITING which is exposed via > ThreadInfo.getWaitedCount, so I don't see any issue there. If parking is > causing a change to the blocked count then that is a major bug in the > underlying MXBean implementation. Ok, so there must be something else. According the debug output I added to share/vm/services/threadService.hpp in contended_enter_begin(thread) method I can see the thread being blocked here: 1. Might be related to class loading? The code being called at the reported line is "LockSupport.unpark(t)" *** Blocking on object [I ============================================================= [Contended thread] BlockedThread at java.util.concurrent.Phaser.releaseWaiters(Phaser.java:982) at java.util.concurrent.Phaser.arriveAndAwaitAdvance(Phaser.java:705) at threads.ThreadBlockedCount1$BlockedThread.run(ThreadBlockedCount1.java:99) [Blocked count] 1 *** 2. This report is missing information about the lock and the contended thread. I was not able to figure out how to easily print the information if the current thread is not the contended thread *** at java.util.concurrent.Phaser.internalAwaitAdvance(Phaser.java:1067) at java.util.concurrent.Phaser.arriveAndAwaitAdvance(Phaser.java:690) at threads.ThreadBlockedCount1$BlockedThread.run(ThreadBlockedCount1.java:104) - locked <0x00000000d6e108e0> (a java.lang.Object) [Blocked count] 1 *** One of those reports can be seen in the debug output when the test fails. -JB- > > David > ----- > >> -JB- >> >>> >>> David >> From staffan.larsen at oracle.com Wed Jan 8 02:24:27 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 8 Jan 2014 11:24:27 +0100 Subject: RFR(XS): 8030184 Remove unneeded "content_type" declarations from tracetypes.xml In-Reply-To: <10B96F6E-72A4-49CD-B31F-23E4A5009158@oracle.com> References: <10B96F6E-72A4-49CD-B31F-23E4A5009158@oracle.com> Message-ID: <03E2B42C-E178-484D-BA29-30596433EBEE@oracle.com> Can I have a Review of this one, please? /Staffan On 16 dec 2013, at 13:38, Staffan Larsen wrote: > tracetypes.xml has declarations of a couple of content_types that are never used. > > bug: https://bugs.openjdk.java.net/browse/JDK-8030184 > webrev: http://cr.openjdk.java.net/~sla/8030184/webrev.00/ > > Thanks, > /Staffan From jaroslav.bachorik at oracle.com Wed Jan 8 02:47:49 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 08 Jan 2014 11:47:49 +0100 Subject: RFR(XS): 8030184 Remove unneeded "content_type" declarations from tracetypes.xml In-Reply-To: <03E2B42C-E178-484D-BA29-30596433EBEE@oracle.com> References: <10B96F6E-72A4-49CD-B31F-23E4A5009158@oracle.com> <03E2B42C-E178-484D-BA29-30596433EBEE@oracle.com> Message-ID: <52CD2CD5.3090909@oracle.com> Looks good! -JB- On 8.1.2014 11:24, Staffan Larsen wrote: > Can I have a Review of this one, please? > > /Staffan > > On 16 dec 2013, at 13:38, Staffan Larsen wrote: > >> tracetypes.xml has declarations of a couple of content_types that are never used. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8030184 >> webrev: http://cr.openjdk.java.net/~sla/8030184/webrev.00/ >> >> Thanks, >> /Staffan > From david.holmes at oracle.com Wed Jan 8 03:35:32 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Jan 2014 21:35:32 +1000 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52CD1F89.6070607@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CB6600.4050804@oracle.com> <52CD0EF6.4010801@oracle.com> <52CD19AB.1080307@oracle.com> <52CD1F89.6070607@oracle.com> Message-ID: <52CD3804.7000003@oracle.com> On 8/01/2014 7:51 PM, Jaroslav Bachorik wrote: > On 8.1.2014 10:26, David Holmes wrote: >>>> getBlockedCount(): Returns the total number of times that the thread >>>> associated with this ThreadInfo blocked to enter or reenter a monitor. >>>> >>>> None of CyclicBarrier/Phaser etc are monitors, so the BlockedCount >>>> should not be being updated. If it is then that is a spec or >>>> implementation bug in itself :( >>> >>> Indeed, it seems so. I've run the test with JFR enabled and one can >>> distinctively see that the test fails when the thread is parked as it >>> puts the thread into the "blocked" state in the end. I've also patched >>> JVM (the attached monitor-contention.patch; applies to the hotspot >>> repository) to report the thread going into "blocked" state and printing >>> the actual stack trace at that moment and it also shows that the thread >>> goes to "blocked" state somewhere from the "park()" code. >>> >>> I am attaching the JFR recordings - one for the failing test and one for >>> the successful test. >>> >>> IMO, it seems that the ThreadInfo was not updated to reflect the >>> introduction of the park()/unpark() methods. In the current state it >>> mistakenly reports parking a thread as blocking but if the >>> implementation is updated to include only blocking on monitor entry (to >>> correspond to the API docs) we will miss the information about the >>> thread being parked (when the thread also does not execute any user >>> code). This would most probably call for the update of ThreadInfo API. >> >> park() puts you in Thread.State WAITING which is exposed via >> ThreadInfo.getWaitedCount, so I don't see any issue there. If parking is >> causing a change to the blocked count then that is a major bug in the >> underlying MXBean implementation. > > Ok, so there must be something else. According the debug output I added > to share/vm/services/threadService.hpp in contended_enter_begin(thread) > method I can see the thread being blocked here: Was the debug output System.out/err.println? It uses synchronization internally so your debug statements may be the cause of the extra block count updates. David ----- > 1. Might be related to class loading? The code being called at the > reported line is "LockSupport.unpark(t)" > *** > Blocking on object [I > ============================================================= > [Contended thread] BlockedThread > at java.util.concurrent.Phaser.releaseWaiters(Phaser.java:982) > at java.util.concurrent.Phaser.arriveAndAwaitAdvance(Phaser.java:705) > at > threads.ThreadBlockedCount1$BlockedThread.run(ThreadBlockedCount1.java:99) > [Blocked count] 1 > *** > > 2. This report is missing information about the lock and the contended > thread. I was not able to figure out how to easily print the information > if the current thread is not the contended thread > *** > at java.util.concurrent.Phaser.internalAwaitAdvance(Phaser.java:1067) > at java.util.concurrent.Phaser.arriveAndAwaitAdvance(Phaser.java:690) > at > threads.ThreadBlockedCount1$BlockedThread.run(ThreadBlockedCount1.java:104) > - locked <0x00000000d6e108e0> (a java.lang.Object) > [Blocked count] 1 > *** > > > One of those reports can be seen in the debug output when the test fails. > > -JB- > >> >> David >> ----- >> >>> -JB- >>> >>>> >>>> David >>> > From david.holmes at oracle.com Wed Jan 8 03:37:30 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Jan 2014 21:37:30 +1000 Subject: RFR(XS): 8030184 Remove unneeded "content_type" declarations from tracetypes.xml In-Reply-To: <03E2B42C-E178-484D-BA29-30596433EBEE@oracle.com> References: <10B96F6E-72A4-49CD-B31F-23E4A5009158@oracle.com> <03E2B42C-E178-484D-BA29-30596433EBEE@oracle.com> Message-ID: <52CD387A.1070902@oracle.com> Looks fine. I will take your word for it that these are indeed unused :) David On 8/01/2014 8:24 PM, Staffan Larsen wrote: > Can I have a Review of this one, please? > > /Staffan > > On 16 dec 2013, at 13:38, Staffan Larsen wrote: > >> tracetypes.xml has declarations of a couple of content_types that are never used. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8030184 >> webrev: http://cr.openjdk.java.net/~sla/8030184/webrev.00/ >> >> Thanks, >> /Staffan > From jaroslav.bachorik at oracle.com Wed Jan 8 03:39:17 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 08 Jan 2014 12:39:17 +0100 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52CD3804.7000003@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CB6600.4050804@oracle.com> <52CD0EF6.4010801@oracle.com> <52CD19AB.1080307@oracle.com> <52CD1F89.6070607@oracle.com> <52CD3804.7000003@oracle.com> Message-ID: <52CD38E5.5070306@oracle.com> On 8.1.2014 12:35, David Holmes wrote: > On 8/01/2014 7:51 PM, Jaroslav Bachorik wrote: >> On 8.1.2014 10:26, David Holmes wrote: >>>>> getBlockedCount(): Returns the total number of times that the thread >>>>> associated with this ThreadInfo blocked to enter or reenter a monitor. >>>>> >>>>> None of CyclicBarrier/Phaser etc are monitors, so the BlockedCount >>>>> should not be being updated. If it is then that is a spec or >>>>> implementation bug in itself :( >>>> >>>> Indeed, it seems so. I've run the test with JFR enabled and one can >>>> distinctively see that the test fails when the thread is parked as it >>>> puts the thread into the "blocked" state in the end. I've also patched >>>> JVM (the attached monitor-contention.patch; applies to the hotspot >>>> repository) to report the thread going into "blocked" state and >>>> printing >>>> the actual stack trace at that moment and it also shows that the thread >>>> goes to "blocked" state somewhere from the "park()" code. >>>> >>>> I am attaching the JFR recordings - one for the failing test and one >>>> for >>>> the successful test. >>>> >>>> IMO, it seems that the ThreadInfo was not updated to reflect the >>>> introduction of the park()/unpark() methods. In the current state it >>>> mistakenly reports parking a thread as blocking but if the >>>> implementation is updated to include only blocking on monitor entry (to >>>> correspond to the API docs) we will miss the information about the >>>> thread being parked (when the thread also does not execute any user >>>> code). This would most probably call for the update of ThreadInfo API. >>> >>> park() puts you in Thread.State WAITING which is exposed via >>> ThreadInfo.getWaitedCount, so I don't see any issue there. If parking is >>> causing a change to the blocked count then that is a major bug in the >>> underlying MXBean implementation. >> >> Ok, so there must be something else. According the debug output I added >> to share/vm/services/threadService.hpp in contended_enter_begin(thread) >> method I can see the thread being blocked here: > > Was the debug output System.out/err.println? It uses synchronization > internally so your debug statements may be the cause of the extra block > count updates. No. The output comes from inside the VM native code. Using tty->print(). But the contention handler method contended_enter_begin(thrd) enters before any output is generated. I removed all the System.out/err.println() statements from the test code because they were causing much more blocked events. -JB- > > David > ----- > >> 1. Might be related to class loading? The code being called at the >> reported line is "LockSupport.unpark(t)" >> *** >> Blocking on object [I >> ============================================================= >> [Contended thread] BlockedThread >> at java.util.concurrent.Phaser.releaseWaiters(Phaser.java:982) >> at >> java.util.concurrent.Phaser.arriveAndAwaitAdvance(Phaser.java:705) >> at >> threads.ThreadBlockedCount1$BlockedThread.run(ThreadBlockedCount1.java:99) >> >> [Blocked count] 1 >> *** >> >> 2. This report is missing information about the lock and the contended >> thread. I was not able to figure out how to easily print the information >> if the current thread is not the contended thread >> *** >> at java.util.concurrent.Phaser.internalAwaitAdvance(Phaser.java:1067) >> at >> java.util.concurrent.Phaser.arriveAndAwaitAdvance(Phaser.java:690) >> at >> threads.ThreadBlockedCount1$BlockedThread.run(ThreadBlockedCount1.java:104) >> >> - locked <0x00000000d6e108e0> (a java.lang.Object) >> [Blocked count] 1 >> *** >> >> >> One of those reports can be seen in the debug output when the test fails. >> >> -JB- >> >>> >>> David >>> ----- >>> >>>> -JB- >>>> >>>>> >>>>> David >>>> >> From david.holmes at oracle.com Wed Jan 8 03:43:04 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Jan 2014 21:43:04 +1000 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52CD38E5.5070306@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CB6600.4050804@oracle.com> <52CD0EF6.4010801@oracle.com> <52CD19AB.1080307@oracle.com> <52CD1F89.6070607@oracle.com> <52CD3804.7000003@oracle.com> <52CD38E5.5070306@oracle.com> Message-ID: <52CD39C8.1020509@oracle.com> On 8/01/2014 9:39 PM, Jaroslav Bachorik wrote: > On 8.1.2014 12:35, David Holmes wrote: >> On 8/01/2014 7:51 PM, Jaroslav Bachorik wrote: >>> On 8.1.2014 10:26, David Holmes wrote: >>>>>> getBlockedCount(): Returns the total number of times that the thread >>>>>> associated with this ThreadInfo blocked to enter or reenter a >>>>>> monitor. >>>>>> >>>>>> None of CyclicBarrier/Phaser etc are monitors, so the BlockedCount >>>>>> should not be being updated. If it is then that is a spec or >>>>>> implementation bug in itself :( >>>>> >>>>> Indeed, it seems so. I've run the test with JFR enabled and one can >>>>> distinctively see that the test fails when the thread is parked as it >>>>> puts the thread into the "blocked" state in the end. I've also patched >>>>> JVM (the attached monitor-contention.patch; applies to the hotspot >>>>> repository) to report the thread going into "blocked" state and >>>>> printing >>>>> the actual stack trace at that moment and it also shows that the >>>>> thread >>>>> goes to "blocked" state somewhere from the "park()" code. >>>>> >>>>> I am attaching the JFR recordings - one for the failing test and one >>>>> for >>>>> the successful test. >>>>> >>>>> IMO, it seems that the ThreadInfo was not updated to reflect the >>>>> introduction of the park()/unpark() methods. In the current state it >>>>> mistakenly reports parking a thread as blocking but if the >>>>> implementation is updated to include only blocking on monitor entry >>>>> (to >>>>> correspond to the API docs) we will miss the information about the >>>>> thread being parked (when the thread also does not execute any user >>>>> code). This would most probably call for the update of ThreadInfo API. >>>> >>>> park() puts you in Thread.State WAITING which is exposed via >>>> ThreadInfo.getWaitedCount, so I don't see any issue there. If >>>> parking is >>>> causing a change to the blocked count then that is a major bug in the >>>> underlying MXBean implementation. >>> >>> Ok, so there must be something else. According the debug output I added >>> to share/vm/services/threadService.hpp in contended_enter_begin(thread) >>> method I can see the thread being blocked here: >> >> Was the debug output System.out/err.println? It uses synchronization >> internally so your debug statements may be the cause of the extra block >> count updates. > > No. The output comes from inside the VM native code. Using tty->print(). Okay. > But the contention handler method contended_enter_begin(thrd) enters > before any output is generated. It should be easy enough to report the stack whenever the blocked count is updated for a thread. David (signing off for the night) ----- > I removed all the System.out/err.println() statements from the test code > because they were causing much more blocked events. > > -JB- > >> >> David >> ----- >> >>> 1. Might be related to class loading? The code being called at the >>> reported line is "LockSupport.unpark(t)" >>> *** >>> Blocking on object [I >>> ============================================================= >>> [Contended thread] BlockedThread >>> at java.util.concurrent.Phaser.releaseWaiters(Phaser.java:982) >>> at >>> java.util.concurrent.Phaser.arriveAndAwaitAdvance(Phaser.java:705) >>> at >>> threads.ThreadBlockedCount1$BlockedThread.run(ThreadBlockedCount1.java:99) >>> >>> >>> [Blocked count] 1 >>> *** >>> >>> 2. This report is missing information about the lock and the contended >>> thread. I was not able to figure out how to easily print the information >>> if the current thread is not the contended thread >>> *** >>> at java.util.concurrent.Phaser.internalAwaitAdvance(Phaser.java:1067) >>> at >>> java.util.concurrent.Phaser.arriveAndAwaitAdvance(Phaser.java:690) >>> at >>> threads.ThreadBlockedCount1$BlockedThread.run(ThreadBlockedCount1.java:104) >>> >>> >>> - locked <0x00000000d6e108e0> (a java.lang.Object) >>> [Blocked count] 1 >>> *** >>> >>> >>> One of those reports can be seen in the debug output when the test >>> fails. >>> >>> -JB- >>> >>>> >>>> David >>>> ----- >>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>> >>> > From staffan.larsen at oracle.com Wed Jan 8 05:46:01 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 8 Jan 2014 14:46:01 +0100 Subject: Review request for 7195249: Some jtreg tests use hard coded ports In-Reply-To: <52BC2A7D.3070403@oracle.com> References: <529EF58F.5000701@oracle.com> <52A58687.6020708@oracle.com> <52A5953A.5040102@oracle.com> <52A7061E.8040002@oracle.com> <52BC2A7D.3070403@oracle.com> Message-ID: Hi Taras, Thanks for doing this clean up and conversion of tests into Java. Here?s a couple of comments: test/runtime/6294277/SourceDebugExtension.java: This test could be simplified by not specifying an address at all. Since the test never connects to the JVM started with -Xrunjdwp, there is no reason to specify an address. If address is unspecified (and server=y), the connector will pick an address and print it to the command line. Thus the only change that needs to be done is to remove ",address=8888? from the @run command. test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh: test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh: These tests do not compile cleanly with an empty JTwork directory. It seems that having one @build for each class does not work well - when compiling RmiBootstrapTest.java it cannot find TestLogger. Moving all classes to one @build statement solved this problem for me. test/lib/testlibrary/jdk/testlibrary/ProcessTools.java: 187 Future stdoutTask = stdout.process(); 188 Future stderrTask = stderr.process(); The stdoutTask and stderrTask variables are unused. test/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java: At first I thought something was wrong with this file - the diff is very weird. Then I realized you renamed an old file and created a new file using the old name. test/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java: - Is resetPasswordFilePermission() really necessary? It looks like you delete the files at the beginning of the test in any case. - I find the names and usage of ?mgmt? and ?file2PermissionTest? confusing. They are both Paths. One is used directly by the sub-classes, the other has a getter method. - Lines 57-58: Don?t swallow exceptions, add an ex.printStackTrace(). (Same thing for all other places where you call Integer.parseInt()) test/sun/management/jmxremote/bootstrap/Dummy.java: This file is never used as far as I can see. Thanks, /Staffan On 26 dec 2013, at 14:09, taras ledkov wrote: > Hi, > > Please take a look at the review with fixed issues about trying to launch test that needs free port several times. > > Webrev for jdk part: > http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.01/ > > Webrev for hs part: > http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.01/ > > Pay your attention to new method ProcessTools.startProcess(String, ProcessBuilder, Consumer) that is used to analyze all output of a sub-process. It has common part with > ProcessTools.startProcess(String, ProcessBuilder, Predicate, long, TumeUnit) that is used to determine the warm-up moment. > > I think the ProcessTools.startProcess(String, ProcessBuilder, Predicate, long, TumeUnit) may be changed by adding LinePump to stderr if there is not serious reason for restricting the warm-up analysis to stdout stream. > > On 10.12.2013 16:16, Yekaterina Kantserova wrote: >> Hi, >> >> I've consulted with Serviceability engineers (add them to CC list) and >> they would like to see tests to solve these problem so far: >> >> 2. Implement loops in every test. >> >> Thanks, >> Katja >> >> >> On 12/09/2013 11:02 AM, Alexandre (Shura) Iline wrote: >>> Guys. >>> >>> Let me try to sum up what was said before and may be suggest a >>> compromise. >>> >>> 1. There is a desire to have a support port allocation on the level of >>> a JTReg suite execution. Taras created a bug for that >>> (https://bugs.openjdk.java.net/browse/JDK-7195249). Whether it is a >>> test harness API or a library API does not really matter from usage >>> point of view. >>> >>> 2. There is no way to make the tests absolutely stable, whatever port >>> allocation logic is used. The best we could do is to try to perform >>> the test logic with different ports until the test succeeds. >>> >>> Both arguments make sense. #2 is the ultimate answer, of course, but >>> better be used in conjunction with a meaningful port selection algorithm. >>> >>> At the same time, copying a loop-until-success login from one test to >>> another may be not the best solution. Library could help with that I >>> believe. There only need to be an API method which takes behavior as a >>> parameter and run it until it succeeds. Something like: >>> public runOnAFreePort(Function) >>> or similar. There could be arguments of how/whether to implement it, >>> the solution would not work for shell tests, etc, but still ... >>> >>> >>> With the tests in question though, we have a few options. >>> >>> 1. Integrate tests as is. Get to it later after reaching agreement in >>> the library, etc. >>> 2. Implement loops in every test. >>> 3. Wait for the library to be ready and only then integrate the changes. >>> >>> Please let us know which one is closer to your heart. >>> >>> I personally prefer #1 for the reason that the changes already >>> supposed to make the tests more stable and also there are many more >>> tests tests which use ports, so the scope of the problem is bigger >>> than these. >>> >>> Shura >>> >>> >>>> Taras, >>>> >>>> I agree with the previous comments, that Utils.getFreePort() does not >>>> guarantee the port will be still free when you start your process. >>>> Unfortunately I don't think the library can do more. However, there is a >>>> solution. >>>> >>>> Please, look at the *jdk/test/sun/tools/jstatd/JstatdTest.java >>>> tryToSetupJstatdProcess()*. In brief, the test will try to start a >>>> process with a free port and then check if >>>> /java.rmi.server.ExportException: Port already in use/ has been thrown. >>>> If yes, you have to retry. >>>> >>>> Thanks, >>>> Katja >>>> >>>> >>>> >>>> On 12/02/2013 01:39 PM, taras ledkov wrote: >>>>> Hi Everyone, >>>>> >>>>> Whatever logic is to be chosen to select a free port, it is the >>>>> library responsibility to implements it, would not you agree? >>>>> >>>>> Hence what I am suggesting is to integrate the tests as is. >>>>> >>>>> Should we decide to replace logic of the port selection, we could do >>>>> it later in the library. >>>>> >>>>> On 21.11.2013 15:00, Jaroslav Bachorik wrote: >>>>>> On 20.11.2013 18:38, Dmitry Samersoff wrote: >>>>>>> Roger, >>>>>>> >>>>>>> As soon as we close a socket nobody can guarantee that the port is >>>>>>> free. >>>>>>> >>>>>>> Moreover, port returned by getFreePort()[1] remains not accessible >>>>>>> for >>>>>>> some time - it depends to system setup, take a look to discussions >>>>>>> around SO_REUSEPORT for Linux or SO_REUSEADDR and SO_LINGER for BSD. >>>>>>> >>>>>>> So from stability point of view it's better to just return random >>>>>>> number >>>>>>> between 49152 and 65535. >>>>>> >>>>>> Well, this doesn't seem to improve the odds by much. When there are >>>>>> more >>>>>> tests run in parallel, all of them requiring a free port, nothing >>>>>> prevents the random function to return the same port to all of them. >>>>>> Also, two subsequent requests can return the same port and cause >>>>>> problems with timing when a port used by a previous test is not fully >>>>>> ready to be assigned to a different socket. And as Dmitry pointed out >>>>>> unless one can keep hold of the allocated socket and use it later >>>>>> there >>>>>> is no guarantee that a port which was tested unallocated will remain >>>>>> unallocated also for the next few milliseconds. >>>>>> >>>>>> The only fail proof solution would be a port allocating service >>>>>> provided >>>>>> by the harness. Until then we can only (hopefully) decrease the chance >>>>>> of intermittent failures due to a port being in use. >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> 141 public static int getFreePort() throws InterruptedException, >>>>>>> IOException { >>>>>>> 142 int port = -1; >>>>>>> 143 >>>>>>> 144 while (port <= 0) { >>>>>>> 145 Thread.sleep(100); >>>>>>> 146 >>>>>>> 147 ServerSocket serverSocket = null; >>>>>>> 148 try { >>>>>>> 149 serverSocket = new ServerSocket(0); >>>>>>> 150 port = serverSocket.getLocalPort(); >>>>>>> 151 } finally { >>>>>>> 152 serverSocket.close(); >>>>>>> 153 } >>>>>>> 154 } >>>>>>> 155 >>>>>>> 156 return port; >>>>>>> 157 } >>>>>>> 158 >>>>>>> >>>>>>> >>>>>>> On 2013-11-20 19:40, roger riggs wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> fyi, The jdk.testlibrary.Utils.getFreePort() method will Open an >>>>>>>> free >>>>>>>> Socket, close it and return >>>>>>>> the port number. >>>>>>>> >>>>>>>> And as Alan recommended, use (0) when possible to have the system >>>>>>>> assign >>>>>>>> the port #. >>>>>>>> >>>>>>>> Roger >>>>>>>> >>>>>>>> On 11/20/2013 8:04 AM, Dmitry Samersoff wrote: >>>>>>>>> Taras, >>>>>>>>> >>>>>>>>> *The only* correct way to take really free port is: >>>>>>>>> >>>>>>>>> 1. Chose random number between 49152 and 65535 >>>>>>>>> 2. Open socket >>>>>>>>> >>>>>>>>> if socket fails - repeat step 1 >>>>>>>>> if socket OK - return *socket* >>>>>>>>> >>>>>>>>> >>>>>>>>> If you can't keep the socket open (e.g. you have to pass port >>>>>>>>> number as >>>>>>>>> property value) you shouldn't do any pre-check as it has no value >>>>>>>>> - as >>>>>>>>> as soon as you close socket someone can take the port. >>>>>>>>> >>>>>>>>> So just choose a random number within the range above and let >>>>>>>>> networking >>>>>>>>> code opening socket to handle port conflict. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-11-20 15:54, taras ledkov wrote: >>>>>>>>>> Hi Everyone, >>>>>>>>>> >>>>>>>>>> I am working on bug >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7195249. >>>>>>>>>> >>>>>>>>>> There are two webrevs: >>>>>>>>>> Webrev for jdk part: >>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.00/ >>>>>>>>>> >>>>>>>>>> Webrev for hs part: >>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.00/ >>>>>>>>>> >>>>>>>>>> Please take a look at some notes: >>>>>>>>>> - After discussing with Yekaterina Kantserova & Jaroslav Bachorik >>>>>>>>>> some >>>>>>>>>> shell tests have been converted to java based tests >>>>>>>>>> >>>>>>>>>> - PasswordFilePermissionTest & SSLConfigFilePermissionTest tests >>>>>>>>>> looked >>>>>>>>>> very similar, so a common parent class was created for them: >>>>>>>>>> AbstractFilePermissionTest >>>>>>>>>> >>>>>>>>>> - What was called RmiRegistrySslTest.java I've renamed to >>>>>>>>>> RmiRegistrySslTestApp.java. The java code to replace old shell >>>>>>>>>> script >>>>>>>>>> RmiRegistrySslTest.sh is called RmiRegistrySslTest.java, hence the >>>>>>>>>> huge >>>>>>>>>> diff. >>>>>>>>>> >>>>>>>>>> - The new RmiRegistrySslTest.java has some lines similar to the >>>>>>>>>> AbstractFilePermissionTest.java, I nevertheless decided to not >>>>>>>>>> complicate the code further and leave it as is. Please let me >>>>>>>>>> know if >>>>>>>>>> this is somehow not acceptable >>>>>>>>>> >>>>>>>>>> - com/oracle/java/testlibrary/Utils.java that is added to hotspot >>>>>>>>>> repository is taken from this patch: >>>>>>>>>> http://cr.openjdk.java.net/~ykantser/8023138/webrev.00/test/lib/testlibrary/jdk/testlibrary/Utils.java.sdiff.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - These tests will need additional changes when test library >>>>>>>>>> process >>>>>>>>>> tools will support command line options inheritance >>>>>>>>>> (http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-November/013235.html) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >> > > -- > With best regards, > Taras Ledkov > Mail-To: taras.ledkov at oracle.com > skype: taras_ledkov > Phone: 7(812)3346-157 From erik.joelsson at oracle.com Wed Jan 8 06:24:24 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 08 Jan 2014 14:24:24 +0000 Subject: hg: jdk8/tl: 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Message-ID: <20140108142425.364A862461@hg.openjdk.java.net> Changeset: 53d74b77ee53 Author: erikj Date: 2014-01-08 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/53d74b77ee53 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb, ihse, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 From erik.joelsson at oracle.com Wed Jan 8 06:24:48 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 08 Jan 2014 14:24:48 +0000 Subject: hg: jdk8/tl/jdk: 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Message-ID: <20140108142555.A4F0B62462@hg.openjdk.java.net> Changeset: 2437ccbf3504 Author: erikj Date: 2014-01-08 14:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2437ccbf3504 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb + test/java/lang/System/SetPropertiesNull.java From staffan.larsen at oracle.com Wed Jan 8 06:27:23 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 8 Jan 2014 15:27:23 +0100 Subject: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running In-Reply-To: <1CF6FDFD0639DF478B44651D79ECE7049BCE8691@GSCMHKP12EX.firmwide.corp.gs.com> References: <1CF6FDFD0639DF478B44651D79ECE7049BCE8691@GSCMHKP12EX.firmwide.corp.gs.com> Message-ID: Chan, Thanks for providing a patch and extra points for adding a test case! We are trying to move away from writing tests in shell-scripts because they tend to break more often than Java-based tests. Do you think it is possible to re-write your test case in pure Java? There are some helper classes for launching processes and parsing output in test/lib/testlibrary/jdk/testlibrary/. What is the reason for creating so many classes? Is that the best way to provoke the bug? If loading classes is the most efficient way of provoking the bug, perhaps it would be possible to re-write the test to load the same class over and over again in multiple class loaders instead of creating a ton of different classes? Thanks, /Staffan On 23 dec 2013, at 08:57, Chan, Sunny wrote: > Hello, > > I would like to proposed the following patch to fix the bug 7142035. The missing assert could cause an Assertion failure message if you install a java.lang.instrument agent and have a daemon thread running in the JVM. I have also included a regression test that demonstrate the issue. > > Please review this and let me know if we need to modify the patch in any way. > > Sunny Chan, Executive Director, Technology > Goldman Sachs (Asia) L.L.C. | 68th Floor | Cheung Kong Center | 2 Queens Road Central | Hong Kong > email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 > > This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication. > > <7142035.patch> From staffan.larsen at oracle.com Wed Jan 8 06:32:02 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 8 Jan 2014 15:32:02 +0100 Subject: [8] WXP fixes to avoid warning when compiling SA files In-Reply-To: <52B5CB65.5080407@orange.fr> References: <52A359FC.3010305@orange.fr> <52B5CB65.5080407@orange.fr> Message-ID: Francis, To be honest (and because I?m lazy), it?s a bit more work to push this to jdk7u than I am willing to spend. There isn?t a lot of activity in jdk7u any more and you shouldn?t expect much to be changed there. Most of the activity now is in jdk9. Thanks, /Staffan On 21 dec 2013, at 18:09, Francis ANDRE wrote: > Staffan > > By the way, I am working on the jdk7u... Could you also take in charge the backport to the jdk7u? > > Francis > > Le 09/12/2013 13:25, Staffan Larsen a ?crit : >> This change looks good to me. >> >> I have created https://bugs.openjdk.java.net/browse/JDK-8029798 for this change, and I can sponsor it. There are currently no open repos for low-priority hotspot changes so I will have to wait before pushing the change. >> >> /Staffan >> >> >> On 7 dec 2013, at 18:25, Francis ANDRE wrote: >> >>> Hi >>> >>> Compiling SA files leads to warning because of old or invalid options as below >>> >>> set INCLUDE=C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v7.0A\include;C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v7.0A\include >>> C:\progra~1\micros~2.0\vc\bin\cl.exe @C:\cygwin\tmp\nmE2.tmp >>> cl?: Ligne de commande warning D9035?: l'option 'GZ' est d?conseill?e et sera supprim?e dans une version ult?rieure >>> cl?: Ligne de commande warning D9036?: utilisez 'RTC1' ? la place de 'GZ' >>> cl?: Ligne de commande warning D9035?: l'option 'o' est d?conseill?e et sera supprim?e dans une version ult?rieure >>> cl?: Ligne de commande warning D9002?: option '-YX' inconnue ignor?e >>> cl?: Ligne de commande warning D9030?: '/Gm' incompatible avec le multitraitement?; commutateur /MP ignor? >>> sadis.c >>> >>> >>> Here the diff >>> >>> diff --git a/make/windows/makefiles/sa.make b/make/windows/makefiles/sa.make >>> --- a/make/windows/makefiles/sa.make >>> +++ b/make/windows/makefiles/sa.make >>> @@ -94,7 +94,7 @@ >>> SA_LD_FLAGS = bufferoverflowU.lib >>> !endif >>> !else >>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX >>> -FD -GZ -c >>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -FD -RT >>> C1 -c >>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>> SA_CFLAGS = $(SA_CFLAGS) -ZI >>> !endif >>> >> > From kevin.walls at oracle.com Wed Jan 8 06:59:32 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 08 Jan 2014 14:59:32 +0000 Subject: RFR 8028623: SA: hash codes in SymbolTable mismatching java_lang_String::hash_code for extended characters. In-Reply-To: <67C1E9FA-7680-421F-BAD3-292021231C6B@oracle.com> References: <52C6F69E.4010107@oracle.com> <67C1E9FA-7680-421F-BAD3-292021231C6B@oracle.com> Message-ID: <52CD67D4.7020702@oracle.com> Hi Staffan - http://cr.openjdk.java.net/~kevinw/8028623/webrev.01/ Yes it's better now, getting pid and launching a tool etc have been previous reasons to use a script, but with this new help it's not too bad!... Thanks, Kevin On 07/01/14 09:43, Staffan Larsen wrote: > Kevin, > > The fix looks good. > > For tests, we are trying to avoid adding new shell-script based tests since they too often cause problems. Would it be possible to rewrite the test in pure Java code? There are some helper routines in test/testlibrary/com/oracle/java/testlibrary/ that could be useful. > > /Staffan > > On 3 jan 2014, at 18:42, Kevin Walls wrote: > >> Hi, >> >> This problem means you can't use the SA if the target app contains a symbol which uses a non-ascii character. The SA tool will fail with an error, the JVM itself and the SA having calculated different hashes for such Strings. >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8028623 >> >> webrev: >> http://cr.openjdk.java.net/~kevinw/8028623/webrev.00/ >> >> Thanks >> Kevin From michael.fang at oracle.com Wed Jan 8 06:58:52 2014 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Wed, 08 Jan 2014 14:58:52 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20140108145930.428F162463@hg.openjdk.java.net> Changeset: 5d05be02629c Author: mfang Date: 2014-01-07 21:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d05be02629c 8029239: jdk8 l10n resource file translation update - localenames Reviewed-by: okutsu ! src/share/classes/sun/util/resources/de/LocaleNames_de.properties ! src/share/classes/sun/util/resources/es/LocaleNames_es.properties ! src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties ! src/share/classes/sun/util/resources/it/LocaleNames_it.properties ! src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties ! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties ! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties Changeset: b7e7d7ad6f68 Author: mfang Date: 2014-01-07 22:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7e7d7ad6f68 8026570: NLS: jdk8 man page update Reviewed-by: naoto, okutsu ! make/Images.gmk ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 + src/linux/doc/man/ja/jcmd.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 + src/linux/doc/man/ja/jdeps.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 + src/linux/doc/man/ja/jjs.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/jvisualvm.1 ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 + src/solaris/doc/sun/man/man1/ja/jcmd.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 + src/solaris/doc/sun/man/man1/ja/jdeps.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 + src/solaris/doc/sun/man/man1/ja/jjs.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/jvisualvm.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 Changeset: 7c8f4610a23d Author: mfang Date: 2014-01-08 06:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c8f4610a23d Merge From Sunny.Chan at gs.com Wed Jan 8 07:48:55 2014 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Wed, 8 Jan 2014 23:48:55 +0800 Subject: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running In-Reply-To: References: <1CF6FDFD0639DF478B44651D79ECE7049BCE8691@GSCMHKP12EX.firmwide.corp.gs.com> Message-ID: <1CF6FDFD0639DF478B44651D79ECE7049BCE89FB@GSCMHKP12EX.firmwide.corp.gs.com> Hi Staffan I wrote the test with a shell script and creating lots of classes because that's the easiest way to trigger the bug. I will try to rewrite the test in Pure Java and multiple classloaders and see whether it will trigger the bug - I will get back to you on this. In terms of the bug fix itself does it look fine? Thanks, Sunny -----Original Message----- From: Staffan Larsen [mailto:staffan.larsen at oracle.com] Sent: 08 January 2014 22:27 To: Chan, Sunny [Tech] Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running Chan, Thanks for providing a patch and extra points for adding a test case! We are trying to move away from writing tests in shell-scripts because they tend to break more often than Java-based tests. Do you think it is possible to re-write your test case in pure Java? There are some helper classes for launching processes and parsing output in test/lib/testlibrary/jdk/testlibrary/. What is the reason for creating so many classes? Is that the best way to provoke the bug? If loading classes is the most efficient way of provoking the bug, perhaps it would be possible to re-write the test to load the same class over and over again in multiple class loaders instead of creating a ton of different classes? Thanks, /Staffan On 23 dec 2013, at 08:57, Chan, Sunny wrote: > Hello, > > I would like to proposed the following patch to fix the bug 7142035. The missing assert could cause an Assertion failure message if you install a java.lang.instrument agent and have a daemon thread running in the JVM. I have also included a regression test that demonstrate the issue. > > Please review this and let me know if we need to modify the patch in any way. > > Sunny Chan, Executive Director, Technology Goldman Sachs (Asia) L.L.C. > | 68th Floor | Cheung Kong Center | 2 Queens Road Central | Hong Kong > email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 > > This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication. > > <7142035.patch> From vladimir.kozlov at oracle.com Wed Jan 8 09:59:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 08 Jan 2014 09:59:26 -0800 Subject: RFR(L): 8028468: Add inlining information into ciReplay In-Reply-To: <8C0BDE83-8DC7-46C6-B4FD-399344BEEF41@oracle.com> References: <529E92AB.9060901@oracle.com> <52BE343C.8030500@oracle.com> <5677FA89-F151-4E24-8857-C6A9717E0C3D@oracle.com> <52CCCDE4.4010606@oracle.com> <8C0BDE83-8DC7-46C6-B4FD-399344BEEF41@oracle.com> Message-ID: <52CD91FE.5020104@oracle.com> Thank you, Roland On 1/8/14 12:41 AM, Roland Westrelin wrote: > Thanks for the new webrev and explanations. > > ciReplay.hpp > 59 // Replay data file replay_pid%p.log is also created when VM crushes > > when VM crashes Fixed. Thanks, Vladimir > > That looks good to me. > > Roland. > > On Jan 8, 2014, at 5:02 AM, Vladimir Kozlov wrote: > >> Thank you, Roland >> >> On 1/7/14 2:39 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~kvn/8028468/webrev/ >> >> New webrev: >> >> http://cr.openjdk.java.net/~kvn/8028468/webrev.01/ >> >>> >>> Should the agent/doc/cireplay.html be updated? Is there another doc on how to use the replay support somewhere (wiki)? >> >> cireplay.html describes how to use SA to extract compilation replay data from core files. Nothing changed there with my changes. >> I don't think we have any wiki for compilation replay. >> >> I added all replay command descriptions and examples into ciReplay.hpp. >> >>> >>> ciReplay.cpp >>> typos: >>> // Use pointer because we may need to retirn inline records >>> >>> // Replay Inlinig >>> >>> vmError.cpp >>> typo: >>> // Do not overwite file during replay >> >> Typos are fixed. >> >>> >>> compile.hpp >>> Shouldn?t _replay_inline_data be private with an accessor? >>> >>> 1183 // Dump inlining replay data to the stream. >>> 1184 void dump_inline_data(outputStream* out); >>> 1185 void* _replay_inline_data; >> >> Done. >> >>> >>> ciReplay.cpp >>> Why was this changed? Why was it there in the first place? >>> 1052 // Make sure we don't run with background compilation >>> 1053 // BackgroundCompilation = false; >> >> I forgot to uncomment it. It is done only when compilation (not inlining) is replayed. It is special case. Such replaying is done by putting compilation task on compile queue immediately after VM initialization. So we should wait (-Xbatch, -XX:-BackgroundCompilation) until it is finished because we don't need to execute java code (there is no program to execute). And after compilation we exit VM: >> >> void ciReplay::replay(TRAPS) { >> int exit_code = replay_impl(THREAD); >> >> Threads::destroy_vm(); >> >> vm_exit(exit_code); >> } >> >>> >>> Existing fields in class CompileReplay that don?t start with _ make the code confusing: >>> >>> char* bufptr; >>> char* buffer; >>> int buffer_length; >>> int buffer_end; >>> int line_no; >>> >>> etc. Maybe it would be worthwhile to fix that as part of this change? >> >> I added '_' to all fields in this file. >> >>> >>> Can buffer be a growableArray? If not factor this code and other similar code in a method? >>> 437 if (pos + 1 >= buffer_length) { >>> 438 int newl = buffer_length * 2; >>> 439 char* newb = NEW_RESOURCE_ARRAY(char, newl); >>> 440 memcpy(newb, buffer, pos); >>> 441 buffer = newb; >>> 442 buffer_length = newl; >>> 443 } >>> >>> Same for: >>> 445 // null terminate it, reset the pointer and process the line >>> 446 buffer[pos] = '\0'; >>> 447 buffer_end = pos++; >>> 448 bufptr = buffer; >> >> Done. That code is moved to new method get_line(). >> >>> >>> Shouldn?t the fields below be private? >>> 422 ciKlass* _iklass; >>> 423 Method* _imethod; >>> 424 int _entry_bci; >>> 425 int _comp_level; >> >> Done. >> >>> >>> I think >>> ciInlineRecord* find_ciInlineRecord(Method* method, int bci, int inline_depth) >>> should be implemented by calling: >>> static ciInlineRecord* find_ciInlineRecord(GrowableArray* records, Method* method, int bci, int inline_depth) >>> to avoid duplication of code. >> >> Done. >> >> I also missed _ci_inline_records field initialization so I added it to CompileReplay constructor. >> >> Thanks, >> Vladimir >> >>> >>> Roland. >>> > From mandy.chung at oracle.com Wed Jan 8 14:52:29 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 08 Jan 2014 14:52:29 -0800 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52CD19AB.1080307@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CB6600.4050804@oracle.com> <52CD0EF6.4010801@oracle.com> <52CD19AB.1080307@oracle.com> Message-ID: <52CDD6AD.8010803@oracle.com> On 1/8/2014 1:26 AM, David Holmes wrote: >> IMO, it seems that the ThreadInfo was not updated to reflect the >> introduction of the park()/unpark() methods. In the current state it >> mistakenly reports parking a thread as blocking but if the >> implementation is updated to include only blocking on monitor entry (to >> correspond to the API docs) we will miss the information about the >> thread being parked (when the thread also does not execute any user >> code). This would most probably call for the update of ThreadInfo API. > > park() puts you in Thread.State WAITING which is exposed via > ThreadInfo.getWaitedCount, so I don't see any issue there. If parking > is causing a change to the blocked count then that is a major bug in > the underlying MXBean implementation. David is right that LockSupport.park (and parkUntil or parkNanos) transitions the thread state to WAITING (and TIMED_WAITING) [1]. Similar to Object.wait, the current thread is waiting for another thread to unpark it (i.e. make the permit available for it). Mandy [1] http://download.java.net/jdk8/docs/api/java/lang/Thread.State.html#WAITING From paul.sandoz at oracle.com Thu Jan 9 02:50:48 2014 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 09 Jan 2014 10:50:48 +0000 Subject: hg: jdk8/tl/jdk: 8031187: DoubleStream.count is incorrect for a stream containing > Integer.MAX_VALUE elements Message-ID: <20140109105107.5E7D86248A@hg.openjdk.java.net> Changeset: 630a92015993 Author: psandoz Date: 2014-01-09 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/630a92015993 8031187: DoubleStream.count is incorrect for a stream containing > Integer.MAX_VALUE elements Reviewed-by: darcy ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountLargeTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java From jaroslav.bachorik at oracle.com Thu Jan 9 05:35:39 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 09 Jan 2014 14:35:39 +0100 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52B82FBC.3080704@oracle.com> References: <52B82FBC.3080704@oracle.com> Message-ID: <52CEA5AB.7040900@oracle.com> Hi, thanks do David and Staffan it was possible to pinpoint the contention to the static initializaton and classloading. David suggested running the test routine twice to exercise any initialization during the first run and performs the checks only for the results of the second run. The test is using Phaser for synchronization. All the potentially blocking code (System.out.println(), Thread.currentThread(), etc.) was removed from the tested thread. The webrev is available at http://cr.openjdk.java.net/~jbachorik/8030847/webrev.01 Thanks, -JB- From jaroslav.bachorik at oracle.com Thu Jan 9 06:05:11 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 09 Jan 2014 15:05:11 +0100 Subject: RFR 8031420: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails on some platforms: Unable to locate 'libjvm.so' Message-ID: <52CEAC97.6040707@oracle.com> Please, review this small test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8031420 Webrev: http://cr.openjdk.java.net/~jbachorik/8031420/webrev.00 The test needs to check for the supported platform first and exit gracefully if it is run on an unsupported one. Thanks, -JB- From shanliang.jiang at oracle.com Thu Jan 9 06:27:29 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 09 Jan 2014 15:27:29 +0100 Subject: jmx-dev RFR 8031420: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails on some platforms: Unable to locate 'libjvm.so' In-Reply-To: <52CEAC97.6040707@oracle.com> References: <52CEAC97.6040707@oracle.com> Message-ID: <52CEB1D1.7000101@oracle.com> The fix looks OK. Line 232 is not necessary. The simplest fix might be only to add the following lines to 94 if (getPlatform() == null) { return; } Shanliang Jaroslav Bachorik wrote: > Please, review this small test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031420 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031420/webrev.00 > > The test needs to check for the supported platform first and exit > gracefully if it is run on an unsupported one. > > Thanks, > > -JB- From chris.hegarty at oracle.com Thu Jan 9 09:02:57 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 9 Jan 2014 17:02:57 +0000 Subject: RFR 8031420: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails on some platforms: Unable to locate 'libjvm.so' In-Reply-To: <52CEAC97.6040707@oracle.com> References: <52CEAC97.6040707@oracle.com> Message-ID: <379B3BE4-031B-4885-B16F-5DF4DA0484D0@oracle.com> Looks fine to me. -Chris. On 9 Jan 2014, at 14:05, Jaroslav Bachorik wrote: > Please, review this small test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031420 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031420/webrev.00 > > The test needs to check for the supported platform first and exit gracefully if it is run on an unsupported one. > > Thanks, > > -JB- From staffan.larsen at oracle.com Thu Jan 9 23:15:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 10 Jan 2014 08:15:50 +0100 Subject: RFR 8031420: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails on some platforms: Unable to locate 'libjvm.so' In-Reply-To: <52CEAC97.6040707@oracle.com> References: <52CEAC97.6040707@oracle.com> Message-ID: <6A08D74B-6227-40D8-805A-83F46FE33CE5@oracle.com> Looks good! Thanks, /Staffan On 9 jan 2014, at 15:05, Jaroslav Bachorik wrote: > Please, review this small test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031420 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031420/webrev.00 > > The test needs to check for the supported platform first and exit gracefully if it is run on an unsupported one. > > Thanks, > > -JB- From Alan.Bateman at oracle.com Fri Jan 10 00:34:18 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2014 08:34:18 +0000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CF2EA3.9060504@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> Message-ID: <52CFB08A.5040400@oracle.com> On 09/01/2014 23:20, Tristan Yan wrote: > Hi David > I wasn't able to reproduce this failure either in local or in our same > binaries running(This is a continuous running with same JDK binaries). > So intention for this code change is bringing this test back; add > some debug info and try to avoid possible issues in this test. I agree > this code change won't solve the failure happened. But this test was > put into ProblemList two years ago better move for this is move out it > from ProblemList and trace down the issue in our normal nightly. If we can't duplicate it now, and the output from previously reported failures (in 2011) is insufficient to diagnose it properly, then it seems reasonable to add better output so as to improve our chances of understanding if it fails again. So better output + removing from the exclude list seems fine here. (cc'ing serviceability-dev as that is actually the mailing list for the HPROF and JVM TI areas). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140110/4b1884c1/attachment.html From staffan.larsen at oracle.com Fri Jan 10 00:40:17 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 10 Jan 2014 09:40:17 +0100 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CFB08A.5040400@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52CFB08A.5040400@oracle.com> Message-ID: <2637E9FC-1CE2-4774-AD41-E760BAAFB30C@oracle.com> On 10 jan 2014, at 09:34, Alan Bateman wrote: > On 09/01/2014 23:20, Tristan Yan wrote: >> Hi David >> I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same JDK binaries). So intention for this code change is bringing this test back; add some debug info and try to avoid possible issues in this test. I agree this code change won't solve the failure happened. But this test was put into ProblemList two years ago better move for this is move out it from ProblemList and trace down the issue in our normal nightly. > If we can't duplicate it now, and the output from previously reported failures (in 2011) is insufficient to diagnose it properly, then it seems reasonable to add better output so as to improve our chances of understanding if it fails again. So better output + removing from the exclude list seems fine here. (cc'ing serviceability-dev as that is actually the mailing list for the HPROF and JVM TI areas). Sounds good to me, /Staffan > > -Alan From david.holmes at oracle.com Fri Jan 10 02:37:21 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Jan 2014 20:37:21 +1000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <2637E9FC-1CE2-4774-AD41-E760BAAFB30C@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52CFB08A.5040400@oracle.com> <2637E9FC-1CE2-4774-AD41-E760BAAFB30C@oracle.com> Message-ID: <52CFCD61.5070907@oracle.com> On 10/01/2014 6:40 PM, Staffan Larsen wrote: > > On 10 jan 2014, at 09:34, Alan Bateman wrote: > >> On 09/01/2014 23:20, Tristan Yan wrote: >>> Hi David >>> I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same JDK binaries). So intention for this code change is bringing this test back; add some debug info and try to avoid possible issues in this test. I agree this code change won't solve the failure happened. But this test was put into ProblemList two years ago better move for this is move out it from ProblemList and trace down the issue in our normal nightly. >> If we can't duplicate it now, and the output from previously reported failures (in 2011) is insufficient to diagnose it properly, then it seems reasonable to add better output so as to improve our chances of understanding if it fails again. So better output + removing from the exclude list seems fine here. (cc'ing serviceability-dev as that is actually the mailing list for the HPROF and JVM TI areas). > > Sounds good to me, I'm not sure what is actually being proposed. I don't really see anything that would help diagnoze the original issue. But bring back the test - maybe this was a bug elsewhere that has now been fixed. David > /Staffan > >> >> -Alan > From Alan.Bateman at oracle.com Fri Jan 10 02:43:00 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2014 10:43:00 +0000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CFCD61.5070907@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52CFB08A.5040400@oracle.com> <2637E9FC-1CE2-4774-AD41-E760BAAFB30C@oracle.com> <52CFCD61.5070907@oracle.com> Message-ID: <52CFCEB4.7080603@oracle.com> On 10/01/2014 10:37, David Holmes wrote: > > I'm not sure what is actually being proposed. I don't really see > anything that would help diagnoze the original issue. But bring back > the test - maybe this was a bug elsewhere that has now been fixed. I think the proposal is as we said, more diagnostic output + remove from exclude list. If Tristan's agrees then I'm sure he'll update the patch. On your second point then you may be right, there were a number of issues during JDK 8 and it's very possible that the ghost being chasing now is gone. -Alan. From yekaterina.kantserova at oracle.com Fri Jan 10 04:50:07 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 10 Jan 2014 13:50:07 +0100 Subject: RFR (S): 7185591: jcmd-big-script.sh ERROR: could not find app's Java pid. Message-ID: <52CFEC7F.4040207@oracle.com> Hi, Could I please have a review of this fix. In this fix I've rewritten sun/tools/jcmd/* tests in pure java to get rid of all intermittent failures depending on for example MKS or race conditions (test application has not yet started when the test start to run). Webrev: http://cr.openjdk.java.net/~ykantser/7185591/webrev.00/ Primal bug: https://bugs.openjdk.java.net/browse/JDK-7185591 Similar bugs: https://bugs.openjdk.java.net/browse/JDK-6977426 https://bugs.openjdk.java.net/browse/JDK-8020798 https://bugs.openjdk.java.net/browse/JDK-7130656 (this one is blocked by https://bugs.openjdk.java.net/browse/JDK-8031482 so far) Thanks, Katja From erik.joelsson at oracle.com Fri Jan 10 04:29:57 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 10 Jan 2014 12:29:57 +0000 Subject: hg: jdk8/tl/jdk: 8031300: No jdeps.1 and jjs.1 man pages in jdk8 b122 build and jvisualvm.1 and jcmd.1 missing on macosx; ... Message-ID: <20140110123036.99DB6624BC@hg.openjdk.java.net> Changeset: 6f3a3bd78c57 Author: erikj Date: 2014-01-10 10:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f3a3bd78c57 8031300: No jdeps.1 and jjs.1 man pages in jdk8 b122 build and jvisualvm.1 and jcmd.1 missing on macosx 8030946: No jmc.1 for man page of JMC Reviewed-by: ihse, tbell ! make/Images.gmk + src/bsd/doc/man/ja/jcmd.1 + src/bsd/doc/man/ja/jdeps.1 + src/bsd/doc/man/ja/jjs.1 - src/bsd/doc/man/ja/kinit.1 - src/bsd/doc/man/ja/klist.1 - src/bsd/doc/man/ja/ktab.1 From john.coomes at oracle.com Fri Jan 10 13:17:45 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 21:17:45 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b123 for changeset 1ecd4619f60c Message-ID: <20140110211748.B1126624FA@hg.openjdk.java.net> Changeset: afecd2878aee Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/afecd2878aee Added tag jdk8-b123 for changeset 1ecd4619f60c ! .hgtags From john.coomes at oracle.com Fri Jan 10 13:17:53 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 21:17:53 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b123 for changeset 4e35b5b6d2e5 Message-ID: <20140110211806.4E9E1624FB@hg.openjdk.java.net> Changeset: 1a28f773c894 Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/1a28f773c894 Added tag jdk8-b123 for changeset 4e35b5b6d2e5 ! .hgtags From john.coomes at oracle.com Fri Jan 10 13:18:11 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 21:18:11 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b123 for changeset 91f5c542ccad Message-ID: <20140110211821.CEF3F624FC@hg.openjdk.java.net> Changeset: 241e4effed6d Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/241e4effed6d Added tag jdk8-b123 for changeset 91f5c542ccad ! .hgtags From john.coomes at oracle.com Fri Jan 10 13:18:32 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 21:18:32 +0000 Subject: hg: hsx/hotspot-rt/jdk: 2 new changesets Message-ID: <20140110212038.7A173624FD@hg.openjdk.java.net> Changeset: 484e16c0a040 Author: nikgor Date: 2014-01-07 12:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/484e16c0a040 8004562: Better support for crossdomain.xml Reviewed-by: herrick, ngthomas, chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 13b28cffa140 Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/13b28cffa140 Added tag jdk8-b123 for changeset 484e16c0a040 ! .hgtags From john.coomes at oracle.com Fri Jan 10 13:22:49 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 21:22:49 +0000 Subject: hg: hsx/hotspot-rt/nashorn: Added tag jdk8-b123 for changeset 688f4167f921 Message-ID: <20140110212256.6796F624FF@hg.openjdk.java.net> Changeset: 0b4301c79225 Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/0b4301c79225 Added tag jdk8-b123 for changeset 688f4167f921 ! .hgtags From john.coomes at oracle.com Fri Jan 10 13:22:33 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 21:22:33 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b123 for changeset a345cf28faca Message-ID: <20140110212243.7F948624FE@hg.openjdk.java.net> Changeset: d5aab8300d3b Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d5aab8300d3b Added tag jdk8-b123 for changeset a345cf28faca ! .hgtags From john.coomes at oracle.com Fri Jan 10 13:17:41 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 21:17:41 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b123 for changeset ff1478785e43 Message-ID: <20140110211741.BA975624F8@hg.openjdk.java.net> Changeset: c330fa67c4da Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/c330fa67c4da Added tag jdk8-b123 for changeset ff1478785e43 ! .hgtags From staffan.larsen at oracle.com Mon Jan 13 02:30:15 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Jan 2014 11:30:15 +0100 Subject: RFR(M): 8030812 : Change the solaris DTrace implementation to use USDT2 instead of USDT1 In-Reply-To: <29F99613-1784-409C-98A8-21E1F663B046@oracle.com> References: <29F99613-1784-409C-98A8-21E1F663B046@oracle.com> Message-ID: <959AAEDF-D660-496C-B2DA-30E9EDF1725B@oracle.com> I?m still looking for a Review of this change (I know it?s nobody?s favorite code?). Thanks, /Staffan On 20 dec 2013, at 12:58, Staffan Larsen wrote: > The DTrace static probe implementation in Hotspot was written with an earlier version of DTrace. With newer versions, DTrace can create a header file from the contents of the .d file that describes the probes. This newer version (called USDT2) has been used on OS X. Because we have had both versions active, the code has ended up looking ugly because of all the extra macros. > > This is a first step in cleaning that up by moving the solaris implementation to use USDT2. The remaining step before USDT1 can be removed is to change the Linux system tap implementation to also use USDT2. > > What I have changed is: > - Update the solaris dtrace.make to generate the header files. I have used the same code as on bsd. > - While I was there, I removed a lot of commented out code from the bsd dtrace.make file. > - Updated the hotspot.d files on bsd and solaris so that they have the same contents. > - Fixed some compilation errors in compileBroker.cpp with const char*. > - May of the USDT2 macro invocations had an extra line break in them. This both looked ugly and confused the solaris compiler, so I removed them. This lead to a _lot_ of changes in jni.cpp - enough changes so that webrev couldn?t handle it, which is why some of the webrev views are broken for this file. > - > > Testing: I have run the vm.dtrace.testlist on both Solaris and OS X. > > webrev: http://cr.openjdk.java.net/~sla/8030812/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8030812 > > Thanks, > /Staffan From yekaterina.kantserova at oracle.com Mon Jan 13 02:40:05 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 13 Jan 2014 11:40:05 +0100 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52CFEC7F.4040207@oracle.com> References: <52CFEC7F.4040207@oracle.com> Message-ID: <52D3C285.70301@oracle.com> Hi, Could I please have a review of this fix. I've rewritten the shell tests sun/tools/jstack and sun/tools/jmap in pure Java to get rid of environmental problems. The com/sun/tools/attach tests has already been fixed. Webrev: http://cr.openjdk.java.net/~ykantser/6380601/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-6380601 Thanks, Katja From staffan.larsen at oracle.com Mon Jan 13 03:31:17 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Jan 2014 12:31:17 +0100 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D3C285.70301@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> Message-ID: <6E4A2950-A79C-43CE-BC97-8D693E371870@oracle.com> The changes look good, although the tests are *very* basic. Probably does not make sense to improve the tests as part of this change, though. /Staffan On 13 jan 2014, at 11:40, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > I've rewritten the shell tests sun/tools/jstack and sun/tools/jmap in pure Java to get rid of environmental problems. The com/sun/tools/attach tests has already been fixed. > > > Webrev: > http://cr.openjdk.java.net/~ykantser/6380601/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-6380601 > > > Thanks, > Katja From Alan.Bateman at oracle.com Mon Jan 13 03:33:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Jan 2014 11:33:13 +0000 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D3C285.70301@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> Message-ID: <52D3CEF9.2000307@oracle.com> On 13/01/2014 10:40, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > I've rewritten the shell tests sun/tools/jstack and sun/tools/jmap in > pure Java to get rid of environmental problems. The > com/sun/tools/attach tests has already been fixed. > > > Webrev: > http://cr.openjdk.java.net/~ykantser/6380601/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-6380601 A minor comment but the location implies that it is a test for jmap or jstack so you could use a shorter name for the test if you wish. In other areas then we have been using "Basic.java" for the name of basic tests. You might want to check the copyright dates, there should be one year or a range (two years) rather than three. -Alan From dmitry.samersoff at oracle.com Mon Jan 13 04:12:08 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 13 Jan 2014 16:12:08 +0400 Subject: RFR(M): 8030812 : Change the solaris DTrace implementation to use USDT2 instead of USDT1 In-Reply-To: <959AAEDF-D660-496C-B2DA-30E9EDF1725B@oracle.com> References: <29F99613-1784-409C-98A8-21E1F663B046@oracle.com> <959AAEDF-D660-496C-B2DA-30E9EDF1725B@oracle.com> Message-ID: <52D3D818.3040301@oracle.com> Staffan, Looks good for me. -Dmitry On 2014-01-13 14:30, Staffan Larsen wrote: > I?m still looking for a Review of this change (I know it?s nobody?s favorite code?). > > Thanks, > /Staffan > > On 20 dec 2013, at 12:58, Staffan Larsen wrote: > >> The DTrace static probe implementation in Hotspot was written with an earlier version of DTrace. With newer versions, DTrace can create a header file from the contents of the .d file that describes the probes. This newer version (called USDT2) has been used on OS X. Because we have had both versions active, the code has ended up looking ugly because of all the extra macros. >> >> This is a first step in cleaning that up by moving the solaris implementation to use USDT2. The remaining step before USDT1 can be removed is to change the Linux system tap implementation to also use USDT2. >> >> What I have changed is: >> - Update the solaris dtrace.make to generate the header files. I have used the same code as on bsd. >> - While I was there, I removed a lot of commented out code from the bsd dtrace.make file. >> - Updated the hotspot.d files on bsd and solaris so that they have the same contents. >> - Fixed some compilation errors in compileBroker.cpp with const char*. >> - May of the USDT2 macro invocations had an extra line break in them. This both looked ugly and confused the solaris compiler, so I removed them. This lead to a _lot_ of changes in jni.cpp - enough changes so that webrev couldn?t handle it, which is why some of the webrev views are broken for this file. >> - >> >> Testing: I have run the vm.dtrace.testlist on both Solaris and OS X. >> >> webrev: http://cr.openjdk.java.net/~sla/8030812/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8030812 >> >> Thanks, >> /Staffan > -- 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 staffan.larsen at oracle.com Mon Jan 13 04:19:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Jan 2014 13:19:42 +0100 Subject: RFR (S): 7185591: jcmd-big-script.sh ERROR: could not find app's Java pid. In-Reply-To: <52CFEC7F.4040207@oracle.com> References: <52CFEC7F.4040207@oracle.com> Message-ID: Katja, test/lib/testlibrary/jdk/testlibrary/JcmdBase.java 68 * Run jcmd standalone I think you should expand a bit on what ?standalone? means here. It took me a while to understand the difference. test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java 423 public int indexOf(String pattern) { This seems very inefficient. Add all lines to an ArrayList and then walk through them one at a time to if it matches and then walk through them once again to find the index of that line. 469 public int shouldMatchByLine(String from, String to, String pattern) { Same inefficiency here, but worse because both asLines() and indexOf() does the same work. test/lib/testlibrary/jdk/testlibrary/Utils.java 65 public static final String TEST_SRC = System.getProperty("test.src").trim(); I wonder if this really works. Isn?t ?test.src? different for different tests? A property that jtreg changes before invoking each test? Or does this work because each test is run in a different class loader and Utils.java will exist once in each class loader? /Staffan On 10 jan 2014, at 13:50, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > In this fix I've rewritten sun/tools/jcmd/* tests in pure java to get rid of all intermittent failures depending on for example MKS or race conditions (test application has not yet started when the test start to run). > > > Webrev: > http://cr.openjdk.java.net/~ykantser/7185591/webrev.00/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-7185591 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-6977426 > https://bugs.openjdk.java.net/browse/JDK-8020798 > https://bugs.openjdk.java.net/browse/JDK-7130656 (this one is blocked by https://bugs.openjdk.java.net/browse/JDK-8031482 so far) > > Thanks, > Katja From staffan.larsen at oracle.com Mon Jan 13 04:37:08 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Jan 2014 13:37:08 +0100 Subject: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running In-Reply-To: <1CF6FDFD0639DF478B44651D79ECE7049BCE89FB@GSCMHKP12EX.firmwide.corp.gs.com> References: <1CF6FDFD0639DF478B44651D79ECE7049BCE8691@GSCMHKP12EX.firmwide.corp.gs.com> <1CF6FDFD0639DF478B44651D79ECE7049BCE89FB@GSCMHKP12EX.firmwide.corp.gs.com> Message-ID: <82EAB712-F453-4048-A9AB-1A42EE258102@oracle.com> On 8 jan 2014, at 16:48, Chan, Sunny wrote: > In terms of the bug fix itself does it look fine? Yes, it does. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140113/ac1ad90c/attachment.html From staffan.larsen at oracle.com Mon Jan 13 04:38:53 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Jan 2014 13:38:53 +0100 Subject: RFR 8028623: SA: hash codes in SymbolTable mismatching java_lang_String::hash_code for extended characters. In-Reply-To: <52CD67D4.7020702@oracle.com> References: <52C6F69E.4010107@oracle.com> <67C1E9FA-7680-421F-BAD3-292021231C6B@oracle.com> <52CD67D4.7020702@oracle.com> Message-ID: <6A95994F-A7B2-47AD-8B05-0595280D6F95@oracle.com> Looks good! Thanks for taking the time to re-write the test in Java. Thanks, /Staffan On 8 jan 2014, at 15:59, Kevin Walls wrote: > > Hi Staffan - > > http://cr.openjdk.java.net/~kevinw/8028623/webrev.01/ > > Yes it's better now, getting pid and launching a tool etc have been previous reasons to use a script, but with this new help it's not too bad!... > > Thanks, > Kevin > > > On 07/01/14 09:43, Staffan Larsen wrote: >> Kevin, >> >> The fix looks good. >> >> For tests, we are trying to avoid adding new shell-script based tests since they too often cause problems. Would it be possible to rewrite the test in pure Java code? There are some helper routines in test/testlibrary/com/oracle/java/testlibrary/ that could be useful. >> >> /Staffan >> >> On 3 jan 2014, at 18:42, Kevin Walls wrote: >> >>> Hi, >>> >>> This problem means you can't use the SA if the target app contains a symbol which uses a non-ascii character. The SA tool will fail with an error, the JVM itself and the SA having calculated different hashes for such Strings. >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8028623 >>> >>> webrev: >>> http://cr.openjdk.java.net/~kevinw/8028623/webrev.00/ >>> >>> Thanks >>> Kevin > From yekaterina.kantserova at oracle.com Mon Jan 13 05:14:45 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 13 Jan 2014 14:14:45 +0100 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <6E4A2950-A79C-43CE-BC97-8D693E371870@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <6E4A2950-A79C-43CE-BC97-8D693E371870@oracle.com> Message-ID: <52D3E6C5.8080803@oracle.com> Thank you for reviewing this! Yes, I completely agree the tests are *very* basic, but I've decided it's more important to fix them as they are for the moment. I can open en enhancement that sun tools need more tests. Thanks, Katja On 01/13/2014 12:31 PM, Staffan Larsen wrote: > The changes look good, although the tests are *very* basic. Probably does not make sense to improve the tests as part of this change, though. > > /Staffan > > On 13 jan 2014, at 11:40, Yekaterina Kantserova wrote: > >> Hi, >> >> Could I please have a review of this fix. >> >> I've rewritten the shell tests sun/tools/jstack and sun/tools/jmap in pure Java to get rid of environmental problems. The com/sun/tools/attach tests has already been fixed. >> >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/6380601/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-6380601 >> >> >> Thanks, >> Katja From yekaterina.kantserova at oracle.com Mon Jan 13 05:17:48 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 13 Jan 2014 14:17:48 +0100 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D3CEF9.2000307@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <52D3CEF9.2000307@oracle.com> Message-ID: <52D3E77C.9020609@oracle.com> Thank you for reviewing this! Unfortunantely I can't use Basic.java since we don't use packages for jtreg tests. Should I use "2005 - 2014" instead of "2005, 2011, 2014"? Thanks, Katja On 01/13/2014 12:33 PM, Alan Bateman wrote: > On 13/01/2014 10:40, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> I've rewritten the shell tests sun/tools/jstack and sun/tools/jmap in >> pure Java to get rid of environmental problems. The >> com/sun/tools/attach tests has already been fixed. >> >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/6380601/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-6380601 > A minor comment but the location implies that it is a test for jmap or > jstack so you could use a shorter name for the test if you wish. In > other areas then we have been using "Basic.java" for the name of basic > tests. > > You might want to check the copyright dates, there should be one year > or a range (two years) rather than three. > > -Alan From fredrik.arvidsson at oracle.com Mon Jan 13 05:17:52 2014 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Mon, 13 Jan 2014 14:17:52 +0100 Subject: RFR(S): JDK-8031304 : Add dcmd to print all loaded dynamic libraries Message-ID: <52D3E780.4020507@oracle.com> Hi Please help me review the following small enhancement: Webrev: http://cr.openjdk.java.net/~farvidsson/8031304/webrev.00/ Jira: https://bugs.openjdk.java.net/browse/JDK-8031304 /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140113/ccb65c2e/attachment.html From Alan.Bateman at oracle.com Mon Jan 13 05:29:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Jan 2014 13:29:20 +0000 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D3E77C.9020609@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <52D3CEF9.2000307@oracle.com> <52D3E77C.9020609@oracle.com> Message-ID: <52D3EA30.6040806@oracle.com> On 13/01/2014 13:17, Yekaterina Kantserova wrote: > Thank you for reviewing this! > > Unfortunantely I can't use Basic.java since we don't use packages for > jtreg tests. It is true that we use the unnamed package in most of the tests but that shouldn't be an issue because the location is unique. > > Should I use "2005 - 2014" instead of "2005, 2011, 2014"? 2005, 2014. -Alan. From yekaterina.kantserova at oracle.com Mon Jan 13 05:57:44 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 13 Jan 2014 14:57:44 +0100 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D3EA30.6040806@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <52D3CEF9.2000307@oracle.com> <52D3E77C.9020609@oracle.com> <52D3EA30.6040806@oracle.com> Message-ID: <52D3F0D8.1040605@oracle.com> On 01/13/2014 02:29 PM, Alan Bateman wrote: > On 13/01/2014 13:17, Yekaterina Kantserova wrote: >> Thank you for reviewing this! >> >> Unfortunantely I can't use Basic.java since we don't use packages for >> jtreg tests. > It is true that we use the unnamed package in most of the tests but > that shouldn't be an issue because the location is unique. > Sorry, I've not explained in more details. I have sun/tools tests in the same project in Eclipse and there I get a compilation error if I have 2 classes with the same name. I've used this standard for several fixes, for example sun/tools/jstatd. Do you think it's OK to keep these names? >> >> Should I use "2005 - 2014" instead of "2005, 2011, 2014"? > 2005, 2014. Thanks! > > -Alan. // Katja From dmitry.samersoff at oracle.com Mon Jan 13 06:03:41 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 13 Jan 2014 18:03:41 +0400 Subject: RFR(S): JDK-8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: <52D3E780.4020507@oracle.com> References: <52D3E780.4020507@oracle.com> Message-ID: <52D3F23D.80505@oracle.com> Looks good to me. On 2014-01-13 17:17, Fredrik Arvidsson wrote: > Hi > > Please help me review the following small enhancement: > > Webrev: http://cr.openjdk.java.net/~farvidsson/8031304/webrev.00/ > > Jira: https://bugs.openjdk.java.net/browse/JDK-8031304 > > /Fredrik -- 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 jaroslav.bachorik at oracle.com Mon Jan 13 06:04:44 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 13 Jan 2014 15:04:44 +0100 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D3F0D8.1040605@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <52D3CEF9.2000307@oracle.com> <52D3E77C.9020609@oracle.com> <52D3EA30.6040806@oracle.com> <52D3F0D8.1040605@oracle.com> Message-ID: <52D3F27C.4030807@oracle.com> On 13.1.2014 14:57, Yekaterina Kantserova wrote: > On 01/13/2014 02:29 PM, Alan Bateman wrote: >> On 13/01/2014 13:17, Yekaterina Kantserova wrote: >>> Thank you for reviewing this! >>> >>> Unfortunantely I can't use Basic.java since we don't use packages for >>> jtreg tests. >> It is true that we use the unnamed package in most of the tests but >> that shouldn't be an issue because the location is unique. >> > Sorry, I've not explained in more details. I have sun/tools tests in the > same project in Eclipse and there I get a compilation error if I have 2 > classes with the same name. I've used this standard for several fixes, > for example sun/tools/jstatd. Do you think it's OK to keep these names? Actually, this no-package convention really disturbs all the IDEs making them rather unusable when it comes to working with JDK tests. They are downgraded to dumb editors with the benefit of receiving of various false errors. -JB- >>> >>> Should I use "2005 - 2014" instead of "2005, 2011, 2014"? >> 2005, 2014. > Thanks! >> >> -Alan. > > // Katja From Alan.Bateman at oracle.com Mon Jan 13 06:13:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Jan 2014 14:13:55 +0000 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D3F0D8.1040605@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <52D3CEF9.2000307@oracle.com> <52D3E77C.9020609@oracle.com> <52D3EA30.6040806@oracle.com> <52D3F0D8.1040605@oracle.com> Message-ID: <52D3F4A3.4040102@oracle.com> On 13/01/2014 13:57, Yekaterina Kantserova wrote: > > > Sorry, I've not explained in more details. I have sun/tools tests in > the same project in Eclipse and there I get a compilation error if I > have 2 classes with the same name. I've used this standard for several > fixes, for example sun/tools/jstatd. Do you think it's OK to keep > these names? I don't have a strong opinion on the test names, I was just pointing out that the names duplicates information in directory name. As most of the tests are in the unnamed package then it will be awkward if you attempt to being them into the same IDE project. If you do need unique names then I would go for something like BasicJMapTest and BasicJStackTest. The names in sun/tools/jstatd look okay because they test something specific. However, this is all subjective and not something to spend much time on. Just another comment on @library, does /lib/testlibrary work? I though a recent change to jtreg meant that absolute paths works relative to the test root (which allows tests to move without needing to change the relative path to the library). -Alan. From yekaterina.kantserova at oracle.com Mon Jan 13 06:18:07 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 13 Jan 2014 15:18:07 +0100 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D3F4A3.4040102@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <52D3CEF9.2000307@oracle.com> <52D3E77C.9020609@oracle.com> <52D3EA30.6040806@oracle.com> <52D3F0D8.1040605@oracle.com> <52D3F4A3.4040102@oracle.com> Message-ID: <52D3F59F.1070804@oracle.com> On 01/13/2014 03:13 PM, Alan Bateman wrote: > On 13/01/2014 13:57, Yekaterina Kantserova wrote: >> >> >> Sorry, I've not explained in more details. I have sun/tools tests in >> the same project in Eclipse and there I get a compilation error if I >> have 2 classes with the same name. I've used this standard for >> several fixes, for example sun/tools/jstatd. Do you think it's OK to >> keep these names? > I don't have a strong opinion on the test names, I was just pointing > out that the names duplicates information in directory name. As most > of the tests are in the unnamed package then it will be awkward if you > attempt to being them into the same IDE project. If you do need unique > names then I would go for something like BasicJMapTest and > BasicJStackTest. The names in sun/tools/jstatd look okay because they > test something specific. However, this is all subjective and not > something to spend much time on. Jepp. > > Just another comment on @library, does /lib/testlibrary work? I though > a recent change to jtreg meant that absolute paths works relative to > the test root (which allows tests to move without needing to change > the relative path to the library). > Oh, I'll download the latest jtreg.jar and test again. > -Alan. From alan.bateman at oracle.com Mon Jan 13 08:21:07 2014 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Jan 2014 16:21:07 +0000 Subject: hg: jdk8/tl/jaxws: 8027908: serialVersionUID of javax.xml.bind.TypeConstraintException accidently changed Message-ID: <20140113162119.3F8986240B@hg.openjdk.java.net> Changeset: bd943bdbce05 Author: alanb Date: 2014-01-13 16:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/bd943bdbce05 8027908: serialVersionUID of javax.xml.bind.TypeConstraintException accidently changed Reviewed-by: alanb Contributed-by: iaroslav.savytskyi at oracle.com ! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java From frederic.parain at oracle.com Mon Jan 13 08:40:24 2014 From: frederic.parain at oracle.com (frederic parain) Date: Mon, 13 Jan 2014 17:40:24 +0100 Subject: RFR(S): JDK-8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: <52D3E780.4020507@oracle.com> References: <52D3E780.4020507@oracle.com> Message-ID: <52D416F8.7000305@oracle.com> The code looks good to me (not an official reviewer). However, I'm surprised this command doesn't require the java.lang.management.ManagementPermission("monitor") when invoked from the DiagnosticCommandMBean. Has this topic been discussed during the CCC review or with the security team? Regards, Fred On 13/01/2014 14:17, Fredrik Arvidsson wrote: > Hi > > Please help me review the following small enhancement: > > Webrev: http://cr.openjdk.java.net/~farvidsson/8031304/webrev.00/ > > Jira: https://bugs.openjdk.java.net/browse/JDK-8031304 > > /Fredrik -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From ivan.gerasimov at oracle.com Mon Jan 13 10:18:42 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 13 Jan 2014 22:18:42 +0400 Subject: RFR [8030878] JConsole issues meaningless message if SSL connection fails Message-ID: <52D42E02.8050703@oracle.com> Hello! This is a 7u-dev fix only. The issue doesn't exist in 8 nor in 9. Currently when the Jconsole app fails to establish a secured connection it displays a message box with two lines: ConnectionFailedSSL1 ConnectionFailedSSL2 which have a little sense. The fix is to place the correct lines into the massage.properties file. I also renamed the constants to make their names match those in the later releases. Here's the webrev, please have a chance to review. http://cr.openjdk.java.net/~igerasim/8030878/0/webrev/ Sincerely yours, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140113/03d76a2c/attachment.html From mandy.chung at oracle.com Mon Jan 13 15:15:16 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 13 Jan 2014 15:15:16 -0800 Subject: RFR [8030878] JConsole issues meaningless message if SSL connection fails In-Reply-To: <52D42E02.8050703@oracle.com> References: <52D42E02.8050703@oracle.com> Message-ID: <52D47384.7090002@oracle.com> Looks okay to me. Mandy On 1/13/2014 10:18 AM, Ivan Gerasimov wrote: > Hello! > > This is a 7u-dev fix only. The issue doesn't exist in 8 nor in 9. > > Currently when the Jconsole app fails to establish a secured > connection it displays a message box with two lines: > ConnectionFailedSSL1 > ConnectionFailedSSL2 > which have a little sense. > > The fix is to place the correct lines into the massage.properties file. > I also renamed the constants to make their names match those in the > later releases. > > Here's the webrev, please have a chance to review. > http://cr.openjdk.java.net/~igerasim/8030878/0/webrev/ > > Sincerely yours, > Ivan Gerasimov > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140113/581c96a9/attachment.html From staffan.larsen at oracle.com Mon Jan 13 23:38:33 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Jan 2014 08:38:33 +0100 Subject: RFR [8030878] JConsole issues meaningless message if SSL connection fails In-Reply-To: <52D42E02.8050703@oracle.com> References: <52D42E02.8050703@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 13 jan 2014, at 19:18, Ivan Gerasimov wrote: > Hello! > > This is a 7u-dev fix only. The issue doesn't exist in 8 nor in 9. > > Currently when the Jconsole app fails to establish a secured connection it displays a message box with two lines: > ConnectionFailedSSL1 > ConnectionFailedSSL2 > which have a little sense. > > The fix is to place the correct lines into the massage.properties file. > I also renamed the constants to make their names match those in the later releases. > > Here's the webrev, please have a chance to review. > http://cr.openjdk.java.net/~igerasim/8030878/0/webrev/ > > Sincerely yours, > Ivan Gerasimov > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140114/22b4671c/attachment.html From yekaterina.kantserova at oracle.com Tue Jan 14 00:14:37 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 14 Jan 2014 09:14:37 +0100 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D3F4A3.4040102@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <52D3CEF9.2000307@oracle.com> <52D3E77C.9020609@oracle.com> <52D3EA30.6040806@oracle.com> <52D3F0D8.1040605@oracle.com> <52D3F4A3.4040102@oracle.com> Message-ID: <52D4F1ED.1060806@oracle.com> Hi, Here is a new webrev with fixes from reviews: http://cr.openjdk.java.net/~ykantser/6380601/webrev.01/ 1) tests' names are changed; 2) copyright years are fixed; 3) @library is set to /lib/testlibrary (it works fine; Alan, thanks for pointing it out!) Thanks, Katja From volker.simonis at gmail.com Tue Jan 14 00:40:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 09:40:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests Message-ID: Hi, could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): http://cr.openjdk.java.net/~simonis/webrevs/8031581/ I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): java/net/Inet6Address/B6558853.java java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) java/nio/channels/Selector/RacyDeregister.java sun/security/krb5/auto/Unreachable.java (only on IPv6) Thank you and best regards, Volker Following a detailed description of the various changes: src/share/native/java/util/zip/zip_util.c src/share/native/sun/management/DiagnosticCommandImpl.c - According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. - Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. make/CompileJavaClasses.gmk - Also use PollingWatchService on AIX. make/lib/NioLibraries.gmk src/aix/native/sun/nio/ch/AixNativeThread.c - Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. src/solaris/native/sun/nio/ch/PollArrayWrapper.c src/solaris/native/sun/nio/ch/Net.c src/aix/classes/sun/nio/ch/AixPollPort.java src/aix/native/sun/nio/ch/AixPollPort.c src/aix/native/java/net/aix_close.c - On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. src/share/classes/java/nio/file/CopyMoveHelper.java - As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java - Support "compound text" on AIX in the same way like on other Unix platforms. src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider - Define the correct attach provider for AIX. src/solaris/native/java/net/net_util_md.h src/solaris/native/sun/nio/ch/FileDispatcherImpl.c src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c - AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv()and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. - Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). src/solaris/classes/java/lang/UNIXProcess.java.aix - On AIX the implementation is especially tricky, because the close()system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. src/share/transport/socket/socketTransport.c - On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. - Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. src/solaris/native/java/net/NetworkInterface.c - Set the scope identifier for IPv6 addresses on AIX. src/solaris/native/java/net/net_util_md.c - It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. - Also fixed a comment and removed unused local variables. - Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. src/solaris/native/sun/management/OperatingSystemImpl.c - AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. src/solaris/native/sun/nio/ch/DatagramChannelImpl.c - On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140114/866bb06d/attachment-0001.html From Alan.Bateman at oracle.com Tue Jan 14 01:19:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 09:19:20 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <52D50118.3080000@oracle.com> On 14/01/2014 08:40, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration > into ppc-aix-port/stage-9 and subsequent backporting to > ppc-aix-port/stage): I'd like to review this but I won't have time until later in the week. From an initial look then there are a few things are not pretty (the changes to fix the AIX problems with I/O cancellation in particular) and I suspect that some refactoring is going to be required to handle some of this cleanly. A minor comment is that bug synopsis doesn't really communicate what these changes are about. -Alan. From staffan.larsen at oracle.com Tue Jan 14 01:45:05 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Jan 2014 10:45:05 +0100 Subject: RFR(S): JDK-8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: <52D416F8.7000305@oracle.com> References: <52D3E780.4020507@oracle.com> <52D416F8.7000305@oracle.com> Message-ID: <717C9B55-241A-4E26-A1ED-7B284B691C13@oracle.com> I think "monitor" permission sounds reasonable. Thanks for pointing it out! /Staffan (mobile) > On 13 jan 2014, at 17:40, frederic parain wrote: > > The code looks good to me (not an official reviewer). > > However, I'm surprised this command doesn't > require the java.lang.management.ManagementPermission("monitor") > when invoked from the DiagnosticCommandMBean. > Has this topic been discussed during the CCC review > or with the security team? > > Regards, > > Fred > >> On 13/01/2014 14:17, Fredrik Arvidsson wrote: >> Hi >> >> Please help me review the following small enhancement: >> >> Webrev: http://cr.openjdk.java.net/~farvidsson/8031304/webrev.00/ >> >> Jira: https://bugs.openjdk.java.net/browse/JDK-8031304 >> >> /Fredrik > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From Alan.Bateman at oracle.com Tue Jan 14 01:47:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 09:47:06 +0000 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D4F1ED.1060806@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <52D3CEF9.2000307@oracle.com> <52D3E77C.9020609@oracle.com> <52D3EA30.6040806@oracle.com> <52D3F0D8.1040605@oracle.com> <52D3F4A3.4040102@oracle.com> <52D4F1ED.1060806@oracle.com> Message-ID: <52D5079A.1080505@oracle.com> On 14/01/2014 08:14, Yekaterina Kantserova wrote: > Hi, > > Here is a new webrev with fixes from reviews: > http://cr.openjdk.java.net/~ykantser/6380601/webrev.01/ > > 1) tests' names are changed; > 2) copyright years are fixed; > 3) @library is set to /lib/testlibrary (it works fine; Alan, thanks > for pointing it out!) These changes looks good to me, I assume Staffan or someone in the serviceability area will sponsor this. -Alan. From volker.simonis at gmail.com Tue Jan 14 01:56:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 10:56:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D50118.3080000@oracle.com> References: <52D50118.3080000@oracle.com> Message-ID: Hi Alan, On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> > > I'd like to review this but I won't have time until later in the week. Thanks, that would be great. > From an initial look then there are a few things are not pretty (the > changes to fix the AIX problems with I/O cancellation in particular) and I > suspect that some refactoring is going to be required to handle some of > this cleanly. I agree, but as I wrote, this change is intended to finally go into both jdk9 and jkd8u and I didn't wanted to do to much refactoring for jdk8u. Once its in and we have a working port I'd be happy to work on refactoring the code but I think this should be done in jdk9 where we have more time and less risks of changing the behaviour on the existing platforms. > A minor comment is that bug synopsis doesn't really communicate what these > changes are about. > > This is the last "bulk change" which address issues in several different areas of the class library. Follow up changes will be more specific with better bug synopsis (I promise :). Regards, Volker > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140114/0f098ab3/attachment.html From jaroslav.bachorik at oracle.com Tue Jan 14 02:02:17 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Jan 2014 11:02:17 +0100 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D5079A.1080505@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <52D3CEF9.2000307@oracle.com> <52D3E77C.9020609@oracle.com> <52D3EA30.6040806@oracle.com> <52D3F0D8.1040605@oracle.com> <52D3F4A3.4040102@oracle.com> <52D4F1ED.1060806@oracle.com> <52D5079A.1080505@oracle.com> Message-ID: <52D50B29.6060708@oracle.com> On 14.1.2014 10:47, Alan Bateman wrote: > On 14/01/2014 08:14, Yekaterina Kantserova wrote: >> Hi, >> >> Here is a new webrev with fixes from reviews: >> http://cr.openjdk.java.net/~ykantser/6380601/webrev.01/ >> >> 1) tests' names are changed; >> 2) copyright years are fixed; >> 3) @library is set to /lib/testlibrary (it works fine; Alan, thanks >> for pointing it out!) > These changes looks good to me, I assume Staffan or someone in the > serviceability area will sponsor this. Looks good. I can sponsor the push. -JB- > > -Alan. From yekaterina.kantserova at oracle.com Tue Jan 14 02:11:26 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 14 Jan 2014 11:11:26 +0100 Subject: RFR (S): 6380601: MISC_REGRESSION tests need to be more resilient to ps cmd problems In-Reply-To: <52D50B29.6060708@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D3C285.70301@oracle.com> <52D3CEF9.2000307@oracle.com> <52D3E77C.9020609@oracle.com> <52D3EA30.6040806@oracle.com> <52D3F0D8.1040605@oracle.com> <52D3F4A3.4040102@oracle.com> <52D4F1ED.1060806@oracle.com> <52D5079A.1080505@oracle.com> <52D50B29.6060708@oracle.com> Message-ID: <52D50D4E.1010907@oracle.com> Alan, Jaroslav, thanks! Jaroslav, I've attached the paths to the mail. // Katja On 01/14/2014 11:02 AM, Jaroslav Bachorik wrote: > On 14.1.2014 10:47, Alan Bateman wrote: >> On 14/01/2014 08:14, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Here is a new webrev with fixes from reviews: >>> http://cr.openjdk.java.net/~ykantser/6380601/webrev.01/ >>> >>> 1) tests' names are changed; >>> 2) copyright years are fixed; >>> 3) @library is set to /lib/testlibrary (it works fine; Alan, thanks >>> for pointing it out!) >> These changes looks good to me, I assume Staffan or someone in the >> serviceability area will sponsor this. > > Looks good. I can sponsor the push. > > -JB- > >> >> -Alan. > -------------- next part -------------- A non-text attachment was scrubbed... Name: 6380601.3.patch Type: text/x-patch Size: 11602 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140114/b68cb855/6380601.3-0001.patch From fredrik.arvidsson at oracle.com Tue Jan 14 02:21:50 2014 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Tue, 14 Jan 2014 11:21:50 +0100 Subject: RFR(S): JDK-8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: <52D416F8.7000305@oracle.com> References: <52D3E780.4020507@oracle.com> <52D416F8.7000305@oracle.com> Message-ID: <52D50FBE.70607@oracle.com> Hi Frederic Well spotted, I will add 'monitor' permission restrictions to this dcmd. Thanks /F On 2014-01-13 17:40, frederic parain wrote: > The code looks good to me (not an official reviewer). > > However, I'm surprised this command doesn't > require the java.lang.management.ManagementPermission("monitor") > when invoked from the DiagnosticCommandMBean. > Has this topic been discussed during the CCC review > or with the security team? > > Regards, > > Fred > > On 13/01/2014 14:17, Fredrik Arvidsson wrote: >> Hi >> >> Please help me review the following small enhancement: >> >> Webrev: http://cr.openjdk.java.net/~farvidsson/8031304/webrev.00/ >> >> Jira: https://bugs.openjdk.java.net/browse/JDK-8031304 >> >> /Fredrik > From jaroslav.bachorik at oracle.com Tue Jan 14 03:10:08 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Jan 2014 12:10:08 +0100 Subject: RFR (S): 7185591: jcmd-big-script.sh ERROR: could not find app's Java pid. In-Reply-To: References: <52CFEC7F.4040207@oracle.com> Message-ID: <52D51B10.4040309@oracle.com> On 13.1.2014 13:19, Staffan Larsen wrote: > Katja, > > test/lib/testlibrary/jdk/testlibrary/JcmdBase.java > 68 * Run jcmd standalone > > I think you should expand a bit on what ?standalone? means here. It took me a while to understand the difference. Perhaps renaming jcmd(...) to jcmdSelf(...) and jcmdStandalone(...) to jcmd(...) would better communicate the desired functionality? Anyway a proper javadoc will be needed for the both of them. -JB- > > test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java > 423 public int indexOf(String pattern) { > > This seems very inefficient. Add all lines to an ArrayList and then walk through them one at a time to if it matches and then walk through them once again to find the index of that line. > > 469 public int shouldMatchByLine(String from, String to, String pattern) { > > Same inefficiency here, but worse because both asLines() and indexOf() does the same work. > > test/lib/testlibrary/jdk/testlibrary/Utils.java > 65 public static final String TEST_SRC = System.getProperty("test.src").trim(); > > I wonder if this really works. Isn?t ?test.src? different for different tests? A property that jtreg changes before invoking each test? Or does this work because each test is run in a different class loader and Utils.java will exist once in each class loader? > > > /Staffan > > > On 10 jan 2014, at 13:50, Yekaterina Kantserova wrote: > >> Hi, >> >> Could I please have a review of this fix. >> >> In this fix I've rewritten sun/tools/jcmd/* tests in pure java to get rid of all intermittent failures depending on for example MKS or race conditions (test application has not yet started when the test start to run). >> >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/7185591/webrev.00/ >> >> Primal bug: >> https://bugs.openjdk.java.net/browse/JDK-7185591 >> >> Similar bugs: >> https://bugs.openjdk.java.net/browse/JDK-6977426 >> https://bugs.openjdk.java.net/browse/JDK-8020798 >> https://bugs.openjdk.java.net/browse/JDK-7130656 (this one is blocked by https://bugs.openjdk.java.net/browse/JDK-8031482 so far) >> >> Thanks, >> Katja > From jaroslav.bachorik at oracle.com Tue Jan 14 03:25:37 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Jan 2014 12:25:37 +0100 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52CEA5AB.7040900@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CEA5AB.7040900@oracle.com> Message-ID: <52D51EB1.2040908@oracle.com> Please, could I have a review of this change? It really is pretty simple and won't take much time to review. Thanks, -JB- On 9.1.2014 14:35, Jaroslav Bachorik wrote: > Hi, > > thanks do David and Staffan it was possible to pinpoint the contention > to the static initializaton and classloading. > > David suggested running the test routine twice to exercise any > initialization during the first run and performs the checks only for the > results of the second run. > > The test is using Phaser for synchronization. All the potentially > blocking code (System.out.println(), Thread.currentThread(), etc.) was > removed from the tested thread. > > The webrev is available at > http://cr.openjdk.java.net/~jbachorik/8030847/webrev.01 > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Tue Jan 14 03:27:32 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Jan 2014 12:27:32 +0100 Subject: jmx-dev [ping] Re: RFR 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <52B03858.7040409@oracle.com> References: <52862EDC.4080703@oracle.com> <52B03858.7040409@oracle.com> Message-ID: <52D51F24.7000904@oracle.com> Ok, trying again. Could anyone, please, spare some time to review this test stabilization fix? Thanks! -JB- On 17.12.2013 12:41, Jaroslav Bachorik wrote: > Anyone? > > -JB- > > On 15.11.2013 15:25, Jaroslav Bachorik wrote: >> Please, review this test fix. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8022221 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00 >> >> The test was facing intermittent failures due to not 100% failproof >> interprocess synchronization using lock files. The solution is rewriting >> the shell test to pure Java and use stdout/stderr processing for the >> application started by the test to assess its status. >> >> A part of the change is also few improvements to the >> jdk.testlibrary.ProcessTools. >> >> Thanks, >> >> -JB- > From david.holmes at oracle.com Tue Jan 14 03:29:48 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jan 2014 21:29:48 +1000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <52D51FAC.8060800@oracle.com> Just a note on this part (I havent looked at the code): > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. Sounds like this should be handled the same way that the other "system constants" are handled - you can either store a platform file in the repo (for cross-compiling) or you generate the class containing the constants at build time. David On 14/01/2014 6:40 PM, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration into > ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: > Updated jdk/test scripts to understand the AIX os and environment" and > "8031134 : PPC64: implement printing on AIX") our port passes all but > the following 7 jtreg regression tests on AIX (compared to the > Linux/x86_64 baseline from > www.java.net/download/jdk8/testresults/testresults.html > ?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > > > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > * According to ISO C it is perfectly legal for malloc to return zero > if called with a zero argument. Fix various places where malloc can > potentially correctly return zero because it was called with a zero > argument. > * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. This > only fixes a compiler warning on Linux, but on AIX it prevents a VM > crash later on because the return value of |malloc()| will be casted > to |int| which is especially bad if that pointer was bigger than > 32-bit. > > > make/CompileJavaClasses.gmk > > * Also use |PollingWatchService| on AIX. > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > * Put the implementation for the native methods of |NativeThread| into > |AixNativeThread.c| on AIX. > > > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > * On AIX, the constants used for the polling events (i.e. |POLLIN|, > |POLLOUT|, ...) are defined to different values than on other > operating systems. The problem is however, that these constants are > hardcoded as public final static members of various, shared Java > classes. We therefore have to map them from Java to native every > time before calling one of the native poll functions and back to > Java after the call on AIX in order to get the right semantics. > > > src/share/classes/java/nio/file/CopyMoveHelper.java > > * As discussed on the core-libs mailing list (see > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > it is not necessary to call |Files.getFileAttributeView()| with any > |linkOptions| because at that place we've already checked that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support symbolic links > but do not support the |O_NOFOLLOW| flag to the |open| system call. > It also makes the JDK pass the |demo/zipfs/basic.sh| test on AIX. > > > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > * Support "compound text" on AIX in the same way like on other Unix > platforms. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > * Define the correct attach provider for AIX. > > > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > * AIX needs a workaround for I/O cancellation (see: > http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > "..The |close()| subroutine is blocked until all subroutines which > use the file descriptor return to usr space. For example, when a > thread is calling close and another thread is calling select with > the same file descriptor, the close subroutine does not return until > the select call returns...". To fix this problem, we have to use the > various |NET_| wrappers which are declared in |net_util_md.h| and > defined in |aix_close.c| and we also need some additional wrappers > for |fcntl()|, |read()| and |write()| on AIX. > While the current solution isn't really nice because it introduces > some more AIX-specifc sections in shared code, I think it is the > best way to go for JDK 8 because it imposes the smallest possible > changes and risks for the existing platforms. I'm ready to change > the code to unconditionally use the wrappers for all platforms and > implement the wrappers empty on platforms which don't need any > wrapping. I think it would also be nice to clean up the names (e.g. > |NET_Read()| is currently a wrapper for |recv()| and the |NET_| > prefix is probably not appropriate any more so maybe change it to > something like |IO_|). But again, I'll prefer to keep that as a > follow up change for JDK9. > * Calling |fsync()| on a "read-only" file descriptor on AIX will > result in an error (i.e. "EBADF: The FileDescriptor parameter is not > a valid file descriptor open for writing."). To prevent this error > we have to query if the corresponding file descriptor is writeable. > Notice that at that point we can not access the |writable| attribute > of the corresponding file channel so we have to use |fcntl()|. > > > src/solaris/classes/java/lang/UNIXProcess.java.aix > > * On AIX the implementation is especially tricky, because the > |close()| system call will block if another thread is at the same > time blocked in a file operation (e.g. 'read()') on the same file > descriptor. We therefore combine the AIX |ProcessPipeInputStream| > implemenatation with the |DeferredCloseInputStream| approach used on > Solaris (see |UNIXProcess.java.solaris|). This means that every > potentially blocking operation on the file descriptor increments a > counter before it is executed and decrements it once it finishes. > The 'close()' operation will only be executed if there are no > pending operations. Otherwise it is deferred after the last pending > operation has finished. > > > src/share/transport/socket/socketTransport.c > > * On AIX we have to call |shutdown()| on a socket descriptor before > closing it, otherwise the |close()| call may be blocked. This is the > same problem as described before. Unfortunately the JDI framework > doesn't use the same IO wrappers like other class library components > so we can not easily use the |NET_| abstractions from |aix_close.c| > here. > * Without this small change all JDI regression tests will fail on AIX > because of the way how the tests act as a "debugger" which launches > another VM (the "debugge") which connects itself back to the > debugger. In this scenario the "debugge" can not shut down itself > because one thread will always be blocked in the |close()| call on > one of the communication sockets. > > > src/solaris/native/java/net/NetworkInterface.c > > * Set the scope identifier for IPv6 addresses on AIX. > > > src/solaris/native/java/net/net_util_md.c > > * It turns out that we do not always have to replace |SO_REUSEADDR| on > AIX by |SO_REUSEPORT|. Instead we can simply use the same approach > like BSD and only use |SO_REUSEPORT| additionally, if several > datagram sockets try to bind to the same port. > * Also fixed a comment and removed unused local variables. > * Fixed the obviously inverted assignment |newTime = prevTime;| which > should read |prevTime = newTime;|. Otherwise |prevTime| will never > change and the timeout will be potential reached too fast. > > > src/solaris/native/sun/management/OperatingSystemImpl.c > > * AIX does not understand |/proc/self| so we have to query the real > process ID to access the proc file system. > > > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > * On AIX, |connect()| may legally return |EAFNOSUPPORT| if called on a > socket with the address family set to |AF_UNSPEC|. > > From david.holmes at oracle.com Tue Jan 14 03:38:40 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jan 2014 21:38:40 +1000 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52D51EB1.2040908@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CEA5AB.7040900@oracle.com> <52D51EB1.2040908@oracle.com> Message-ID: <52D521C0.50000@oracle.com> On 14/01/2014 9:25 PM, Jaroslav Bachorik wrote: > Please, could I have a review of this change? > > It really is pretty simple and won't take much time to review. Sorry this slipped past me :) Changes look fine. Could you just expand on this comment: 55 // warmup to say: // warmup - ensure all classes loaded and initialized etc to // avoid unintended locking and blocking in the VM Thanks, David > Thanks, > > -JB- > > On 9.1.2014 14:35, Jaroslav Bachorik wrote: >> Hi, >> >> thanks do David and Staffan it was possible to pinpoint the contention >> to the static initializaton and classloading. >> >> David suggested running the test routine twice to exercise any >> initialization during the first run and performs the checks only for the >> results of the second run. >> >> The test is using Phaser for synchronization. All the potentially >> blocking code (System.out.println(), Thread.currentThread(), etc.) was >> removed from the tested thread. >> >> The webrev is available at >> http://cr.openjdk.java.net/~jbachorik/8030847/webrev.01 >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Tue Jan 14 03:53:41 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Jan 2014 12:53:41 +0100 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52D521C0.50000@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CEA5AB.7040900@oracle.com> <52D51EB1.2040908@oracle.com> <52D521C0.50000@oracle.com> Message-ID: <13BE0CE4-1CE9-4820-92F3-C5E7B8A9E2DF@oracle.com> +1 On 14 jan 2014, at 12:38, David Holmes wrote: > On 14/01/2014 9:25 PM, Jaroslav Bachorik wrote: >> Please, could I have a review of this change? >> >> It really is pretty simple and won't take much time to review. > > Sorry this slipped past me :) > > Changes look fine. Could you just expand on this comment: > > 55 // warmup > > to say: > > // warmup - ensure all classes loaded and initialized etc to > // avoid unintended locking and blocking in the VM > > Thanks, > David > >> Thanks, >> >> -JB- >> >> On 9.1.2014 14:35, Jaroslav Bachorik wrote: >>> Hi, >>> >>> thanks do David and Staffan it was possible to pinpoint the contention >>> to the static initializaton and classloading. >>> >>> David suggested running the test routine twice to exercise any >>> initialization during the first run and performs the checks only for the >>> results of the second run. >>> >>> The test is using Phaser for synchronization. All the potentially >>> blocking code (System.out.println(), Thread.currentThread(), etc.) was >>> removed from the tested thread. >>> >>> The webrev is available at >>> http://cr.openjdk.java.net/~jbachorik/8030847/webrev.01 >>> >>> Thanks, >>> >>> -JB- >> From jaroslav.bachorik at oracle.com Tue Jan 14 03:54:43 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Jan 2014 12:54:43 +0100 Subject: RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again In-Reply-To: <52D521C0.50000@oracle.com> References: <52B82FBC.3080704@oracle.com> <52CEA5AB.7040900@oracle.com> <52D51EB1.2040908@oracle.com> <52D521C0.50000@oracle.com> Message-ID: <52D52583.5050807@oracle.com> On 14.1.2014 12:38, David Holmes wrote: > On 14/01/2014 9:25 PM, Jaroslav Bachorik wrote: >> Please, could I have a review of this change? >> >> It really is pretty simple and won't take much time to review. > > Sorry this slipped past me :) > > Changes look fine. Could you just expand on this comment: > > 55 // warmup > > to say: > > // warmup - ensure all classes loaded and initialized etc to > // avoid unintended locking and blocking in the VM Will do! -JB- > > Thanks, > David > >> Thanks, >> >> -JB- >> >> On 9.1.2014 14:35, Jaroslav Bachorik wrote: >>> Hi, >>> >>> thanks do David and Staffan it was possible to pinpoint the contention >>> to the static initializaton and classloading. >>> >>> David suggested running the test routine twice to exercise any >>> initialization during the first run and performs the checks only for the >>> results of the second run. >>> >>> The test is using Phaser for synchronization. All the potentially >>> blocking code (System.out.println(), Thread.currentThread(), etc.) was >>> removed from the tested thread. >>> >>> The webrev is available at >>> http://cr.openjdk.java.net/~jbachorik/8030847/webrev.01 >>> >>> Thanks, >>> >>> -JB- >> From staffan.larsen at oracle.com Tue Jan 14 04:13:07 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Jan 2014 13:13:07 +0100 Subject: jmx-dev [ping] Re: RFR 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <52D51F24.7000904@oracle.com> References: <52862EDC.4080703@oracle.com> <52B03858.7040409@oracle.com> <52D51F24.7000904@oracle.com> Message-ID: JMXStartStopTest.java:162 I see no path that calls testConnect with port == -1, so can we we remove the setting of port to 4567? I don?t like that hardcoded port, and I don?t see it being used. Other than that I think it looks good. /Staffan On 14 jan 2014, at 12:27, Jaroslav Bachorik wrote: > Ok, trying again. Could anyone, please, spare some time to review this test stabilization fix? > > Thanks! > > -JB- > > On 17.12.2013 12:41, Jaroslav Bachorik wrote: >> Anyone? >> >> -JB- >> >> On 15.11.2013 15:25, Jaroslav Bachorik wrote: >>> Please, review this test fix. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8022221 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00 >>> >>> The test was facing intermittent failures due to not 100% failproof >>> interprocess synchronization using lock files. The solution is rewriting >>> the shell test to pure Java and use stdout/stderr processing for the >>> application started by the test to assess its status. >>> >>> A part of the change is also few improvements to the >>> jdk.testlibrary.ProcessTools. >>> >>> Thanks, >>> >>> -JB- >> > From fredrik.arvidsson at oracle.com Tue Jan 14 04:51:59 2014 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Tue, 14 Jan 2014 13:51:59 +0100 Subject: RFR(S): JDK-8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: <52D3E780.4020507@oracle.com> References: <52D3E780.4020507@oracle.com> Message-ID: <52D532EF.2090304@oracle.com> Hi Added 'monitor' permission to VM.dynlibs and changed test code so it works on all platforms... Changed some formatting. Updated webrev here: http://cr.openjdk.java.net/~farvidsson/8031304/webrev.02/ Thanks /F On 2014-01-13 14:17, Fredrik Arvidsson wrote: > Hi > > Please help me review the following small enhancement: > > Webrev: http://cr.openjdk.java.net/~farvidsson/8031304/webrev.00/ > > Jira: https://bugs.openjdk.java.net/browse/JDK-8031304 > > /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140114/c8be414c/attachment.html From jaroslav.bachorik at oracle.com Tue Jan 14 05:13:40 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Jan 2014 14:13:40 +0100 Subject: jmx-dev [ping] Re: RFR 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: References: <52862EDC.4080703@oracle.com> <52B03858.7040409@oracle.com> <52D51F24.7000904@oracle.com> Message-ID: <52D53804.8000505@oracle.com> Thanks, Staffan! On 14.1.2014 13:13, Staffan Larsen wrote: > JMXStartStopTest.java:162 > I see no path that calls testConnect with port == -1, so can we we remove the setting of port to 4567? I don?t like that hardcoded port, and I don?t see it being used. I've removed the port setting magic - now the testConnect(...) needs to be called with the requested port number. Also, there are some minor changes in the webrev due to merging. Updated webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.01 Cheers, -JB- > > Other than that I think it looks good. > > /Staffan > > On 14 jan 2014, at 12:27, Jaroslav Bachorik wrote: > >> Ok, trying again. Could anyone, please, spare some time to review this test stabilization fix? >> >> Thanks! >> >> -JB- >> >> On 17.12.2013 12:41, Jaroslav Bachorik wrote: >>> Anyone? >>> >>> -JB- >>> >>> On 15.11.2013 15:25, Jaroslav Bachorik wrote: >>>> Please, review this test fix. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8022221 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00 >>>> >>>> The test was facing intermittent failures due to not 100% failproof >>>> interprocess synchronization using lock files. The solution is rewriting >>>> the shell test to pure Java and use stdout/stderr processing for the >>>> application started by the test to assess its status. >>>> >>>> A part of the change is also few improvements to the >>>> jdk.testlibrary.ProcessTools. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From staffan.larsen at oracle.com Tue Jan 14 05:24:38 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Jan 2014 14:24:38 +0100 Subject: RFR(S): JDK-8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: <52D532EF.2090304@oracle.com> References: <52D3E780.4020507@oracle.com> <52D532EF.2090304@oracle.com> Message-ID: <72EB357F-C6CB-47F9-A5BF-878AEDF29EC0@oracle.com> Looks good! Thanks, /Staffan On 14 jan 2014, at 13:51, Fredrik Arvidsson wrote: > Hi > Added 'monitor' permission to VM.dynlibs and changed test code so it works on all platforms... Changed some formatting. > > Updated webrev here: http://cr.openjdk.java.net/~farvidsson/8031304/webrev.02/ > > Thanks > /F > > On 2014-01-13 14:17, Fredrik Arvidsson wrote: >> Hi >> >> Please help me review the following small enhancement: >> >> Webrev: http://cr.openjdk.java.net/~farvidsson/8031304/webrev.00/ >> Jira: https://bugs.openjdk.java.net/browse/JDK-8031304 >> >> /Fredrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140114/fe226369/attachment.html From markus.gronlund at oracle.com Tue Jan 14 05:29:36 2014 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 14 Jan 2014 05:29:36 -0800 (PST) Subject: RFR(S): JDK-8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: <52D532EF.2090304@oracle.com> References: <52D3E780.4020507@oracle.com> <52D532EF.2090304@oracle.com> Message-ID: <75cb4f9b-a661-4b87-875a-e07c2bac0a94@default> Looks good Fredrik! /Markus From: Fredrik Arvidsson Sent: den 14 januari 2014 13:52 To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: RFR(S): JDK-8031304 : Add dcmd to print all loaded dynamic libraries Hi Added 'monitor' permission to VM.dynlibs and changed test code so it works on all platforms... Changed some formatting. Updated webrev here: HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/8031304/webrev.02/"http://cr.openjdk.java.net/~farvidsson/8031304/webrev.02/ Thanks /F On 2014-01-13 14:17, Fredrik Arvidsson wrote: Hi Please help me review the following small enhancement: Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/8031304/webrev.00/"http://cr.openjdk.java.net/~farvidsson/8031304/webrev.00/ Jira: https://bugs.openjdk.java.net/browse/JDK-8031304 /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140114/64ca3a06/attachment-0001.html From frederic.parain at oracle.com Tue Jan 14 05:31:51 2014 From: frederic.parain at oracle.com (frederic parain) Date: Tue, 14 Jan 2014 14:31:51 +0100 Subject: RFR(S): JDK-8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: <52D532EF.2090304@oracle.com> References: <52D3E780.4020507@oracle.com> <52D532EF.2090304@oracle.com> Message-ID: <52D53C47.6030303@oracle.com> Looks good to me. Fred On 14/01/2014 13:51, Fredrik Arvidsson wrote: > Hi > Added 'monitor' permission to VM.dynlibs and changed test code so it > works on all platforms... Changed some formatting. > > Updated webrev here: > http://cr.openjdk.java.net/~farvidsson/8031304/webrev.02/ > > > Thanks > /F > > On 2014-01-13 14:17, Fredrik Arvidsson wrote: >> Hi >> >> Please help me review the following small enhancement: >> >> Webrev: http://cr.openjdk.java.net/~farvidsson/8031304/webrev.00/ >> >> Jira: https://bugs.openjdk.java.net/browse/JDK-8031304 >> >> /Fredrik > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From Alan.Bateman at oracle.com Tue Jan 14 05:48:42 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 13:48:42 +0000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52D53054.9080908@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52D385D1.9020604@oracle.com> <52D4A34C.8070502@oracle.com> <52D53054.9080908@oracle.com> Message-ID: <52D5403A.10608@oracle.com> On 14/01/2014 12:40, Tristan Yan wrote: > Okay. But I think we all agree we should at least bring this test back > for further tacking. > > http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.06/ > This make sense so I think this should be pushed. If JDK-7027502 is used for this then the synopsis should be changed as it would otherwise not reflect the fact that this is not fixing the issue, rather just liberating the test with some additional output to help in the event that it fails in the future. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140114/15ea2c39/attachment.html From tristan.yan at oracle.com Tue Jan 14 05:57:45 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 14 Jan 2014 21:57:45 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52D5403A.10608@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52D385D1.9020604@oracle.com> <52D4A34C.8070502@oracle.com> <52D53054.9080908@oracle.com> <52D5403A.10608@oracle.com> Message-ID: <52D54259.6000509@oracle.com> Thank you Alan. I have changed this bug's synopsis. Is it okay you could push this? Tristan On 01/14/2014 09:48 PM, Alan Bateman wrote: > On 14/01/2014 12:40, Tristan Yan wrote: >> Okay. But I think we all agree we should at least bring this test >> back for further tacking. >> >> http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.06/ >> > This make sense so I think this should be pushed. If JDK-7027502 is > used for this then the synopsis should be changed as it would > otherwise not reflect the fact that this is not fixing the issue, > rather just liberating the test with some additional output to help in > the event that it fails in the future. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140114/a80b9532/attachment.html From volker.simonis at gmail.com Tue Jan 14 06:10:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 15:10:27 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D51FAC.8060800@oracle.com> References: <52D51FAC.8060800@oracle.com> Message-ID: On Tue, Jan 14, 2014 at 12:29 PM, David Holmes wrote: > Just a note on this part (I havent looked at the code): > > > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >> ...) are defined to different values than on other operating systems. The >> problem is however, that these constants are hardcoded as public final >> static members of various, shared Java classes. >> > > Sounds like this should be handled the same way that the other "system > constants" are handled - you can either store a platform file in the repo > (for cross-compiling) or you generate the class containing the constants at > build time. > > Hi David, thanks for your comments. That sound like a good idea but I'm not sure if it would make sense to duplicate the following files: src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java: src/solaris/classes/sun/nio/ch/Port.java because of this. Do you have a concrete example where Java-classes are being generated with different constants in the class library build? Both solutions would result in different class files on Aix and other Unix variants. What do you think about assigning the concrete values depending on 'os.name' in the static initializers of the corresponding classes? I think that shouldn't introduce too much overhead and I could get rid of all the ugly conversion code. Regards, Volker > David > > > On 14/01/2014 6:40 PM, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and >> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: >> Updated jdk/test scripts to understand the AIX os and environment" and >> "8031134 : PPC64: implement printing on AIX") our port passes all but >> the following 7 jtreg regression tests on AIX (compared to the >> Linux/x86_64 baseline from >> www.java.net/download/jdk8/testresults/testresults.html >> ?): >> >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> >> >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> * According to ISO C it is perfectly legal for malloc to return zero >> >> if called with a zero argument. Fix various places where malloc can >> potentially correctly return zero because it was called with a zero >> argument. >> * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. This >> >> only fixes a compiler warning on Linux, but on AIX it prevents a VM >> crash later on because the return value of |malloc()| will be casted >> to |int| which is especially bad if that pointer was bigger than >> 32-bit. >> >> >> make/CompileJavaClasses.gmk >> >> * Also use |PollingWatchService| on AIX. >> >> >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> * Put the implementation for the native methods of |NativeThread| into >> >> |AixNativeThread.c| on AIX. >> >> >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> * On AIX, the constants used for the polling events (i.e. |POLLIN|, >> |POLLOUT|, ...) are defined to different values than on other >> >> operating systems. The problem is however, that these constants are >> hardcoded as public final static members of various, shared Java >> classes. We therefore have to map them from Java to native every >> time before calling one of the native poll functions and back to >> Java after the call on AIX in order to get the right semantics. >> >> >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> * As discussed on the core-libs mailing list (see >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013- >> December/024119.html) >> it is not necessary to call |Files.getFileAttributeView()| with any >> |linkOptions| because at that place we've already checked that the >> target file can not be a symbolic link. This change makes the >> implementation more robust on platforms which support symbolic links >> but do not support the |O_NOFOLLOW| flag to the |open| system call. >> It also makes the JDK pass the |demo/zipfs/basic.sh| test on AIX. >> >> >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> * Support "compound text" on AIX in the same way like on other Unix >> platforms. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com. >> sun.tools.attach.spi.AttachProvider >> >> * Define the correct attach provider for AIX. >> >> >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> * AIX needs a workaround for I/O cancellation (see: >> >> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index. >> jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >> "..The |close()| subroutine is blocked until all subroutines which >> use the file descriptor return to usr space. For example, when a >> thread is calling close and another thread is calling select with >> the same file descriptor, the close subroutine does not return until >> the select call returns...". To fix this problem, we have to use the >> various |NET_| wrappers which are declared in |net_util_md.h| and >> defined in |aix_close.c| and we also need some additional wrappers >> for |fcntl()|, |read()| and |write()| on AIX. >> >> While the current solution isn't really nice because it introduces >> some more AIX-specifc sections in shared code, I think it is the >> best way to go for JDK 8 because it imposes the smallest possible >> changes and risks for the existing platforms. I'm ready to change >> the code to unconditionally use the wrappers for all platforms and >> implement the wrappers empty on platforms which don't need any >> wrapping. I think it would also be nice to clean up the names (e.g. >> |NET_Read()| is currently a wrapper for |recv()| and the |NET_| >> prefix is probably not appropriate any more so maybe change it to >> something like |IO_|). But again, I'll prefer to keep that as a >> >> follow up change for JDK9. >> * Calling |fsync()| on a "read-only" file descriptor on AIX will >> >> result in an error (i.e. "EBADF: The FileDescriptor parameter is not >> a valid file descriptor open for writing."). To prevent this error >> we have to query if the corresponding file descriptor is writeable. >> Notice that at that point we can not access the |writable| attribute >> of the corresponding file channel so we have to use |fcntl()|. >> >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> * On AIX the implementation is especially tricky, because the >> >> |close()| system call will block if another thread is at the same >> time blocked in a file operation (e.g. 'read()') on the same file >> descriptor. We therefore combine the AIX |ProcessPipeInputStream| >> implemenatation with the |DeferredCloseInputStream| approach used on >> Solaris (see |UNIXProcess.java.solaris|). This means that every >> >> potentially blocking operation on the file descriptor increments a >> counter before it is executed and decrements it once it finishes. >> The 'close()' operation will only be executed if there are no >> pending operations. Otherwise it is deferred after the last pending >> operation has finished. >> >> >> src/share/transport/socket/socketTransport.c >> >> * On AIX we have to call |shutdown()| on a socket descriptor before >> >> closing it, otherwise the |close()| call may be blocked. This is the >> same problem as described before. Unfortunately the JDI framework >> doesn't use the same IO wrappers like other class library components >> so we can not easily use the |NET_| abstractions from |aix_close.c| >> here. >> * Without this small change all JDI regression tests will fail on AIX >> >> because of the way how the tests act as a "debugger" which launches >> another VM (the "debugge") which connects itself back to the >> debugger. In this scenario the "debugge" can not shut down itself >> because one thread will always be blocked in the |close()| call on >> one of the communication sockets. >> >> >> src/solaris/native/java/net/NetworkInterface.c >> >> * Set the scope identifier for IPv6 addresses on AIX. >> >> >> src/solaris/native/java/net/net_util_md.c >> >> * It turns out that we do not always have to replace |SO_REUSEADDR| on >> AIX by |SO_REUSEPORT|. Instead we can simply use the same approach >> >> like BSD and only use |SO_REUSEPORT| additionally, if several >> datagram sockets try to bind to the same port. >> * Also fixed a comment and removed unused local variables. >> * Fixed the obviously inverted assignment |newTime = prevTime;| which >> >> should read |prevTime = newTime;|. Otherwise |prevTime| will never >> change and the timeout will be potential reached too fast. >> >> >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> * AIX does not understand |/proc/self| so we have to query the real >> >> process ID to access the proc file system. >> >> >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> * On AIX, |connect()| may legally return |EAFNOSUPPORT| if called on a >> >> socket with the address family set to |AF_UNSPEC|. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140114/e6f3ed73/attachment-0001.html From alexander.zuev at oracle.com Tue Jan 14 11:17:52 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:17:52 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20140114191752.B1DC66242B@hg.openjdk.java.net> Changeset: ff1478785e43 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ff1478785e43 Added tag jdk8-b122 for changeset 347009c58816 ! .hgtags Changeset: c330fa67c4da Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c330fa67c4da Added tag jdk8-b123 for changeset ff1478785e43 ! .hgtags Changeset: fd869d9f3ca7 Author: kizune Date: 2014-01-14 23:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fd869d9f3ca7 Merge From alexander.zuev at oracle.com Tue Jan 14 11:18:03 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:18:03 +0000 Subject: hg: jdk8/tl/corba: 10 new changesets Message-ID: <20140114191809.3B0F76242C@hg.openjdk.java.net> Changeset: 98a5caae1990 Author: chegar Date: 2013-11-03 07:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/98a5caae1990 Merge Changeset: 880514b576d5 Author: msheppar Date: 2013-11-12 17:56 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/880514b576d5 8026193: Enhance CORBA stub factories Summary: modify com.sun.corba.se.impl.presenetation.rmi.StubFactoryDynamicBase inheritance structure. Reviewed-by: alanb, coffeys, ahgross ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryFactoryProxyImpl.java Changeset: b083590cb088 Author: msheppar Date: 2013-11-12 18:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b083590cb088 8025767: Enhance IIOP Streams Summary: modify org.omg.CORBA_2_3.portable.InputStream inheritance structure. Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/EncapsInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/EncapsOutputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/TypeCodeInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/TypeCodeOutputStream.java ! src/share/classes/com/sun/corba/se/impl/interceptors/CDREncapsCodec.java ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java ! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/ior/iiop/IIOPProfileImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/SharedCDRClientRequestDispatcherImpl.java ! src/share/classes/com/sun/corba/se/impl/resolver/INSURLOperationImpl.java ! src/share/classes/com/sun/corba/se/spi/servicecontext/ServiceContexts.java ! src/share/classes/org/omg/CORBA_2_3/portable/InputStream.java + src/share/classes/sun/corba/EncapsInputStreamFactory.java Changeset: 6b9b31f2298b Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6b9b31f2298b Merge Changeset: d05c64360b6c Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d05c64360b6c Merge - make/com/Makefile - make/com/sun/Makefile - make/com/sun/corba/Makefile - make/com/sun/corba/minclude/com_sun_corba_se_PortableActivationIDL.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_activation.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_corba.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_core.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_dynamicany.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_encoding.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_interceptors.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_io.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_ior.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_legacy.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_logging.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_monitoring.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_cosnaming.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_namingutil.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_pcosnaming.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_oa_poa.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_oa_toa.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_orb.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_presentation_rmi.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_protocol.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_resolver.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_transport.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_util.jmk - make/com/sun/corba/minclude/com_sun_corba_se_internal_LegacyFiles.jmk - make/com/sun/corba/minclude/com_sun_corba_se_pept.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_activation.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_copyobject.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_encoding.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_extension.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_ior.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_connection.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_interceptor.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_logging.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_monitoring.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_oa.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_orb.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_orbutil.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_presentation_rmi.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_protocol.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_resolver.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_servicecontext.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_transport.jmk - make/com/sun/corba/minclude/com_sun_tools_corba_se_idl_toJavaPortable.jmk - make/com/sun/corba/minclude/javax_activity.jmk - make/com/sun/corba/minclude/javax_rmi.jmk - make/com/sun/corba/minclude/javax_rmi_CORBA.jmk - make/com/sun/corba/minclude/javax_transaction.jmk - make/com/sun/corba/minclude/org_omg_CORBA.jmk - make/com/sun/corba/minclude/org_omg_CORBAX.jmk - make/com/sun/corba/minclude/org_omg_CORBA_2_3.jmk - make/com/sun/corba/minclude/org_omg_CosNaming.jmk - make/com/sun/corba/minclude/org_omg_DynamicAny.jmk - make/com/sun/corba/minclude/org_omg_IOP.jmk - make/com/sun/corba/minclude/org_omg_Messaging.jmk - make/com/sun/corba/minclude/org_omg_PortableInterceptor.jmk - make/com/sun/corba/minclude/org_omg_PortableServer.jmk - make/com/sun/corba/minclude/org_omg_SendingContext.jmk - make/com/sun/corba/minclude/sun_corba.jmk - make/com/sun/corba/se/Makefile - make/com/sun/corba/se/PortableActivationIDL/Makefile - make/com/sun/corba/se/connection/FILES_java.gmk - make/com/sun/corba/se/connection/Makefile - make/com/sun/corba/se/core/Makefile - make/com/sun/corba/se/corespi/Makefile - make/com/sun/corba/se/impl/Makefile - make/com/sun/corba/se/impl/activation/Makefile - make/com/sun/corba/se/impl/activation/orbd/Makefile - make/com/sun/corba/se/impl/activation/servertool/Makefile - make/com/sun/corba/se/impl/interceptors/Makefile - make/com/sun/corba/se/impl/logging/Makefile - make/com/sun/corba/se/impl/monitoring/Makefile - make/com/sun/corba/se/impl/naming/Makefile - make/com/sun/corba/se/impl/naming/cosnaming/Makefile - make/com/sun/corba/se/impl/naming/namingutil/Makefile - make/com/sun/corba/se/impl/naming/pcosnaming/Makefile - make/com/sun/corba/se/impl/oa/Makefile - make/com/sun/corba/se/impl/oa/poa/Makefile - make/com/sun/corba/se/impl/oa/toa/Makefile - make/com/sun/corba/se/interceptor/FILES_java.gmk - make/com/sun/corba/se/interceptor/Makefile - make/com/sun/corba/se/pept/Makefile - make/com/sun/corba/se/rmi/Makefile - make/com/sun/corba/se/rmi/rmic/Makefile - make/com/sun/corba/se/rmi/rmic/SUN_RMI_RMIC_IIOP_java.gmk - make/com/sun/corba/se/sources/Makefile - make/com/sun/corba/se/spi/Makefile - make/com/sun/corba/se/spi/activation/Makefile - make/com/sun/corba/se/spi/copyobject/Makefile - make/com/sun/corba/se/spi/encoding/Makefile - make/com/sun/corba/se/spi/extension/Makefile - make/com/sun/corba/se/spi/legacy/Makefile - make/com/sun/corba/se/spi/legacy/connection/Makefile - make/com/sun/corba/se/spi/legacy/interceptor/Makefile - make/com/sun/corba/se/spi/logging/Makefile - make/com/sun/corba/se/spi/monitoring/Makefile - make/common/BuildToolJar.gmk - make/common/CancelImplicits.gmk - make/common/Classes.gmk - make/common/Defs-bsd.gmk - make/common/Defs-linux.gmk - make/common/Defs-solaris.gmk - make/common/Defs-windows.gmk - make/common/Defs.gmk - make/common/Rules.gmk - make/common/internal/Resources.gmk - make/common/shared/Defs-bsd.gmk - make/common/shared/Defs-java.gmk - make/common/shared/Defs-linux.gmk - make/common/shared/Defs-solaris.gmk - make/common/shared/Defs-utils.gmk - make/common/shared/Defs-windows.gmk - make/common/shared/Defs.gmk - make/common/shared/Platform.gmk - make/javax/Makefile - make/javax/xa/Makefile - make/jprt.properties - make/org/Makefile - make/org/omg/CORBA/Makefile - make/org/omg/CORBAX_java.gmk - make/org/omg/CosNaming/Makefile - make/org/omg/DynamicAny/Makefile - make/org/omg/Makefile - make/org/omg/PortableInterceptor/Makefile - make/org/omg/PortableServer/Makefile - make/org/omg/idl/FILES_java.gmk - make/org/omg/idl/Makefile - make/org/omg/sources/Makefile - make/sun/Makefile - make/sun/corba/Makefile - make/sun/corba/core/Makefile - make/sun/corba/org/Makefile - make/sun/corba/org/omg/FILES_java.gmk - make/sun/corba/org/omg/Makefile - make/sun/rmi/Makefile - make/sun/rmi/corbalogcompile/Makefile - make/sun/rmi/corbalogsources/Makefile - make/sun/rmi/rmic/FILES.gmk - make/sun/rmi/rmic/Makefile - make/tools/Makefile - make/tools/idlj/Makefile - make/tools/logutil/Makefile - make/tools/strip_properties/Makefile - makefiles/BuildCorba.gmk - makefiles/Makefile Changeset: dae8ee5b71d9 Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/dae8ee5b71d9 Merge Changeset: 0354055127f5 Author: asaha Date: 2013-12-20 07:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0354055127f5 Merge Changeset: 7ec1c16f6fb8 Author: asaha Date: 2014-01-02 15:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7ec1c16f6fb8 Merge ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java Changeset: 1ecd4619f60c Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/1ecd4619f60c Added tag jdk8-b122 for changeset 0cd687347540 ! .hgtags Changeset: 9240e4c6b107 Author: asaha Date: 2014-01-03 15:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9240e4c6b107 Merge From alexander.zuev at oracle.com Tue Jan 14 11:25:32 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:25:32 +0000 Subject: hg: jdk8/tl/hotspot: 21 new changesets Message-ID: <20140114192621.73DC36242F@hg.openjdk.java.net> Changeset: 7ccce1a6fa4d Author: coleenp Date: 2013-09-05 10:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ccce1a6fa4d 8021266: Better life cycle for objects Summary: Improve life cycle for objects Reviewed-by: art, hseigel Contributed-by: gerard.ziemski at oracle.com ! src/share/vm/runtime/os.cpp Changeset: 2a907fd129cb Author: chegar Date: 2013-09-06 09:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2a907fd129cb Merge ! src/share/vm/runtime/os.cpp - test/runtime/7051189/Xchecksig.sh Changeset: 9b4ce069642e Author: chegar Date: 2013-09-14 20:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b4ce069642e Merge ! src/share/vm/classfile/classFileParser.cpp - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/os.cpp Changeset: 6fa574bfd32a Author: chegar Date: 2013-10-03 19:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6fa574bfd32a Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/os.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: 6795fcebbf42 Author: chegar Date: 2013-10-21 14:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6795fcebbf42 Merge ! src/share/vm/classfile/classFileParser.cpp - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: c31f0cbe6d9e Author: chegar Date: 2013-11-03 07:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c31f0cbe6d9e Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/gc/7168848/HumongousAlloc.java Changeset: 0611ce949aaa Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0611ce949aaa Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: e254e5940c19 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e254e5940c19 Merge ! src/share/vm/classfile/classFileParser.cpp - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: 9063bd8808a7 Author: jrose Date: 2013-12-05 00:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9063bd8808a7 8029507: Enhance JVM method processing Summary: update MemberName.clazz correctly in MemberName.resolve; also pass lookupClass to MethodHandles::resolve_MemberName Reviewed-by: acorn, vlivanov ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 1b46c3672650 Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b46c3672650 Merge Changeset: 8dbd61445631 Author: asaha Date: 2013-12-17 15:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8dbd61445631 Merge Changeset: ddff10b13587 Author: asaha Date: 2013-12-20 07:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ddff10b13587 Merge Changeset: 0b9c7eb6658b Author: amurillo Date: 2013-12-20 08:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b9c7eb6658b 8030752: new hotspot build - hs25-b65 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5832cdaf89c6 Author: hseigel Date: 2013-12-16 08:24 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5832cdaf89c6 8027804: JCK resolveMethod test fails expecting AbstractMethodError Summary: Create AME overpass methods and fix method search logic Reviewed-by: kamg, acorn, lfoltan, coleenp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp Changeset: 62e87648a4be Author: coleenp Date: 2013-12-19 20:28 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/62e87648a4be 8030633: nsk/jvmti/RedefineClasses/StressRedefine failed invalid method ordering length on Solaris Summary: A method with no declared methods was getting an AME overpass method with the latest change. The method_ordering array was not updated for the new methods. Reviewed-by: dcubed, acorn, dsamersoff, lfoltan, hseigel ! src/share/vm/classfile/defaultMethods.cpp Changeset: be840d0078bc Author: coleenp Date: 2013-12-20 14:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be840d0078bc Merge Changeset: 55fb97c4c58d Author: mikael Date: 2013-12-24 11:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55fb97c4c58d 8029233: Update copyright year to match last edit in jdk8 hotspot repository for 2013 Summary: Copyright year updated for files modified during 2013 Reviewed-by: twisti, iveresov ! agent/make/Makefile ! agent/src/os/linux/libproc.h ! agent/src/os/linux/salibelf.c ! agent/src/os/linux/symtab.c ! agent/src/os/solaris/proc/saproc.cpp ! agent/src/os/win32/windbg/sawindbg.cpp ! 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/LinuxVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxOopHandle.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windows/x86/WindowsX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodCounters.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.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/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/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/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/ui/SAPanel.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaInstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/minimal1.make ! make/hotspot.script ! make/linux/makefiles/adlc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/minimal1.make ! make/linux/makefiles/saproc.make ! make/sa.files ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/gcc.make ! make/windows/build_vm_def.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/c2_init_sparc.cpp ! src/cpu/sparc/vm/disassembler_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/register_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/interp_masm_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/jni_zero.h ! src/cpu/zero/vm/nativeInst_zero.hpp ! src/cpu/zero/vm/register_zero.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os/bsd/dtrace/jvm_dtrace.c ! src/os/posix/vm/os_posix.hpp ! src/os/solaris/dtrace/jvm_dtrace.c ! src/os/solaris/vm/globals_solaris.hpp ! src/os/windows/vm/decoder_windows.hpp ! 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/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_sparc/vm/linux_sparc.s ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! 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/linux_x86/vm/os_linux_x86.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_64.s ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/tools/hsdis/hsdis.c ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_globals.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciArray.cpp ! src/share/vm/ci/ciArray.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciFlags.hpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/ci/ciTypeArray.cpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/bytecodeAssembler.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genRemSet.cpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiTrace.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/perf.cpp ! src/share/vm/prims/wbtestmethods/parserTests.hpp ! src/share/vm/prims/whitebox.hpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/memoryUsage.hpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/threadService.hpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! test/Makefile ! test/TEST.ROOT ! test/compiler/5091921/Test7005594.sh ! test/compiler/6431242/Test.java ! test/compiler/6589834/Test_ia32.java ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java ! test/compiler/6795161/Test.java ! test/compiler/6857159/Test6857159.sh ! test/compiler/7068051/Test7068051.sh ! test/compiler/7070134/Test7070134.sh ! test/compiler/7200264/Test7200264.sh ! test/compiler/8000805/Test8000805.java ! test/compiler/8005419/Test8005419.java ! test/gc/6941923/Test6941923.java ! test/gc/g1/TestHumongousAllocInitialMark.java ! test/runtime/6626217/Test6626217.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7162488/Test7162488.sh ! test/runtime/RedefineObject/Agent.java ! test/runtime/RedefineObject/TestRedefineObject.java Changeset: d3521d8e562a Author: amurillo Date: 2013-12-27 07:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d3521d8e562a Added tag hs25-b65 for changeset 55fb97c4c58d ! .hgtags Changeset: a902f789ea1f Author: asaha Date: 2014-01-02 15:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a902f789ea1f Merge Changeset: 591135a7d6f9 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/591135a7d6f9 Added tag jdk8-b122 for changeset d3521d8e562a ! .hgtags Changeset: 3b69a859e3f9 Author: asaha Date: 2014-01-03 15:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b69a859e3f9 Merge From alexander.zuev at oracle.com Tue Jan 14 11:30:13 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:30:13 +0000 Subject: hg: jdk8/tl/jaxp: 18 new changesets Message-ID: <20140114193052.B889062431@hg.openjdk.java.net> Changeset: 51bbdd517b93 Author: joehw Date: 2013-08-26 21:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/51bbdd517b93 8022935: Enhance Apache resolver classes Reviewed-by: alanb, mchung, skoivu ! src/com/sun/org/apache/xml/internal/resolver/CatalogManager.java ! src/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java ! src/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java Changeset: d6d8302ecf8f Author: chegar Date: 2013-08-30 10:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d6d8302ecf8f Merge ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java Changeset: aef8ae2fcec4 Author: chegar Date: 2013-09-06 09:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/aef8ae2fcec4 Merge Changeset: 0ce80229af71 Author: chegar Date: 2013-09-14 20:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0ce80229af71 Merge Changeset: 5e6bf44f3b7d Author: chegar Date: 2013-10-03 19:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5e6bf44f3b7d Merge Changeset: 54a0dd196acd Author: chegar Date: 2013-10-21 14:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/54a0dd196acd Merge Changeset: 10b3a127b1fc Author: joehw Date: 2013-10-22 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/10b3a127b1fc 8025018: Enhance JAX-P set up Reviewed-by: alanb, dfuchs, lancea, ahgross ! src/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java ! src/com/sun/org/apache/xalan/internal/lib/Extensions.java Changeset: ef71f2353352 Author: chegar Date: 2013-10-25 09:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ef71f2353352 Merge Changeset: e68f3e585d7d Author: chegar Date: 2013-11-03 07:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e68f3e585d7d Merge Changeset: fb51ed270f53 Author: joehw Date: 2013-11-14 10:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/fb51ed270f53 8027201: Enhance JAX-P set up Reviewed-by: alanb, dfuchs, lancea, hawtin ! src/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java ! src/com/sun/org/apache/xalan/internal/lib/Extensions.java Changeset: 932684ede1c6 Author: joehw Date: 2013-11-27 14:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/932684ede1c6 8028111: XML readers share the same entity expansion counter Reviewed-by: alanb, lancea, dfuchs, ahgross ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDScanner.java Changeset: 2a8fce63503a Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2a8fce63503a Merge ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java Changeset: 5be9182ceb48 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5be9182ceb48 Merge - make/jprt.properties - make/scripts/update_src.sh - makefiles/BuildJaxp.gmk - makefiles/Makefile Changeset: 41068d69fe3e Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/41068d69fe3e Merge Changeset: f2c9c0f64280 Author: asaha Date: 2013-12-20 07:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f2c9c0f64280 Merge Changeset: 01b611e0c341 Author: asaha Date: 2014-01-02 15:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/01b611e0c341 Merge ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java Changeset: 4e35b5b6d2e5 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4e35b5b6d2e5 Added tag jdk8-b122 for changeset 93bf25903af0 ! .hgtags Changeset: 985376a77c4c Author: asaha Date: 2014-01-03 15:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/985376a77c4c Merge From alexander.zuev at oracle.com Tue Jan 14 11:31:06 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:31:06 +0000 Subject: hg: jdk8/tl/jaxws: 8 new changesets Message-ID: <20140114193123.8797F62432@hg.openjdk.java.net> Changeset: b0c2840e2513 Author: mkos Date: 2013-11-22 21:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b0c2840e2513 8010935: Better XML handling 8027378: Two closed/javax/xml/8005432 fails with jdk7u51b04 8028382: Two javax/xml/8005433 tests still fail after the fix JDK-8028147 Summary: base fix + fixes for test regressions; fix also reviewed by Maxim Soloviev, Alexander Fomin Reviewed-by: mchung, mgrebac, mullan ! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/ApNavigator.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/EagerNType.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/JAXBRIContext.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/TypeReference.java + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeAnyTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeInfoSetImpl.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/Navigator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfoSet.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/ClassBeanInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/ElementBeanInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/TransducedAccessor.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/RuntimeModeler.java + src/share/jaxws_classes/com/sun/xml/internal/ws/model/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/WrapperBeanGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingHelper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/TypeInfo.java + src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/Utils.java Changeset: f80c37c168f7 Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f80c37c168f7 Merge Changeset: c99140027351 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c99140027351 Merge - make/jprt.properties - make/scripts/update_src.sh - makefiles/BuildJaxws.gmk - makefiles/Makefile Changeset: ca6bb6b558a6 Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ca6bb6b558a6 Merge Changeset: d4b785ac4079 Author: asaha Date: 2013-12-20 07:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d4b785ac4079 Merge Changeset: 91f5c542ccad Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/91f5c542ccad Added tag jdk8-b122 for changeset bc622ba563f9 ! .hgtags Changeset: c07fc967624b Author: asaha Date: 2014-01-03 15:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c07fc967624b Merge Changeset: 6547da5c3277 Author: kizune Date: 2014-01-14 23:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6547da5c3277 Merge From alexander.zuev at oracle.com Tue Jan 14 11:35:25 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:35:25 +0000 Subject: hg: jdk8/tl/jdk: 53 new changesets Message-ID: <20140114194639.1F1C362434@hg.openjdk.java.net> Changeset: 75142ce752da Author: malenkov Date: 2013-12-23 16:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75142ce752da 8030118: Document listeners fired outside document lock Reviewed-by: art, serb ! src/share/classes/javax/swing/text/AbstractDocument.java - test/javax/swing/text/AbstractDocument/7146146/bug7146146.java + test/javax/swing/text/AbstractDocument/8030118/Test8030118.java Changeset: 8b5985f1a0b5 Author: lana Date: 2013-12-25 11:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b5985f1a0b5 Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: e1499442453b Author: lana Date: 2013-12-26 22:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1499442453b Merge ! src/share/classes/javax/swing/text/AbstractDocument.java Changeset: 7e10ee00fe41 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e10ee00fe41 Added tag jdk8-b122 for changeset e1499442453b ! .hgtags Changeset: 484e16c0a040 Author: nikgor Date: 2014-01-07 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/484e16c0a040 8004562: Better support for crossdomain.xml Reviewed-by: herrick, ngthomas, chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 0dfcc99c6f5d Author: weijun Date: 2013-08-16 17:57 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0dfcc99c6f5d 8022945: Enhance JNDI implementation classes Reviewed-by: xuelei, ahgross, skoivu ! 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 Changeset: 46c8720ef36f Author: lancea Date: 2013-08-21 11:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46c8720ef36f 8022904: Enhance JDBC Parsers Reviewed-by: alanb, skoivu ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: 428288ee9c99 Author: valeriep Date: 2013-08-21 11:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/428288ee9c99 8022927: Input validation for byte/endian conversions Summary: Add additional boundary checks Reviewed-by: ascarpino ! src/share/classes/sun/security/provider/ByteArrayAccess.java Changeset: 24a7024bd86b Author: bae Date: 2013-08-23 12:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24a7024bd86b 8021394: Better color profiles Reviewed-by: prr, vadim, mschoene ! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c Changeset: ff2792868d89 Author: chegar Date: 2013-08-23 12:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff2792868d89 Merge Changeset: 036ad7864d35 Author: chegar Date: 2013-08-30 09:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/036ad7864d35 Merge ! 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 Changeset: 2ae5cf0805de Author: malenkov Date: 2013-09-02 11:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ae5cf0805de 8023245: Enhance Beans decoding Reviewed-by: art, skoivu, alanb ! src/share/classes/com/sun/beans/decoder/DocumentHandler.java Changeset: 9bc1411d0223 Author: coleenp Date: 2013-09-05 10:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bc1411d0223 8021266: Better life cycle for objects Summary: Improve life cycle for objects Reviewed-by: art, hseigel Contributed-by: gerard.ziemski at oracle.com ! make/common/Release.gmk ! make/java/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/Images.gmk ! makefiles/Profiles.gmk Changeset: 46e86a9402ab Author: chegar Date: 2013-09-06 13:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46e86a9402ab Merge ! makefiles/Profiles.gmk ! 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 Changeset: 4cab5eb93124 Author: xuelei Date: 2013-09-07 20:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4cab5eb93124 8023069: Enhance TLS connections Summary: Also reviewed by Alexander Fomin and Andrew Gross Reviewed-by: wetmore ! src/share/classes/com/sun/crypto/provider/TlsRsaPremasterSecretGenerator.java ! src/share/classes/sun/security/internal/spec/TlsRsaPremasterSecretParameterSpec.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java ! src/share/classes/sun/security/rsa/RSAPadding.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: ac3e7b3c1a00 Author: weijun Date: 2013-09-13 15:37 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac3e7b3c1a00 8024306: Enhance Subject consistency Summary: Also reviewed by Alexander Fomin Reviewed-by: mullan, ahgross ! src/share/classes/javax/security/auth/Subject.java Changeset: 4b74f9ad3dd7 Author: weijun Date: 2013-09-13 15:37 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b74f9ad3dd7 8023672: Enhance jar file validation Summary: Also reviewed by Chris Ries and Alexander Fomin Reviewed-by: mullan, sherman ! src/share/classes/java/util/jar/JarVerifier.java Changeset: 432c348e15bc Author: vadim Date: 2013-09-13 13:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/432c348e15bc 8023057: Enhance start up image display Reviewed-by: anthony, serb, mschoene ! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m ! src/share/native/sun/awt/splashscreen/splashscreen_impl.c ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: ca700a3c1708 Author: chegar Date: 2013-09-14 19:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca700a3c1708 Merge Changeset: d931b672bfa9 Author: prr Date: 2013-09-19 08:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d931b672bfa9 8025034: Improve layout lookups Reviewed-by: mschoene, vadim, srl ! src/share/native/sun/font/layout/LookupProcessor.cpp Changeset: a90e9b3c99b8 Author: weijun Date: 2013-09-19 10:40 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a90e9b3c99b8 8024302: Clarify jar verifications 8023338: Update jarsigner to encourage timestamping Reviewed-by: mullan, ahgross ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/jarsigner/Resources.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/ts.sh + test/sun/security/tools/jarsigner/warnings.sh Changeset: f996a185e9a1 Author: weijun Date: 2013-09-19 10:41 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f996a185e9a1 8024659: Clarify JarFile API Reviewed-by: mullan, ahgross ! src/share/classes/java/util/jar/JarFile.java Changeset: f8b097b01270 Author: chegar Date: 2013-10-03 19:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8b097b01270 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/sun/security/ssl/Handshaker.java Changeset: 1e3216123667 Author: chegar Date: 2013-10-04 14:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e3216123667 Merge Changeset: 282c5e92d9a0 Author: malenkov Date: 2013-10-04 19:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/282c5e92d9a0 8025448: Enhance listening events Reviewed-by: art, skoivu ! src/share/classes/javax/swing/event/EventListenerList.java Changeset: 146dd44703f7 Author: chegar Date: 2013-10-07 11:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/146dd44703f7 Merge Changeset: 3cd01bc784b2 Author: dfuchs Date: 2013-10-07 12:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cd01bc784b2 8024867: Enhance logging start up Reviewed-by: mchung, hawtin ! src/share/classes/java/util/logging/LogManager.java Changeset: d0a5383a63ad Author: weijun Date: 2013-10-09 18:58 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d0a5383a63ad 8026037: [TESTBUG] sun/security/tools/jarsigner/warnings.sh test fails on Solaris Reviewed-by: chegar Contributed-by: Artem Smotrakov ! test/sun/security/tools/jarsigner/warnings.sh Changeset: b90047350153 Author: jfranck Date: 2013-10-11 13:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b90047350153 8023301: Enhance generic classes Reviewed-by: mchung, hawtin ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: eafa41f4e9fd Author: weijun Date: 2013-10-12 10:22 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eafa41f4e9fd 8026304: jarsigner output bad grammar Reviewed-by: chegar, coffeys Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/tools/jarsigner/Resources.java Changeset: 62a8a26dca09 Author: xuelei Date: 2013-10-12 20:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62a8a26dca09 8025026: Enhance canonicalization Summary: Don't use cached null xmlns definition. Also reviewed by Alexander Fomin Reviewed-by: mullan, hawtin ! 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/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/CanonicalizerBase.java Changeset: c1f6ed408492 Author: prr Date: 2013-10-14 16:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f6ed408492 8026176: Enhance document printing Reviewed-by: bae, jgodinez ! src/share/classes/javax/print/SimpleDoc.java Changeset: 5cb70d52ae61 Author: xuelei Date: 2013-10-15 18:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5cb70d52ae61 8026204: Enhance auth login contexts Summary: Enforce package access control with current context. Also reviewed by Alexander Fomin Reviewed-by: weijun, ahgross ! src/share/classes/javax/security/auth/login/LoginContext.java Changeset: 48dc2eacb0e5 Author: malenkov Date: 2013-10-16 13:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48dc2eacb0e5 8026172: Enhance UI Management Reviewed-by: art, skoivu ! src/share/classes/javax/swing/SwingUtilities.java Changeset: 76262685781c Author: xuelei Date: 2013-10-16 18:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76262685781c 8025758: Enhance Naming management Summary: Enforce package access control with current context. Also reviewed by Alexander Fomin Reviewed-by: weijun, ahgross ! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/share/classes/com/sun/naming/internal/VersionHelper12.java Changeset: d4f4a9915357 Author: prr Date: 2013-10-17 09:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4f4a9915357 8024530: Enhance font process resilience Reviewed-by: mschoene, bae, srl, prr ! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp ! src/share/native/sun/font/layout/AnchorTables.cpp ! src/share/native/sun/font/layout/AnchorTables.h ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/CanonShaping.cpp ! src/share/native/sun/font/layout/CharSubstitutionFilter.h ! src/share/native/sun/font/layout/ClassDefinitionTables.h ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CoverageTables.h ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/DeviceTables.h ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/GDEFMarkFilter.cpp ! src/share/native/sun/font/layout/GDEFMarkFilter.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphFilter.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEScripts.h ! src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LETableReference.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LigatureSubstProc2.cpp ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/Lookups.cpp ! src/share/native/sun/font/layout/MarkArrays.cpp ! src/share/native/sun/font/layout/MarkArrays.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeUtilities.h ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.h ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/TibetanReordering.h ! src/share/native/sun/font/layout/ValueRecords.cpp ! src/share/native/sun/font/layout/ValueRecords.h Changeset: b8008a2bf4fe Author: sjiang Date: 2013-10-21 09:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8008a2bf4fe 7068126: Enhance SNMP statuses Reviewed-by: dfuchs, hawtin ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java Changeset: d7ef65d3ee57 Author: chegar Date: 2013-10-21 15:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7ef65d3ee57 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk + makefiles/GenerateSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Profiles.gmk - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/lang/invoke/MagicLambdaImpl.java - src/share/classes/java/net/HttpURLPermission.java - src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-windows - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/lang/SecurityManager/CheckPackageAccess.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: 1c85f50e2622 Author: chegar Date: 2013-10-22 12:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c85f50e2622 Merge ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! 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 Changeset: ad808fe39337 Author: weijun Date: 2013-10-17 09:58 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad808fe39337 8025014: Enhance Security Policy 6727821: Enhance JAAS Configuration Reviewed-by: xuelei, hawtin ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/login/Configuration.java Changeset: f87d59557049 Author: chegar Date: 2013-10-22 14:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f87d59557049 Merge Changeset: d92379723173 Author: asaha Date: 2013-12-07 16:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d92379723173 Merge ! make/CompileJavaClasses.gmk ! make/CompileNativeLibraries.gmk ! make/CreateJars.gmk ! make/CreateSecurityJars.gmk ! make/GenerateSources.gmk ! make/Images.gmk ! make/Profiles.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/CoreLibraries.gmk ! make/lib/NetworkingLibraries.gmk ! make/lib/NioLibraries.gmk ! make/lib/PlatformLibraries.gmk ! make/lib/SecurityLibraries.gmk ! make/lib/ServiceabilityLibraries.gmk ! make/lib/SoundLibraries.gmk ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/ts.sh Changeset: ef2352bf3dfe Author: xuelei Date: 2013-10-23 21:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef2352bf3dfe 8026417: Enhance XML canonicalization Summary: Copy before use mutable byte arrays. Also reviewed by Alexander Fomin Reviewed-by: mullan, hawtin, ahgross ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java Changeset: fe1707a836b4 Author: xuelei Date: 2013-10-24 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe1707a836b4 8027204: Revise the update of 8026204 and 8025758 Summary: Rivise the update to use system class loader with null TCCL. Also reviewed by Alexander Fomin Reviewed-by: mchung, ahgross ! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/share/classes/com/sun/naming/internal/VersionHelper12.java ! src/share/classes/javax/security/auth/login/LoginContext.java Changeset: a147b2084bc3 Author: michaelm Date: 2013-10-24 20:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a147b2084bc3 8011786: Better applet networking Reviewed-by: alanb, chegar ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/lib/security/java.policy ! 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 ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java Changeset: a0b6e5895464 Author: michaelm Date: 2013-11-20 23:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0b6e5895464 8028453: AsynchronousSocketChannel.connect() requires SocketPermission due to bind to local address (win) Reviewed-by: alanb, chegar ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java Changeset: d5107c804de5 Author: michaelm Date: 2013-11-26 10:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5107c804de5 8028293: Check local configuration for actual ephemeral port range Reviewed-by: alanb, chegar, smarks ! make/lib/NetworkingLibraries.gmk ! make/mapfiles/libnet/mapfile-vers ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! 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 + src/solaris/classes/sun/net/PortConfig.java ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h + src/solaris/native/sun/net/portconfig.c + src/windows/classes/sun/net/PortConfig.java + src/windows/native/sun/net/portconfig.c ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/testlibrary/TestLibrary.java Changeset: ac1c8e892877 Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac1c8e892877 Merge ! make/CreateSecurityJars.gmk - make/data/cryptopolicy/limited/LIMITED - make/data/cryptopolicy/unlimited/UNLIMITED ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/javax/security/auth/login/LoginContext.java - test/com/sun/jmx/snmp/NoInfoLeakTest.java - test/com/sun/tools/attach/AgentSetup.sh - test/com/sun/tools/attach/ApplicationSetup.sh - test/com/sun/tools/attach/BasicTests.sh - test/com/sun/tools/attach/CommonSetup.sh - test/com/sun/tools/attach/PermissionTests.sh - test/com/sun/tools/attach/ProviderTests.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh - test/java/rmi/reliability/benchmark/runRmiBench.sh - test/java/rmi/reliability/benchmark/runSerialBench.sh Changeset: db6e25fee0f7 Author: asaha Date: 2014-01-08 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db6e25fee0f7 Merge ! make/CompileJavaClasses.gmk ! make/mapfiles/libnet/mapfile-vers ! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/jarsigner/Resources.java ! src/share/classes/sun/security/util/SecurityConstants.java - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! test/java/rmi/registry/readTest/readTest.sh - test/javax/swing/text/AbstractDocument/7146146/bug7146146.java - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/ts.sh Changeset: f251cb144366 Author: erikj Date: 2014-01-08 13:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f251cb144366 8029254: Build error when javadoc generates beaninfo for javax.swing.beans Reviewed-by: alanb, ihse, michaelm ! make/gensrc/GensrcSwing.gmk Changeset: 13b28cffa140 Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13b28cffa140 Added tag jdk8-b123 for changeset 484e16c0a040 ! .hgtags Changeset: e4c9787cae89 Author: asaha Date: 2014-01-10 09:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4c9787cae89 Merge Changeset: a110ff64efa0 Author: kizune Date: 2014-01-14 23:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a110ff64efa0 Merge ! make/Images.gmk - src/bsd/doc/man/ja/kinit.1 - src/bsd/doc/man/ja/klist.1 - src/bsd/doc/man/ja/ktab.1 ! src/share/classes/java/util/logging/LogManager.java From alexander.zuev at oracle.com Tue Jan 14 11:58:03 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:58:03 +0000 Subject: hg: jdk8/tl/nashorn: 10 new changesets Message-ID: <20140114195813.D4DC562437@hg.openjdk.java.net> Changeset: b9fdc55a6e28 Author: chegar Date: 2013-11-03 07:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b9fdc55a6e28 Merge Changeset: c1049f63d4f5 Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c1049f63d4f5 Merge Changeset: 39a3e5a4d6d4 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/39a3e5a4d6d4 Merge - makefiles/BuildNashorn.gmk - makefiles/Makefile Changeset: dd59e60accdd Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/dd59e60accdd Merge Changeset: 89f838ccd186 Author: asaha Date: 2013-12-20 07:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/89f838ccd186 Merge Changeset: a9d41a8055ca Author: asaha Date: 2014-01-02 15:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a9d41a8055ca Merge Changeset: 688f4167f921 Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/688f4167f921 Added tag jdk8-b122 for changeset 9d112a0e7df7 ! .hgtags Changeset: 98e7379a4345 Author: asaha Date: 2014-01-03 16:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/98e7379a4345 Merge Changeset: 0b4301c79225 Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0b4301c79225 Added tag jdk8-b123 for changeset 688f4167f921 ! .hgtags Changeset: 2334772d5292 Author: asaha Date: 2014-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2334772d5292 Merge From alexander.zuev at oracle.com Tue Jan 14 11:57:23 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:57:23 +0000 Subject: hg: jdk8/tl/langtools: 9 new changesets Message-ID: <20140114195751.0CCF762435@hg.openjdk.java.net> Changeset: 53dd31d3c5d7 Author: chegar Date: 2013-11-03 07:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/53dd31d3c5d7 Merge Changeset: aaea3a69fa6c Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aaea3a69fa6c Merge - test/tools/javac/ArraysInIntersections.java - test/tools/javac/ExtDirs/ext1/pkg1.jar - test/tools/javac/ExtDirs/ext2/pkg2.jar - test/tools/javac/ExtDirs/ext3/pkg1.jar - test/tools/javac/ExtDirs/ext3/pkg2.jar - test/tools/javac/InferArraysInIntersections.java - test/tools/javac/diags/examples/InterfaceOrArrayExpected.java Changeset: 48367e6de872 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/48367e6de872 Merge - make/jprt.properties - makefiles/BuildLangtools.gmk - makefiles/Makefile Changeset: f06c0dcf251f Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f06c0dcf251f Merge Changeset: b07b8c077482 Author: asaha Date: 2013-12-20 07:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b07b8c077482 Merge Changeset: efc18829e3a6 Author: asaha Date: 2014-01-02 15:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/efc18829e3a6 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif Changeset: a345cf28faca Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a345cf28faca Added tag jdk8-b122 for changeset 232b9cf6303a ! .hgtags Changeset: 8712cc6441db Author: asaha Date: 2014-01-03 16:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8712cc6441db Merge Changeset: 1f135528db7c Author: kizune Date: 2014-01-14 23:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f135528db7c Merge From david.holmes at oracle.com Tue Jan 14 22:24:32 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jan 2014 16:24:32 +1000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> Message-ID: <52D629A0.4080806@oracle.com> On 15/01/2014 12:10 AM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 12:29 PM, David Holmes > wrote: > > Just a note on this part (I havent looked at the code): > > > On AIX, the constants used for the polling events (i.e. POLLIN, > POLLOUT, ...) are defined to different values than on other > operating systems. The problem is however, that these constants > are hardcoded as public final static members of various, shared > Java classes. > > > Sounds like this should be handled the same way that the other > "system constants" are handled - you can either store a platform > file in the repo (for cross-compiling) or you generate the class > containing the constants at build time. > > > Hi David, > > thanks for your comments. That sound like a good idea but I'm not sure > if it would make sense to duplicate the following files: > > src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java: > src/solaris/classes/sun/nio/ch/Port.java > > because of this. Do you have a concrete example where Java-classes are > being generated with different constants in the class library build? There are two files generated: UnixConstants.java (or SolarisConstants.java) for general I/O type values SocketOptionRegistry.java for socket options. See jdk/make/gensrc/GensrcMisc.gmk. > Both solutions would result in different class files on Aix and other > Unix variants. What do you think about assigning the concrete values > depending on 'os.name ' in the static initializers of > the corresponding classes? I think that shouldn't introduce too much > overhead and I could get rid of all the ugly conversion code. I'm not a fan of runtime checks of this kind though if it is only a very samll number of values it might be okay. Another option would be to make those classes into "templates" as done with Version.java.template and substitute the right values at build time. But I'll let Alan and net-dev folk come back with their preferred technique for this. Cheers, David > > Regards, > Volker > > David > > > On 14/01/2014 6:40 PM, Volker Simonis wrote: > > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for > integration into > ppc-aix-port/stage-9 and subsequent backporting to > ppc-aix-port/stage): > > http://cr.openjdk.java.net/~__simonis/webrevs/8031581/ > > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: > PPC64: > Updated jdk/test scripts to understand the AIX os and > environment" and > "8031134 : PPC64: implement printing on AIX") our port passes > all but > the following 7 jtreg regression tests on AIX (compared to the > Linux/x86_64 baseline from > www.java.net/download/jdk8/__testresults/testresults.html > > >?): > > > java/net/Inet6Address/__B6558853.java > java/nio/channels/__AsynchronousChannelGroup/__Basic.java > (sporadically) > java/nio/channels/__AsynchronousChannelGroup/__GroupOfOne.java > java/nio/channels/__AsynchronousChannelGroup/__Unbounded.java > (sporadically) > java/nio/channels/Selector/__RacyDeregister.java > sun/security/krb5/auto/__Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > > > src/share/native/java/util/__zip/zip_util.c > src/share/native/sun/__management/__DiagnosticCommandImpl.c > > * According to ISO C it is perfectly legal for malloc to > return zero > > if called with a zero argument. Fix various places where > malloc can > potentially correctly return zero because it was called > with a zero > argument. > * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. > This > > only fixes a compiler warning on Linux, but on AIX it > prevents a VM > crash later on because the return value of |malloc()| will > be casted > to |int| which is especially bad if that pointer was bigger > than > 32-bit. > > > make/CompileJavaClasses.gmk > > * Also use |PollingWatchService| on AIX. > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/__AixNativeThread.c > > * Put the implementation for the native methods of > |NativeThread| into > > |AixNativeThread.c| on AIX. > > > src/solaris/native/sun/nio/ch/__PollArrayWrapper.c > src/solaris/native/sun/nio/ch/__Net.c > src/aix/classes/sun/nio/ch/__AixPollPort.java > src/aix/native/sun/nio/ch/__AixPollPort.c > src/aix/native/java/net/aix___close.c > > * On AIX, the constants used for the polling events (i.e. > |POLLIN|, > |POLLOUT|, ...) are defined to different values than on other > > operating systems. The problem is however, that these > constants are > hardcoded as public final static members of various, shared > Java > classes. We therefore have to map them from Java to native > every > time before calling one of the native poll functions and > back to > Java after the call on AIX in order to get the right semantics. > > > src/share/classes/java/nio/__file/CopyMoveHelper.java > > * As discussed on the core-libs mailing list (see > > http://mail.openjdk.java.net/__pipermail/core-libs-dev/2013-__December/024119.html > ) > it is not necessary to call |Files.getFileAttributeView()| > with any > |linkOptions| because at that place we've already checked > that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support > symbolic links > but do not support the |O_NOFOLLOW| flag to the |open| > system call. > It also makes the JDK pass the |demo/zipfs/basic.sh| test > on AIX. > > > src/share/classes/sun/nio/cs/__ext/ExtendedCharsets.java > > * Support "compound text" on AIX in the same way like on > other Unix > platforms. > > > > src/share/classes/sun/tools/__attach/META-INF/services/com.__sun.tools.attach.spi.__AttachProvider > > * Define the correct attach provider for AIX. > > > src/solaris/native/java/net/__net_util_md.h > src/solaris/native/sun/nio/ch/__FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/__ServerSocketChannelImpl.c > > * AIX needs a workaround for I/O cancellation (see: > > http://publib.boulder.ibm.com/__infocenter/pseries/v5r3/index.__jsp?topic=/com.ibm.aix.__basetechref/doc/basetrf1/__close.htm > ). > "..The |close()| subroutine is blocked until all > subroutines which > use the file descriptor return to usr space. For example, > when a > thread is calling close and another thread is calling > select with > the same file descriptor, the close subroutine does not > return until > the select call returns...". To fix this problem, we have > to use the > various |NET_| wrappers which are declared in > |net_util_md.h| and > defined in |aix_close.c| and we also need some additional > wrappers > for |fcntl()|, |read()| and |write()| on AIX. > > While the current solution isn't really nice because it > introduces > some more AIX-specifc sections in shared code, I think it > is the > best way to go for JDK 8 because it imposes the smallest > possible > changes and risks for the existing platforms. I'm ready to > change > the code to unconditionally use the wrappers for all > platforms and > implement the wrappers empty on platforms which don't need any > wrapping. I think it would also be nice to clean up the > names (e.g. > |NET_Read()| is currently a wrapper for |recv()| and the |NET_| > prefix is probably not appropriate any more so maybe change > it to > something like |IO_|). But again, I'll prefer to keep that as a > > follow up change for JDK9. > * Calling |fsync()| on a "read-only" file descriptor on AIX will > > result in an error (i.e. "EBADF: The FileDescriptor > parameter is not > a valid file descriptor open for writing."). To prevent > this error > we have to query if the corresponding file descriptor is > writeable. > Notice that at that point we can not access the |writable| > attribute > of the corresponding file channel so we have to use |fcntl()|. > > > src/solaris/classes/java/lang/__UNIXProcess.java.aix > > * On AIX the implementation is especially tricky, because the > > |close()| system call will block if another thread is at > the same > time blocked in a file operation (e.g. 'read()') on the > same file > descriptor. We therefore combine the AIX > |ProcessPipeInputStream| > implemenatation with the |DeferredCloseInputStream| > approach used on > Solaris (see |UNIXProcess.java.solaris|). This means that every > > potentially blocking operation on the file descriptor > increments a > counter before it is executed and decrements it once it > finishes. > The 'close()' operation will only be executed if there are no > pending operations. Otherwise it is deferred after the last > pending > operation has finished. > > > src/share/transport/socket/__socketTransport.c > > * On AIX we have to call |shutdown()| on a socket descriptor > before > > closing it, otherwise the |close()| call may be blocked. > This is the > same problem as described before. Unfortunately the JDI > framework > doesn't use the same IO wrappers like other class library > components > so we can not easily use the |NET_| abstractions from > |aix_close.c| > here. > * Without this small change all JDI regression tests will > fail on AIX > > because of the way how the tests act as a "debugger" which > launches > another VM (the "debugge") which connects itself back to the > debugger. In this scenario the "debugge" can not shut down > itself > because one thread will always be blocked in the |close()| > call on > one of the communication sockets. > > > src/solaris/native/java/net/__NetworkInterface.c > > * Set the scope identifier for IPv6 addresses on AIX. > > > src/solaris/native/java/net/__net_util_md.c > > * It turns out that we do not always have to replace > |SO_REUSEADDR| on > AIX by |SO_REUSEPORT|. Instead we can simply use the same > approach > > like BSD and only use |SO_REUSEPORT| additionally, if several > datagram sockets try to bind to the same port. > * Also fixed a comment and removed unused local variables. > * Fixed the obviously inverted assignment |newTime = > prevTime;| which > > should read |prevTime = newTime;|. Otherwise |prevTime| > will never > change and the timeout will be potential reached too fast. > > > src/solaris/native/sun/__management/__OperatingSystemImpl.c > > * AIX does not understand |/proc/self| so we have to query > the real > > process ID to access the proc file system. > > > src/solaris/native/sun/nio/ch/__DatagramChannelImpl.c > > * On AIX, |connect()| may legally return |EAFNOSUPPORT| if > called on a > > socket with the address family set to |AF_UNSPEC|. > > > From staffan.larsen at oracle.com Wed Jan 15 00:57:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 09:57:31 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Volker, I?ve look at the following files: src/share/native/sun/management/DiagnosticCommandImpl.c: nit: ?legel? -> ?legal? (two times) In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you allow dcmd_info_array to become NULL, then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to check that. src/solaris/native/sun/management/OperatingSystemImpl.c No comments. src/share/transport/socket/socketTransport.c No comments. src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider No comments. Thanks, /Staffan On 14 jan 2014, at 09:40, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. > Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. > make/CompileJavaClasses.gmk > > Also use PollingWatchService on AIX. > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. > src/share/classes/java/nio/file/CopyMoveHelper.java > > As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > Support "compound text" on AIX in the same way like on other Unix platforms. > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > Define the correct attach provider for AIX. > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. > While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. > Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). > src/solaris/classes/java/lang/UNIXProcess.java.aix > > On AIX the implementation is especially tricky, because the close() system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. > src/share/transport/socket/socketTransport.c > > On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. > Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. > src/solaris/native/java/net/NetworkInterface.c > > Set the scope identifier for IPv6 addresses on AIX. > src/solaris/native/java/net/net_util_md.c > > It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. > Also fixed a comment and removed unused local variables. > Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. > src/solaris/native/sun/management/OperatingSystemImpl.c > > AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140115/691071b6/attachment-0001.html From Alan.Bateman at oracle.com Wed Jan 15 01:03:17 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Jan 2014 09:03:17 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D629A0.4080806@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> Message-ID: <52D64ED5.4020409@oracle.com> On 15/01/2014 06:24, David Holmes wrote: > > I'm not a fan of runtime checks of this kind though if it is only a > very samll number of values it might be okay. > > Another option would be to make those classes into "templates" as done > with Version.java.template and substitute the right values at build time. > > But I'll let Alan and net-dev folk come back with their preferred > technique for this. > I plan to spend time on Volker's webrev later in the week (just too busy with other things right now). For the translation issue then it's an oversight in the original implementation, it just hasn't come up before (to my knowledge anyway). The simplest solution here maybe to to just move them to sun.net.ch.Net and have them initialized to their native value. In general then I'm not too concerned about that one, it's the changes to support async close on AIX that are leaping out at me. -Alan From yekaterina.kantserova at oracle.com Wed Jan 15 01:13:42 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 15 Jan 2014 10:13:42 +0100 Subject: RFR (S): 7185591: jcmd-big-script.sh ERROR: could not find app's Java pid. In-Reply-To: References: <52CFEC7F.4040207@oracle.com> Message-ID: <52D65146.4000700@oracle.com> Staffan, thank you for pointing out performance and test.src issues! The webrev with fixes can be found here: http://cr.openjdk.java.net/~ykantser/7185591/webrev.01/ Please, see my comments in-lined. Thanks, Katja On 01/13/2014 01:19 PM, Staffan Larsen wrote: > Katja, > > test/lib/testlibrary/jdk/testlibrary/JcmdBase.java > 68 * Run jcmd standalone > > I think you should expand a bit on what ?standalone? means here. It took me a while to understand the difference. Fixed. > > test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java > 423 public int indexOf(String pattern) { > > This seems very inefficient. Add all lines to an ArrayList and then walk through them one at a time to if it matches and then walk through them once again to find the index of that line. > > 469 public int shouldMatchByLine(String from, String to, String pattern) { > > Same inefficiency here, but worse because both asLines() and indexOf() does the same work. > > test/lib/testlibrary/jdk/testlibrary/Utils.java > 65 public static final String TEST_SRC = System.getProperty("test.src").trim(); Fixed. > > I wonder if this really works. Isn?t ?test.src? different for different tests? A property that jtreg changes Yes, it is different. > before invoking each test? Or does this work because each test is run in a different class loader and Utils.java will exist once in each class loader? I've learned now it works because jtreg compiles all classes a test needs to a separate location. For example when I run TestJcmdDefaults there will be both TestJcmdDefaults.class and jdk/testlibrary/Utils.class under /tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/. The class loader will load Utils for TestJcmdDefaults from /tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/. ... [Loaded jdk.testlibrary.Utils from file:/tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/] ... But I think it's better to declare TEST_SRC per test precisely because it's different for different tests. > > > /Staffan > > > On 10 jan 2014, at 13:50, Yekaterina Kantserova wrote: > >> Hi, >> >> Could I please have a review of this fix. >> >> In this fix I've rewritten sun/tools/jcmd/* tests in pure java to get rid of all intermittent failures depending on for example MKS or race conditions (test application has not yet started when the test start to run). >> >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/7185591/webrev.00/ >> >> Primal bug: >> https://bugs.openjdk.java.net/browse/JDK-7185591 >> >> Similar bugs: >> https://bugs.openjdk.java.net/browse/JDK-6977426 >> https://bugs.openjdk.java.net/browse/JDK-8020798 >> https://bugs.openjdk.java.net/browse/JDK-7130656 (this one is blocked by https://bugs.openjdk.java.net/browse/JDK-8031482 so far) >> >> Thanks, >> Katja From staffan.larsen at oracle.com Wed Jan 15 02:37:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 11:37:42 +0100 Subject: RFR (S): 7185591: jcmd-big-script.sh ERROR: could not find app's Java pid. In-Reply-To: <52D65146.4000700@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D65146.4000700@oracle.com> Message-ID: <7384F0AF-3FCF-4551-A506-EB4E7EC25618@oracle.com> Katja, test/lib/testlibrary/jdk/testlibrary/JcmdBase.java The toolArgs parameter should be renamed jcmdArgs. test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java 423 public int indexOf(String pattern) { You don?t have to convert the List to an array before iterating through it. Use lLines.get(i).matches(?) instead. 470 public int shouldMatchByLine(String from, String to, String pattern) { This method still reads the lines into an ArrayList (at most) three times. It calls asLines() once and indexOf() twice. There could be a version of indexOf() that takes a List. Actually indexOf could be private and always take a List. Otherwise ok! /Staffan On 15 jan 2014, at 10:13, Yekaterina Kantserova wrote: > Staffan, thank you for pointing out performance and test.src issues! > > The webrev with fixes can be found here: > http://cr.openjdk.java.net/~ykantser/7185591/webrev.01/ > > Please, see my comments in-lined. > > Thanks, > Katja > > > > On 01/13/2014 01:19 PM, Staffan Larsen wrote: >> Katja, >> >> test/lib/testlibrary/jdk/testlibrary/JcmdBase.java >> 68 * Run jcmd standalone >> >> I think you should expand a bit on what ?standalone? means here. It took me a while to understand the difference. > Fixed. >> >> test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java >> 423 public int indexOf(String pattern) { >> >> This seems very inefficient. Add all lines to an ArrayList and then walk through them one at a time to if it matches and then walk through them once again to find the index of that line. >> >> 469 public int shouldMatchByLine(String from, String to, String pattern) { >> >> Same inefficiency here, but worse because both asLines() and indexOf() does the same work. >> >> test/lib/testlibrary/jdk/testlibrary/Utils.java >> 65 public static final String TEST_SRC = System.getProperty("test.src").trim(); > Fixed. >> >> I wonder if this really works. Isn?t ?test.src? different for different tests? A property that jtreg changes > Yes, it is different. >> before invoking each test? Or does this work because each test is run in a different class loader and Utils.java will exist once in each class loader? > I've learned now it works because jtreg compiles all classes a test needs to a separate location. For example when I run TestJcmdDefaults there will be both TestJcmdDefaults.class and jdk/testlibrary/Utils.class under /tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/. The class loader will load Utils for TestJcmdDefaults from /tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/. > > ... > [Loaded jdk.testlibrary.Utils from file:/tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/] > ... > > But I think it's better to declare TEST_SRC per test precisely because it's different for different tests. > >> >> >> /Staffan >> >> >> On 10 jan 2014, at 13:50, Yekaterina Kantserova wrote: >> >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> In this fix I've rewritten sun/tools/jcmd/* tests in pure java to get rid of all intermittent failures depending on for example MKS or race conditions (test application has not yet started when the test start to run). >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ykantser/7185591/webrev.00/ >>> >>> Primal bug: >>> https://bugs.openjdk.java.net/browse/JDK-7185591 >>> >>> Similar bugs: >>> https://bugs.openjdk.java.net/browse/JDK-6977426 >>> https://bugs.openjdk.java.net/browse/JDK-8020798 >>> https://bugs.openjdk.java.net/browse/JDK-7130656 (this one is blocked by https://bugs.openjdk.java.net/browse/JDK-8031482 so far) >>> >>> Thanks, >>> Katja -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140115/c7e6cdc0/attachment.html From volker.simonis at gmail.com Wed Jan 15 03:05:14 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 12:05:14 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D64ED5.4020409@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > On 15/01/2014 06:24, David Holmes wrote: > >> >> I'm not a fan of runtime checks of this kind though if it is only a very >> samll number of values it might be okay. >> >> Another option would be to make those classes into "templates" as done >> with Version.java.template and substitute the right values at build time. >> >> But I'll let Alan and net-dev folk come back with their preferred >> technique for this. >> >> I plan to spend time on Volker's webrev later in the week (just too busy > with other things right now). For the translation issue then it's an > oversight in the original implementation, it just hasn't come up before (to > my knowledge anyway). The simplest solution here maybe to to just move them > to sun.net.ch.Net and have them initialized to their native value. Do you mean sun.nio.ch.Net right? Do you propose to completely remove the definitions of the POLL constants from: src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java src/solaris/classes/sun/nio/ch/Port.java and replace all their usages by Net.POLL* ? > In general then I'm not too concerned about that one, it's the changes to > support async close on AIX that are leaping out at me. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140115/d0df4591/attachment.html From yekaterina.kantserova at oracle.com Wed Jan 15 06:30:03 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 15 Jan 2014 15:30:03 +0100 Subject: RFR (S): 7185591: jcmd-big-script.sh ERROR: could not find app's Java pid. In-Reply-To: <7384F0AF-3FCF-4551-A506-EB4E7EC25618@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D65146.4000700@oracle.com> <7384F0AF-3FCF-4551-A506-EB4E7EC25618@oracle.com> Message-ID: <52D69B6B.3010609@oracle.com> Staffan, The webrev with changes can be found here: http://cr.openjdk.java.net/~ykantser/7185591/webrev.02/ If it looks good, could you please be my sponsor and push the changes? The patch is attached to this mail. Thanks, Katja On 01/15/2014 11:37 AM, Staffan Larsen wrote: > Katja, > > test/lib/testlibrary/jdk/testlibrary/JcmdBase.java > The toolArgs parameter should be renamed jcmdArgs. > > test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java > 423 public int indexOf(String pattern) { > You don?t have to convert the List to an array before iterating > through it. Use lLines.get(i).matches(?) instead. > > 470 public int shouldMatchByLine(String from, String to, String > pattern) { > This method still reads the lines into an ArrayList (at most) three > times. It calls asLines() once and indexOf() twice. There could be a > version of indexOf() that takes a List. Actually indexOf could > be private and always take a List. > > > Otherwise ok! > > /Staffan > > > > On 15 jan 2014, at 10:13, Yekaterina Kantserova > > wrote: > >> Staffan, thank you for pointing out performance and test.src issues! >> >> The webrev with fixes can be found here: >> http://cr.openjdk.java.net/~ykantser/7185591/webrev.01/ >> >> >> Please, see my comments in-lined. >> >> Thanks, >> Katja >> >> >> >> On 01/13/2014 01:19 PM, Staffan Larsen wrote: >>> Katja, >>> >>> test/lib/testlibrary/jdk/testlibrary/JcmdBase.java >>> 68 * Run jcmd standalone >>> >>> I think you should expand a bit on what ?standalone? means here. It >>> took me a while to understand the difference. >> Fixed. >>> >>> test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java >>> 423 public int indexOf(String pattern) { >>> >>> This seems very inefficient. Add all lines to an ArrayList and then >>> walk through them one at a time to if it matches and then walk >>> through them once again to find the index of that line. >>> >>> 469 public int shouldMatchByLine(String from, String to, String >>> pattern) { >>> >>> Same inefficiency here, but worse because both asLines() and >>> indexOf() does the same work. >>> >>> test/lib/testlibrary/jdk/testlibrary/Utils.java >>> 65 public static final String TEST_SRC = >>> System.getProperty("test.src").trim(); >> Fixed. >>> >>> I wonder if this really works. Isn?t ?test.src? different for >>> different tests? A property that jtreg changes >> Yes, it is different. >>> before invoking each test? Or does this work because each test is >>> run in a different class loader and Utils.java will exist once in >>> each class loader? >> I've learned now it works because jtreg compiles all classes a test >> needs to a separate location. For example when I run TestJcmdDefaults >> there will be both TestJcmdDefaults.class and >> jdk/testlibrary/Utils.class under >> /tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/. The class loader >> will load Utils for TestJcmdDefaults from >> /tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/. >> >> ... >> [Loaded jdk.testlibrary.Utils from >> file:/tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/] >> ... >> >> But I think it's better to declare TEST_SRC per test precisely >> because it's different for different tests. >> >>> >>> >>> /Staffan >>> >>> >>> On 10 jan 2014, at 13:50, Yekaterina Kantserova >>> >> > wrote: >>> >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> In this fix I've rewritten sun/tools/jcmd/* tests in pure java to >>>> get rid of all intermittent failures depending on for example MKS >>>> or race conditions (test application has not yet started when the >>>> test start to run). >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ykantser/7185591/webrev.00/ >>>> >>>> >>>> Primal bug: >>>> https://bugs.openjdk.java.net/browse/JDK-7185591 >>>> >>>> Similar bugs: >>>> https://bugs.openjdk.java.net/browse/JDK-6977426 >>>> https://bugs.openjdk.java.net/browse/JDK-8020798 >>>> https://bugs.openjdk.java.net/browse/JDK-7130656 (this one is >>>> blocked by https://bugs.openjdk.java.net/browse/JDK-8031482 so far) >>>> >>>> Thanks, >>>> Katja > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140115/fe93a007/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 7185591.2.patch Type: text/x-patch Size: 37773 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140115/fe93a007/7185591.2-0001.patch From taras.ledkov at oracle.com Wed Jan 15 07:15:38 2014 From: taras.ledkov at oracle.com (taras ledkov) Date: Wed, 15 Jan 2014 19:15:38 +0400 Subject: Review request for 7195249: Some jtreg tests use hard coded ports In-Reply-To: References: <529EF58F.5000701@oracle.com> <52A58687.6020708@oracle.com> <52A5953A.5040102@oracle.com> <52A7061E.8040002@oracle.com> <52BC2A7D.3070403@oracle.com> Message-ID: <52D6A61A.5020109@oracle.com> Hi, Please take a look at the new review. Webrev for jdk part: http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.02/ Webrev for hs part: http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.02/ My answers are inline: On 08.01.2014 17:46, Staffan Larsen wrote: > Hi Taras, > > Thanks for doing this clean up and conversion of tests into Java. Here?s a couple of comments: > > test/runtime/6294277/SourceDebugExtension.java: > This test could be simplified by not specifying an address at all. Since the test never connects to the JVM started with -Xrunjdwp, there is no reason to specify an address. If address is unspecified (and server=y), the connector will pick an address and print it to the command line. Thus the only change that needs to be done is to remove ",address=8888? from the @run command. fixed > test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh: > test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh: > These tests do not compile cleanly with an empty JTwork directory. It seems that having one @build for each class does not work well - when compiling RmiBootstrapTest.java it cannot find TestLogger. Moving all classes to one @build statement solved this problem for me. fixed > test/lib/testlibrary/jdk/testlibrary/ProcessTools.java: > 187 Future stdoutTask = stdout.process(); > 188 Future stderrTask = stderr.process(); > The stdoutTask and stderrTask variables are unused. fixed > test/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java: > At first I thought something was wrong with this file - the diff is very weird. Then I realized you renamed an old file and created a new file using the old name. You are right. I did it to keep the test name. > test/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java: > - Is resetPasswordFilePermission() really necessary? It looks like you delete the files at the beginning of the test in any case. I think yes. n the first place, this functionality was at the old code. In the second place, a file without write permission may be a problem for a further cleanup (not by the test, for example for the tests launcher scripts etc.) > - I find the names and usage of ?mgmt? and ?file2PermissionTest? confusing. They are both Paths. One is used directly by the sub-classes, the other has a getter method. fixed > - Lines 57-58: Don?t swallow exceptions, add an ex.printStackTrace(). (Same thing for all other places where you call Integer.parseInt()) fixed > test/sun/management/jmxremote/bootstrap/Dummy.java: > This file is never used as far as I can see. It is used by PasswordFilePermissionTest & SSLConfigFilePermissionTest via the AbstractFilePermissionTest (see the doTest method, AbstractFilePermissionTest : 162). > Thanks, > /Staffan > > > > > > On 26 dec 2013, at 14:09, taras ledkov wrote: > >> Hi, >> >> Please take a look at the review with fixed issues about trying to launch test that needs free port several times. >> >> Webrev for jdk part: >> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.01/ >> >> Webrev for hs part: >> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.01/ >> >> Pay your attention to new method ProcessTools.startProcess(String, ProcessBuilder, Consumer) that is used to analyze all output of a sub-process. It has common part with >> ProcessTools.startProcess(String, ProcessBuilder, Predicate, long, TumeUnit) that is used to determine the warm-up moment. >> >> I think the ProcessTools.startProcess(String, ProcessBuilder, Predicate, long, TumeUnit) may be changed by adding LinePump to stderr if there is not serious reason for restricting the warm-up analysis to stdout stream. >> >> On 10.12.2013 16:16, Yekaterina Kantserova wrote: >>> Hi, >>> >>> I've consulted with Serviceability engineers (add them to CC list) and >>> they would like to see tests to solve these problem so far: >>> >>> 2. Implement loops in every test. >>> >>> Thanks, >>> Katja >>> >>> >>> On 12/09/2013 11:02 AM, Alexandre (Shura) Iline wrote: >>>> Guys. >>>> >>>> Let me try to sum up what was said before and may be suggest a >>>> compromise. >>>> >>>> 1. There is a desire to have a support port allocation on the level of >>>> a JTReg suite execution. Taras created a bug for that >>>> (https://bugs.openjdk.java.net/browse/JDK-7195249). Whether it is a >>>> test harness API or a library API does not really matter from usage >>>> point of view. >>>> >>>> 2. There is no way to make the tests absolutely stable, whatever port >>>> allocation logic is used. The best we could do is to try to perform >>>> the test logic with different ports until the test succeeds. >>>> >>>> Both arguments make sense. #2 is the ultimate answer, of course, but >>>> better be used in conjunction with a meaningful port selection algorithm. >>>> >>>> At the same time, copying a loop-until-success login from one test to >>>> another may be not the best solution. Library could help with that I >>>> believe. There only need to be an API method which takes behavior as a >>>> parameter and run it until it succeeds. Something like: >>>> public runOnAFreePort(Function) >>>> or similar. There could be arguments of how/whether to implement it, >>>> the solution would not work for shell tests, etc, but still ... >>>> >>>> >>>> With the tests in question though, we have a few options. >>>> >>>> 1. Integrate tests as is. Get to it later after reaching agreement in >>>> the library, etc. >>>> 2. Implement loops in every test. >>>> 3. Wait for the library to be ready and only then integrate the changes. >>>> >>>> Please let us know which one is closer to your heart. >>>> >>>> I personally prefer #1 for the reason that the changes already >>>> supposed to make the tests more stable and also there are many more >>>> tests tests which use ports, so the scope of the problem is bigger >>>> than these. >>>> >>>> Shura >>>> >>>> >>>>> Taras, >>>>> >>>>> I agree with the previous comments, that Utils.getFreePort() does not >>>>> guarantee the port will be still free when you start your process. >>>>> Unfortunately I don't think the library can do more. However, there is a >>>>> solution. >>>>> >>>>> Please, look at the *jdk/test/sun/tools/jstatd/JstatdTest.java >>>>> tryToSetupJstatdProcess()*. In brief, the test will try to start a >>>>> process with a free port and then check if >>>>> /java.rmi.server.ExportException: Port already in use/ has been thrown. >>>>> If yes, you have to retry. >>>>> >>>>> Thanks, >>>>> Katja >>>>> >>>>> >>>>> >>>>> On 12/02/2013 01:39 PM, taras ledkov wrote: >>>>>> Hi Everyone, >>>>>> >>>>>> Whatever logic is to be chosen to select a free port, it is the >>>>>> library responsibility to implements it, would not you agree? >>>>>> >>>>>> Hence what I am suggesting is to integrate the tests as is. >>>>>> >>>>>> Should we decide to replace logic of the port selection, we could do >>>>>> it later in the library. >>>>>> >>>>>> On 21.11.2013 15:00, Jaroslav Bachorik wrote: >>>>>>> On 20.11.2013 18:38, Dmitry Samersoff wrote: >>>>>>>> Roger, >>>>>>>> >>>>>>>> As soon as we close a socket nobody can guarantee that the port is >>>>>>>> free. >>>>>>>> >>>>>>>> Moreover, port returned by getFreePort()[1] remains not accessible >>>>>>>> for >>>>>>>> some time - it depends to system setup, take a look to discussions >>>>>>>> around SO_REUSEPORT for Linux or SO_REUSEADDR and SO_LINGER for BSD. >>>>>>>> >>>>>>>> So from stability point of view it's better to just return random >>>>>>>> number >>>>>>>> between 49152 and 65535. >>>>>>> >>>>>>> Well, this doesn't seem to improve the odds by much. When there are >>>>>>> more >>>>>>> tests run in parallel, all of them requiring a free port, nothing >>>>>>> prevents the random function to return the same port to all of them. >>>>>>> Also, two subsequent requests can return the same port and cause >>>>>>> problems with timing when a port used by a previous test is not fully >>>>>>> ready to be assigned to a different socket. And as Dmitry pointed out >>>>>>> unless one can keep hold of the allocated socket and use it later >>>>>>> there >>>>>>> is no guarantee that a port which was tested unallocated will remain >>>>>>> unallocated also for the next few milliseconds. >>>>>>> >>>>>>> The only fail proof solution would be a port allocating service >>>>>>> provided >>>>>>> by the harness. Until then we can only (hopefully) decrease the chance >>>>>>> of intermittent failures due to a port being in use. >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>>>> 141 public static int getFreePort() throws InterruptedException, >>>>>>>> IOException { >>>>>>>> 142 int port = -1; >>>>>>>> 143 >>>>>>>> 144 while (port <= 0) { >>>>>>>> 145 Thread.sleep(100); >>>>>>>> 146 >>>>>>>> 147 ServerSocket serverSocket = null; >>>>>>>> 148 try { >>>>>>>> 149 serverSocket = new ServerSocket(0); >>>>>>>> 150 port = serverSocket.getLocalPort(); >>>>>>>> 151 } finally { >>>>>>>> 152 serverSocket.close(); >>>>>>>> 153 } >>>>>>>> 154 } >>>>>>>> 155 >>>>>>>> 156 return port; >>>>>>>> 157 } >>>>>>>> 158 >>>>>>>> >>>>>>>> >>>>>>>> On 2013-11-20 19:40, roger riggs wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> fyi, The jdk.testlibrary.Utils.getFreePort() method will Open an >>>>>>>>> free >>>>>>>>> Socket, close it and return >>>>>>>>> the port number. >>>>>>>>> >>>>>>>>> And as Alan recommended, use (0) when possible to have the system >>>>>>>>> assign >>>>>>>>> the port #. >>>>>>>>> >>>>>>>>> Roger >>>>>>>>> >>>>>>>>> On 11/20/2013 8:04 AM, Dmitry Samersoff wrote: >>>>>>>>>> Taras, >>>>>>>>>> >>>>>>>>>> *The only* correct way to take really free port is: >>>>>>>>>> >>>>>>>>>> 1. Chose random number between 49152 and 65535 >>>>>>>>>> 2. Open socket >>>>>>>>>> >>>>>>>>>> if socket fails - repeat step 1 >>>>>>>>>> if socket OK - return *socket* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If you can't keep the socket open (e.g. you have to pass port >>>>>>>>>> number as >>>>>>>>>> property value) you shouldn't do any pre-check as it has no value >>>>>>>>>> - as >>>>>>>>>> as soon as you close socket someone can take the port. >>>>>>>>>> >>>>>>>>>> So just choose a random number within the range above and let >>>>>>>>>> networking >>>>>>>>>> code opening socket to handle port conflict. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2013-11-20 15:54, taras ledkov wrote: >>>>>>>>>>> Hi Everyone, >>>>>>>>>>> >>>>>>>>>>> I am working on bug >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7195249. >>>>>>>>>>> >>>>>>>>>>> There are two webrevs: >>>>>>>>>>> Webrev for jdk part: >>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Webrev for hs part: >>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Please take a look at some notes: >>>>>>>>>>> - After discussing with Yekaterina Kantserova & Jaroslav Bachorik >>>>>>>>>>> some >>>>>>>>>>> shell tests have been converted to java based tests >>>>>>>>>>> >>>>>>>>>>> - PasswordFilePermissionTest & SSLConfigFilePermissionTest tests >>>>>>>>>>> looked >>>>>>>>>>> very similar, so a common parent class was created for them: >>>>>>>>>>> AbstractFilePermissionTest >>>>>>>>>>> >>>>>>>>>>> - What was called RmiRegistrySslTest.java I've renamed to >>>>>>>>>>> RmiRegistrySslTestApp.java. The java code to replace old shell >>>>>>>>>>> script >>>>>>>>>>> RmiRegistrySslTest.sh is called RmiRegistrySslTest.java, hence the >>>>>>>>>>> huge >>>>>>>>>>> diff. >>>>>>>>>>> >>>>>>>>>>> - The new RmiRegistrySslTest.java has some lines similar to the >>>>>>>>>>> AbstractFilePermissionTest.java, I nevertheless decided to not >>>>>>>>>>> complicate the code further and leave it as is. Please let me >>>>>>>>>>> know if >>>>>>>>>>> this is somehow not acceptable >>>>>>>>>>> >>>>>>>>>>> - com/oracle/java/testlibrary/Utils.java that is added to hotspot >>>>>>>>>>> repository is taken from this patch: >>>>>>>>>>> http://cr.openjdk.java.net/~ykantser/8023138/webrev.00/test/lib/testlibrary/jdk/testlibrary/Utils.java.sdiff.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - These tests will need additional changes when test library >>>>>>>>>>> process >>>>>>>>>>> tools will support command line options inheritance >>>>>>>>>>> (http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-November/013235.html) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >> >> -- >> With best regards, >> Taras Ledkov >> Mail-To: taras.ledkov at oracle.com >> skype: taras_ledkov >> Phone: 7(812)3346-157 > -- With best regards, Taras Ledkov Mail-To: taras.ledkov at oracle.com skype: taras_ledkov Phone: 7(812)3346-157 From volker.simonis at gmail.com Wed Jan 15 08:34:58 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 17:34:58 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: Hi Staffan, thanks for the review. Please find my comments inline: On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen wrote: > Volker, > > I?ve look at the following files: > > src/share/native/sun/management/DiagnosticCommandImpl.c: > nit: ?legel? -> ?legal? (two times) > In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if > you allow dcmd_info_array to become NULL, > then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you > need to check that. > Good catch. I actually had problems with malloc returning NULL in 'getDiagnosticCommandArgumentInfoArray()' and then changed all other potentially dangerous locations which used the same pattern. However I think if the 'dcmd_info_array' has zero length it would be perfectly fine to return a zero length array. So what about the following solution: dcmdInfoCls = (*env)->FindClass(env, "sun/management/DiagnosticCommandInfo"); num_commands = (*env)->GetArrayLength(env, commands); if (num_commands = 0) { result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); if (result == NULL) { JNU_ThrowOutOfMemoryError(env, 0); } else { return result; } } dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); if (dcmd_info_array == NULL) { JNU_ThrowOutOfMemoryError(env, NULL); } jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); That seems easier and saves me from handling the exception. What do you think? src/solaris/native/sun/management/OperatingSystemImpl.c > No comments. > > src/share/transport/socket/socketTransport.c > No comments. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > No comments. > > > Thanks, > /Staffan > > > > On 14 jan 2014, at 09:40, Volker Simonis wrote: > > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration into > ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: > Updated jdk/test scripts to understand the AIX os and environment" and > "8031134 : PPC64: implement printing on AIX") our port passes all but the > following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 > baseline from www.java.net/download/jdk8/testresults/testresults.html?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > - According to ISO C it is perfectly legal for malloc to return zero > if called with a zero argument. Fix various places where malloc can > potentially correctly return zero because it was called with a zero > argument. > - Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only > fixes a compiler warning on Linux, but on AIX it prevents a VM crash later > on because the return value of malloc() will be casted to int which is > especially bad if that pointer was bigger than 32-bit. > > make/CompileJavaClasses.gmk > > - Also use PollingWatchService on AIX. > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > - Put the implementation for the native methods of NativeThread into > AixNativeThread.c on AIX. > > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > - On AIX, the constants used for the polling events (i.e. POLLIN, > POLLOUT, ...) are defined to different values than on other operating > systems. The problem is however, that these constants are hardcoded as > public final static members of various, shared Java classes. We therefore > have to map them from Java to native every time before calling one of the > native poll functions and back to Java after the call on AIX in order to > get the right semantics. > > src/share/classes/java/nio/file/CopyMoveHelper.java > > - As discussed on the core-libs mailing list (see > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > it is not necessary to call Files.getFileAttributeView() with any > linkOptions because at that place we've already checked that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support symbolic links but do > not support the O_NOFOLLOW flag to the open system call. It also makes > the JDK pass the demo/zipfs/basic.sh test on AIX. > > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > - Support "compound text" on AIX in the same way like on other Unix > platforms. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > - Define the correct attach provider for AIX. > > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > - AIX needs a workaround for I/O cancellation (see: > http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > "..The close() subroutine is blocked until all subroutines which use > the file descriptor return to usr space. For example, when a thread is > calling close and another thread is calling select with the same file > descriptor, the close subroutine does not return until the select call > returns...". To fix this problem, we have to use the various NET_wrappers which are declared in > net_util_md.h and defined in aix_close.c and we also need some > additional wrappers for fcntl(), read() and write() on AIX. > While the current solution isn't really nice because it introduces > some more AIX-specifc sections in shared code, I think it is the best way > to go for JDK 8 because it imposes the smallest possible changes and risks > for the existing platforms. I'm ready to change the code to unconditionally > use the wrappers for all platforms and implement the wrappers empty on > platforms which don't need any wrapping. I think it would also be nice to > clean up the names (e.g. NET_Read() is currently a wrapper for recv()and the > NET_ prefix is probably not appropriate any more so maybe change it to > something like IO_). But again, I'll prefer to keep that as a follow > up change for JDK9. > - Calling fsync() on a "read-only" file descriptor on AIX will result > in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file > descriptor open for writing."). To prevent this error we have to query if > the corresponding file descriptor is writeable. Notice that at that point > we can not access the writable attribute of the corresponding file > channel so we have to use fcntl(). > > src/solaris/classes/java/lang/UNIXProcess.java.aix > > - On AIX the implementation is especially tricky, because the close()system call will block if another thread is at the same time blocked in a > file operation (e.g. 'read()') on the same file descriptor. We therefore > combine the AIX ProcessPipeInputStream implemenatation with the > DeferredCloseInputStream approach used on Solaris (see > UNIXProcess.java.solaris). This means that every potentially blocking > operation on the file descriptor increments a counter before it is executed > and decrements it once it finishes. The 'close()' operation will only be > executed if there are no pending operations. Otherwise it is deferred after > the last pending operation has finished. > > src/share/transport/socket/socketTransport.c > > - On AIX we have to call shutdown() on a socket descriptor before > closing it, otherwise the close() call may be blocked. This is the > same problem as described before. Unfortunately the JDI framework doesn't > use the same IO wrappers like other class library components so we can not > easily use the NET_ abstractions from aix_close.c here. > - Without this small change all JDI regression tests will fail on AIX > because of the way how the tests act as a "debugger" which launches another > VM (the "debugge") which connects itself back to the debugger. In this > scenario the "debugge" can not shut down itself because one thread will > always be blocked in the close() call on one of the communication > sockets. > > src/solaris/native/java/net/NetworkInterface.c > > - Set the scope identifier for IPv6 addresses on AIX. > > src/solaris/native/java/net/net_util_md.c > > - It turns out that we do not always have to replace SO_REUSEADDR on > AIX by SO_REUSEPORT. Instead we can simply use the same approach like > BSD and only use SO_REUSEPORT additionally, if several datagram > sockets try to bind to the same port. > - Also fixed a comment and removed unused local variables. > - Fixed the obviously inverted assignment newTime = prevTime; which > should read prevTime = newTime;. Otherwise prevTime will never change > and the timeout will be potential reached too fast. > > src/solaris/native/sun/management/OperatingSystemImpl.c > > - AIX does not understand /proc/self so we have to query the real > process ID to access the proc file system. > > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > - On AIX, connect() may legally return EAFNOSUPPORT if called on a > socket with the address family set to AF_UNSPEC. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140115/6f1cd9ba/attachment-0001.html From volker.simonis at gmail.com Wed Jan 15 09:27:01 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 18:27:01 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > wrote: >> >> Volker, >> >> I?ve look at the following files: >> >> src/share/native/sun/management/DiagnosticCommandImpl.c: >> nit: ?legel? -> ?legal? (two times) >> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >> you allow dcmd_info_array to become NULL, then >> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >> check that. > > > Good catch. I actually had problems with malloc returning NULL in > 'getDiagnosticCommandArgumentInfoArray()' and then changed all other > potentially dangerous locations which used the same pattern. > > However I think if the 'dcmd_info_array' has zero length it would be > perfectly fine to return a zero length array. So what about the following > solution: > > dcmdInfoCls = (*env)->FindClass(env, > "sun/management/DiagnosticCommandInfo"); > num_commands = (*env)->GetArrayLength(env, commands); Sorry, of course I wanted to say "if (num_commands == 0)" here! > if (num_commands = 0) { > result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > if (result == NULL) { > JNU_ThrowOutOfMemoryError(env, 0); > } > else { > return result; > } > } > dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > > That seems easier and saves me from handling the exception. > > What do you think? > >> src/solaris/native/sun/management/OperatingSystemImpl.c >> No comments. >> >> src/share/transport/socket/socketTransport.c >> No comments. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> No comments. >> >> >> Thanks, >> /Staffan >> >> >> >> On 14 jan 2014, at 09:40, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and >> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: >> Updated jdk/test scripts to understand the AIX os and environment" and >> "8031134 : PPC64: implement printing on AIX") our port passes all but the >> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> According to ISO C it is perfectly legal for malloc to return zero if >> called with a zero argument. Fix various places where malloc can potentially >> correctly return zero because it was called with a zero argument. >> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >> compiler warning on Linux, but on AIX it prevents a VM crash later on >> because the return value of malloc() will be casted to int which is >> especially bad if that pointer was bigger than 32-bit. >> >> make/CompileJavaClasses.gmk >> >> Also use PollingWatchService on AIX. >> >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> Put the implementation for the native methods of NativeThread into >> AixNativeThread.c on AIX. >> >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >> ...) are defined to different values than on other operating systems. The >> problem is however, that these constants are hardcoded as public final >> static members of various, shared Java classes. We therefore have to map >> them from Java to native every time before calling one of the native poll >> functions and back to Java after the call on AIX in order to get the right >> semantics. >> >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> As discussed on the core-libs mailing list (see >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) >> it is not necessary to call Files.getFileAttributeView() with any >> linkOptions because at that place we've already checked that the target file >> can not be a symbolic link. This change makes the implementation more robust >> on platforms which support symbolic links but do not support the O_NOFOLLOW >> flag to the open system call. It also makes the JDK pass the >> demo/zipfs/basic.sh test on AIX. >> >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> Support "compound text" on AIX in the same way like on other Unix >> platforms. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> >> Define the correct attach provider for AIX. >> >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> AIX needs a workaround for I/O cancellation (see: >> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >> "..The close() subroutine is blocked until all subroutines which use the >> file descriptor return to usr space. For example, when a thread is calling >> close and another thread is calling select with the same file descriptor, >> the close subroutine does not return until the select call returns...". To >> fix this problem, we have to use the various NET_ wrappers which are >> declared in net_util_md.h and defined in aix_close.c and we also need some >> additional wrappers for fcntl(), read() and write() on AIX. >> While the current solution isn't really nice because it introduces some >> more AIX-specifc sections in shared code, I think it is the best way to go >> for JDK 8 because it imposes the smallest possible changes and risks for the >> existing platforms. I'm ready to change the code to unconditionally use the >> wrappers for all platforms and implement the wrappers empty on platforms >> which don't need any wrapping. I think it would also be nice to clean up the >> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >> is probably not appropriate any more so maybe change it to something like >> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >> Calling fsync() on a "read-only" file descriptor on AIX will result in an >> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >> descriptor open for writing."). To prevent this error we have to query if >> the corresponding file descriptor is writeable. Notice that at that point we >> can not access the writable attribute of the corresponding file channel so >> we have to use fcntl(). >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> On AIX the implementation is especially tricky, because the close() system >> call will block if another thread is at the same time blocked in a file >> operation (e.g. 'read()') on the same file descriptor. We therefore combine >> the AIX ProcessPipeInputStream implemenatation with the >> DeferredCloseInputStream approach used on Solaris (see >> UNIXProcess.java.solaris). This means that every potentially blocking >> operation on the file descriptor increments a counter before it is executed >> and decrements it once it finishes. The 'close()' operation will only be >> executed if there are no pending operations. Otherwise it is deferred after >> the last pending operation has finished. >> >> src/share/transport/socket/socketTransport.c >> >> On AIX we have to call shutdown() on a socket descriptor before closing >> it, otherwise the close() call may be blocked. This is the same problem as >> described before. Unfortunately the JDI framework doesn't use the same IO >> wrappers like other class library components so we can not easily use the >> NET_ abstractions from aix_close.c here. >> Without this small change all JDI regression tests will fail on AIX >> because of the way how the tests act as a "debugger" which launches another >> VM (the "debugge") which connects itself back to the debugger. In this >> scenario the "debugge" can not shut down itself because one thread will >> always be blocked in the close() call on one of the communication sockets. >> >> src/solaris/native/java/net/NetworkInterface.c >> >> Set the scope identifier for IPv6 addresses on AIX. >> >> src/solaris/native/java/net/net_util_md.c >> >> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >> the same port. >> Also fixed a comment and removed unused local variables. >> Fixed the obviously inverted assignment newTime = prevTime; which should >> read prevTime = newTime;. Otherwise prevTime will never change and the >> timeout will be potential reached too fast. >> >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> AIX does not understand /proc/self so we have to query the real process ID >> to access the proc file system. >> >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >> with the address family set to AF_UNSPEC. >> >> >> > From eric.mccorkle at oracle.com Wed Jan 15 09:47:32 2014 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Wed, 15 Jan 2014 17:47:32 +0000 Subject: hg: jdk8/tl/jdk: 8031502: JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter Message-ID: <20140115174752.A89E762486@hg.openjdk.java.net> Changeset: 9e91793fd516 Author: vlivanov Date: 2014-01-15 20:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e91793fd516 8031502: JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter Reviewed-by: sundar, lagergren, drchase ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java + test/java/lang/invoke/ObjectMethodInInterfaceTest.java From volker.simonis at gmail.com Wed Jan 15 09:52:39 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 18:52:39 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen < staffan.larsen at oracle.com> >> wrote: >>> >>> Volker, >>> >>> I?ve look at the following files: >>> >>> src/share/native/sun/management/DiagnosticCommandImpl.c: >>> nit: ?legel? -> ?legal? (two times) >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >>> you allow dcmd_info_array to become NULL, then >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >>> check that. >> >> >> Good catch. I actually had problems with malloc returning NULL in >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other >> potentially dangerous locations which used the same pattern. >> >> However I think if the 'dcmd_info_array' has zero length it would be >> perfectly fine to return a zero length array. So what about the following >> solution: >> Sorry for the noise - it seems I was a little indisposed during the last mails:) So this is the simple change I'd like to propose for Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo(): @@ -117,19 +119,23 @@ return NULL; } num_commands = (*env)->GetArrayLength(env, commands); - dcmd_info_array = (dcmdInfo*) malloc(num_commands * - sizeof(dcmdInfo)); + dcmdInfoCls = (*env)->FindClass(env, + "sun/management/DiagnosticCommandInfo"); + result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); + if (result == NULL) { + JNU_ThrowOutOfMemoryError(env, 0); + } + if (num_commands == 0) { + /* Handle the 'zero commands' case specially to avoid calling 'malloc()' */ + /* with a zero argument because that may legally return a NULL pointer. */ + return result; + } + dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); if (dcmd_info_array == NULL) { JNU_ThrowOutOfMemoryError(env, NULL); } jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); - dcmdInfoCls = (*env)->FindClass(env, - "sun/management/DiagnosticCommandInfo"); - result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); - if (result == NULL) { - free(dcmd_info_array); - JNU_ThrowOutOfMemoryError(env, 0); - } for (i=0; iGetObjectArrayElement(env,commands,i), If the 'commands' input array is of zero length just return a zero length array. OK? >> dcmdInfoCls = (*env)->FindClass(env, >> "sun/management/DiagnosticCommandInfo"); >> num_commands = (*env)->GetArrayLength(env, commands); > > Sorry, of course I wanted to say "if (num_commands == 0)" here! > >> if (num_commands = 0) { >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); >> if (result == NULL) { >> JNU_ThrowOutOfMemoryError(env, 0); >> } >> else { >> return result; >> } >> } >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); >> if (dcmd_info_array == NULL) { >> JNU_ThrowOutOfMemoryError(env, NULL); >> } >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); >> >> That seems easier and saves me from handling the exception. >> >> What do you think? >> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> No comments. >>> >>> src/share/transport/socket/socketTransport.c >>> No comments. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> No comments. >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >>> >>> I've build and smoke tested without any problems on Linux/x86_64 and >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >>> >>> With these changes (and together with the changes from "8028537: PPC64: >>> Updated jdk/test scripts to understand the AIX os and environment" and >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >>> >>> java/net/Inet6Address/B6558853.java >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >>> java/nio/channels/Selector/RacyDeregister.java >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> Following a detailed description of the various changes: >>> >>> src/share/native/java/util/zip/zip_util.c >>> src/share/native/sun/management/DiagnosticCommandImpl.c >>> >>> According to ISO C it is perfectly legal for malloc to return zero if >>> called with a zero argument. Fix various places where malloc can potentially >>> correctly return zero because it was called with a zero argument. >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >>> compiler warning on Linux, but on AIX it prevents a VM crash later on >>> because the return value of malloc() will be casted to int which is >>> especially bad if that pointer was bigger than 32-bit. >>> >>> make/CompileJavaClasses.gmk >>> >>> Also use PollingWatchService on AIX. >>> >>> make/lib/NioLibraries.gmk >>> src/aix/native/sun/nio/ch/AixNativeThread.c >>> >>> Put the implementation for the native methods of NativeThread into >>> AixNativeThread.c on AIX. >>> >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >>> src/solaris/native/sun/nio/ch/Net.c >>> src/aix/classes/sun/nio/ch/AixPollPort.java >>> src/aix/native/sun/nio/ch/AixPollPort.c >>> src/aix/native/java/net/aix_close.c >>> >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >>> ...) are defined to different values than on other operating systems. The >>> problem is however, that these constants are hardcoded as public final >>> static members of various, shared Java classes. We therefore have to map >>> them from Java to native every time before calling one of the native poll >>> functions and back to Java after the call on AIX in order to get the right >>> semantics. >>> >>> src/share/classes/java/nio/file/CopyMoveHelper.java >>> >>> As discussed on the core-libs mailing list (see >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html ) >>> it is not necessary to call Files.getFileAttributeView() with any >>> linkOptions because at that place we've already checked that the target file >>> can not be a symbolic link. This change makes the implementation more robust >>> on platforms which support symbolic links but do not support the O_NOFOLLOW >>> flag to the open system call. It also makes the JDK pass the >>> demo/zipfs/basic.sh test on AIX. >>> >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >>> >>> Support "compound text" on AIX in the same way like on other Unix >>> platforms. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> >>> Define the correct attach provider for AIX. >>> >>> src/solaris/native/java/net/net_util_md.h >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >>> >>> AIX needs a workaround for I/O cancellation (see: >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm ). >>> "..The close() subroutine is blocked until all subroutines which use the >>> file descriptor return to usr space. For example, when a thread is calling >>> close and another thread is calling select with the same file descriptor, >>> the close subroutine does not return until the select call returns...". To >>> fix this problem, we have to use the various NET_ wrappers which are >>> declared in net_util_md.h and defined in aix_close.c and we also need some >>> additional wrappers for fcntl(), read() and write() on AIX. >>> While the current solution isn't really nice because it introduces some >>> more AIX-specifc sections in shared code, I think it is the best way to go >>> for JDK 8 because it imposes the smallest possible changes and risks for the >>> existing platforms. I'm ready to change the code to unconditionally use the >>> wrappers for all platforms and implement the wrappers empty on platforms >>> which don't need any wrapping. I think it would also be nice to clean up the >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >>> is probably not appropriate any more so maybe change it to something like >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >>> descriptor open for writing."). To prevent this error we have to query if >>> the corresponding file descriptor is writeable. Notice that at that point we >>> can not access the writable attribute of the corresponding file channel so >>> we have to use fcntl(). >>> >>> src/solaris/classes/java/lang/UNIXProcess.java.aix >>> >>> On AIX the implementation is especially tricky, because the close() system >>> call will block if another thread is at the same time blocked in a file >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine >>> the AIX ProcessPipeInputStream implemenatation with the >>> DeferredCloseInputStream approach used on Solaris (see >>> UNIXProcess.java.solaris). This means that every potentially blocking >>> operation on the file descriptor increments a counter before it is executed >>> and decrements it once it finishes. The 'close()' operation will only be >>> executed if there are no pending operations. Otherwise it is deferred after >>> the last pending operation has finished. >>> >>> src/share/transport/socket/socketTransport.c >>> >>> On AIX we have to call shutdown() on a socket descriptor before closing >>> it, otherwise the close() call may be blocked. This is the same problem as >>> described before. Unfortunately the JDI framework doesn't use the same IO >>> wrappers like other class library components so we can not easily use the >>> NET_ abstractions from aix_close.c here. >>> Without this small change all JDI regression tests will fail on AIX >>> because of the way how the tests act as a "debugger" which launches another >>> VM (the "debugge") which connects itself back to the debugger. In this >>> scenario the "debugge" can not shut down itself because one thread will >>> always be blocked in the close() call on one of the communication sockets. >>> >>> src/solaris/native/java/net/NetworkInterface.c >>> >>> Set the scope identifier for IPv6 addresses on AIX. >>> >>> src/solaris/native/java/net/net_util_md.c >>> >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >>> the same port. >>> Also fixed a comment and removed unused local variables. >>> Fixed the obviously inverted assignment newTime = prevTime; which should >>> read prevTime = newTime;. Otherwise prevTime will never change and the >>> timeout will be potential reached too fast. >>> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> >>> AIX does not understand /proc/self so we have to query the real process ID >>> to access the proc file system. >>> >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >>> >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >>> with the address family set to AF_UNSPEC. >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140115/6fe475ef/attachment-0001.html From dmitry.samersoff at oracle.com Wed Jan 15 10:23:48 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Jan 2014 22:23:48 +0400 Subject: RR(XS): JDK-8024049 com/sun/jdi/ProcessAttachTest.sh shortens 7-digit pid to 6-digit Message-ID: <52D6D234.1060704@oracle.com> Hi Everybody, Please review small, test-only fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8024049/webrev.01/ fix summary: grep/cut chain is replaced with awk. -- 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 staffan.larsen at oracle.com Wed Jan 15 11:02:26 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:02:26 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: Yes, that looks like a good solution. /Staffan On 15 jan 2014, at 17:34, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen wrote: > Volker, > > I?ve look at the following files: > > src/share/native/sun/management/DiagnosticCommandImpl.c: > nit: ?legel? -> ?legal? (two times) > In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you allow dcmd_info_array to become NULL, then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to check that. > > Good catch. I actually had problems with malloc returning NULL in 'getDiagnosticCommandArgumentInfoArray()' and then changed all other potentially dangerous locations which used the same pattern. > > However I think if the 'dcmd_info_array' has zero length it would be perfectly fine to return a zero length array. So what about the following solution: > > dcmdInfoCls = (*env)->FindClass(env, > "sun/management/DiagnosticCommandInfo"); > num_commands = (*env)->GetArrayLength(env, commands); > if (num_commands = 0) { > result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > if (result == NULL) { > JNU_ThrowOutOfMemoryError(env, 0); > } > else { > return result; > } > } > dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > > That seems easier and saves me from handling the exception. > > What do you think? > > src/solaris/native/sun/management/OperatingSystemImpl.c > No comments. > > src/share/transport/socket/socketTransport.c > No comments. > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > No comments. > > > Thanks, > /Staffan > > > > On 14 jan 2014, at 09:40, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. >> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. >> make/CompileJavaClasses.gmk >> >> Also use PollingWatchService on AIX. >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> Support "compound text" on AIX in the same way like on other Unix platforms. >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> >> Define the correct attach provider for AIX. >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. >> While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >> Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> On AIX the implementation is especially tricky, because the close() system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. >> src/share/transport/socket/socketTransport.c >> >> On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. >> Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. >> src/solaris/native/java/net/NetworkInterface.c >> >> Set the scope identifier for IPv6 addresses on AIX. >> src/solaris/native/java/net/net_util_md.c >> >> It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. >> Also fixed a comment and removed unused local variables. >> Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140115/7a8e80d0/attachment-0001.html From staffan.larsen at oracle.com Wed Jan 15 11:03:01 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:03:01 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: <9DE753A4-E6E0-435D-8FB9-5C93CD3184D4@oracle.com> On 15 jan 2014, at 18:27, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen >> wrote: >>> >>> Volker, >>> >>> I?ve look at the following files: >>> >>> src/share/native/sun/management/DiagnosticCommandImpl.c: >>> nit: ?legel? -> ?legal? (two times) >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >>> you allow dcmd_info_array to become NULL, then >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >>> check that. >> >> >> Good catch. I actually had problems with malloc returning NULL in >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other >> potentially dangerous locations which used the same pattern. >> >> However I think if the 'dcmd_info_array' has zero length it would be >> perfectly fine to return a zero length array. So what about the following >> solution: >> >> dcmdInfoCls = (*env)->FindClass(env, >> "sun/management/DiagnosticCommandInfo"); >> num_commands = (*env)->GetArrayLength(env, commands); > > Sorry, of course I wanted to say "if (num_commands == 0)" here! I understood as much :-) > >> if (num_commands = 0) { >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); >> if (result == NULL) { >> JNU_ThrowOutOfMemoryError(env, 0); >> } >> else { >> return result; >> } >> } >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); >> if (dcmd_info_array == NULL) { >> JNU_ThrowOutOfMemoryError(env, NULL); >> } >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); >> >> That seems easier and saves me from handling the exception. >> >> What do you think? >> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> No comments. >>> >>> src/share/transport/socket/socketTransport.c >>> No comments. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> No comments. >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >>> >>> I've build and smoke tested without any problems on Linux/x86_64 and >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >>> >>> With these changes (and together with the changes from "8028537: PPC64: >>> Updated jdk/test scripts to understand the AIX os and environment" and >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >>> >>> java/net/Inet6Address/B6558853.java >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >>> java/nio/channels/Selector/RacyDeregister.java >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> Following a detailed description of the various changes: >>> >>> src/share/native/java/util/zip/zip_util.c >>> src/share/native/sun/management/DiagnosticCommandImpl.c >>> >>> According to ISO C it is perfectly legal for malloc to return zero if >>> called with a zero argument. Fix various places where malloc can potentially >>> correctly return zero because it was called with a zero argument. >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >>> compiler warning on Linux, but on AIX it prevents a VM crash later on >>> because the return value of malloc() will be casted to int which is >>> especially bad if that pointer was bigger than 32-bit. >>> >>> make/CompileJavaClasses.gmk >>> >>> Also use PollingWatchService on AIX. >>> >>> make/lib/NioLibraries.gmk >>> src/aix/native/sun/nio/ch/AixNativeThread.c >>> >>> Put the implementation for the native methods of NativeThread into >>> AixNativeThread.c on AIX. >>> >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >>> src/solaris/native/sun/nio/ch/Net.c >>> src/aix/classes/sun/nio/ch/AixPollPort.java >>> src/aix/native/sun/nio/ch/AixPollPort.c >>> src/aix/native/java/net/aix_close.c >>> >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >>> ...) are defined to different values than on other operating systems. The >>> problem is however, that these constants are hardcoded as public final >>> static members of various, shared Java classes. We therefore have to map >>> them from Java to native every time before calling one of the native poll >>> functions and back to Java after the call on AIX in order to get the right >>> semantics. >>> >>> src/share/classes/java/nio/file/CopyMoveHelper.java >>> >>> As discussed on the core-libs mailing list (see >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) >>> it is not necessary to call Files.getFileAttributeView() with any >>> linkOptions because at that place we've already checked that the target file >>> can not be a symbolic link. This change makes the implementation more robust >>> on platforms which support symbolic links but do not support the O_NOFOLLOW >>> flag to the open system call. It also makes the JDK pass the >>> demo/zipfs/basic.sh test on AIX. >>> >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >>> >>> Support "compound text" on AIX in the same way like on other Unix >>> platforms. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> >>> Define the correct attach provider for AIX. >>> >>> src/solaris/native/java/net/net_util_md.h >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >>> >>> AIX needs a workaround for I/O cancellation (see: >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >>> "..The close() subroutine is blocked until all subroutines which use the >>> file descriptor return to usr space. For example, when a thread is calling >>> close and another thread is calling select with the same file descriptor, >>> the close subroutine does not return until the select call returns...". To >>> fix this problem, we have to use the various NET_ wrappers which are >>> declared in net_util_md.h and defined in aix_close.c and we also need some >>> additional wrappers for fcntl(), read() and write() on AIX. >>> While the current solution isn't really nice because it introduces some >>> more AIX-specifc sections in shared code, I think it is the best way to go >>> for JDK 8 because it imposes the smallest possible changes and risks for the >>> existing platforms. I'm ready to change the code to unconditionally use the >>> wrappers for all platforms and implement the wrappers empty on platforms >>> which don't need any wrapping. I think it would also be nice to clean up the >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >>> is probably not appropriate any more so maybe change it to something like >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >>> descriptor open for writing."). To prevent this error we have to query if >>> the corresponding file descriptor is writeable. Notice that at that point we >>> can not access the writable attribute of the corresponding file channel so >>> we have to use fcntl(). >>> >>> src/solaris/classes/java/lang/UNIXProcess.java.aix >>> >>> On AIX the implementation is especially tricky, because the close() system >>> call will block if another thread is at the same time blocked in a file >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine >>> the AIX ProcessPipeInputStream implemenatation with the >>> DeferredCloseInputStream approach used on Solaris (see >>> UNIXProcess.java.solaris). This means that every potentially blocking >>> operation on the file descriptor increments a counter before it is executed >>> and decrements it once it finishes. The 'close()' operation will only be >>> executed if there are no pending operations. Otherwise it is deferred after >>> the last pending operation has finished. >>> >>> src/share/transport/socket/socketTransport.c >>> >>> On AIX we have to call shutdown() on a socket descriptor before closing >>> it, otherwise the close() call may be blocked. This is the same problem as >>> described before. Unfortunately the JDI framework doesn't use the same IO >>> wrappers like other class library components so we can not easily use the >>> NET_ abstractions from aix_close.c here. >>> Without this small change all JDI regression tests will fail on AIX >>> because of the way how the tests act as a "debugger" which launches another >>> VM (the "debugge") which connects itself back to the debugger. In this >>> scenario the "debugge" can not shut down itself because one thread will >>> always be blocked in the close() call on one of the communication sockets. >>> >>> src/solaris/native/java/net/NetworkInterface.c >>> >>> Set the scope identifier for IPv6 addresses on AIX. >>> >>> src/solaris/native/java/net/net_util_md.c >>> >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >>> the same port. >>> Also fixed a comment and removed unused local variables. >>> Fixed the obviously inverted assignment newTime = prevTime; which should >>> read prevTime = newTime;. Otherwise prevTime will never change and the >>> timeout will be potential reached too fast. >>> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> >>> AIX does not understand /proc/self so we have to query the real process ID >>> to access the proc file system. >>> >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >>> >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >>> with the address family set to AF_UNSPEC. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140115/c93b7945/attachment.html From staffan.larsen at oracle.com Wed Jan 15 11:04:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:04:50 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: <5F6D2785-23EF-4F43-9E0E-649BEF50F204@oracle.com> On 15 jan 2014, at 18:52, Volker Simonis wrote: > > > On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > > wrote: > >> Hi Staffan, > >> > >> thanks for the review. Please find my comments inline: > >> > >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > >> wrote: > >>> > >>> Volker, > >>> > >>> I?ve look at the following files: > >>> > >>> src/share/native/sun/management/DiagnosticCommandImpl.c: > >>> nit: ?legel? -> ?legal? (two times) > >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if > >>> you allow dcmd_info_array to become NULL, then > >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to > >>> check that. > >> > >> > >> Good catch. I actually had problems with malloc returning NULL in > >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other > >> potentially dangerous locations which used the same pattern. > >> > >> However I think if the 'dcmd_info_array' has zero length it would be > >> perfectly fine to return a zero length array. So what about the following > >> solution: > >> > > Sorry for the noise - it seems I was a little indisposed during the last mails:) > So this is the simple change I'd like to propose for Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo(): > > > @@ -117,19 +119,23 @@ > return NULL; > } > num_commands = (*env)->GetArrayLength(env, commands); > - dcmd_info_array = (dcmdInfo*) malloc(num_commands * > - sizeof(dcmdInfo)); > + dcmdInfoCls = (*env)->FindClass(env, > + "sun/management/DiagnosticCommandInfo"); > + result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > + if (result == NULL) { > + JNU_ThrowOutOfMemoryError(env, 0); > + } > + if (num_commands == 0) { > + /* Handle the 'zero commands' case specially to avoid calling 'malloc()' */ > + /* with a zero argument because that may legally return a NULL pointer. */ > + return result; > + } > + dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > - dcmdInfoCls = (*env)->FindClass(env, > - "sun/management/DiagnosticCommandInfo"); > - result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > - if (result == NULL) { > - free(dcmd_info_array); > - JNU_ThrowOutOfMemoryError(env, 0); > - } > for (i=0; i args = getDiagnosticCommandArgumentInfoArray(env, > (*env)->GetObjectArrayElement(env,commands,i), > > If the 'commands' input array is of zero length just return a zero length array. > OK? Yes, this looks good (still :-) ) /Staffan > > >> dcmdInfoCls = (*env)->FindClass(env, > >> "sun/management/DiagnosticCommandInfo"); > >> num_commands = (*env)->GetArrayLength(env, commands); > > > > Sorry, of course I wanted to say "if (num_commands == 0)" here! > > > >> if (num_commands = 0) { > >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > >> if (result == NULL) { > >> JNU_ThrowOutOfMemoryError(env, 0); > >> } > >> else { > >> return result; > >> } > >> } > >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > >> if (dcmd_info_array == NULL) { > >> JNU_ThrowOutOfMemoryError(env, NULL); > >> } > >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > >> > >> That seems easier and saves me from handling the exception. > >> > >> What do you think? > >> > >>> src/solaris/native/sun/management/OperatingSystemImpl.c > >>> No comments. > >>> > >>> src/share/transport/socket/socketTransport.c > >>> No comments. > >>> > >>> > >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > >>> No comments. > >>> > >>> > >>> Thanks, > >>> /Staffan > >>> > >>> > >>> > >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: > >>> > >>> Hi, > >>> > >>> could you please review the following changes for the ppc-aix-port > >>> stage/stage-9 repositories (the changes are planned for integration into > >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > >>> > >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > >>> > >>> I've build and smoke tested without any problems on Linux/x86_64 and > >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > >>> > >>> With these changes (and together with the changes from "8028537: PPC64: > >>> Updated jdk/test scripts to understand the AIX os and environment" and > >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the > >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 > >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): > >>> > >>> java/net/Inet6Address/B6558853.java > >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > >>> java/nio/channels/Selector/RacyDeregister.java > >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) > >>> > >>> Thank you and best regards, > >>> Volker > >>> > >>> > >>> Following a detailed description of the various changes: > >>> > >>> src/share/native/java/util/zip/zip_util.c > >>> src/share/native/sun/management/DiagnosticCommandImpl.c > >>> > >>> According to ISO C it is perfectly legal for malloc to return zero if > >>> called with a zero argument. Fix various places where malloc can potentially > >>> correctly return zero because it was called with a zero argument. > >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a > >>> compiler warning on Linux, but on AIX it prevents a VM crash later on > >>> because the return value of malloc() will be casted to int which is > >>> especially bad if that pointer was bigger than 32-bit. > >>> > >>> make/CompileJavaClasses.gmk > >>> > >>> Also use PollingWatchService on AIX. > >>> > >>> make/lib/NioLibraries.gmk > >>> src/aix/native/sun/nio/ch/AixNativeThread.c > >>> > >>> Put the implementation for the native methods of NativeThread into > >>> AixNativeThread.c on AIX. > >>> > >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c > >>> src/solaris/native/sun/nio/ch/Net.c > >>> src/aix/classes/sun/nio/ch/AixPollPort.java > >>> src/aix/native/sun/nio/ch/AixPollPort.c > >>> src/aix/native/java/net/aix_close.c > >>> > >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, > >>> ...) are defined to different values than on other operating systems. The > >>> problem is however, that these constants are hardcoded as public final > >>> static members of various, shared Java classes. We therefore have to map > >>> them from Java to native every time before calling one of the native poll > >>> functions and back to Java after the call on AIX in order to get the right > >>> semantics. > >>> > >>> src/share/classes/java/nio/file/CopyMoveHelper.java > >>> > >>> As discussed on the core-libs mailing list (see > >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > >>> it is not necessary to call Files.getFileAttributeView() with any > >>> linkOptions because at that place we've already checked that the target file > >>> can not be a symbolic link. This change makes the implementation more robust > >>> on platforms which support symbolic links but do not support the O_NOFOLLOW > >>> flag to the open system call. It also makes the JDK pass the > >>> demo/zipfs/basic.sh test on AIX. > >>> > >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > >>> > >>> Support "compound text" on AIX in the same way like on other Unix > >>> platforms. > >>> > >>> > >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > >>> > >>> Define the correct attach provider for AIX. > >>> > >>> src/solaris/native/java/net/net_util_md.h > >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > >>> > >>> AIX needs a workaround for I/O cancellation (see: > >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > >>> "..The close() subroutine is blocked until all subroutines which use the > >>> file descriptor return to usr space. For example, when a thread is calling > >>> close and another thread is calling select with the same file descriptor, > >>> the close subroutine does not return until the select call returns...". To > >>> fix this problem, we have to use the various NET_ wrappers which are > >>> declared in net_util_md.h and defined in aix_close.c and we also need some > >>> additional wrappers for fcntl(), read() and write() on AIX. > >>> While the current solution isn't really nice because it introduces some > >>> more AIX-specifc sections in shared code, I think it is the best way to go > >>> for JDK 8 because it imposes the smallest possible changes and risks for the > >>> existing platforms. I'm ready to change the code to unconditionally use the > >>> wrappers for all platforms and implement the wrappers empty on platforms > >>> which don't need any wrapping. I think it would also be nice to clean up the > >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix > >>> is probably not appropriate any more so maybe change it to something like > >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. > >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an > >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file > >>> descriptor open for writing."). To prevent this error we have to query if > >>> the corresponding file descriptor is writeable. Notice that at that point we > >>> can not access the writable attribute of the corresponding file channel so > >>> we have to use fcntl(). > >>> > >>> src/solaris/classes/java/lang/UNIXProcess.java.aix > >>> > >>> On AIX the implementation is especially tricky, because the close() system > >>> call will block if another thread is at the same time blocked in a file > >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine > >>> the AIX ProcessPipeInputStream implemenatation with the > >>> DeferredCloseInputStream approach used on Solaris (see > >>> UNIXProcess.java.solaris). This means that every potentially blocking > >>> operation on the file descriptor increments a counter before it is executed > >>> and decrements it once it finishes. The 'close()' operation will only be > >>> executed if there are no pending operations. Otherwise it is deferred after > >>> the last pending operation has finished. > >>> > >>> src/share/transport/socket/socketTransport.c > >>> > >>> On AIX we have to call shutdown() on a socket descriptor before closing > >>> it, otherwise the close() call may be blocked. This is the same problem as > >>> described before. Unfortunately the JDI framework doesn't use the same IO > >>> wrappers like other class library components so we can not easily use the > >>> NET_ abstractions from aix_close.c here. > >>> Without this small change all JDI regression tests will fail on AIX > >>> because of the way how the tests act as a "debugger" which launches another > >>> VM (the "debugge") which connects itself back to the debugger. In this > >>> scenario the "debugge" can not shut down itself because one thread will > >>> always be blocked in the close() call on one of the communication sockets. > >>> > >>> src/solaris/native/java/net/NetworkInterface.c > >>> > >>> Set the scope identifier for IPv6 addresses on AIX. > >>> > >>> src/solaris/native/java/net/net_util_md.c > >>> > >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by > >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only > >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to > >>> the same port. > >>> Also fixed a comment and removed unused local variables. > >>> Fixed the obviously inverted assignment newTime = prevTime; which should > >>> read prevTime = newTime;. Otherwise prevTime will never change and the > >>> timeout will be potential reached too fast. > >>> > >>> src/solaris/native/sun/management/OperatingSystemImpl.c > >>> > >>> AIX does not understand /proc/self so we have to query the real process ID > >>> to access the proc file system. > >>> > >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > >>> > >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket > >>> with the address family set to AF_UNSPEC. > >>> > >>> > >>> > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140115/c4ae36c9/attachment-0001.html From staffan.larsen at oracle.com Wed Jan 15 11:10:36 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:10:36 +0100 Subject: RR(XS): JDK-8024049 com/sun/jdi/ProcessAttachTest.sh shortens 7-digit pid to 6-digit In-Reply-To: <52D6D234.1060704@oracle.com> References: <52D6D234.1060704@oracle.com> Message-ID: <8EF29D5B-5CA3-404E-B323-2349835E5DAE@oracle.com> Looks good! Thanks, /Staffan On 15 jan 2014, at 19:23, Dmitry Samersoff wrote: > Hi Everybody, > > Please review small, test-only fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8024049/webrev.01/ > > fix summary: > > grep/cut chain is replaced with awk. > > -- > 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 Jan 15 23:37:23 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 16 Jan 2014 08:37:23 +0100 Subject: Review request for 8029378: com/sun/jdi/BadHandshakeTest.java failed with java.util.concurrent.TimeoutException Message-ID: <52D78C33.6000305@oracle.com> Hi, Please review this simple fix, the test needs more time to wait Phaser.awaitAdvanceInterruptibly(...). webrev: http://cr.openjdk.java.net/~sjiang/JDK-8029378/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8029378 Thanks, Shanliang From david.holmes at oracle.com Thu Jan 16 00:37:31 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jan 2014 18:37:31 +1000 Subject: Review request for 8029378: com/sun/jdi/BadHandshakeTest.java failed with java.util.concurrent.TimeoutException In-Reply-To: <52D78C33.6000305@oracle.com> References: <52D78C33.6000305@oracle.com> Message-ID: <52D79A4B.3030506@oracle.com> On 16/01/2014 5:37 PM, shanliang wrote: > Hi, > > Please review this simple fix, the test needs more time to wait > Phaser.awaitAdvanceInterruptibly(...). Integer.MAX_VALUE? There's no point using a timed form at all. David > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8029378/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8029378 > > Thanks, > Shanliang From volker.simonis at gmail.com Thu Jan 16 01:38:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jan 2014 10:38:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 12:05 PM, Volker Simonis wrote: > > > > On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > >> On 15/01/2014 06:24, David Holmes wrote: >> >>> >>> I'm not a fan of runtime checks of this kind though if it is only a very >>> samll number of values it might be okay. >>> >>> Another option would be to make those classes into "templates" as done >>> with Version.java.template and substitute the right values at build time. >>> >>> But I'll let Alan and net-dev folk come back with their preferred >>> technique for this. >>> >>> I plan to spend time on Volker's webrev later in the week (just too >> busy with other things right now). For the translation issue then it's an >> oversight in the original implementation, it just hasn't come up before (to >> my knowledge anyway). The simplest solution here maybe to to just move them >> to sun.net.ch.Net and have them initialized to their native value. > > > Do you mean sun.nio.ch.Net right? > > Do you propose to completely remove the definitions of the POLL constants > from: > > src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java > src/solaris/classes/sun/nio/ch/Port.java > > and replace all their usages by Net.POLL* ? > > Hi Alan, I think sun.nio.ch.IOUtil seems even more appropriate to me for these constants. What do you think? Would it be OK for you if I initialize them right in the static initializer of IOUtil based on "os.name" or do you prefer to have native methods which return the right constants? Regards, Volker > In general then I'm not too concerned about that one, it's the changes to >> support async close on AIX that are leaping out at me. >> >> -Alan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140116/cacb3907/attachment.html From Alan.Bateman at oracle.com Thu Jan 16 02:05:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 10:05:44 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: <52D7AEF8.8090502@oracle.com> On 16/01/2014 09:38, Volker Simonis wrote: > > > Hi Alan, > > I think sun.nio.ch.IOUtil seems even more appropriate to me for these > constants. What do you think? > > Would it be OK for you if I initialize them right in the static > initializer of IOUtil based on "os.name " or do you > prefer to have native methods which return the right constants? I have a small preference for sun.nio.ch.Net because these constants are used with Net.poll. Would you be open to separating this one from the AIX changes? The reason is that it isn't AIX specific, rather just an oversight that hasn't been an issue because it doesn't impact other platforms. Using os.name initially would be okay although we could change that over time. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140116/0bb0612a/attachment.html From volker.simonis at gmail.com Thu Jan 16 02:34:03 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jan 2014 11:34:03 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D7AEF8.8090502@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> <52D7AEF8.8090502@oracle.com> Message-ID: On Thu, Jan 16, 2014 at 11:05 AM, Alan Bateman wrote: > On 16/01/2014 09:38, Volker Simonis wrote: > > > > Hi Alan, > > I think sun.nio.ch.IOUtil seems even more appropriate to me for these > constants. What do you think? > > Would it be OK for you if I initialize them right in the static initializer > of IOUtil based on "os.name" or do you prefer to have native methods which > return the right constants? > > I have a small preference for sun.nio.ch.Net because these constants are > used with Net.poll. I just thought because poll is more file-descriptor oriented and not network specific. And the constants are also used for example in: src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java: src/solaris/classes/sun/nio/ch/sctp/Sctp* src/solaris/classes/sun/nio/ch/Port.java But actually I have no prefernece here so I can put them just as well to sun.nio.ch.Net > Would you be open to separating this one from the AIX > changes? The reason is that it isn't AIX specific, rather just an oversight > that hasn't been an issue because it doesn't impact other platforms. Sure, no problem. Although I still would like to push this to ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where we really need it. Anyway, the current plan is to merge ppc-aix-port/stage-9 into jdk9 mainline by the end of January and ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would that be ok? > Using > os.name initially would be okay although we could change that over time. I've already written the native methods:) > > -Alan From shanliang.jiang at oracle.com Thu Jan 16 02:48:01 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 16 Jan 2014 11:48:01 +0100 Subject: Review request for 8029378: com/sun/jdi/BadHandshakeTest.java failed with java.util.concurrent.TimeoutException In-Reply-To: <52D79A4B.3030506@oracle.com> References: <52D78C33.6000305@oracle.com> <52D79A4B.3030506@oracle.com> Message-ID: <52D7B8E1.4010509@oracle.com> David Holmes wrote: > On 16/01/2014 5:37 PM, shanliang wrote: >> Hi, >> >> Please review this simple fix, the test needs more time to wait >> Phaser.awaitAdvanceInterruptibly(...). > > Integer.MAX_VALUE? There's no point using a timed form at all. > > David Yes Phaser.awaitAdvanceInterruptibly(int phase) could be used here, but the call of this method is wrapped in: jdk.testlibrary.ProcessTools.startProcess(...) So we have to add a new method ProcessTools.startProcess(...) which has no timeout parameter. I did not do this because I thought to have a simple fix only within the test. If this is useful, here is the new web: http://cr.openjdk.java.net/~sjiang/JDK-8029378/01/ Thanks, Shanliang >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8029378/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8029378 >> >> Thanks, >> Shanliang From yekaterina.kantserova at oracle.com Thu Jan 16 02:51:31 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 16 Jan 2014 11:51:31 +0100 Subject: RFR (S): 7185591: jcmd-big-script.sh ERROR: could not find app's Java pid. In-Reply-To: <52D69B6B.3010609@oracle.com> References: <52CFEC7F.4040207@oracle.com> <52D65146.4000700@oracle.com> <7384F0AF-3FCF-4551-A506-EB4E7EC25618@oracle.com> <52D69B6B.3010609@oracle.com> Message-ID: <52D7B9B3.7080103@oracle.com> Staffan, I've missed to rename toolArgs in JcmdBase.java. The webrev with changes can be found here: http://cr.openjdk.java.net/~ykantser/7185591/webrev.03 If it looks good, could you please be my sponsor and push the changes? The patch is attached to this mail. Thanks, Katja On 01/15/2014 03:30 PM, Yekaterina Kantserova wrote: > Staffan, > > The webrev with changes can be found here: > http://cr.openjdk.java.net/~ykantser/7185591/webrev.02/ > > If it looks good, could you please be my sponsor and push the changes? > The patch is attached to this mail. > > Thanks, > Katja > > > > On 01/15/2014 11:37 AM, Staffan Larsen wrote: >> Katja, >> >> test/lib/testlibrary/jdk/testlibrary/JcmdBase.java >> The toolArgs parameter should be renamed jcmdArgs. >> >> test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java >> 423 public int indexOf(String pattern) { >> You don?t have to convert the List to an array before iterating >> through it. Use lLines.get(i).matches(?) instead. >> >> 470 public int shouldMatchByLine(String from, String to, String >> pattern) { >> This method still reads the lines into an ArrayList (at most) three >> times. It calls asLines() once and indexOf() twice. There could be a >> version of indexOf() that takes a List. Actually indexOf >> could be private and always take a List. >> >> >> Otherwise ok! >> >> /Staffan >> >> >> >> On 15 jan 2014, at 10:13, Yekaterina Kantserova >> > > wrote: >> >>> Staffan, thank you for pointing out performance and test.src issues! >>> >>> The webrev with fixes can be found here: >>> http://cr.openjdk.java.net/~ykantser/7185591/webrev.01/ >>> >>> >>> Please, see my comments in-lined. >>> >>> Thanks, >>> Katja >>> >>> >>> >>> On 01/13/2014 01:19 PM, Staffan Larsen wrote: >>>> Katja, >>>> >>>> test/lib/testlibrary/jdk/testlibrary/JcmdBase.java >>>> 68 * Run jcmd standalone >>>> >>>> I think you should expand a bit on what ?standalone? means here. It >>>> took me a while to understand the difference. >>> Fixed. >>>> >>>> test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java >>>> 423 public int indexOf(String pattern) { >>>> >>>> This seems very inefficient. Add all lines to an ArrayList and then >>>> walk through them one at a time to if it matches and then walk >>>> through them once again to find the index of that line. >>>> >>>> 469 public int shouldMatchByLine(String from, String to, String >>>> pattern) { >>>> >>>> Same inefficiency here, but worse because both asLines() and >>>> indexOf() does the same work. >>>> >>>> test/lib/testlibrary/jdk/testlibrary/Utils.java >>>> 65 public static final String TEST_SRC = >>>> System.getProperty("test.src").trim(); >>> Fixed. >>>> >>>> I wonder if this really works. Isn?t ?test.src? different for >>>> different tests? A property that jtreg changes >>> Yes, it is different. >>>> before invoking each test? Or does this work because each test is >>>> run in a different class loader and Utils.java will exist once in >>>> each class loader? >>> I've learned now it works because jtreg compiles all classes a test >>> needs to a separate location. For example when I run >>> TestJcmdDefaults there will be both TestJcmdDefaults.class and >>> jdk/testlibrary/Utils.class under >>> /tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/. The class loader >>> will load Utils for TestJcmdDefaults from >>> /tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/. >>> >>> ... >>> [Loaded jdk.testlibrary.Utils from >>> file:/tmp/jtreg/jtreg-workdir/classes/sun/tools/jcmd/] >>> ... >>> >>> But I think it's better to declare TEST_SRC per test precisely >>> because it's different for different tests. >>> >>>> >>>> >>>> /Staffan >>>> >>>> >>>> On 10 jan 2014, at 13:50, Yekaterina Kantserova >>>> >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> Could I please have a review of this fix. >>>>> >>>>> In this fix I've rewritten sun/tools/jcmd/* tests in pure java to >>>>> get rid of all intermittent failures depending on for example MKS >>>>> or race conditions (test application has not yet started when the >>>>> test start to run). >>>>> >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ykantser/7185591/webrev.00/ >>>>> >>>>> >>>>> Primal bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-7185591 >>>>> >>>>> Similar bugs: >>>>> https://bugs.openjdk.java.net/browse/JDK-6977426 >>>>> https://bugs.openjdk.java.net/browse/JDK-8020798 >>>>> https://bugs.openjdk.java.net/browse/JDK-7130656 (this one is >>>>> blocked by https://bugs.openjdk.java.net/browse/JDK-8031482 so far) >>>>> >>>>> Thanks, >>>>> Katja >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140116/ab962dac/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 7185591.3.patch Type: text/x-patch Size: 37844 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140116/ab962dac/7185591.3-0001.patch From jaroslav.bachorik at oracle.com Thu Jan 16 02:54:18 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 16 Jan 2014 11:54:18 +0100 Subject: Review request for 8029378: com/sun/jdi/BadHandshakeTest.java failed with java.util.concurrent.TimeoutException In-Reply-To: <52D7B8E1.4010509@oracle.com> References: <52D78C33.6000305@oracle.com> <52D79A4B.3030506@oracle.com> <52D7B8E1.4010509@oracle.com> Message-ID: <52D7BA5A.3000808@oracle.com> On 16.1.2014 11:48, shanliang wrote: > David Holmes wrote: >> On 16/01/2014 5:37 PM, shanliang wrote: >>> Hi, >>> >>> Please review this simple fix, the test needs more time to wait >>> Phaser.awaitAdvanceInterruptibly(...). >> >> Integer.MAX_VALUE? There's no point using a timed form at all. >> >> David > Yes Phaser.awaitAdvanceInterruptibly(int phase) could be used here, but > the call of this method is wrapped in: > jdk.testlibrary.ProcessTools.startProcess(...) > > So we have to add a new method ProcessTools.startProcess(...) which has > no timeout parameter. I did not do this because I thought to have a > simple fix only within the test. This timeoud seems to be caused by using the fastdebug build. You could use Utils.TIMEOUT_FACTOR to scale the original timeout (1500) according to the parameters specified for tests running fastdebug builds. -JB- > > If this is useful, here is the new web: > http://cr.openjdk.java.net/~sjiang/JDK-8029378/01/ > > Thanks, > Shanliang > >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8029378/00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8029378 >>> >>> Thanks, >>> Shanliang > From shanliang.jiang at oracle.com Thu Jan 16 03:01:38 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 16 Jan 2014 12:01:38 +0100 Subject: Review request for 8029378: com/sun/jdi/BadHandshakeTest.java failed with java.util.concurrent.TimeoutException In-Reply-To: <52D7BA5A.3000808@oracle.com> References: <52D78C33.6000305@oracle.com> <52D79A4B.3030506@oracle.com> <52D7B8E1.4010509@oracle.com> <52D7BA5A.3000808@oracle.com> Message-ID: <52D7BC12.9080403@oracle.com> Jaroslav Bachorik wrote: > On 16.1.2014 11:48, shanliang wrote: >> David Holmes wrote: >>> On 16/01/2014 5:37 PM, shanliang wrote: >>>> Hi, >>>> >>>> Please review this simple fix, the test needs more time to wait >>>> Phaser.awaitAdvanceInterruptibly(...). >>> >>> Integer.MAX_VALUE? There's no point using a timed form at all. >>> >>> David >> Yes Phaser.awaitAdvanceInterruptibly(int phase) could be used here, but >> the call of this method is wrapped in: >> jdk.testlibrary.ProcessTools.startProcess(...) >> >> So we have to add a new method ProcessTools.startProcess(...) which has >> no timeout parameter. I did not do this because I thought to have a >> simple fix only within the test. > > This timeoud seems to be caused by using the fastdebug build. You > could use Utils.TIMEOUT_FACTOR to scale the original timeout (1500) > according to the parameters specified for tests running fastdebug builds. Yes it could be a solution, but to wait the jtreg timeout seems better, we do not need to take care of timeout. Thanks, Shanliang > > -JB- > >> >> If this is useful, here is the new web: >> http://cr.openjdk.java.net/~sjiang/JDK-8029378/01/ >> >> Thanks, >> Shanliang >> >>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8029378/00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029378 >>>> >>>> Thanks, >>>> Shanliang >> > From kevin.walls at oracle.com Thu Jan 16 04:41:48 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 16 Jan 2014 12:41:48 +0000 Subject: RFR 8028623: SA: hash codes in SymbolTable mismatching java_lang_String::hash_code for extended characters. In-Reply-To: <6A95994F-A7B2-47AD-8B05-0595280D6F95@oracle.com> References: <52C6F69E.4010107@oracle.com> <67C1E9FA-7680-421F-BAD3-292021231C6B@oracle.com> <52CD67D4.7020702@oracle.com> <6A95994F-A7B2-47AD-8B05-0595280D6F95@oracle.com> Message-ID: <52D7D38C.3070902@oracle.com> Thanks - just need that second reviewer then... On 13/01/14 12:38, Staffan Larsen wrote: > Looks good! Thanks for taking the time to re-write the test in Java. > > Thanks, > /Staffan > > On 8 jan 2014, at 15:59, Kevin Walls wrote: > >> Hi Staffan - >> >> http://cr.openjdk.java.net/~kevinw/8028623/webrev.01/ >> >> Yes it's better now, getting pid and launching a tool etc have been previous reasons to use a script, but with this new help it's not too bad!... >> >> Thanks, >> Kevin >> >> >> On 07/01/14 09:43, Staffan Larsen wrote: >>> Kevin, >>> >>> The fix looks good. >>> >>> For tests, we are trying to avoid adding new shell-script based tests since they too often cause problems. Would it be possible to rewrite the test in pure Java code? There are some helper routines in test/testlibrary/com/oracle/java/testlibrary/ that could be useful. >>> >>> /Staffan >>> >>> On 3 jan 2014, at 18:42, Kevin Walls wrote: >>> >>>> Hi, >>>> >>>> This problem means you can't use the SA if the target app contains a symbol which uses a non-ascii character. The SA tool will fail with an error, the JVM itself and the SA having calculated different hashes for such Strings. >>>> >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8028623 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~kevinw/8028623/webrev.00/ >>>> >>>> Thanks >>>> Kevin From david.holmes at oracle.com Thu Jan 16 04:44:50 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jan 2014 22:44:50 +1000 Subject: Review request for 8029378: com/sun/jdi/BadHandshakeTest.java failed with java.util.concurrent.TimeoutException In-Reply-To: <52D7BC12.9080403@oracle.com> References: <52D78C33.6000305@oracle.com> <52D79A4B.3030506@oracle.com> <52D7B8E1.4010509@oracle.com> <52D7BA5A.3000808@oracle.com> <52D7BC12.9080403@oracle.com> Message-ID: <52D7D442.3030900@oracle.com> On 16/01/2014 9:01 PM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 16.1.2014 11:48, shanliang wrote: >>> David Holmes wrote: >>>> On 16/01/2014 5:37 PM, shanliang wrote: >>>>> Hi, >>>>> >>>>> Please review this simple fix, the test needs more time to wait >>>>> Phaser.awaitAdvanceInterruptibly(...). >>>> >>>> Integer.MAX_VALUE? There's no point using a timed form at all. >>>> >>>> David >>> Yes Phaser.awaitAdvanceInterruptibly(int phase) could be used here, but >>> the call of this method is wrapped in: >>> jdk.testlibrary.ProcessTools.startProcess(...) >>> >>> So we have to add a new method ProcessTools.startProcess(...) which has >>> no timeout parameter. I did not do this because I thought to have a >>> simple fix only within the test. >> >> This timeoud seems to be caused by using the fastdebug build. You >> could use Utils.TIMEOUT_FACTOR to scale the original timeout (1500) >> according to the parameters specified for tests running fastdebug builds. > Yes it could be a solution, but to wait the jtreg timeout seems better, > we do not need to take care of timeout. Okay. It would have been clearer if you had stated that you were removing the timeout in the test and relying on jtreg timing out the test instead. :) Thanks, David > Thanks, > Shanliang >> >> -JB- >> >>> >>> If this is useful, here is the new web: >>> http://cr.openjdk.java.net/~sjiang/JDK-8029378/01/ >>> >>> Thanks, >>> Shanliang >>> >>>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8029378/00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029378 >>>>> >>>>> Thanks, >>>>> Shanliang >>> >> > From shanliang.jiang at oracle.com Thu Jan 16 04:54:59 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 16 Jan 2014 13:54:59 +0100 Subject: Review request for 8029378: com/sun/jdi/BadHandshakeTest.java failed with java.util.concurrent.TimeoutException In-Reply-To: <52D7D442.3030900@oracle.com> References: <52D78C33.6000305@oracle.com> <52D79A4B.3030506@oracle.com> <52D7B8E1.4010509@oracle.com> <52D7BA5A.3000808@oracle.com> <52D7BC12.9080403@oracle.com> <52D7D442.3030900@oracle.com> Message-ID: <52D7D6A3.8000308@oracle.com> David Holmes wrote: > On 16/01/2014 9:01 PM, shanliang wrote: >> Jaroslav Bachorik wrote: >>> On 16.1.2014 11:48, shanliang wrote: >>>> David Holmes wrote: >>>>> On 16/01/2014 5:37 PM, shanliang wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this simple fix, the test needs more time to wait >>>>>> Phaser.awaitAdvanceInterruptibly(...). >>>>> >>>>> Integer.MAX_VALUE? There's no point using a timed form at all. >>>>> >>>>> David >>>> Yes Phaser.awaitAdvanceInterruptibly(int phase) could be used here, >>>> but >>>> the call of this method is wrapped in: >>>> jdk.testlibrary.ProcessTools.startProcess(...) >>>> >>>> So we have to add a new method ProcessTools.startProcess(...) which >>>> has >>>> no timeout parameter. I did not do this because I thought to have a >>>> simple fix only within the test. >>> >>> This timeoud seems to be caused by using the fastdebug build. You >>> could use Utils.TIMEOUT_FACTOR to scale the original timeout (1500) >>> according to the parameters specified for tests running fastdebug >>> builds. >> Yes it could be a solution, but to wait the jtreg timeout seems better, >> we do not need to take care of timeout. > > Okay. It would have been clearer if you had stated that you were > removing the timeout in the test and relying on jtreg timing out the > test instead. :) Thanks David and Jaroslav for reviewing, I will push the first version. Shanliang > > Thanks, > David > >> Thanks, >> Shanliang >>> >>> -JB- >>> >>>> >>>> If this is useful, here is the new web: >>>> http://cr.openjdk.java.net/~sjiang/JDK-8029378/01/ >>>> >>>> Thanks, >>>> Shanliang >>>> >>>>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8029378/00/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029378 >>>>>> >>>>>> Thanks, >>>>>> Shanliang >>>> >>> >> From Alan.Bateman at oracle.com Thu Jan 16 08:51:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 16:51:55 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> <52D7AEF8.8090502@oracle.com> Message-ID: <52D80E2B.5000608@oracle.com> On 16/01/2014 10:34, Volker Simonis wrote: > : > I just thought because poll is more file-descriptor oriented and not > network specific. And the constants are also used for example in: > > src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java: > src/solaris/classes/sun/nio/ch/sctp/Sctp* > src/solaris/classes/sun/nio/ch/Port.java > > But actually I have no prefernece here so I can put them just as well > to sun.nio.ch.Net It's not used for anything except sockets here (there aren't any selectable channels that aren't also network channels). So I think sun.nio.ch.Net is marginly cleaner here. > : > > Sure, no problem. Although I still would like to push this to > ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where > we really need it. Anyway, the current plan is to merge > ppc-aix-port/stage-9 into jdk9 mainline by the end of January and > ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would > that be ok? > I see you've created a bug for this. I guess it's okay if comes via the ppc port although would still be good to get it into jdk9/dev early as it impacts all platforms. -Alan. From dmitry.samersoff at oracle.com Fri Jan 17 06:17:17 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 17 Jan 2014 18:17:17 +0400 Subject: RFR 8028623: SA: hash codes in SymbolTable mismatching java_lang_String::hash_code for extended characters. In-Reply-To: <52C6F69E.4010107@oracle.com> References: <52C6F69E.4010107@oracle.com> Message-ID: <52D93B6D.9020601@oracle.com> Looks good for me. -Dmitry On 2014-01-03 21:42, Kevin Walls wrote: > Hi, > > This problem means you can't use the SA if the target app contains a > symbol which uses a non-ascii character. The SA tool will fail with an > error, the JVM itself and the SA having calculated different hashes for > such Strings. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8028623 > > webrev: > http://cr.openjdk.java.net/~kevinw/8028623/webrev.00/ > > Thanks > Kevin -- 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 kevin.walls at oracle.com Fri Jan 17 06:26:09 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 17 Jan 2014 14:26:09 +0000 Subject: RFR 8028623: SA: hash codes in SymbolTable mismatching java_lang_String::hash_code for extended characters. In-Reply-To: <52D93B6D.9020601@oracle.com> References: <52C6F69E.4010107@oracle.com> <52D93B6D.9020601@oracle.com> Message-ID: <52D93D81.6060201@oracle.com> Thanks! On 17/01/14 14:17, Dmitry Samersoff wrote: > Looks good for me. > > -Dmitry > > > On 2014-01-03 21:42, Kevin Walls wrote: >> Hi, >> >> This problem means you can't use the SA if the target app contains a >> symbol which uses a non-ascii character. The SA tool will fail with an >> error, the JVM itself and the SA having calculated different hashes for >> such Strings. >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8028623 >> >> webrev: >> http://cr.openjdk.java.net/~kevinw/8028623/webrev.00/ >> >> Thanks >> Kevin > From volker.simonis at gmail.com Fri Jan 17 13:15:08 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 22:15:08 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D50118.3080000@oracle.com> References: <52D50118.3080000@oracle.com> Message-ID: On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > I'd like to review this but I won't have time until later in the week. From > an initial look then there are a few things are not pretty (the changes to > fix the AIX problems with I/O cancellation in particular) and I suspect that > some refactoring is going to be required to handle some of this cleanly. A > minor comment is that bug synopsis doesn't really communicate what these > changes are about. > > -Alan. Just forwarded the following message from another thread here where it belongs: On 17/01/2014 16:57, Alan Bateman wrote: I've finally got to this one. As the event translation issue is now a separate issue then I've ignored that part. I'm not comfortable with the changes to FileDispatcherImpl.c as I don't think we shouldn't be calling into IO_ or NET_* functions here. I think I get the issue that you have on AIX (and assume it's the preClose/dup2 that blocks rather than close) but need a bit of time to suggest alternatives. It may be that it will require an AIX specific SocketDispatcher. Do you happen to know which tests fail due to this part? The other changes look okay. There is a typo in the change to zip_util.c, s/legel/legal/. In DatagramChannelImpl.c then you handle connect failing with EAFNOSUPPORT. I would be tempted to replace the comment to say that it EAFNOSUPPORT can be ignored on AIX. A minor comment but the indentation for rv = errno can be fixed (I see the BSD code has it wrong too). From dmitry.samersoff at oracle.com Sun Jan 19 02:03:36 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 19 Jan 2014 14:03:36 +0400 Subject: RR(S): JDK-7010732 SA_ALTROOT only works if running the SA tools from their build directory. Message-ID: <52DBA2F8.30600@oracle.com> Hi Everyone, Please review small SA fix. http://cr.openjdk.java.net/~dsamersoff/JDK-7010732/webrev.01/ Notice, new build system doesn't build libsaproc_audit.so so the fix affects old-style usage only. -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 volker.simonis at gmail.com Mon Jan 20 01:59:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 10:59:13 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> Message-ID: On Fri, Jan 17, 2014 at 10:15 PM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: >> On 14/01/2014 08:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> I'd like to review this but I won't have time until later in the week. From >> an initial look then there are a few things are not pretty (the changes to >> fix the AIX problems with I/O cancellation in particular) and I suspect that >> some refactoring is going to be required to handle some of this cleanly. A >> minor comment is that bug synopsis doesn't really communicate what these >> changes are about. >> >> -Alan. > > Just forwarded the following message from another thread here where it belongs: > > On 17/01/2014 16:57, Alan Bateman wrote: > > I've finally got to this one. As the event translation issue is now a > separate issue then I've ignored that part. > > I'm not comfortable with the changes to FileDispatcherImpl.c as I > don't think we shouldn't be calling into IO_ or NET_* functions here. > I think I get the issue that you have on AIX (and assume it's the > preClose/dup2 that blocks rather than close) but need a bit of time to > suggest alternatives. It may be that it will require an AIX specific > SocketDispatcher. Do you happen to know which tests fail due to this > part? > > The other changes look okay. There is a typo in the change to > zip_util.c, s/legel/legal/. > > In DatagramChannelImpl.c then you handle connect failing with > EAFNOSUPPORT. I would be tempted to replace the comment to say that it > EAFNOSUPPORT can be ignored on AIX. A minor comment but the > indentation for rv = errno can be fixed (I see the BSD code has it > wrong too). > On 17/01/2014 21:23, Volker Simonis wrote: > > > You're right, one race is with preClose/dup2 but also with other calls > > like read/fcntl/... > > > > There were several tests that failed and once I fixed it they all > > succeeded. But I can recreate some of the failures for you. The > > symptoms are always the same: the VMis locked. If you trigger a stack > > trace you can see that at least on thread is blocked in a I/O > > operation on a file descriptor like fcntl (e.g. for file locking), > > read, etc. while another thread is trying to close that socket. > > > > As it happens, we have some carry over issues from the Mac port, > one of which is that async close of FileChannels will block > indefinitely in dup2 when there is another thread blocked (on > fnctl or reading from a pipe ...). I haven't time time to work on > it but this discussion has reminded me that we need to sort it > out. I've put a preliminary webrev with the changes here: > > http://cr.openjdk.java.net/~alanb/7133499/webrev/ > > The important part is that it's using signal consistently on > Linux/Solaris/OSX so that any blocked threads are interrupted. My > guess is that if NativeThread.c is updated to define a signal on > AIX they this should resolve some of the issues on AIX. > > I would like to see the list of tests failing. If there is an > issue with dup2 with sockets (and OS X doesn't seem to have that > issue) then it will require further work but I would at least > like to start by understanding if this patch will help with the > FileChannel issues. Hi Alan, yes, that's interesting. Sounds like a very similar problem on Mac. I would suggest the following: I cut out the "Async Close AIX FIX" stuff from this change (i.e. "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests" and send out a new webrev for the remaining part. I think that the remaining part was more or less reviewed and we can then push it faster. In the mean time, I'll recheck which tests exactly fail with my missing "Async Close AIX FIX" stuff and which of these tests will be fixed by your 7133499 webrev. Maybe we can really get trough with it or with it and a few enhancements. I'll let you know my results later today. By the way, my webrev already contained a AixNativeThread.c implementation in src/aix/native/sun/nio/ch. The only remaining problem I see with this approach is that we would need to downport your 7133499 change to 8u-dev in the 8u20 time frame to make our AIX port work. Would this be OK for you? Regards, Volker From Alan.Bateman at oracle.com Mon Jan 20 03:41:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 11:41:48 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> Message-ID: <52DD0B7C.4090605@oracle.com> On 20/01/2014 09:59, Volker Simonis wrote: > : > Hi Alan, > > yes, that's interesting. Sounds like a very similar problem on Mac. > > I would suggest the following: > > I cut out the "Async Close AIX FIX" stuff from this change (i.e. > "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression > tests" and send out a new webrev for the remaining part. I think that > the remaining part was more or less reviewed and we can then push it > faster. > > In the mean time, I'll recheck which tests exactly fail with my > missing "Async Close AIX FIX" stuff and which of these tests will be > fixed by your 7133499 webrev. Maybe we can really get trough with it > or with it and a few enhancements. I'll let you know my results later > today. By the way, my webrev already contained a AixNativeThread.c > implementation in src/aix/native/sun/nio/ch. > > The only remaining problem I see with this approach is that we would > need to downport your 7133499 change to 8u-dev in the 8u20 time frame > to make our AIX port work. Would this be OK for you? > I'm okay with this plan and if you re-generate the webrev without the async close changes then I can look at it quickly so that you can get it into the stage-9 forest. On 7133499 then it would be a good candidate for 8u-dev too, I don't expect any problems but we will need to get it approved on the jdk8u-dev list. -Alan. From volker.simonis at gmail.com Mon Jan 20 05:45:12 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 14:45:12 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52DD0B7C.4090605@oracle.com> References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> Message-ID: On Mon, Jan 20, 2014 at 12:41 PM, Alan Bateman wrote: > On 20/01/2014 09:59, Volker Simonis wrote: >> >> : >> Hi Alan, >> >> yes, that's interesting. Sounds like a very similar problem on Mac. >> >> I would suggest the following: >> >> I cut out the "Async Close AIX FIX" stuff from this change (i.e. >> "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression >> tests" and send out a new webrev for the remaining part. I think that >> the remaining part was more or less reviewed and we can then push it >> faster. >> >> In the mean time, I'll recheck which tests exactly fail with my >> missing "Async Close AIX FIX" stuff and which of these tests will be >> fixed by your 7133499 webrev. Maybe we can really get trough with it >> or with it and a few enhancements. I'll let you know my results later >> today. By the way, my webrev already contained a AixNativeThread.c >> implementation in src/aix/native/sun/nio/ch. >> >> The only remaining problem I see with this approach is that we would >> need to downport your 7133499 change to 8u-dev in the 8u20 time frame >> to make our AIX port work. Would this be OK for you? >> > I'm okay with this plan and if you re-generate the webrev without the async > close changes then I can look at it quickly so that you can get it into the > stage-9 forest. > > On 7133499 then it would be a good candidate for 8u-dev too, I don't expect > any problems but we will need to get it approved on the jdk8u-dev list. > > -Alan. Hi everybody, so here's the second version of this webrev: http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ The main changes compared to the first webrew are as follows: - the POLL-constants related stuff has been factored out into its own webrev ("8031997: PPC64: Make the various POLL constants system dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). - the "Async close on AIX" workarounds have been taken out as well and will be handled separately (probably together with Alans fix for http://cr.openjdk.java.net/~alanb/7133499/webrev/). - in the remaining files I've applied the changes suggested by Staffan, so I think the changes to the following files can be considered as reviewed: src/share/native/sun/management/DiagnosticCommandImpl.c src/solaris/native/sun/management/OperatingSystemImpl.c src/share/transport/socket/socketTransport.c src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider - I've added the following additional files to the change: src/aix/classes/sun/nio/ch/sctp/SctpChannelImpl.java src/aix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java src/aix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java which are just empty stub implementations of the SCTP classes needed to pass the SCTP jtreg tests. All other changes should be the same like in the first review round. Thanks, Volker From olivier.lagneau at oracle.com Mon Jan 20 06:51:15 2014 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Mon, 20 Jan 2014 15:51:15 +0100 Subject: RFR 8019389: SA-JDI JSR292: sun.jvm.hotspot.jdi.StackFrame.thisObject() throws sun.jvm.hotspot.utilities.AssertionFailure: sanity check Message-ID: <52DD37E3.1020402@oracle.com> Please review the following simple fix. Issue: https://bugs.openjdk.java.net/browse/JDK-8019389 Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.00/ The issue is due to the fact that _invokeHandle bytecode is generated by hotspot, but is not declared in agent code. Just declaring the new bytecode solves the assertion failure. However the tests reported in 8019389 (bootstrapOtherStratumInStackTrace, targetOtherStratumInStackTrace) suffer the problem from JDK-7016268 : Can't get strata information through SA-JDI Thus, the "stratum mismatch" related to JDK-7016268 will still be present after fix. This second problem has to be fixed through JDK-7016268. Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140120/d23cb365/attachment.html From taras.ledkov at oracle.com Mon Jan 20 07:07:34 2014 From: taras.ledkov at oracle.com (taras ledkov) Date: Mon, 20 Jan 2014 19:07:34 +0400 Subject: Review request for 7195249: Some jtreg tests use hard coded ports In-Reply-To: <52D6A61A.5020109@oracle.com> References: <529EF58F.5000701@oracle.com> <52A58687.6020708@oracle.com> <52A5953A.5040102@oracle.com> <52A7061E.8040002@oracle.com> <52BC2A7D.3070403@oracle.com> <52D6A61A.5020109@oracle.com> Message-ID: <52DD3BB6.2070607@oracle.com> Hi Staffan, I fixed the tests according with your comments. Are you OK? On 15.01.2014 19:15, taras ledkov wrote: > Hi, > > Please take a look at the new review. > > Webrev for jdk part: > http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.02/ > > Webrev for hs part: > http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.02/ > > My answers are inline: > > On 08.01.2014 17:46, Staffan Larsen wrote: >> Hi Taras, >> >> Thanks for doing this clean up and conversion of tests into Java. >> Here?s a couple of comments: >> >> test/runtime/6294277/SourceDebugExtension.java: >> This test could be simplified by not specifying an address at all. >> Since the test never connects to the JVM started with -Xrunjdwp, there >> is no reason to specify an address. If address is unspecified (and >> server=y), the connector will pick an address and print it to the >> command line. Thus the only change that needs to be done is to remove >> ",address=8888? from the @run command. > fixed > >> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh: >> test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh: >> These tests do not compile cleanly with an empty JTwork directory. It >> seems that having one @build for each class does not work well - when >> compiling RmiBootstrapTest.java it cannot find TestLogger. Moving all >> classes to one @build statement solved this problem for me. > fixed > >> test/lib/testlibrary/jdk/testlibrary/ProcessTools.java: >> 187 Future stdoutTask = stdout.process(); >> 188 Future stderrTask = stderr.process(); >> The stdoutTask and stderrTask variables are unused. > fixed > >> test/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java: >> At first I thought something was wrong with this file - the diff is >> very weird. Then I realized you renamed an old file and created a new >> file using the old name. > You are right. I did it to keep the test name. > >> test/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java: >> - Is resetPasswordFilePermission() really necessary? It looks like you >> delete the files at the beginning of the test in any case. > I think yes. n the first place, this functionality was at the old code. > In the second place, a file without write permission may be a problem > for a further cleanup (not by the test, for example for the tests > launcher scripts etc.) > >> - I find the names and usage of ?mgmt? and ?file2PermissionTest? >> confusing. They are both Paths. One is used directly by the >> sub-classes, the other has a getter method. > fixed > >> - Lines 57-58: Don?t swallow exceptions, add an ex.printStackTrace(). >> (Same thing for all other places where you call Integer.parseInt()) > fixed > >> test/sun/management/jmxremote/bootstrap/Dummy.java: >> This file is never used as far as I can see. > It is used by PasswordFilePermissionTest & SSLConfigFilePermissionTest > via the AbstractFilePermissionTest (see the doTest method, > AbstractFilePermissionTest : 162). > >> Thanks, >> /Staffan >> >> >> >> >> >> On 26 dec 2013, at 14:09, taras ledkov wrote: >> >>> Hi, >>> >>> Please take a look at the review with fixed issues about trying to >>> launch test that needs free port several times. >>> >>> Webrev for jdk part: >>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.01/ >>> >>> Webrev for hs part: >>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.01/ >>> >>> Pay your attention to new method ProcessTools.startProcess(String, >>> ProcessBuilder, Consumer) that is used to analyze all output >>> of a sub-process. It has common part with >>> ProcessTools.startProcess(String, ProcessBuilder, Predicate, >>> long, TumeUnit) that is used to determine the warm-up moment. >>> >>> I think the ProcessTools.startProcess(String, ProcessBuilder, >>> Predicate, long, TumeUnit) may be changed by adding LinePump >>> to stderr if there is not serious reason for restricting the warm-up >>> analysis to stdout stream. >>> >>> On 10.12.2013 16:16, Yekaterina Kantserova wrote: >>>> Hi, >>>> >>>> I've consulted with Serviceability engineers (add them to CC list) and >>>> they would like to see tests to solve these problem so far: >>>> >>>> 2. Implement loops in every test. >>>> >>>> Thanks, >>>> Katja >>>> >>>> >>>> On 12/09/2013 11:02 AM, Alexandre (Shura) Iline wrote: >>>>> Guys. >>>>> >>>>> Let me try to sum up what was said before and may be suggest a >>>>> compromise. >>>>> >>>>> 1. There is a desire to have a support port allocation on the level of >>>>> a JTReg suite execution. Taras created a bug for that >>>>> (https://bugs.openjdk.java.net/browse/JDK-7195249). Whether it is a >>>>> test harness API or a library API does not really matter from usage >>>>> point of view. >>>>> >>>>> 2. There is no way to make the tests absolutely stable, whatever port >>>>> allocation logic is used. The best we could do is to try to perform >>>>> the test logic with different ports until the test succeeds. >>>>> >>>>> Both arguments make sense. #2 is the ultimate answer, of course, but >>>>> better be used in conjunction with a meaningful port selection >>>>> algorithm. >>>>> >>>>> At the same time, copying a loop-until-success login from one test to >>>>> another may be not the best solution. Library could help with that I >>>>> believe. There only need to be an API method which takes behavior as a >>>>> parameter and run it until it succeeds. Something like: >>>>> public runOnAFreePort(Function) >>>>> or similar. There could be arguments of how/whether to implement it, >>>>> the solution would not work for shell tests, etc, but still ... >>>>> >>>>> >>>>> With the tests in question though, we have a few options. >>>>> >>>>> 1. Integrate tests as is. Get to it later after reaching agreement in >>>>> the library, etc. >>>>> 2. Implement loops in every test. >>>>> 3. Wait for the library to be ready and only then integrate the >>>>> changes. >>>>> >>>>> Please let us know which one is closer to your heart. >>>>> >>>>> I personally prefer #1 for the reason that the changes already >>>>> supposed to make the tests more stable and also there are many more >>>>> tests tests which use ports, so the scope of the problem is bigger >>>>> than these. >>>>> >>>>> Shura >>>>> >>>>> >>>>>> Taras, >>>>>> >>>>>> I agree with the previous comments, that Utils.getFreePort() does not >>>>>> guarantee the port will be still free when you start your process. >>>>>> Unfortunately I don't think the library can do more. However, >>>>>> there is a >>>>>> solution. >>>>>> >>>>>> Please, look at the *jdk/test/sun/tools/jstatd/JstatdTest.java >>>>>> tryToSetupJstatdProcess()*. In brief, the test will try to start a >>>>>> process with a free port and then check if >>>>>> /java.rmi.server.ExportException: Port already in use/ has been >>>>>> thrown. >>>>>> If yes, you have to retry. >>>>>> >>>>>> Thanks, >>>>>> Katja >>>>>> >>>>>> >>>>>> >>>>>> On 12/02/2013 01:39 PM, taras ledkov wrote: >>>>>>> Hi Everyone, >>>>>>> >>>>>>> Whatever logic is to be chosen to select a free port, it is the >>>>>>> library responsibility to implements it, would not you agree? >>>>>>> >>>>>>> Hence what I am suggesting is to integrate the tests as is. >>>>>>> >>>>>>> Should we decide to replace logic of the port selection, we could do >>>>>>> it later in the library. >>>>>>> >>>>>>> On 21.11.2013 15:00, Jaroslav Bachorik wrote: >>>>>>>> On 20.11.2013 18:38, Dmitry Samersoff wrote: >>>>>>>>> Roger, >>>>>>>>> >>>>>>>>> As soon as we close a socket nobody can guarantee that the port is >>>>>>>>> free. >>>>>>>>> >>>>>>>>> Moreover, port returned by getFreePort()[1] remains not accessible >>>>>>>>> for >>>>>>>>> some time - it depends to system setup, take a look to discussions >>>>>>>>> around SO_REUSEPORT for Linux or SO_REUSEADDR and SO_LINGER for >>>>>>>>> BSD. >>>>>>>>> >>>>>>>>> So from stability point of view it's better to just return random >>>>>>>>> number >>>>>>>>> between 49152 and 65535. >>>>>>>> >>>>>>>> Well, this doesn't seem to improve the odds by much. When there are >>>>>>>> more >>>>>>>> tests run in parallel, all of them requiring a free port, nothing >>>>>>>> prevents the random function to return the same port to all of >>>>>>>> them. >>>>>>>> Also, two subsequent requests can return the same port and cause >>>>>>>> problems with timing when a port used by a previous test is not >>>>>>>> fully >>>>>>>> ready to be assigned to a different socket. And as Dmitry >>>>>>>> pointed out >>>>>>>> unless one can keep hold of the allocated socket and use it later >>>>>>>> there >>>>>>>> is no guarantee that a port which was tested unallocated will >>>>>>>> remain >>>>>>>> unallocated also for the next few milliseconds. >>>>>>>> >>>>>>>> The only fail proof solution would be a port allocating service >>>>>>>> provided >>>>>>>> by the harness. Until then we can only (hopefully) decrease the >>>>>>>> chance >>>>>>>> of intermittent failures due to a port being in use. >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>>>>>>> 141 public static int getFreePort() throws >>>>>>>>> InterruptedException, >>>>>>>>> IOException { >>>>>>>>> 142 int port = -1; >>>>>>>>> 143 >>>>>>>>> 144 while (port <= 0) { >>>>>>>>> 145 Thread.sleep(100); >>>>>>>>> 146 >>>>>>>>> 147 ServerSocket serverSocket = null; >>>>>>>>> 148 try { >>>>>>>>> 149 serverSocket = new ServerSocket(0); >>>>>>>>> 150 port = serverSocket.getLocalPort(); >>>>>>>>> 151 } finally { >>>>>>>>> 152 serverSocket.close(); >>>>>>>>> 153 } >>>>>>>>> 154 } >>>>>>>>> 155 >>>>>>>>> 156 return port; >>>>>>>>> 157 } >>>>>>>>> 158 >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-11-20 19:40, roger riggs wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> fyi, The jdk.testlibrary.Utils.getFreePort() method will Open an >>>>>>>>>> free >>>>>>>>>> Socket, close it and return >>>>>>>>>> the port number. >>>>>>>>>> >>>>>>>>>> And as Alan recommended, use (0) when possible to have the system >>>>>>>>>> assign >>>>>>>>>> the port #. >>>>>>>>>> >>>>>>>>>> Roger >>>>>>>>>> >>>>>>>>>> On 11/20/2013 8:04 AM, Dmitry Samersoff wrote: >>>>>>>>>>> Taras, >>>>>>>>>>> >>>>>>>>>>> *The only* correct way to take really free port is: >>>>>>>>>>> >>>>>>>>>>> 1. Chose random number between 49152 and 65535 >>>>>>>>>>> 2. Open socket >>>>>>>>>>> >>>>>>>>>>> if socket fails - repeat step 1 >>>>>>>>>>> if socket OK - return *socket* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If you can't keep the socket open (e.g. you have to pass port >>>>>>>>>>> number as >>>>>>>>>>> property value) you shouldn't do any pre-check as it has no >>>>>>>>>>> value >>>>>>>>>>> - as >>>>>>>>>>> as soon as you close socket someone can take the port. >>>>>>>>>>> >>>>>>>>>>> So just choose a random number within the range above and let >>>>>>>>>>> networking >>>>>>>>>>> code opening socket to handle port conflict. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2013-11-20 15:54, taras ledkov wrote: >>>>>>>>>>>> Hi Everyone, >>>>>>>>>>>> >>>>>>>>>>>> I am working on bug >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7195249. >>>>>>>>>>>> >>>>>>>>>>>> There are two webrevs: >>>>>>>>>>>> Webrev for jdk part: >>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Webrev for hs part: >>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Please take a look at some notes: >>>>>>>>>>>> - After discussing with Yekaterina Kantserova & Jaroslav >>>>>>>>>>>> Bachorik >>>>>>>>>>>> some >>>>>>>>>>>> shell tests have been converted to java based tests >>>>>>>>>>>> >>>>>>>>>>>> - PasswordFilePermissionTest & SSLConfigFilePermissionTest >>>>>>>>>>>> tests >>>>>>>>>>>> looked >>>>>>>>>>>> very similar, so a common parent class was created for them: >>>>>>>>>>>> AbstractFilePermissionTest >>>>>>>>>>>> >>>>>>>>>>>> - What was called RmiRegistrySslTest.java I've renamed to >>>>>>>>>>>> RmiRegistrySslTestApp.java. The java code to replace old shell >>>>>>>>>>>> script >>>>>>>>>>>> RmiRegistrySslTest.sh is called RmiRegistrySslTest.java, >>>>>>>>>>>> hence the >>>>>>>>>>>> huge >>>>>>>>>>>> diff. >>>>>>>>>>>> >>>>>>>>>>>> - The new RmiRegistrySslTest.java has some lines similar to the >>>>>>>>>>>> AbstractFilePermissionTest.java, I nevertheless decided to not >>>>>>>>>>>> complicate the code further and leave it as is. Please let me >>>>>>>>>>>> know if >>>>>>>>>>>> this is somehow not acceptable >>>>>>>>>>>> >>>>>>>>>>>> - com/oracle/java/testlibrary/Utils.java that is added to >>>>>>>>>>>> hotspot >>>>>>>>>>>> repository is taken from this patch: >>>>>>>>>>>> http://cr.openjdk.java.net/~ykantser/8023138/webrev.00/test/lib/testlibrary/jdk/testlibrary/Utils.java.sdiff.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - These tests will need additional changes when test library >>>>>>>>>>>> process >>>>>>>>>>>> tools will support command line options inheritance >>>>>>>>>>>> (http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-November/013235.html) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >>> -- >>> With best regards, >>> Taras Ledkov >>> Mail-To: taras.ledkov at oracle.com >>> skype: taras_ledkov >>> Phone: 7(812)3346-157 >> > -- With best regards, Taras Ledkov Mail-To: taras.ledkov at oracle.com skype: taras_ledkov Phone: 7(812)3346-157 From shanliang.jiang at oracle.com Mon Jan 20 07:13:31 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 20 Jan 2014 16:13:31 +0100 Subject: RFR 8019389: SA-JDI JSR292: sun.jvm.hotspot.jdi.StackFrame.thisObject() throws sun.jvm.hotspot.utilities.AssertionFailure: sanity check In-Reply-To: <52DD37E3.1020402@oracle.com> References: <52DD37E3.1020402@oracle.com> Message-ID: <52DD3D1B.9070700@oracle.com> Olivier, Now it is 2014 :) Olivier Lagneau wrote: > Please review the following simple fix. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8019389 > Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.00/ > > > The issue is due to the fact that _invokeHandle bytecode is generated > by hotspot, > but is not declared in agent code. Just declaring the new bytecode > solves the assertion failure. > > However the tests reported in 8019389 > (bootstrapOtherStratumInStackTrace, targetOtherStratumInStackTrace) > suffer the problem from JDK-7016268 > : Can't get strata > information through SA-JDI > Thus, the "stratum mismatch" related to JDK-7016268 will still be > present after fix. > This second problem has to be fixed through JDK-7016268. > > Thanks, > Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140120/cee67876/attachment.html From staffan.larsen at oracle.com Mon Jan 20 07:21:12 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 20 Jan 2014 16:21:12 +0100 Subject: Review request for 7195249: Some jtreg tests use hard coded ports In-Reply-To: <52DD3BB6.2070607@oracle.com> References: <529EF58F.5000701@oracle.com> <52A58687.6020708@oracle.com> <52A5953A.5040102@oracle.com> <52A7061E.8040002@oracle.com> <52BC2A7D.3070403@oracle.com> <52D6A61A.5020109@oracle.com> <52DD3BB6.2070607@oracle.com> Message-ID: Sorry for not replying earlier. Yes, I?m ok with these changes. Thanks, /Staffan On 20 jan 2014, at 16:07, taras ledkov wrote: > Hi Staffan, > > I fixed the tests according with your comments. > Are you OK? > > On 15.01.2014 19:15, taras ledkov wrote: >> Hi, >> >> Please take a look at the new review. >> >> Webrev for jdk part: >> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.02/ >> >> Webrev for hs part: >> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.02/ >> >> My answers are inline: >> >> On 08.01.2014 17:46, Staffan Larsen wrote: >>> Hi Taras, >>> >>> Thanks for doing this clean up and conversion of tests into Java. >>> Here?s a couple of comments: >>> >>> test/runtime/6294277/SourceDebugExtension.java: >>> This test could be simplified by not specifying an address at all. >>> Since the test never connects to the JVM started with -Xrunjdwp, there >>> is no reason to specify an address. If address is unspecified (and >>> server=y), the connector will pick an address and print it to the >>> command line. Thus the only change that needs to be done is to remove >>> ",address=8888? from the @run command. >> fixed >> >>> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh: >>> test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh: >>> These tests do not compile cleanly with an empty JTwork directory. It >>> seems that having one @build for each class does not work well - when >>> compiling RmiBootstrapTest.java it cannot find TestLogger. Moving all >>> classes to one @build statement solved this problem for me. >> fixed >> >>> test/lib/testlibrary/jdk/testlibrary/ProcessTools.java: >>> 187 Future stdoutTask = stdout.process(); >>> 188 Future stderrTask = stderr.process(); >>> The stdoutTask and stderrTask variables are unused. >> fixed >> >>> test/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java: >>> At first I thought something was wrong with this file - the diff is >>> very weird. Then I realized you renamed an old file and created a new >>> file using the old name. >> You are right. I did it to keep the test name. >> >>> test/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java: >>> - Is resetPasswordFilePermission() really necessary? It looks like you >>> delete the files at the beginning of the test in any case. >> I think yes. n the first place, this functionality was at the old code. >> In the second place, a file without write permission may be a problem >> for a further cleanup (not by the test, for example for the tests >> launcher scripts etc.) >> >>> - I find the names and usage of ?mgmt? and ?file2PermissionTest? >>> confusing. They are both Paths. One is used directly by the >>> sub-classes, the other has a getter method. >> fixed >> >>> - Lines 57-58: Don?t swallow exceptions, add an ex.printStackTrace(). >>> (Same thing for all other places where you call Integer.parseInt()) >> fixed >> >>> test/sun/management/jmxremote/bootstrap/Dummy.java: >>> This file is never used as far as I can see. >> It is used by PasswordFilePermissionTest & SSLConfigFilePermissionTest >> via the AbstractFilePermissionTest (see the doTest method, >> AbstractFilePermissionTest : 162). >> >>> Thanks, >>> /Staffan >>> >>> >>> >>> >>> >>> On 26 dec 2013, at 14:09, taras ledkov wrote: >>> >>>> Hi, >>>> >>>> Please take a look at the review with fixed issues about trying to >>>> launch test that needs free port several times. >>>> >>>> Webrev for jdk part: >>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.01/ >>>> >>>> Webrev for hs part: >>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.01/ >>>> >>>> Pay your attention to new method ProcessTools.startProcess(String, >>>> ProcessBuilder, Consumer) that is used to analyze all output >>>> of a sub-process. It has common part with >>>> ProcessTools.startProcess(String, ProcessBuilder, Predicate, >>>> long, TumeUnit) that is used to determine the warm-up moment. >>>> >>>> I think the ProcessTools.startProcess(String, ProcessBuilder, >>>> Predicate, long, TumeUnit) may be changed by adding LinePump >>>> to stderr if there is not serious reason for restricting the warm-up >>>> analysis to stdout stream. >>>> >>>> On 10.12.2013 16:16, Yekaterina Kantserova wrote: >>>>> Hi, >>>>> >>>>> I've consulted with Serviceability engineers (add them to CC list) and >>>>> they would like to see tests to solve these problem so far: >>>>> >>>>> 2. Implement loops in every test. >>>>> >>>>> Thanks, >>>>> Katja >>>>> >>>>> >>>>> On 12/09/2013 11:02 AM, Alexandre (Shura) Iline wrote: >>>>>> Guys. >>>>>> >>>>>> Let me try to sum up what was said before and may be suggest a >>>>>> compromise. >>>>>> >>>>>> 1. There is a desire to have a support port allocation on the level of >>>>>> a JTReg suite execution. Taras created a bug for that >>>>>> (https://bugs.openjdk.java.net/browse/JDK-7195249). Whether it is a >>>>>> test harness API or a library API does not really matter from usage >>>>>> point of view. >>>>>> >>>>>> 2. There is no way to make the tests absolutely stable, whatever port >>>>>> allocation logic is used. The best we could do is to try to perform >>>>>> the test logic with different ports until the test succeeds. >>>>>> >>>>>> Both arguments make sense. #2 is the ultimate answer, of course, but >>>>>> better be used in conjunction with a meaningful port selection >>>>>> algorithm. >>>>>> >>>>>> At the same time, copying a loop-until-success login from one test to >>>>>> another may be not the best solution. Library could help with that I >>>>>> believe. There only need to be an API method which takes behavior as a >>>>>> parameter and run it until it succeeds. Something like: >>>>>> public runOnAFreePort(Function) >>>>>> or similar. There could be arguments of how/whether to implement it, >>>>>> the solution would not work for shell tests, etc, but still ... >>>>>> >>>>>> >>>>>> With the tests in question though, we have a few options. >>>>>> >>>>>> 1. Integrate tests as is. Get to it later after reaching agreement in >>>>>> the library, etc. >>>>>> 2. Implement loops in every test. >>>>>> 3. Wait for the library to be ready and only then integrate the >>>>>> changes. >>>>>> >>>>>> Please let us know which one is closer to your heart. >>>>>> >>>>>> I personally prefer #1 for the reason that the changes already >>>>>> supposed to make the tests more stable and also there are many more >>>>>> tests tests which use ports, so the scope of the problem is bigger >>>>>> than these. >>>>>> >>>>>> Shura >>>>>> >>>>>> >>>>>>> Taras, >>>>>>> >>>>>>> I agree with the previous comments, that Utils.getFreePort() does not >>>>>>> guarantee the port will be still free when you start your process. >>>>>>> Unfortunately I don't think the library can do more. However, >>>>>>> there is a >>>>>>> solution. >>>>>>> >>>>>>> Please, look at the *jdk/test/sun/tools/jstatd/JstatdTest.java >>>>>>> tryToSetupJstatdProcess()*. In brief, the test will try to start a >>>>>>> process with a free port and then check if >>>>>>> /java.rmi.server.ExportException: Port already in use/ has been >>>>>>> thrown. >>>>>>> If yes, you have to retry. >>>>>>> >>>>>>> Thanks, >>>>>>> Katja >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 12/02/2013 01:39 PM, taras ledkov wrote: >>>>>>>> Hi Everyone, >>>>>>>> >>>>>>>> Whatever logic is to be chosen to select a free port, it is the >>>>>>>> library responsibility to implements it, would not you agree? >>>>>>>> >>>>>>>> Hence what I am suggesting is to integrate the tests as is. >>>>>>>> >>>>>>>> Should we decide to replace logic of the port selection, we could do >>>>>>>> it later in the library. >>>>>>>> >>>>>>>> On 21.11.2013 15:00, Jaroslav Bachorik wrote: >>>>>>>>> On 20.11.2013 18:38, Dmitry Samersoff wrote: >>>>>>>>>> Roger, >>>>>>>>>> >>>>>>>>>> As soon as we close a socket nobody can guarantee that the port is >>>>>>>>>> free. >>>>>>>>>> >>>>>>>>>> Moreover, port returned by getFreePort()[1] remains not accessible >>>>>>>>>> for >>>>>>>>>> some time - it depends to system setup, take a look to discussions >>>>>>>>>> around SO_REUSEPORT for Linux or SO_REUSEADDR and SO_LINGER for >>>>>>>>>> BSD. >>>>>>>>>> >>>>>>>>>> So from stability point of view it's better to just return random >>>>>>>>>> number >>>>>>>>>> between 49152 and 65535. >>>>>>>>> >>>>>>>>> Well, this doesn't seem to improve the odds by much. When there are >>>>>>>>> more >>>>>>>>> tests run in parallel, all of them requiring a free port, nothing >>>>>>>>> prevents the random function to return the same port to all of >>>>>>>>> them. >>>>>>>>> Also, two subsequent requests can return the same port and cause >>>>>>>>> problems with timing when a port used by a previous test is not >>>>>>>>> fully >>>>>>>>> ready to be assigned to a different socket. And as Dmitry >>>>>>>>> pointed out >>>>>>>>> unless one can keep hold of the allocated socket and use it later >>>>>>>>> there >>>>>>>>> is no guarantee that a port which was tested unallocated will >>>>>>>>> remain >>>>>>>>> unallocated also for the next few milliseconds. >>>>>>>>> >>>>>>>>> The only fail proof solution would be a port allocating service >>>>>>>>> provided >>>>>>>>> by the harness. Until then we can only (hopefully) decrease the >>>>>>>>> chance >>>>>>>>> of intermittent failures due to a port being in use. >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> >>>>>>>>>> 141 public static int getFreePort() throws >>>>>>>>>> InterruptedException, >>>>>>>>>> IOException { >>>>>>>>>> 142 int port = -1; >>>>>>>>>> 143 >>>>>>>>>> 144 while (port <= 0) { >>>>>>>>>> 145 Thread.sleep(100); >>>>>>>>>> 146 >>>>>>>>>> 147 ServerSocket serverSocket = null; >>>>>>>>>> 148 try { >>>>>>>>>> 149 serverSocket = new ServerSocket(0); >>>>>>>>>> 150 port = serverSocket.getLocalPort(); >>>>>>>>>> 151 } finally { >>>>>>>>>> 152 serverSocket.close(); >>>>>>>>>> 153 } >>>>>>>>>> 154 } >>>>>>>>>> 155 >>>>>>>>>> 156 return port; >>>>>>>>>> 157 } >>>>>>>>>> 158 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2013-11-20 19:40, roger riggs wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> fyi, The jdk.testlibrary.Utils.getFreePort() method will Open an >>>>>>>>>>> free >>>>>>>>>>> Socket, close it and return >>>>>>>>>>> the port number. >>>>>>>>>>> >>>>>>>>>>> And as Alan recommended, use (0) when possible to have the system >>>>>>>>>>> assign >>>>>>>>>>> the port #. >>>>>>>>>>> >>>>>>>>>>> Roger >>>>>>>>>>> >>>>>>>>>>> On 11/20/2013 8:04 AM, Dmitry Samersoff wrote: >>>>>>>>>>>> Taras, >>>>>>>>>>>> >>>>>>>>>>>> *The only* correct way to take really free port is: >>>>>>>>>>>> >>>>>>>>>>>> 1. Chose random number between 49152 and 65535 >>>>>>>>>>>> 2. Open socket >>>>>>>>>>>> >>>>>>>>>>>> if socket fails - repeat step 1 >>>>>>>>>>>> if socket OK - return *socket* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If you can't keep the socket open (e.g. you have to pass port >>>>>>>>>>>> number as >>>>>>>>>>>> property value) you shouldn't do any pre-check as it has no >>>>>>>>>>>> value >>>>>>>>>>>> - as >>>>>>>>>>>> as soon as you close socket someone can take the port. >>>>>>>>>>>> >>>>>>>>>>>> So just choose a random number within the range above and let >>>>>>>>>>>> networking >>>>>>>>>>>> code opening socket to handle port conflict. >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2013-11-20 15:54, taras ledkov wrote: >>>>>>>>>>>>> Hi Everyone, >>>>>>>>>>>>> >>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7195249. >>>>>>>>>>>>> >>>>>>>>>>>>> There are two webrevs: >>>>>>>>>>>>> Webrev for jdk part: >>>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev for hs part: >>>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Please take a look at some notes: >>>>>>>>>>>>> - After discussing with Yekaterina Kantserova & Jaroslav >>>>>>>>>>>>> Bachorik >>>>>>>>>>>>> some >>>>>>>>>>>>> shell tests have been converted to java based tests >>>>>>>>>>>>> >>>>>>>>>>>>> - PasswordFilePermissionTest & SSLConfigFilePermissionTest >>>>>>>>>>>>> tests >>>>>>>>>>>>> looked >>>>>>>>>>>>> very similar, so a common parent class was created for them: >>>>>>>>>>>>> AbstractFilePermissionTest >>>>>>>>>>>>> >>>>>>>>>>>>> - What was called RmiRegistrySslTest.java I've renamed to >>>>>>>>>>>>> RmiRegistrySslTestApp.java. The java code to replace old shell >>>>>>>>>>>>> script >>>>>>>>>>>>> RmiRegistrySslTest.sh is called RmiRegistrySslTest.java, >>>>>>>>>>>>> hence the >>>>>>>>>>>>> huge >>>>>>>>>>>>> diff. >>>>>>>>>>>>> >>>>>>>>>>>>> - The new RmiRegistrySslTest.java has some lines similar to the >>>>>>>>>>>>> AbstractFilePermissionTest.java, I nevertheless decided to not >>>>>>>>>>>>> complicate the code further and leave it as is. Please let me >>>>>>>>>>>>> know if >>>>>>>>>>>>> this is somehow not acceptable >>>>>>>>>>>>> >>>>>>>>>>>>> - com/oracle/java/testlibrary/Utils.java that is added to >>>>>>>>>>>>> hotspot >>>>>>>>>>>>> repository is taken from this patch: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ykantser/8023138/webrev.00/test/lib/testlibrary/jdk/testlibrary/Utils.java.sdiff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - These tests will need additional changes when test library >>>>>>>>>>>>> process >>>>>>>>>>>>> tools will support command line options inheritance >>>>>>>>>>>>> (http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-November/013235.html) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>> -- >>>> With best regards, >>>> Taras Ledkov >>>> Mail-To: taras.ledkov at oracle.com >>>> skype: taras_ledkov >>>> Phone: 7(812)3346-157 >>> >> > > -- > With best regards, > Taras Ledkov > Mail-To: taras.ledkov at oracle.com > skype: taras_ledkov > Phone: 7(812)3346-157 From staffan.larsen at oracle.com Mon Jan 20 07:22:16 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 20 Jan 2014 16:22:16 +0100 Subject: RFR 8019389: SA-JDI JSR292: sun.jvm.hotspot.jdi.StackFrame.thisObject() throws sun.jvm.hotspot.utilities.AssertionFailure: sanity check In-Reply-To: <52DD37E3.1020402@oracle.com> References: <52DD37E3.1020402@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 20 jan 2014, at 15:51, Olivier Lagneau wrote: > Please review the following simple fix. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8019389 > Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.00/ > > The issue is due to the fact that _invokeHandle bytecode is generated by hotspot, > but is not declared in agent code. Just declaring the new bytecode solves the assertion failure. > > However the tests reported in 8019389 (bootstrapOtherStratumInStackTrace, targetOtherStratumInStackTrace) > suffer the problem from JDK-7016268 : Can't get strata information through SA-JDI > Thus, the "stratum mismatch" related to JDK-7016268 will still be present after fix. > This second problem has to be fixed through JDK-7016268. > > Thanks, > Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140120/db2fe0cb/attachment.html From Alan.Bateman at oracle.com Mon Jan 20 07:24:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 15:24:01 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> Message-ID: <52DD3F91.7020202@oracle.com> On 20/01/2014 13:45, Volker Simonis wrote: > : > Hi everybody, > > so here's the second version of this webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ This looks okay to me. The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can be fixed before you push this (no need to generate a few webrev of course). For the JDWP socket transport then it's interesting that shutdown is being used to cause the reader thread to be preempted. That may be useful when it comes to addressing the bigger async close issue. > > The main changes compared to the first webrew are as follows: > > - the POLL-constants related stuff has been factored out into its own > webrev ("8031997: PPC64: Make the various POLL constants system > dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). I see this has been pushed to ppc-aix-port/stage-9. Would you have any objection if I brought this into jdk9/dev (minus the AixPollPort change)? We can use a different bug number so as not to cause duplicate bug issues. It should trivially merge when you come to sync'ing up the staging forest. > - the "Async close on AIX" workarounds have been taken out as well > and will be handled separately Thanks for separating this one out as I suspect this that doing this cleanly is going to involve changes for all platforms. -Alan. From dmitry.samersoff at oracle.com Mon Jan 20 07:24:43 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 20 Jan 2014 19:24:43 +0400 Subject: RFR 8019389: SA-JDI JSR292: sun.jvm.hotspot.jdi.StackFrame.thisObject() throws sun.jvm.hotspot.utilities.AssertionFailure: sanity check In-Reply-To: <52DD37E3.1020402@oracle.com> References: <52DD37E3.1020402@oracle.com> Message-ID: <52DD3FBB.7050808@oracle.com> Olivier, Looks good for me. -Dmitry On 2014-01-20 18:51, Olivier Lagneau wrote: > Please review the following simple fix. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8019389 > Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.00/ > > > The issue is due to the fact that _invokeHandle bytecode is generated by > hotspot, > but is not declared in agent code. Just declaring the new bytecode > solves the assertion failure. > > However the tests reported in 8019389 > (bootstrapOtherStratumInStackTrace, targetOtherStratumInStackTrace) > suffer the problem from JDK-7016268 > : Can't get strata > information through SA-JDI > Thus, the "stratum mismatch" related to JDK-7016268 will still be > present after fix. > This second problem has to be fixed through JDK-7016268. > > Thanks, > Olivier. -- 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 Mon Jan 20 07:36:18 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 20 Jan 2014 19:36:18 +0400 Subject: RR(S): SA: Constantpool lookup for invokedynamic is not implemented Message-ID: <52DD4272.6050806@oracle.com> Hi Everyone, Please review a small fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8032247/webrev.01/ It's one of fixes required to support invokedynamic in SA ClassWriter. -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 dmitry.samersoff at oracle.com Mon Jan 20 08:00:34 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 20 Jan 2014 20:00:34 +0400 Subject: RR(S): JDK-7127191 SA JSDB does not display native symbols correctly for transported Linux cores Message-ID: <52DD4822.7080301@oracle.com> Hi Everyone, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.01/ This fix doesn't solve all problems with symbol lookup in SA, but address the problem mentioned in bug reports. 1. I change algorithm of pathmap_open. Now, it tries to find library hardly. 2. I decided not to fix broken binary search in loadObjectContainingPC, because with less then 20 DSO's we typically have here performance of just linear search is approx the same as load, sort, convert to array and do binary search. -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 volker.simonis at gmail.com Mon Jan 20 08:29:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 17:29:13 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52DD3F91.7020202@oracle.com> References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> <52DD3F91.7020202@oracle.com> Message-ID: On Mon, Jan 20, 2014 at 4:24 PM, Alan Bateman wrote: > On 20/01/2014 13:45, Volker Simonis wrote: >> >> : >> Hi everybody, >> >> so here's the second version of this webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ > > This looks okay to me. Thanks. > > The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can > be fixed before you push this (no need to generate a few webrev of course). > Sorry, I've just fixed it in my patch queue and will used the fixed version for pushing. @Vladimir: could you please run this change (http://cr.openjdk.java.net/~simonis/webrevs/8031581_2) through JPRT as well. I'll push it (together with the fixed typo in the comment) if everything is OK. > For the JDWP socket transport then it's interesting that shutdown is being > used to cause the reader thread to be preempted. That may be useful when it > comes to addressing the bigger async close issue. > > >> >> The main changes compared to the first webrew are as follows: >> >> - the POLL-constants related stuff has been factored out into its own >> webrev ("8031997: PPC64: Make the various POLL constants system >> dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). > > I see this has been pushed to ppc-aix-port/stage-9. Would you have any > objection if I brought this into jdk9/dev (minus the AixPollPort change)? We > can use a different bug number so as not to cause duplicate bug issues. It > should trivially merge when you come to sync'ing up the staging forest. > I have no objections of course. I'm just not sure what exact implications this will have. @Vladimir: what do you think - can Alan push "8031997: PPC64: Make the various POLL constants system dependant" minus the Aix-specific stuff to jdk9/dev now, without causing you any harm during integration. @Alan: on the other hand, the bulk integration from ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so maybe you could wait until that happens? Thanks, Volker > >> - the "Async close on AIX" workarounds have been taken out as well >> and will be handled separately > > Thanks for separating this one out as I suspect this that doing this cleanly > is going to involve changes for all platforms. > > -Alan. From Alan.Bateman at oracle.com Mon Jan 20 08:42:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 16:42:39 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> <52DD3F91.7020202@oracle.com> Message-ID: <52DD51FF.7060502@oracle.com> On 20/01/2014 16:29, Volker Simonis wrote: > : > > @Alan: on the other hand, the bulk integration from > ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so > maybe you could wait until that happens? > In that case then ignore my request, I assumed it would not be pushed to jdk9/dev until end-Feb. -Alan From olivier.lagneau at oracle.com Mon Jan 20 08:50:10 2014 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Mon, 20 Jan 2014 17:50:10 +0100 Subject: RFR 8019389: SA-JDI JSR292: sun.jvm.hotspot.jdi.StackFrame.thisObject() throws sun.jvm.hotspot.utilities.AssertionFailure: sanity check In-Reply-To: <52DD3D1B.9070700@oracle.com> References: <52DD37E3.1020402@oracle.com> <52DD3D1B.9070700@oracle.com> Message-ID: <52DD53C2.6070904@oracle.com> Oops, right ! Will fix that. Olivier. shanliang said on date 1/20/2014 4:13 PM: > Olivier, > > Now it is 2014 :) > > > Olivier Lagneau wrote: >> Please review the following simple fix. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8019389 >> Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.00/ >> >> >> The issue is due to the fact that _invokeHandle bytecode is generated >> by hotspot, >> but is not declared in agent code. Just declaring the new bytecode >> solves the assertion failure. >> >> However the tests reported in 8019389 >> (bootstrapOtherStratumInStackTrace, targetOtherStratumInStackTrace) >> suffer the problem from JDK-7016268 >> : Can't get strata >> information through SA-JDI >> Thus, the "stratum mismatch" related to JDK-7016268 will still be >> present after fix. >> This second problem has to be fixed through JDK-7016268. >> >> Thanks, >> Olivier. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140120/b50b075f/attachment.html From dmitry.samersoff at oracle.com Mon Jan 20 11:06:38 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 20 Jan 2014 23:06:38 +0400 Subject: RR(S): [JavaSecurityScanner] review package com.sun.management.* Native methods should be private Message-ID: <52DD73BE.70605@oracle.com> Hi Everyone, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8022323/webrev.01/ -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 jaroslav.bachorik at oracle.com Mon Jan 20 12:14:57 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 20 Jan 2014 21:14:57 +0100 Subject: RR(S): [JavaSecurityScanner] review package com.sun.management.* Native methods should be private In-Reply-To: <52DD73BE.70605@oracle.com> References: <52DD73BE.70605@oracle.com> Message-ID: <52DD83C1.90709@oracle.com> Looks good! -JB- On 20.1.2014 20:06, Dmitry Samersoff wrote: > Hi Everyone, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8022323/webrev.01/ > > -Dmitry > From staffan.larsen at oracle.com Mon Jan 20 23:46:18 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Jan 2014 08:46:18 +0100 Subject: RR(S): [JavaSecurityScanner] review package com.sun.management.* Native methods should be private In-Reply-To: <52DD73BE.70605@oracle.com> References: <52DD73BE.70605@oracle.com> Message-ID: Looks good, but you also need to update jdk/make/mapfiles/libmanagement/mapfile-vers. /Staffan On 20 jan 2014, at 20:06, Dmitry Samersoff wrote: > Hi Everyone, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8022323/webrev.01/ > > -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 staffan.larsen at oracle.com Mon Jan 20 23:59:57 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Jan 2014 08:59:57 +0100 Subject: jmx-dev [ping] Re: RFR 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <52D53804.8000505@oracle.com> References: <52862EDC.4080703@oracle.com> <52B03858.7040409@oracle.com> <52D51F24.7000904@oracle.com> <52D53804.8000505@oracle.com> Message-ID: <98D2338B-FD62-4B16-BA94-5D1A01D4BFCA@oracle.com> Looks good! And very sorry for letting this slip. Thanks, /Staffan On 14 jan 2014, at 14:13, Jaroslav Bachorik wrote: > Thanks, Staffan! > > On 14.1.2014 13:13, Staffan Larsen wrote: >> JMXStartStopTest.java:162 >> I see no path that calls testConnect with port == -1, so can we we remove the setting of port to 4567? I don?t like that hardcoded port, and I don?t see it being used. > > I've removed the port setting magic - now the testConnect(...) needs to be called with the requested port number. > > Also, there are some minor changes in the webrev due to merging. > > Updated webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.01 > > Cheers, > > -JB- > >> >> Other than that I think it looks good. >> >> /Staffan >> >> On 14 jan 2014, at 12:27, Jaroslav Bachorik wrote: >> >>> Ok, trying again. Could anyone, please, spare some time to review this test stabilization fix? >>> >>> Thanks! >>> >>> -JB- >>> >>> On 17.12.2013 12:41, Jaroslav Bachorik wrote: >>>> Anyone? >>>> >>>> -JB- >>>> >>>> On 15.11.2013 15:25, Jaroslav Bachorik wrote: >>>>> Please, review this test fix. >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8022221 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00 >>>>> >>>>> The test was facing intermittent failures due to not 100% failproof >>>>> interprocess synchronization using lock files. The solution is rewriting >>>>> the shell test to pure Java and use stdout/stderr processing for the >>>>> application started by the test to assess its status. >>>>> >>>>> A part of the change is also few improvements to the >>>>> jdk.testlibrary.ProcessTools. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From jaroslav.bachorik at oracle.com Tue Jan 21 00:01:34 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 21 Jan 2014 09:01:34 +0100 Subject: jmx-dev [ping] Re: RFR 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <98D2338B-FD62-4B16-BA94-5D1A01D4BFCA@oracle.com> References: <52862EDC.4080703@oracle.com> <52B03858.7040409@oracle.com> <52D51F24.7000904@oracle.com> <52D53804.8000505@oracle.com> <98D2338B-FD62-4B16-BA94-5D1A01D4BFCA@oracle.com> Message-ID: <52DE295E.7070400@oracle.com> On 21.1.2014 08:59, Staffan Larsen wrote: > Looks good! And very sorry for letting this slip. Thanks Staffan. NP! I guess I can leave the Utils in the patch for 8031559 :) -JB- > > Thanks, > /Staffan > > On 14 jan 2014, at 14:13, Jaroslav Bachorik wrote: > >> Thanks, Staffan! >> >> On 14.1.2014 13:13, Staffan Larsen wrote: >>> JMXStartStopTest.java:162 >>> I see no path that calls testConnect with port == -1, so can we we remove the setting of port to 4567? I don?t like that hardcoded port, and I don?t see it being used. >> >> I've removed the port setting magic - now the testConnect(...) needs to be called with the requested port number. >> >> Also, there are some minor changes in the webrev due to merging. >> >> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.01 >> >> Cheers, >> >> -JB- >> >>> >>> Other than that I think it looks good. >>> >>> /Staffan >>> >>> On 14 jan 2014, at 12:27, Jaroslav Bachorik wrote: >>> >>>> Ok, trying again. Could anyone, please, spare some time to review this test stabilization fix? >>>> >>>> Thanks! >>>> >>>> -JB- >>>> >>>> On 17.12.2013 12:41, Jaroslav Bachorik wrote: >>>>> Anyone? >>>>> >>>>> -JB- >>>>> >>>>> On 15.11.2013 15:25, Jaroslav Bachorik wrote: >>>>>> Please, review this test fix. >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8022221 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00 >>>>>> >>>>>> The test was facing intermittent failures due to not 100% failproof >>>>>> interprocess synchronization using lock files. The solution is rewriting >>>>>> the shell test to pure Java and use stdout/stderr processing for the >>>>>> application started by the test to assess its status. >>>>>> >>>>>> A part of the change is also few improvements to the >>>>>> jdk.testlibrary.ProcessTools. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >>> >> > From olivier.lagneau at oracle.com Tue Jan 21 00:41:50 2014 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Tue, 21 Jan 2014 09:41:50 +0100 Subject: RFR 8019389: SA-JDI JSR292: sun.jvm.hotspot.jdi.StackFrame.thisObject() throws sun.jvm.hotspot.utilities.AssertionFailure: sanity check In-Reply-To: <52DD53C2.6070904@oracle.com> References: <52DD37E3.1020402@oracle.com> <52DD3D1B.9070700@oracle.com> <52DD53C2.6070904@oracle.com> Message-ID: <52DE32CE.3080703@oracle.com> Please find the new webrev with copyright date fixed (changed to 2014). Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.01/ Olivier. Olivier Lagneau said on date 1/20/2014 5:50 PM: > Oops, right ! > > Will fix that. > > Olivier. > > shanliang said on date 1/20/2014 4:13 PM: >> Olivier, >> >> Now it is 2014 :) >> >> >> Olivier Lagneau wrote: >>> Please review the following simple fix. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8019389 >>> Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.00/ >>> >>> >>> The issue is due to the fact that _invokeHandle bytecode is >>> generated by hotspot, >>> but is not declared in agent code. Just declaring the new bytecode >>> solves the assertion failure. >>> >>> However the tests reported in 8019389 >>> (bootstrapOtherStratumInStackTrace, targetOtherStratumInStackTrace) >>> suffer the problem from JDK-7016268 >>> : Can't get >>> strata information through SA-JDI >>> Thus, the "stratum mismatch" related to JDK-7016268 will still be >>> present after fix. >>> This second problem has to be fixed through JDK-7016268. >>> >>> Thanks, >>> Olivier. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140121/330fa3d7/attachment.html From dmitry.samersoff at oracle.com Tue Jan 21 01:25:30 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Jan 2014 13:25:30 +0400 Subject: RR(S): JDK-8022323 [JavaSecurityScanner] review package com.sun.management.* Native methods should be private In-Reply-To: References: <52DD73BE.70605@oracle.com> Message-ID: <52DE3D0A.1090404@oracle.com> Staffan, Updated webrev with mapfile-vers changes. http://cr.openjdk.java.net/~dsamersoff/JDK-8022323/webrev.02/ -Dmitry On 2014-01-21 11:46, Staffan Larsen wrote: > Looks good, but you also need to update jdk/make/mapfiles/libmanagement/mapfile-vers. > > /Staffan > > On 20 jan 2014, at 20:06, Dmitry Samersoff wrote: > >> Hi Everyone, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8022323/webrev.01/ >> >> -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. > -- 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 taras.ledkov at oracle.com Tue Jan 21 01:30:37 2014 From: taras.ledkov at oracle.com (taras ledkov) Date: Tue, 21 Jan 2014 13:30:37 +0400 Subject: Review request for 7195249: Some jtreg tests use hard coded ports In-Reply-To: References: <529EF58F.5000701@oracle.com> <52A58687.6020708@oracle.com> <52A5953A.5040102@oracle.com> <52A7061E.8040002@oracle.com> <52BC2A7D.3070403@oracle.com> <52D6A61A.5020109@oracle.com> <52DD3BB6.2070607@oracle.com> Message-ID: <52DE3E3D.5070903@oracle.com> Hi Jaroslav, Could you please review the last changes? Are you OK? On 20.01.2014 19:21, Staffan Larsen wrote: > Sorry for not replying earlier. Yes, I?m ok with these changes. > > Thanks, > /Staffan > > On 20 jan 2014, at 16:07, taras ledkov wrote: > >> Hi Staffan, >> >> I fixed the tests according with your comments. >> Are you OK? >> >> On 15.01.2014 19:15, taras ledkov wrote: >>> Hi, >>> >>> Please take a look at the new review. >>> >>> Webrev for jdk part: >>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.02/ >>> >>> Webrev for hs part: >>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.02/ >>> >>> My answers are inline: >>> >>> On 08.01.2014 17:46, Staffan Larsen wrote: >>>> Hi Taras, >>>> >>>> Thanks for doing this clean up and conversion of tests into Java. >>>> Here?s a couple of comments: >>>> >>>> test/runtime/6294277/SourceDebugExtension.java: >>>> This test could be simplified by not specifying an address at all. >>>> Since the test never connects to the JVM started with -Xrunjdwp, there >>>> is no reason to specify an address. If address is unspecified (and >>>> server=y), the connector will pick an address and print it to the >>>> command line. Thus the only change that needs to be done is to remove >>>> ",address=8888? from the @run command. >>> fixed >>> >>>> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh: >>>> test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh: >>>> These tests do not compile cleanly with an empty JTwork directory. It >>>> seems that having one @build for each class does not work well - when >>>> compiling RmiBootstrapTest.java it cannot find TestLogger. Moving all >>>> classes to one @build statement solved this problem for me. >>> fixed >>> >>>> test/lib/testlibrary/jdk/testlibrary/ProcessTools.java: >>>> 187 Future stdoutTask = stdout.process(); >>>> 188 Future stderrTask = stderr.process(); >>>> The stdoutTask and stderrTask variables are unused. >>> fixed >>> >>>> test/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java: >>>> At first I thought something was wrong with this file - the diff is >>>> very weird. Then I realized you renamed an old file and created a new >>>> file using the old name. >>> You are right. I did it to keep the test name. >>> >>>> test/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java: >>>> - Is resetPasswordFilePermission() really necessary? It looks like you >>>> delete the files at the beginning of the test in any case. >>> I think yes. n the first place, this functionality was at the old code. >>> In the second place, a file without write permission may be a problem >>> for a further cleanup (not by the test, for example for the tests >>> launcher scripts etc.) >>> >>>> - I find the names and usage of ?mgmt? and ?file2PermissionTest? >>>> confusing. They are both Paths. One is used directly by the >>>> sub-classes, the other has a getter method. >>> fixed >>> >>>> - Lines 57-58: Don?t swallow exceptions, add an ex.printStackTrace(). >>>> (Same thing for all other places where you call Integer.parseInt()) >>> fixed >>> >>>> test/sun/management/jmxremote/bootstrap/Dummy.java: >>>> This file is never used as far as I can see. >>> It is used by PasswordFilePermissionTest & SSLConfigFilePermissionTest >>> via the AbstractFilePermissionTest (see the doTest method, >>> AbstractFilePermissionTest : 162). >>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> >>>> >>>> >>>> On 26 dec 2013, at 14:09, taras ledkov wrote: >>>> >>>>> Hi, >>>>> >>>>> Please take a look at the review with fixed issues about trying to >>>>> launch test that needs free port several times. >>>>> >>>>> Webrev for jdk part: >>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.01/ >>>>> >>>>> Webrev for hs part: >>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.01/ >>>>> >>>>> Pay your attention to new method ProcessTools.startProcess(String, >>>>> ProcessBuilder, Consumer) that is used to analyze all output >>>>> of a sub-process. It has common part with >>>>> ProcessTools.startProcess(String, ProcessBuilder, Predicate, >>>>> long, TumeUnit) that is used to determine the warm-up moment. >>>>> >>>>> I think the ProcessTools.startProcess(String, ProcessBuilder, >>>>> Predicate, long, TumeUnit) may be changed by adding LinePump >>>>> to stderr if there is not serious reason for restricting the warm-up >>>>> analysis to stdout stream. >>>>> >>>>> On 10.12.2013 16:16, Yekaterina Kantserova wrote: >>>>>> Hi, >>>>>> >>>>>> I've consulted with Serviceability engineers (add them to CC list) and >>>>>> they would like to see tests to solve these problem so far: >>>>>> >>>>>> 2. Implement loops in every test. >>>>>> >>>>>> Thanks, >>>>>> Katja >>>>>> >>>>>> >>>>>> On 12/09/2013 11:02 AM, Alexandre (Shura) Iline wrote: >>>>>>> Guys. >>>>>>> >>>>>>> Let me try to sum up what was said before and may be suggest a >>>>>>> compromise. >>>>>>> >>>>>>> 1. There is a desire to have a support port allocation on the level of >>>>>>> a JTReg suite execution. Taras created a bug for that >>>>>>> (https://bugs.openjdk.java.net/browse/JDK-7195249). Whether it is a >>>>>>> test harness API or a library API does not really matter from usage >>>>>>> point of view. >>>>>>> >>>>>>> 2. There is no way to make the tests absolutely stable, whatever port >>>>>>> allocation logic is used. The best we could do is to try to perform >>>>>>> the test logic with different ports until the test succeeds. >>>>>>> >>>>>>> Both arguments make sense. #2 is the ultimate answer, of course, but >>>>>>> better be used in conjunction with a meaningful port selection >>>>>>> algorithm. >>>>>>> >>>>>>> At the same time, copying a loop-until-success login from one test to >>>>>>> another may be not the best solution. Library could help with that I >>>>>>> believe. There only need to be an API method which takes behavior as a >>>>>>> parameter and run it until it succeeds. Something like: >>>>>>> public runOnAFreePort(Function) >>>>>>> or similar. There could be arguments of how/whether to implement it, >>>>>>> the solution would not work for shell tests, etc, but still ... >>>>>>> >>>>>>> >>>>>>> With the tests in question though, we have a few options. >>>>>>> >>>>>>> 1. Integrate tests as is. Get to it later after reaching agreement in >>>>>>> the library, etc. >>>>>>> 2. Implement loops in every test. >>>>>>> 3. Wait for the library to be ready and only then integrate the >>>>>>> changes. >>>>>>> >>>>>>> Please let us know which one is closer to your heart. >>>>>>> >>>>>>> I personally prefer #1 for the reason that the changes already >>>>>>> supposed to make the tests more stable and also there are many more >>>>>>> tests tests which use ports, so the scope of the problem is bigger >>>>>>> than these. >>>>>>> >>>>>>> Shura >>>>>>> >>>>>>> >>>>>>>> Taras, >>>>>>>> >>>>>>>> I agree with the previous comments, that Utils.getFreePort() does not >>>>>>>> guarantee the port will be still free when you start your process. >>>>>>>> Unfortunately I don't think the library can do more. However, >>>>>>>> there is a >>>>>>>> solution. >>>>>>>> >>>>>>>> Please, look at the *jdk/test/sun/tools/jstatd/JstatdTest.java >>>>>>>> tryToSetupJstatdProcess()*. In brief, the test will try to start a >>>>>>>> process with a free port and then check if >>>>>>>> /java.rmi.server.ExportException: Port already in use/ has been >>>>>>>> thrown. >>>>>>>> If yes, you have to retry. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Katja >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 12/02/2013 01:39 PM, taras ledkov wrote: >>>>>>>>> Hi Everyone, >>>>>>>>> >>>>>>>>> Whatever logic is to be chosen to select a free port, it is the >>>>>>>>> library responsibility to implements it, would not you agree? >>>>>>>>> >>>>>>>>> Hence what I am suggesting is to integrate the tests as is. >>>>>>>>> >>>>>>>>> Should we decide to replace logic of the port selection, we could do >>>>>>>>> it later in the library. >>>>>>>>> >>>>>>>>> On 21.11.2013 15:00, Jaroslav Bachorik wrote: >>>>>>>>>> On 20.11.2013 18:38, Dmitry Samersoff wrote: >>>>>>>>>>> Roger, >>>>>>>>>>> >>>>>>>>>>> As soon as we close a socket nobody can guarantee that the port is >>>>>>>>>>> free. >>>>>>>>>>> >>>>>>>>>>> Moreover, port returned by getFreePort()[1] remains not accessible >>>>>>>>>>> for >>>>>>>>>>> some time - it depends to system setup, take a look to discussions >>>>>>>>>>> around SO_REUSEPORT for Linux or SO_REUSEADDR and SO_LINGER for >>>>>>>>>>> BSD. >>>>>>>>>>> >>>>>>>>>>> So from stability point of view it's better to just return random >>>>>>>>>>> number >>>>>>>>>>> between 49152 and 65535. >>>>>>>>>> >>>>>>>>>> Well, this doesn't seem to improve the odds by much. When there are >>>>>>>>>> more >>>>>>>>>> tests run in parallel, all of them requiring a free port, nothing >>>>>>>>>> prevents the random function to return the same port to all of >>>>>>>>>> them. >>>>>>>>>> Also, two subsequent requests can return the same port and cause >>>>>>>>>> problems with timing when a port used by a previous test is not >>>>>>>>>> fully >>>>>>>>>> ready to be assigned to a different socket. And as Dmitry >>>>>>>>>> pointed out >>>>>>>>>> unless one can keep hold of the allocated socket and use it later >>>>>>>>>> there >>>>>>>>>> is no guarantee that a port which was tested unallocated will >>>>>>>>>> remain >>>>>>>>>> unallocated also for the next few milliseconds. >>>>>>>>>> >>>>>>>>>> The only fail proof solution would be a port allocating service >>>>>>>>>> provided >>>>>>>>>> by the harness. Until then we can only (hopefully) decrease the >>>>>>>>>> chance >>>>>>>>>> of intermittent failures due to a port being in use. >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> >>>>>>>>>>> 141 public static int getFreePort() throws >>>>>>>>>>> InterruptedException, >>>>>>>>>>> IOException { >>>>>>>>>>> 142 int port = -1; >>>>>>>>>>> 143 >>>>>>>>>>> 144 while (port <= 0) { >>>>>>>>>>> 145 Thread.sleep(100); >>>>>>>>>>> 146 >>>>>>>>>>> 147 ServerSocket serverSocket = null; >>>>>>>>>>> 148 try { >>>>>>>>>>> 149 serverSocket = new ServerSocket(0); >>>>>>>>>>> 150 port = serverSocket.getLocalPort(); >>>>>>>>>>> 151 } finally { >>>>>>>>>>> 152 serverSocket.close(); >>>>>>>>>>> 153 } >>>>>>>>>>> 154 } >>>>>>>>>>> 155 >>>>>>>>>>> 156 return port; >>>>>>>>>>> 157 } >>>>>>>>>>> 158 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2013-11-20 19:40, roger riggs wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> fyi, The jdk.testlibrary.Utils.getFreePort() method will Open an >>>>>>>>>>>> free >>>>>>>>>>>> Socket, close it and return >>>>>>>>>>>> the port number. >>>>>>>>>>>> >>>>>>>>>>>> And as Alan recommended, use (0) when possible to have the system >>>>>>>>>>>> assign >>>>>>>>>>>> the port #. >>>>>>>>>>>> >>>>>>>>>>>> Roger >>>>>>>>>>>> >>>>>>>>>>>> On 11/20/2013 8:04 AM, Dmitry Samersoff wrote: >>>>>>>>>>>>> Taras, >>>>>>>>>>>>> >>>>>>>>>>>>> *The only* correct way to take really free port is: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Chose random number between 49152 and 65535 >>>>>>>>>>>>> 2. Open socket >>>>>>>>>>>>> >>>>>>>>>>>>> if socket fails - repeat step 1 >>>>>>>>>>>>> if socket OK - return *socket* >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If you can't keep the socket open (e.g. you have to pass port >>>>>>>>>>>>> number as >>>>>>>>>>>>> property value) you shouldn't do any pre-check as it has no >>>>>>>>>>>>> value >>>>>>>>>>>>> - as >>>>>>>>>>>>> as soon as you close socket someone can take the port. >>>>>>>>>>>>> >>>>>>>>>>>>> So just choose a random number within the range above and let >>>>>>>>>>>>> networking >>>>>>>>>>>>> code opening socket to handle port conflict. >>>>>>>>>>>>> >>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2013-11-20 15:54, taras ledkov wrote: >>>>>>>>>>>>>> Hi Everyone, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7195249. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are two webrevs: >>>>>>>>>>>>>> Webrev for jdk part: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev for hs part: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please take a look at some notes: >>>>>>>>>>>>>> - After discussing with Yekaterina Kantserova & Jaroslav >>>>>>>>>>>>>> Bachorik >>>>>>>>>>>>>> some >>>>>>>>>>>>>> shell tests have been converted to java based tests >>>>>>>>>>>>>> >>>>>>>>>>>>>> - PasswordFilePermissionTest & SSLConfigFilePermissionTest >>>>>>>>>>>>>> tests >>>>>>>>>>>>>> looked >>>>>>>>>>>>>> very similar, so a common parent class was created for them: >>>>>>>>>>>>>> AbstractFilePermissionTest >>>>>>>>>>>>>> >>>>>>>>>>>>>> - What was called RmiRegistrySslTest.java I've renamed to >>>>>>>>>>>>>> RmiRegistrySslTestApp.java. The java code to replace old shell >>>>>>>>>>>>>> script >>>>>>>>>>>>>> RmiRegistrySslTest.sh is called RmiRegistrySslTest.java, >>>>>>>>>>>>>> hence the >>>>>>>>>>>>>> huge >>>>>>>>>>>>>> diff. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - The new RmiRegistrySslTest.java has some lines similar to the >>>>>>>>>>>>>> AbstractFilePermissionTest.java, I nevertheless decided to not >>>>>>>>>>>>>> complicate the code further and leave it as is. Please let me >>>>>>>>>>>>>> know if >>>>>>>>>>>>>> this is somehow not acceptable >>>>>>>>>>>>>> >>>>>>>>>>>>>> - com/oracle/java/testlibrary/Utils.java that is added to >>>>>>>>>>>>>> hotspot >>>>>>>>>>>>>> repository is taken from this patch: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ykantser/8023138/webrev.00/test/lib/testlibrary/jdk/testlibrary/Utils.java.sdiff.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - These tests will need additional changes when test library >>>>>>>>>>>>>> process >>>>>>>>>>>>>> tools will support command line options inheritance >>>>>>>>>>>>>> (http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-November/013235.html) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> -- >>>>> With best regards, >>>>> Taras Ledkov >>>>> Mail-To: taras.ledkov at oracle.com >>>>> skype: taras_ledkov >>>>> Phone: 7(812)3346-157 >>>> >>> >> >> -- >> With best regards, >> Taras Ledkov >> Mail-To: taras.ledkov at oracle.com >> skype: taras_ledkov >> Phone: 7(812)3346-157 > -- With best regards, Taras Ledkov Mail-To: taras.ledkov at oracle.com skype: taras_ledkov Phone: 7(812)3346-157 From staffan.larsen at oracle.com Tue Jan 21 01:35:19 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Jan 2014 10:35:19 +0100 Subject: RR(S): JDK-8022323 [JavaSecurityScanner] review package com.sun.management.* Native methods should be private In-Reply-To: <52DE3D0A.1090404@oracle.com> References: <52DD73BE.70605@oracle.com> <52DE3D0A.1090404@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 21 jan 2014, at 10:25, Dmitry Samersoff wrote: > Staffan, > > Updated webrev with mapfile-vers changes. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8022323/webrev.02/ > > -Dmitry > > On 2014-01-21 11:46, Staffan Larsen wrote: >> Looks good, but you also need to update jdk/make/mapfiles/libmanagement/mapfile-vers. >> >> /Staffan >> >> On 20 jan 2014, at 20:06, Dmitry Samersoff wrote: >> >>> Hi Everyone, >>> >>> Please review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8022323/webrev.01/ >>> >>> -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. >> > > > -- > 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 jaroslav.bachorik at oracle.com Tue Jan 21 01:45:31 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 21 Jan 2014 10:45:31 +0100 Subject: Review request for 7195249: Some jtreg tests use hard coded ports In-Reply-To: <52DE3E3D.5070903@oracle.com> References: <529EF58F.5000701@oracle.com> <52A58687.6020708@oracle.com> <52A5953A.5040102@oracle.com> <52A7061E.8040002@oracle.com> <52BC2A7D.3070403@oracle.com> <52D6A61A.5020109@oracle.com> <52DD3BB6.2070607@oracle.com> <52DE3E3D.5070903@oracle.com> Message-ID: <52DE41BB.40309@oracle.com> Hi Taras, On 21.1.2014 10:30, taras ledkov wrote: > Hi Jaroslav, > > Could you please review the last changes? > Are you OK? Yes, the change looks ok. But I think we will need to get back to this problem eventually and implement a central port dispatcher if we want to be 100% sure the port conflicts wouldn't occur. But your changes reduce the chance significantly. Thanks for taking care of this. -JB- > > On 20.01.2014 19:21, Staffan Larsen wrote: >> Sorry for not replying earlier. Yes, I?m ok with these changes. >> >> Thanks, >> /Staffan >> >> On 20 jan 2014, at 16:07, taras ledkov wrote: >> >>> Hi Staffan, >>> >>> I fixed the tests according with your comments. >>> Are you OK? >>> >>> On 15.01.2014 19:15, taras ledkov wrote: >>>> Hi, >>>> >>>> Please take a look at the new review. >>>> >>>> Webrev for jdk part: >>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.02/ >>>> >>>> Webrev for hs part: >>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.02/ >>>> >>>> My answers are inline: >>>> >>>> On 08.01.2014 17:46, Staffan Larsen wrote: >>>>> Hi Taras, >>>>> >>>>> Thanks for doing this clean up and conversion of tests into Java. >>>>> Here?s a couple of comments: >>>>> >>>>> test/runtime/6294277/SourceDebugExtension.java: >>>>> This test could be simplified by not specifying an address at all. >>>>> Since the test never connects to the JVM started with -Xrunjdwp, there >>>>> is no reason to specify an address. If address is unspecified (and >>>>> server=y), the connector will pick an address and print it to the >>>>> command line. Thus the only change that needs to be done is to remove >>>>> ",address=8888? from the @run command. >>>> fixed >>>> >>>>> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh: >>>>> test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh: >>>>> These tests do not compile cleanly with an empty JTwork directory. It >>>>> seems that having one @build for each class does not work well - when >>>>> compiling RmiBootstrapTest.java it cannot find TestLogger. Moving all >>>>> classes to one @build statement solved this problem for me. >>>> fixed >>>> >>>>> test/lib/testlibrary/jdk/testlibrary/ProcessTools.java: >>>>> 187 Future stdoutTask = stdout.process(); >>>>> 188 Future stderrTask = stderr.process(); >>>>> The stdoutTask and stderrTask variables are unused. >>>> fixed >>>> >>>>> test/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java: >>>>> At first I thought something was wrong with this file - the diff is >>>>> very weird. Then I realized you renamed an old file and created a new >>>>> file using the old name. >>>> You are right. I did it to keep the test name. >>>> >>>>> test/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java: >>>>> >>>>> - Is resetPasswordFilePermission() really necessary? It looks like you >>>>> delete the files at the beginning of the test in any case. >>>> I think yes. n the first place, this functionality was at the old code. >>>> In the second place, a file without write permission may be a problem >>>> for a further cleanup (not by the test, for example for the tests >>>> launcher scripts etc.) >>>> >>>>> - I find the names and usage of ?mgmt? and ?file2PermissionTest? >>>>> confusing. They are both Paths. One is used directly by the >>>>> sub-classes, the other has a getter method. >>>> fixed >>>> >>>>> - Lines 57-58: Don?t swallow exceptions, add an ex.printStackTrace(). >>>>> (Same thing for all other places where you call Integer.parseInt()) >>>> fixed >>>> >>>>> test/sun/management/jmxremote/bootstrap/Dummy.java: >>>>> This file is never used as far as I can see. >>>> It is used by PasswordFilePermissionTest & SSLConfigFilePermissionTest >>>> via the AbstractFilePermissionTest (see the doTest method, >>>> AbstractFilePermissionTest : 162). >>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 26 dec 2013, at 14:09, taras ledkov >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Please take a look at the review with fixed issues about trying to >>>>>> launch test that needs free port several times. >>>>>> >>>>>> Webrev for jdk part: >>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.01/ >>>>>> >>>>>> Webrev for hs part: >>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.01/ >>>>>> >>>>>> Pay your attention to new method ProcessTools.startProcess(String, >>>>>> ProcessBuilder, Consumer) that is used to analyze all output >>>>>> of a sub-process. It has common part with >>>>>> ProcessTools.startProcess(String, ProcessBuilder, Predicate, >>>>>> long, TumeUnit) that is used to determine the warm-up moment. >>>>>> >>>>>> I think the ProcessTools.startProcess(String, ProcessBuilder, >>>>>> Predicate, long, TumeUnit) may be changed by adding LinePump >>>>>> to stderr if there is not serious reason for restricting the warm-up >>>>>> analysis to stdout stream. >>>>>> >>>>>> On 10.12.2013 16:16, Yekaterina Kantserova wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've consulted with Serviceability engineers (add them to CC >>>>>>> list) and >>>>>>> they would like to see tests to solve these problem so far: >>>>>>> >>>>>>> 2. Implement loops in every test. >>>>>>> >>>>>>> Thanks, >>>>>>> Katja >>>>>>> >>>>>>> >>>>>>> On 12/09/2013 11:02 AM, Alexandre (Shura) Iline wrote: >>>>>>>> Guys. >>>>>>>> >>>>>>>> Let me try to sum up what was said before and may be suggest a >>>>>>>> compromise. >>>>>>>> >>>>>>>> 1. There is a desire to have a support port allocation on the >>>>>>>> level of >>>>>>>> a JTReg suite execution. Taras created a bug for that >>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-7195249). Whether it is a >>>>>>>> test harness API or a library API does not really matter from usage >>>>>>>> point of view. >>>>>>>> >>>>>>>> 2. There is no way to make the tests absolutely stable, whatever >>>>>>>> port >>>>>>>> allocation logic is used. The best we could do is to try to perform >>>>>>>> the test logic with different ports until the test succeeds. >>>>>>>> >>>>>>>> Both arguments make sense. #2 is the ultimate answer, of course, >>>>>>>> but >>>>>>>> better be used in conjunction with a meaningful port selection >>>>>>>> algorithm. >>>>>>>> >>>>>>>> At the same time, copying a loop-until-success login from one >>>>>>>> test to >>>>>>>> another may be not the best solution. Library could help with >>>>>>>> that I >>>>>>>> believe. There only need to be an API method which takes >>>>>>>> behavior as a >>>>>>>> parameter and run it until it succeeds. Something like: >>>>>>>> public runOnAFreePort(Function) >>>>>>>> or similar. There could be arguments of how/whether to implement >>>>>>>> it, >>>>>>>> the solution would not work for shell tests, etc, but still ... >>>>>>>> >>>>>>>> >>>>>>>> With the tests in question though, we have a few options. >>>>>>>> >>>>>>>> 1. Integrate tests as is. Get to it later after reaching >>>>>>>> agreement in >>>>>>>> the library, etc. >>>>>>>> 2. Implement loops in every test. >>>>>>>> 3. Wait for the library to be ready and only then integrate the >>>>>>>> changes. >>>>>>>> >>>>>>>> Please let us know which one is closer to your heart. >>>>>>>> >>>>>>>> I personally prefer #1 for the reason that the changes already >>>>>>>> supposed to make the tests more stable and also there are many more >>>>>>>> tests tests which use ports, so the scope of the problem is bigger >>>>>>>> than these. >>>>>>>> >>>>>>>> Shura >>>>>>>> >>>>>>>> >>>>>>>>> Taras, >>>>>>>>> >>>>>>>>> I agree with the previous comments, that Utils.getFreePort() >>>>>>>>> does not >>>>>>>>> guarantee the port will be still free when you start your process. >>>>>>>>> Unfortunately I don't think the library can do more. However, >>>>>>>>> there is a >>>>>>>>> solution. >>>>>>>>> >>>>>>>>> Please, look at the *jdk/test/sun/tools/jstatd/JstatdTest.java >>>>>>>>> tryToSetupJstatdProcess()*. In brief, the test will try to start a >>>>>>>>> process with a free port and then check if >>>>>>>>> /java.rmi.server.ExportException: Port already in use/ has been >>>>>>>>> thrown. >>>>>>>>> If yes, you have to retry. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Katja >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/02/2013 01:39 PM, taras ledkov wrote: >>>>>>>>>> Hi Everyone, >>>>>>>>>> >>>>>>>>>> Whatever logic is to be chosen to select a free port, it is the >>>>>>>>>> library responsibility to implements it, would not you agree? >>>>>>>>>> >>>>>>>>>> Hence what I am suggesting is to integrate the tests as is. >>>>>>>>>> >>>>>>>>>> Should we decide to replace logic of the port selection, we >>>>>>>>>> could do >>>>>>>>>> it later in the library. >>>>>>>>>> >>>>>>>>>> On 21.11.2013 15:00, Jaroslav Bachorik wrote: >>>>>>>>>>> On 20.11.2013 18:38, Dmitry Samersoff wrote: >>>>>>>>>>>> Roger, >>>>>>>>>>>> >>>>>>>>>>>> As soon as we close a socket nobody can guarantee that the >>>>>>>>>>>> port is >>>>>>>>>>>> free. >>>>>>>>>>>> >>>>>>>>>>>> Moreover, port returned by getFreePort()[1] remains not >>>>>>>>>>>> accessible >>>>>>>>>>>> for >>>>>>>>>>>> some time - it depends to system setup, take a look to >>>>>>>>>>>> discussions >>>>>>>>>>>> around SO_REUSEPORT for Linux or SO_REUSEADDR and SO_LINGER for >>>>>>>>>>>> BSD. >>>>>>>>>>>> >>>>>>>>>>>> So from stability point of view it's better to just return >>>>>>>>>>>> random >>>>>>>>>>>> number >>>>>>>>>>>> between 49152 and 65535. >>>>>>>>>>> >>>>>>>>>>> Well, this doesn't seem to improve the odds by much. When >>>>>>>>>>> there are >>>>>>>>>>> more >>>>>>>>>>> tests run in parallel, all of them requiring a free port, >>>>>>>>>>> nothing >>>>>>>>>>> prevents the random function to return the same port to all of >>>>>>>>>>> them. >>>>>>>>>>> Also, two subsequent requests can return the same port and cause >>>>>>>>>>> problems with timing when a port used by a previous test is not >>>>>>>>>>> fully >>>>>>>>>>> ready to be assigned to a different socket. And as Dmitry >>>>>>>>>>> pointed out >>>>>>>>>>> unless one can keep hold of the allocated socket and use it >>>>>>>>>>> later >>>>>>>>>>> there >>>>>>>>>>> is no guarantee that a port which was tested unallocated will >>>>>>>>>>> remain >>>>>>>>>>> unallocated also for the next few milliseconds. >>>>>>>>>>> >>>>>>>>>>> The only fail proof solution would be a port allocating service >>>>>>>>>>> provided >>>>>>>>>>> by the harness. Until then we can only (hopefully) decrease the >>>>>>>>>>> chance >>>>>>>>>>> of intermittent failures due to a port being in use. >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> >>>>>>>>>>>> 141 public static int getFreePort() throws >>>>>>>>>>>> InterruptedException, >>>>>>>>>>>> IOException { >>>>>>>>>>>> 142 int port = -1; >>>>>>>>>>>> 143 >>>>>>>>>>>> 144 while (port <= 0) { >>>>>>>>>>>> 145 Thread.sleep(100); >>>>>>>>>>>> 146 >>>>>>>>>>>> 147 ServerSocket serverSocket = null; >>>>>>>>>>>> 148 try { >>>>>>>>>>>> 149 serverSocket = new ServerSocket(0); >>>>>>>>>>>> 150 port = serverSocket.getLocalPort(); >>>>>>>>>>>> 151 } finally { >>>>>>>>>>>> 152 serverSocket.close(); >>>>>>>>>>>> 153 } >>>>>>>>>>>> 154 } >>>>>>>>>>>> 155 >>>>>>>>>>>> 156 return port; >>>>>>>>>>>> 157 } >>>>>>>>>>>> 158 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2013-11-20 19:40, roger riggs wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> fyi, The jdk.testlibrary.Utils.getFreePort() method will >>>>>>>>>>>>> Open an >>>>>>>>>>>>> free >>>>>>>>>>>>> Socket, close it and return >>>>>>>>>>>>> the port number. >>>>>>>>>>>>> >>>>>>>>>>>>> And as Alan recommended, use (0) when possible to have the >>>>>>>>>>>>> system >>>>>>>>>>>>> assign >>>>>>>>>>>>> the port #. >>>>>>>>>>>>> >>>>>>>>>>>>> Roger >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/20/2013 8:04 AM, Dmitry Samersoff wrote: >>>>>>>>>>>>>> Taras, >>>>>>>>>>>>>> >>>>>>>>>>>>>> *The only* correct way to take really free port is: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Chose random number between 49152 and 65535 >>>>>>>>>>>>>> 2. Open socket >>>>>>>>>>>>>> >>>>>>>>>>>>>> if socket fails - repeat step 1 >>>>>>>>>>>>>> if socket OK - return *socket* >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you can't keep the socket open (e.g. you have to pass port >>>>>>>>>>>>>> number as >>>>>>>>>>>>>> property value) you shouldn't do any pre-check as it has no >>>>>>>>>>>>>> value >>>>>>>>>>>>>> - as >>>>>>>>>>>>>> as soon as you close socket someone can take the port. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So just choose a random number within the range above and let >>>>>>>>>>>>>> networking >>>>>>>>>>>>>> code opening socket to handle port conflict. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2013-11-20 15:54, taras ledkov wrote: >>>>>>>>>>>>>>> Hi Everyone, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7195249. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There are two webrevs: >>>>>>>>>>>>>>> Webrev for jdk part: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev for hs part: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please take a look at some notes: >>>>>>>>>>>>>>> - After discussing with Yekaterina Kantserova & Jaroslav >>>>>>>>>>>>>>> Bachorik >>>>>>>>>>>>>>> some >>>>>>>>>>>>>>> shell tests have been converted to java based tests >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - PasswordFilePermissionTest & SSLConfigFilePermissionTest >>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>> looked >>>>>>>>>>>>>>> very similar, so a common parent class was created for them: >>>>>>>>>>>>>>> AbstractFilePermissionTest >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - What was called RmiRegistrySslTest.java I've renamed to >>>>>>>>>>>>>>> RmiRegistrySslTestApp.java. The java code to replace old >>>>>>>>>>>>>>> shell >>>>>>>>>>>>>>> script >>>>>>>>>>>>>>> RmiRegistrySslTest.sh is called RmiRegistrySslTest.java, >>>>>>>>>>>>>>> hence the >>>>>>>>>>>>>>> huge >>>>>>>>>>>>>>> diff. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - The new RmiRegistrySslTest.java has some lines similar >>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>> AbstractFilePermissionTest.java, I nevertheless decided >>>>>>>>>>>>>>> to not >>>>>>>>>>>>>>> complicate the code further and leave it as is. Please >>>>>>>>>>>>>>> let me >>>>>>>>>>>>>>> know if >>>>>>>>>>>>>>> this is somehow not acceptable >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - com/oracle/java/testlibrary/Utils.java that is added to >>>>>>>>>>>>>>> hotspot >>>>>>>>>>>>>>> repository is taken from this patch: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ykantser/8023138/webrev.00/test/lib/testlibrary/jdk/testlibrary/Utils.java.sdiff.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - These tests will need additional changes when test library >>>>>>>>>>>>>>> process >>>>>>>>>>>>>>> tools will support command line options inheritance >>>>>>>>>>>>>>> (http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-November/013235.html) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> With best regards, >>>>>> Taras Ledkov >>>>>> Mail-To: taras.ledkov at oracle.com >>>>>> skype: taras_ledkov >>>>>> Phone: 7(812)3346-157 >>>>> >>>> >>> >>> -- >>> With best regards, >>> Taras Ledkov >>> Mail-To: taras.ledkov at oracle.com >>> skype: taras_ledkov >>> Phone: 7(812)3346-157 >> > From jaroslav.bachorik at oracle.com Tue Jan 21 03:31:27 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 21 Jan 2014 12:31:27 +0100 Subject: RFR 8032377: test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java still fails intermittently Message-ID: <52DE5A8F.1050806@oracle.com> Please, review the following test fix. Issue : https://bugs.openjdk.java.net/browse/JDK-8032377 Webrev: http://cr.openjdk.java.net/~jbachorik/8032377/webrev.00 test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java still fails intermittently due to locking happening at the class loading level which is not 100% predictable. After many tries to force predictable behaviour it seems that the only way to fix this is to relax the test condition - so the test requires that the number of times the thread went blocked is equal or bigger than the anticipated number (the number of times the test forces the thread to block). Thanks, -JB- From david.holmes at oracle.com Tue Jan 21 03:57:21 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jan 2014 21:57:21 +1000 Subject: RFR 8032377: test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java still fails intermittently In-Reply-To: <52DE5A8F.1050806@oracle.com> References: <52DE5A8F.1050806@oracle.com> Message-ID: <52DE60A1.3000507@oracle.com> Ok. Thanks, David On 21/01/2014 9:31 PM, Jaroslav Bachorik wrote: > Please, review the following test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8032377 > Webrev: http://cr.openjdk.java.net/~jbachorik/8032377/webrev.00 > > test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java still > fails intermittently due to locking happening at the class loading level > which is not 100% predictable. After many tries to force predictable > behaviour it seems that the only way to fix this is to relax the test > condition - so the test requires that the number of times the thread > went blocked is equal or bigger than the anticipated number (the number > of times the test forces the thread to block). > > Thanks, > > -JB- From Alan.Bateman at oracle.com Tue Jan 21 04:09:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jan 2014 12:09:11 +0000 Subject: RFR 8032377: test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java still fails intermittently In-Reply-To: <52DE60A1.3000507@oracle.com> References: <52DE5A8F.1050806@oracle.com> <52DE60A1.3000507@oracle.com> Message-ID: <52DE6367.8090003@oracle.com> I've seen this fail once since the original changes and also agree with the proposed change. -Alan. On 21/01/2014 11:57, David Holmes wrote: > Ok. > > Thanks, > David > > On 21/01/2014 9:31 PM, Jaroslav Bachorik wrote: >> Please, review the following test fix. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8032377 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8032377/webrev.00 >> >> test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java still >> fails intermittently due to locking happening at the class loading level >> which is not 100% predictable. After many tries to force predictable >> behaviour it seems that the only way to fix this is to relax the test >> condition - so the test requires that the number of times the thread >> went blocked is equal or bigger than the anticipated number (the number >> of times the test forces the thread to block). >> >> Thanks, >> >> -JB- From mattias.tobiasson at oracle.com Tue Jan 21 04:32:44 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Tue, 21 Jan 2014 04:32:44 -0800 (PST) Subject: RFR(XS) 6545321: jstatLineCounts4.sh has to be resilient to unexpected output Message-ID: Hi, Could you please review this test fix. The current test is unstable and fails intermittently. The test parses output from jstat. It verifies number of header lines, data lines and total lines. The test sometimes fails because there are unexpected debug output from the jvm, which means that total line count does not match. The fix is to ignore total line count, and only verify header lines and data lines. There are multiple tests with the same problem. All have been fixed, even if the bug only mentions one test. bug: https://bugs.openjdk.java.net/browse/JDK-6545321 webrev: http://cr.openjdk.java.net/~ykantser/6545321/webrev.00/ Mattias From jaroslav.bachorik at oracle.com Tue Jan 21 05:14:16 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 21 Jan 2014 14:14:16 +0100 Subject: RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52B3FEBE.40106@oracle.com> References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com> <528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com> <528BB41A.4070107@oracle.com> <52A5AD7B.1060403@oracle.com> <52B3AB16.30206@oracle.com> <52B3FEBE.40106@oracle.com> Message-ID: <52DE72A8.9050807@oracle.com> Based on the experience while fixing https://bugs.openjdk.java.net/browse/JDK-8032377 I've updated the patch not to require an exact number for the blocked count - it will pass whenever the reported blocked count is at least large as the the expected number. Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.06 Thanks, -JB- On 20.12.2013 09:24, Jaroslav Bachorik wrote: > On 20.12.2013 03:27, David Holmes wrote: >> Sorry for the delay - still catching up after vacation (only 435 openjdk >> emails left :( ). > > NP > >> >> On 9/12/2013 9:46 PM, Jaroslav Bachorik wrote: >>> On 19.11.2013 19:55, David Holmes wrote: >>>> On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote: >>>>> Hi David, >>>>> >>>>> On 18.11.2013 22:03, David Holmes wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> I think your phaser usage is incorrect: >>>>>> >>>>>> 88 public void run() { >>>>>> 89 p.arriveAndAwaitAdvance(); // phase[1] >>>>>> 90 synchronized(lock1) { >>>>>> 91 System.out.println("[LockerThread obtained >>>>>> Lock1]"); >>>>>> 92 p.arrive(); // phase[2] >>>>>> 93 } >>>>>> 94 p.arriveAndAwaitAdvance(); // phase[3] >>>>>> 95 } >>>>>> >>>>>> Here the current thread can release itself at line 94. You have >>>>>> assumed >>>>>> that the phase[2] arrive will be a trigger to release the main thread >>>>>> but it may not have reached its arriveAndAwaitAdvance phase[2] >>>>>> statement >>>>>> yet, so the current thread arrives then does arrive-and-wait but the >>>>>> number of arrivals is 2 so it doesn't wait. >>>>>> >>>>>> A CyclicBarrier per phase may be clearer. >>>>> >>>>> Yes, thanks for pointing this out. But, wouldn't >>>>> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've tried to >>>>> replace Phaser with CyclicBarrier but while it seems to work as >>>>> expected >>>>> it pollutes code with the necessity to catch various exceptions >>>>> (InterruptedException, BarrierException etc.). So, if the simple fix >>>>> with Phaser would do the trick I would better use that. >>>> >>>> In this case yes arriveAndAwaitAdvance would fix it. I don't know if >>>> other tests have the same issue - the concern would be ensuring there's >>>> no possibility of deadlocks in general. >>> >>> I've updated the webrev with the one using p.arriveAndAwaitAdvance() at >>> line 92 - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.04 >>> >>> Are you ok with this change then? >> >> I think you have the same problem anywhere that arrive() is used eg: >> >> 129 p.arrive(); // phase[2] >> 130 p.arriveAndAwaitAdvance(); // phase[3] >> >> and >> >> 185 p.arrive(); // phase[2] >> 186 } >> 187 p.arriveAndAwaitAdvance(); // phase[3] > > Very probable :( Also, when analysing the recurrence of JDK-8029890 I've > found out that Phaser.arriveAndAwaitAdvance() actually blocked the > thread in a way that it increased the number of contentions reported :( > CyclicBarrier seems to wait instead - I will have to use CyclicBarrier > when testing the number of reported contentions and Phaser when testing > the number of reported waits :/ > > -JB- > >> >> David >> ------ >> >>> Thanks, >>> >>> -JB- >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> >>>>>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote: >>>>>>> Hi, >>>>>>> >>>>>>> after discussing this with Mandy I've rewritten the test to use the >>>>>>> j.u.concurrent for synchronization - this also makes it much >>>>>>> easier to >>>>>>> follow the test logic. >>>>>>> >>>>>>> The waited time, the blocked time and the waited counts are only >>>>>>> checked >>>>>>> for sanity (increasing values) since it is not possible to do the >>>>>>> reliable checks against hard numbers. >>>>>>> >>>>>>> I ran the test in a tight loop for 1500 times using -Xcomp and -Xint >>>>>>> and >>>>>>> the test seems to pass constantly. >>>>>>> >>>>>>> New webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03 >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote: >>>>>>>> Please, review this small patch for a test failing due to the >>>>>>>> updated >>>>>>>> implementation in JDK6. >>>>>>>> >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>>>>>> >>>>>>>> The test fails due to the change in mustang where >>>>>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>>>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include >>>>>>>> Thread.sleep() >>>>>>>> too. Unfortunately, Thread.sleep() is used throughout the test for >>>>>>>> synchronization purposes and this breaks the test. >>>>>>>> >>>>>>>> In the patch I propose to replace Thread.sleep() with busy wait and >>>>>>>> hinting the scheduler by Thread.yield(). While not very elegant it >>>>>>>> successfully works around inclusion of unknown number of >>>>>>>> Thread.sleep()s >>>>>>>> (they are called in loop). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>>> >>>>> >>> > From staffan.larsen at oracle.com Tue Jan 21 05:47:38 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Jan 2014 14:47:38 +0100 Subject: RFR(S): JDK-8032250 : Add trace event for VM flag changes Message-ID: <4213C88C-3617-466C-909B-F8DAA37C8015@oracle.com> This is a patch to capture a trace event whenever a manageable VM flag is changed in runtime. webrev: http://cr.openjdk.java.net/~sla/8032250/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8032250 Thanks, /Staffan From dmitry.samersoff at oracle.com Tue Jan 21 05:49:36 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Jan 2014 17:49:36 +0400 Subject: RR(XS): This JdbReadTwiceTest.sh gets an exit 1 Message-ID: <52DE7AF0.1030901@oracle.com> Hi Everyone, Please review. http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ I can't reproduce the issue locally, but suspect, the test failed because after chmod a-r the file is sill readable. So check it explicitly before run the test itself. -- 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 Tue Jan 21 06:00:28 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Jan 2014 18:00:28 +0400 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <52DE7AF0.1030901@oracle.com> References: <52DE7AF0.1030901@oracle.com> Message-ID: <52DE7D7C.8090007@oracle.com> Missed CR in subject. Sorry! http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ On 2014-01-21 17:49, Dmitry Samersoff wrote: > Hi Everyone, > > Please review. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ > > I can't reproduce the issue locally, but suspect, the test failed > because after chmod a-r the file is sill readable. So check it > explicitly before run the test itself. > -- 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 markus.gronlund at oracle.com Tue Jan 21 06:43:30 2014 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 21 Jan 2014 06:43:30 -0800 (PST) Subject: RFR(S): JDK-8032250 : Add trace event for VM flag changes In-Reply-To: <4213C88C-3617-466C-909B-F8DAA37C8015@oracle.com> References: <4213C88C-3617-466C-909B-F8DAA37C8015@oracle.com> Message-ID: <67fb78c5-b9b3-491c-ac2a-9af7d2bb2ff7@default> Looks good. /Markus -----Original Message----- From: Staffan Larsen Sent: den 21 januari 2014 14:48 To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev Subject: RFR(S): JDK-8032250 : Add trace event for VM flag changes This is a patch to capture a trace event whenever a manageable VM flag is changed in runtime. webrev: http://cr.openjdk.java.net/~sla/8032250/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8032250 Thanks, /Staffan From staffan.larsen at oracle.com Tue Jan 21 06:49:07 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Jan 2014 15:49:07 +0100 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <52DE7D7C.8090007@oracle.com> References: <52DE7AF0.1030901@oracle.com> <52DE7D7C.8090007@oracle.com> Message-ID: <0D2DDFBC-BA46-42B5-8A86-E7DE2710488F@oracle.com> Should we really be skipping the test if this fail? Isn?t it an infrastructure bug if we can?t make the file unreadable? I think the test should fail, but say why it failed: ?could not make $HOME/jdb.ini unreadable? and perhaps include the current permissions on the file and directory for debugging purposes. /Staffan On 21 jan 2014, at 15:00, Dmitry Samersoff wrote: > Missed CR in subject. Sorry! > > http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ > > > On 2014-01-21 17:49, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Please review. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >> >> I can't reproduce the issue locally, but suspect, the test failed >> because after chmod a-r the file is sill readable. So check it >> explicitly before run the test itself. >> > > > -- > 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 jaroslav.bachorik at oracle.com Tue Jan 21 07:50:51 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 21 Jan 2014 16:50:51 +0100 Subject: RFR 8031701: java/lang/management/ThreadMXBean/Locks.java: Thread WaitingThread is expected to wait on Object but got null Thread.State = RUNNABLE Message-ID: <52DE975B.4090802@oracle.com> Please, review the following test fix. Issue : https://bugs.openjdk.java.net/browse/JDK-8031701 Webrev: http://cr.openjdk.java.net/~jbachorik/8031701/webrev.00 The ThreadExecutionSynchronizer was replaced by Phaser - this should give more predictable results. Also, "checkBlockedObject()" failed to re-retrieve the ThreadInfo while waiting for the thread to become blocked. This would lead to timing out the test and producing the error message used as the issue subject. The fix for this is at L78-79 Thanks, -JB- From dmitry.samersoff at oracle.com Tue Jan 21 08:00:48 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Jan 2014 20:00:48 +0400 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <0D2DDFBC-BA46-42B5-8A86-E7DE2710488F@oracle.com> References: <52DE7AF0.1030901@oracle.com> <52DE7D7C.8090007@oracle.com> <0D2DDFBC-BA46-42B5-8A86-E7DE2710488F@oracle.com> Message-ID: <52DE99B0.30009@oracle.com> Staffan, We already skip this test under MS Windows. But I'm OK to make the test fail. PS: This time the test was running as root - this is the reason of failure. -Dmitry On 2014-01-21 18:49, Staffan Larsen wrote: > Should we really be skipping the test if this fail? Isn?t it an > infrastructure bug if we can?t make the file unreadable? I think the > test should fail, but say why it failed: ?could not make > $HOME/jdb.ini unreadable? and perhaps include the current permissions > on the file and directory for debugging purposes. > > /Staffan > > On 21 jan 2014, at 15:00, Dmitry Samersoff > wrote: > >> Missed CR in subject. Sorry! >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >> >> >> On 2014-01-21 17:49, Dmitry Samersoff wrote: >>> Hi Everyone, >>> >>> Please review. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>> >>> I can't reproduce the issue locally, but suspect, the test >>> failed because after chmod a-r the file is sill readable. So >>> check it explicitly before run the test itself. >>> >> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >> Russia * I would love to change the world, but they won't give me >> the sources. > -- 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 lana.steuck at oracle.com Tue Jan 21 11:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl: 5 new changesets Message-ID: <20140121190312.C650E625FA@hg.openjdk.java.net> Changeset: ca4612164195 Author: lana Date: 2014-01-08 11:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ca4612164195 Merge Changeset: b5e1dad69605 Author: jeff Date: 2014-01-13 14:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b5e1dad69605 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 6ac7d4011e8a Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6ac7d4011e8a Merge Changeset: 790bbd46b201 Author: lana Date: 2014-01-15 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/790bbd46b201 Merge Changeset: 0623ae55afff Author: katleman Date: 2014-01-17 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0623ae55afff Added tag jdk8-b124 for changeset 790bbd46b201 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:15 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:15 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20140121190344.1A946625FF@hg.openjdk.java.net> Changeset: d5aab8300d3b Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d5aab8300d3b Added tag jdk8-b123 for changeset a345cf28faca ! .hgtags Changeset: 4a5e16002234 Author: lana Date: 2014-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a5e16002234 Merge Changeset: e90611913bb1 Author: jeff Date: 2014-01-13 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e90611913bb1 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 91e6cd536c34 Author: lana Date: 2014-01-13 22:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/91e6cd536c34 Merge Changeset: 436176151e85 Author: lana Date: 2014-01-15 10:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/436176151e85 Merge Changeset: 9e35f82eec22 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9e35f82eec22 Added tag jdk8-b124 for changeset 436176151e85 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl/corba: 5 new changesets Message-ID: <20140121190318.21207625FB@hg.openjdk.java.net> Changeset: afecd2878aee Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/afecd2878aee Added tag jdk8-b123 for changeset 1ecd4619f60c ! .hgtags Changeset: b509e2e0fc41 Author: jeff Date: 2014-01-13 14:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b509e2e0fc41 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 33e3d3425095 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/33e3d3425095 Merge Changeset: 7b45151c7a05 Author: lana Date: 2014-01-15 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7b45151c7a05 Merge Changeset: 6b66ffd36885 Author: katleman Date: 2014-01-17 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6b66ffd36885 Added tag jdk8-b124 for changeset 7b45151c7a05 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20140121190322.3C85A625FC@hg.openjdk.java.net> Changeset: 3356919b1639 Author: jeff Date: 2014-01-13 14:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3356919b1639 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: aefba9e5e35c Author: lana Date: 2014-01-13 22:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aefba9e5e35c Merge Changeset: 7346abe2ea03 Author: lana Date: 2014-01-15 10:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7346abe2ea03 Merge Changeset: 40192ec6af87 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/40192ec6af87 Added tag jdk8-b124 for changeset 7346abe2ea03 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:17 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:17 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20140121190335.DFCF8625FE@hg.openjdk.java.net> Changeset: 241e4effed6d Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/241e4effed6d Added tag jdk8-b123 for changeset 91f5c542ccad ! .hgtags Changeset: c71b6b41a2a1 Author: jeff Date: 2014-01-13 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c71b6b41a2a1 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 9ed8a0577511 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9ed8a0577511 Merge Changeset: ef71ecbcd7bc Author: lana Date: 2014-01-15 10:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ef71ecbcd7bc Merge Changeset: b14885a461b3 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b14885a461b3 Added tag jdk8-b124 for changeset ef71ecbcd7bc ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20140121190335.3FF2F625FD@hg.openjdk.java.net> Changeset: 1a28f773c894 Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1a28f773c894 Added tag jdk8-b123 for changeset 4e35b5b6d2e5 ! .hgtags Changeset: d906d69e24a3 Author: jeff Date: 2014-01-13 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d906d69e24a3 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: a7c0452ab987 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a7c0452ab987 Merge Changeset: 83bb924238f8 Author: lana Date: 2014-01-15 10:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/83bb924238f8 Merge Changeset: 5a4e9ef8673d Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5a4e9ef8673d Added tag jdk8-b124 for changeset 83bb924238f8 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:12 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:12 +0000 Subject: hg: jdk8/tl/hotspot: 10 new changesets Message-ID: <20140121190346.1F25862600@hg.openjdk.java.net> Changeset: c89630a122b4 Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c89630a122b4 Added tag jdk8-b123 for changeset 591135a7d6f9 ! .hgtags Changeset: f898fdfc08a5 Author: jeff Date: 2014-01-13 14:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f898fdfc08a5 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: b99955ea4b91 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b99955ea4b91 Merge Changeset: 9d39e8a8ff61 Author: amurillo Date: 2013-12-27 07:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d39e8a8ff61 8031060: new hotspot build - hs25-b66 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c3f3cfd39184 Author: hseigel Date: 2014-01-10 12:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3f3cfd39184 8031059: invokestatic: ICCE trying to invoke static method when it clashes with an abstract method inherited from an interface Summary: Do not create AME overpass if there is a matching static method Reviewed-by: lfoltan, coleenp, kamg ! src/share/vm/classfile/defaultMethods.cpp Changeset: 9b9816164447 Author: amurillo Date: 2014-01-13 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b9816164447 Merge Changeset: ac902fca803b Author: amurillo Date: 2014-01-13 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ac902fca803b Added tag hs25-b66 for changeset 9b9816164447 ! .hgtags Changeset: 2c3130311ffa Author: amurillo Date: 2014-01-14 11:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c3130311ffa Merge Changeset: df333ee12bba Author: lana Date: 2014-01-15 10:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df333ee12bba Merge Changeset: e2e6ca7e0ea6 Author: katleman Date: 2014-01-17 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2e6ca7e0ea6 Added tag jdk8-b124 for changeset df333ee12bba ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:04:00 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:04:00 +0000 Subject: hg: jdk8/tl/jdk: 8 new changesets Message-ID: <20140121190556.93AC862601@hg.openjdk.java.net> Changeset: 9683419eddef Author: lana Date: 2014-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9683419eddef Merge Changeset: 2551e7290450 Author: jeff Date: 2014-01-13 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2551e7290450 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 01a6b4654550 Author: lana Date: 2014-01-13 22:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01a6b4654550 Merge Changeset: 2a3afe1ec514 Author: rgallard Date: 2014-01-09 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a3afe1ec514 8026909: Retire Some Rarely Used GC Combintations Summary: Fix only affects java command, nroff page, OpenJDK Reviewed-by: maxelsso ! src/bsd/doc/man/java.1 ! src/linux/doc/man/java.1 ! src/solaris/doc/sun/man/man1/java.1 Changeset: acc59aae7992 Author: katleman Date: 2014-01-14 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acc59aae7992 Merge Changeset: f1f3596239a4 Author: lana Date: 2014-01-15 10:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1f3596239a4 Merge - src/bsd/doc/man/ja/kinit.1 - src/bsd/doc/man/ja/klist.1 - src/bsd/doc/man/ja/ktab.1 Changeset: ae303640bc1c Author: lana Date: 2014-01-16 10:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae303640bc1c Merge - src/bsd/doc/man/ja/kinit.1 - src/bsd/doc/man/ja/klist.1 - src/bsd/doc/man/ja/ktab.1 Changeset: 3e9b46280c16 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e9b46280c16 Added tag jdk8-b124 for changeset ae303640bc1c ! .hgtags From jesper.wilhelmsson at oracle.com Tue Jan 21 13:49:19 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 21 Jan 2014 22:49:19 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable Message-ID: <52DEEB5F.6020306@oracle.com> Hi, Could I have a few reviews of this change? Summary: To allow applications a more fine grained control over the GC over time, we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. The initial request that lead up to this change involved ParallelGC which is notoriously unwilling to shrink the heap. Since ParallelGC didn't support the heap free ratio flags, this change also includes implementing support for these flags in ParallelGC. Changes have also been made to the argument parsing, attach listener and the management API to verify the flag values when set through the different interfaces. Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 The plan is to push this to 9 and then backport to 8 and 7. Thanks! /Jesper From david.holmes at oracle.com Tue Jan 21 22:25:47 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2014 16:25:47 +1000 Subject: RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52DE72A8.9050807@oracle.com> References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com> <528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com> <528BB41A.4070107@oracle.com> <52A5AD7B.1060403@oracle.com> <52B3AB16.30206@oracle.com> <52B3FEBE.40106@oracle.com> <52DE72A8.9050807@oracle.com> Message-ID: <52DF646B.3000606@oracle.com> Hi Jaroslav, I still see some suspect uses of p.arrive() instead of p.arriveAndAwaitAdvance(). David On 21/01/2014 11:14 PM, Jaroslav Bachorik wrote: > Based on the experience while fixing > https://bugs.openjdk.java.net/browse/JDK-8032377 I've updated the patch > not to require an exact number for the blocked count - it will pass > whenever the reported blocked count is at least large as the the > expected number. > > Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.06 > > Thanks, > > -JB- > > On 20.12.2013 09:24, Jaroslav Bachorik wrote: >> On 20.12.2013 03:27, David Holmes wrote: >>> Sorry for the delay - still catching up after vacation (only 435 openjdk >>> emails left :( ). >> >> NP >> >>> >>> On 9/12/2013 9:46 PM, Jaroslav Bachorik wrote: >>>> On 19.11.2013 19:55, David Holmes wrote: >>>>> On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote: >>>>>> Hi David, >>>>>> >>>>>> On 18.11.2013 22:03, David Holmes wrote: >>>>>>> Hi Jaroslav, >>>>>>> >>>>>>> I think your phaser usage is incorrect: >>>>>>> >>>>>>> 88 public void run() { >>>>>>> 89 p.arriveAndAwaitAdvance(); // phase[1] >>>>>>> 90 synchronized(lock1) { >>>>>>> 91 System.out.println("[LockerThread obtained >>>>>>> Lock1]"); >>>>>>> 92 p.arrive(); // phase[2] >>>>>>> 93 } >>>>>>> 94 p.arriveAndAwaitAdvance(); // phase[3] >>>>>>> 95 } >>>>>>> >>>>>>> Here the current thread can release itself at line 94. You have >>>>>>> assumed >>>>>>> that the phase[2] arrive will be a trigger to release the main >>>>>>> thread >>>>>>> but it may not have reached its arriveAndAwaitAdvance phase[2] >>>>>>> statement >>>>>>> yet, so the current thread arrives then does arrive-and-wait but the >>>>>>> number of arrivals is 2 so it doesn't wait. >>>>>>> >>>>>>> A CyclicBarrier per phase may be clearer. >>>>>> >>>>>> Yes, thanks for pointing this out. But, wouldn't >>>>>> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've >>>>>> tried to >>>>>> replace Phaser with CyclicBarrier but while it seems to work as >>>>>> expected >>>>>> it pollutes code with the necessity to catch various exceptions >>>>>> (InterruptedException, BarrierException etc.). So, if the simple fix >>>>>> with Phaser would do the trick I would better use that. >>>>> >>>>> In this case yes arriveAndAwaitAdvance would fix it. I don't know if >>>>> other tests have the same issue - the concern would be ensuring >>>>> there's >>>>> no possibility of deadlocks in general. >>>> >>>> I've updated the webrev with the one using p.arriveAndAwaitAdvance() at >>>> line 92 - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.04 >>>> >>>> Are you ok with this change then? >>> >>> I think you have the same problem anywhere that arrive() is used eg: >>> >>> 129 p.arrive(); // phase[2] >>> 130 p.arriveAndAwaitAdvance(); // phase[3] >>> >>> and >>> >>> 185 p.arrive(); // phase[2] >>> 186 } >>> 187 p.arriveAndAwaitAdvance(); // phase[3] >> >> Very probable :( Also, when analysing the recurrence of JDK-8029890 I've >> found out that Phaser.arriveAndAwaitAdvance() actually blocked the >> thread in a way that it increased the number of contentions reported :( >> CyclicBarrier seems to wait instead - I will have to use CyclicBarrier >> when testing the number of reported contentions and Phaser when testing >> the number of reported waits :/ >> >> -JB- >> >>> >>> David >>> ------ >>> >>>> Thanks, >>>> >>>> -JB- >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> after discussing this with Mandy I've rewritten the test to use the >>>>>>>> j.u.concurrent for synchronization - this also makes it much >>>>>>>> easier to >>>>>>>> follow the test logic. >>>>>>>> >>>>>>>> The waited time, the blocked time and the waited counts are only >>>>>>>> checked >>>>>>>> for sanity (increasing values) since it is not possible to do the >>>>>>>> reliable checks against hard numbers. >>>>>>>> >>>>>>>> I ran the test in a tight loop for 1500 times using -Xcomp and >>>>>>>> -Xint >>>>>>>> and >>>>>>>> the test seems to pass constantly. >>>>>>>> >>>>>>>> New webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>> >>>>>>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote: >>>>>>>>> Please, review this small patch for a test failing due to the >>>>>>>>> updated >>>>>>>>> implementation in JDK6. >>>>>>>>> >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>>>>>>> >>>>>>>>> The test fails due to the change in mustang where >>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include >>>>>>>>> Thread.sleep() >>>>>>>>> too. Unfortunately, Thread.sleep() is used throughout the test for >>>>>>>>> synchronization purposes and this breaks the test. >>>>>>>>> >>>>>>>>> In the patch I propose to replace Thread.sleep() with busy wait >>>>>>>>> and >>>>>>>>> hinting the scheduler by Thread.yield(). While not very elegant it >>>>>>>>> successfully works around inclusion of unknown number of >>>>>>>>> Thread.sleep()s >>>>>>>>> (they are called in loop). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>>>>>>> >>>>>> >>>> >> > From david.holmes at oracle.com Tue Jan 21 22:39:15 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2014 16:39:15 +1000 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <52DE7D7C.8090007@oracle.com> References: <52DE7AF0.1030901@oracle.com> <52DE7D7C.8090007@oracle.com> Message-ID: <52DF6793.1070903@oracle.com> On 22/01/2014 12:00 AM, Dmitry Samersoff wrote: > Missed CR in subject. Sorry! > > http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ You already create the file with mkFiles so no need to echo something into it, a simple cat will suffice to see if it is unreadable. Not sure why this was being run as root though - can't be normal else we'd have seen this before. There are other tests that fail when run as root due to still being able to read/write unreadable/unwriteable files. BTW the indention in that test case is messed up (in the original). David > > On 2014-01-21 17:49, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Please review. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >> >> I can't reproduce the issue locally, but suspect, the test failed >> because after chmod a-r the file is sill readable. So check it >> explicitly before run the test itself. >> > > From jaroslav.bachorik at oracle.com Wed Jan 22 00:12:06 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 22 Jan 2014 09:12:06 +0100 Subject: RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52DF646B.3000606@oracle.com> References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com> <528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com> <528BB41A.4070107@oracle.com> <52A5AD7B.1060403@oracle.com> <52B3AB16.30206@oracle.com> <52B3FEBE.40106@oracle.com> <52DE72A8.9050807@oracle.com> <52DF646B.3000606@oracle.com> Message-ID: Argh. Sorry. Probably messed up when restoring my crashed HDD. I will go through the patch to see if there are any other omissions. Thanks, -JB- David Holmes wrote: >Hi Jaroslav, > >I still see some suspect uses of p.arrive() instead of >p.arriveAndAwaitAdvance(). > >David > >On 21/01/2014 11:14 PM, Jaroslav Bachorik wrote: >> Based on the experience while fixing >> https://bugs.openjdk.java.net/browse/JDK-8032377 I've updated the >patch >> not to require an exact number for the blocked count - it will pass >> whenever the reported blocked count is at least large as the the >> expected number. >> >> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.06 >> >> Thanks, >> >> -JB- >> >> On 20.12.2013 09:24, Jaroslav Bachorik wrote: >>> On 20.12.2013 03:27, David Holmes wrote: >>>> Sorry for the delay - still catching up after vacation (only 435 >openjdk >>>> emails left :( ). >>> >>> NP >>> >>>> >>>> On 9/12/2013 9:46 PM, Jaroslav Bachorik wrote: >>>>> On 19.11.2013 19:55, David Holmes wrote: >>>>>> On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 18.11.2013 22:03, David Holmes wrote: >>>>>>>> Hi Jaroslav, >>>>>>>> >>>>>>>> I think your phaser usage is incorrect: >>>>>>>> >>>>>>>> 88 public void run() { >>>>>>>> 89 p.arriveAndAwaitAdvance(); // phase[1] >>>>>>>> 90 synchronized(lock1) { >>>>>>>> 91 System.out.println("[LockerThread >obtained >>>>>>>> Lock1]"); >>>>>>>> 92 p.arrive(); // phase[2] >>>>>>>> 93 } >>>>>>>> 94 p.arriveAndAwaitAdvance(); // phase[3] >>>>>>>> 95 } >>>>>>>> >>>>>>>> Here the current thread can release itself at line 94. You have >>>>>>>> assumed >>>>>>>> that the phase[2] arrive will be a trigger to release the main >>>>>>>> thread >>>>>>>> but it may not have reached its arriveAndAwaitAdvance phase[2] >>>>>>>> statement >>>>>>>> yet, so the current thread arrives then does arrive-and-wait >but the >>>>>>>> number of arrivals is 2 so it doesn't wait. >>>>>>>> >>>>>>>> A CyclicBarrier per phase may be clearer. >>>>>>> >>>>>>> Yes, thanks for pointing this out. But, wouldn't >>>>>>> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've >>>>>>> tried to >>>>>>> replace Phaser with CyclicBarrier but while it seems to work as >>>>>>> expected >>>>>>> it pollutes code with the necessity to catch various exceptions >>>>>>> (InterruptedException, BarrierException etc.). So, if the simple >fix >>>>>>> with Phaser would do the trick I would better use that. >>>>>> >>>>>> In this case yes arriveAndAwaitAdvance would fix it. I don't know >if >>>>>> other tests have the same issue - the concern would be ensuring >>>>>> there's >>>>>> no possibility of deadlocks in general. >>>>> >>>>> I've updated the webrev with the one using >p.arriveAndAwaitAdvance() at >>>>> line 92 - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.04 >>>>> >>>>> Are you ok with this change then? >>>> >>>> I think you have the same problem anywhere that arrive() is used >eg: >>>> >>>> 129 p.arrive(); // phase[2] >>>> 130 p.arriveAndAwaitAdvance(); // phase[3] >>>> >>>> and >>>> >>>> 185 p.arrive(); // phase[2] >>>> 186 } >>>> 187 p.arriveAndAwaitAdvance(); // phase[3] >>> >>> Very probable :( Also, when analysing the recurrence of JDK-8029890 >I've >>> found out that Phaser.arriveAndAwaitAdvance() actually blocked the >>> thread in a way that it increased the number of contentions reported >:( >>> CyclicBarrier seems to wait instead - I will have to use >CyclicBarrier >>> when testing the number of reported contentions and Phaser when >testing >>> the number of reported waits :/ >>> >>> -JB- >>> >>>> >>>> David >>>> ------ >>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> after discussing this with Mandy I've rewritten the test to >use the >>>>>>>>> j.u.concurrent for synchronization - this also makes it much >>>>>>>>> easier to >>>>>>>>> follow the test logic. >>>>>>>>> >>>>>>>>> The waited time, the blocked time and the waited counts are >only >>>>>>>>> checked >>>>>>>>> for sanity (increasing values) since it is not possible to do >the >>>>>>>>> reliable checks against hard numbers. >>>>>>>>> >>>>>>>>> I ran the test in a tight loop for 1500 times using -Xcomp and >>>>>>>>> -Xint >>>>>>>>> and >>>>>>>>> the test seems to pass constantly. >>>>>>>>> >>>>>>>>> New webrev: >http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>> >>>>>>>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote: >>>>>>>>>> Please, review this small patch for a test failing due to the >>>>>>>>>> updated >>>>>>>>>> implementation in JDK6. >>>>>>>>>> >>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>>>>>>>> Webrev: >http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>>>>>>>> >>>>>>>>>> The test fails due to the change in mustang where >>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include >>>>>>>>>> Thread.sleep() >>>>>>>>>> too. Unfortunately, Thread.sleep() is used throughout the >test for >>>>>>>>>> synchronization purposes and this breaks the test. >>>>>>>>>> >>>>>>>>>> In the patch I propose to replace Thread.sleep() with busy >wait >>>>>>>>>> and >>>>>>>>>> hinting the scheduler by Thread.yield(). While not very >elegant it >>>>>>>>>> successfully works around inclusion of unknown number of >>>>>>>>>> Thread.sleep()s >>>>>>>>>> (they are called in loop). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>> >>>>>>> >>>>> >>> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140122/4bf68bbd/attachment-0001.html From staffan.larsen at oracle.com Wed Jan 22 00:40:19 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Jan 2014 09:40:19 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52DEEB5F.6020306@oracle.com> References: <52DEEB5F.6020306@oracle.com> Message-ID: <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> Jesper, This looks ok from a serviceability perspective. Long term we should probably have a more pluggable way to verify values of manageable flags so we can avoid some of the duplication. I have a slight problem with is_within() and is_min() in that it is not obvious from the call site if the min and max values are inclusive or not - it was very obvious before. /Staffan On 21 jan 2014, at 22:49, Jesper Wilhelmsson wrote: > Hi, > > Could I have a few reviews of this change? > > Summary: > To allow applications a more fine grained control over the GC over time, we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. > > The initial request that lead up to this change involved ParallelGC which is notoriously unwilling to shrink the heap. Since ParallelGC didn't support the heap free ratio flags, this change also includes implementing support for these flags in ParallelGC. > > Changes have also been made to the argument parsing, attach listener and the management API to verify the flag values when set through the different interfaces. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 > > The plan is to push this to 9 and then backport to 8 and 7. > > Thanks! > /Jesper From staffan.larsen at oracle.com Wed Jan 22 00:48:32 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Jan 2014 09:48:32 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52DEEB5F.6020306@oracle.com> References: <52DEEB5F.6020306@oracle.com> Message-ID: Jesper, This looks ok from a serviceability perspective. Long term we should probably have a more pluggable way to verify values of manageable flags so we can avoid some of the duplication. I have a slight problem with is_within() and is_min() in that it is not obvious from the call site if the min and max values are inclusive or not - it was very o On 21 jan 2014, at 22:49, Jesper Wilhelmsson wrote: > Hi, > > Could I have a few reviews of this change? > > Summary: > To allow applications a more fine grained control over the GC over time, we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. > > The initial request that lead up to this change involved ParallelGC which is notoriously unwilling to shrink the heap. Since ParallelGC didn't support the heap free ratio flags, this change also includes implementing support for these flags in ParallelGC. > > Changes have also been made to the argument parsing, attach listener and the management API to verify the flag values when set through the different interfaces. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 > > The plan is to push this to 9 and then backport to 8 and 7. > > Thanks! > /Jesper From dmitry.samersoff at oracle.com Wed Jan 22 01:57:30 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Jan 2014 13:57:30 +0400 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <52DF6793.1070903@oracle.com> References: <52DE7AF0.1030901@oracle.com> <52DE7D7C.8090007@oracle.com> <52DF6793.1070903@oracle.com> Message-ID: <52DF960A.1090001@oracle.com> On 2014-01-22 10:39, David Holmes wrote: > On 22/01/2014 12:00 AM, Dmitry Samersoff wrote: >> Missed CR in subject. Sorry! >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ > > You already create the file with mkFiles so no need to echo something > into it, a simple cat will suffice to see if it is unreadable. Exit code of cat is not specified. So cat is enough to just warn user, but we have to use grep to branch. Grep should return 2 in case of permission denied, but it's not stable across implementations - grep can return 0 if patter is found and 1 in all other cases. So I just choose the most reliable solution. > Not sure why this was being run as root though - can't be normal else > we'd have seen this before. There are other tests that fail when run as > root due to still being able to read/write unreadable/unwriteable files. I plan to file infrastructure bug to clarify it. Tests shouldn't run as root in any case. -Dmitry > > BTW the indention in that test case is messed up (in the original). > > David > >> >> On 2014-01-21 17:49, Dmitry Samersoff wrote: >>> Hi Everyone, >>> >>> Please review. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>> >>> I can't reproduce the issue locally, but suspect, the test failed >>> because after chmod a-r the file is sill readable. So check it >>> explicitly before run the test itself. >>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From bengt.rutisson at oracle.com Wed Jan 22 02:21:10 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 22 Jan 2014 11:21:10 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> Message-ID: <52DF9B96.8050901@oracle.com> Hi Jesper, The calculation in PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() looks wrong to me. I would have expected this: 86 // free = (live*ratio) / (1-ratio) 87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() * mhfr_as_percent) / (1.0 - mhfr_as_percent)); to be something like this: size_t max_free = heap->old_gen()->capacity_in_bytes() * mhfr_as_percent; (A minor naming thing is that mhfr_as_percent is actually not a percent but a ratio or fraction. Just like you write in the comment.) We also don't seem to take MinHeapFreeRatio into account. Should we do that? I think it should be possible to write a internal VM test or a whitebox test for the calculated_old_free_size_in_bytes() to verify that it produces the correct results. Speaking of testing. There is already a test called test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass with the ParallelGC already before your changes. I think that means that the test is not strict enough. Could you update that test or add a new test to make sure that your changes are tested? I also agree with Staffan that the methods is_within() and is_min() make it harder to read the code. Thanks, Bengt On 2014-01-22 09:40, Staffan Larsen wrote: > Jesper, > > This looks ok from a serviceability perspective. Long term we should probably have a more pluggable way to verify values of manageable flags so we can avoid some of the duplication. > > I have a slight problem with is_within() and is_min() in that it is not obvious from the call site if the min and max values are inclusive or not - it was very obvious before. > > /Staffan > > > On 21 jan 2014, at 22:49, Jesper Wilhelmsson wrote: > >> Hi, >> >> Could I have a few reviews of this change? >> >> Summary: >> To allow applications a more fine grained control over the GC over time, we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. >> >> The initial request that lead up to this change involved ParallelGC which is notoriously unwilling to shrink the heap. Since ParallelGC didn't support the heap free ratio flags, this change also includes implementing support for these flags in ParallelGC. >> >> Changes have also been made to the argument parsing, attach listener and the management API to verify the flag values when set through the different interfaces. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >> >> The plan is to push this to 9 and then backport to 8 and 7. >> >> Thanks! >> /Jesper From david.holmes at oracle.com Wed Jan 22 02:38:55 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2014 20:38:55 +1000 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <52DF960A.1090001@oracle.com> References: <52DE7AF0.1030901@oracle.com> <52DE7D7C.8090007@oracle.com> <52DF6793.1070903@oracle.com> <52DF960A.1090001@oracle.com> Message-ID: <52DF9FBF.90408@oracle.com> On 22/01/2014 7:57 PM, Dmitry Samersoff wrote: > On 2014-01-22 10:39, David Holmes wrote: >> On 22/01/2014 12:00 AM, Dmitry Samersoff wrote: >>> Missed CR in subject. Sorry! >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >> >> You already create the file with mkFiles so no need to echo something >> into it, a simple cat will suffice to see if it is unreadable. > > Exit code of cat is not specified. So cat is enough to just warn user, > but we have to use grep to branch. > > Grep should return 2 in case of permission denied, but it's not stable > across implementations - grep can return 0 if patter is found and 1 in > all other cases. > > So I just choose the most reliable solution. So grep is commonly better than cat but still not guaranteed - okay. But can't you simply grep the empty file to get the same result? No big deal. David >> Not sure why this was being run as root though - can't be normal else >> we'd have seen this before. There are other tests that fail when run as >> root due to still being able to read/write unreadable/unwriteable files. > > I plan to file infrastructure bug to clarify it. Tests shouldn't run as > root in any case. > > -Dmitry > >> >> BTW the indention in that test case is messed up (in the original). >> >> David >> >>> >>> On 2014-01-21 17:49, Dmitry Samersoff wrote: >>>> Hi Everyone, >>>> >>>> Please review. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>>> >>>> I can't reproduce the issue locally, but suspect, the test failed >>>> because after chmod a-r the file is sill readable. So check it >>>> explicitly before run the test itself. >>>> >>> >>> > > From erik.joelsson at oracle.com Wed Jan 22 03:13:55 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 22 Jan 2014 11:13:55 +0000 Subject: hg: jdk8/tl/jdk: 8032217: failure in man page processing Message-ID: <20140122111510.5171762655@hg.openjdk.java.net> Changeset: ff56039c4870 Author: erikj Date: 2014-01-22 12:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff56039c4870 8032217: failure in man page processing Reviewed-by: dholmes, tbell ! make/Images.gmk From staffan.larsen at oracle.com Wed Jan 22 03:44:01 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Jan 2014 12:44:01 +0100 Subject: RFR(XS) 6545321: jstatLineCounts4.sh has to be resilient to unexpected output In-Reply-To: References: Message-ID: <8E47A1AC-BE95-4838-ACEC-9793FFEF7F1C@oracle.com> Looks good! I can sponsor this. Thanks, /Staffan On 21 jan 2014, at 13:32, Mattias Tobiasson wrote: > Hi, > Could you please review this test fix. The current test is unstable and fails intermittently. > > The test parses output from jstat. > It verifies number of header lines, data lines and total lines. > The test sometimes fails because there are unexpected debug output from the jvm, which means that total line count does not match. > > The fix is to ignore total line count, and only verify header lines and data lines. > There are multiple tests with the same problem. All have been fixed, even if the bug only mentions one test. > > bug: > https://bugs.openjdk.java.net/browse/JDK-6545321 > > webrev: > http://cr.openjdk.java.net/~ykantser/6545321/webrev.00/ > > Mattias From dmitry.samersoff at oracle.com Wed Jan 22 03:59:07 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Jan 2014 15:59:07 +0400 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <52DF9FBF.90408@oracle.com> References: <52DE7AF0.1030901@oracle.com> <52DE7D7C.8090007@oracle.com> <52DF6793.1070903@oracle.com> <52DF960A.1090001@oracle.com> <52DF9FBF.90408@oracle.com> Message-ID: <52DFB28B.5060707@oracle.com> On 2014-01-22 14:38, David Holmes wrote: > On 22/01/2014 7:57 PM, Dmitry Samersoff wrote: >> On 2014-01-22 10:39, David Holmes wrote: >>> On 22/01/2014 12:00 AM, Dmitry Samersoff wrote: >>>> Missed CR in subject. Sorry! >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>> >>> You already create the file with mkFiles so no need to echo something >>> into it, a simple cat will suffice to see if it is unreadable. >> >> Exit code of cat is not specified. So cat is enough to just warn user, >> but we have to use grep to branch. >> >> Grep should return 2 in case of permission denied, but it's not stable >> across implementations - grep can return 0 if patter is found and 1 in >> all other cases. >> >> So I just choose the most reliable solution. > > So grep is commonly better than cat but still not guaranteed - okay. But > can't you simply grep the empty file to get the same result? If I would grep the empty file I expect the exit code: 1 - pattern not found 2 - file not readable It usually works, but some of grep implementations return either 0 (pattern found) or 1 (in all other cases) -Dmitry > > No big deal. > > David > >>> Not sure why this was being run as root though - can't be normal else >>> we'd have seen this before. There are other tests that fail when run as >>> root due to still being able to read/write unreadable/unwriteable files. >> >> I plan to file infrastructure bug to clarify it. Tests shouldn't run as >> root in any case. >> >> -Dmitry >> >>> >>> BTW the indention in that test case is messed up (in the original). >>> >>> David >>> >>>> >>>> On 2014-01-21 17:49, Dmitry Samersoff wrote: >>>>> Hi Everyone, >>>>> >>>>> Please review. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>>>> >>>>> I can't reproduce the issue locally, but suspect, the test failed >>>>> because after chmod a-r the file is sill readable. So check it >>>>> explicitly before run the test itself. >>>>> >>>> >>>> >> >> -- 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 Jan 22 04:49:32 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Jan 2014 16:49:32 +0400 Subject: RFR(XS) 6545321: jstatLineCounts4.sh has to be resilient to unexpected output In-Reply-To: References: Message-ID: <52DFBE5C.5070701@oracle.com> Mattias, We don't use totallines anymore so need not to increment it: { totallines++; print $0 } otherwise looks good. -Dmitry On 2014-01-21 16:32, Mattias Tobiasson wrote: > Hi, > Could you please review this test fix. The current test is unstable and fails intermittently. > > The test parses output from jstat. > It verifies number of header lines, data lines and total lines. > The test sometimes fails because there are unexpected debug output from the jvm, which means that total line count does not match. > > The fix is to ignore total line count, and only verify header lines and data lines. > There are multiple tests with the same problem. All have been fixed, even if the bug only mentions one test. > > bug: > https://bugs.openjdk.java.net/browse/JDK-6545321 > > webrev: > http://cr.openjdk.java.net/~ykantser/6545321/webrev.00/ > > Mattias > -- 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 jaroslav.bachorik at oracle.com Wed Jan 22 05:07:30 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 22 Jan 2014 14:07:30 +0100 Subject: RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com> <528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com> <528BB41A.4070107@oracle.com> <52A5AD7B.1060403@oracle.com> <52B3AB16.30206@oracle.com> <52B3FEBE.40106@oracle.com> <52DE72A8.9050807@oracle.com> <52DF646B.3000606@oracle.com> Message-ID: <52DFC292.8040401@oracle.com> Updated webrev with no "arrive()" calls dangling. - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.07 -JB- On 22.1.2014 09:12, Jaroslav Bachorik wrote: > Argh. Sorry. Probably messed up when restoring my crashed HDD. I will go through the patch to see if there are any other omissions. > > Thanks, > -JB- > > David Holmes wrote: >> Hi Jaroslav, >> >> I still see some suspect uses of p.arrive() instead of >> p.arriveAndAwaitAdvance(). >> >> David >> >> On 21/01/2014 11:14 PM, Jaroslav Bachorik wrote: >>> Based on the experience while fixing >>> https://bugs.openjdk.java.net/browse/JDK-8032377 I've updated the >> patch >>> not to require an exact number for the blocked count - it will pass >>> whenever the reported blocked count is at least large as the the >>> expected number. >>> >>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.06 >>> >>> Thanks, >>> >>> -JB- >>> >>> On 20.12.2013 09:24, Jaroslav Bachorik wrote: >>>> On 20.12.2013 03:27, David Holmes wrote: >>>>> Sorry for the delay - still catching up after vacation (only 435 >> openjdk >>>>> emails left :( ). >>>> >>>> NP >>>> >>>>> >>>>> On 9/12/2013 9:46 PM, Jaroslav Bachorik wrote: >>>>>> On 19.11.2013 19:55, David Holmes wrote: >>>>>>> On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 18.11.2013 22:03, David Holmes wrote: >>>>>>>>> Hi Jaroslav, >>>>>>>>> >>>>>>>>> I think your phaser usage is incorrect: >>>>>>>>> >>>>>>>>> 88 public void run() { >>>>>>>>> 89 p.arriveAndAwaitAdvance(); // phase[1] >>>>>>>>> 90 synchronized(lock1) { >>>>>>>>> 91 System.out.println("[LockerThread >> obtained >>>>>>>>> Lock1]"); >>>>>>>>> 92 p.arrive(); // phase[2] >>>>>>>>> 93 } >>>>>>>>> 94 p.arriveAndAwaitAdvance(); // phase[3] >>>>>>>>> 95 } >>>>>>>>> >>>>>>>>> Here the current thread can release itself at line 94. You have >>>>>>>>> assumed >>>>>>>>> that the phase[2] arrive will be a trigger to release the main >>>>>>>>> thread >>>>>>>>> but it may not have reached its arriveAndAwaitAdvance phase[2] >>>>>>>>> statement >>>>>>>>> yet, so the current thread arrives then does arrive-and-wait >> but the >>>>>>>>> number of arrivals is 2 so it doesn't wait. >>>>>>>>> >>>>>>>>> A CyclicBarrier per phase may be clearer. >>>>>>>> >>>>>>>> Yes, thanks for pointing this out. But, wouldn't >>>>>>>> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've >>>>>>>> tried to >>>>>>>> replace Phaser with CyclicBarrier but while it seems to work as >>>>>>>> expected >>>>>>>> it pollutes code with the necessity to catch various exceptions >>>>>>>> (InterruptedException, BarrierException etc.). So, if the simple >> fix >>>>>>>> with Phaser would do the trick I would better use that. >>>>>>> >>>>>>> In this case yes arriveAndAwaitAdvance would fix it. I don't know >> if >>>>>>> other tests have the same issue - the concern would be ensuring >>>>>>> there's >>>>>>> no possibility of deadlocks in general. >>>>>> >>>>>> I've updated the webrev with the one using >> p.arriveAndAwaitAdvance() at >>>>>> line 92 - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.04 >>>>>> >>>>>> Are you ok with this change then? >>>>> >>>>> I think you have the same problem anywhere that arrive() is used >> eg: >>>>> >>>>> 129 p.arrive(); // phase[2] >>>>> 130 p.arriveAndAwaitAdvance(); // phase[3] >>>>> >>>>> and >>>>> >>>>> 185 p.arrive(); // phase[2] >>>>> 186 } >>>>> 187 p.arriveAndAwaitAdvance(); // phase[3] >>>> >>>> Very probable :( Also, when analysing the recurrence of JDK-8029890 >> I've >>>> found out that Phaser.arriveAndAwaitAdvance() actually blocked the >>>> thread in a way that it increased the number of contentions reported >> :( >>>> CyclicBarrier seems to wait instead - I will have to use >> CyclicBarrier >>>> when testing the number of reported contentions and Phaser when >> testing >>>> the number of reported waits :/ >>>> >>>> -JB- >>>> >>>>> >>>>> David >>>>> ------ >>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> after discussing this with Mandy I've rewritten the test to >> use the >>>>>>>>>> j.u.concurrent for synchronization - this also makes it much >>>>>>>>>> easier to >>>>>>>>>> follow the test logic. >>>>>>>>>> >>>>>>>>>> The waited time, the blocked time and the waited counts are >> only >>>>>>>>>> checked >>>>>>>>>> for sanity (increasing values) since it is not possible to do >> the >>>>>>>>>> reliable checks against hard numbers. >>>>>>>>>> >>>>>>>>>> I ran the test in a tight loop for 1500 times using -Xcomp and >>>>>>>>>> -Xint >>>>>>>>>> and >>>>>>>>>> the test seems to pass constantly. >>>>>>>>>> >>>>>>>>>> New webrev: >> http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote: >>>>>>>>>>> Please, review this small patch for a test failing due to the >>>>>>>>>>> updated >>>>>>>>>>> implementation in JDK6. >>>>>>>>>>> >>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>>>>>>>>> Webrev: >> http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The test fails due to the change in mustang where >>>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include >>>>>>>>>>> Thread.sleep() >>>>>>>>>>> too. Unfortunately, Thread.sleep() is used throughout the >> test for >>>>>>>>>>> synchronization purposes and this breaks the test. >>>>>>>>>>> >>>>>>>>>>> In the patch I propose to replace Thread.sleep() with busy >> wait >>>>>>>>>>> and >>>>>>>>>>> hinting the scheduler by Thread.yield(). While not very >> elegant it >>>>>>>>>>> successfully works around inclusion of unknown number of >>>>>>>>>>> Thread.sleep()s >>>>>>>>>>> (they are called in loop). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From dmitry.samersoff at oracle.com Wed Jan 22 05:18:47 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Jan 2014 17:18:47 +0400 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <0D2DDFBC-BA46-42B5-8A86-E7DE2710488F@oracle.com> References: <52DE7AF0.1030901@oracle.com> <52DE7D7C.8090007@oracle.com> <0D2DDFBC-BA46-42B5-8A86-E7DE2710488F@oracle.com> Message-ID: <52DFC537.6080504@oracle.com> Staffan, http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.02/ Updated webrev - test will continue fail but with meaningful diagnostic. -Dmitry On 2014-01-21 18:49, Staffan Larsen wrote: > Should we really be skipping the test if this fail? Isn?t it an infrastructure bug if we can?t make the file unreadable? I think the test should fail, but say why it failed: ?could not make $HOME/jdb.ini unreadable? and perhaps include the current permissions on the file and directory for debugging purposes. > > /Staffan > > On 21 jan 2014, at 15:00, Dmitry Samersoff wrote: > >> Missed CR in subject. Sorry! >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >> >> >> On 2014-01-21 17:49, Dmitry Samersoff wrote: >>> Hi Everyone, >>> >>> Please review. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>> >>> I can't reproduce the issue locally, but suspect, the test failed >>> because after chmod a-r the file is sill readable. So check it >>> explicitly before run the test itself. >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- 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 Jan 22 05:27:41 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 22 Jan 2014 14:27:41 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 Message-ID: <52DFC74D.5040303@oracle.com> Hi, The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9. We can have several solutions, like to use: Runtime.getRuntime().maxMemory() Runtime.getRuntime().totalMemory; MemoryUsage.getCommitted() or hard-code chunkSize to be 1M. I found that the test ran much faster with: chunkSize = Runtime.getRuntime().freeMemory()/10; than: chunkSize = 1M; webrev: http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ bug: https://bugs.openjdk.java.net/browse/JDK-6980984 Thanks, Shanliang From staffan.larsen at oracle.com Wed Jan 22 05:30:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Jan 2014 14:30:42 +0100 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <52DFC537.6080504@oracle.com> References: <52DE7AF0.1030901@oracle.com> <52DE7D7C.8090007@oracle.com> <0D2DDFBC-BA46-42B5-8A86-E7DE2710488F@oracle.com> <52DFC537.6080504@oracle.com> Message-ID: <7D8B0DC9-303F-47BE-A262-1359A5B5416C@oracle.com> Looks good! Should we perhaps add the output of ?ls -l $HOME/jdb.ini? when it fails? Thanks, /Staffan On 22 jan 2014, at 14:18, Dmitry Samersoff wrote: > Staffan, > > http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.02/ > > Updated webrev - test will continue fail but with meaningful diagnostic. > > -Dmitry > > On 2014-01-21 18:49, Staffan Larsen wrote: >> Should we really be skipping the test if this fail? Isn?t it an infrastructure bug if we can?t make the file unreadable? I think the test should fail, but say why it failed: ?could not make $HOME/jdb.ini unreadable? and perhaps include the current permissions on the file and directory for debugging purposes. >> >> /Staffan >> >> On 21 jan 2014, at 15:00, Dmitry Samersoff wrote: >> >>> Missed CR in subject. Sorry! >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>> >>> >>> On 2014-01-21 17:49, Dmitry Samersoff wrote: >>>> Hi Everyone, >>>> >>>> Please review. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>>> >>>> I can't reproduce the issue locally, but suspect, the test failed >>>> because after chmod a-r the file is sill readable. So check it >>>> explicitly before run the test itself. >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > > > -- > 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 Jan 22 05:49:49 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Jan 2014 17:49:49 +0400 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <7D8B0DC9-303F-47BE-A262-1359A5B5416C@oracle.com> References: <52DE7AF0.1030901@oracle.com> <52DE7D7C.8090007@oracle.com> <0D2DDFBC-BA46-42B5-8A86-E7DE2710488F@oracle.com> <52DFC537.6080504@oracle.com> <7D8B0DC9-303F-47BE-A262-1359A5B5416C@oracle.com> Message-ID: <52DFCC7D.1080301@oracle.com> Staffan, On 2014-01-22 17:30, Staffan Larsen wrote: > Looks good! > > Should we perhaps add the output of ?ls -l $HOME/jdb.ini? when it fails? I would prefer not to load test with diagnostic code (actually, check for root is also redundant). There are plenty of reason for file to being readable and we can't check it all without significant efforts. -Dmitry > > Thanks, > /Staffan > > > On 22 jan 2014, at 14:18, Dmitry Samersoff wrote: > >> Staffan, >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.02/ >> >> Updated webrev - test will continue fail but with meaningful diagnostic. >> >> -Dmitry >> >> On 2014-01-21 18:49, Staffan Larsen wrote: >>> Should we really be skipping the test if this fail? Isn?t it an infrastructure bug if we can?t make the file unreadable? I think the test should fail, but say why it failed: ?could not make $HOME/jdb.ini unreadable? and perhaps include the current permissions on the file and directory for debugging purposes. >>> >>> /Staffan >>> >>> On 21 jan 2014, at 15:00, Dmitry Samersoff wrote: >>> >>>> Missed CR in subject. Sorry! >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>>> >>>> >>>> On 2014-01-21 17:49, Dmitry Samersoff wrote: >>>>> Hi Everyone, >>>>> >>>>> Please review. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>>>> >>>>> I can't reproduce the issue locally, but suspect, the test failed >>>>> because after chmod a-r the file is sill readable. So check it >>>>> explicitly before run the test itself. >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- 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 staffan.larsen at oracle.com Wed Jan 22 05:54:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Jan 2014 14:54:42 +0100 Subject: RR(XS): JDK-8002116 This JdbReadTwiceTest.sh gets an exit 1 In-Reply-To: <52DFCC7D.1080301@oracle.com> References: <52DE7AF0.1030901@oracle.com> <52DE7D7C.8090007@oracle.com> <0D2DDFBC-BA46-42B5-8A86-E7DE2710488F@oracle.com> <52DFC537.6080504@oracle.com> <7D8B0DC9-303F-47BE-A262-1359A5B5416C@oracle.com> <52DFCC7D.1080301@oracle.com> Message-ID: Ok. /Staffan On 22 jan 2014, at 14:49, Dmitry Samersoff wrote: > Staffan, > > On 2014-01-22 17:30, Staffan Larsen wrote: >> Looks good! >> >> Should we perhaps add the output of ?ls -l $HOME/jdb.ini? when it fails? > > I would prefer not to load test with diagnostic code (actually, check > for root is also redundant). > > There are plenty of reason for file to being readable and we can't check > it all without significant efforts. > > -Dmitry > >> >> Thanks, >> /Staffan >> >> >> On 22 jan 2014, at 14:18, Dmitry Samersoff wrote: >> >>> Staffan, >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.02/ >>> >>> Updated webrev - test will continue fail but with meaningful diagnostic. >>> >>> -Dmitry >>> >>> On 2014-01-21 18:49, Staffan Larsen wrote: >>>> Should we really be skipping the test if this fail? Isn?t it an infrastructure bug if we can?t make the file unreadable? I think the test should fail, but say why it failed: ?could not make $HOME/jdb.ini unreadable? and perhaps include the current permissions on the file and directory for debugging purposes. >>>> >>>> /Staffan >>>> >>>> On 21 jan 2014, at 15:00, Dmitry Samersoff wrote: >>>> >>>>> Missed CR in subject. Sorry! >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>>>> >>>>> >>>>> On 2014-01-21 17:49, Dmitry Samersoff wrote: >>>>>> Hi Everyone, >>>>>> >>>>>> Please review. >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/ >>>>>> >>>>>> I can't reproduce the issue locally, but suspect, the test failed >>>>>> because after chmod a-r the file is sill readable. So check it >>>>>> explicitly before run the test itself. >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Oracle Java development team, Saint Petersburg, Russia >>>>> * I would love to change the world, but they won't give me the sources. >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140122/36a54a4b/attachment.html From staffan.larsen at oracle.com Wed Jan 22 06:08:56 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Jan 2014 15:08:56 +0100 Subject: RFR(S): JDK-8032250 : Add trace event for VM flag changes In-Reply-To: <4213C88C-3617-466C-909B-F8DAA37C8015@oracle.com> References: <4213C88C-3617-466C-909B-F8DAA37C8015@oracle.com> Message-ID: Erik Helin suggested using template functions instead of macros which makes the code a little more type safe. Also added a missing #include in globals.cpp. Here is a new version of the webrev: http://cr.openjdk.java.net/~sla/8032250/webrev.01/ Thanks, /Staffan On 21 jan 2014, at 14:47, Staffan Larsen wrote: > This is a patch to capture a trace event whenever a manageable VM flag is changed in runtime. > > webrev: http://cr.openjdk.java.net/~sla/8032250/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8032250 > > Thanks, > /Staffan From jaroslav.bachorik at oracle.com Wed Jan 22 06:14:43 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 22 Jan 2014 15:14:43 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 In-Reply-To: <52DFC74D.5040303@oracle.com> References: <52DFC74D.5040303@oracle.com> Message-ID: <52DFD253.20107@oracle.com> Hi Shanliang, On 22.1.2014 14:27, shanliang wrote: > Hi, > > The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9. > > We can have several solutions, like to use: > Runtime.getRuntime().maxMemory() > Runtime.getRuntime().totalMemory; > > MemoryUsage.getCommitted() You were also mentioning passing -XMaxHeapSize argument to force G1 to put restriction on the max heap size in the issue. Does it work? > > or hard-code chunkSize to be 1M. > > I found that the test ran much faster with: > chunkSize = Runtime.getRuntime().freeMemory()/10; > than: > chunkSize = 1M; That's odd - unless "Runtime.getRuntime().freeMemory()/10" gives you a chunk much smaller than 1M. BTW, why do you divide the amount of free memory by 10? The "mu.getMax()" based calculation is using 20. Wouldn't this give you a bigger chunk when calculating it from "freeMemory()". And this would also increase the expected threshold since the chunk is multiplied by NUM_CHUNKS to get the threshold. And just a nits: 1. While you are changing the source you might fix the type at L28 "setUsatgeThreshold" -> "setUsageThreshold" 2. Should the @bug annotation contain the test issues? Just asking - I saw fixes without the test issue number added to the @bug annotation. Cheers, -JB- > > webrev: > http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ > > bug: > https://bugs.openjdk.java.net/browse/JDK-6980984 > > Thanks, > Shanliang From shanliang.jiang at oracle.com Wed Jan 22 06:32:09 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 22 Jan 2014 15:32:09 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 In-Reply-To: <52DFD253.20107@oracle.com> References: <52DFC74D.5040303@oracle.com> <52DFD253.20107@oracle.com> Message-ID: <52DFD669.1000805@oracle.com> Jaroslav Bachorik wrote: > Hi Shanliang, > On 22.1.2014 14:27, shanliang wrote: >> Hi, >> >> The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9. >> >> We can have several solutions, like to use: >> Runtime.getRuntime().maxMemory() >> Runtime.getRuntime().totalMemory; >> >> MemoryUsage.getCommitted() > > You were also mentioning passing -XMaxHeapSize argument to force G1 to > put restriction on the max heap size in the issue. Does it work? Yes it worked too, as other solutions I mentioned above. > >> >> or hard-code chunkSize to be 1M. >> >> I found that the test ran much faster with: >> chunkSize = Runtime.getRuntime().freeMemory()/10; >> than: >> chunkSize = 1M; > > That's odd - unless "Runtime.getRuntime().freeMemory()/10" gives you a > chunk much smaller than 1M. BTW, why do you divide the amount of free > memory by 10? The "mu.getMax()" based calculation is using 20. > Wouldn't this give you a bigger chunk when calculating it from > "freeMemory()". And this would also increase the expected threshold > since the chunk is multiplied by NUM_CHUNKS to get the threshold. Yes it is interesting, it took 15 seconds and num_iteration = 145 with chunkSize = 1M, but with Runtime.getRuntime().freeMemory()/10, it worked as without G1GC, took less 1 second and num_iteration = 2, at least on my Mac. > > > And just a nits: > 1. While you are changing the source you might fix the type at L28 > "setUsatgeThreshold" -> "setUsageThreshold" OK, good catch. > 2. Should the @bug annotation contain the test issues? Just asking - I > saw fixes without the test issue number added to the @bug annotation. Not sure, but remember that once I was suggested to add it. Thanks, Shanliang > > Cheers, > > -JB- > >> >> webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-6980984 >> >> Thanks, >> Shanliang > From jaroslav.bachorik at oracle.com Wed Jan 22 06:35:44 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 22 Jan 2014 15:35:44 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 In-Reply-To: <52DFD669.1000805@oracle.com> References: <52DFC74D.5040303@oracle.com> <52DFD253.20107@oracle.com> <52DFD669.1000805@oracle.com> Message-ID: <52DFD740.2000704@oracle.com> On 22.1.2014 15:32, shanliang wrote: > Jaroslav Bachorik wrote: >> Hi Shanliang, >> On 22.1.2014 14:27, shanliang wrote: >>> Hi, >>> >>> The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9. >>> >>> We can have several solutions, like to use: >>> Runtime.getRuntime().maxMemory() >>> Runtime.getRuntime().totalMemory; >>> >>> MemoryUsage.getCommitted() >> >> You were also mentioning passing -XMaxHeapSize argument to force G1 to >> put restriction on the max heap size in the issue. Does it work? > Yes it worked too, as other solutions I mentioned above. >> >>> >>> or hard-code chunkSize to be 1M. >>> >>> I found that the test ran much faster with: >>> chunkSize = Runtime.getRuntime().freeMemory()/10; >>> than: >>> chunkSize = 1M; >> >> That's odd - unless "Runtime.getRuntime().freeMemory()/10" gives you a >> chunk much smaller than 1M. BTW, why do you divide the amount of free >> memory by 10? The "mu.getMax()" based calculation is using 20. >> Wouldn't this give you a bigger chunk when calculating it from >> "freeMemory()". And this would also increase the expected threshold >> since the chunk is multiplied by NUM_CHUNKS to get the threshold. > Yes it is interesting, it took 15 seconds and num_iteration = 145 with > chunkSize = 1M, but with Runtime.getRuntime().freeMemory()/10, it worked > as without G1GC, took less 1 second and num_iteration = 2, at least on > my Mac. Just out of curiosity - what is the chunk size when calculating via "Runtime.getRuntime().freeMemory()/10"? -JB- >> >> >> And just a nits: >> 1. While you are changing the source you might fix the type at L28 >> "setUsatgeThreshold" -> "setUsageThreshold" > OK, good catch. >> 2. Should the @bug annotation contain the test issues? Just asking - I >> saw fixes without the test issue number added to the @bug annotation. > Not sure, but remember that once I was suggested to add it. > > Thanks, > Shanliang >> >> Cheers, >> >> -JB- >> >>> >>> webrev: >>> http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-6980984 >>> >>> Thanks, >>> Shanliang >> > From daniel.fuchs at oracle.com Wed Jan 22 06:40:24 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 Jan 2014 15:40:24 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 In-Reply-To: <52DFD669.1000805@oracle.com> References: <52DFC74D.5040303@oracle.com> <52DFD253.20107@oracle.com> <52DFD669.1000805@oracle.com> Message-ID: <52DFD858.4080601@oracle.com> On 1/22/14 3:32 PM, shanliang wrote: > Jaroslav Bachorik wrote: >> Hi Shanliang, >> On 22.1.2014 14:27, shanliang wrote: >>> Hi, >>> >>> The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9. >>> >>> We can have several solutions, like to use: >>> Runtime.getRuntime().maxMemory() >>> Runtime.getRuntime().totalMemory; >>> >>> MemoryUsage.getCommitted() >> >> You were also mentioning passing -XMaxHeapSize argument to force G1 to >> put restriction on the max heap size in the issue. Does it work? > Yes it worked too, as other solutions I mentioned above. >> >>> >>> or hard-code chunkSize to be 1M. >>> >>> I found that the test ran much faster with: >>> chunkSize = Runtime.getRuntime().freeMemory()/10; >>> than: >>> chunkSize = 1M; >> >> That's odd - unless "Runtime.getRuntime().freeMemory()/10" gives you a >> chunk much smaller than 1M. BTW, why do you divide the amount of free >> memory by 10? The "mu.getMax()" based calculation is using 20. >> Wouldn't this give you a bigger chunk when calculating it from >> "freeMemory()". And this would also increase the expected threshold >> since the chunk is multiplied by NUM_CHUNKS to get the threshold. > Yes it is interesting, it took 15 seconds and num_iteration = 145 with > chunkSize = 1M, but with Runtime.getRuntime().freeMemory()/10, it worked > as without G1GC, took less 1 second and num_iteration = 2, at least on > my Mac. >> This is strange Shanliang: you must have made a mistake somewhere, because on my Mac with chunkSize = 1M when max == -1 it only needs 2 iterations (as it should - and not 145). FYI - I have added a trace to print both MemoryUsage and Runtime.freeMemory() in the test, and I have observed that the result of Runtime.freeMemory() is very close to mu.getCommitted(): Memory Usage: init = 127926272(124928K) used = 0(0K) committed = 126877696(123904K) max = -1(-1K) Free memory: 128325536 Here is the full trace (with cheukSize=1M when max=-1): ACTION: main -- Passed. Execution successful REASON: User specified action: run main/othervm/timeout=600 -XX:+UseG1GC MemoryManagement TIME: 0.54 seconds messages: command: main -XX:+UseG1GC MemoryManagement reason: User specified action: run main/othervm/timeout=600 -XX:+UseG1GC MemoryManagement elapsed time (seconds): 0.54 STDOUT: Memory Usage: init = 127926272(124928K) used = 0(0K) committed = 126877696(123904K) max = -1(-1K) Free memory: 128325536 Setting threshold for G1 Old Gen from 0 to 2000000. Current used = 0 Starting an AllocatorThread to allocate memory. Notification for G1 Old Gen [type = java.management.memory.threshold.exceeded count = 1] usage = init = 127926272(124928K) used = 2951472(2882K) committed = 126877696(123904K) max = -1(-1K) AllocatedThread finished memory allocation num_iteration = 2 Test passed. -- daniel >> >> And just a nits: >> 1. While you are changing the source you might fix the type at L28 >> "setUsatgeThreshold" -> "setUsageThreshold" > OK, good catch. >> 2. Should the @bug annotation contain the test issues? Just asking - I >> saw fixes without the test issue number added to the @bug annotation. > Not sure, but remember that once I was suggested to add it. > > Thanks, > Shanliang >> >> Cheers, >> >> -JB- >> >>> >>> webrev: >>> http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-6980984 >>> >>> Thanks, >>> Shanliang >> > From shanliang.jiang at oracle.com Wed Jan 22 06:42:09 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 22 Jan 2014 15:42:09 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 In-Reply-To: <52DFD740.2000704@oracle.com> References: <52DFC74D.5040303@oracle.com> <52DFD253.20107@oracle.com> <52DFD669.1000805@oracle.com> <52DFD740.2000704@oracle.com> Message-ID: <52DFD8C1.6030203@oracle.com> Jaroslav Bachorik wrote: > On 22.1.2014 15:32, shanliang wrote: >> Jaroslav Bachorik wrote: >>> Hi Shanliang, >>> On 22.1.2014 14:27, shanliang wrote: >>>> Hi, >>>> >>>> The bug was reproduced only on jdk6 on my Mac, but well passed on >>>> 7/8/9. >>>> >>>> We can have several solutions, like to use: >>>> Runtime.getRuntime().maxMemory() >>>> Runtime.getRuntime().totalMemory; >>>> >>>> MemoryUsage.getCommitted() >>> >>> You were also mentioning passing -XMaxHeapSize argument to force G1 to >>> put restriction on the max heap size in the issue. Does it work? >> Yes it worked too, as other solutions I mentioned above. >>> >>>> >>>> or hard-code chunkSize to be 1M. >>>> >>>> I found that the test ran much faster with: >>>> chunkSize = Runtime.getRuntime().freeMemory()/10; >>>> than: >>>> chunkSize = 1M; >>> >>> That's odd - unless "Runtime.getRuntime().freeMemory()/10" gives you a >>> chunk much smaller than 1M. BTW, why do you divide the amount of free >>> memory by 10? The "mu.getMax()" based calculation is using 20. >>> Wouldn't this give you a bigger chunk when calculating it from >>> "freeMemory()". And this would also increase the expected threshold >>> since the chunk is multiplied by NUM_CHUNKS to get the threshold. >> Yes it is interesting, it took 15 seconds and num_iteration = 145 with >> chunkSize = 1M, but with Runtime.getRuntime().freeMemory()/10, it worked >> as without G1GC, took less 1 second and num_iteration = 2, at least on >> my Mac. > > Just out of curiosity - what is the chunk size when calculating via > "Runtime.getRuntime().freeMemory()/10"? 8325091 > > -JB- > >>> >>> >>> And just a nits: >>> 1. While you are changing the source you might fix the type at L28 >>> "setUsatgeThreshold" -> "setUsageThreshold" >> OK, good catch. >>> 2. Should the @bug annotation contain the test issues? Just asking - I >>> saw fixes without the test issue number added to the @bug annotation. >> Not sure, but remember that once I was suggested to add it. >> >> Thanks, >> Shanliang >>> >>> Cheers, >>> >>> -JB- >>> >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ >>>> >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-6980984 >>>> >>>> Thanks, >>>> Shanliang >>> >> > From mikael.gerdin at oracle.com Wed Jan 22 06:50:43 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 22 Jan 2014 15:50:43 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52DEEB5F.6020306@oracle.com> References: <52DEEB5F.6020306@oracle.com> Message-ID: <2712053.9DHssW8NCY@mgerdin03> Hi Jesper, On Tuesday 21 January 2014 22.49.19 Jesper Wilhelmsson wrote: > Hi, > > Could I have a few reviews of this change? > > Summary: > To allow applications a more fine grained control over the GC over time, > we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. > > The initial request that lead up to this change involved ParallelGC which is > notoriously unwilling to shrink the heap. Since ParallelGC didn't support > the heap free ratio flags, this change also includes implementing support > for these flags in ParallelGC. > > Changes have also been made to the argument parsing, attach listener and the > management API to verify the flag values when set through the different > interfaces. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ In psAdaptiveSizePolicy.cpp: 83 ParallelScavengeHeap* heap = (ParallelScavengeHeap*)Universe::heap(); You can use ParallelScavengeHeap::heap() here instead. I had an offline discussion with Jesper with notebooks and formulas to figure out how Min/MaxHeapFreeRatio should be used and how to change the psScavenge change. I have a suggestion for how to do verification as well: if you add a bool Flag::is_equal(void* flagptr) const { return _addr == flagptr; } you can have a sort of generic verify_flag function with only a pointer check and some ifs instead of doing string compares: template bool CommandLineFlags::verify_flag(Flag* flag, T value) { if (flag->is_equal(&MinHeapFreeRatio)) { if (is_percentage(value)) { } if (value <= MaxHeapFreeRatio) { } } if (flag->is_equal(&MaxHeapFreeRatio)) { ... } return something; } Another, perhaps too complex, approach would be to trade the _type char* for a vtable pointer for Flags and have BooleanFlag, FloatFlag, etc. and make the _type field based on virtual dispatch. Then each flag which needed verification could override a virtual verify() function. I'm not going to insist on changing this but we really need to fix this if we add one more manageable flag which needs bounds checking or some other type of verification. /Mikael > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 > > The plan is to push this to 9 and then backport to 8 and 7. > > Thanks! > /Jesper From daniel.fuchs at oracle.com Wed Jan 22 06:57:50 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 Jan 2014 15:57:50 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 In-Reply-To: <52DFC74D.5040303@oracle.com> References: <52DFC74D.5040303@oracle.com> Message-ID: <52DFDC6E.5070409@oracle.com> Hi Shanliang, I just notice that there are some synchronization issues in the test as well: all static variables used by the allocator thread should be declared volatile (chunkSize, mpool ...). -- daniel On 1/22/14 2:27 PM, shanliang wrote: > Hi, > > The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9. > > We can have several solutions, like to use: > Runtime.getRuntime().maxMemory() > Runtime.getRuntime().totalMemory; > > MemoryUsage.getCommitted() > > or hard-code chunkSize to be 1M. > > I found that the test ran much faster with: > chunkSize = Runtime.getRuntime().freeMemory()/10; > than: > chunkSize = 1M; > > webrev: > http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ > > bug: > https://bugs.openjdk.java.net/browse/JDK-6980984 > > Thanks, > Shanliang From staffan.larsen at oracle.com Wed Jan 22 07:02:53 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Jan 2014 16:02:53 +0100 Subject: RFR(S): JDK-8032250 : Add trace event for VM flag changes In-Reply-To: References: <4213C88C-3617-466C-909B-F8DAA37C8015@oracle.com> Message-ID: Erik discovered that I used traced events with signed values for some unsigned flag types. So, new revision: http://cr.openjdk.java.net/~sla/8032250/webrev.02/ Thanks, /Staffan On 22 jan 2014, at 15:08, Staffan Larsen wrote: > Erik Helin suggested using template functions instead of macros which makes the code a little more type safe. > > Also added a missing #include in globals.cpp. > > Here is a new version of the webrev: http://cr.openjdk.java.net/~sla/8032250/webrev.01/ > > Thanks, > /Staffan > > On 21 jan 2014, at 14:47, Staffan Larsen wrote: > >> This is a patch to capture a trace event whenever a manageable VM flag is changed in runtime. >> >> webrev: http://cr.openjdk.java.net/~sla/8032250/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8032250 >> >> Thanks, >> /Staffan > From erik.gahlin at oracle.com Wed Jan 22 07:17:34 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 22 Jan 2014 16:17:34 +0100 Subject: RFR(S): JDK-8032250 : Add trace event for VM flag changes In-Reply-To: References: <4213C88C-3617-466C-909B-F8DAA37C8015@oracle.com> Message-ID: <52DFE10E.8010406@oracle.com> Looks good. Erik Staffan Larsen skrev 2014-01-22 16:02: > Erik discovered that I used traced events with signed values for some unsigned flag types. > > So, new revision: http://cr.openjdk.java.net/~sla/8032250/webrev.02/ > > Thanks, > /Staffan > > On 22 jan 2014, at 15:08, Staffan Larsen wrote: > >> Erik Helin suggested using template functions instead of macros which makes the code a little more type safe. >> >> Also added a missing #include in globals.cpp. >> >> Here is a new version of the webrev: http://cr.openjdk.java.net/~sla/8032250/webrev.01/ >> >> Thanks, >> /Staffan >> >> On 21 jan 2014, at 14:47, Staffan Larsen wrote: >> >>> This is a patch to capture a trace event whenever a manageable VM flag is changed in runtime. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8032250/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8032250 >>> >>> Thanks, >>> /Staffan From erik.helin at oracle.com Wed Jan 22 07:28:36 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 22 Jan 2014 16:28:36 +0100 Subject: RFR(S): JDK-8032250 : Add trace event for VM flag changes In-Reply-To: References: <4213C88C-3617-466C-909B-F8DAA37C8015@oracle.com> Message-ID: <52DFE3A4.8060703@oracle.com> Hi Staffan, the change looks good now :) Thanks, Erik On 2014-01-22 16:02, Staffan Larsen wrote: > Erik discovered that I used traced events with signed values for some unsigned flag types. > > So, new revision: http://cr.openjdk.java.net/~sla/8032250/webrev.02/ > > Thanks, > /Staffan > > On 22 jan 2014, at 15:08, Staffan Larsen wrote: > >> Erik Helin suggested using template functions instead of macros which makes the code a little more type safe. >> >> Also added a missing #include in globals.cpp. >> >> Here is a new version of the webrev: http://cr.openjdk.java.net/~sla/8032250/webrev.01/ >> >> Thanks, >> /Staffan >> >> On 21 jan 2014, at 14:47, Staffan Larsen wrote: >> >>> This is a patch to capture a trace event whenever a manageable VM flag is changed in runtime. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8032250/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8032250 >>> >>> Thanks, >>> /Staffan >> > From shanliang.jiang at oracle.com Wed Jan 22 08:29:05 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 22 Jan 2014 17:29:05 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 In-Reply-To: <52DFDC6E.5070409@oracle.com> References: <52DFC74D.5040303@oracle.com> <52DFDC6E.5070409@oracle.com> Message-ID: <52DFF1D1.9000309@oracle.com> Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-6980984/01/ with the modifications for: 1) synchronization issues raised by Daniel 2) "setUsatgeThreshold" -> "setUsageThreshold" The odd issue about getting slower with: chunkSize = 1M; maybe was from the "old gen" behavior, but that seems not important for the test. Thanks, Shanliang Daniel Fuchs wrote: > Hi Shanliang, > > I just notice that there are some synchronization > issues in the test as well: all static variables > used by the allocator thread should be declared > volatile (chunkSize, mpool ...). > > -- daniel > > On 1/22/14 2:27 PM, shanliang wrote: >> Hi, >> >> The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9. >> >> We can have several solutions, like to use: >> Runtime.getRuntime().maxMemory() >> Runtime.getRuntime().totalMemory; >> >> MemoryUsage.getCommitted() >> >> or hard-code chunkSize to be 1M. >> >> I found that the test ran much faster with: >> chunkSize = Runtime.getRuntime().freeMemory()/10; >> than: >> chunkSize = 1M; >> >> webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-6980984 >> >> Thanks, >> Shanliang > From daniel.fuchs at oracle.com Wed Jan 22 08:43:18 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 Jan 2014 17:43:18 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 In-Reply-To: <52DFF1D1.9000309@oracle.com> References: <52DFC74D.5040303@oracle.com> <52DFDC6E.5070409@oracle.com> <52DFF1D1.9000309@oracle.com> Message-ID: <52DFF526.7010902@oracle.com> Hi Shanliang, This looks reasonable to me. I'm not sure that using freeMemory() will always work - but at the worst it means that there are still some cases where the test that used to fail will continue to fail ;-) We have both seen that it fixes the original issue which was encountered on Mac with JDK 6 & -XX:+UseG1GC (which looks to be the unique known config that seems to return a MemoryUsage whose getMax() is -1). Please run the test through jprt before pushing though - just to check that it still passes on all archs :-) cheers, -- daniel On 1/22/14 5:29 PM, shanliang wrote: > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-6980984/01/ > > with the modifications for: > 1) synchronization issues raised by Daniel > 2) "setUsatgeThreshold" -> "setUsageThreshold" > > The odd issue about getting slower with: > chunkSize = 1M; > maybe was from the "old gen" behavior, but that seems not important for > the test. > > Thanks, > Shanliang > > Daniel Fuchs wrote: >> Hi Shanliang, >> >> I just notice that there are some synchronization >> issues in the test as well: all static variables >> used by the allocator thread should be declared >> volatile (chunkSize, mpool ...). >> >> -- daniel >> >> On 1/22/14 2:27 PM, shanliang wrote: >>> Hi, >>> >>> The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9. >>> >>> We can have several solutions, like to use: >>> Runtime.getRuntime().maxMemory() >>> Runtime.getRuntime().totalMemory; >>> >>> MemoryUsage.getCommitted() >>> >>> or hard-code chunkSize to be 1M. >>> >>> I found that the test ran much faster with: >>> chunkSize = Runtime.getRuntime().freeMemory()/10; >>> than: >>> chunkSize = 1M; >>> >>> webrev: >>> http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-6980984 >>> >>> Thanks, >>> Shanliang >> > From kevin.walls at oracle.com Wed Jan 22 09:43:23 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 22 Jan 2014 17:43:23 +0000 Subject: RR(S): 8032466: serviceability/sa/jmap-hashcode/Test8028623.java fails with compilation errors Message-ID: <52E0033B.80109@oracle.com> Hi, Can I just get a review of this jtreg tag change in a testcase. The testcase specifically contains a utf8 character and to make sure it compiles everywhere we need to specify -encoding on the @compile line, and then add an @run line: webrev http://cr.openjdk.java.net/~kevinw/8032466/webrev.00/ bug https://bugs.openjdk.java.net/browse/JDK-8032466 (if the testcase runs fine without this change, in jtreg locally you can make it fail by setting -encoding ascii) Thanks! Kevin From dmitry.samersoff at oracle.com Wed Jan 22 10:02:49 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Jan 2014 22:02:49 +0400 Subject: RR(S): 8032466: serviceability/sa/jmap-hashcode/Test8028623.java fails with compilation errors In-Reply-To: <52E0033B.80109@oracle.com> References: <52E0033B.80109@oracle.com> Message-ID: <52E007C9.7060207@oracle.com> Kevin, Looks good for me. -Dmitry On 2014-01-22 21:43, Kevin Walls wrote: > Hi, > > Can I just get a review of this jtreg tag change in a testcase. The > testcase specifically contains a utf8 character and to make sure it > compiles everywhere we need to specify -encoding on the @compile line, > and then add an @run line: > > webrev > http://cr.openjdk.java.net/~kevinw/8032466/webrev.00/ > > bug > https://bugs.openjdk.java.net/browse/JDK-8032466 > > (if the testcase runs fine without this change, in jtreg locally you can > make it fail by setting -encoding ascii) > > Thanks! > Kevin -- 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 sean.mullan at oracle.com Wed Jan 22 16:12:58 2014 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 23 Jan 2014 00:12:58 +0000 Subject: hg: jdk8/tl/jdk: 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID Message-ID: <20140123001311.1048B6269C@hg.openjdk.java.net> Changeset: 57c26829deb6 Author: mullan Date: 2014-01-22 19:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57c26829deb6 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID Reviewed-by: vinnie, xuelei ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java From david.holmes at oracle.com Wed Jan 22 22:06:04 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jan 2014 16:06:04 +1000 Subject: RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52DFC292.8040401@oracle.com> References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com> <528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com> <528BB41A.4070107@oracle.com> <52A5AD7B.1060403@oracle.com> <52B3AB16.30206@oracle.com> <52B3FEBE.40106@oracle.com> <52DE72A8.9050807@oracle.com> <52DF646B.3000606@oracle.com> <52DFC292.8040401@oracle.com> Message-ID: <52E0B14C.2020105@oracle.com> On 22/01/2014 11:07 PM, Jaroslav Bachorik wrote: > Updated webrev with no "arrive()" calls dangling. > > - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.07 Thanks looks okay. The proof as always is in the running of the test. David > -JB- > > On 22.1.2014 09:12, Jaroslav Bachorik wrote: >> Argh. Sorry. Probably messed up when restoring my crashed HDD. I will >> go through the patch to see if there are any other omissions. >> >> Thanks, >> -JB- >> >> David Holmes wrote: >>> Hi Jaroslav, >>> >>> I still see some suspect uses of p.arrive() instead of >>> p.arriveAndAwaitAdvance(). >>> >>> David >>> >>> On 21/01/2014 11:14 PM, Jaroslav Bachorik wrote: >>>> Based on the experience while fixing >>>> https://bugs.openjdk.java.net/browse/JDK-8032377 I've updated the >>> patch >>>> not to require an exact number for the blocked count - it will pass >>>> whenever the reported blocked count is at least large as the the >>>> expected number. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.06 >>>> >>>> Thanks, >>>> >>>> -JB- >>>> >>>> On 20.12.2013 09:24, Jaroslav Bachorik wrote: >>>>> On 20.12.2013 03:27, David Holmes wrote: >>>>>> Sorry for the delay - still catching up after vacation (only 435 >>> openjdk >>>>>> emails left :( ). >>>>> >>>>> NP >>>>> >>>>>> >>>>>> On 9/12/2013 9:46 PM, Jaroslav Bachorik wrote: >>>>>>> On 19.11.2013 19:55, David Holmes wrote: >>>>>>>> On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 18.11.2013 22:03, David Holmes wrote: >>>>>>>>>> Hi Jaroslav, >>>>>>>>>> >>>>>>>>>> I think your phaser usage is incorrect: >>>>>>>>>> >>>>>>>>>> 88 public void run() { >>>>>>>>>> 89 p.arriveAndAwaitAdvance(); // phase[1] >>>>>>>>>> 90 synchronized(lock1) { >>>>>>>>>> 91 System.out.println("[LockerThread >>> obtained >>>>>>>>>> Lock1]"); >>>>>>>>>> 92 p.arrive(); // phase[2] >>>>>>>>>> 93 } >>>>>>>>>> 94 p.arriveAndAwaitAdvance(); // phase[3] >>>>>>>>>> 95 } >>>>>>>>>> >>>>>>>>>> Here the current thread can release itself at line 94. You have >>>>>>>>>> assumed >>>>>>>>>> that the phase[2] arrive will be a trigger to release the main >>>>>>>>>> thread >>>>>>>>>> but it may not have reached its arriveAndAwaitAdvance phase[2] >>>>>>>>>> statement >>>>>>>>>> yet, so the current thread arrives then does arrive-and-wait >>> but the >>>>>>>>>> number of arrivals is 2 so it doesn't wait. >>>>>>>>>> >>>>>>>>>> A CyclicBarrier per phase may be clearer. >>>>>>>>> >>>>>>>>> Yes, thanks for pointing this out. But, wouldn't >>>>>>>>> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've >>>>>>>>> tried to >>>>>>>>> replace Phaser with CyclicBarrier but while it seems to work as >>>>>>>>> expected >>>>>>>>> it pollutes code with the necessity to catch various exceptions >>>>>>>>> (InterruptedException, BarrierException etc.). So, if the simple >>> fix >>>>>>>>> with Phaser would do the trick I would better use that. >>>>>>>> >>>>>>>> In this case yes arriveAndAwaitAdvance would fix it. I don't know >>> if >>>>>>>> other tests have the same issue - the concern would be ensuring >>>>>>>> there's >>>>>>>> no possibility of deadlocks in general. >>>>>>> >>>>>>> I've updated the webrev with the one using >>> p.arriveAndAwaitAdvance() at >>>>>>> line 92 - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.04 >>>>>>> >>>>>>> Are you ok with this change then? >>>>>> >>>>>> I think you have the same problem anywhere that arrive() is used >>> eg: >>>>>> >>>>>> 129 p.arrive(); // phase[2] >>>>>> 130 p.arriveAndAwaitAdvance(); // phase[3] >>>>>> >>>>>> and >>>>>> >>>>>> 185 p.arrive(); // phase[2] >>>>>> 186 } >>>>>> 187 p.arriveAndAwaitAdvance(); // phase[3] >>>>> >>>>> Very probable :( Also, when analysing the recurrence of JDK-8029890 >>> I've >>>>> found out that Phaser.arriveAndAwaitAdvance() actually blocked the >>>>> thread in a way that it increased the number of contentions reported >>> :( >>>>> CyclicBarrier seems to wait instead - I will have to use >>> CyclicBarrier >>>>> when testing the number of reported contentions and Phaser when >>> testing >>>>> the number of reported waits :/ >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> ------ >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> after discussing this with Mandy I've rewritten the test to >>> use the >>>>>>>>>>> j.u.concurrent for synchronization - this also makes it much >>>>>>>>>>> easier to >>>>>>>>>>> follow the test logic. >>>>>>>>>>> >>>>>>>>>>> The waited time, the blocked time and the waited counts are >>> only >>>>>>>>>>> checked >>>>>>>>>>> for sanity (increasing values) since it is not possible to do >>> the >>>>>>>>>>> reliable checks against hard numbers. >>>>>>>>>>> >>>>>>>>>>> I ran the test in a tight loop for 1500 times using -Xcomp and >>>>>>>>>>> -Xint >>>>>>>>>>> and >>>>>>>>>>> the test seems to pass constantly. >>>>>>>>>>> >>>>>>>>>>> New webrev: >>> http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote: >>>>>>>>>>>> Please, review this small patch for a test failing due to the >>>>>>>>>>>> updated >>>>>>>>>>>> implementation in JDK6. >>>>>>>>>>>> >>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>>>>>>>>>> Webrev: >>> http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> The test fails due to the change in mustang where >>>>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include >>>>>>>>>>>> Thread.sleep() >>>>>>>>>>>> too. Unfortunately, Thread.sleep() is used throughout the >>> test for >>>>>>>>>>>> synchronization purposes and this breaks the test. >>>>>>>>>>>> >>>>>>>>>>>> In the patch I propose to replace Thread.sleep() with busy >>> wait >>>>>>>>>>>> and >>>>>>>>>>>> hinting the scheduler by Thread.yield(). While not very >>> elegant it >>>>>>>>>>>> successfully works around inclusion of unknown number of >>>>>>>>>>>> Thread.sleep()s >>>>>>>>>>>> (they are called in loop). >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> > From staffan.larsen at oracle.com Wed Jan 22 23:05:08 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Jan 2014 08:05:08 +0100 Subject: RR(S): 8032466: serviceability/sa/jmap-hashcode/Test8028623.java fails with compilation errors In-Reply-To: <52E0033B.80109@oracle.com> References: <52E0033B.80109@oracle.com> Message-ID: <05BFE552-8255-4C60-AE82-981E0FD9E5AD@oracle.com> Looks good! Thanks, /Staffan On 22 jan 2014, at 18:43, Kevin Walls wrote: > Hi, > > Can I just get a review of this jtreg tag change in a testcase. The testcase specifically contains a utf8 character and to make sure it compiles everywhere we need to specify -encoding on the @compile line, and then add an @run line: > > webrev > http://cr.openjdk.java.net/~kevinw/8032466/webrev.00/ > > bug > https://bugs.openjdk.java.net/browse/JDK-8032466 > > (if the testcase runs fine without this change, in jtreg locally you can make it fail by setting -encoding ascii) > > Thanks! > Kevin From staffan.larsen at oracle.com Wed Jan 22 23:36:02 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Jan 2014 08:36:02 +0100 Subject: RFR(M): 8032462 Change the linux SDT implementation to use USDT2 instead of USDT1 Message-ID: <64224E80-D3F3-45ED-913C-A1883B18E4AB@oracle.com> The only usage today of the DTrace macros under the USDT1 define is the SDT provider on linux. This can be changed to use the USDT2 style by preprocessing the .d files into .h files with the dtrace utility in the same way as we do on solaris and OS X. I have also moved the provider definition files (hotspot.d, hotspot_jni.d and hs_private.d) to a common directory instead of having one identical copy per platform. I would really like to have a review from somebody on the IcedTea team since I haven?t been able to fully verify this change by running systemtap. Once this change is done, we can proceed to remove the USDT1 style macros. webrev: http://cr.openjdk.java.net/~sla/8032462/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8032462 testing: vm.dtrace.testlist in nsk Thanks, /Staffan From kevin.walls at oracle.com Thu Jan 23 01:16:18 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 23 Jan 2014 09:16:18 +0000 Subject: RR(S): 8032466: serviceability/sa/jmap-hashcode/Test8028623.java fails with compilation errors In-Reply-To: <05BFE552-8255-4C60-AE82-981E0FD9E5AD@oracle.com> References: <52E0033B.80109@oracle.com> <05BFE552-8255-4C60-AE82-981E0FD9E5AD@oracle.com> Message-ID: <52E0DDE2.6050601@oracle.com> Thanks Dmitry, Staffan! On 23/01/14 07:05, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 22 jan 2014, at 18:43, Kevin Walls wrote: > >> Hi, >> >> Can I just get a review of this jtreg tag change in a testcase. The testcase specifically contains a utf8 character and to make sure it compiles everywhere we need to specify -encoding on the @compile line, and then add an @run line: >> >> webrev >> http://cr.openjdk.java.net/~kevinw/8032466/webrev.00/ >> >> bug >> https://bugs.openjdk.java.net/browse/JDK-8032466 >> >> (if the testcase runs fine without this change, in jtreg locally you can make it fail by setting -encoding ascii) >> >> Thanks! >> Kevin From jaroslav.bachorik at oracle.com Thu Jan 23 01:19:02 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 23 Jan 2014 10:19:02 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 In-Reply-To: <52DFF1D1.9000309@oracle.com> References: <52DFC74D.5040303@oracle.com> <52DFDC6E.5070409@oracle.com> <52DFF1D1.9000309@oracle.com> Message-ID: <52E0DE86.3040409@oracle.com> Looks good. Just a side question - why are you using the divider of 10 (and the original divider is 20)? -JB- On 22.1.2014 17:29, shanliang wrote: > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-6980984/01/ > > with the modifications for: > 1) synchronization issues raised by Daniel > 2) "setUsatgeThreshold" -> "setUsageThreshold" > > The odd issue about getting slower with: > chunkSize = 1M; > maybe was from the "old gen" behavior, but that seems not important for > the test. > > Thanks, > Shanliang > > Daniel Fuchs wrote: >> Hi Shanliang, >> >> I just notice that there are some synchronization >> issues in the test as well: all static variables >> used by the allocator thread should be declared >> volatile (chunkSize, mpool ...). >> >> -- daniel >> >> On 1/22/14 2:27 PM, shanliang wrote: >>> Hi, >>> >>> The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9. >>> >>> We can have several solutions, like to use: >>> Runtime.getRuntime().maxMemory() >>> Runtime.getRuntime().totalMemory; >>> >>> MemoryUsage.getCommitted() >>> >>> or hard-code chunkSize to be 1M. >>> >>> I found that the test ran much faster with: >>> chunkSize = Runtime.getRuntime().freeMemory()/10; >>> than: >>> chunkSize = 1M; >>> >>> webrev: >>> http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-6980984 >>> >>> Thanks, >>> Shanliang >> > From shanliang.jiang at oracle.com Thu Jan 23 01:26:44 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 23 Jan 2014 10:26:44 +0100 Subject: Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1 In-Reply-To: <52E0DE86.3040409@oracle.com> References: <52DFC74D.5040303@oracle.com> <52DFDC6E.5070409@oracle.com> <52DFF1D1.9000309@oracle.com> <52E0DE86.3040409@oracle.com> Message-ID: <52E0E054.2040509@oracle.com> Jaroslav Bachorik wrote: > Looks good. > > Just a side question - why are you using the divider of 10 (and the > original divider is 20)? Did change to 20 in the last version :) I tested with different dividers and got almost same running time with 10 and 20. Thanks, Shanliang > > -JB- > > On 22.1.2014 17:29, shanliang wrote: >> Here is the new version: >> http://cr.openjdk.java.net/~sjiang/JDK-6980984/01/ >> >> with the modifications for: >> 1) synchronization issues raised by Daniel >> 2) "setUsatgeThreshold" -> "setUsageThreshold" >> >> The odd issue about getting slower with: >> chunkSize = 1M; >> maybe was from the "old gen" behavior, but that seems not important for >> the test. >> >> Thanks, >> Shanliang >> >> Daniel Fuchs wrote: >>> Hi Shanliang, >>> >>> I just notice that there are some synchronization >>> issues in the test as well: all static variables >>> used by the allocator thread should be declared >>> volatile (chunkSize, mpool ...). >>> >>> -- daniel >>> >>> On 1/22/14 2:27 PM, shanliang wrote: >>>> Hi, >>>> >>>> The bug was reproduced only on jdk6 on my Mac, but well passed on >>>> 7/8/9. >>>> >>>> We can have several solutions, like to use: >>>> Runtime.getRuntime().maxMemory() >>>> Runtime.getRuntime().totalMemory; >>>> >>>> MemoryUsage.getCommitted() >>>> >>>> or hard-code chunkSize to be 1M. >>>> >>>> I found that the test ran much faster with: >>>> chunkSize = Runtime.getRuntime().freeMemory()/10; >>>> than: >>>> chunkSize = 1M; >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ >>>> >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-6980984 >>>> >>>> Thanks, >>>> Shanliang >>> >> > From paul.sandoz at oracle.com Thu Jan 23 02:08:33 2014 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 23 Jan 2014 10:08:33 +0000 Subject: hg: jdk8/tl/jdk: 8032190: Specifications of stream flatMap methods should require mapped streams to be closed Message-ID: <20140123100901.4C12D626BF@hg.openjdk.java.net> Changeset: 68eb0c55a8c0 Author: psandoz Date: 2014-01-21 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68eb0c55a8c0 8032190: Specifications of stream flatMap methods should require mapped streams to be closed Reviewed-by: chegar, alanb ! 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 From olivier.lagneau at oracle.com Thu Jan 23 08:48:25 2014 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Thu, 23 Jan 2014 17:48:25 +0100 Subject: RR(S): SA: Constantpool lookup for invokedynamic is not implemented In-Reply-To: <52DD4272.6050806@oracle.com> References: <52DD4272.6050806@oracle.com> Message-ID: <52E147D9.4020700@oracle.com> Copyright year for ByteCodeRewriter should be 2014 now ;-) Otherwise looks good. (not an official reviewer). Olivier. Dmitry Samersoff said on date 1/20/2014 4:36 PM: > Hi Everyone, > > Please review a small fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8032247/webrev.01/ > > It's one of fixes required to support invokedynamic in SA ClassWriter. > > -Dmitry > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140123/2cd9ac89/attachment.html From staffan.larsen at oracle.com Thu Jan 23 11:13:06 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Jan 2014 20:13:06 +0100 Subject: RR(S): SA: Constantpool lookup for invokedynamic is not implemented In-Reply-To: <52DD4272.6050806@oracle.com> References: <52DD4272.6050806@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 20 jan 2014, at 16:36, Dmitry Samersoff wrote: > Hi Everyone, > > Please review a small fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8032247/webrev.01/ > > It's one of fixes required to support invokedynamic in SA ClassWriter. > > -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 serguei.spitsyn at oracle.com Thu Jan 23 11:36:41 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jan 2014 11:36:41 -0800 Subject: RR(S): SA: Constantpool lookup for invokedynamic is not implemented In-Reply-To: <52DD4272.6050806@oracle.com> References: <52DD4272.6050806@oracle.com> Message-ID: <52E16F49.1080003@oracle.com> Looks good. Thanks, Serguei On 1/20/14 7:36 AM, Dmitry Samersoff wrote: > Hi Everyone, > > Please review a small fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8032247/webrev.01/ > > It's one of fixes required to support invokedynamic in SA ClassWriter. > > -Dmitry > From christian.thalinger at oracle.com Thu Jan 23 13:09:38 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 Jan 2014 13:09:38 -0800 Subject: RFR 8019389: SA-JDI JSR292: sun.jvm.hotspot.jdi.StackFrame.thisObject() throws sun.jvm.hotspot.utilities.AssertionFailure: sanity check In-Reply-To: <52DE32CE.3080703@oracle.com> References: <52DD37E3.1020402@oracle.com> <52DD3D1B.9070700@oracle.com> <52DD53C2.6070904@oracle.com> <52DE32CE.3080703@oracle.com> Message-ID: <2F0BD850-0C45-4377-959A-41045C75FB88@oracle.com> Looks good. On Jan 21, 2014, at 12:41 AM, Olivier Lagneau wrote: > Please find the new webrev with copyright date fixed (changed to 2014). > > Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.01/ > > Olivier. > > Olivier Lagneau said on date 1/20/2014 5:50 PM: >> >> Oops, right ! >> >> Will fix that. >> >> Olivier. >> >> shanliang said on date 1/20/2014 4:13 PM: >>> >>> Olivier, >>> >>> Now it is 2014 :) >>> >>> >>> Olivier Lagneau wrote: >>>> >>>> Please review the following simple fix. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8019389 >>>> Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.00/ >>>> >>>> The issue is due to the fact that _invokeHandle bytecode is generated by hotspot, >>>> but is not declared in agent code. Just declaring the new bytecode solves the assertion failure. >>>> >>>> However the tests reported in 8019389 (bootstrapOtherStratumInStackTrace, targetOtherStratumInStackTrace) >>>> suffer the problem from JDK-7016268 : Can't get strata information through SA-JDI >>>> Thus, the "stratum mismatch" related to JDK-7016268 will still be present after fix. >>>> This second problem has to be fixed through JDK-7016268. >>>> >>>> Thanks, >>>> Olivier. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140123/c163a5c2/attachment.html From erik.joelsson at oracle.com Fri Jan 24 01:40:30 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 24 Jan 2014 09:40:30 +0000 Subject: hg: jdk8/tl: 8032632: Wrong version for the first jdk8 fcs build Message-ID: <20140124094031.71A1062744@hg.openjdk.java.net> Changeset: 7238a870ddb7 Author: erikj Date: 2014-01-24 10:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7238a870ddb7 8032632: Wrong version for the first jdk8 fcs build Reviewed-by: katleman ! common/autoconf/spec.gmk.in From yasu at ysfactory.dip.jp Fri Jan 24 05:50:26 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Fri, 24 Jan 2014 22:50:26 +0900 Subject: JDK-7090324: gclog rotation via external tool In-Reply-To: <52A09642.4030609@ysfactory.dip.jp> References: <52483BDB.8040206@ysfactory.dip.jp> <52496A21.8080608@ysfactory.dip.jp> <527CDD56.7080106@ysfactory.dip.jp> <52A09642.4030609@ysfactory.dip.jp> Message-ID: <52E26FA2.40909@ysfactory.dip.jp> Hi all, I've created webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ This patch works fine on current jdk9/hs-rt . Could you review this? I am just an Author. So I need a sponsor. Could you help me? Please cooperate. Thanks, Yasumasa On 2013/12/06 0:05, Yasumasa Suenaga wrote: > Hi all, > > Did someone read my email? > I really hope to merge "JDK-7090324: gclog rotation via external tool" . > > I hear that someone need this RFE. So I want to discuss about this. > > > Thanks, > > Yasumasa > > On 2013/11/08 21:47, Yasumasa Suenaga wrote: >> Hi all, >> >> Did someone read my mail? >> >> I think that this RFE helps us to watch Java heap on production system. >> Also I think this RFE is able to be part of the JEP 158 (Unified JVM Logging) . >> >> I want to update this RFE in JDK Bug System, but I don't have account. >> So I've posted email at first. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2013/09/30 21:10, Yasumasa Suenaga wrote: >>> In previous email, I've attached new patch for this RFE. >>> It works fine with current hsx. >>> >>> >>> Yasumasa >>> >>> On 2013/09/29 23:40, Yasu wrote: >>>> Hi all, >>>> >>>> We are using "logrotate" tool on RHEL for various log rotation. >>>> Current HotSpot has gclog rotation function for log size base, >>>> however I need to rotate gc log synchronizing with logrotate tool. >>>> >>>> So I've created RFE as "JDK-7090324: gclog rotation via external tool" . >>>> And Sr. Engineering Manager in Oracle said he use the essence of my patch in one >>>> of the jcmd subcommands. >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274.html >>>> >>>> 2 years ago, I posted a patch for this RFE. >>>> But this patch is too old to apply for current HotSpot. >>>> >>>> In last month, a similar discussion was appeared in ML. >>>> So I think it's time to discuss this RFE. >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.html >>>> >>>> >>>> Please cooperate. >>>> >>>> Best regards, >>>> Yasumasa >>> >> > From yumin.qi at oracle.com Fri Jan 24 15:06:28 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 24 Jan 2014 15:06:28 -0800 Subject: JDK-7090324: gclog rotation via external tool In-Reply-To: <52E26FA2.40909@ysfactory.dip.jp> References: <52483BDB.8040206@ysfactory.dip.jp> <52496A21.8080608@ysfactory.dip.jp> <527CDD56.7080106@ysfactory.dip.jp> <52A09642.4030609@ysfactory.dip.jp> <52E26FA2.40909@ysfactory.dip.jp> Message-ID: <52E2F1F4.5020003@oracle.com> Yasumasa, I can sponsor this for you --- will start from next week. Thanks Yumin On 1/24/2014 5:50 AM, Yasumasa Suenaga wrote: > Hi all, > > I've created webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ > > This patch works fine on current jdk9/hs-rt . > Could you review this? > > > I am just an Author. So I need a sponsor. > Could you help me? > > > Please cooperate. > > > Thanks, > > Yasumasa > > > On 2013/12/06 0:05, Yasumasa Suenaga wrote: >> Hi all, >> >> Did someone read my email? >> I really hope to merge "JDK-7090324: gclog rotation via external tool" . >> >> I hear that someone need this RFE. So I want to discuss about this. >> >> >> Thanks, >> >> Yasumasa >> >> On 2013/11/08 21:47, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Did someone read my mail? >>> >>> I think that this RFE helps us to watch Java heap on production system. >>> Also I think this RFE is able to be part of the JEP 158 (Unified JVM >>> Logging) . >>> >>> I want to update this RFE in JDK Bug System, but I don't have account. >>> So I've posted email at first. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2013/09/30 21:10, Yasumasa Suenaga wrote: >>>> In previous email, I've attached new patch for this RFE. >>>> It works fine with current hsx. >>>> >>>> >>>> Yasumasa >>>> >>>> On 2013/09/29 23:40, Yasu wrote: >>>>> Hi all, >>>>> >>>>> We are using "logrotate" tool on RHEL for various log rotation. >>>>> Current HotSpot has gclog rotation function for log size base, >>>>> however I need to rotate gc log synchronizing with logrotate tool. >>>>> >>>>> So I've created RFE as "JDK-7090324: gclog rotation via external >>>>> tool" . >>>>> And Sr. Engineering Manager in Oracle said he use the essence of >>>>> my patch in one >>>>> of the jcmd subcommands. >>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274.html >>>>> >>>>> >>>>> 2 years ago, I posted a patch for this RFE. >>>>> But this patch is too old to apply for current HotSpot. >>>>> >>>>> In last month, a similar discussion was appeared in ML. >>>>> So I think it's time to discuss this RFE. >>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.html >>>>> >>>>> >>>>> >>>>> Please cooperate. >>>>> >>>>> Best regards, >>>>> Yasumasa >>>> >>> >> > From yasu at ysfactory.dip.jp Fri Jan 24 15:49:39 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Sat, 25 Jan 2014 08:49:39 +0900 Subject: JDK-7090324: gclog rotation via external tool In-Reply-To: <52E2F1F4.5020003@oracle.com> References: <52483BDB.8040206@ysfactory.dip.jp> <52496A21.8080608@ysfactory.dip.jp> <527CDD56.7080106@ysfactory.dip.jp> <52A09642.4030609@ysfactory.dip.jp> <52E26FA2.40909@ysfactory.dip.jp> <52E2F1F4.5020003@oracle.com> Message-ID: <52E2FC13.4040105@ysfactory.dip.jp> Hi Yumin, Thank you so much! Yasumasa On 2014/01/25 8:06, Yumin Qi wrote: > Yasumasa, > > I can sponsor this for you --- will start from next week. > > Thanks > Yumin > > On 1/24/2014 5:50 AM, Yasumasa Suenaga wrote: >> Hi all, >> >> I've created webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ >> >> This patch works fine on current jdk9/hs-rt . >> Could you review this? >> >> >> I am just an Author. So I need a sponsor. >> Could you help me? >> >> >> Please cooperate. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2013/12/06 0:05, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Did someone read my email? >>> I really hope to merge "JDK-7090324: gclog rotation via external tool" . >>> >>> I hear that someone need this RFE. So I want to discuss about this. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> On 2013/11/08 21:47, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Did someone read my mail? >>>> >>>> I think that this RFE helps us to watch Java heap on production system. >>>> Also I think this RFE is able to be part of the JEP 158 (Unified JVM Logging) . >>>> >>>> I want to update this RFE in JDK Bug System, but I don't have account. >>>> So I've posted email at first. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2013/09/30 21:10, Yasumasa Suenaga wrote: >>>>> In previous email, I've attached new patch for this RFE. >>>>> It works fine with current hsx. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> On 2013/09/29 23:40, Yasu wrote: >>>>>> Hi all, >>>>>> >>>>>> We are using "logrotate" tool on RHEL for various log rotation. >>>>>> Current HotSpot has gclog rotation function for log size base, >>>>>> however I need to rotate gc log synchronizing with logrotate tool. >>>>>> >>>>>> So I've created RFE as "JDK-7090324: gclog rotation via external tool" . >>>>>> And Sr. Engineering Manager in Oracle said he use the essence of my patch in one >>>>>> of the jcmd subcommands. >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274.html >>>>>> >>>>>> 2 years ago, I posted a patch for this RFE. >>>>>> But this patch is too old to apply for current HotSpot. >>>>>> >>>>>> In last month, a similar discussion was appeared in ML. >>>>>> So I think it's time to discuss this RFE. >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.html >>>>>> >>>>>> >>>>>> Please cooperate. >>>>>> >>>>>> Best regards, >>>>>> Yasumasa >>>>> >>>> >>> >> > From weijun.wang at oracle.com Sat Jan 25 05:32:19 2014 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 25 Jan 2014 13:32:19 +0000 Subject: hg: jdk8/tl/jdk: 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed Message-ID: <20140125133414.AA45C62795@hg.openjdk.java.net> Changeset: 4d891c8db5c1 Author: weijun Date: 2014-01-21 12:08 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d891c8db5c1 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed Reviewed-by: mullan ! src/share/classes/java/util/jar/JarFile.java + test/sun/security/tools/jarsigner/EntriesOrder.java From alan.bateman at oracle.com Sat Jan 25 12:05:49 2014 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 25 Jan 2014 20:05:49 +0000 Subject: hg: jdk8/tl/jdk: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X Message-ID: <20140125200603.4D4F962798@hg.openjdk.java.net> Changeset: b56ff7d30a72 Author: alanb Date: 2014-01-24 11:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b56ff7d30a72 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X Reviewed-by: sla, chegar, psandoz ! src/solaris/native/common/jni_util_md.c From jaroslav.bachorik at oracle.com Mon Jan 27 01:17:21 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 27 Jan 2014 10:17:21 +0100 Subject: [PING] Re: RFR 8031701: java/lang/management/ThreadMXBean/Locks.java: Thread WaitingThread is expected to wait on Object but got null Thread.State = RUNNABLE In-Reply-To: <52DE975B.4090802@oracle.com> References: <52DE975B.4090802@oracle.com> Message-ID: <52E62421.2050207@oracle.com> On 21.1.2014 16:50, Jaroslav Bachorik wrote: > Please, review the following test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031701 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031701/webrev.00 > > The ThreadExecutionSynchronizer was replaced by Phaser - this should > give more predictable results. > Also, "checkBlockedObject()" failed to re-retrieve the ThreadInfo while > waiting for the thread to become blocked. This would lead to timing out > the test and producing the error message used as the issue subject. The > fix for this is at L78-79 > > Thanks, > > -JB- From dmitry.samersoff at oracle.com Mon Jan 27 01:34:53 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Jan 2014 13:34:53 +0400 Subject: RFR 8031701: java/lang/management/ThreadMXBean/Locks.java: Thread WaitingThread is expected to wait on Object but got null Thread.State = RUNNABLE In-Reply-To: <52DE975B.4090802@oracle.com> References: <52DE975B.4090802@oracle.com> Message-ID: <52E6283D.9070106@oracle.com> Jaroslav, Looks good for me. -Dmitry On 2014-01-21 19:50, Jaroslav Bachorik wrote: > Please, review the following test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031701 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031701/webrev.00 > > The ThreadExecutionSynchronizer was replaced by Phaser - this should > give more predictable results. > Also, "checkBlockedObject()" failed to re-retrieve the ThreadInfo while > waiting for the thread to become blocked. This would lead to timing out > the test and producing the error message used as the issue subject. The > fix for this is at L78-79 > > Thanks, > > -JB- -- 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 Sunny.Chan at gs.com Mon Jan 27 03:44:31 2014 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Mon, 27 Jan 2014 19:44:31 +0800 Subject: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running In-Reply-To: <82EAB712-F453-4048-A9AB-1A42EE258102@oracle.com> References: <1CF6FDFD0639DF478B44651D79ECE7049BCE8691@GSCMHKP12EX.firmwide.corp.gs.com> <1CF6FDFD0639DF478B44651D79ECE7049BCE89FB@GSCMHKP12EX.firmwide.corp.gs.com> <82EAB712-F453-4048-A9AB-1A42EE258102@oracle.com> Message-ID: <1CF6FDFD0639DF478B44651D79ECE7049EF3E217@GSCMHKP12EX.firmwide.corp.gs.com> Hi Staffan, I have attached the new version of the patch - I have reworked the test case and now it is mostly based in Java, but I have decided to keep using the shell script to build the Agent Jar file as it is easier. Thanks. From: Staffan Larsen [mailto:staffan.larsen at oracle.com] Sent: 13 January 2014 12:37 To: Chan, Sunny [Tech] Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running On 8 jan 2014, at 16:48, Chan, Sunny > wrote: In terms of the bug fix itself does it look fine? Yes, it does. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140127/50651228/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 7142035rev1.patch Type: application/octet-stream Size: 9451 bytes Desc: 7142035rev1.patch Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140127/50651228/7142035rev1.patch From staffan.larsen at oracle.com Mon Jan 27 05:18:29 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 27 Jan 2014 14:18:29 +0100 Subject: RR(S): JDK-7010732 SA_ALTROOT only works if running the SA tools from their build directory. In-Reply-To: <52DBA2F8.30600@oracle.com> References: <52DBA2F8.30600@oracle.com> Message-ID: <8BA891EB-471F-4D42-9F5A-073574C94104@oracle.com> I wasn?t aware that these makefiles and utilities were still around, much less in use. We really should consolidate them into the main hotspot makefiles. Anyway, changes look fine. /Staffan On 19 jan 2014, at 11:03, Dmitry Samersoff wrote: > Hi Everyone, > > Please review small SA fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-7010732/webrev.01/ > > Notice, new build system doesn't build libsaproc_audit.so so the fix > affects old-style usage only. > > -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 dmitry.samersoff at oracle.com Mon Jan 27 05:36:37 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Jan 2014 17:36:37 +0400 Subject: RR(S): JDK-7010732 SA_ALTROOT only works if running the SA tools from their build directory. In-Reply-To: <8BA891EB-471F-4D42-9F5A-073574C94104@oracle.com> References: <52DBA2F8.30600@oracle.com> <8BA891EB-471F-4D42-9F5A-073574C94104@oracle.com> Message-ID: <52E660E5.9080007@oracle.com> Staffan, I had no ideas what libsaproc_audit is for, code at hotspot/agent/src/os/solaris/proc/saproc_audit.cpp didn't get me a clue. new build system doesn't build it and it seems like everything works fine. -Dmitry On 2014-01-27 17:18, Staffan Larsen wrote: > I wasn?t aware that these makefiles and utilities were still around, > much less in use. We really should consolidate them into the main > hotspot makefiles. > > Anyway, changes look fine. > > /Staffan > > On 19 jan 2014, at 11:03, Dmitry Samersoff > wrote: > >> Hi Everyone, >> >> Please review small SA fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-7010732/webrev.01/ >> >> Notice, new build system doesn't build libsaproc_audit.so so the >> fix affects old-style usage only. >> >> -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. > -- 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 staffan.larsen at oracle.com Mon Jan 27 05:38:00 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 27 Jan 2014 14:38:00 +0100 Subject: RR(S): JDK-7127191 SA JSDB does not display native symbols correctly for transported Linux cores In-Reply-To: <52DD4822.7080301@oracle.com> References: <52DD4822.7080301@oracle.com> Message-ID: <1F3B80DA-C652-41F4-A1AC-254A35712C2C@oracle.com> Dmitry, agent/src/os/linux/libproc_impl.c line 35: it would be good to initialize alt_root to something for clarity. line 41-46: it looks like this will cause getenv() to be called for every call to pathmap_open if SA_ALTROOT is set. Perhaps better to add an alt_root_initialized variable instead of trying to reuse the alt_root variable for two purposes. nit: there are some missing spaces after commas and after ?while? line 55: nit: extra space at beginning of line line 53: rename ptr to alt_path_end? agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java line 69: shouldn?t the second part of the condition be pc.lessThan(base.addOffsetTo(size)) ? agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js no comments Thanks, /Staffan On 20 jan 2014, at 17:00, Dmitry Samersoff wrote: > Hi Everyone, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.01/ > > This fix doesn't solve all problems with symbol lookup in SA, but > address the problem mentioned in bug reports. > > 1. I change algorithm of pathmap_open. Now, it tries to find library > hardly. > > 2. I decided not to fix broken binary search in loadObjectContainingPC, > because with less then 20 DSO's we typically have here performance of > just linear search is approx the same as load, sort, convert to array > and do binary search. > > -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 staffan.larsen at oracle.com Mon Jan 27 05:53:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 27 Jan 2014 14:53:14 +0100 Subject: RR(S): JDK-7010732 SA_ALTROOT only works if running the SA tools from their build directory. In-Reply-To: <52E660E5.9080007@oracle.com> References: <52DBA2F8.30600@oracle.com> <8BA891EB-471F-4D42-9F5A-073574C94104@oracle.com> <52E660E5.9080007@oracle.com> Message-ID: Sounds like we should investigate what it does and potentially remove it completely. /Staffan On 27 jan 2014, at 14:36, Dmitry Samersoff wrote: > Staffan, > > I had no ideas what libsaproc_audit is for, code at > > hotspot/agent/src/os/solaris/proc/saproc_audit.cpp > > didn't get me a clue. > > new build system doesn't build it and it seems like everything works fine. > > -Dmitry > > On 2014-01-27 17:18, Staffan Larsen wrote: >> I wasn?t aware that these makefiles and utilities were still around, >> much less in use. We really should consolidate them into the main >> hotspot makefiles. >> >> Anyway, changes look fine. >> >> /Staffan >> >> On 19 jan 2014, at 11:03, Dmitry Samersoff >> wrote: >> >>> Hi Everyone, >>> >>> Please review small SA fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-7010732/webrev.01/ >>> >>> Notice, new build system doesn't build libsaproc_audit.so so the >>> fix affects old-style usage only. >>> >>> -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. >> > > > -- > 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 Mon Jan 27 06:02:17 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Jan 2014 18:02:17 +0400 Subject: RR(S): JDK-7127191 SA JSDB does not display native symbols correctly for transported Linux cores In-Reply-To: <1F3B80DA-C652-41F4-A1AC-254A35712C2C@oracle.com> References: <52DD4822.7080301@oracle.com> <1F3B80DA-C652-41F4-A1AC-254A35712C2C@oracle.com> Message-ID: <52E666E9.1010103@oracle.com> Staffan, Thank you for review. Comments addressed. http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.02/ -Dmitry On 2014-01-27 17:38, Staffan Larsen wrote: > Dmitry, > > agent/src/os/linux/libproc_impl.c > line 35: it would be good to initialize alt_root to something for clarity. > line 41-46: it looks like this will cause getenv() to be called for every call to pathmap_open if SA_ALTROOT is set. Perhaps better to add an alt_root_initialized variable instead of trying to reuse the alt_root variable for two purposes. > nit: there are some missing spaces after commas and after ?while? > line 55: nit: extra space at beginning of line > line 53: rename ptr to alt_path_end? > > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java > line 69: shouldn?t the second part of the condition be pc.lessThan(base.addOffsetTo(size)) ? > > agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js > no comments > > Thanks, > /Staffan > > On 20 jan 2014, at 17:00, Dmitry Samersoff wrote: > >> Hi Everyone, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.01/ >> >> This fix doesn't solve all problems with symbol lookup in SA, but >> address the problem mentioned in bug reports. >> >> 1. I change algorithm of pathmap_open. Now, it tries to find library >> hardly. >> >> 2. I decided not to fix broken binary search in loadObjectContainingPC, >> because with less then 20 DSO's we typically have here performance of >> just linear search is approx the same as load, sort, convert to array >> and do binary search. >> >> -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. > -- 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 Mon Jan 27 06:13:31 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Jan 2014 18:13:31 +0400 Subject: RR(S): JDK-7010732 SA_ALTROOT only works if running the SA tools from their build directory. In-Reply-To: References: <52DBA2F8.30600@oracle.com> <8BA891EB-471F-4D42-9F5A-073574C94104@oracle.com> <52E660E5.9080007@oracle.com> Message-ID: <52E6698B.8090109@oracle.com> Staffan, On 2014-01-27 17:53, Staffan Larsen wrote: > Sounds like we should investigate what it does and potentially remove it completely. Agree. I'll file a bug. -Dmitry > > /Staffan > > On 27 jan 2014, at 14:36, Dmitry Samersoff wrote: > >> Staffan, >> >> I had no ideas what libsaproc_audit is for, code at >> >> hotspot/agent/src/os/solaris/proc/saproc_audit.cpp >> >> didn't get me a clue. >> >> new build system doesn't build it and it seems like everything works fine. >> >> -Dmitry >> >> On 2014-01-27 17:18, Staffan Larsen wrote: >>> I wasn?t aware that these makefiles and utilities were still around, >>> much less in use. We really should consolidate them into the main >>> hotspot makefiles. >>> >>> Anyway, changes look fine. >>> >>> /Staffan >>> >>> On 19 jan 2014, at 11:03, Dmitry Samersoff >>> wrote: >>> >>>> Hi Everyone, >>>> >>>> Please review small SA fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-7010732/webrev.01/ >>>> >>>> Notice, new build system doesn't build libsaproc_audit.so so the >>>> fix affects old-style usage only. >>>> >>>> -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. >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- 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 staffan.larsen at oracle.com Mon Jan 27 06:33:08 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 27 Jan 2014 15:33:08 +0100 Subject: RR(S): JDK-7127191 SA JSDB does not display native symbols correctly for transported Linux cores In-Reply-To: <52E666E9.1010103@oracle.com> References: <52DD4822.7080301@oracle.com> <1F3B80DA-C652-41F4-A1AC-254A35712C2C@oracle.com> <52E666E9.1010103@oracle.com> Message-ID: Looks good! 43 alt_root_initialized = -1; I would have expect 1 instead of -1. But both work. /Staffan On 27 jan 2014, at 15:02, Dmitry Samersoff wrote: > Staffan, > > Thank you for review. Comments addressed. > > http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.02/ > > -Dmitry > > On 2014-01-27 17:38, Staffan Larsen wrote: >> Dmitry, >> >> agent/src/os/linux/libproc_impl.c >> line 35: it would be good to initialize alt_root to something for clarity. >> line 41-46: it looks like this will cause getenv() to be called for every call to pathmap_open if SA_ALTROOT is set. Perhaps better to add an alt_root_initialized variable instead of trying to reuse the alt_root variable for two purposes. >> nit: there are some missing spaces after commas and after ?while? >> line 55: nit: extra space at beginning of line >> line 53: rename ptr to alt_path_end? >> >> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java >> line 69: shouldn?t the second part of the condition be pc.lessThan(base.addOffsetTo(size)) ? >> >> agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js >> no comments >> >> Thanks, >> /Staffan >> >> On 20 jan 2014, at 17:00, Dmitry Samersoff wrote: >> >>> Hi Everyone, >>> >>> Please review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.01/ >>> >>> This fix doesn't solve all problems with symbol lookup in SA, but >>> address the problem mentioned in bug reports. >>> >>> 1. I change algorithm of pathmap_open. Now, it tries to find library >>> hardly. >>> >>> 2. I decided not to fix broken binary search in loadObjectContainingPC, >>> because with less then 20 DSO's we typically have here performance of >>> just linear search is approx the same as load, sort, convert to array >>> and do binary search. >>> >>> -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. >> > > > -- > 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 kevin.walls at oracle.com Mon Jan 27 07:45:37 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 27 Jan 2014 15:45:37 +0000 Subject: RR(S): JDK-7010732 SA_ALTROOT only works if running the SA tools from their build directory. In-Reply-To: <52E660E5.9080007@oracle.com> References: <52DBA2F8.30600@oracle.com> <8BA891EB-471F-4D42-9F5A-073574C94104@oracle.com> <52E660E5.9080007@oracle.com> Message-ID: <52E67F21.60508@oracle.com> Hi, Yes, change looks good I think. (I was just pleasantly surprised that SA_ALTROOT is respected by the product build where libsaproc_audit does not exist. But libsaproc_open is the open routine that respects the alt_root, and it needs to get called by libproc in order to fixup paths for a transported core file, but I can't immediately see the magic link that makes that happen, when the the audit library isn't there...) Thanks Kevin On 27/01/14 13:36, Dmitry Samersoff wrote: > Staffan, > > I had no ideas what libsaproc_audit is for, code at > > hotspot/agent/src/os/solaris/proc/saproc_audit.cpp > > didn't get me a clue. > > new build system doesn't build it and it seems like everything works fine. > > -Dmitry > > On 2014-01-27 17:18, Staffan Larsen wrote: >> I wasn?t aware that these makefiles and utilities were still around, >> much less in use. We really should consolidate them into the main >> hotspot makefiles. >> >> Anyway, changes look fine. >> >> /Staffan >> >> On 19 jan 2014, at 11:03, Dmitry Samersoff >> wrote: >> >>> Hi Everyone, >>> >>> Please review small SA fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-7010732/webrev.01/ >>> >>> Notice, new build system doesn't build libsaproc_audit.so so the >>> fix affects old-style usage only. >>> >>> -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 staffan.larsen at oracle.com Mon Jan 27 08:14:17 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 27 Jan 2014 17:14:17 +0100 Subject: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running In-Reply-To: <1CF6FDFD0639DF478B44651D79ECE7049EF3E217@GSCMHKP12EX.firmwide.corp.gs.com> References: <1CF6FDFD0639DF478B44651D79ECE7049BCE8691@GSCMHKP12EX.firmwide.corp.gs.com> <1CF6FDFD0639DF478B44651D79ECE7049BCE89FB@GSCMHKP12EX.firmwide.corp.gs.com> <82EAB712-F453-4048-A9AB-1A42EE258102@oracle.com> <1CF6FDFD0639DF478B44651D79ECE7049EF3E217@GSCMHKP12EX.firmwide.corp.gs.com> Message-ID: Hi Sunny, This looks good! - I?d like to avoid bug ids in the names of tests, so can you change the directory name to say ?DaemonThread?? - The test takes quite a long time to run (~1 minute). I wonder if we should shorten that by either starting less processes (currently 50) or letting each process run for a shorter period (currently ~1 sec). - I think we can reduce the noise by removing the System.out.println() output from the DummyAgent. - During one of my test runs I ran into the following failure: *** java.lang.instrument ASSERTION FAILED ***: "error == JVMTI_ERROR_NONE" at Reentrancy.c line: 133 It looks like the patch isn?t complete. I added the patch below and have not seen a failure after that. Can you incorporate that change as well (if you agree with it)? Thanks, /Staffan --- a/src/share/instrument/Reentrancy.c +++ b/src/share/instrument/Reentrancy.c @@ -130,6 +130,7 @@ error = confirmingTLSSet ( jvmtienv, thread, JPLIS_CURRENTLY_INSIDE_TOKEN); + check_phase_ret_false(error); jplis_assert(error == JVMTI_ERROR_NONE); if ( error != JVMTI_ERROR_NONE ) { result = JNI_FALSE; On 27 jan 2014, at 12:44, Chan, Sunny wrote: > Hi Staffan, > > I have attached the new version of the patch - I have reworked the test case and now it is mostly based in Java, but I have decided to keep using the shell script to build the Agent Jar file as it is easier. > > Thanks. > > From: Staffan Larsen [mailto:staffan.larsen at oracle.com] > Sent: 13 January 2014 12:37 > To: Chan, Sunny [Tech] > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > Subject: Re: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running > > > On 8 jan 2014, at 16:48, Chan, Sunny wrote: > > > In terms of the bug fix itself does it look fine? > > Yes, it does. > > Thanks, > /Staffan > <7142035rev1.patch> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140127/78532c1a/attachment.html From dmitry.samersoff at oracle.com Mon Jan 27 09:12:44 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Jan 2014 21:12:44 +0400 Subject: RR(S): JDK-7010732 SA_ALTROOT only works if running the SA tools from their build directory. In-Reply-To: <52E67F21.60508@oracle.com> References: <52DBA2F8.30600@oracle.com> <8BA891EB-471F-4D42-9F5A-073574C94104@oracle.com> <52E660E5.9080007@oracle.com> <52E67F21.60508@oracle.com> Message-ID: <52E6938C.4070609@oracle.com> Kevin, Thank you! (see also below) On 2014-01-27 19:45, Kevin Walls wrote: > Hi, > > Yes, change looks good I think. > > (I was just pleasantly surprised that SA_ALTROOT is respected by the > product build where libsaproc_audit does not exist. But libsaproc_open > is the open routine that respects the alt_root, and it needs to get > called by libproc in order to fixup paths for a transported core file, > but I can't immediately see the magic link that makes that happen, when > the the audit library isn't there...) I still doesn't understand the reason to hooking-in into libc/libproc. Path to SO-lib is important when we are remapping truncated core segments and when looking for symbols. I have no ideas what else is involved on Solaris. -Dmitry > > Thanks > Kevin > > > > > > > On 27/01/14 13:36, Dmitry Samersoff wrote: >> Staffan, >> >> I had no ideas what libsaproc_audit is for, code at >> >> hotspot/agent/src/os/solaris/proc/saproc_audit.cpp >> >> didn't get me a clue. >> >> new build system doesn't build it and it seems like everything works >> fine. >> >> -Dmitry >> >> On 2014-01-27 17:18, Staffan Larsen wrote: >>> I wasn?t aware that these makefiles and utilities were still around, >>> much less in use. We really should consolidate them into the main >>> hotspot makefiles. >>> >>> Anyway, changes look fine. >>> >>> /Staffan >>> >>> On 19 jan 2014, at 11:03, Dmitry Samersoff >>> wrote: >>> >>>> Hi Everyone, >>>> >>>> Please review small SA fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-7010732/webrev.01/ >>>> >>>> Notice, new build system doesn't build libsaproc_audit.so so the >>>> fix affects old-style usage only. >>>> >>>> -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. >> > -- 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 jesper.wilhelmsson at oracle.com Mon Jan 27 12:46:01 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 27 Jan 2014 21:46:01 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52DF9B96.8050901@oracle.com> References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> <52DF9B96.8050901@oracle.com> Message-ID: <52E6C589.9030007@oracle.com> Staffan, Bengt, Mikael, Thanks for the reviews! I have made the changes you have suggested and a new webrev is available at: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ I agree with your assessment that it would be good to implement a generic way to verify manageable flags. I think it is a separate change though so I will not attack that problem in this change. As Mikael wrote in his review we have talked offline about the changes and how to make them more correct and readable. Thanks Mikael for the input! More comments inline. Bengt Rutisson skrev 22/1/14 11:21 AM: > > Hi Jesper, > > The calculation in PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() > looks wrong to me. I would have expected this: > > 86 // free = (live*ratio) / (1-ratio) > 87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() * > mhfr_as_percent) / (1.0 - mhfr_as_percent)); > > to be something like this: > > size_t max_free = heap->old_gen()->capacity_in_bytes() * mhfr_as_percent; The suggested formula above will calculate how much free memory there can be based on the current old gen size. What I want to achieve in the code is to calculate how much free memory there can be based on the amount of live data in the old generation. I have talked to Bengt offline and he agrees that the code is doing what I want it to. I have rewritten the code and added more comments to explain the formula. > (A minor naming thing is that mhfr_as_percent is actually not a percent but a > ratio or fraction. Just like you write in the comment.) Right. Fixed. > We also don't seem to take MinHeapFreeRatio into account. Should we do that? We should. Good catch! I have added support for MinHeapFreeRatio both here and in psScavenge.cpp. > I think it should be possible to write a internal VM test or a whitebox test for > the calculated_old_free_size_in_bytes() to verify that it produces the correct > results. I've added an internal test to verify the new code. > Speaking of testing. There is already a test called > test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass with the > ParallelGC already before your changes. I think that means that the test is not > strict enough. Could you update that test or add a new test to make sure that > your changes are tested? TestHeapFreeRatio only verifies that the VM gives correct error messages for the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain about flags that don't affect the chosen GC, there is no error given about ParallelGC not implementing the heap ratio flags. The code I change is not tested by this test. Dmitry Fazunenko has developed a test for the new feature which I have used while developing. This test will be pushed once the feature is in place. > I also agree with Staffan that the methods is_within() and is_min() make it > harder to read the code. Yes, me to... I removed them. Thanks, /Jesper > > Thanks, > Bengt > > > > On 2014-01-22 09:40, Staffan Larsen wrote: >> Jesper, >> >> This looks ok from a serviceability perspective. Long term we should probably >> have a more pluggable way to verify values of manageable flags so we can avoid >> some of the duplication. >> >> I have a slight problem with is_within() and is_min() in that it is not >> obvious from the call site if the min and max values are inclusive or not - it >> was very obvious before. >> >> /Staffan >> >> >> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >> wrote: >> >>> Hi, >>> >>> Could I have a few reviews of this change? >>> >>> Summary: >>> To allow applications a more fine grained control over the GC over time, >>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. >>> >>> The initial request that lead up to this change involved ParallelGC which is >>> notoriously unwilling to shrink the heap. Since ParallelGC didn't support the >>> heap free ratio flags, this change also includes implementing support for >>> these flags in ParallelGC. >>> >>> Changes have also been made to the argument parsing, attach listener and the >>> management API to verify the flag values when set through the different >>> interfaces. >>> >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>> >>> The plan is to push this to 9 and then backport to 8 and 7. >>> >>> Thanks! >>> /Jesper > From staffan.larsen at oracle.com Mon Jan 27 23:09:32 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 Jan 2014 08:09:32 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52E6C589.9030007@oracle.com> References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> Message-ID: Looks good from my point of view. /Staffan On 27 jan 2014, at 21:46, Jesper Wilhelmsson wrote: > Staffan, Bengt, Mikael, > > Thanks for the reviews! > > I have made the changes you have suggested and a new webrev is available at: > > http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ > > I agree with your assessment that it would be good to implement a generic way to verify manageable flags. I think it is a separate change though so I will not attack that problem in this change. > > As Mikael wrote in his review we have talked offline about the changes and how to make them more correct and readable. Thanks Mikael for the input! > > More comments inline. > > Bengt Rutisson skrev 22/1/14 11:21 AM: >> >> Hi Jesper, >> >> The calculation in PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() >> looks wrong to me. I would have expected this: >> >> 86 // free = (live*ratio) / (1-ratio) >> 87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() * >> mhfr_as_percent) / (1.0 - mhfr_as_percent)); >> >> to be something like this: >> >> size_t max_free = heap->old_gen()->capacity_in_bytes() * mhfr_as_percent; > > The suggested formula above will calculate how much free memory there can be based on the current old gen size. What I want to achieve in the code is to calculate how much free memory there can be based on the amount of live data in the old generation. I have talked to Bengt offline and he agrees that the code is doing what I want it to. I have rewritten the code and added more comments to explain the formula. > >> (A minor naming thing is that mhfr_as_percent is actually not a percent but a >> ratio or fraction. Just like you write in the comment.) > > Right. Fixed. > >> We also don't seem to take MinHeapFreeRatio into account. Should we do that? > > We should. Good catch! I have added support for MinHeapFreeRatio both here and in psScavenge.cpp. > >> I think it should be possible to write a internal VM test or a whitebox test for >> the calculated_old_free_size_in_bytes() to verify that it produces the correct >> results. > > I've added an internal test to verify the new code. > >> Speaking of testing. There is already a test called >> test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass with the >> ParallelGC already before your changes. I think that means that the test is not >> strict enough. Could you update that test or add a new test to make sure that >> your changes are tested? > > TestHeapFreeRatio only verifies that the VM gives correct error messages for the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain about flags that don't affect the chosen GC, there is no error given about ParallelGC not implementing the heap ratio flags. The code I change is not tested by this test. Dmitry Fazunenko has developed a test for the new feature which I have used while developing. This test will be pushed once the feature is in place. > >> I also agree with Staffan that the methods is_within() and is_min() make it >> harder to read the code. > > Yes, me to... > I removed them. > > Thanks, > /Jesper > > >> >> Thanks, >> Bengt >> >> >> >> On 2014-01-22 09:40, Staffan Larsen wrote: >>> Jesper, >>> >>> This looks ok from a serviceability perspective. Long term we should probably >>> have a more pluggable way to verify values of manageable flags so we can avoid >>> some of the duplication. >>> >>> I have a slight problem with is_within() and is_min() in that it is not >>> obvious from the call site if the min and max values are inclusive or not - it >>> was very obvious before. >>> >>> /Staffan >>> >>> >>> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >>> wrote: >>> >>>> Hi, >>>> >>>> Could I have a few reviews of this change? >>>> >>>> Summary: >>>> To allow applications a more fine grained control over the GC over time, >>>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. >>>> >>>> The initial request that lead up to this change involved ParallelGC which is >>>> notoriously unwilling to shrink the heap. Since ParallelGC didn't support the >>>> heap free ratio flags, this change also includes implementing support for >>>> these flags in ParallelGC. >>>> >>>> Changes have also been made to the argument parsing, attach listener and the >>>> management API to verify the flag values when set through the different >>>> interfaces. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>>> >>>> The plan is to push this to 9 and then backport to 8 and 7. >>>> >>>> Thanks! >>>> /Jesper -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140128/ea594fed/attachment.html From staffan.larsen at oracle.com Tue Jan 28 00:52:04 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 Jan 2014 09:52:04 +0100 Subject: RFR(M): 8032462 Change the linux SDT implementation to use USDT2 instead of USDT1 In-Reply-To: <64224E80-D3F3-45ED-913C-A1883B18E4AB@oracle.com> References: <64224E80-D3F3-45ED-913C-A1883B18E4AB@oracle.com> Message-ID: Still looking for reviewers for this change. Thanks, /Staffan On 23 jan 2014, at 08:36, Staffan Larsen wrote: > The only usage today of the DTrace macros under the USDT1 define is the SDT provider on linux. This can be changed to use the USDT2 style by preprocessing the .d files into .h files with the dtrace utility in the same way as we do on solaris and OS X. > > I have also moved the provider definition files (hotspot.d, hotspot_jni.d and hs_private.d) to a common directory instead of having one identical copy per platform. > > I would really like to have a review from somebody on the IcedTea team since I haven?t been able to fully verify this change by running systemtap. > > Once this change is done, we can proceed to remove the USDT1 style macros. > > webrev: http://cr.openjdk.java.net/~sla/8032462/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8032462 > > testing: vm.dtrace.testlist in nsk > > Thanks, > /Staffan From bengt.rutisson at oracle.com Tue Jan 28 05:02:01 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 28 Jan 2014 14:02:01 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52E6C589.9030007@oracle.com> References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> Message-ID: <52E7AA49.7000808@oracle.com> Hi Jesper, On 2014-01-27 21:46, Jesper Wilhelmsson wrote: > Staffan, Bengt, Mikael, > > Thanks for the reviews! > > I have made the changes you have suggested and a new webrev is > available at: > > http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ Can you explain this code in psScavenge.cpp a bit? I am not sure I understand what it wants to achieve and how it works if I have set NewSize and/or MaxNewSize on the command line. 532 size_t max_young_size = young_gen->max_size(); 533 if (MinHeapFreeRatio != 0 || MaxHeapFreeRatio != 100) { 534 max_young_size = MIN2(old_gen->capacity_in_bytes() / NewRatio, young_gen->max_size()); 535 } In arguments.cpp: 1572 if (UseAdaptiveSizePolicy) { 1573 // We don't want to limit adaptive heap sizing's freedom to adjust the heap 1574 // unless the user actually sets these flags. 1575 if (FLAG_IS_DEFAULT(MinHeapFreeRatio)) { 1576 FLAG_SET_DEFAULT(MinHeapFreeRatio, 0); 1577 } 1578 if (FLAG_IS_DEFAULT(MaxHeapFreeRatio)) { 1579 FLAG_SET_DEFAULT(MaxHeapFreeRatio, 100); 1580 } 1581 } Should these be FLAG_SET_ERGO instead? Not sure. Just asking. 3705 if (MinHeapFreeRatio == 100) { 3706 // Keeping the heap 100% free is hard ;-) so limit it to 99%. 3707 FLAG_SET_ERGO(uintx, MinHeapFreeRatio, 99); 3708 } Couldn't this just be part of Arguments::verify_MinHeapFreeRatio()? attachListener.cpp strncmp(name, "MaxHeapFreeRatio", 17) == 0 MaxHeapFreeRatio is 16 characters. Is the 17th character in the constant always NULL and this check verifies that I can write MaxHeapFreeRatioMoreCharacters and get it to pass the strncmp? It would be nice with a JTreg test that sets the flags to valid and invalid values and checks that the flags have the right values after this. Did you have a look at the test/gc/arguments/TestHeapFreeRatio.java test? Is that relevant to verify your changes? Thanks, Bengt > > I agree with your assessment that it would be good to implement a > generic way to verify manageable flags. I think it is a separate > change though so I will not attack that problem in this change. > > As Mikael wrote in his review we have talked offline about the changes > and how to make them more correct and readable. Thanks Mikael for the > input! > > More comments inline. > > Bengt Rutisson skrev 22/1/14 11:21 AM: >> >> Hi Jesper, >> >> The calculation in >> PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() >> looks wrong to me. I would have expected this: >> >> 86 // free = (live*ratio) / (1-ratio) >> 87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() * >> mhfr_as_percent) / (1.0 - mhfr_as_percent)); >> >> to be something like this: >> >> size_t max_free = heap->old_gen()->capacity_in_bytes() * >> mhfr_as_percent; > > The suggested formula above will calculate how much free memory there > can be based on the current old gen size. What I want to achieve in > the code is to calculate how much free memory there can be based on > the amount of live data in the old generation. I have talked to Bengt > offline and he agrees that the code is doing what I want it to. I have > rewritten the code and added more comments to explain the formula. > >> (A minor naming thing is that mhfr_as_percent is actually not a >> percent but a >> ratio or fraction. Just like you write in the comment.) > > Right. Fixed. > >> We also don't seem to take MinHeapFreeRatio into account. Should we >> do that? > > We should. Good catch! I have added support for MinHeapFreeRatio both > here and in psScavenge.cpp. > >> I think it should be possible to write a internal VM test or a >> whitebox test for >> the calculated_old_free_size_in_bytes() to verify that it produces >> the correct >> results. > > I've added an internal test to verify the new code. > >> Speaking of testing. There is already a test called >> test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass >> with the >> ParallelGC already before your changes. I think that means that the >> test is not >> strict enough. Could you update that test or add a new test to make >> sure that >> your changes are tested? > > TestHeapFreeRatio only verifies that the VM gives correct error > messages for the -Xminf and -Xmaxf flags. Since HotSpot usually don't > complain about flags that don't affect the chosen GC, there is no > error given about ParallelGC not implementing the heap ratio flags. > The code I change is not tested by this test. Dmitry Fazunenko has > developed a test for the new feature which I have used while > developing. This test will be pushed once the feature is in place. > >> I also agree with Staffan that the methods is_within() and is_min() >> make it >> harder to read the code. > > Yes, me to... > I removed them. > > Thanks, > /Jesper > > >> >> Thanks, >> Bengt >> >> >> >> On 2014-01-22 09:40, Staffan Larsen wrote: >>> Jesper, >>> >>> This looks ok from a serviceability perspective. Long term we should >>> probably >>> have a more pluggable way to verify values of manageable flags so we >>> can avoid >>> some of the duplication. >>> >>> I have a slight problem with is_within() and is_min() in that it is not >>> obvious from the call site if the min and max values are inclusive >>> or not - it >>> was very obvious before. >>> >>> /Staffan >>> >>> >>> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >>> >>> wrote: >>> >>>> Hi, >>>> >>>> Could I have a few reviews of this change? >>>> >>>> Summary: >>>> To allow applications a more fine grained control over the GC over >>>> time, >>>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. >>>> >>>> The initial request that lead up to this change involved ParallelGC >>>> which is >>>> notoriously unwilling to shrink the heap. Since ParallelGC didn't >>>> support the >>>> heap free ratio flags, this change also includes implementing >>>> support for >>>> these flags in ParallelGC. >>>> >>>> Changes have also been made to the argument parsing, attach >>>> listener and the >>>> management API to verify the flag values when set through the >>>> different >>>> interfaces. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>>> >>>> The plan is to push this to 9 and then backport to 8 and 7. >>>> >>>> Thanks! >>>> /Jesper >> From eric.mccorkle at oracle.com Tue Jan 28 05:53:05 2014 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 28 Jan 2014 13:53:05 +0000 Subject: hg: jdk8/tl/jdk: 8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package Message-ID: <20140128135328.E3A1662802@hg.openjdk.java.net> Changeset: 56d05f260123 Author: vlivanov Date: 2014-01-28 13:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56d05f260123 8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package Reviewed-by: twisti, jrose ! src/share/classes/sun/invoke/util/VerifyAccess.java + test/java/lang/invoke/ProtectedMemberDifferentPackage/Test.java + test/java/lang/invoke/ProtectedMemberDifferentPackage/p1/T2.java + test/java/lang/invoke/ProtectedMemberDifferentPackage/p2/T3.java From Sunny.Chan at gs.com Tue Jan 28 06:59:24 2014 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Tue, 28 Jan 2014 22:59:24 +0800 Subject: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running In-Reply-To: References: <1CF6FDFD0639DF478B44651D79ECE7049BCE8691@GSCMHKP12EX.firmwide.corp.gs.com> <1CF6FDFD0639DF478B44651D79ECE7049BCE89FB@GSCMHKP12EX.firmwide.corp.gs.com> <82EAB712-F453-4048-A9AB-1A42EE258102@oracle.com> <1CF6FDFD0639DF478B44651D79ECE7049EF3E217@GSCMHKP12EX.firmwide.corp.gs.com> Message-ID: <1CF6FDFD0639DF478B44651D79ECE7049EF3E299@GSCMHKP12EX.firmwide.corp.gs.com> Hi Staffan, I agreed with your assessment and have incorporated your extra change into my patch. I have a couple of test runs and have determined that we can reduce each process period but we will need to repeat at least 50 times to reliably reproduce the issue in unpatched builds. So the intervals is now 200ms instead of 1 second. Let me know if there is anything else need to change. Thanks Sunny From: Staffan Larsen [mailto:staffan.larsen at oracle.com] Sent: 27 January 2014 16:14 To: Chan, Sunny [Tech] Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running Hi Sunny, This looks good! - I'd like to avoid bug ids in the names of tests, so can you change the directory name to say "DaemonThread"? - The test takes quite a long time to run (~1 minute). I wonder if we should shorten that by either starting less processes (currently 50) or letting each process run for a shorter period (currently ~1 sec). - I think we can reduce the noise by removing the System.out.println() output from the DummyAgent. - During one of my test runs I ran into the following failure: *** java.lang.instrument ASSERTION FAILED ***: "error == JVMTI_ERROR_NONE" at Reentrancy.c line: 133 It looks like the patch isn't complete. I added the patch below and have not seen a failure after that. Can you incorporate that change as well (if you agree with it)? Thanks, /Staffan --- a/src/share/instrument/Reentrancy.c +++ b/src/share/instrument/Reentrancy.c @@ -130,6 +130,7 @@ error = confirmingTLSSet ( jvmtienv, thread, JPLIS_CURRENTLY_INSIDE_TOKEN); + check_phase_ret_false(error); jplis_assert(error == JVMTI_ERROR_NONE); if ( error != JVMTI_ERROR_NONE ) { result = JNI_FALSE; On 27 jan 2014, at 12:44, Chan, Sunny > wrote: Hi Staffan, I have attached the new version of the patch - I have reworked the test case and now it is mostly based in Java, but I have decided to keep using the shell script to build the Agent Jar file as it is easier. Thanks. From: Staffan Larsen [mailto:staffan.larsen at oracle.com] Sent: 13 January 2014 12:37 To: Chan, Sunny [Tech] Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running On 8 jan 2014, at 16:48, Chan, Sunny > wrote: In terms of the bug fix itself does it look fine? Yes, it does. Thanks, /Staffan <7142035rev1.patch> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140128/7a7b13ca/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 7142035rev2.patch Type: application/octet-stream Size: 10842 bytes Desc: 7142035rev2.patch Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140128/7a7b13ca/7142035rev2-0001.patch From kmcguigan at twitter.com Tue Jan 28 06:51:03 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Tue, 28 Jan 2014 09:51:03 -0500 Subject: RFR(M): 8032462 Change the linux SDT implementation to use USDT2 instead of USDT1 In-Reply-To: References: <64224E80-D3F3-45ED-913C-A1883B18E4AB@oracle.com> Message-ID: Hi Staffan, It looks ok to me. LInux has a 'dtrace' command now? -- - Keith On Tue, Jan 28, 2014 at 3:52 AM, Staffan Larsen wrote: > Still looking for reviewers for this change. > > Thanks, > /Staffan > > On 23 jan 2014, at 08:36, Staffan Larsen > wrote: > > > The only usage today of the DTrace macros under the USDT1 define is the > SDT provider on linux. This can be changed to use the USDT2 style by > preprocessing the .d files into .h files with the dtrace utility in the > same way as we do on solaris and OS X. > > > > I have also moved the provider definition files (hotspot.d, > hotspot_jni.d and hs_private.d) to a common directory instead of having one > identical copy per platform. > > > > I would really like to have a review from somebody on the IcedTea team > since I haven't been able to fully verify this change by running systemtap. > > > > Once this change is done, we can proceed to remove the USDT1 style > macros. > > > > webrev: http://cr.openjdk.java.net/~sla/8032462/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8032462 > > > > testing: vm.dtrace.testlist in nsk > > > > Thanks, > > /Staffan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140128/09d39e30/attachment.html From staffan.larsen at oracle.com Tue Jan 28 11:02:04 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 Jan 2014 20:02:04 +0100 Subject: RFR(M): 8032462 Change the linux SDT implementation to use USDT2 instead of USDT1 In-Reply-To: References: <64224E80-D3F3-45ED-913C-A1883B18E4AB@oracle.com> Message-ID: <8187EF45-8F21-49D9-80A5-FDF3400125D6@oracle.com> On 28 jan 2014, at 15:51, Keith McGuigan wrote: > Hi Staffan, > > It looks ok to me. Thanks Keith! > LInux has a 'dtrace' command now? Yeah, it?s only there to provide the most basic dtrace compatibility for systemtap. I don?t think it can run dtrace scripts, but it can generate the header files we need. /Staffan > > -- > - Keith > > > On Tue, Jan 28, 2014 at 3:52 AM, Staffan Larsen wrote: > Still looking for reviewers for this change. > > Thanks, > /Staffan > > On 23 jan 2014, at 08:36, Staffan Larsen wrote: > > > The only usage today of the DTrace macros under the USDT1 define is the SDT provider on linux. This can be changed to use the USDT2 style by preprocessing the .d files into .h files with the dtrace utility in the same way as we do on solaris and OS X. > > > > I have also moved the provider definition files (hotspot.d, hotspot_jni.d and hs_private.d) to a common directory instead of having one identical copy per platform. > > > > I would really like to have a review from somebody on the IcedTea team since I haven?t been able to fully verify this change by running systemtap. > > > > Once this change is done, we can proceed to remove the USDT1 style macros. > > > > webrev: http://cr.openjdk.java.net/~sla/8032462/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8032462 > > > > testing: vm.dtrace.testlist in nsk > > > > Thanks, > > /Staffan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140128/126875d6/attachment.html From jeff.dinkins at oracle.com Tue Jan 28 12:40:59 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:40:59 +0000 Subject: hg: jdk8/tl/hotspot: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204101.F2B7262824@hg.openjdk.java.net> Changeset: ce0320cdb075 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce0320cdb075 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:40:07 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:40:07 +0000 Subject: hg: jdk8/tl/corba: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204007.AA92D62823@hg.openjdk.java.net> Changeset: 6d40c0d49c7a Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6d40c0d49c7a 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:41:28 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:41:28 +0000 Subject: hg: jdk8/tl/jaxp: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204131.5EC6762825@hg.openjdk.java.net> Changeset: 60c2c003fa11 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/60c2c003fa11 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:41:46 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:41:46 +0000 Subject: hg: jdk8/tl/jaxws: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204148.F3F7962826@hg.openjdk.java.net> Changeset: 2b44c111e153 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2b44c111e153 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:42:29 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:42:29 +0000 Subject: hg: jdk8/tl/jdk: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204248.3844C62827@hg.openjdk.java.net> Changeset: 72d0cc723560 Author: jeff Date: 2014-01-28 20:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72d0cc723560 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:44:50 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:44:50 +0000 Subject: hg: jdk8/tl/langtools: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204454.0BE4B62828@hg.openjdk.java.net> Changeset: afa91c54ff00 Author: jeff Date: 2014-01-28 20:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/afa91c54ff00 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:45:07 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:45:07 +0000 Subject: hg: jdk8/tl/nashorn: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204508.980F662829@hg.openjdk.java.net> Changeset: d3b293a4d554 Author: jeff Date: 2014-01-28 20:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d3b293a4d554 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From robert.field at oracle.com Tue Jan 28 13:03:07 2014 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 28 Jan 2014 21:03:07 +0000 Subject: hg: jdk8/tl/jdk: 8032711: Issue with Lambda in handling; ... Message-ID: <20140128210319.AFAB66282B@hg.openjdk.java.net> Changeset: c8d9cdc6445c Author: rfield Date: 2014-01-28 13:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8d9cdc6445c 8032711: Issue with Lambda in handling 8032704: Issues with lib perm in Lambda Reviewed-by: jrose, ahgross, briangoetz ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + test/java/lang/invoke/lambda/T8032704.java + test/java/lang/invoke/lambda/T8032711.java From jeff.dinkins at oracle.com Tue Jan 28 12:39:31 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:39:31 +0000 Subject: hg: jdk8/tl: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128203931.DC82E62821@hg.openjdk.java.net> Changeset: 4f590c2cec75 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4f590c2cec75 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jesper.wilhelmsson at oracle.com Tue Jan 28 14:09:07 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 28 Jan 2014 23:09:07 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52E7AA49.7000808@oracle.com> References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> <52E7AA49.7000808@oracle.com> Message-ID: <52E82A83.7070708@oracle.com> Bengt, Thanks for looking at the change. Answers inline. Bengt Rutisson skrev 28/1/14 2:02 PM: > > Hi Jesper, > > On 2014-01-27 21:46, Jesper Wilhelmsson wrote: >> Staffan, Bengt, Mikael, >> >> Thanks for the reviews! >> >> I have made the changes you have suggested and a new webrev is available at: >> >> http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ > > Can you explain this code in psScavenge.cpp a bit? I am not sure I understand > what it wants to achieve and how it works if I have set NewSize and/or > MaxNewSize on the command line. > > 532 size_t max_young_size = young_gen->max_size(); > 533 if (MinHeapFreeRatio != 0 || MaxHeapFreeRatio != 100) { > 534 max_young_size = MIN2(old_gen->capacity_in_bytes() / NewRatio, > young_gen->max_size()); > 535 } The intention of this code is to constrain the young space if someone is using the heap free ratio flags. Since it is a bit weird to talk about a "free ratio" in the young space, we use the heap free ratios to determine the size of the old generation, and then we use NewRatio to scale the young generation accordingly. The use of NewSize and MaxNewSize shouldn't affect this decision at this point. They are mainly used to set the initial sizes and limits for the young generation which will be respected as we use the MIN of the NewRatio calculation and the young_gen->max_size(). This code should however only be executed if using adaptive size policy so I will add that to the if-statement. > In arguments.cpp: > > 1572 if (UseAdaptiveSizePolicy) { > 1573 // We don't want to limit adaptive heap sizing's freedom to adjust the > heap > 1574 // unless the user actually sets these flags. > 1575 if (FLAG_IS_DEFAULT(MinHeapFreeRatio)) { > 1576 FLAG_SET_DEFAULT(MinHeapFreeRatio, 0); > 1577 } > 1578 if (FLAG_IS_DEFAULT(MaxHeapFreeRatio)) { > 1579 FLAG_SET_DEFAULT(MaxHeapFreeRatio, 100); > 1580 } > 1581 } > > Should these be FLAG_SET_ERGO instead? Not sure. Just asking. I went back and forth on this one, but decided that I wanted to express that if using adaptive size policy, the default values of these flags should be different. I think it would work perfectly fine if using FLAG_SET_ERGO instead but I'm thinking that this is not really an ergonomic decision, but rather due to a different implementation. > 3705 if (MinHeapFreeRatio == 100) { > 3706 // Keeping the heap 100% free is hard ;-) so limit it to 99%. > 3707 FLAG_SET_ERGO(uintx, MinHeapFreeRatio, 99); > 3708 } > > Couldn't this just be part of Arguments::verify_MinHeapFreeRatio()? This code moved from check_vm_args_consistency() to apply_ergo() since it is a ergonomic decision to change the value of the flag. I don't think this kind of changes should be done while checking argument consistency. verify_MinHeapFreeRatio() is called from check_vm_args_consistency(). > attachListener.cpp > > strncmp(name, "MaxHeapFreeRatio", 17) == 0 > > MaxHeapFreeRatio is 16 characters. Is the 17th character in the constant always > NULL and this check verifies that I can write MaxHeapFreeRatioMoreCharacters and > get it to pass the strncmp? Yes, that's what I want to achieve. (I assume that you mean "can't write MaxHeapFreeRatioMoreCharacters".) > It would be nice with a JTreg test that sets the flags to valid and invalid > values and checks that the flags have the right values after this. Dmitry is working on the tests for this feature. I'll ask him to include a few tests for illegal values as well. > Did you have a look at the test/gc/arguments/TestHeapFreeRatio.java test? Is > that relevant to verify your changes? No, my changes are not tested by TestHeapFreeRatio. I wrote a few lines about why towards the end of my last mail. Thanks, /Jesper > > Thanks, > Bengt > > >> >> I agree with your assessment that it would be good to implement a generic way >> to verify manageable flags. I think it is a separate change though so I will >> not attack that problem in this change. >> >> As Mikael wrote in his review we have talked offline about the changes and how >> to make them more correct and readable. Thanks Mikael for the input! >> >> More comments inline. >> >> Bengt Rutisson skrev 22/1/14 11:21 AM: >>> >>> Hi Jesper, >>> >>> The calculation in PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() >>> looks wrong to me. I would have expected this: >>> >>> 86 // free = (live*ratio) / (1-ratio) >>> 87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() * >>> mhfr_as_percent) / (1.0 - mhfr_as_percent)); >>> >>> to be something like this: >>> >>> size_t max_free = heap->old_gen()->capacity_in_bytes() * mhfr_as_percent; >> >> The suggested formula above will calculate how much free memory there can be >> based on the current old gen size. What I want to achieve in the code is to >> calculate how much free memory there can be based on the amount of live data >> in the old generation. I have talked to Bengt offline and he agrees that the >> code is doing what I want it to. I have rewritten the code and added more >> comments to explain the formula. >> >>> (A minor naming thing is that mhfr_as_percent is actually not a percent but a >>> ratio or fraction. Just like you write in the comment.) >> >> Right. Fixed. >> >>> We also don't seem to take MinHeapFreeRatio into account. Should we do that? >> >> We should. Good catch! I have added support for MinHeapFreeRatio both here and >> in psScavenge.cpp. >> >>> I think it should be possible to write a internal VM test or a whitebox test for >>> the calculated_old_free_size_in_bytes() to verify that it produces the correct >>> results. >> >> I've added an internal test to verify the new code. >> >>> Speaking of testing. There is already a test called >>> test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass with the >>> ParallelGC already before your changes. I think that means that the test is not >>> strict enough. Could you update that test or add a new test to make sure that >>> your changes are tested? >> >> TestHeapFreeRatio only verifies that the VM gives correct error messages for >> the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain about flags >> that don't affect the chosen GC, there is no error given about ParallelGC not >> implementing the heap ratio flags. The code I change is not tested by this >> test. Dmitry Fazunenko has developed a test for the new feature which I have >> used while developing. This test will be pushed once the feature is in place. >> >>> I also agree with Staffan that the methods is_within() and is_min() make it >>> harder to read the code. >> >> Yes, me to... >> I removed them. >> >> Thanks, >> /Jesper >> >> >>> >>> Thanks, >>> Bengt >>> >>> >>> >>> On 2014-01-22 09:40, Staffan Larsen wrote: >>>> Jesper, >>>> >>>> This looks ok from a serviceability perspective. Long term we should probably >>>> have a more pluggable way to verify values of manageable flags so we can avoid >>>> some of the duplication. >>>> >>>> I have a slight problem with is_within() and is_min() in that it is not >>>> obvious from the call site if the min and max values are inclusive or not - it >>>> was very obvious before. >>>> >>>> /Staffan >>>> >>>> >>>> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Could I have a few reviews of this change? >>>>> >>>>> Summary: >>>>> To allow applications a more fine grained control over the GC over time, >>>>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. >>>>> >>>>> The initial request that lead up to this change involved ParallelGC which is >>>>> notoriously unwilling to shrink the heap. Since ParallelGC didn't support the >>>>> heap free ratio flags, this change also includes implementing support for >>>>> these flags in ParallelGC. >>>>> >>>>> Changes have also been made to the argument parsing, attach listener and the >>>>> management API to verify the flag values when set through the different >>>>> interfaces. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>>>> >>>>> The plan is to push this to 9 and then backport to 8 and 7. >>>>> >>>>> Thanks! >>>>> /Jesper >>> > From jesper.wilhelmsson at oracle.com Tue Jan 28 14:10:07 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 28 Jan 2014 23:10:07 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> Message-ID: <52E82ABF.3030106@oracle.com> Thanks for the review! /Jesper Staffan Larsen skrev 28/1/14 8:09 AM: > Looks good from my point of view. > > /Staffan > > On 27 jan 2014, at 21:46, Jesper Wilhelmsson > wrote: > >> Staffan, Bengt, Mikael, >> >> Thanks for the reviews! >> >> I have made the changes you have suggested and a new webrev is available at: >> >> http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ >> >> I agree with your assessment that it would be good to implement a generic way >> to verify manageable flags. I think it is a separate change though so I will >> not attack that problem in this change. >> >> As Mikael wrote in his review we have talked offline about the changes and how >> to make them more correct and readable. Thanks Mikael for the input! >> >> More comments inline. >> >> Bengt Rutisson skrev 22/1/14 11:21 AM: >>> >>> Hi Jesper, >>> >>> The calculation in PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() >>> looks wrong to me. I would have expected this: >>> >>> 86 // free = (live*ratio) / (1-ratio) >>> 87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() * >>> mhfr_as_percent) / (1.0 - mhfr_as_percent)); >>> >>> to be something like this: >>> >>> size_t max_free = heap->old_gen()->capacity_in_bytes() * mhfr_as_percent; >> >> The suggested formula above will calculate how much free memory there can be >> based on the current old gen size. What I want to achieve in the code is to >> calculate how much free memory there can be based on the amount of live data >> in the old generation. I have talked to Bengt offline and he agrees that the >> code is doing what I want it to. I have rewritten the code and added more >> comments to explain the formula. >> >>> (A minor naming thing is that mhfr_as_percent is actually not a percent but a >>> ratio or fraction. Just like you write in the comment.) >> >> Right. Fixed. >> >>> We also don't seem to take MinHeapFreeRatio into account. Should we do that? >> >> We should. Good catch! I have added support for MinHeapFreeRatio both here and >> in psScavenge.cpp. >> >>> I think it should be possible to write a internal VM test or a whitebox test for >>> the calculated_old_free_size_in_bytes() to verify that it produces the correct >>> results. >> >> I've added an internal test to verify the new code. >> >>> Speaking of testing. There is already a test called >>> test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass with the >>> ParallelGC already before your changes. I think that means that the test is not >>> strict enough. Could you update that test or add a new test to make sure that >>> your changes are tested? >> >> TestHeapFreeRatio only verifies that the VM gives correct error messages for >> the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain about flags >> that don't affect the chosen GC, there is no error given about ParallelGC not >> implementing the heap ratio flags. The code I change is not tested by this >> test. Dmitry Fazunenko has developed a test for the new feature which I have >> used while developing. This test will be pushed once the feature is in place. >> >>> I also agree with Staffan that the methods is_within() and is_min() make it >>> harder to read the code. >> >> Yes, me to... >> I removed them. >> >> Thanks, >> /Jesper >> >> >>> >>> Thanks, >>> Bengt >>> >>> >>> >>> On 2014-01-22 09:40, Staffan Larsen wrote: >>>> Jesper, >>>> >>>> This looks ok from a serviceability perspective. Long term we should probably >>>> have a more pluggable way to verify values of manageable flags so we can avoid >>>> some of the duplication. >>>> >>>> I have a slight problem with is_within() and is_min() in that it is not >>>> obvious from the call site if the min and max values are inclusive or not - it >>>> was very obvious before. >>>> >>>> /Staffan >>>> >>>> >>>> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >>> > >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Could I have a few reviews of this change? >>>>> >>>>> Summary: >>>>> To allow applications a more fine grained control over the GC over time, >>>>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. >>>>> >>>>> The initial request that lead up to this change involved ParallelGC which is >>>>> notoriously unwilling to shrink the heap. Since ParallelGC didn't support the >>>>> heap free ratio flags, this change also includes implementing support for >>>>> these flags in ParallelGC. >>>>> >>>>> Changes have also been made to the argument parsing, attach listener and the >>>>> management API to verify the flag values when set through the different >>>>> interfaces. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>>>> >>>>> The plan is to push this to 9 and then backport to 8 and 7. >>>>> >>>>> Thanks! >>>>> /Jesper > From mandy.chung at oracle.com Tue Jan 28 15:50:28 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 28 Jan 2014 15:50:28 -0800 Subject: RFR 8031701: java/lang/management/ThreadMXBean/Locks.java: Thread WaitingThread is expected to wait on Object but got null Thread.State = RUNNABLE In-Reply-To: <52DE975B.4090802@oracle.com> References: <52DE975B.4090802@oracle.com> Message-ID: <52E84244.5030509@oracle.com> Hi Jaroslav, On 1/21/14 7:50 AM, Jaroslav Bachorik wrote: > Please, review the following test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031701 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031701/webrev.00 > The change looks okay. I like the new assertNoLock method and as you indicate in the comment in L54-55 that the thread state is dummy and not verified, would it worth refactor checkBlockedObject? The comment "// #blocking#1", "// #waiting#1", etc are little confusing - maybe "phase 1", "phase 2", etc? line 279 - leftover comment can be removed. Since you are here, can you add a space after "==" in line 68 "==Thread.State.BLOCKED" thanks Mandy From serguei.spitsyn at oracle.com Tue Jan 28 17:03:35 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jan 2014 17:03:35 -0800 Subject: RFR(M): 8032462 Change the linux SDT implementation to use USDT2 instead of USDT1 In-Reply-To: References: <64224E80-D3F3-45ED-913C-A1883B18E4AB@oracle.com> Message-ID: <52E85367.1050403@oracle.com> Hi Staffan, Sorry for being late, I thought it was already reviewed. :) It looks good, just a minor question below. make/bsd/makefiles/dtrace.make Can this line be removed as it is not used in this file anymore? 55 DTRACE_SRCDIR = $(GAMMADIR)/src/os/$(Platform_os_family)/dtrace Thanks, Serguei On 1/28/14 12:52 AM, Staffan Larsen wrote: > Still looking for reviewers for this change. > > Thanks, > /Staffan > > On 23 jan 2014, at 08:36, Staffan Larsen wrote: > >> The only usage today of the DTrace macros under the USDT1 define is the SDT provider on linux. This can be changed to use the USDT2 style by preprocessing the .d files into .h files with the dtrace utility in the same way as we do on solaris and OS X. >> >> I have also moved the provider definition files (hotspot.d, hotspot_jni.d and hs_private.d) to a common directory instead of having one identical copy per platform. >> >> I would really like to have a review from somebody on the IcedTea team since I haven?t been able to fully verify this change by running systemtap. >> >> Once this change is done, we can proceed to remove the USDT1 style macros. >> >> webrev: http://cr.openjdk.java.net/~sla/8032462/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8032462 >> >> testing: vm.dtrace.testlist in nsk >> >> Thanks, >> /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140128/c3962923/attachment.html From robert.field at oracle.com Tue Jan 28 17:25:00 2014 From: robert.field at oracle.com (robert.field at oracle.com) Date: Wed, 29 Jan 2014 01:25:00 +0000 Subject: hg: jdk8/tl/jdk: 8032697: Issues with Lambda Message-ID: <20140129012512.8FE0E62837@hg.openjdk.java.net> Changeset: e385bd6f7338 Author: rfield Date: 2014-01-28 17:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e385bd6f7338 8032697: Issues with Lambda Reviewed-by: ahgross, briangoetz, dlsmith, rfield Contributed-by: daniel.smith at oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + test/java/lang/invoke/lambda/T8032697.java + test/java/lang/invoke/lambda/T8032697_anotherpkg/T8032697_A.java From staffan.larsen at oracle.com Wed Jan 29 00:28:30 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 29 Jan 2014 09:28:30 +0100 Subject: RFR(M): 8032462 Change the linux SDT implementation to use USDT2 instead of USDT1 In-Reply-To: <52E85367.1050403@oracle.com> References: <64224E80-D3F3-45ED-913C-A1883B18E4AB@oracle.com> <52E85367.1050403@oracle.com> Message-ID: <2A6C3196-9415-4F3B-8E17-9FF2C865C8AE@oracle.com> On 29 jan 2014, at 02:03, serguei.spitsyn at oracle.com wrote: > Hi Staffan, > > Sorry for being late, I thought it was already reviewed. :) > > It looks good, just a minor question below. Thanks! > make/bsd/makefiles/dtrace.make > > Can this line be removed as it is not used in this file anymore? > 55 DTRACE_SRCDIR = $(GAMMADIR)/src/os/$(Platform_os_family)/dtrace It is actually still used. Or actually not. It?s complicated and messy. The bsd makefile has a lot of logic in it that was copied from the solaris makefiles for building jvm_db. But, jvm_db isn't used on OS X (there is no support for ustack helpers) so all that logic is never called from vm.make when building on OS X: ifeq ($(OS_VENDOR), Darwin) # no libjvm_db for macosx build: $(LIBJVM) $(LAUNCHER) $(LIBJSIG) $(BUILDLIBSAPROC) dtraceCheck echo "Doing vm.make build:" else build: $(LIBJVM) $(LAUNCHER) $(LIBJSIG) $(LIBJVM_DB) $(BUILDLIBSAPROC) endif So you might think that it would be built on other BSDs. But it isn?t because the whole jvm_db building stuff in dtrace.make is conditional on only building on OS X: ifeq ($(OS_VENDOR), Darwin) In short: it?s a mess. I didn?t clean this up, but maybe a future change will. Or maybe the hotspot makefile rewrite will. Thanks, /Staffan > > Thanks, > Serguei > > > On 1/28/14 12:52 AM, Staffan Larsen wrote: >> Still looking for reviewers for this change. >> >> Thanks, >> /Staffan >> >> On 23 jan 2014, at 08:36, Staffan Larsen wrote: >> >>> The only usage today of the DTrace macros under the USDT1 define is the SDT provider on linux. This can be changed to use the USDT2 style by preprocessing the .d files into .h files with the dtrace utility in the same way as we do on solaris and OS X. >>> >>> I have also moved the provider definition files (hotspot.d, hotspot_jni.d and hs_private.d) to a common directory instead of having one identical copy per platform. >>> >>> I would really like to have a review from somebody on the IcedTea team since I haven?t been able to fully verify this change by running systemtap. >>> >>> Once this change is done, we can proceed to remove the USDT1 style macros. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8032462/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8032462 >>> >>> testing: vm.dtrace.testlist in nsk >>> >>> Thanks, >>> /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140129/24a3b5b8/attachment-0001.html From serguei.spitsyn at oracle.com Wed Jan 29 01:04:41 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jan 2014 01:04:41 -0800 Subject: RFR(M): 8032462 Change the linux SDT implementation to use USDT2 instead of USDT1 In-Reply-To: <2A6C3196-9415-4F3B-8E17-9FF2C865C8AE@oracle.com> References: <64224E80-D3F3-45ED-913C-A1883B18E4AB@oracle.com> <52E85367.1050403@oracle.com> <2A6C3196-9415-4F3B-8E17-9FF2C865C8AE@oracle.com> Message-ID: <52E8C429.4080405@oracle.com> Ok, thanks! It is Ok that you did not clean this up. The macro can still be used in the future. Thanks, Serguei On 1/29/14 12:28 AM, Staffan Larsen wrote: > > On 29 jan 2014, at 02:03, serguei.spitsyn at oracle.com > wrote: > >> Hi Staffan, >> >> Sorry for being late, I thought it was already reviewed. :) >> >> It looks good, just a minor question below. > > Thanks! > >> make/bsd/makefiles/dtrace.make >> >> Can this line be removed as it is not used in this file anymore? >> 55 DTRACE_SRCDIR = $(GAMMADIR)/src/os/$(Platform_os_family)/dtrace > > It is actually still used. Or actually not. It?s complicated and messy. > > The bsd makefile has a lot of logic in it that was copied from the > solaris makefiles for building jvm_db. But, jvm_db isn't used on OS X > (there is no support for ustack helpers) so all that logic is never > called from vm.make when building on OS X: > > ifeq ($(OS_VENDOR), Darwin) > # no libjvm_db for macosx > build: $(LIBJVM) $(LAUNCHER) $(LIBJSIG) $(BUILDLIBSAPROC) dtraceCheck > echo "Doing vm.make build:" > else > build: $(LIBJVM) $(LAUNCHER) $(LIBJSIG) $(LIBJVM_DB) $(BUILDLIBSAPROC) > endif > > So you might think that it would be built on other BSDs. But it isn?t > because the whole jvm_db building stuff in dtrace.make is conditional > on only building on OS X: > > ifeq ($(OS_VENDOR), Darwin) > > In short: it?s a mess. I didn?t clean this up, but maybe a future > change will. Or maybe the hotspot makefile rewrite will. > > Thanks, > /Staffan > > >> >> Thanks, >> Serguei >> >> >> On 1/28/14 12:52 AM, Staffan Larsen wrote: >>> Still looking for reviewers for this change. >>> >>> Thanks, >>> /Staffan >>> >>> On 23 jan 2014, at 08:36, Staffan Larsen wrote: >>> >>>> The only usage today of the DTrace macros under the USDT1 define is the SDT provider on linux. This can be changed to use the USDT2 style by preprocessing the .d files into .h files with the dtrace utility in the same way as we do on solaris and OS X. >>>> >>>> I have also moved the provider definition files (hotspot.d, hotspot_jni.d and hs_private.d) to a common directory instead of having one identical copy per platform. >>>> >>>> I would really like to have a review from somebody on the IcedTea team since I haven?t been able to fully verify this change by running systemtap. >>>> >>>> Once this change is done, we can proceed to remove the USDT1 style macros. >>>> >>>> webrev:http://cr.openjdk.java.net/~sla/8032462/webrev.00/ >>>> bug:https://bugs.openjdk.java.net/browse/JDK-8032462 >>>> >>>> testing: vm.dtrace.testlist in nsk >>>> >>>> Thanks, >>>> /Staffan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140129/d2578e29/attachment.html From staffan.larsen at oracle.com Wed Jan 29 03:34:40 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 29 Jan 2014 12:34:40 +0100 Subject: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running In-Reply-To: <1CF6FDFD0639DF478B44651D79ECE7049EF3E299@GSCMHKP12EX.firmwide.corp.gs.com> References: <1CF6FDFD0639DF478B44651D79ECE7049BCE8691@GSCMHKP12EX.firmwide.corp.gs.com> <1CF6FDFD0639DF478B44651D79ECE7049BCE89FB@GSCMHKP12EX.firmwide.corp.gs.com> <82EAB712-F453-4048-A9AB-1A42EE258102@oracle.com> <1CF6FDFD0639DF478B44651D79ECE7049EF3E217@GSCMHKP12EX.firmwide.corp.gs.com> <1CF6FDFD0639DF478B44651D79ECE7049EF3E299@GSCMHKP12EX.firmwide.corp.gs.com> Message-ID: <26CA95D5-95E7-447F-81E9-6E2BD7CA2A7F@oracle.com> The patch has been pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/87fdc579dafc Thanks for contributing! /Staffan On 28 jan 2014, at 15:59, Chan, Sunny wrote: > Hi Staffan, > > I agreed with your assessment and have incorporated your extra change into my patch. I have a couple of test runs and have determined that we can reduce each process period but we will need to repeat at least 50 times to reliably reproduce the issue in unpatched builds. So the intervals is now 200ms instead of 1 second. > > Let me know if there is anything else need to change. > > Thanks > Sunny > > From: Staffan Larsen [mailto:staffan.larsen at oracle.com] > Sent: 27 January 2014 16:14 > To: Chan, Sunny [Tech] > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > Subject: Re: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running > > Hi Sunny, > > This looks good! > > - I?d like to avoid bug ids in the names of tests, so can you change the directory name to say ?DaemonThread?? > > - The test takes quite a long time to run (~1 minute). I wonder if we should shorten that by either starting less processes (currently 50) or letting each process run for a shorter period (currently ~1 sec). > > - I think we can reduce the noise by removing the System.out.println() output from the DummyAgent. > > - During one of my test runs I ran into the following failure: > *** java.lang.instrument ASSERTION FAILED ***: "error == JVMTI_ERROR_NONE" at Reentrancy.c line: 133 > It looks like the patch isn?t complete. I added the patch below and have not seen a failure after that. Can you incorporate that change as well (if you agree with it)? > > Thanks, > /Staffan > > > --- a/src/share/instrument/Reentrancy.c > +++ b/src/share/instrument/Reentrancy.c > @@ -130,6 +130,7 @@ > error = confirmingTLSSet ( jvmtienv, > thread, > JPLIS_CURRENTLY_INSIDE_TOKEN); > + check_phase_ret_false(error); > jplis_assert(error == JVMTI_ERROR_NONE); > if ( error != JVMTI_ERROR_NONE ) { > result = JNI_FALSE; > > > On 27 jan 2014, at 12:44, Chan, Sunny wrote: > > > Hi Staffan, > > I have attached the new version of the patch - I have reworked the test case and now it is mostly based in Java, but I have decided to keep using the shell script to build the Agent Jar file as it is easier. > > Thanks. > > From: Staffan Larsen [mailto:staffan.larsen at oracle.com] > Sent: 13 January 2014 12:37 > To: Chan, Sunny [Tech] > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > Subject: Re: [PATCH] 7142035 assert in j.l.instrument agents during shutdown when daemon thread is running > > > On 8 jan 2014, at 16:48, Chan, Sunny wrote: > > > > In terms of the bug fix itself does it look fine? > > Yes, it does. > > Thanks, > /Staffan > <7142035rev1.patch> > > <7142035rev2.patch> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140129/de603cab/attachment-0001.html From staffan.larsen at oracle.com Wed Jan 29 03:56:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 29 Jan 2014 12:56:14 +0100 Subject: JDK-7090324: gclog rotation via external tool In-Reply-To: <52E26FA2.40909@ysfactory.dip.jp> References: <52483BDB.8040206@ysfactory.dip.jp> <52496A21.8080608@ysfactory.dip.jp> <527CDD56.7080106@ysfactory.dip.jp> <52A09642.4030609@ysfactory.dip.jp> <52E26FA2.40909@ysfactory.dip.jp> Message-ID: <0E26045D-F7F9-49BC-AB36-A42C1DC6E64E@oracle.com> Yasumasa, src/share/vm/runtime/arguments.cpp no comments src/share/vm/runtime/safepoint.cpp I was surprised that gc log size was checked after each safe point. That seems an uneccssary burden to place on a safe point. Instead we should switch to a periodic task that checks the gc log size. However, this is unrelated to you patch, so please ignore for now. src/share/vm/runtime/vm_operations.hpp line 402: nit: missing space before { line 405: I think ?force? is a better name than ?is_force? src/share/vm/services/diagnosticCommand.cpp line 666: What does this do without the -force option? It looks to me that the non-force case will happen after each safe point (see above) and that there is no need to ever do this from a diagnostic command. Can we remove the option? line 677: ?Target VM does not support GC log file rotation." nits: some missing spaces before ?{' and after ?if' src/share/vm/services/diagnosticCommand.hpp I think RotateGCLogDCmd should require the ?control? permission when executed via JMX, so please add: static const JavaPermission permission() { JavaPermission p = {"java.lang.management.ManagementPermission", "control", NULL}; return p; } line 394: Maybe ?Force the GC log file to be rotated.? is a better description? src/share/vm/utilities/ostream.cpp line 662: I think ?force? is a better name than ?is_force? line 668: The comment says exactly the same thing as the code so I think it can be skipped line 671: ?GC log file rotation occurs by external trigger ONLY." line 675: "not need? -> ?no need? line 718: "GC log rotation request has been received? src/share/vm/utilities/ostream.hpp no comments Thanks, /Staffan On 24 jan 2014, at 14:50, Yasumasa Suenaga wrote: > Hi all, > > I've created webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ > > This patch works fine on current jdk9/hs-rt . > Could you review this? > > > I am just an Author. So I need a sponsor. > Could you help me? > > > Please cooperate. > > > Thanks, > > Yasumasa > > > On 2013/12/06 0:05, Yasumasa Suenaga wrote: >> Hi all, >> >> Did someone read my email? >> I really hope to merge "JDK-7090324: gclog rotation via external tool" . >> >> I hear that someone need this RFE. So I want to discuss about this. >> >> >> Thanks, >> >> Yasumasa >> >> On 2013/11/08 21:47, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Did someone read my mail? >>> >>> I think that this RFE helps us to watch Java heap on production system. >>> Also I think this RFE is able to be part of the JEP 158 (Unified JVM Logging) . >>> >>> I want to update this RFE in JDK Bug System, but I don't have account. >>> So I've posted email at first. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2013/09/30 21:10, Yasumasa Suenaga wrote: >>>> In previous email, I've attached new patch for this RFE. >>>> It works fine with current hsx. >>>> >>>> >>>> Yasumasa >>>> >>>> On 2013/09/29 23:40, Yasu wrote: >>>>> Hi all, >>>>> >>>>> We are using "logrotate" tool on RHEL for various log rotation. >>>>> Current HotSpot has gclog rotation function for log size base, >>>>> however I need to rotate gc log synchronizing with logrotate tool. >>>>> >>>>> So I've created RFE as "JDK-7090324: gclog rotation via external tool" . >>>>> And Sr. Engineering Manager in Oracle said he use the essence of my patch in one >>>>> of the jcmd subcommands. >>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274.html >>>>> >>>>> 2 years ago, I posted a patch for this RFE. >>>>> But this patch is too old to apply for current HotSpot. >>>>> >>>>> In last month, a similar discussion was appeared in ML. >>>>> So I think it's time to discuss this RFE. >>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.html >>>>> >>>>> >>>>> Please cooperate. >>>>> >>>>> Best regards, >>>>> Yasumasa >>>> >>> >> > From dmitry.samersoff at oracle.com Wed Jan 29 06:17:33 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 29 Jan 2014 18:17:33 +0400 Subject: Need Second Reviewer Re: RR(S): JDK-7127191 SA JSDB does not display native symbols correctly for transported Linux cores In-Reply-To: <52DD4822.7080301@oracle.com> References: <52DD4822.7080301@oracle.com> Message-ID: <52E90D7D.6070601@oracle.com> Hi Everyone, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.02/ -Dmitry On 2014-01-20 20:00, Dmitry Samersoff wrote: > Hi Everyone, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.01/ > > This fix doesn't solve all problems with symbol lookup in SA, but > address the problem mentioned in bug reports. > > 1. I change algorithm of pathmap_open. Now, it tries to find library > hardly. > > 2. I decided not to fix broken binary search in loadObjectContainingPC, > because with less then 20 DSO's we typically have here performance of > just linear search is approx the same as load, sort, convert to array > and do binary search. > > -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 yasu at ysfactory.dip.jp Wed Jan 29 06:28:16 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Wed, 29 Jan 2014 23:28:16 +0900 Subject: JDK-7090324: gclog rotation via external tool In-Reply-To: <0E26045D-F7F9-49BC-AB36-A42C1DC6E64E@oracle.com> References: <52483BDB.8040206@ysfactory.dip.jp> <52496A21.8080608@ysfactory.dip.jp> <527CDD56.7080106@ysfactory.dip.jp> <52A09642.4030609@ysfactory.dip.jp> <52E26FA2.40909@ysfactory.dip.jp> <0E26045D-F7F9-49BC-AB36-A42C1DC6E64E@oracle.com> Message-ID: <52E91000.9010600@ysfactory.dip.jp> Hi Staffan, Thank you for reviewing! I've uploaded new webrev. http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.01/ On 2014/01/29 20:56, Staffan Larsen wrote: > Yasumasa, > > src/share/vm/runtime/arguments.cpp > no comments > > src/share/vm/runtime/safepoint.cpp > I was surprised that gc log size was checked after each safe point. That seems an uneccssary burden to place on a safe point. Instead we should switch to a periodic task that checks the gc log size. However, this is unrelated to you patch, so please ignore for now. Agree. However, I think that PeriodicTask also is not appropriate for this. Size of GC log file is increased when GC is occurred. So I think rotate function should be called at entry of each GC events e.g. VM_GC_Operation::doit_prologue() etc... > src/share/vm/runtime/vm_operations.hpp > line 402: nit: missing space before { Fixed. > line 405: I think ?force? is a better name than ?is_force? I removed "force" option from DCmd. So I removed this from VMOperation. > src/share/vm/services/diagnosticCommand.cpp > line 666: What does this do without the -force option? It looks to me that the non-force case will happen after each safe point (see above) and that there is no need to ever do this from a diagnostic command. Can we remove the option? Indeed. I removed "force" option. > line 677: ?Target VM does not support GC log file rotation." Fixed. > nits: some missing spaces before ?{' and after ?if' Fixed. > src/share/vm/services/diagnosticCommand.hpp > I think RotateGCLogDCmd should require the ?control? permission when executed via JMX, so please add: > static const JavaPermission permission() { > JavaPermission p = {"java.lang.management.ManagementPermission", > "control", NULL}; > return p; > } Added. > line 394: Maybe ?Force the GC log file to be rotated.? is a better description? Fixed. > src/share/vm/utilities/ostream.cpp > line 662: I think ?force? is a better name than ?is_force? > line 668: The comment says exactly the same thing as the code so I think it can be skipped > line 671: ?GC log file rotation occurs by external trigger ONLY." > line 675: "not need? -> ?no need? > line 718: "GC log rotation request has been received? Fixed them. Thanks, Yasumasa > src/share/vm/utilities/ostream.hpp > no comments > > > Thanks, > /Staffan > > On 24 jan 2014, at 14:50, Yasumasa Suenaga wrote: > >> Hi all, >> >> I've created webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ >> >> This patch works fine on current jdk9/hs-rt . >> Could you review this? >> >> >> I am just an Author. So I need a sponsor. >> Could you help me? >> >> >> Please cooperate. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2013/12/06 0:05, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Did someone read my email? >>> I really hope to merge "JDK-7090324: gclog rotation via external tool" . >>> >>> I hear that someone need this RFE. So I want to discuss about this. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> On 2013/11/08 21:47, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Did someone read my mail? >>>> >>>> I think that this RFE helps us to watch Java heap on production system. >>>> Also I think this RFE is able to be part of the JEP 158 (Unified JVM Logging) . >>>> >>>> I want to update this RFE in JDK Bug System, but I don't have account. >>>> So I've posted email at first. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2013/09/30 21:10, Yasumasa Suenaga wrote: >>>>> In previous email, I've attached new patch for this RFE. >>>>> It works fine with current hsx. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> On 2013/09/29 23:40, Yasu wrote: >>>>>> Hi all, >>>>>> >>>>>> We are using "logrotate" tool on RHEL for various log rotation. >>>>>> Current HotSpot has gclog rotation function for log size base, >>>>>> however I need to rotate gc log synchronizing with logrotate tool. >>>>>> >>>>>> So I've created RFE as "JDK-7090324: gclog rotation via external tool" . >>>>>> And Sr. Engineering Manager in Oracle said he use the essence of my patch in one >>>>>> of the jcmd subcommands. >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274.html >>>>>> >>>>>> 2 years ago, I posted a patch for this RFE. >>>>>> But this patch is too old to apply for current HotSpot. >>>>>> >>>>>> In last month, a similar discussion was appeared in ML. >>>>>> So I think it's time to discuss this RFE. >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.html >>>>>> >>>>>> >>>>>> Please cooperate. >>>>>> >>>>>> Best regards, >>>>>> Yasumasa >>>>> >>>> >>> >> > From mikael.gerdin at oracle.com Wed Jan 29 06:48:03 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 29 Jan 2014 15:48:03 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52E6C589.9030007@oracle.com> References: <52DEEB5F.6020306@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> Message-ID: <7285765.UvUaglGYTH@mgerdin03> Hi Jesper, On Monday 27 January 2014 21.46.01 Jesper Wilhelmsson wrote: > Staffan, Bengt, Mikael, > > Thanks for the reviews! > > I have made the changes you have suggested and a new webrev is available at: > > http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ > > I agree with your assessment that it would be good to implement a generic > way to verify manageable flags. I think it is a separate change though so I > will not attack that problem in this change. > > As Mikael wrote in his review we have talked offline about the changes and > how to make them more correct and readable. Thanks Mikael for the input! The calculations are much easier to follow now, thanks. I think the changes are good. /Mikael > > More comments inline. > > Bengt Rutisson skrev 22/1/14 11:21 AM: > > Hi Jesper, > > > > The calculation in > > PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes()> > > looks wrong to me. I would have expected this: > > 86 // free = (live*ratio) / (1-ratio) > > 87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() * > > > > mhfr_as_percent) / (1.0 - mhfr_as_percent)); > > > > to be something like this: > > size_t max_free = heap->old_gen()->capacity_in_bytes() * > > mhfr_as_percent; > > The suggested formula above will calculate how much free memory there can be > based on the current old gen size. What I want to achieve in the code is to > calculate how much free memory there can be based on the amount of live > data in the old generation. I have talked to Bengt offline and he agrees > that the code is doing what I want it to. I have rewritten the code and > added more comments to explain the formula. > > > (A minor naming thing is that mhfr_as_percent is actually not a percent > > but a ratio or fraction. Just like you write in the comment.) > > Right. Fixed. > > > We also don't seem to take MinHeapFreeRatio into account. Should we do > > that? > We should. Good catch! I have added support for MinHeapFreeRatio both here > and in psScavenge.cpp. > > > I think it should be possible to write a internal VM test or a whitebox > > test for the calculated_old_free_size_in_bytes() to verify that it > > produces the correct results. > > I've added an internal test to verify the new code. > > > Speaking of testing. There is already a test called > > test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass with the > > ParallelGC already before your changes. I think that means that the test > > is not strict enough. Could you update that test or add a new test to > > make sure that your changes are tested? > > TestHeapFreeRatio only verifies that the VM gives correct error messages for > the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain about > flags that don't affect the chosen GC, there is no error given about > ParallelGC not implementing the heap ratio flags. The code I change is not > tested by this test. Dmitry Fazunenko has developed a test for the new > feature which I have used while developing. This test will be pushed once > the feature is in place. > > I also agree with Staffan that the methods is_within() and is_min() make > > it > > harder to read the code. > > Yes, me to... > I removed them. > > Thanks, > /Jesper > > > Thanks, > > Bengt > > > > On 2014-01-22 09:40, Staffan Larsen wrote: > >> Jesper, > >> > >> This looks ok from a serviceability perspective. Long term we should > >> probably have a more pluggable way to verify values of manageable flags > >> so we can avoid some of the duplication. > >> > >> I have a slight problem with is_within() and is_min() in that it is not > >> obvious from the call site if the min and max values are inclusive or not > >> - it was very obvious before. > >> > >> /Staffan > >> > >> > >> On 21 jan 2014, at 22:49, Jesper Wilhelmsson > >> >> > >> wrote: > >>> Hi, > >>> > >>> Could I have a few reviews of this change? > >>> > >>> Summary: > >>> To allow applications a more fine grained control over the GC over time, > >>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. > >>> > >>> The initial request that lead up to this change involved ParallelGC > >>> which is notoriously unwilling to shrink the heap. Since ParallelGC > >>> didn't support the heap free ratio flags, this change also includes > >>> implementing support for these flags in ParallelGC. > >>> > >>> Changes have also been made to the argument parsing, attach listener and > >>> the management API to verify the flag values when set through the > >>> different interfaces. > >>> > >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 > >>> > >>> The plan is to push this to 9 and then backport to 8 and 7. > >>> > >>> Thanks! > >>> /Jesper From jesper.wilhelmsson at oracle.com Wed Jan 29 06:53:57 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 29 Jan 2014 15:53:57 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <7285765.UvUaglGYTH@mgerdin03> References: <52DEEB5F.6020306@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> <7285765.UvUaglGYTH@mgerdin03> Message-ID: <52E91605.1030500@oracle.com> Thanks for the review Mikael! /Jesper Mikael Gerdin skrev 29/1/14 3:48 PM: > Hi Jesper, > > On Monday 27 January 2014 21.46.01 Jesper Wilhelmsson wrote: >> Staffan, Bengt, Mikael, >> >> Thanks for the reviews! >> >> I have made the changes you have suggested and a new webrev is available at: >> >> http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ >> >> I agree with your assessment that it would be good to implement a generic >> way to verify manageable flags. I think it is a separate change though so I >> will not attack that problem in this change. >> >> As Mikael wrote in his review we have talked offline about the changes and >> how to make them more correct and readable. Thanks Mikael for the input! > > The calculations are much easier to follow now, thanks. > > I think the changes are good. > > /Mikael > >> >> More comments inline. >> >> Bengt Rutisson skrev 22/1/14 11:21 AM: >>> Hi Jesper, >>> >>> The calculation in >>> PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes()> >>> looks wrong to me. I would have expected this: >>> 86 // free = (live*ratio) / (1-ratio) >>> 87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() * >>> >>> mhfr_as_percent) / (1.0 - mhfr_as_percent)); >>> >>> to be something like this: >>> size_t max_free = heap->old_gen()->capacity_in_bytes() * >>> mhfr_as_percent; >> >> The suggested formula above will calculate how much free memory there can be >> based on the current old gen size. What I want to achieve in the code is to >> calculate how much free memory there can be based on the amount of live >> data in the old generation. I have talked to Bengt offline and he agrees >> that the code is doing what I want it to. I have rewritten the code and >> added more comments to explain the formula. >> >>> (A minor naming thing is that mhfr_as_percent is actually not a percent >>> but a ratio or fraction. Just like you write in the comment.) >> >> Right. Fixed. >> >>> We also don't seem to take MinHeapFreeRatio into account. Should we do >>> that? >> We should. Good catch! I have added support for MinHeapFreeRatio both here >> and in psScavenge.cpp. >> >>> I think it should be possible to write a internal VM test or a whitebox >>> test for the calculated_old_free_size_in_bytes() to verify that it >>> produces the correct results. >> >> I've added an internal test to verify the new code. >> >>> Speaking of testing. There is already a test called >>> test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass with the >>> ParallelGC already before your changes. I think that means that the test >>> is not strict enough. Could you update that test or add a new test to >>> make sure that your changes are tested? >> >> TestHeapFreeRatio only verifies that the VM gives correct error messages for >> the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain about >> flags that don't affect the chosen GC, there is no error given about >> ParallelGC not implementing the heap ratio flags. The code I change is not >> tested by this test. Dmitry Fazunenko has developed a test for the new >> feature which I have used while developing. This test will be pushed once >> the feature is in place. >>> I also agree with Staffan that the methods is_within() and is_min() make >>> it >>> harder to read the code. >> >> Yes, me to... >> I removed them. >> >> Thanks, >> /Jesper >> >>> Thanks, >>> Bengt >>> >>> On 2014-01-22 09:40, Staffan Larsen wrote: >>>> Jesper, >>>> >>>> This looks ok from a serviceability perspective. Long term we should >>>> probably have a more pluggable way to verify values of manageable flags >>>> so we can avoid some of the duplication. >>>> >>>> I have a slight problem with is_within() and is_min() in that it is not >>>> obvious from the call site if the min and max values are inclusive or not >>>> - it was very obvious before. >>>> >>>> /Staffan >>>> >>>> >>>> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >>>> >> >>>> wrote: >>>>> Hi, >>>>> >>>>> Could I have a few reviews of this change? >>>>> >>>>> Summary: >>>>> To allow applications a more fine grained control over the GC over time, >>>>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. >>>>> >>>>> The initial request that lead up to this change involved ParallelGC >>>>> which is notoriously unwilling to shrink the heap. Since ParallelGC >>>>> didn't support the heap free ratio flags, this change also includes >>>>> implementing support for these flags in ParallelGC. >>>>> >>>>> Changes have also been made to the argument parsing, attach listener and >>>>> the management API to verify the flag values when set through the >>>>> different interfaces. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>>>> >>>>> The plan is to push this to 9 and then backport to 8 and 7. >>>>> >>>>> Thanks! >>>>> /Jesper > From jaroslav.bachorik at oracle.com Wed Jan 29 06:54:31 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 29 Jan 2014 15:54:31 +0100 Subject: RFR 8031701: java/lang/management/ThreadMXBean/Locks.java: Thread WaitingThread is expected to wait on Object but got null Thread.State = RUNNABLE In-Reply-To: <52E84244.5030509@oracle.com> References: <52DE975B.4090802@oracle.com> <52E84244.5030509@oracle.com> Message-ID: <52E91627.3070308@oracle.com> Hi Mandy, On 29.1.2014 00:50, Mandy Chung wrote: > Hi Jaroslav, > > On 1/21/14 7:50 AM, Jaroslav Bachorik wrote: >> Please, review the following test fix. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8031701 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8031701/webrev.00 >> > > The change looks okay. I like the new assertNoLock method and as you > indicate in the comment in L54-55 that the thread state is dummy and not > verified, would it worth refactor checkBlockedObject? The comment "// > #blocking#1", "// #waiting#1", etc are little confusing - maybe "phase > 1", "phase 2", etc? I've simplified checkBlockedObject() and modified the comments - I'm using "#phase#w#1" and "#phase#b#1" to distinguish between the phases during testing blocking and waiting. > > line 279 - leftover comment can be removed. Since you are here, can you > add a space after "==" in line 68 "==Thread.State.BLOCKED" Fixed. Updated webrev: http://cr.openjdk.java.net/~jbachorik/8031701/webrev.02 Thanks, -JB- > > thanks > Mandy From erik.helin at oracle.com Wed Jan 29 07:13:46 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 29 Jan 2014 16:13:46 +0100 Subject: JDK-7090324: gclog rotation via external tool In-Reply-To: <52E91000.9010600@ysfactory.dip.jp> References: <52483BDB.8040206@ysfactory.dip.jp> <52496A21.8080608@ysfactory.dip.jp> <527CDD56.7080106@ysfactory.dip.jp> <52A09642.4030609@ysfactory.dip.jp> <52E26FA2.40909@ysfactory.dip.jp> <0E26045D-F7F9-49BC-AB36-A42C1DC6E64E@oracle.com> <52E91000.9010600@ysfactory.dip.jp> Message-ID: <52E91AAA.3060008@oracle.com> Hi Yasumasa, (have to use HTML email to get a width of more than 78 chars, sorry) why did you change the code in arguments.cpp in the method check_gc_log_consistency? Next, the gcLogFileStream::rotate_log method now does a lot of things. Could you separate out the first block into a new method, gcLogFileStream::should_rotate(bool force)? This was, the code would read: > bool gcLogFileStream::should_rotate(bool force) { > return force || _bytes_writen >= GCLogFileSize; > } > > void gcLogFileStream::rotate_log(bool force) { > char time_msg[FILENAMEBUFLEN]; > char time_str[EXTRACHARLEN]; > char current_file_name[FILENAMEBUFLEN]; > char renamed_file_name[FILENAMEBUFLEN]; > > if (!should_rotate(force)) { > return; > } > > ... > } Could you please update your patch? There is a new empty line in the rotate_log method: > } > + > #ifdef ASSERT could you please remove it? The logging change in rotate_log uses a different kind of if/else syntax than the rest of the file: > if (force) { > ... > } > else { > ... > } The other if/else statements in the file uses: > if (cond) { > ... > } else { > ... > } Could you please update your change to use the same if/else syntax? This part of the change duplicates the code: + jio_snprintf(time_msg, sizeof(time_msg), "%s GC log rotation request has been received. Saved as %s\n", + os::local_time_string((char *)time_str, sizeof(time_str)), + renamed_file_name); + } + else { + jio_snprintf(time_msg, sizeof(time_msg), "%s GC log file has reached the" " maximum size. Saved as %s\n", - os::local_time_string((char *)time_str, sizeof(time_str)), + os::local_time_string((char *)time_str, sizeof(time_str)), renamed_file_name); Could you instead just change the message, as in: > const char* msg = forced ? "%s GC log rotation request has been received. Saved as %s\n" : > "%s GC log file has reached the maximum size. Saved as %s\n"; > jio_snprintf(msg, os::local_time_string((char *)time_str, sizeof(time_str)), renamed_file_name); The declaration of rotate_log in ostream.hpp still uses the old variable name is_force, it should use force, just as the definition. Finally, could you add a test that tests your change? Have a look at the other tests in hotspot/test/gc to see how you can do it (you might want to use some functionality from hotspot/test/testlibrary). Thanks, Erik On 2014-01-29 15:28, Yasumasa Suenaga wrote: > Hi Staffan, > > Thank you for reviewing! > I've uploaded new webrev. > http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.01/ > > On 2014/01/29 20:56, Staffan Larsen wrote: >> Yasumasa, >> >> src/share/vm/runtime/arguments.cpp >> no comments >> >> src/share/vm/runtime/safepoint.cpp >> I was surprised that gc log size was checked after each safe point. >> That seems an uneccssary burden to place on a safe point. Instead we >> should switch to a periodic task that checks the gc log size. >> However, this is unrelated to you patch, so please ignore for now. > > Agree. > However, I think that PeriodicTask also is not appropriate for this. > > Size of GC log file is increased when GC is occurred. > So I think rotate function should be called at entry of each GC events > e.g. VM_GC_Operation::doit_prologue() etc... > > >> src/share/vm/runtime/vm_operations.hpp >> line 402: nit: missing space before { > > Fixed. > > >> line 405: I think ?force? is a better name than ?is_force? > > I removed "force" option from DCmd. > So I removed this from VMOperation. > > >> src/share/vm/services/diagnosticCommand.cpp >> line 666: What does this do without the -force option? It looks to me >> that the non-force case will happen after each safe point (see above) >> and that there is no need to ever do this from a diagnostic command. >> Can we remove the option? > > Indeed. > I removed "force" option. > > >> line 677: ?Target VM does not support GC log file rotation." > > Fixed. > > >> nits: some missing spaces before ?{' and after ?if' > > Fixed. > > >> src/share/vm/services/diagnosticCommand.hpp >> I think RotateGCLogDCmd should require the ?control? permission when >> executed via JMX, so please add: >> static const JavaPermission permission() { >> JavaPermission p = {"java.lang.management.ManagementPermission", >> "control", NULL}; >> return p; >> } > > Added. > > >> line 394: Maybe ?Force the GC log file to be rotated.? is a better >> description? > > Fixed. > > >> src/share/vm/utilities/ostream.cpp >> line 662: I think ?force? is a better name than ?is_force? >> line 668: The comment says exactly the same thing as the code so I >> think it can be skipped >> line 671: ?GC log file rotation occurs by external trigger ONLY." >> line 675: "not need? -> ?no need? >> line 718: "GC log rotation request has been received? > > Fixed them. > > > Thanks, > > Yasumasa > > >> src/share/vm/utilities/ostream.hpp >> no comments >> >> >> Thanks, >> /Staffan >> >> On 24 jan 2014, at 14:50, Yasumasa Suenaga >> wrote: >> >>> Hi all, >>> >>> I've created webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ >>> >>> This patch works fine on current jdk9/hs-rt . >>> Could you review this? >>> >>> >>> I am just an Author. So I need a sponsor. >>> Could you help me? >>> >>> >>> Please cooperate. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2013/12/06 0:05, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Did someone read my email? >>>> I really hope to merge "JDK-7090324: gclog rotation via external >>>> tool" . >>>> >>>> I hear that someone need this RFE. So I want to discuss about this. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> On 2013/11/08 21:47, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Did someone read my mail? >>>>> >>>>> I think that this RFE helps us to watch Java heap on production >>>>> system. >>>>> Also I think this RFE is able to be part of the JEP 158 (Unified >>>>> JVM Logging) . >>>>> >>>>> I want to update this RFE in JDK Bug System, but I don't have >>>>> account. >>>>> So I've posted email at first. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2013/09/30 21:10, Yasumasa Suenaga wrote: >>>>>> In previous email, I've attached new patch for this RFE. >>>>>> It works fine with current hsx. >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> On 2013/09/29 23:40, Yasu wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> We are using "logrotate" tool on RHEL for various log rotation. >>>>>>> Current HotSpot has gclog rotation function for log size base, >>>>>>> however I need to rotate gc log synchronizing with logrotate tool. >>>>>>> >>>>>>> So I've created RFE as "JDK-7090324: gclog rotation via external >>>>>>> tool" . >>>>>>> And Sr. Engineering Manager in Oracle said he use the essence of >>>>>>> my patch in one >>>>>>> of the jcmd subcommands. >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274.html >>>>>>> >>>>>>> >>>>>>> 2 years ago, I posted a patch for this RFE. >>>>>>> But this patch is too old to apply for current HotSpot. >>>>>>> >>>>>>> In last month, a similar discussion was appeared in ML. >>>>>>> So I think it's time to discuss this RFE. >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please cooperate. >>>>>>> >>>>>>> Best regards, >>>>>>> Yasumasa >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140129/ba9f6c77/attachment.html From mattias.tobiasson at oracle.com Wed Jan 29 07:29:01 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Wed, 29 Jan 2014 07:29:01 -0800 (PST) Subject: RFR(S) 6545422: NativeErrors.java uses wrong path name in exec Message-ID: <6c51117e-1a6c-4ec7-a7ce-1ade543850dc@default> Hi, Could you please review this test fix. Problems with the current version: It sometimes fails to find the correct executable for "native2ascii". It throws NullPointerExceptions from multiple locations without logs. Probably because it checks null values with "assert", which may not be enabled. Main Changes: 1. Use common test library to run native2ascii. 2. More real checks for null. 3. More logging. bug: https://bugs.openjdk.java.net/browse/JDK-6545422 webrev: http://cr.openjdk.java.net/~ykantser/6545422/webrev.00/ Mattias From bengt.rutisson at oracle.com Wed Jan 29 07:41:53 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 29 Jan 2014 16:41:53 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52E82A83.7070708@oracle.com> References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> <52E7AA49.7000808@oracle.com> <52E82A83.7070708@oracle.com> Message-ID: <52E92141.6000207@oracle.com> Hi Jesper, On 1/28/14 11:09 PM, Jesper Wilhelmsson wrote: > Bengt, > > Thanks for looking at the change. > Answers inline. > > Bengt Rutisson skrev 28/1/14 2:02 PM: >> >> Hi Jesper, >> >> On 2014-01-27 21:46, Jesper Wilhelmsson wrote: >>> Staffan, Bengt, Mikael, >>> >>> Thanks for the reviews! >>> >>> I have made the changes you have suggested and a new webrev is >>> available at: >>> >>> http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ >> >> Can you explain this code in psScavenge.cpp a bit? I am not sure I >> understand >> what it wants to achieve and how it works if I have set NewSize and/or >> MaxNewSize on the command line. >> >> 532 size_t max_young_size = young_gen->max_size(); >> 533 if (MinHeapFreeRatio != 0 || MaxHeapFreeRatio != 100) { >> 534 max_young_size = MIN2(old_gen->capacity_in_bytes() / >> NewRatio, >> young_gen->max_size()); >> 535 } > > The intention of this code is to constrain the young space if someone > is using the heap free ratio flags. Since it is a bit weird to talk > about a "free ratio" in the young space, we use the heap free ratios > to determine the size of the old generation, and then we use NewRatio > to scale the young generation accordingly. > > The use of NewSize and MaxNewSize shouldn't affect this decision at > this point. They are mainly used to set the initial sizes and limits > for the young generation which will be respected as we use the MIN of > the NewRatio calculation and the young_gen->max_size(). I agree that it is hard to define "free" for the young gen. But this looks kind of strange to me. We guard the setting of max_young_size with both MinHeapFreeRatio or MaxHeapFreeRatio but we don't use any of them in the calculation. We use the max_young_size for two purposes: calculating the survivor size and calculating the eden size. Maybe we can split it up somehow to get understandable logic. I'll think a bit more about this and come back later tonight with some comments. > > This code should however only be executed if using adaptive size > policy so I will add that to the if-statement. That won't be necessary. That whole section is guarded by UseAdaptiveSizePolicy. > >> In arguments.cpp: >> >> 1572 if (UseAdaptiveSizePolicy) { >> 1573 // We don't want to limit adaptive heap sizing's freedom to >> adjust the >> heap >> 1574 // unless the user actually sets these flags. >> 1575 if (FLAG_IS_DEFAULT(MinHeapFreeRatio)) { >> 1576 FLAG_SET_DEFAULT(MinHeapFreeRatio, 0); >> 1577 } >> 1578 if (FLAG_IS_DEFAULT(MaxHeapFreeRatio)) { >> 1579 FLAG_SET_DEFAULT(MaxHeapFreeRatio, 100); >> 1580 } >> 1581 } >> >> Should these be FLAG_SET_ERGO instead? Not sure. Just asking. > > I went back and forth on this one, but decided that I wanted to > express that if using adaptive size policy, the default values of > these flags should be different. I think it would work perfectly fine > if using FLAG_SET_ERGO instead but I'm thinking that this is not > really an ergonomic decision, but rather due to a different > implementation. OK. I am also undecided on what's best, so let's leave it as it is. > >> 3705 if (MinHeapFreeRatio == 100) { >> 3706 // Keeping the heap 100% free is hard ;-) so limit it to 99%. >> 3707 FLAG_SET_ERGO(uintx, MinHeapFreeRatio, 99); >> 3708 } >> >> Couldn't this just be part of Arguments::verify_MinHeapFreeRatio()? > > This code moved from check_vm_args_consistency() to apply_ergo() since > it is a ergonomic decision to change the value of the flag. I don't > think this kind of changes should be done while checking argument > consistency. verify_MinHeapFreeRatio() is called from > check_vm_args_consistency(). I don't see why it is wrong to check this as argument consistency. Clearly MinHeapFreeRatio can only be a value between 0 and 99. In my opinion that would be best to check at startup. > >> attachListener.cpp >> >> strncmp(name, "MaxHeapFreeRatio", 17) == 0 >> >> MaxHeapFreeRatio is 16 characters. Is the 17th character in the >> constant always >> NULL and this check verifies that I can write >> MaxHeapFreeRatioMoreCharacters and >> get it to pass the strncmp? > > Yes, that's what I want to achieve. OK. Good. > (I assume that you mean "can't write MaxHeapFreeRatioMoreCharacters".) Right ;) > >> It would be nice with a JTreg test that sets the flags to valid and >> invalid >> values and checks that the flags have the right values after this. > > Dmitry is working on the tests for this feature. I'll ask him to > include a few tests for illegal values as well. OK. > >> Did you have a look at the test/gc/arguments/TestHeapFreeRatio.java >> test? Is >> that relevant to verify your changes? > > No, my changes are not tested by TestHeapFreeRatio. I wrote a few > lines about why towards the end of my last mail. Sorry. Missed that. I will go back and check that email. Thanks, Bengt > > Thanks, > /Jesper > >> >> Thanks, >> Bengt >> >> >>> >>> I agree with your assessment that it would be good to implement a >>> generic way >>> to verify manageable flags. I think it is a separate change though >>> so I will >>> not attack that problem in this change. >>> >>> As Mikael wrote in his review we have talked offline about the >>> changes and how >>> to make them more correct and readable. Thanks Mikael for the input! >>> >>> More comments inline. >>> >>> Bengt Rutisson skrev 22/1/14 11:21 AM: >>>> >>>> Hi Jesper, >>>> >>>> The calculation in >>>> PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() >>>> looks wrong to me. I would have expected this: >>>> >>>> 86 // free = (live*ratio) / (1-ratio) >>>> 87 size_t max_free = >>>> (size_t)((heap->old_gen()->used_in_bytes() * >>>> mhfr_as_percent) / (1.0 - mhfr_as_percent)); >>>> >>>> to be something like this: >>>> >>>> size_t max_free = heap->old_gen()->capacity_in_bytes() * >>>> mhfr_as_percent; >>> >>> The suggested formula above will calculate how much free memory >>> there can be >>> based on the current old gen size. What I want to achieve in the >>> code is to >>> calculate how much free memory there can be based on the amount of >>> live data >>> in the old generation. I have talked to Bengt offline and he agrees >>> that the >>> code is doing what I want it to. I have rewritten the code and added >>> more >>> comments to explain the formula. >>> >>>> (A minor naming thing is that mhfr_as_percent is actually not a >>>> percent but a >>>> ratio or fraction. Just like you write in the comment.) >>> >>> Right. Fixed. >>> >>>> We also don't seem to take MinHeapFreeRatio into account. Should we >>>> do that? >>> >>> We should. Good catch! I have added support for MinHeapFreeRatio >>> both here and >>> in psScavenge.cpp. >>> >>>> I think it should be possible to write a internal VM test or a >>>> whitebox test for >>>> the calculated_old_free_size_in_bytes() to verify that it produces >>>> the correct >>>> results. >>> >>> I've added an internal test to verify the new code. >>> >>>> Speaking of testing. There is already a test called >>>> test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass >>>> with the >>>> ParallelGC already before your changes. I think that means that the >>>> test is not >>>> strict enough. Could you update that test or add a new test to make >>>> sure that >>>> your changes are tested? >>> >>> TestHeapFreeRatio only verifies that the VM gives correct error >>> messages for >>> the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain >>> about flags >>> that don't affect the chosen GC, there is no error given about >>> ParallelGC not >>> implementing the heap ratio flags. The code I change is not tested >>> by this >>> test. Dmitry Fazunenko has developed a test for the new feature >>> which I have >>> used while developing. This test will be pushed once the feature is >>> in place. >>> >>>> I also agree with Staffan that the methods is_within() and is_min() >>>> make it >>>> harder to read the code. >>> >>> Yes, me to... >>> I removed them. >>> >>> Thanks, >>> /Jesper >>> >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> >>>> On 2014-01-22 09:40, Staffan Larsen wrote: >>>>> Jesper, >>>>> >>>>> This looks ok from a serviceability perspective. Long term we >>>>> should probably >>>>> have a more pluggable way to verify values of manageable flags so >>>>> we can avoid >>>>> some of the duplication. >>>>> >>>>> I have a slight problem with is_within() and is_min() in that it >>>>> is not >>>>> obvious from the call site if the min and max values are inclusive >>>>> or not - it >>>>> was very obvious before. >>>>> >>>>> /Staffan >>>>> >>>>> >>>>> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >>>>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Could I have a few reviews of this change? >>>>>> >>>>>> Summary: >>>>>> To allow applications a more fine grained control over the GC >>>>>> over time, >>>>>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio >>>>>> manageable. >>>>>> >>>>>> The initial request that lead up to this change involved >>>>>> ParallelGC which is >>>>>> notoriously unwilling to shrink the heap. Since ParallelGC didn't >>>>>> support the >>>>>> heap free ratio flags, this change also includes implementing >>>>>> support for >>>>>> these flags in ParallelGC. >>>>>> >>>>>> Changes have also been made to the argument parsing, attach >>>>>> listener and the >>>>>> management API to verify the flag values when set through the >>>>>> different >>>>>> interfaces. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>>>>> >>>>>> The plan is to push this to 9 and then backport to 8 and 7. >>>>>> >>>>>> Thanks! >>>>>> /Jesper >>>> >> From mandy.chung at oracle.com Wed Jan 29 07:52:59 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 Jan 2014 07:52:59 -0800 Subject: RFR 8031701: java/lang/management/ThreadMXBean/Locks.java: Thread WaitingThread is expected to wait on Object but got null Thread.State = RUNNABLE In-Reply-To: <52E91627.3070308@oracle.com> References: <52DE975B.4090802@oracle.com> <52E84244.5030509@oracle.com> <52E91627.3070308@oracle.com> Message-ID: <52E923DB.9090609@oracle.com> On 1/29/2014 6:54 AM, Jaroslav Bachorik wrote: > Hi Mandy, > > On 29.1.2014 00:50, Mandy Chung wrote: >> >> The change looks okay. I like the new assertNoLock method and as you >> indicate in the comment in L54-55 that the thread state is dummy and not >> verified, would it worth refactor checkBlockedObject? The comment "// >> #blocking#1", "// #waiting#1", etc are little confusing - maybe "phase >> 1", "phase 2", etc? > > I've simplified checkBlockedObject() and modified the comments - I'm > using "#phase#w#1" and "#phase#b#1" to distinguish between the phases > during testing blocking and waiting. > Updated webrev: http://cr.openjdk.java.net/~jbachorik/8031701/webrev.02 Perhaps you should add a comment to describe the notation (no need for a new webrev). Other than that, looks okay. Good to see ThreadExecutionSynchronizer.java now goes away. Thanks for following this up. Mandy From yasu at ysfactory.dip.jp Wed Jan 29 07:55:57 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Thu, 30 Jan 2014 00:55:57 +0900 Subject: JDK-7090324: gclog rotation via external tool In-Reply-To: <52E91AAA.3060008@oracle.com> References: <52483BDB.8040206@ysfactory.dip.jp> <52496A21.8080608@ysfactory.dip.jp> <527CDD56.7080106@ysfactory.dip.jp> <52A09642.4030609@ysfactory.dip.jp> <52E26FA2.40909@ysfactory.dip.jp> <0E26045D-F7F9-49BC-AB36-A42C1DC6E64E@oracle.com> <52E91000.9010600@ysfactory.dip.jp> <52E91AAA.3060008@oracle.com> Message-ID: <52E9248D.2090108@ysfactory.dip.jp> Hi Erik, On 2014/01/30 0:13, Erik Helin wrote: > Hi Yasumasa, > > (have to use HTML email to get a width of more than 78 chars, sorry) > > why did you change the code in arguments.cpp in the method check_gc_log_consistency? In current implementation, check_gclog_consistency() checks three parameters: - GC log filename - NumberOfGCLogFiles - GCLogFileSize My customer uses external trigger "ONLY" for rotating logs. If they want to do that, GCLogFileSize does not need. > Next, the gcLogFileStream::rotate_log method now does a lot of things. >Could you separate out the first block into a new method, >gcLogFileStream::should_rotate(bool force)? > > This was, the code would read: > > > bool gcLogFileStream::should_rotate(bool force) { > > return force || _bytes_writen >= GCLogFileSize; > > } > > > > void gcLogFileStream::rotate_log(bool force) { > > char time_msg[FILENAMEBUFLEN]; > > char time_str[EXTRACHARLEN]; > > char current_file_name[FILENAMEBUFLEN]; > > char renamed_file_name[FILENAMEBUFLEN]; > > > > if (!should_rotate(force)) { > > return; > > } > > > > ... > > } > > Could you please update your patch? I will do that. > There is a new empty line in the rotate_log method: > > > } > > + > > #ifdef ASSERT > > could you please remove it? I will do that. > The logging change in rotate_log uses a different kind of if/else syntax > than the rest of the file: > > > if (force) { > > ... > > } > > else { > > ... > > } > > The other if/else statements in the file uses: > > > if (cond) { > > ... > > } else { > > ... > > } > > Could you please update your change to use the same if/else syntax? I will do that. > This part of the change duplicates the code: > > + jio_snprintf(time_msg, sizeof(time_msg), "%s GC log rotation request has been received. Saved as %s\n", > + os::local_time_string((char *)time_str, sizeof(time_str)), > + renamed_file_name); > + } > + else { > + jio_snprintf(time_msg, sizeof(time_msg), "%s GC log file has reached the" > " maximum size. Saved as %s\n", > - os::local_time_string((char *)time_str, sizeof(time_str)), > + os::local_time_string((char *)time_str, sizeof(time_str)), > renamed_file_name); > > Could you instead just change the message, as in: > > > const char* msg = forced ? "%s GC log rotation request has been received. Saved as %s\n" : > > "%s GC log file has reached the maximum size. Saved as %s\n"; > > jio_snprintf(msg, os::local_time_string((char *)time_str, sizeof(time_str)), renamed_file_name); I will do that. > The declaration of rotate_log in ostream.hpp still uses the old >variable name is_force, it should use force, >just as the definition. Sorry, I will fix it. > Finally, could you add a test that tests your change? Have a look at the other tests >in hotspot/test/gc to see how you can do it > (you might want to use some functionality from hotspot/test/testlibrary). I found three tests as following: [ysuenaga at xelvis test]$ find . -iname "*jcmd*" ./runtime/NMT/JcmdWithNMTDisabled.java ./runtime/NMT/JcmdScale.java ./gc/TestG1ZeroPGCTJcmdThreadPrint.java I understand that these tests checks output (stdout/stderr) with OutputAnalyzer. However, my patch affects target VM. So I guess current test cannot check that GC log rotation is succeeded. Should I make test which checks exit value of jcmd ? Thanks, Yasumasa > Thanks, > Erik > > On 2014-01-29 15:28, Yasumasa Suenaga wrote: >> Hi Staffan, >> >> Thank you for reviewing! >> I've uploaded new webrev. >> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.01/ >> >> On 2014/01/29 20:56, Staffan Larsen wrote: >>> Yasumasa, >>> >>> src/share/vm/runtime/arguments.cpp >>> no comments >>> >>> src/share/vm/runtime/safepoint.cpp >>> I was surprised that gc log size was checked after each safe point. That seems an uneccssary burden to place on a safe point. Instead we should switch to a periodic task that checks the gc log size. However, this is unrelated to you patch, so please ignore for now. >> >> Agree. >> However, I think that PeriodicTask also is not appropriate for this. >> >> Size of GC log file is increased when GC is occurred. >> So I think rotate function should be called at entry of each GC events >> e.g. VM_GC_Operation::doit_prologue() etc... >> >> >>> src/share/vm/runtime/vm_operations.hpp >>> line 402: nit: missing space before { >> >> Fixed. >> >> >>> line 405: I think ?force? is a better name than ?is_force? >> >> I removed "force" option from DCmd. >> So I removed this from VMOperation. >> >> >>> src/share/vm/services/diagnosticCommand.cpp >>> line 666: What does this do without the -force option? It looks to me that the non-force case will happen after each safe point (see above) and that there is no need to ever do this from a diagnostic command. Can we remove the option? >> >> Indeed. >> I removed "force" option. >> >> >>> line 677: ?Target VM does not support GC log file rotation." >> >> Fixed. >> >> >>> nits: some missing spaces before ?{' and after ?if' >> >> Fixed. >> >> >>> src/share/vm/services/diagnosticCommand.hpp >>> I think RotateGCLogDCmd should require the ?control? permission when executed via JMX, so please add: >>> static const JavaPermission permission() { >>> JavaPermission p = {"java.lang.management.ManagementPermission", >>> "control", NULL}; >>> return p; >>> } >> >> Added. >> >> >>> line 394: Maybe ?Force the GC log file to be rotated.? is a better description? >> >> Fixed. >> >> >>> src/share/vm/utilities/ostream.cpp >>> line 662: I think ?force? is a better name than ?is_force? >>> line 668: The comment says exactly the same thing as the code so I think it can be skipped >>> line 671: ?GC log file rotation occurs by external trigger ONLY." >>> line 675: "not need? -> ?no need? >>> line 718: "GC log rotation request has been received? >> >> Fixed them. >> >> >> Thanks, >> >> Yasumasa >> >> >>> src/share/vm/utilities/ostream.hpp >>> no comments >>> >>> >>> Thanks, >>> /Staffan >>> >>> On 24 jan 2014, at 14:50, Yasumasa Suenaga wrote: >>> >>>> Hi all, >>>> >>>> I've created webrev: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ >>>> >>>> This patch works fine on current jdk9/hs-rt . >>>> Could you review this? >>>> >>>> >>>> I am just an Author. So I need a sponsor. >>>> Could you help me? >>>> >>>> >>>> Please cooperate. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2013/12/06 0:05, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Did someone read my email? >>>>> I really hope to merge "JDK-7090324: gclog rotation via external tool" . >>>>> >>>>> I hear that someone need this RFE. So I want to discuss about this. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> On 2013/11/08 21:47, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Did someone read my mail? >>>>>> >>>>>> I think that this RFE helps us to watch Java heap on production system. >>>>>> Also I think this RFE is able to be part of the JEP 158 (Unified JVM Logging) . >>>>>> >>>>>> I want to update this RFE in JDK Bug System, but I don't have account. >>>>>> So I've posted email at first. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2013/09/30 21:10, Yasumasa Suenaga wrote: >>>>>>> In previous email, I've attached new patch for this RFE. >>>>>>> It works fine with current hsx. >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> On 2013/09/29 23:40, Yasu wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> We are using "logrotate" tool on RHEL for various log rotation. >>>>>>>> Current HotSpot has gclog rotation function for log size base, >>>>>>>> however I need to rotate gc log synchronizing with logrotate tool. >>>>>>>> >>>>>>>> So I've created RFE as "JDK-7090324: gclog rotation via external tool" . >>>>>>>> And Sr. Engineering Manager in Oracle said he use the essence of my patch in one >>>>>>>> of the jcmd subcommands. >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274.html >>>>>>>> >>>>>>>> 2 years ago, I posted a patch for this RFE. >>>>>>>> But this patch is too old to apply for current HotSpot. >>>>>>>> >>>>>>>> In last month, a similar discussion was appeared in ML. >>>>>>>> So I think it's time to discuss this RFE. >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.html >>>>>>>> >>>>>>>> >>>>>>>> Please cooperate. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Yasumasa >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jesper.wilhelmsson at oracle.com Wed Jan 29 12:25:04 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 29 Jan 2014 21:25:04 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52E92141.6000207@oracle.com> References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> <52E7AA49.7000808@oracle.com> <52E82A83.7070708@oracle.com> <52E92141.6000207@oracle.com> Message-ID: <52E963A0.90704@oracle.com> Hi Bengt, Just a short clarification inline. Looking forward to your comments later today. Bengt Rutisson skrev 29/1/14 4:41 PM: > > Hi Jesper, > > On 1/28/14 11:09 PM, Jesper Wilhelmsson wrote: >> Bengt, >> >> Thanks for looking at the change. >> Answers inline. >> >> Bengt Rutisson skrev 28/1/14 2:02 PM: >>> >>> Hi Jesper, >>> >>> On 2014-01-27 21:46, Jesper Wilhelmsson wrote: >>>> Staffan, Bengt, Mikael, >>>> >>>> Thanks for the reviews! >>>> >>>> I have made the changes you have suggested and a new webrev is available at: >>>> >>>> http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ >>> >>> Can you explain this code in psScavenge.cpp a bit? I am not sure I understand >>> what it wants to achieve and how it works if I have set NewSize and/or >>> MaxNewSize on the command line. >>> >>> 532 size_t max_young_size = young_gen->max_size(); >>> 533 if (MinHeapFreeRatio != 0 || MaxHeapFreeRatio != 100) { >>> 534 max_young_size = MIN2(old_gen->capacity_in_bytes() / NewRatio, >>> young_gen->max_size()); >>> 535 } >> >> The intention of this code is to constrain the young space if someone is using >> the heap free ratio flags. Since it is a bit weird to talk about a "free >> ratio" in the young space, we use the heap free ratios to determine the size >> of the old generation, and then we use NewRatio to scale the young generation >> accordingly. >> >> The use of NewSize and MaxNewSize shouldn't affect this decision at this >> point. They are mainly used to set the initial sizes and limits for the young >> generation which will be respected as we use the MIN of the NewRatio >> calculation and the young_gen->max_size(). > > I agree that it is hard to define "free" for the young gen. But this looks kind > of strange to me. We guard the setting of max_young_size with both > MinHeapFreeRatio or MaxHeapFreeRatio but we don't use any of them in the > calculation. In psScavenge.cpp the flags MinHeapFreeRatio and MaxHeapFreeRatio is only used to determine *if* we should limit the young gen size. The flags are used to determine the size of the old generation. Then we scale the young generation based on the limited old size using the NewRatio flag. I will add the following comment before the new if-statement: // Deciding a free ratio in the young generation is tricky, so if // MinHeapFreeRatio or MaxHeapFreeRatio are in use (implicating // that the old generation size may have been limited because of them) we // should then limit our young generation size using NewRatio to have it // follow the old generation size. > We use the max_young_size for two purposes: calculating the survivor size and > calculating the eden size. Maybe we can split it up somehow to get > understandable logic. I'll think a bit more about this and come back later > tonight with some comments. invoke_no_policy() is a huge method and clearly it would benefit the code to split it into smaller parts. I'm not sure this particular part is the most urgent to refactor though, plus I didn't want to mix this change with a lot of cleanup. The logic of the sizing calculation is not really changed more than the possible adjustment of the upper limit of the young size. Instead of using the hard upper limit of the young generation, we use the NewRatio-based size if it's smaller. The young gen has two parts that needs to be resized, eden and survivors. Both use the same limited young gen size for their size calculations in the same way as they before used the young gen max size. There is only one other use of young_gen->max_size() in this code. This is an assert that verifies that the parts of the young gen doesn't exceed the hard upper limit. I think this one should still look at the real limit, and not the calculated one. >> >> This code should however only be executed if using adaptive size policy so I >> will add that to the if-statement. > > That won't be necessary. That whole section is guarded by UseAdaptiveSizePolicy. Indeed it is. I noticed the check in line 561 and thought "Hey, this code also needs that check", but it seems the check should be removed from line 561 instead. :-) >> >>> In arguments.cpp: >>> >>> 1572 if (UseAdaptiveSizePolicy) { >>> 1573 // We don't want to limit adaptive heap sizing's freedom to adjust the >>> heap >>> 1574 // unless the user actually sets these flags. >>> 1575 if (FLAG_IS_DEFAULT(MinHeapFreeRatio)) { >>> 1576 FLAG_SET_DEFAULT(MinHeapFreeRatio, 0); >>> 1577 } >>> 1578 if (FLAG_IS_DEFAULT(MaxHeapFreeRatio)) { >>> 1579 FLAG_SET_DEFAULT(MaxHeapFreeRatio, 100); >>> 1580 } >>> 1581 } >>> >>> Should these be FLAG_SET_ERGO instead? Not sure. Just asking. >> >> I went back and forth on this one, but decided that I wanted to express that >> if using adaptive size policy, the default values of these flags should be >> different. I think it would work perfectly fine if using FLAG_SET_ERGO instead >> but I'm thinking that this is not really an ergonomic decision, but rather due >> to a different implementation. > > OK. I am also undecided on what's best, so let's leave it as it is. > >> >>> 3705 if (MinHeapFreeRatio == 100) { >>> 3706 // Keeping the heap 100% free is hard ;-) so limit it to 99%. >>> 3707 FLAG_SET_ERGO(uintx, MinHeapFreeRatio, 99); >>> 3708 } >>> >>> Couldn't this just be part of Arguments::verify_MinHeapFreeRatio()? >> >> This code moved from check_vm_args_consistency() to apply_ergo() since it is a >> ergonomic decision to change the value of the flag. I don't think this kind of >> changes should be done while checking argument consistency. >> verify_MinHeapFreeRatio() is called from check_vm_args_consistency(). > > I don't see why it is wrong to check this as argument consistency. Clearly > MinHeapFreeRatio can only be a value between 0 and 99. In my opinion that would > be best to check at startup. apply_ergo() is also done during startup, but I see your point. I'll move the check into verify_MinHeapFreeRatio(). Thanks, /Jesper >> >>> attachListener.cpp >>> >>> strncmp(name, "MaxHeapFreeRatio", 17) == 0 >>> >>> MaxHeapFreeRatio is 16 characters. Is the 17th character in the constant always >>> NULL and this check verifies that I can write MaxHeapFreeRatioMoreCharacters and >>> get it to pass the strncmp? >> >> Yes, that's what I want to achieve. > > OK. Good. > >> (I assume that you mean "can't write MaxHeapFreeRatioMoreCharacters".) > > Right ;) > >> >>> It would be nice with a JTreg test that sets the flags to valid and invalid >>> values and checks that the flags have the right values after this. >> >> Dmitry is working on the tests for this feature. I'll ask him to include a few >> tests for illegal values as well. > > OK. > >> >>> Did you have a look at the test/gc/arguments/TestHeapFreeRatio.java test? Is >>> that relevant to verify your changes? >> >> No, my changes are not tested by TestHeapFreeRatio. I wrote a few lines about >> why towards the end of my last mail. > > Sorry. Missed that. I will go back and check that email. > > Thanks, > Bengt > >> >> Thanks, >> /Jesper >> >>> >>> Thanks, >>> Bengt >>> >>> >>>> >>>> I agree with your assessment that it would be good to implement a generic way >>>> to verify manageable flags. I think it is a separate change though so I will >>>> not attack that problem in this change. >>>> >>>> As Mikael wrote in his review we have talked offline about the changes and how >>>> to make them more correct and readable. Thanks Mikael for the input! >>>> >>>> More comments inline. >>>> >>>> Bengt Rutisson skrev 22/1/14 11:21 AM: >>>>> >>>>> Hi Jesper, >>>>> >>>>> The calculation in PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() >>>>> looks wrong to me. I would have expected this: >>>>> >>>>> 86 // free = (live*ratio) / (1-ratio) >>>>> 87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() * >>>>> mhfr_as_percent) / (1.0 - mhfr_as_percent)); >>>>> >>>>> to be something like this: >>>>> >>>>> size_t max_free = heap->old_gen()->capacity_in_bytes() * mhfr_as_percent; >>>> >>>> The suggested formula above will calculate how much free memory there can be >>>> based on the current old gen size. What I want to achieve in the code is to >>>> calculate how much free memory there can be based on the amount of live data >>>> in the old generation. I have talked to Bengt offline and he agrees that the >>>> code is doing what I want it to. I have rewritten the code and added more >>>> comments to explain the formula. >>>> >>>>> (A minor naming thing is that mhfr_as_percent is actually not a percent but a >>>>> ratio or fraction. Just like you write in the comment.) >>>> >>>> Right. Fixed. >>>> >>>>> We also don't seem to take MinHeapFreeRatio into account. Should we do that? >>>> >>>> We should. Good catch! I have added support for MinHeapFreeRatio both here and >>>> in psScavenge.cpp. >>>> >>>>> I think it should be possible to write a internal VM test or a whitebox >>>>> test for >>>>> the calculated_old_free_size_in_bytes() to verify that it produces the correct >>>>> results. >>>> >>>> I've added an internal test to verify the new code. >>>> >>>>> Speaking of testing. There is already a test called >>>>> test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass with the >>>>> ParallelGC already before your changes. I think that means that the test is >>>>> not >>>>> strict enough. Could you update that test or add a new test to make sure that >>>>> your changes are tested? >>>> >>>> TestHeapFreeRatio only verifies that the VM gives correct error messages for >>>> the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain about flags >>>> that don't affect the chosen GC, there is no error given about ParallelGC not >>>> implementing the heap ratio flags. The code I change is not tested by this >>>> test. Dmitry Fazunenko has developed a test for the new feature which I have >>>> used while developing. This test will be pushed once the feature is in place. >>>> >>>>> I also agree with Staffan that the methods is_within() and is_min() make it >>>>> harder to read the code. >>>> >>>> Yes, me to... >>>> I removed them. >>>> >>>> Thanks, >>>> /Jesper >>>> >>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>> >>>>> On 2014-01-22 09:40, Staffan Larsen wrote: >>>>>> Jesper, >>>>>> >>>>>> This looks ok from a serviceability perspective. Long term we should probably >>>>>> have a more pluggable way to verify values of manageable flags so we can >>>>>> avoid >>>>>> some of the duplication. >>>>>> >>>>>> I have a slight problem with is_within() and is_min() in that it is not >>>>>> obvious from the call site if the min and max values are inclusive or not >>>>>> - it >>>>>> was very obvious before. >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Could I have a few reviews of this change? >>>>>>> >>>>>>> Summary: >>>>>>> To allow applications a more fine grained control over the GC over time, >>>>>>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. >>>>>>> >>>>>>> The initial request that lead up to this change involved ParallelGC which is >>>>>>> notoriously unwilling to shrink the heap. Since ParallelGC didn't support >>>>>>> the >>>>>>> heap free ratio flags, this change also includes implementing support for >>>>>>> these flags in ParallelGC. >>>>>>> >>>>>>> Changes have also been made to the argument parsing, attach listener and the >>>>>>> management API to verify the flag values when set through the different >>>>>>> interfaces. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>>>>>> >>>>>>> The plan is to push this to 9 and then backport to 8 and 7. >>>>>>> >>>>>>> Thanks! >>>>>>> /Jesper >>>>> >>> > From bengt.rutisson at oracle.com Wed Jan 29 13:09:26 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 29 Jan 2014 22:09:26 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52E963A0.90704@oracle.com> References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> <52E7AA49.7000808@oracle.com> <52E82A83.7070708@oracle.com> <52E92141.6000207@oracle.com> <52E963A0.90704@oracle.com> Message-ID: <52E96E06.8080906@oracle.com> Hi everyone, I just talked this through with Jesper. I'm fine with the latest webrev. To size the young gen the code relies on that an old GC has happened. Currently there is nothing that guarantees this, so the implementation kind of relies on the application to call System.gc() to get the desired effect. That works for the current use case (using the management APIs to set the values) but may not work well for someone how just sets the values on the command line. An alternative would be to check Min/MaxHeapFreeRatio at the end of a scavenge and trigger an old collection if the limits have been exceeded. That way the code would be more self sustained. Jesper will file a separate RFE for that. Bengt On 1/29/14 9:25 PM, Jesper Wilhelmsson wrote: > Hi Bengt, > > Just a short clarification inline. Looking forward to your comments > later today. > > Bengt Rutisson skrev 29/1/14 4:41 PM: >> >> Hi Jesper, >> >> On 1/28/14 11:09 PM, Jesper Wilhelmsson wrote: >>> Bengt, >>> >>> Thanks for looking at the change. >>> Answers inline. >>> >>> Bengt Rutisson skrev 28/1/14 2:02 PM: >>>> >>>> Hi Jesper, >>>> >>>> On 2014-01-27 21:46, Jesper Wilhelmsson wrote: >>>>> Staffan, Bengt, Mikael, >>>>> >>>>> Thanks for the reviews! >>>>> >>>>> I have made the changes you have suggested and a new webrev is >>>>> available at: >>>>> >>>>> http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ >>>> >>>> Can you explain this code in psScavenge.cpp a bit? I am not sure I >>>> understand >>>> what it wants to achieve and how it works if I have set NewSize and/or >>>> MaxNewSize on the command line. >>>> >>>> 532 size_t max_young_size = young_gen->max_size(); >>>> 533 if (MinHeapFreeRatio != 0 || MaxHeapFreeRatio != 100) { >>>> 534 max_young_size = MIN2(old_gen->capacity_in_bytes() >>>> / NewRatio, >>>> young_gen->max_size()); >>>> 535 } >>> >>> The intention of this code is to constrain the young space if >>> someone is using >>> the heap free ratio flags. Since it is a bit weird to talk about a >>> "free >>> ratio" in the young space, we use the heap free ratios to determine >>> the size >>> of the old generation, and then we use NewRatio to scale the young >>> generation >>> accordingly. >>> >>> The use of NewSize and MaxNewSize shouldn't affect this decision at >>> this >>> point. They are mainly used to set the initial sizes and limits for >>> the young >>> generation which will be respected as we use the MIN of the NewRatio >>> calculation and the young_gen->max_size(). >> >> I agree that it is hard to define "free" for the young gen. But this >> looks kind >> of strange to me. We guard the setting of max_young_size with both >> MinHeapFreeRatio or MaxHeapFreeRatio but we don't use any of them in the >> calculation. > > In psScavenge.cpp the flags MinHeapFreeRatio and MaxHeapFreeRatio is > only used to determine *if* we should limit the young gen size. > > The flags are used to determine the size of the old generation. Then > we scale the young generation based on the limited old size using the > NewRatio flag. > > I will add the following comment before the new if-statement: > > // Deciding a free ratio in the young generation is tricky, so if > // MinHeapFreeRatio or MaxHeapFreeRatio are in use (implicating > // that the old generation size may have been limited because of them) we > // should then limit our young generation size using NewRatio to have it > // follow the old generation size. > > >> We use the max_young_size for two purposes: calculating the survivor >> size and >> calculating the eden size. Maybe we can split it up somehow to get >> understandable logic. I'll think a bit more about this and come back >> later >> tonight with some comments. > > invoke_no_policy() is a huge method and clearly it would benefit the > code to split it into smaller parts. I'm not sure this particular part > is the most urgent to refactor though, plus I didn't want to mix this > change with a lot of cleanup. > > The logic of the sizing calculation is not really changed more than > the possible adjustment of the upper limit of the young size. Instead > of using the hard upper limit of the young generation, we use the > NewRatio-based size if it's smaller. The young gen has two parts that > needs to be resized, eden and survivors. Both use the same limited > young gen size for their size calculations in the same way as they > before used the young gen max size. > > There is only one other use of young_gen->max_size() in this code. > This is an assert that verifies that the parts of the young gen > doesn't exceed the hard upper limit. I think this one should still > look at the real limit, and not the calculated one. > >>> >>> This code should however only be executed if using adaptive size >>> policy so I >>> will add that to the if-statement. >> >> That won't be necessary. That whole section is guarded by >> UseAdaptiveSizePolicy. > > Indeed it is. I noticed the check in line 561 and thought "Hey, this > code also needs that check", but it seems the check should be removed > from line 561 instead. :-) > >>> >>>> In arguments.cpp: >>>> >>>> 1572 if (UseAdaptiveSizePolicy) { >>>> 1573 // We don't want to limit adaptive heap sizing's freedom >>>> to adjust the >>>> heap >>>> 1574 // unless the user actually sets these flags. >>>> 1575 if (FLAG_IS_DEFAULT(MinHeapFreeRatio)) { >>>> 1576 FLAG_SET_DEFAULT(MinHeapFreeRatio, 0); >>>> 1577 } >>>> 1578 if (FLAG_IS_DEFAULT(MaxHeapFreeRatio)) { >>>> 1579 FLAG_SET_DEFAULT(MaxHeapFreeRatio, 100); >>>> 1580 } >>>> 1581 } >>>> >>>> Should these be FLAG_SET_ERGO instead? Not sure. Just asking. >>> >>> I went back and forth on this one, but decided that I wanted to >>> express that >>> if using adaptive size policy, the default values of these flags >>> should be >>> different. I think it would work perfectly fine if using >>> FLAG_SET_ERGO instead >>> but I'm thinking that this is not really an ergonomic decision, but >>> rather due >>> to a different implementation. >> >> OK. I am also undecided on what's best, so let's leave it as it is. >> >>> >>>> 3705 if (MinHeapFreeRatio == 100) { >>>> 3706 // Keeping the heap 100% free is hard ;-) so limit it to 99%. >>>> 3707 FLAG_SET_ERGO(uintx, MinHeapFreeRatio, 99); >>>> 3708 } >>>> >>>> Couldn't this just be part of Arguments::verify_MinHeapFreeRatio()? >>> >>> This code moved from check_vm_args_consistency() to apply_ergo() >>> since it is a >>> ergonomic decision to change the value of the flag. I don't think >>> this kind of >>> changes should be done while checking argument consistency. >>> verify_MinHeapFreeRatio() is called from check_vm_args_consistency(). >> >> I don't see why it is wrong to check this as argument consistency. >> Clearly >> MinHeapFreeRatio can only be a value between 0 and 99. In my opinion >> that would >> be best to check at startup. > > apply_ergo() is also done during startup, but I see your point. I'll > move the check into verify_MinHeapFreeRatio(). > > Thanks, > /Jesper > >>> >>>> attachListener.cpp >>>> >>>> strncmp(name, "MaxHeapFreeRatio", 17) == 0 >>>> >>>> MaxHeapFreeRatio is 16 characters. Is the 17th character in the >>>> constant always >>>> NULL and this check verifies that I can write >>>> MaxHeapFreeRatioMoreCharacters and >>>> get it to pass the strncmp? >>> >>> Yes, that's what I want to achieve. >> >> OK. Good. >> >>> (I assume that you mean "can't write MaxHeapFreeRatioMoreCharacters".) >> >> Right ;) >> >>> >>>> It would be nice with a JTreg test that sets the flags to valid and >>>> invalid >>>> values and checks that the flags have the right values after this. >>> >>> Dmitry is working on the tests for this feature. I'll ask him to >>> include a few >>> tests for illegal values as well. >> >> OK. >> >>> >>>> Did you have a look at the test/gc/arguments/TestHeapFreeRatio.java >>>> test? Is >>>> that relevant to verify your changes? >>> >>> No, my changes are not tested by TestHeapFreeRatio. I wrote a few >>> lines about >>> why towards the end of my last mail. >> >> Sorry. Missed that. I will go back and check that email. >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> /Jesper >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>>> >>>>> I agree with your assessment that it would be good to implement a >>>>> generic way >>>>> to verify manageable flags. I think it is a separate change though >>>>> so I will >>>>> not attack that problem in this change. >>>>> >>>>> As Mikael wrote in his review we have talked offline about the >>>>> changes and how >>>>> to make them more correct and readable. Thanks Mikael for the input! >>>>> >>>>> More comments inline. >>>>> >>>>> Bengt Rutisson skrev 22/1/14 11:21 AM: >>>>>> >>>>>> Hi Jesper, >>>>>> >>>>>> The calculation in >>>>>> PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() >>>>>> looks wrong to me. I would have expected this: >>>>>> >>>>>> 86 // free = (live*ratio) / (1-ratio) >>>>>> 87 size_t max_free = >>>>>> (size_t)((heap->old_gen()->used_in_bytes() * >>>>>> mhfr_as_percent) / (1.0 - mhfr_as_percent)); >>>>>> >>>>>> to be something like this: >>>>>> >>>>>> size_t max_free = heap->old_gen()->capacity_in_bytes() * >>>>>> mhfr_as_percent; >>>>> >>>>> The suggested formula above will calculate how much free memory >>>>> there can be >>>>> based on the current old gen size. What I want to achieve in the >>>>> code is to >>>>> calculate how much free memory there can be based on the amount of >>>>> live data >>>>> in the old generation. I have talked to Bengt offline and he >>>>> agrees that the >>>>> code is doing what I want it to. I have rewritten the code and >>>>> added more >>>>> comments to explain the formula. >>>>> >>>>>> (A minor naming thing is that mhfr_as_percent is actually not a >>>>>> percent but a >>>>>> ratio or fraction. Just like you write in the comment.) >>>>> >>>>> Right. Fixed. >>>>> >>>>>> We also don't seem to take MinHeapFreeRatio into account. Should >>>>>> we do that? >>>>> >>>>> We should. Good catch! I have added support for MinHeapFreeRatio >>>>> both here and >>>>> in psScavenge.cpp. >>>>> >>>>>> I think it should be possible to write a internal VM test or a >>>>>> whitebox >>>>>> test for >>>>>> the calculated_old_free_size_in_bytes() to verify that it >>>>>> produces the correct >>>>>> results. >>>>> >>>>> I've added an internal test to verify the new code. >>>>> >>>>>> Speaking of testing. There is already a test called >>>>>> test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass >>>>>> with the >>>>>> ParallelGC already before your changes. I think that means that >>>>>> the test is >>>>>> not >>>>>> strict enough. Could you update that test or add a new test to >>>>>> make sure that >>>>>> your changes are tested? >>>>> >>>>> TestHeapFreeRatio only verifies that the VM gives correct error >>>>> messages for >>>>> the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain >>>>> about flags >>>>> that don't affect the chosen GC, there is no error given about >>>>> ParallelGC not >>>>> implementing the heap ratio flags. The code I change is not tested >>>>> by this >>>>> test. Dmitry Fazunenko has developed a test for the new feature >>>>> which I have >>>>> used while developing. This test will be pushed once the feature >>>>> is in place. >>>>> >>>>>> I also agree with Staffan that the methods is_within() and >>>>>> is_min() make it >>>>>> harder to read the code. >>>>> >>>>> Yes, me to... >>>>> I removed them. >>>>> >>>>> Thanks, >>>>> /Jesper >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> >>>>>> >>>>>> On 2014-01-22 09:40, Staffan Larsen wrote: >>>>>>> Jesper, >>>>>>> >>>>>>> This looks ok from a serviceability perspective. Long term we >>>>>>> should probably >>>>>>> have a more pluggable way to verify values of manageable flags >>>>>>> so we can >>>>>>> avoid >>>>>>> some of the duplication. >>>>>>> >>>>>>> I have a slight problem with is_within() and is_min() in that it >>>>>>> is not >>>>>>> obvious from the call site if the min and max values are >>>>>>> inclusive or not >>>>>>> - it >>>>>>> was very obvious before. >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Could I have a few reviews of this change? >>>>>>>> >>>>>>>> Summary: >>>>>>>> To allow applications a more fine grained control over the GC >>>>>>>> over time, >>>>>>>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio >>>>>>>> manageable. >>>>>>>> >>>>>>>> The initial request that lead up to this change involved >>>>>>>> ParallelGC which is >>>>>>>> notoriously unwilling to shrink the heap. Since ParallelGC >>>>>>>> didn't support >>>>>>>> the >>>>>>>> heap free ratio flags, this change also includes implementing >>>>>>>> support for >>>>>>>> these flags in ParallelGC. >>>>>>>> >>>>>>>> Changes have also been made to the argument parsing, attach >>>>>>>> listener and the >>>>>>>> management API to verify the flag values when set through the >>>>>>>> different >>>>>>>> interfaces. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>>>>>>> >>>>>>>> The plan is to push this to 9 and then backport to 8 and 7. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> /Jesper >>>>>> >>>> >> From jaroslav.bachorik at oracle.com Wed Jan 29 13:21:59 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 29 Jan 2014 22:21:59 +0100 Subject: RFR 6656031: SA: jmap -permstat number of classes is off by 1 In-Reply-To: <52B052E6.6010807@oracle.com> References: <52B03B92.8060804@oracle.com> <52B052E6.6010807@oracle.com> Message-ID: <52E970F7.6060301@oracle.com> Could I have a second HS reviewer for this, please? -JB- On 17.12.2013 14:34, Jaroslav Bachorik wrote: > Thanks! I guess I will be needing a second reviewer since the change is > in the hotspot repo. > > -JB- > > On 17.12.2013 14:32, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >> On 17 dec 2013, at 12:54, Jaroslav Bachorik >> wrote: >> >>> Please, review the following fix. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-6656031 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/6656031/webrev.00 >>> >>> The issue is caused by using SystemDictionary.ClassAndLoaderVisitor >>> to traverse the dictionary classes to get the numbers of the loaded >>> classes per classloader. This visitor will visit all the combinations >>> of a particular class and all its classloaders - the defining CL + >>> all initiating CLs. This will cause completely wrong numbers to be >>> reported. >>> >>> The solution is to use SystemDictionary.ClassVisitor which walks only >>> over the loaded classes (each class exactly once) and extract the >>> defining CL from the visited Klass. >>> >>> Thanks, >>> >>> -JB- >> > From jesper.wilhelmsson at oracle.com Wed Jan 29 13:34:22 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 29 Jan 2014 22:34:22 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <20140129213700.000031bf.bernd-2014@eckenfels.net> References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> <52E7AA49.7000808@oracle.com> <52E82A83.7070708@oracle.com> <52E92141.6000207@oracle.com> <20140129213700.000031bf.bernd-2014@eckenfels.net> Message-ID: <52E973DE.8050207@oracle.com> Hi Bernd, This change did not introduce setting the MinHeapFreeRatio to 99, I just moved it to a different place in the code. Currently it is allowed to set Min = Max. I can't say I have given this enough thought to determine if that is good or bad. Anyhow, changing that would affect all collectors so it would have to be done in a separate change. Cheers, /Jesper Bernd Eckenfels skrev 29/1/14 9:37 PM: > Hello, > > I wonder if there is a need to clamp MinHeapFreeRatio to 99, as that > can be similiar unlikely to be achieved (in all cases the Heap will not > grow more than Xmx). Would it be more important to check if MinHeap < > MaxHeap? (which also ensures it can not be 100). > > Bernd > > > Am Wed, 29 Jan 2014 16:41:53 +0100 > schrieb Bengt Rutisson : > >> >> Hi Jesper, >> >> On 1/28/14 11:09 PM, Jesper Wilhelmsson wrote: >>> Bengt, >>> >>> Thanks for looking at the change. >>> Answers inline. >>> >>> Bengt Rutisson skrev 28/1/14 2:02 PM: >>>> >>>> Hi Jesper, >>>> >>>> On 2014-01-27 21:46, Jesper Wilhelmsson wrote: >>>>> Staffan, Bengt, Mikael, >>>>> >>>>> Thanks for the reviews! >>>>> >>>>> I have made the changes you have suggested and a new webrev is >>>>> available at: >>>>> >>>>> http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ >>>> >>>> Can you explain this code in psScavenge.cpp a bit? I am not sure I >>>> understand >>>> what it wants to achieve and how it works if I have set NewSize >>>> and/or MaxNewSize on the command line. >>>> >>>> 532 size_t max_young_size = young_gen->max_size(); >>>> 533 if (MinHeapFreeRatio != 0 || MaxHeapFreeRatio != >>>> 100) { 534 max_young_size = >>>> MIN2(old_gen->capacity_in_bytes() / NewRatio, >>>> young_gen->max_size()); >>>> 535 } >>> >>> The intention of this code is to constrain the young space if >>> someone is using the heap free ratio flags. Since it is a bit weird >>> to talk about a "free ratio" in the young space, we use the heap >>> free ratios to determine the size of the old generation, and then >>> we use NewRatio to scale the young generation accordingly. >>> >>> The use of NewSize and MaxNewSize shouldn't affect this decision at >>> this point. They are mainly used to set the initial sizes and >>> limits for the young generation which will be respected as we use >>> the MIN of the NewRatio calculation and the young_gen->max_size(). >> >> I agree that it is hard to define "free" for the young gen. But this >> looks kind of strange to me. We guard the setting of max_young_size >> with both MinHeapFreeRatio or MaxHeapFreeRatio but we don't use any >> of them in the calculation. >> >> We use the max_young_size for two purposes: calculating the survivor >> size and calculating the eden size. Maybe we can split it up somehow >> to get understandable logic. I'll think a bit more about this and >> come back later tonight with some comments. >> >>> >>> This code should however only be executed if using adaptive size >>> policy so I will add that to the if-statement. >> >> That won't be necessary. That whole section is guarded by >> UseAdaptiveSizePolicy. >> >>> >>>> In arguments.cpp: >>>> >>>> 1572 if (UseAdaptiveSizePolicy) { >>>> 1573 // We don't want to limit adaptive heap sizing's freedom >>>> to adjust the >>>> heap >>>> 1574 // unless the user actually sets these flags. >>>> 1575 if (FLAG_IS_DEFAULT(MinHeapFreeRatio)) { >>>> 1576 FLAG_SET_DEFAULT(MinHeapFreeRatio, 0); >>>> 1577 } >>>> 1578 if (FLAG_IS_DEFAULT(MaxHeapFreeRatio)) { >>>> 1579 FLAG_SET_DEFAULT(MaxHeapFreeRatio, 100); >>>> 1580 } >>>> 1581 } >>>> >>>> Should these be FLAG_SET_ERGO instead? Not sure. Just asking. >>> >>> I went back and forth on this one, but decided that I wanted to >>> express that if using adaptive size policy, the default values of >>> these flags should be different. I think it would work perfectly >>> fine if using FLAG_SET_ERGO instead but I'm thinking that this is >>> not really an ergonomic decision, but rather due to a different >>> implementation. >> >> OK. I am also undecided on what's best, so let's leave it as it is. >> >>> >>>> 3705 if (MinHeapFreeRatio == 100) { >>>> 3706 // Keeping the heap 100% free is hard ;-) so limit it to >>>> 99%. 3707 FLAG_SET_ERGO(uintx, MinHeapFreeRatio, 99); >>>> 3708 } >>>> >>>> Couldn't this just be part of Arguments::verify_MinHeapFreeRatio()? >>> >>> This code moved from check_vm_args_consistency() to apply_ergo() >>> since it is a ergonomic decision to change the value of the flag. I >>> don't think this kind of changes should be done while checking >>> argument consistency. verify_MinHeapFreeRatio() is called from >>> check_vm_args_consistency(). >> >> I don't see why it is wrong to check this as argument consistency. >> Clearly MinHeapFreeRatio can only be a value between 0 and 99. In my >> opinion that would be best to check at startup. >> >>> >>>> attachListener.cpp >>>> >>>> strncmp(name, "MaxHeapFreeRatio", 17) == 0 >>>> >>>> MaxHeapFreeRatio is 16 characters. Is the 17th character in the >>>> constant always >>>> NULL and this check verifies that I can write >>>> MaxHeapFreeRatioMoreCharacters and >>>> get it to pass the strncmp? >>> >>> Yes, that's what I want to achieve. >> >> OK. Good. >> >>> (I assume that you mean "can't write >>> MaxHeapFreeRatioMoreCharacters".) >> >> Right ;) >> >>> >>>> It would be nice with a JTreg test that sets the flags to valid >>>> and invalid >>>> values and checks that the flags have the right values after this. >>> >>> Dmitry is working on the tests for this feature. I'll ask him to >>> include a few tests for illegal values as well. >> >> OK. >> >>> >>>> Did you have a look at the >>>> test/gc/arguments/TestHeapFreeRatio.java test? Is >>>> that relevant to verify your changes? >>> >>> No, my changes are not tested by TestHeapFreeRatio. I wrote a few >>> lines about why towards the end of my last mail. >> >> Sorry. Missed that. I will go back and check that email. >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> /Jesper >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>>> >>>>> I agree with your assessment that it would be good to implement a >>>>> generic way >>>>> to verify manageable flags. I think it is a separate change >>>>> though so I will >>>>> not attack that problem in this change. >>>>> >>>>> As Mikael wrote in his review we have talked offline about the >>>>> changes and how >>>>> to make them more correct and readable. Thanks Mikael for the >>>>> input! >>>>> >>>>> More comments inline. >>>>> >>>>> Bengt Rutisson skrev 22/1/14 11:21 AM: >>>>>> >>>>>> Hi Jesper, >>>>>> >>>>>> The calculation in >>>>>> PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() >>>>>> looks wrong to me. I would have expected this: >>>>>> >>>>>> 86 // free = (live*ratio) / (1-ratio) >>>>>> 87 size_t max_free = >>>>>> (size_t)((heap->old_gen()->used_in_bytes() * >>>>>> mhfr_as_percent) / (1.0 - mhfr_as_percent)); >>>>>> >>>>>> to be something like this: >>>>>> >>>>>> size_t max_free = heap->old_gen()->capacity_in_bytes() * >>>>>> mhfr_as_percent; >>>>> >>>>> The suggested formula above will calculate how much free memory >>>>> there can be >>>>> based on the current old gen size. What I want to achieve in the >>>>> code is to >>>>> calculate how much free memory there can be based on the amount >>>>> of live data >>>>> in the old generation. I have talked to Bengt offline and he >>>>> agrees that the >>>>> code is doing what I want it to. I have rewritten the code and >>>>> added more >>>>> comments to explain the formula. >>>>> >>>>>> (A minor naming thing is that mhfr_as_percent is actually not a >>>>>> percent but a >>>>>> ratio or fraction. Just like you write in the comment.) >>>>> >>>>> Right. Fixed. >>>>> >>>>>> We also don't seem to take MinHeapFreeRatio into account. Should >>>>>> we do that? >>>>> >>>>> We should. Good catch! I have added support for MinHeapFreeRatio >>>>> both here and >>>>> in psScavenge.cpp. >>>>> >>>>>> I think it should be possible to write a internal VM test or a >>>>>> whitebox test for >>>>>> the calculated_old_free_size_in_bytes() to verify that it >>>>>> produces the correct >>>>>> results. >>>>> >>>>> I've added an internal test to verify the new code. >>>>> >>>>>> Speaking of testing. There is already a test called >>>>>> test/gc/arguments/TestHeapFreeRatio.java. That test seems to >>>>>> pass with the >>>>>> ParallelGC already before your changes. I think that means that >>>>>> the test is not >>>>>> strict enough. Could you update that test or add a new test to >>>>>> make sure that >>>>>> your changes are tested? >>>>> >>>>> TestHeapFreeRatio only verifies that the VM gives correct error >>>>> messages for >>>>> the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain >>>>> about flags >>>>> that don't affect the chosen GC, there is no error given about >>>>> ParallelGC not >>>>> implementing the heap ratio flags. The code I change is not >>>>> tested by this >>>>> test. Dmitry Fazunenko has developed a test for the new feature >>>>> which I have >>>>> used while developing. This test will be pushed once the feature >>>>> is in place. >>>>> >>>>>> I also agree with Staffan that the methods is_within() and >>>>>> is_min() make it >>>>>> harder to read the code. >>>>> >>>>> Yes, me to... >>>>> I removed them. >>>>> >>>>> Thanks, >>>>> /Jesper >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> >>>>>> >>>>>> On 2014-01-22 09:40, Staffan Larsen wrote: >>>>>>> Jesper, >>>>>>> >>>>>>> This looks ok from a serviceability perspective. Long term we >>>>>>> should probably >>>>>>> have a more pluggable way to verify values of manageable flags >>>>>>> so we can avoid >>>>>>> some of the duplication. >>>>>>> >>>>>>> I have a slight problem with is_within() and is_min() in that >>>>>>> it is not >>>>>>> obvious from the call site if the min and max values are >>>>>>> inclusive or not - it >>>>>>> was very obvious before. >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Could I have a few reviews of this change? >>>>>>>> >>>>>>>> Summary: >>>>>>>> To allow applications a more fine grained control over the GC >>>>>>>> over time, >>>>>>>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio >>>>>>>> manageable. >>>>>>>> >>>>>>>> The initial request that lead up to this change involved >>>>>>>> ParallelGC which is >>>>>>>> notoriously unwilling to shrink the heap. Since ParallelGC >>>>>>>> didn't support the >>>>>>>> heap free ratio flags, this change also includes implementing >>>>>>>> support for >>>>>>>> these flags in ParallelGC. >>>>>>>> >>>>>>>> Changes have also been made to the argument parsing, attach >>>>>>>> listener and the >>>>>>>> management API to verify the flag values when set through the >>>>>>>> different >>>>>>>> interfaces. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>>>>>>> >>>>>>>> The plan is to push this to 9 and then backport to 8 and 7. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> /Jesper >>>>>> >>>> >> > From jesper.wilhelmsson at oracle.com Wed Jan 29 13:35:51 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 29 Jan 2014 22:35:51 +0100 Subject: RFR: 8028391 - Make the Min/MaxHeapFreeRatio flags manageable In-Reply-To: <52E96E06.8080906@oracle.com> References: <52DEEB5F.6020306@oracle.com> <4E837119-7E3F-4611-ACFD-E8FD2D683478@oracle.com> <52DF9B96.8050901@oracle.com> <52E6C589.9030007@oracle.com> <52E7AA49.7000808@oracle.com> <52E82A83.7070708@oracle.com> <52E92141.6000207@oracle.com> <52E963A0.90704@oracle.com> <52E96E06.8080906@oracle.com> Message-ID: <52E97437.5080407@oracle.com> Thanks for the review Bengt! The RFE is filed here: https://bugs.openjdk.java.net/browse/JDK-8033206 /Jesper Bengt Rutisson skrev 29/1/14 10:09 PM: > > Hi everyone, > > I just talked this through with Jesper. > > I'm fine with the latest webrev. To size the young gen the code relies on that > an old GC has happened. Currently there is nothing that guarantees this, so the > implementation kind of relies on the application to call System.gc() to get the > desired effect. That works for the current use case (using the management APIs > to set the values) but may not work well for someone how just sets the values on > the command line. > > An alternative would be to check Min/MaxHeapFreeRatio at the end of a scavenge > and trigger an old collection if the limits have been exceeded. That way the > code would be more self sustained. Jesper will file a separate RFE for that. > > Bengt > > On 1/29/14 9:25 PM, Jesper Wilhelmsson wrote: >> Hi Bengt, >> >> Just a short clarification inline. Looking forward to your comments later today. >> >> Bengt Rutisson skrev 29/1/14 4:41 PM: >>> >>> Hi Jesper, >>> >>> On 1/28/14 11:09 PM, Jesper Wilhelmsson wrote: >>>> Bengt, >>>> >>>> Thanks for looking at the change. >>>> Answers inline. >>>> >>>> Bengt Rutisson skrev 28/1/14 2:02 PM: >>>>> >>>>> Hi Jesper, >>>>> >>>>> On 2014-01-27 21:46, Jesper Wilhelmsson wrote: >>>>>> Staffan, Bengt, Mikael, >>>>>> >>>>>> Thanks for the reviews! >>>>>> >>>>>> I have made the changes you have suggested and a new webrev is available at: >>>>>> >>>>>> http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.5/ >>>>> >>>>> Can you explain this code in psScavenge.cpp a bit? I am not sure I understand >>>>> what it wants to achieve and how it works if I have set NewSize and/or >>>>> MaxNewSize on the command line. >>>>> >>>>> 532 size_t max_young_size = young_gen->max_size(); >>>>> 533 if (MinHeapFreeRatio != 0 || MaxHeapFreeRatio != 100) { >>>>> 534 max_young_size = MIN2(old_gen->capacity_in_bytes() / NewRatio, >>>>> young_gen->max_size()); >>>>> 535 } >>>> >>>> The intention of this code is to constrain the young space if someone is using >>>> the heap free ratio flags. Since it is a bit weird to talk about a "free >>>> ratio" in the young space, we use the heap free ratios to determine the size >>>> of the old generation, and then we use NewRatio to scale the young generation >>>> accordingly. >>>> >>>> The use of NewSize and MaxNewSize shouldn't affect this decision at this >>>> point. They are mainly used to set the initial sizes and limits for the young >>>> generation which will be respected as we use the MIN of the NewRatio >>>> calculation and the young_gen->max_size(). >>> >>> I agree that it is hard to define "free" for the young gen. But this looks kind >>> of strange to me. We guard the setting of max_young_size with both >>> MinHeapFreeRatio or MaxHeapFreeRatio but we don't use any of them in the >>> calculation. >> >> In psScavenge.cpp the flags MinHeapFreeRatio and MaxHeapFreeRatio is only used >> to determine *if* we should limit the young gen size. >> >> The flags are used to determine the size of the old generation. Then we scale >> the young generation based on the limited old size using the NewRatio flag. >> >> I will add the following comment before the new if-statement: >> >> // Deciding a free ratio in the young generation is tricky, so if >> // MinHeapFreeRatio or MaxHeapFreeRatio are in use (implicating >> // that the old generation size may have been limited because of them) we >> // should then limit our young generation size using NewRatio to have it >> // follow the old generation size. >> >> >>> We use the max_young_size for two purposes: calculating the survivor size and >>> calculating the eden size. Maybe we can split it up somehow to get >>> understandable logic. I'll think a bit more about this and come back later >>> tonight with some comments. >> >> invoke_no_policy() is a huge method and clearly it would benefit the code to >> split it into smaller parts. I'm not sure this particular part is the most >> urgent to refactor though, plus I didn't want to mix this change with a lot of >> cleanup. >> >> The logic of the sizing calculation is not really changed more than the >> possible adjustment of the upper limit of the young size. Instead of using the >> hard upper limit of the young generation, we use the NewRatio-based size if >> it's smaller. The young gen has two parts that needs to be resized, eden and >> survivors. Both use the same limited young gen size for their size >> calculations in the same way as they before used the young gen max size. >> >> There is only one other use of young_gen->max_size() in this code. This is an >> assert that verifies that the parts of the young gen doesn't exceed the hard >> upper limit. I think this one should still look at the real limit, and not the >> calculated one. >> >>>> >>>> This code should however only be executed if using adaptive size policy so I >>>> will add that to the if-statement. >>> >>> That won't be necessary. That whole section is guarded by UseAdaptiveSizePolicy. >> >> Indeed it is. I noticed the check in line 561 and thought "Hey, this code also >> needs that check", but it seems the check should be removed from line 561 >> instead. :-) >> >>>> >>>>> In arguments.cpp: >>>>> >>>>> 1572 if (UseAdaptiveSizePolicy) { >>>>> 1573 // We don't want to limit adaptive heap sizing's freedom to adjust >>>>> the >>>>> heap >>>>> 1574 // unless the user actually sets these flags. >>>>> 1575 if (FLAG_IS_DEFAULT(MinHeapFreeRatio)) { >>>>> 1576 FLAG_SET_DEFAULT(MinHeapFreeRatio, 0); >>>>> 1577 } >>>>> 1578 if (FLAG_IS_DEFAULT(MaxHeapFreeRatio)) { >>>>> 1579 FLAG_SET_DEFAULT(MaxHeapFreeRatio, 100); >>>>> 1580 } >>>>> 1581 } >>>>> >>>>> Should these be FLAG_SET_ERGO instead? Not sure. Just asking. >>>> >>>> I went back and forth on this one, but decided that I wanted to express that >>>> if using adaptive size policy, the default values of these flags should be >>>> different. I think it would work perfectly fine if using FLAG_SET_ERGO instead >>>> but I'm thinking that this is not really an ergonomic decision, but rather due >>>> to a different implementation. >>> >>> OK. I am also undecided on what's best, so let's leave it as it is. >>> >>>> >>>>> 3705 if (MinHeapFreeRatio == 100) { >>>>> 3706 // Keeping the heap 100% free is hard ;-) so limit it to 99%. >>>>> 3707 FLAG_SET_ERGO(uintx, MinHeapFreeRatio, 99); >>>>> 3708 } >>>>> >>>>> Couldn't this just be part of Arguments::verify_MinHeapFreeRatio()? >>>> >>>> This code moved from check_vm_args_consistency() to apply_ergo() since it is a >>>> ergonomic decision to change the value of the flag. I don't think this kind of >>>> changes should be done while checking argument consistency. >>>> verify_MinHeapFreeRatio() is called from check_vm_args_consistency(). >>> >>> I don't see why it is wrong to check this as argument consistency. Clearly >>> MinHeapFreeRatio can only be a value between 0 and 99. In my opinion that would >>> be best to check at startup. >> >> apply_ergo() is also done during startup, but I see your point. I'll move the >> check into verify_MinHeapFreeRatio(). >> >> Thanks, >> /Jesper >> >>>> >>>>> attachListener.cpp >>>>> >>>>> strncmp(name, "MaxHeapFreeRatio", 17) == 0 >>>>> >>>>> MaxHeapFreeRatio is 16 characters. Is the 17th character in the constant >>>>> always >>>>> NULL and this check verifies that I can write >>>>> MaxHeapFreeRatioMoreCharacters and >>>>> get it to pass the strncmp? >>>> >>>> Yes, that's what I want to achieve. >>> >>> OK. Good. >>> >>>> (I assume that you mean "can't write MaxHeapFreeRatioMoreCharacters".) >>> >>> Right ;) >>> >>>> >>>>> It would be nice with a JTreg test that sets the flags to valid and invalid >>>>> values and checks that the flags have the right values after this. >>>> >>>> Dmitry is working on the tests for this feature. I'll ask him to include a few >>>> tests for illegal values as well. >>> >>> OK. >>> >>>> >>>>> Did you have a look at the test/gc/arguments/TestHeapFreeRatio.java test? Is >>>>> that relevant to verify your changes? >>>> >>>> No, my changes are not tested by TestHeapFreeRatio. I wrote a few lines about >>>> why towards the end of my last mail. >>> >>> Sorry. Missed that. I will go back and check that email. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> /Jesper >>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>>> >>>>>> I agree with your assessment that it would be good to implement a generic way >>>>>> to verify manageable flags. I think it is a separate change though so I will >>>>>> not attack that problem in this change. >>>>>> >>>>>> As Mikael wrote in his review we have talked offline about the changes and >>>>>> how >>>>>> to make them more correct and readable. Thanks Mikael for the input! >>>>>> >>>>>> More comments inline. >>>>>> >>>>>> Bengt Rutisson skrev 22/1/14 11:21 AM: >>>>>>> >>>>>>> Hi Jesper, >>>>>>> >>>>>>> The calculation in PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() >>>>>>> looks wrong to me. I would have expected this: >>>>>>> >>>>>>> 86 // free = (live*ratio) / (1-ratio) >>>>>>> 87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() * >>>>>>> mhfr_as_percent) / (1.0 - mhfr_as_percent)); >>>>>>> >>>>>>> to be something like this: >>>>>>> >>>>>>> size_t max_free = heap->old_gen()->capacity_in_bytes() * mhfr_as_percent; >>>>>> >>>>>> The suggested formula above will calculate how much free memory there can be >>>>>> based on the current old gen size. What I want to achieve in the code is to >>>>>> calculate how much free memory there can be based on the amount of live data >>>>>> in the old generation. I have talked to Bengt offline and he agrees that the >>>>>> code is doing what I want it to. I have rewritten the code and added more >>>>>> comments to explain the formula. >>>>>> >>>>>>> (A minor naming thing is that mhfr_as_percent is actually not a percent >>>>>>> but a >>>>>>> ratio or fraction. Just like you write in the comment.) >>>>>> >>>>>> Right. Fixed. >>>>>> >>>>>>> We also don't seem to take MinHeapFreeRatio into account. Should we do that? >>>>>> >>>>>> We should. Good catch! I have added support for MinHeapFreeRatio both here >>>>>> and >>>>>> in psScavenge.cpp. >>>>>> >>>>>>> I think it should be possible to write a internal VM test or a whitebox >>>>>>> test for >>>>>>> the calculated_old_free_size_in_bytes() to verify that it produces the >>>>>>> correct >>>>>>> results. >>>>>> >>>>>> I've added an internal test to verify the new code. >>>>>> >>>>>>> Speaking of testing. There is already a test called >>>>>>> test/gc/arguments/TestHeapFreeRatio.java. That test seems to pass with the >>>>>>> ParallelGC already before your changes. I think that means that the test is >>>>>>> not >>>>>>> strict enough. Could you update that test or add a new test to make sure >>>>>>> that >>>>>>> your changes are tested? >>>>>> >>>>>> TestHeapFreeRatio only verifies that the VM gives correct error messages for >>>>>> the -Xminf and -Xmaxf flags. Since HotSpot usually don't complain about flags >>>>>> that don't affect the chosen GC, there is no error given about ParallelGC not >>>>>> implementing the heap ratio flags. The code I change is not tested by this >>>>>> test. Dmitry Fazunenko has developed a test for the new feature which I have >>>>>> used while developing. This test will be pushed once the feature is in place. >>>>>> >>>>>>> I also agree with Staffan that the methods is_within() and is_min() make it >>>>>>> harder to read the code. >>>>>> >>>>>> Yes, me to... >>>>>> I removed them. >>>>>> >>>>>> Thanks, >>>>>> /Jesper >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2014-01-22 09:40, Staffan Larsen wrote: >>>>>>>> Jesper, >>>>>>>> >>>>>>>> This looks ok from a serviceability perspective. Long term we should >>>>>>>> probably >>>>>>>> have a more pluggable way to verify values of manageable flags so we can >>>>>>>> avoid >>>>>>>> some of the duplication. >>>>>>>> >>>>>>>> I have a slight problem with is_within() and is_min() in that it is not >>>>>>>> obvious from the call site if the min and max values are inclusive or not >>>>>>>> - it >>>>>>>> was very obvious before. >>>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>> On 21 jan 2014, at 22:49, Jesper Wilhelmsson >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Could I have a few reviews of this change? >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> To allow applications a more fine grained control over the GC over time, >>>>>>>>> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable. >>>>>>>>> >>>>>>>>> The initial request that lead up to this change involved ParallelGC >>>>>>>>> which is >>>>>>>>> notoriously unwilling to shrink the heap. Since ParallelGC didn't support >>>>>>>>> the >>>>>>>>> heap free ratio flags, this change also includes implementing support for >>>>>>>>> these flags in ParallelGC. >>>>>>>>> >>>>>>>>> Changes have also been made to the argument parsing, attach listener >>>>>>>>> and the >>>>>>>>> management API to verify the flag values when set through the different >>>>>>>>> interfaces. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028391/webrev.4/ >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028391 >>>>>>>>> >>>>>>>>> The plan is to push this to 9 and then backport to 8 and 7. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> /Jesper >>>>>>> >>>>> >>> > From david.holmes at oracle.com Wed Jan 29 17:38:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jan 2014 11:38:46 +1000 Subject: RFR 6656031: SA: jmap -permstat number of classes is off by 1 In-Reply-To: <52E970F7.6060301@oracle.com> References: <52B03B92.8060804@oracle.com> <52B052E6.6010807@oracle.com> <52E970F7.6060301@oracle.com> Message-ID: <52E9AD26.5030401@oracle.com> Looks good to me. Makes sense to only count classes defined by the loader. David On 30/01/2014 7:21 AM, Jaroslav Bachorik wrote: > Could I have a second HS reviewer for this, please? > > -JB- > > On 17.12.2013 14:34, Jaroslav Bachorik wrote: >> Thanks! I guess I will be needing a second reviewer since the change is >> in the hotspot repo. >> >> -JB- >> >> On 17.12.2013 14:32, Staffan Larsen wrote: >>> Looks good! >>> >>> Thanks, >>> /Staffan >>> >>> On 17 dec 2013, at 12:54, Jaroslav Bachorik >>> wrote: >>> >>>> Please, review the following fix. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-6656031 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6656031/webrev.00 >>>> >>>> The issue is caused by using SystemDictionary.ClassAndLoaderVisitor >>>> to traverse the dictionary classes to get the numbers of the loaded >>>> classes per classloader. This visitor will visit all the combinations >>>> of a particular class and all its classloaders - the defining CL + >>>> all initiating CLs. This will cause completely wrong numbers to be >>>> reported. >>>> >>>> The solution is to use SystemDictionary.ClassVisitor which walks only >>>> over the loaded classes (each class exactly once) and extract the >>>> defining CL from the visited Klass. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From suenaga.yasumasa at lab.ntt.co.jp Wed Jan 29 23:08:11 2014 From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga) Date: Thu, 30 Jan 2014 16:08:11 +0900 Subject: JDK-7090324: gclog rotation via external tool In-Reply-To: <52E9248D.2090108@ysfactory.dip.jp> References: <52483BDB.8040206@ysfactory.dip.jp> <52496A21.8080608@ysfactory.dip.jp> <527CDD56.7080106@ysfactory.dip.jp> <52A09642.4030609@ysfactory.dip.jp> <52E26FA2.40909@ysfactory.dip.jp> <0E26045D-F7F9-49BC-AB36-A42C1DC6E64E@oracle.com> <52E91000.9010600@ysfactory.dip.jp> <52E91AAA.3060008@oracle.com> <52E9248D.2090108@ysfactory.dip.jp> Message-ID: <52E9FA5B.6010306@lab.ntt.co.jp> Hi Erik, Staffan, I've uploaded new webrev. Could you review this ? http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.02/ This patch includes fixes from comments of Staffan and Erik. And I created new test of this patch as Test7090324 . This test works fine with jtreg. Thanks, Yasumasa On 2014/01/30 0:55, Yasumasa Suenaga wrote: > Hi Erik, > > On 2014/01/30 0:13, Erik Helin wrote: >> Hi Yasumasa, >> >> (have to use HTML email to get a width of more than 78 chars, sorry) >> >> why did you change the code in arguments.cpp in the method check_gc_log_consistency? > > In current implementation, check_gclog_consistency() checks three parameters: > > - GC log filename > - NumberOfGCLogFiles > - GCLogFileSize > > My customer uses external trigger "ONLY" for rotating logs. > If they want to do that, GCLogFileSize does not need. > > >> Next, the gcLogFileStream::rotate_log method now does a lot of things. >> Could you separate out the first block into a new method, >> gcLogFileStream::should_rotate(bool force)? >> >> This was, the code would read: >> >> > bool gcLogFileStream::should_rotate(bool force) { >> > return force || _bytes_writen >= GCLogFileSize; >> > } >> > >> > void gcLogFileStream::rotate_log(bool force) { >> > char time_msg[FILENAMEBUFLEN]; >> > char time_str[EXTRACHARLEN]; >> > char current_file_name[FILENAMEBUFLEN]; >> > char renamed_file_name[FILENAMEBUFLEN]; >> > >> > if (!should_rotate(force)) { >> > return; >> > } >> > >> > ... >> > } >> >> Could you please update your patch? > > I will do that. > > >> There is a new empty line in the rotate_log method: >> >> > } >> > + >> > #ifdef ASSERT >> >> could you please remove it? > > I will do that. > > >> The logging change in rotate_log uses a different kind of if/else syntax >> than the rest of the file: >> >> > if (force) { >> > ... >> > } >> > else { >> > ... >> > } >> >> The other if/else statements in the file uses: >> >> > if (cond) { >> > ... >> > } else { >> > ... >> > } >> >> Could you please update your change to use the same if/else syntax? > > I will do that. > > >> This part of the change duplicates the code: >> >> + jio_snprintf(time_msg, sizeof(time_msg), "%s GC log rotation request has been received. Saved as %s\n", >> + os::local_time_string((char *)time_str, sizeof(time_str)), >> + renamed_file_name); >> + } >> + else { >> + jio_snprintf(time_msg, sizeof(time_msg), "%s GC log file has reached the" >> " maximum size. Saved as %s\n", >> - os::local_time_string((char *)time_str, sizeof(time_str)), >> + os::local_time_string((char *)time_str, sizeof(time_str)), >> renamed_file_name); >> >> Could you instead just change the message, as in: >> >> > const char* msg = forced ? "%s GC log rotation request has been received. Saved as %s\n" : >> > "%s GC log file has reached the maximum size. Saved as %s\n"; >> > jio_snprintf(msg, os::local_time_string((char *)time_str, sizeof(time_str)), renamed_file_name); > > I will do that. > > >> The declaration of rotate_log in ostream.hpp still uses the old >> variable name is_force, it should use force, >> just as the definition. > > Sorry, I will fix it. > > >> Finally, could you add a test that tests your change? Have a look at the other tests >> in hotspot/test/gc to see how you can do it >> (you might want to use some functionality from hotspot/test/testlibrary). > > I found three tests as following: > > [ysuenaga at xelvis test]$ find . -iname "*jcmd*" > ./runtime/NMT/JcmdWithNMTDisabled.java > ./runtime/NMT/JcmdScale.java > ./gc/TestG1ZeroPGCTJcmdThreadPrint.java > > I understand that these tests checks output (stdout/stderr) with OutputAnalyzer. > However, my patch affects target VM. So I guess current test cannot check > that GC log rotation is succeeded. > > Should I make test which checks exit value of jcmd ? > > > Thanks, > > Yasumasa > >> Thanks, >> Erik >> >> On 2014-01-29 15:28, Yasumasa Suenaga wrote: >>> Hi Staffan, >>> >>> Thank you for reviewing! >>> I've uploaded new webrev. >>> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.01/ >>> >>> On 2014/01/29 20:56, Staffan Larsen wrote: >>>> Yasumasa, >>>> >>>> src/share/vm/runtime/arguments.cpp >>>> no comments >>>> >>>> src/share/vm/runtime/safepoint.cpp >>>> I was surprised that gc log size was checked after each safe point. That seems an uneccssary burden to place on a safe point. Instead we should switch to a periodic task that checks the gc log size. However, this is unrelated to you patch, so please ignore for now. >>> >>> Agree. >>> However, I think that PeriodicTask also is not appropriate for this. >>> >>> Size of GC log file is increased when GC is occurred. >>> So I think rotate function should be called at entry of each GC events >>> e.g. VM_GC_Operation::doit_prologue() etc... >>> >>> >>>> src/share/vm/runtime/vm_operations.hpp >>>> line 402: nit: missing space before { >>> >>> Fixed. >>> >>> >>>> line 405: I think ?force? is a better name than ?is_force? >>> >>> I removed "force" option from DCmd. >>> So I removed this from VMOperation. >>> >>> >>>> src/share/vm/services/diagnosticCommand.cpp >>>> line 666: What does this do without the -force option? It looks to me that the non-force case will happen after each safe point (see above) and that there is no need to ever do this from a diagnostic command. Can we remove the option? >>> >>> Indeed. >>> I removed "force" option. >>> >>> >>>> line 677: ?Target VM does not support GC log file rotation." >>> >>> Fixed. >>> >>> >>>> nits: some missing spaces before ?{' and after ?if' >>> >>> Fixed. >>> >>> >>>> src/share/vm/services/diagnosticCommand.hpp >>>> I think RotateGCLogDCmd should require the ?control? permission when executed via JMX, so please add: >>>> static const JavaPermission permission() { >>>> JavaPermission p = {"java.lang.management.ManagementPermission", >>>> "control", NULL}; >>>> return p; >>>> } >>> >>> Added. >>> >>> >>>> line 394: Maybe ?Force the GC log file to be rotated.? is a better description? >>> >>> Fixed. >>> >>> >>>> src/share/vm/utilities/ostream.cpp >>>> line 662: I think ?force? is a better name than ?is_force? >>>> line 668: The comment says exactly the same thing as the code so I think it can be skipped >>>> line 671: ?GC log file rotation occurs by external trigger ONLY." >>>> line 675: "not need? -> ?no need? >>>> line 718: "GC log rotation request has been received? >>> >>> Fixed them. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> src/share/vm/utilities/ostream.hpp >>>> no comments >>>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 24 jan 2014, at 14:50, Yasumasa Suenaga wrote: >>>> >>>>> Hi all, >>>>> >>>>> I've created webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ >>>>> >>>>> This patch works fine on current jdk9/hs-rt . >>>>> Could you review this? >>>>> >>>>> >>>>> I am just an Author. So I need a sponsor. >>>>> Could you help me? >>>>> >>>>> >>>>> Please cooperate. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2013/12/06 0:05, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Did someone read my email? >>>>>> I really hope to merge "JDK-7090324: gclog rotation via external tool" . >>>>>> >>>>>> I hear that someone need this RFE. So I want to discuss about this. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> On 2013/11/08 21:47, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Did someone read my mail? >>>>>>> >>>>>>> I think that this RFE helps us to watch Java heap on production system. >>>>>>> Also I think this RFE is able to be part of the JEP 158 (Unified JVM Logging) . >>>>>>> >>>>>>> I want to update this RFE in JDK Bug System, but I don't have account. >>>>>>> So I've posted email at first. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2013/09/30 21:10, Yasumasa Suenaga wrote: >>>>>>>> In previous email, I've attached new patch for this RFE. >>>>>>>> It works fine with current hsx. >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> On 2013/09/29 23:40, Yasu wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> We are using "logrotate" tool on RHEL for various log rotation. >>>>>>>>> Current HotSpot has gclog rotation function for log size base, >>>>>>>>> however I need to rotate gc log synchronizing with logrotate tool. >>>>>>>>> >>>>>>>>> So I've created RFE as "JDK-7090324: gclog rotation via external tool" . >>>>>>>>> And Sr. Engineering Manager in Oracle said he use the essence of my patch in one >>>>>>>>> of the jcmd subcommands. >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274.html >>>>>>>>> >>>>>>>>> 2 years ago, I posted a patch for this RFE. >>>>>>>>> But this patch is too old to apply for current HotSpot. >>>>>>>>> >>>>>>>>> In last month, a similar discussion was appeared in ML. >>>>>>>>> So I think it's time to discuss this RFE. >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Please cooperate. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Yasumasa >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From staffan.larsen at oracle.com Thu Jan 30 00:23:59 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Jan 2014 09:23:59 +0100 Subject: JDK-7090324: gclog rotation via external tool In-Reply-To: <52E9FA5B.6010306@lab.ntt.co.jp> References: <52483BDB.8040206@ysfactory.dip.jp> <52496A21.8080608@ysfactory.dip.jp> <527CDD56.7080106@ysfactory.dip.jp> <52A09642.4030609@ysfactory.dip.jp> <52E26FA2.40909@ysfactory.dip.jp> <0E26045D-F7F9-49BC-AB36-A42C1DC6E64E@oracle.com> <52E91000.9010600@ysfactory.dip.jp> <52E91AAA.3060008@oracle.com> <52E9248D.2090108@ysfactory.dip.jp> <52E9FA5B.6010306@lab.ntt.co.jp> Message-ID: <5B189F0A-7408-47C7-9719-DC2990355209@oracle.com> Would it be possible for the Diagnostic Command to output the location of the rotated log? When invoking the command it would be good to get some kind of feedback. test/gc/7090324/Test7090324.java: - I think this needs to have the Oracle copyright notice as well. - Tests should now use descriptive names, not bug numbers: https://wiki.openjdk.java.net/display/HotSpot/Naming+HotSpot+JTReg+Tests - nits: lots of missing spaces before ?{?, and after ?for?, ?if? - line 47: you don?t need to clean up old files, jtreg will give you a fresh scratch directory to run in /Staffan On 30 jan 2014, at 08:08, Yasumasa Suenaga wrote: > Hi Erik, Staffan, > > I've uploaded new webrev. Could you review this ? > http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.02/ > > This patch includes fixes from comments of Staffan and Erik. > > And I created new test of this patch as Test7090324 . > This test works fine with jtreg. > > > Thanks, > > Yasumasa > > On 2014/01/30 0:55, Yasumasa Suenaga wrote: >> Hi Erik, >> >> On 2014/01/30 0:13, Erik Helin wrote: >>> Hi Yasumasa, >>> >>> (have to use HTML email to get a width of more than 78 chars, sorry) >>> >>> why did you change the code in arguments.cpp in the method check_gc_log_consistency? >> >> In current implementation, check_gclog_consistency() checks three parameters: >> >> - GC log filename >> - NumberOfGCLogFiles >> - GCLogFileSize >> >> My customer uses external trigger "ONLY" for rotating logs. >> If they want to do that, GCLogFileSize does not need. >> >> >>> Next, the gcLogFileStream::rotate_log method now does a lot of things. >>> Could you separate out the first block into a new method, >>> gcLogFileStream::should_rotate(bool force)? >>> >>> This was, the code would read: >>> >>> > bool gcLogFileStream::should_rotate(bool force) { >>> > return force || _bytes_writen >= GCLogFileSize; >>> > } >>> > >>> > void gcLogFileStream::rotate_log(bool force) { >>> > char time_msg[FILENAMEBUFLEN]; >>> > char time_str[EXTRACHARLEN]; >>> > char current_file_name[FILENAMEBUFLEN]; >>> > char renamed_file_name[FILENAMEBUFLEN]; >>> > >>> > if (!should_rotate(force)) { >>> > return; >>> > } >>> > >>> > ... >>> > } >>> >>> Could you please update your patch? >> >> I will do that. >> >> >>> There is a new empty line in the rotate_log method: >>> >>> > } >>> > + >>> > #ifdef ASSERT >>> >>> could you please remove it? >> >> I will do that. >> >> >>> The logging change in rotate_log uses a different kind of if/else syntax >>> than the rest of the file: >>> >>> > if (force) { >>> > ... >>> > } >>> > else { >>> > ... >>> > } >>> >>> The other if/else statements in the file uses: >>> >>> > if (cond) { >>> > ... >>> > } else { >>> > ... >>> > } >>> >>> Could you please update your change to use the same if/else syntax? >> >> I will do that. >> >> >>> This part of the change duplicates the code: >>> >>> + jio_snprintf(time_msg, sizeof(time_msg), "%s GC log rotation request has been received. Saved as %s\n", >>> + os::local_time_string((char *)time_str, sizeof(time_str)), >>> + renamed_file_name); >>> + } >>> + else { >>> + jio_snprintf(time_msg, sizeof(time_msg), "%s GC log file has reached the" >>> " maximum size. Saved as %s\n", >>> - os::local_time_string((char *)time_str, sizeof(time_str)), >>> + os::local_time_string((char *)time_str, sizeof(time_str)), >>> renamed_file_name); >>> >>> Could you instead just change the message, as in: >>> >>> > const char* msg = forced ? "%s GC log rotation request has been received. Saved as %s\n" : >>> > "%s GC log file has reached the maximum size. Saved as %s\n"; >>> > jio_snprintf(msg, os::local_time_string((char *)time_str, sizeof(time_str)), renamed_file_name); >> >> I will do that. >> >> >>> The declaration of rotate_log in ostream.hpp still uses the old >>> variable name is_force, it should use force, >>> just as the definition. >> >> Sorry, I will fix it. >> >> >>> Finally, could you add a test that tests your change? Have a look at the other tests >>> in hotspot/test/gc to see how you can do it >>> (you might want to use some functionality from hotspot/test/testlibrary). >> >> I found three tests as following: >> >> [ysuenaga at xelvis test]$ find . -iname "*jcmd*" >> ./runtime/NMT/JcmdWithNMTDisabled.java >> ./runtime/NMT/JcmdScale.java >> ./gc/TestG1ZeroPGCTJcmdThreadPrint.java >> >> I understand that these tests checks output (stdout/stderr) with OutputAnalyzer. >> However, my patch affects target VM. So I guess current test cannot check >> that GC log rotation is succeeded. >> >> Should I make test which checks exit value of jcmd ? >> >> >> Thanks, >> >> Yasumasa >> >>> Thanks, >>> Erik >>> >>> On 2014-01-29 15:28, Yasumasa Suenaga wrote: >>>> Hi Staffan, >>>> >>>> Thank you for reviewing! >>>> I've uploaded new webrev. >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.01/ >>>> >>>> On 2014/01/29 20:56, Staffan Larsen wrote: >>>>> Yasumasa, >>>>> >>>>> src/share/vm/runtime/arguments.cpp >>>>> no comments >>>>> >>>>> src/share/vm/runtime/safepoint.cpp >>>>> I was surprised that gc log size was checked after each safe point. That seems an uneccssary burden to place on a safe point. Instead we should switch to a periodic task that checks the gc log size. However, this is unrelated to you patch, so please ignore for now. >>>> >>>> Agree. >>>> However, I think that PeriodicTask also is not appropriate for this. >>>> >>>> Size of GC log file is increased when GC is occurred. >>>> So I think rotate function should be called at entry of each GC events >>>> e.g. VM_GC_Operation::doit_prologue() etc... >>>> >>>> >>>>> src/share/vm/runtime/vm_operations.hpp >>>>> line 402: nit: missing space before { >>>> >>>> Fixed. >>>> >>>> >>>>> line 405: I think ?force? is a better name than ?is_force? >>>> >>>> I removed "force" option from DCmd. >>>> So I removed this from VMOperation. >>>> >>>> >>>>> src/share/vm/services/diagnosticCommand.cpp >>>>> line 666: What does this do without the -force option? It looks to me that the non-force case will happen after each safe point (see above) and that there is no need to ever do this from a diagnostic command. Can we remove the option? >>>> >>>> Indeed. >>>> I removed "force" option. >>>> >>>> >>>>> line 677: ?Target VM does not support GC log file rotation." >>>> >>>> Fixed. >>>> >>>> >>>>> nits: some missing spaces before ?{' and after ?if' >>>> >>>> Fixed. >>>> >>>> >>>>> src/share/vm/services/diagnosticCommand.hpp >>>>> I think RotateGCLogDCmd should require the ?control? permission when executed via JMX, so please add: >>>>> static const JavaPermission permission() { >>>>> JavaPermission p = {"java.lang.management.ManagementPermission", >>>>> "control", NULL}; >>>>> return p; >>>>> } >>>> >>>> Added. >>>> >>>> >>>>> line 394: Maybe ?Force the GC log file to be rotated.? is a better description? >>>> >>>> Fixed. >>>> >>>> >>>>> src/share/vm/utilities/ostream.cpp >>>>> line 662: I think ?force? is a better name than ?is_force? >>>>> line 668: The comment says exactly the same thing as the code so I think it can be skipped >>>>> line 671: ?GC log file rotation occurs by external trigger ONLY." >>>>> line 675: "not need? -> ?no need? >>>>> line 718: "GC log rotation request has been received? >>>> >>>> Fixed them. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> src/share/vm/utilities/ostream.hpp >>>>> no comments >>>>> >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 24 jan 2014, at 14:50, Yasumasa Suenaga wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I've created webrev: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ >>>>>> >>>>>> This patch works fine on current jdk9/hs-rt . >>>>>> Could you review this? >>>>>> >>>>>> >>>>>> I am just an Author. So I need a sponsor. >>>>>> Could you help me? >>>>>> >>>>>> >>>>>> Please cooperate. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2013/12/06 0:05, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Did someone read my email? >>>>>>> I really hope to merge "JDK-7090324: gclog rotation via external tool" . >>>>>>> >>>>>>> I hear that someone need this RFE. So I want to discuss about this. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> On 2013/11/08 21:47, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Did someone read my mail? >>>>>>>> >>>>>>>> I think that this RFE helps us to watch Java heap on production system. >>>>>>>> Also I think this RFE is able to be part of the JEP 158 (Unified JVM Logging) . >>>>>>>> >>>>>>>> I want to update this RFE in JDK Bug System, but I don't have account. >>>>>>>> So I've posted email at first. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2013/09/30 21:10, Yasumasa Suenaga wrote: >>>>>>>>> In previous email, I've attached new patch for this RFE. >>>>>>>>> It works fine with current hsx. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> On 2013/09/29 23:40, Yasu wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> We are using "logrotate" tool on RHEL for various log rotation. >>>>>>>>>> Current HotSpot has gclog rotation function for log size base, >>>>>>>>>> however I need to rotate gc log synchronizing with logrotate tool. >>>>>>>>>> >>>>>>>>>> So I've created RFE as "JDK-7090324: gclog rotation via external tool" . >>>>>>>>>> And Sr. Engineering Manager in Oracle said he use the essence of my patch in one >>>>>>>>>> of the jcmd subcommands. >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274.html >>>>>>>>>> >>>>>>>>>> 2 years ago, I posted a patch for this RFE. >>>>>>>>>> But this patch is too old to apply for current HotSpot. >>>>>>>>>> >>>>>>>>>> In last month, a similar discussion was appeared in ML. >>>>>>>>>> So I think it's time to discuss this RFE. >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please cooperate. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> From egor.ushakov at jetbrains.com Thu Jan 30 02:33:26 2014 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Thu, 30 Jan 2014 14:33:26 +0400 Subject: Long standing groovy step into issue Message-ID: <52EA2A76.80601@jetbrains.com> Hi guys! there is a long standing issue (on groovy) https://jira.codehaus.org/browse/GROOVY-4063, that does not allow to do correct step into: java debugger just skips the user code together with the code in stepping filters. If breakpoint is set in user code it stops where expected. Could someone please give a hint on how groovy should correctly generate the code not to confuse debugger step filters. Thanks in advance, Egor From markus.gronlund at oracle.com Thu Jan 30 03:11:05 2014 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 30 Jan 2014 03:11:05 -0800 (PST) Subject: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) Message-ID: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> Greetings, Kindly asking for reviews for this very small fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8032518 Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/ Background: Still a bit puzzled about the manifestations of the crashes when inspecting the .mdmp files, which seems to be dereferencing a (debug) ResourceObj allocation[0] cookie address (~allocation address) at point of crashing. In addition, if the issue is an effect of not handling OOM correctly, I would expect to see a _pending_exception off the problematic thread, but there seems to be none. Also unknown why this seems to occur more on Windows x64 than any other platform. Testing: I have iterated the testcase nsk/stress/jck60/jck60014 locally - without suggested fixes I get about 10 crashes in about 300 runs. With fixes I am yet to see any crashes, currently ~600 iterations. I suggest to putback this first (since it should be fixed anyhow), to see the effect, before any more time is spent on tracing this down. Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140130/cb7cf3df/attachment.html From suenaga.yasumasa at lab.ntt.co.jp Thu Jan 30 03:12:51 2014 From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga) Date: Thu, 30 Jan 2014 20:12:51 +0900 Subject: JDK-7090324: gclog rotation via external tool In-Reply-To: <5B189F0A-7408-47C7-9719-DC2990355209@oracle.com> References: <52483BDB.8040206@ysfactory.dip.jp> <52496A21.8080608@ysfactory.dip.jp> <527CDD56.7080106@ysfactory.dip.jp> <52A09642.4030609@ysfactory.dip.jp> <52E26FA2.40909@ysfactory.dip.jp> <0E26045D-F7F9-49BC-AB36-A42C1DC6E64E@oracle.com> <52E91000.9010600@ysfactory.dip.jp> <52E91AAA.3060008@oracle.com> <52E9248D.2090108@ysfactory.dip.jp> <52E9FA5B.6010306@lab.ntt.co.jp> <5B189F0A-7408-47C7-9719-DC2990355209@oracle.com> Message-ID: <52EA33B3.6080409@lab.ntt.co.jp> Hi Staffan, I've uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.03/ On 2014/01/30 17:23, Staffan Larsen wrote: > Would it be possible for the Diagnostic Command to output the location of the rotated log? When invoking the command it would be good to get some kind of feedback. I changed rotate_log() to redirect messages to jcmd. If GC.rotate_log is executed, we can get messages on jcmd console as below: ------------ $ jcmd 18976 GC.rotate_log 18976: 2014-01-30 19:59:39 GC log rotation request has been received. Saved as test.log.0 2014-01-30 19:59:39 GC log file created test.log.1 ------------ > test/gc/7090324/Test7090324.java: > - I think this needs to have the Oracle copyright notice as well. > - Tests should now use descriptive names, not bug numbers: https://wiki.openjdk.java.net/display/HotSpot/Naming+HotSpot+JTReg+Tests > - nits: lots of missing spaces before ?{?, and after ?for?, ?if? > - line 47: you don?t need to clean up old files, jtreg will give you a fresh scratch directory to run in I've fixed. Could you review again? Thanks, Yasumasa > /Staffan > > > > On 30 jan 2014, at 08:08, Yasumasa Suenaga wrote: > >> Hi Erik, Staffan, >> >> I've uploaded new webrev. Could you review this ? >> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.02/ >> >> This patch includes fixes from comments of Staffan and Erik. >> >> And I created new test of this patch as Test7090324 . >> This test works fine with jtreg. >> >> >> Thanks, >> >> Yasumasa >> >> On 2014/01/30 0:55, Yasumasa Suenaga wrote: >>> Hi Erik, >>> >>> On 2014/01/30 0:13, Erik Helin wrote: >>>> Hi Yasumasa, >>>> >>>> (have to use HTML email to get a width of more than 78 chars, sorry) >>>> >>>> why did you change the code in arguments.cpp in the method check_gc_log_consistency? >>> >>> In current implementation, check_gclog_consistency() checks three parameters: >>> >>> - GC log filename >>> - NumberOfGCLogFiles >>> - GCLogFileSize >>> >>> My customer uses external trigger "ONLY" for rotating logs. >>> If they want to do that, GCLogFileSize does not need. >>> >>> >>>> Next, the gcLogFileStream::rotate_log method now does a lot of things. >>>> Could you separate out the first block into a new method, >>>> gcLogFileStream::should_rotate(bool force)? >>>> >>>> This was, the code would read: >>>> >>>>> bool gcLogFileStream::should_rotate(bool force) { >>>>> return force || _bytes_writen>= GCLogFileSize; >>>>> } >>>>> >>>>> void gcLogFileStream::rotate_log(bool force) { >>>>> char time_msg[FILENAMEBUFLEN]; >>>>> char time_str[EXTRACHARLEN]; >>>>> char current_file_name[FILENAMEBUFLEN]; >>>>> char renamed_file_name[FILENAMEBUFLEN]; >>>>> >>>>> if (!should_rotate(force)) { >>>>> return; >>>>> } >>>>> >>>>> ... >>>>> } >>>> >>>> Could you please update your patch? >>> >>> I will do that. >>> >>> >>>> There is a new empty line in the rotate_log method: >>>> >>>>> } >>>>> + >>>>> #ifdef ASSERT >>>> >>>> could you please remove it? >>> >>> I will do that. >>> >>> >>>> The logging change in rotate_log uses a different kind of if/else syntax >>>> than the rest of the file: >>>> >>>>> if (force) { >>>>> ... >>>>> } >>>>> else { >>>>> ... >>>>> } >>>> >>>> The other if/else statements in the file uses: >>>> >>>>> if (cond) { >>>>> ... >>>>> } else { >>>>> ... >>>>> } >>>> >>>> Could you please update your change to use the same if/else syntax? >>> >>> I will do that. >>> >>> >>>> This part of the change duplicates the code: >>>> >>>> + jio_snprintf(time_msg, sizeof(time_msg), "%s GC log rotation request has been received. Saved as %s\n", >>>> + os::local_time_string((char *)time_str, sizeof(time_str)), >>>> + renamed_file_name); >>>> + } >>>> + else { >>>> + jio_snprintf(time_msg, sizeof(time_msg), "%s GC log file has reached the" >>>> " maximum size. Saved as %s\n", >>>> - os::local_time_string((char *)time_str, sizeof(time_str)), >>>> + os::local_time_string((char *)time_str, sizeof(time_str)), >>>> renamed_file_name); >>>> >>>> Could you instead just change the message, as in: >>>> >>>>> const char* msg = forced ? "%s GC log rotation request has been received. Saved as %s\n" : >>>>> "%s GC log file has reached the maximum size. Saved as %s\n"; >>>>> jio_snprintf(msg, os::local_time_string((char *)time_str, sizeof(time_str)), renamed_file_name); >>> >>> I will do that. >>> >>> >>>> The declaration of rotate_log in ostream.hpp still uses the old >>>> variable name is_force, it should use force, >>>> just as the definition. >>> >>> Sorry, I will fix it. >>> >>> >>>> Finally, could you add a test that tests your change? Have a look at the other tests >>>> in hotspot/test/gc to see how you can do it >>>> (you might want to use some functionality from hotspot/test/testlibrary). >>> >>> I found three tests as following: >>> >>> [ysuenaga at xelvis test]$ find . -iname "*jcmd*" >>> ./runtime/NMT/JcmdWithNMTDisabled.java >>> ./runtime/NMT/JcmdScale.java >>> ./gc/TestG1ZeroPGCTJcmdThreadPrint.java >>> >>> I understand that these tests checks output (stdout/stderr) with OutputAnalyzer. >>> However, my patch affects target VM. So I guess current test cannot check >>> that GC log rotation is succeeded. >>> >>> Should I make test which checks exit value of jcmd ? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>>> Thanks, >>>> Erik >>>> >>>> On 2014-01-29 15:28, Yasumasa Suenaga wrote: >>>>> Hi Staffan, >>>>> >>>>> Thank you for reviewing! >>>>> I've uploaded new webrev. >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.01/ >>>>> >>>>> On 2014/01/29 20:56, Staffan Larsen wrote: >>>>>> Yasumasa, >>>>>> >>>>>> src/share/vm/runtime/arguments.cpp >>>>>> no comments >>>>>> >>>>>> src/share/vm/runtime/safepoint.cpp >>>>>> I was surprised that gc log size was checked after each safe point. That seems an uneccssary burden to place on a safe point. Instead we should switch to a periodic task that checks the gc log size. However, this is unrelated to you patch, so please ignore for now. >>>>> >>>>> Agree. >>>>> However, I think that PeriodicTask also is not appropriate for this. >>>>> >>>>> Size of GC log file is increased when GC is occurred. >>>>> So I think rotate function should be called at entry of each GC events >>>>> e.g. VM_GC_Operation::doit_prologue() etc... >>>>> >>>>> >>>>>> src/share/vm/runtime/vm_operations.hpp >>>>>> line 402: nit: missing space before { >>>>> >>>>> Fixed. >>>>> >>>>> >>>>>> line 405: I think ?force? is a better name than ?is_force? >>>>> >>>>> I removed "force" option from DCmd. >>>>> So I removed this from VMOperation. >>>>> >>>>> >>>>>> src/share/vm/services/diagnosticCommand.cpp >>>>>> line 666: What does this do without the -force option? It looks to me that the non-force case will happen after each safe point (see above) and that there is no need to ever do this from a diagnostic command. Can we remove the option? >>>>> >>>>> Indeed. >>>>> I removed "force" option. >>>>> >>>>> >>>>>> line 677: ?Target VM does not support GC log file rotation." >>>>> >>>>> Fixed. >>>>> >>>>> >>>>>> nits: some missing spaces before ?{' and after ?if' >>>>> >>>>> Fixed. >>>>> >>>>> >>>>>> src/share/vm/services/diagnosticCommand.hpp >>>>>> I think RotateGCLogDCmd should require the ?control? permission when executed via JMX, so please add: >>>>>> static const JavaPermission permission() { >>>>>> JavaPermission p = {"java.lang.management.ManagementPermission", >>>>>> "control", NULL}; >>>>>> return p; >>>>>> } >>>>> >>>>> Added. >>>>> >>>>> >>>>>> line 394: Maybe ?Force the GC log file to be rotated.? is a better description? >>>>> >>>>> Fixed. >>>>> >>>>> >>>>>> src/share/vm/utilities/ostream.cpp >>>>>> line 662: I think ?force? is a better name than ?is_force? >>>>>> line 668: The comment says exactly the same thing as the code so I think it can be skipped >>>>>> line 671: ?GC log file rotation occurs by external trigger ONLY." >>>>>> line 675: "not need? -> ?no need? >>>>>> line 718: "GC log rotation request has been received? >>>>> >>>>> Fixed them. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> src/share/vm/utilities/ostream.hpp >>>>>> no comments >>>>>> >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 24 jan 2014, at 14:50, Yasumasa Suenaga wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I've created webrev: >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ >>>>>>> >>>>>>> This patch works fine on current jdk9/hs-rt . >>>>>>> Could you review this? >>>>>>> >>>>>>> >>>>>>> I am just an Author. So I need a sponsor. >>>>>>> Could you help me? >>>>>>> >>>>>>> >>>>>>> Please cooperate. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2013/12/06 0:05, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Did someone read my email? >>>>>>>> I really hope to merge "JDK-7090324: gclog rotation via external tool" . >>>>>>>> >>>>>>>> I hear that someone need this RFE. So I want to discuss about this. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> On 2013/11/08 21:47, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Did someone read my mail? >>>>>>>>> >>>>>>>>> I think that this RFE helps us to watch Java heap on production system. >>>>>>>>> Also I think this RFE is able to be part of the JEP 158 (Unified JVM Logging) . >>>>>>>>> >>>>>>>>> I want to update this RFE in JDK Bug System, but I don't have account. >>>>>>>>> So I've posted email at first. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013/09/30 21:10, Yasumasa Suenaga wrote: >>>>>>>>>> In previous email, I've attached new patch for this RFE. >>>>>>>>>> It works fine with current hsx. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> On 2013/09/29 23:40, Yasu wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> We are using "logrotate" tool on RHEL for various log rotation. >>>>>>>>>>> Current HotSpot has gclog rotation function for log size base, >>>>>>>>>>> however I need to rotate gc log synchronizing with logrotate tool. >>>>>>>>>>> >>>>>>>>>>> So I've created RFE as "JDK-7090324: gclog rotation via external tool" . >>>>>>>>>>> And Sr. Engineering Manager in Oracle said he use the essence of my patch in one >>>>>>>>>>> of the jcmd subcommands. >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274.html >>>>>>>>>>> >>>>>>>>>>> 2 years ago, I posted a patch for this RFE. >>>>>>>>>>> But this patch is too old to apply for current HotSpot. >>>>>>>>>>> >>>>>>>>>>> In last month, a similar discussion was appeared in ML. >>>>>>>>>>> So I think it's time to discuss this RFE. >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please cooperate. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> > From dmitry.samersoff at oracle.com Thu Jan 30 03:23:24 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 30 Jan 2014 15:23:24 +0400 Subject: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) In-Reply-To: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> References: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> Message-ID: <52EA362C.3090006@oracle.com> Markus, ll. 37 Return isn't necessary here. But it might be good to refactor the code: if (jmm_version <= JMM_VERSION_1_2_2) { throw return } .. ll.130 I would prefer something like goto cleanup_and_OOM rather than duplicated pattern. -Dmitry On 2014-01-30 15:11, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for this very small fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8032518 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/ > > > > Background: > > > > Still a bit puzzled about the manifestations of the crashes when > inspecting the .mdmp files, which seems to be dereferencing a (debug) > ResourceObj allocation[0] cookie address (~allocation address) at point > of crashing. In addition, if the issue is an effect of not handling OOM > correctly, I would expect to see a _pending_exception off the > problematic thread, but there seems to be none. Also unknown why this > seems to occur more on Windows x64 than any other platform? > > > > Testing: > > I have iterated the testcase nsk/stress/jck60/jck60014 locally ? without > suggested fixes I get about 10 crashes in about 300 runs. With fixes I > am yet to see any crashes, currently ~600 iterations? > > > > I suggest to putback this first (since it should be fixed anyhow), to > see the effect, before any more time is spent on tracing this down? > > > > Thanks > > Markus > > > -- 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 jaroslav.bachorik at oracle.com Thu Jan 30 03:24:42 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 30 Jan 2014 12:24:42 +0100 Subject: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) In-Reply-To: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> References: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> Message-ID: <52EA367A.6040502@oracle.com> Looks fine. It definitely makes sense to return properly after notifying OOM. -JB- On 30.1.2014 12:11, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for this very small fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8032518 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/ > > > > Background: > > > > Still a bit puzzled about the manifestations of the crashes when inspecting the .mdmp files, which seems to be dereferencing a (debug) ResourceObj allocation[0] cookie address (~allocation address) at point of crashing. In addition, if the issue is an effect of not handling OOM correctly, I would expect to see a _pending_exception off the problematic thread, but there seems to be none. Also unknown why this seems to occur more on Windows x64 than any other platform. > > > > Testing: > > I have iterated the testcase nsk/stress/jck60/jck60014 locally - without suggested fixes I get about 10 crashes in about 300 runs. With fixes I am yet to see any crashes, currently ~600 iterations. > > > > I suggest to putback this first (since it should be fixed anyhow), to see the effect, before any more time is spent on tracing this down. > > > > Thanks > > Markus > > > From staffan.larsen at oracle.com Thu Jan 30 03:46:39 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Jan 2014 12:46:39 +0100 Subject: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) In-Reply-To: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> References: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> Message-ID: <53A4ECAD-8D88-4C8D-879A-8ABAAAEE4DB0@oracle.com> Looks good! Thanks, /Staffan On 30 jan 2014, at 12:11, Markus Gronlund wrote: > Greetings, > > Kindly asking for reviews for this very small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8032518 > Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/ > > Background: > > Still a bit puzzled about the manifestations of the crashes when inspecting the .mdmp files, which seems to be dereferencing a (debug) ResourceObj allocation[0] cookie address (~allocation address) at point of crashing. In addition, if the issue is an effect of not handling OOM correctly, I would expect to see a _pending_exception off the problematic thread, but there seems to be none. Also unknown why this seems to occur more on Windows x64 than any other platform? > > Testing: > I have iterated the testcase nsk/stress/jck60/jck60014 locally ? without suggested fixes I get about 10 crashes in about 300 runs. With fixes I am yet to see any crashes, currently ~600 iterations? > > I suggest to putback this first (since it should be fixed anyhow), to see the effect, before any more time is spent on tracing this down? > > Thanks > Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140130/f45e7518/attachment.html From staffan.larsen at oracle.com Thu Jan 30 03:53:59 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Jan 2014 12:53:59 +0100 Subject: Long standing groovy step into issue In-Reply-To: <52EA2A76.80601@jetbrains.com> References: <52EA2A76.80601@jetbrains.com> Message-ID: What version of Hotspot have you tried this with? There was a bug fix for invokedynamic and line numbers that may or may not be relevant in jdk8-b115: https://bugs.openjdk.java.net/browse/JDK-8026508 /Staffan On 30 jan 2014, at 11:33, Egor Ushakov wrote: > Hi guys! > > there is a long standing issue (on groovy) https://jira.codehaus.org/browse/GROOVY-4063, > that does not allow to do correct step into: java debugger just skips the user code together with the code in stepping filters. > If breakpoint is set in user code it stops where expected. > Could someone please give a hint on how groovy should correctly generate the code not to confuse debugger step filters. > > Thanks in advance, > Egor From david.holmes at oracle.com Thu Jan 30 04:05:38 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jan 2014 22:05:38 +1000 Subject: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) In-Reply-To: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> References: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> Message-ID: <52EA4012.5050107@oracle.com> This is good to me. The return at line 37 was unnecessary but it does help reinforce the pattern that you must return after JNU_ThrowXXX David On 30/01/2014 9:11 PM, Markus Gronlund wrote: > Greetings, > > Kindly asking for reviews for this very small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8032518 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/ > > Background: > > Still a bit puzzled about the manifestations of the crashes when > inspecting the .mdmp files, which seems to be dereferencing a (debug) > ResourceObj allocation[0] cookie address (~allocation address) at point > of crashing. In addition, if the issue is an effect of not handling OOM > correctly, I would expect to see a _pending_exception off the > problematic thread, but there seems to be none. Also unknown why this > seems to occur more on Windows x64 than any other platform? > > Testing: > > I have iterated the testcase nsk/stress/jck60/jck60014 locally ? without > suggested fixes I get about 10 crashes in about 300 runs. With fixes I > am yet to see any crashes, currently ~600 iterations? > > I suggest to putback this first (since it should be fixed anyhow), to > see the effect, before any more time is spent on tracing this down? > > Thanks > > Markus > From egor.ushakov at jetbrains.com Thu Jan 30 05:00:46 2014 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Thu, 30 Jan 2014 17:00:46 +0400 Subject: Long standing groovy step into issue In-Reply-To: References: <52EA2A76.80601@jetbrains.com> Message-ID: <52EA4CFE.2020300@jetbrains.com> Tried it with the latest jdk 7 and jdk8 b124, no luck. It works fine with groovy version that use invokedynamic, but regular version does not work. Stopped working several years ago when groovy changed the way they generate classes. However from what's in bytecode it is not obvious what's confusing the debugger, consider the code: class T { private static void subfunction(Some some) { println "sub" } } *groovy *generates: // access flags 0xA private static subfunction(Lxxx/Some;)V L0 INVOKESTATIC xxx/Some.$getCallSiteArray ()[Lorg/codehaus/groovy/runtime/callsite/CallSite; ASTORE 1 L1 LINENUMBER 21 L1 ALOAD 1 LDC 3 AALOAD LDC Lxxx/Some;.class LDC "sub" INVOKEINTERFACE org/codehaus/groovy/runtime/callsite/CallSite.callStatic (Ljava/lang/Class;Ljava/lang/Object;)Ljava/lang/Object; POP L2 RETURN LOCALVARIABLE some Lxxx/Some; L0 L2 0 MAXSTACK = 3 MAXLOCALS = 2 *javac* generates: (I replaced println with System.out.printl) // access flags 0xA private static subfunction(Lxxx/Some;)V L0 LINENUMBER 21 L0 GETSTATIC java/lang/System.out : Ljava/io/PrintStream; LDC "sub" INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/String;)V L1 LINENUMBER 22 L1 RETURN L2 LOCALVARIABLE some Lxxx/Some; L0 L2 0 MAXSTACK = 2 MAXLOCALS = 1 Egor On 30.01.2014 15:53, Staffan Larsen wrote: > What version of Hotspot have you tried this with? There was a bug fix for invokedynamic and line numbers that may or may not be relevant in jdk8-b115: https://bugs.openjdk.java.net/browse/JDK-8026508 > > /Staffan > > On 30 jan 2014, at 11:33, Egor Ushakov wrote: > >> Hi guys! >> >> there is a long standing issue (on groovy) https://jira.codehaus.org/browse/GROOVY-4063, >> that does not allow to do correct step into: java debugger just skips the user code together with the code in stepping filters. >> If breakpoint is set in user code it stops where expected. >> Could someone please give a hint on how groovy should correctly generate the code not to confuse debugger step filters. >> >> Thanks in advance, >> Egor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140130/1478cd69/attachment.html From sundararajan.athijegannathan at oracle.com Thu Jan 30 05:04:53 2014 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 30 Jan 2014 13:04:53 +0000 Subject: hg: jdk8/tl/nashorn: 8032944: Improve reflection in Nashorn Message-ID: <20140130130504.4BA5D628AC@hg.openjdk.java.net> Changeset: a43c125b03dc Author: sundar Date: 2014-01-30 18:34 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a43c125b03dc 8032944: Improve reflection in Nashorn Reviewed-by: jlaskey, attila, ahgross ! src/jdk/nashorn/internal/objects/NativeObject.java + test/script/sandbox/classbind.js From sundararajan.athijegannathan at oracle.com Thu Jan 30 05:34:14 2014 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 30 Jan 2014 13:34:14 +0000 Subject: hg: jdk8/tl/nashorn: 8032954: Nashorn: extend Java.extend Message-ID: <20140130133415.A25F4628B0@hg.openjdk.java.net> Changeset: eca774d33fa4 Author: sundar Date: 2014-01-30 19:04 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/eca774d33fa4 8032954: Nashorn: extend Java.extend Reviewed-by: attila, jlaskey, ahgross ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/script/sandbox/classbind.js ! test/script/sandbox/classloader.js ! test/script/sandbox/classloader.js.EXPECTED From markus.gronlund at oracle.com Thu Jan 30 05:52:27 2014 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 30 Jan 2014 05:52:27 -0800 (PST) Subject: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) In-Reply-To: <52EA4012.5050107@oracle.com> References: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> <52EA4012.5050107@oracle.com> Message-ID: <4ca08b05-8f71-41eb-a3ab-34b5ae7a08b9@default> Thanks guys. Yes, the reason I added the return in 37 is to avoid anyone adding anything after the else clause moving forward. However, as Dmitry pointed out, an inversion of the version check will make this clearer - thanks. In addition, just realized I hadn't pulled in the latest changes for the last webrev (for the diff), there were actually recent updates to this file as of: changeset: 9197:902aa2b3265c user: simonis date: Mon Jan 20 17:16:05 2014 +0100 summary: 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests So here's an updated webrev for your convenience: http://cr.openjdk.java.net/~mgronlun/8032518/webrev02/ Dmitry: With the pull, the locations of "free, throw, return" reduces to only two so I don't think refactoring here will add much. Thanks for pointing it out though. Cheers Markus -----Original Message----- From: David Holmes Sent: den 30 januari 2014 13:06 To: Markus Gronlund; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev Subject: Re: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) This is good to me. The return at line 37 was unnecessary but it does help reinforce the pattern that you must return after JNU_ThrowXXX David On 30/01/2014 9:11 PM, Markus Gronlund wrote: > Greetings, > > Kindly asking for reviews for this very small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8032518 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/ > > Background: > > Still a bit puzzled about the manifestations of the crashes when > inspecting the .mdmp files, which seems to be dereferencing a (debug) > ResourceObj allocation[0] cookie address (~allocation address) at > point of crashing. In addition, if the issue is an effect of not > handling OOM correctly, I would expect to see a _pending_exception off > the problematic thread, but there seems to be none. Also unknown why > this seems to occur more on Windows x64 than any other platform. > > Testing: > > I have iterated the testcase nsk/stress/jck60/jck60014 locally - > without suggested fixes I get about 10 crashes in about 300 runs. With > fixes I am yet to see any crashes, currently ~600 iterations. > > I suggest to putback this first (since it should be fixed anyhow), to > see the effect, before any more time is spent on tracing this down. > > Thanks > > Markus > From staffan.larsen at oracle.com Thu Jan 30 05:55:43 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Jan 2014 14:55:43 +0100 Subject: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) In-Reply-To: <4ca08b05-8f71-41eb-a3ab-34b5ae7a08b9@default> References: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> <52EA4012.5050107@oracle.com> <4ca08b05-8f71-41eb-a3ab-34b5ae7a08b9@default> Message-ID: Still good. On 30 jan 2014, at 14:52, Markus Gronlund wrote: > Thanks guys. > > Yes, the reason I added the return in 37 is to avoid anyone adding anything after the else clause moving forward. However, as Dmitry pointed out, an inversion of the version check will make this clearer - thanks. > > In addition, just realized I hadn't pulled in the latest changes for the last webrev (for the diff), there were actually recent updates to this file as of: > > changeset: 9197:902aa2b3265c > user: simonis > date: Mon Jan 20 17:16:05 2014 +0100 > summary: 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests > > > So here's an updated webrev for your convenience: > > http://cr.openjdk.java.net/~mgronlun/8032518/webrev02/ > > Dmitry: > > With the pull, the locations of "free, throw, return" reduces to only two so I don't think refactoring here will add much. Thanks for pointing it out though. > > Cheers > Markus > > > -----Original Message----- > From: David Holmes > Sent: den 30 januari 2014 13:06 > To: Markus Gronlund; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev > Subject: Re: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) > > This is good to me. The return at line 37 was unnecessary but it does help reinforce the pattern that you must return after JNU_ThrowXXX > > David > > On 30/01/2014 9:11 PM, Markus Gronlund wrote: >> Greetings, >> >> Kindly asking for reviews for this very small fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8032518 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/ >> >> Background: >> >> Still a bit puzzled about the manifestations of the crashes when >> inspecting the .mdmp files, which seems to be dereferencing a (debug) >> ResourceObj allocation[0] cookie address (~allocation address) at >> point of crashing. In addition, if the issue is an effect of not >> handling OOM correctly, I would expect to see a _pending_exception off >> the problematic thread, but there seems to be none. Also unknown why >> this seems to occur more on Windows x64 than any other platform. >> >> Testing: >> >> I have iterated the testcase nsk/stress/jck60/jck60014 locally - >> without suggested fixes I get about 10 crashes in about 300 runs. With >> fixes I am yet to see any crashes, currently ~600 iterations. >> >> I suggest to putback this first (since it should be fixed anyhow), to >> see the effect, before any more time is spent on tracing this down. >> >> Thanks >> >> Markus >> From dmitry.samersoff at oracle.com Thu Jan 30 06:35:21 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 30 Jan 2014 18:35:21 +0400 Subject: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) In-Reply-To: <4ca08b05-8f71-41eb-a3ab-34b5ae7a08b9@default> References: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> <52EA4012.5050107@oracle.com> <4ca08b05-8f71-41eb-a3ab-34b5ae7a08b9@default> Message-ID: <52EA6329.5030703@oracle.com> Markus, Thank you for refactoring. Looks good for me! -Dmitry On 2014-01-30 17:52, Markus Gronlund wrote: > Thanks guys. > > Yes, the reason I added the return in 37 is to avoid anyone adding anything after the else clause moving forward. However, as Dmitry pointed out, an inversion of the version check will make this clearer - thanks. > > In addition, just realized I hadn't pulled in the latest changes for the last webrev (for the diff), there were actually recent updates to this file as of: > > changeset: 9197:902aa2b3265c > user: simonis > date: Mon Jan 20 17:16:05 2014 +0100 > summary: 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests > > > So here's an updated webrev for your convenience: > > http://cr.openjdk.java.net/~mgronlun/8032518/webrev02/ > > Dmitry: > > With the pull, the locations of "free, throw, return" reduces to only two so I don't think refactoring here will add much. Thanks for pointing it out though. > > Cheers > Markus > > > -----Original Message----- > From: David Holmes > Sent: den 30 januari 2014 13:06 > To: Markus Gronlund; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev > Subject: Re: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) > > This is good to me. The return at line 37 was unnecessary but it does help reinforce the pattern that you must return after JNU_ThrowXXX > > David > > On 30/01/2014 9:11 PM, Markus Gronlund wrote: >> Greetings, >> >> Kindly asking for reviews for this very small fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8032518 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/ >> >> Background: >> >> Still a bit puzzled about the manifestations of the crashes when >> inspecting the .mdmp files, which seems to be dereferencing a (debug) >> ResourceObj allocation[0] cookie address (~allocation address) at >> point of crashing. In addition, if the issue is an effect of not >> handling OOM correctly, I would expect to see a _pending_exception off >> the problematic thread, but there seems to be none. Also unknown why >> this seems to occur more on Windows x64 than any other platform. >> >> Testing: >> >> I have iterated the testcase nsk/stress/jck60/jck60014 locally - >> without suggested fixes I get about 10 crashes in about 300 runs. With >> fixes I am yet to see any crashes, currently ~600 iterations. >> >> I suggest to putback this first (since it should be fixed anyhow), to >> see the effect, before any more time is spent on tracing this down. >> >> Thanks >> >> Markus >> -- 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 sundararajan.athijegannathan at oracle.com Thu Jan 30 06:15:53 2014 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 30 Jan 2014 14:15:53 +0000 Subject: hg: jdk8/tl/nashorn: 8032949: Nashorn linkages awry Message-ID: <20140130141554.BFDAE628B3@hg.openjdk.java.net> Changeset: c59fb10cb0b5 Author: sundar Date: 2014-01-30 19:45 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c59fb10cb0b5 8032949: Nashorn linkages awry Reviewed-by: jlaskey, attila, ahgross ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java From staffan.larsen at oracle.com Thu Jan 30 08:11:36 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Jan 2014 17:11:36 +0100 Subject: RFR(S): JDK-8029808 com/sun/jdi/ProcessAttachTest.sh times out Message-ID: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> webrev: http://cr.openjdk.java.net/~sla/8029808/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8029808 I have tried to improve the stability of this test in a couple of ways. - Timeout set to 120s - it should never need to run that long - When we start the debugee, we wait for the port-file to become available instead of waiting for output from the process. This should be less racy. - stderr output from the debuggee and ShutdownDebuggee programs are captured with the stdout output - Moved ?sleep 1? to after the check for the port file so the test is faster if the file already exists I?m not sure any of these are the cause of the timeout, but at least it should be a bit more stable now. /Staffan From dmitry.samersoff at oracle.com Thu Jan 30 08:35:18 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 30 Jan 2014 20:35:18 +0400 Subject: RFR(S): JDK-8029808 com/sun/jdi/ProcessAttachTest.sh times out In-Reply-To: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> References: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> Message-ID: <52EA7F46.5070405@oracle.com> Staffan, Looks good for me except windows part. Can you replace all this staff with call to jps ? -Dmitry On 2014-01-30 20:11, Staffan Larsen wrote: > webrev: http://cr.openjdk.java.net/~sla/8029808/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8029808 > > I have tried to improve the stability of this test in a couple of ways. > > - Timeout set to 120s - it should never need to run that long > - When we start the debugee, we wait for the port-file to become available instead of waiting for output from the process. This should be less racy. > - stderr output from the debuggee and ShutdownDebuggee programs are captured with the stdout output > - Moved ?sleep 1? to after the check for the port file so the test is faster if the file already exists > > I?m not sure any of these are the cause of the timeout, but at least it should be a bit more stable now. > > /Staffan > -- 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 staffan.larsen at oracle.com Thu Jan 30 08:53:47 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Jan 2014 17:53:47 +0100 Subject: RFR(S): JDK-8029808 com/sun/jdi/ProcessAttachTest.sh times out In-Reply-To: <52EA7F46.5070405@oracle.com> References: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> <52EA7F46.5070405@oracle.com> Message-ID: <16D6BA50-82FE-41F6-8423-FE218D397C58@oracle.com> On 30 jan 2014, at 17:35, Dmitry Samersoff wrote: > Staffan, > > Looks good for me except windows part. Can you explain? Do any of my changes make things worse on windows? > > Can you replace all this staff with call to ups ? I don?t think so. I need to know that the process has started _and_ reached a certain point in the program. /Staffan > > -Dmitry > > > On 2014-01-30 20:11, Staffan Larsen wrote: >> webrev: http://cr.openjdk.java.net/~sla/8029808/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8029808 >> >> I have tried to improve the stability of this test in a couple of ways. >> >> - Timeout set to 120s - it should never need to run that long >> - When we start the debugee, we wait for the port-file to become available instead of waiting for output from the process. This should be less racy. >> - stderr output from the debuggee and ShutdownDebuggee programs are captured with the stdout output >> - Moved ?sleep 1? to after the check for the port file so the test is faster if the file already exists >> >> I?m not sure any of these are the cause of the timeout, but at least it should be a bit more stable now. >> >> /Staffan >> > > > -- > 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 Thu Jan 30 08:59:08 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 30 Jan 2014 20:59:08 +0400 Subject: RFR(S): JDK-8029808 com/sun/jdi/ProcessAttachTest.sh times out In-Reply-To: <16D6BA50-82FE-41F6-8423-FE218D397C58@oracle.com> References: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> <52EA7F46.5070405@oracle.com> <16D6BA50-82FE-41F6-8423-FE218D397C58@oracle.com> Message-ID: <52EA84DC.5090008@oracle.com> Staffan, No it's not to your code. Sorry for not being clean enough. You cleaned up unix code, but windows code remains bad. Particularly, it has bad unconditional sleep 2 I would propose replace *windows manipulation with CYGWIN/MKS pids* to call to JPS that return windows pid -Dmitry On 2014-01-30 20:53, Staffan Larsen wrote: > > On 30 jan 2014, at 17:35, Dmitry Samersoff wrote: > >> Staffan, >> >> Looks good for me except windows part. > > Can you explain? Do any of my changes make things worse on windows? > >> >> Can you replace all this staff with call to ups ? > > I don?t think so. I need to know that the process has started _and_ reached a certain point in the program. > > /Staffan > >> >> -Dmitry >> >> >> On 2014-01-30 20:11, Staffan Larsen wrote: >>> webrev: http://cr.openjdk.java.net/~sla/8029808/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8029808 >>> >>> I have tried to improve the stability of this test in a couple of ways. >>> >>> - Timeout set to 120s - it should never need to run that long >>> - When we start the debugee, we wait for the port-file to become available instead of waiting for output from the process. This should be less racy. >>> - stderr output from the debuggee and ShutdownDebuggee programs are captured with the stdout output >>> - Moved ?sleep 1? to after the check for the port file so the test is faster if the file already exists >>> >>> I?m not sure any of these are the cause of the timeout, but at least it should be a bit more stable now. >>> >>> /Staffan >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- 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 staffan.larsen at oracle.com Thu Jan 30 09:05:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Jan 2014 18:05:42 +0100 Subject: RFR(S): JDK-8029808 com/sun/jdi/ProcessAttachTest.sh times out In-Reply-To: <52EA84DC.5090008@oracle.com> References: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> <52EA7F46.5070405@oracle.com> <16D6BA50-82FE-41F6-8423-FE218D397C58@oracle.com> <52EA84DC.5090008@oracle.com> Message-ID: <5F1505F7-91F4-42A2-BF82-46124962936B@oracle.com> Ah, yes. The windows ?get-the-right-pid? code could be moved to after the "Waiting for Debuggee to initialize?? loop. Then we know the process is running. And as you say, we could use jps or jcmd to find that pid. I?ll try to update the fix. /Staffan On 30 jan 2014, at 17:59, Dmitry Samersoff wrote: > Staffan, > > No it's not to your code. Sorry for not being clean enough. > > You cleaned up unix code, but windows code remains bad. Particularly, it > has bad unconditional sleep 2 > > I would propose replace *windows manipulation with CYGWIN/MKS pids* to > call to JPS that return windows pid > > -Dmitry > > On 2014-01-30 20:53, Staffan Larsen wrote: >> >> On 30 jan 2014, at 17:35, Dmitry Samersoff wrote: >> >>> Staffan, >>> >>> Looks good for me except windows part. >> >> Can you explain? Do any of my changes make things worse on windows? >> >>> >>> Can you replace all this staff with call to ups ? >> >> I don?t think so. I need to know that the process has started _and_ reached a certain point in the program. >> >> /Staffan >> >>> >>> -Dmitry >>> >>> >>> On 2014-01-30 20:11, Staffan Larsen wrote: >>>> webrev: http://cr.openjdk.java.net/~sla/8029808/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029808 >>>> >>>> I have tried to improve the stability of this test in a couple of ways. >>>> >>>> - Timeout set to 120s - it should never need to run that long >>>> - When we start the debugee, we wait for the port-file to become available instead of waiting for output from the process. This should be less racy. >>>> - stderr output from the debuggee and ShutdownDebuggee programs are captured with the stdout output >>>> - Moved ?sleep 1? to after the check for the port file so the test is faster if the file already exists >>>> >>>> I?m not sure any of these are the cause of the timeout, but at least it should be a bit more stable now. >>>> >>>> /Staffan >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > > > -- > 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 Alan.Bateman at oracle.com Thu Jan 30 09:09:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Jan 2014 17:09:02 +0000 Subject: RFR(S): JDK-8029808 com/sun/jdi/ProcessAttachTest.sh times out In-Reply-To: <52EA84DC.5090008@oracle.com> References: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> <52EA7F46.5070405@oracle.com> <16D6BA50-82FE-41F6-8423-FE218D397C58@oracle.com> <52EA84DC.5090008@oracle.com> Message-ID: <52EA872E.7070209@oracle.com> On 30/01/2014 16:59, Dmitry Samersoff wrote: > Staffan, > > No it's not to your code. Sorry for not being clean enough. > > You cleaned up unix code, but windows code remains bad. Particularly, it > has bad unconditional sleep 2 > > I would propose replace *windows manipulation with CYGWIN/MKS pids* to > call to JPS that return windows pid > I have a vague memory that we had to use ps to get the pid because of the suspend=y test which cause the debuggee to suspect during startup. I might be wrong on this of course, it was a long time ago. -Alan From dmitry.samersoff at oracle.com Thu Jan 30 09:12:13 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 30 Jan 2014 21:12:13 +0400 Subject: RFR(S): JDK-8029808 com/sun/jdi/ProcessAttachTest.sh times out In-Reply-To: <52EA872E.7070209@oracle.com> References: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> <52EA7F46.5070405@oracle.com> <16D6BA50-82FE-41F6-8423-FE218D397C58@oracle.com> <52EA84DC.5090008@oracle.com> <52EA872E.7070209@oracle.com> Message-ID: <52EA87ED.20003@oracle.com> Alan, Do you know any official statements about MKS support for jdk8 and jdk9? Could we drop MKS support? Bad MKS habit to run extra shell is most of pid-related troubles with tests. -Dmitry On 2014-01-30 21:09, Alan Bateman wrote: > On 30/01/2014 16:59, Dmitry Samersoff wrote: >> Staffan, >> >> No it's not to your code. Sorry for not being clean enough. >> >> You cleaned up unix code, but windows code remains bad. Particularly, it >> has bad unconditional sleep 2 >> >> I would propose replace *windows manipulation with CYGWIN/MKS pids* to >> call to JPS that return windows pid >> > I have a vague memory that we had to use ps to get the pid because of > the suspend=y test which cause the debuggee to suspect during startup. I > might be wrong on this of course, it was a long time ago. > > -Alan -- 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 Alan.Bateman at oracle.com Thu Jan 30 09:15:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Jan 2014 17:15:06 +0000 Subject: RFR(S): JDK-8029808 com/sun/jdi/ProcessAttachTest.sh times out In-Reply-To: <52EA87ED.20003@oracle.com> References: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> <52EA7F46.5070405@oracle.com> <16D6BA50-82FE-41F6-8423-FE218D397C58@oracle.com> <52EA84DC.5090008@oracle.com> <52EA872E.7070209@oracle.com> <52EA87ED.20003@oracle.com> Message-ID: <52EA889A.1020609@oracle.com> On 30/01/2014 17:12, Dmitry Samersoff wrote: > Alan, > > Do you know any official statements about MKS support for jdk8 and jdk9? > > Could we drop MKS support? > > Bad MKS habit to run extra shell is most of pid-related troubles with > tests. > I'm not aware of anyone still using MKS. I'm pretty sure that the new build is cygwin only. -Alan. From eric.mccorkle at oracle.com Thu Jan 30 11:28:02 2014 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 30 Jan 2014 19:28:02 +0000 Subject: hg: jdk8/tl/nashorn: 8032681: Issues with Nashorn Message-ID: <20140130192804.0C5A1628D4@hg.openjdk.java.net> Changeset: 11b83c913cca Author: attila Date: 2014-01-30 20:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/11b83c913cca 8032681: Issues with Nashorn Reviewed-by: ahgross, jlaskey, sundar + src/jdk/internal/dynalink/linker/GuardedTypeConversion.java ! src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.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/JavaAdapterServices.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/JDK-8014647.js ! test/script/basic/JDK-8014647.js.EXPECTED ! test/script/basic/javaclassoverrides.js ! test/script/basic/javaclassoverrides.js.EXPECTED ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java + test/src/jdk/nashorn/test/models/ClassWithFinalFinalizer.java + test/src/jdk/nashorn/test/models/ClassWithInheritedFinalFinalizer.java From serguei.spitsyn at oracle.com Thu Jan 30 16:01:54 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 Jan 2014 16:01:54 -0800 Subject: Need Second Reviewer Re: RR(S): JDK-7127191 SA JSDB does not display native symbols correctly for transported Linux cores In-Reply-To: <52E90D7D.6070601@oracle.com> References: <52DD4822.7080301@oracle.com> <52E90D7D.6070601@oracle.com> Message-ID: <52EAE7F2.9080504@oracle.com> Hi Dmitry, agent/src/os/linux/libproc_impl.c Q: To the lines 56-71 (I'm taking a blame for asking stupid questions): Is it possible the name argument has no leading slash '/' ? Does it work correctly in such a case? Is there a need to add a slash after the alt_path? agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java Something is wrong with the comment as it is not clear: 59 /* Typically we don't have too much loaded object here, 60 so final efforts to do a linear search less then sort and do 61 binary serach */ Did you want to say: "too many objects" or "to match loaded object" ? And what does it mean: "so final efforts to do a linear search less then sort and do binary serach" ? Did you want to say something like: "do a linear search instead of binary search" agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js nit: Remove redundant else at line 896, it saves the extra indent. nit: More simplifications to consider: function closestSymbolFor(addr) { var dso = (sa.cdbg == null) ? null : sa.cdbg.loadObjectContainingPC(addr); return (dso == null) ? null : dso.closestSymbolToPC(addr); } function loadObjectContainingPC(addr) { // sa.cdbg == null: no CDebugger support, return null return (sa.cdbg == null) ? null : sa.cdbg.loadObjectContainingPC(addr); } Thanks, Serguei On 1/29/14 6:17 AM, Dmitry Samersoff wrote: > Hi Everyone, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.02/ > > -Dmitry > > On 2014-01-20 20:00, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.01/ >> >> This fix doesn't solve all problems with symbol lookup in SA, but >> address the problem mentioned in bug reports. >> >> 1. I change algorithm of pathmap_open. Now, it tries to find library >> hardly. >> >> 2. I decided not to fix broken binary search in loadObjectContainingPC, >> because with less then 20 DSO's we typically have here performance of >> just linear search is approx the same as load, sort, convert to array >> and do binary search. >> >> -Dmitry >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140130/f8162991/attachment.html From serguei.spitsyn at oracle.com Thu Jan 30 16:36:55 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 Jan 2014 16:36:55 -0800 Subject: RFR(S): JDK-8029808 com/sun/jdi/ProcessAttachTest.sh times out In-Reply-To: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> References: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> Message-ID: <52EAF027.9020808@oracle.com> Looks good. Thanks, Serguei On 1/30/14 8:11 AM, Staffan Larsen wrote: > webrev: http://cr.openjdk.java.net/~sla/8029808/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8029808 > > I have tried to improve the stability of this test in a couple of ways. > > - Timeout set to 120s - it should never need to run that long > - When we start the debugee, we wait for the port-file to become available instead of waiting for output from the process. This should be less racy. > - stderr output from the debuggee and ShutdownDebuggee programs are captured with the stdout output > - Moved ?sleep 1? to after the check for the port file so the test is faster if the file already exists > > I?m not sure any of these are the cause of the timeout, but at least it should be a bit more stable now. > > /Staffan From david.holmes at oracle.com Thu Jan 30 22:43:57 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 Jan 2014 16:43:57 +1000 Subject: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) In-Reply-To: <4ca08b05-8f71-41eb-a3ab-34b5ae7a08b9@default> References: <4f7ffcc8-512f-4ff9-ba7b-c240cfe61f9c@default> <52EA4012.5050107@oracle.com> <4ca08b05-8f71-41eb-a3ab-34b5ae7a08b9@default> Message-ID: <52EB462D.6060900@oracle.com> Still good. On 30/01/2014 11:52 PM, Markus Gronlund wrote: > Thanks guys. > > Yes, the reason I added the return in 37 is to avoid anyone adding anything after the else clause moving forward. However, as Dmitry pointed out, an inversion of the version check will make this clearer - thanks. Given the death of hsx the version check seems removable altogether ;-) Cheers, David > In addition, just realized I hadn't pulled in the latest changes for the last webrev (for the diff), there were actually recent updates to this file as of: > > changeset: 9197:902aa2b3265c > user: simonis > date: Mon Jan 20 17:16:05 2014 +0100 > summary: 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests > > > So here's an updated webrev for your convenience: > > http://cr.openjdk.java.net/~mgronlun/8032518/webrev02/ > > Dmitry: > > With the pull, the locations of "free, throw, return" reduces to only two so I don't think refactoring here will add much. Thanks for pointing it out though. > > Cheers > Markus > > > -----Original Message----- > From: David Holmes > Sent: den 30 januari 2014 13:06 > To: Markus Gronlund; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev > Subject: Re: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation) > > This is good to me. The return at line 37 was unnecessary but it does help reinforce the pattern that you must return after JNU_ThrowXXX > > David > > On 30/01/2014 9:11 PM, Markus Gronlund wrote: >> Greetings, >> >> Kindly asking for reviews for this very small fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8032518 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/ >> >> Background: >> >> Still a bit puzzled about the manifestations of the crashes when >> inspecting the .mdmp files, which seems to be dereferencing a (debug) >> ResourceObj allocation[0] cookie address (~allocation address) at >> point of crashing. In addition, if the issue is an effect of not >> handling OOM correctly, I would expect to see a _pending_exception off >> the problematic thread, but there seems to be none. Also unknown why >> this seems to occur more on Windows x64 than any other platform. >> >> Testing: >> >> I have iterated the testcase nsk/stress/jck60/jck60014 locally - >> without suggested fixes I get about 10 crashes in about 300 runs. With >> fixes I am yet to see any crashes, currently ~600 iterations. >> >> I suggest to putback this first (since it should be fixed anyhow), to >> see the effect, before any more time is spent on tracing this down. >> >> Thanks >> >> Markus >> From staffan.larsen at oracle.com Thu Jan 30 23:41:18 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 31 Jan 2014 08:41:18 +0100 Subject: RFR(S): JDK-8029808 com/sun/jdi/ProcessAttachTest.sh times out In-Reply-To: <52EA889A.1020609@oracle.com> References: <79C6D4D7-F8A0-4A33-AF7A-D1007F227A86@oracle.com> <52EA7F46.5070405@oracle.com> <16D6BA50-82FE-41F6-8423-FE218D397C58@oracle.com> <52EA84DC.5090008@oracle.com> <52EA872E.7070209@oracle.com> <52EA87ED.20003@oracle.com> <52EA889A.1020609@oracle.com> Message-ID: <7B6F5891-C549-471F-8A5C-D3535B702FE2@oracle.com> On 30 jan 2014, at 18:15, Alan Bateman wrote: > On 30/01/2014 17:12, Dmitry Samersoff wrote: >> Alan, >> >> Do you know any official statements about MKS support for jdk8 and jdk9? >> >> Could we drop MKS support? >> >> Bad MKS habit to run extra shell is most of pid-related troubles with >> tests. >> > I'm not aware of anyone still using MKS. I'm pretty sure that the new build is cygwin only. The new build requires cygwin, but there are still many SQE machines that use MKS as far as I can tell from the logs I see. /Staffan From dmitry.samersoff at oracle.com Fri Jan 31 01:48:12 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 31 Jan 2014 13:48:12 +0400 Subject: Need Second Reviewer Re: RR(S): JDK-7127191 SA JSDB does not display native symbols correctly for transported Linux cores In-Reply-To: <52EAE7F2.9080504@oracle.com> References: <52DD4822.7080301@oracle.com> <52E90D7D.6070601@oracle.com> <52EAE7F2.9080504@oracle.com> Message-ID: <52EB715C.7080506@oracle.com> Serguei, Thank you for review. I'd updated webrev (see also below) http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.03/ On 2014-01-31 04:01, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > > agent/src/os/linux/libproc_impl.c > > Q: To the lines 56-71 (I'm taking a blame for asking stupid questions): > Is it possible the name argument has no leading slash '/' ? > Does it work correctly in such a case? > Is there a need to add a slash after the alt_path? Linker always put full path to solib image to process .DYNSECTION. The only exclusion - couple of pseudo-objects providing interface to kernel like linux-gate.so etc, but SA doesn't handle it. I put appropriate comment. > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java > > Something is wrong with the comment as it is not clear: > > 59 /* Typically we don't have too much loaded object here, > 60 so final efforts to do a linear search less then sort and do > 61 binary serach */ > > Did you want to say: "too many objects" or "to match loaded object" ? > And what does it mean: > "so final efforts to do a linear search less then sort and do binary > serach" ? > > Did you want to say something like: > "do a linear search instead of binary search" Comments rephrased. > agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js > > nit: Remove redundant else at line 896, it saves the extra indent. I`m itching to reformat this function to make it readable since first time i saw it. You gives me enough courage to do it ;) So see webrev. > nit: More simplifications to consider: > > function closestSymbolFor(addr) { > var dso = (sa.cdbg == null) ? null : > sa.cdbg.loadObjectContainingPC(addr); > return (dso == null) ? null : dso.closestSymbolToPC(addr); > } > > function loadObjectContainingPC(addr) { > // sa.cdbg == null: no CDebugger support, return null > return (sa.cdbg == null) ? null : > sa.cdbg.loadObjectContainingPC(addr); > } I would prefer to keep full if for readability. -Dmitry > > > Thanks, > Serguei > > On 1/29/14 6:17 AM, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.02/ >> >> -Dmitry >> >> On 2014-01-20 20:00, Dmitry Samersoff wrote: >>> Hi Everyone, >>> >>> Please review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.01/ >>> >>> This fix doesn't solve all problems with symbol lookup in SA, but >>> address the problem mentioned in bug reports. >>> >>> 1. I change algorithm of pathmap_open. Now, it tries to find library >>> hardly. >>> >>> 2. I decided not to fix broken binary search in loadObjectContainingPC, >>> because with less then 20 DSO's we typically have here performance of >>> just linear search is approx the same as load, sort, convert to array >>> and do binary search. >>> >>> -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 serguei.spitsyn at oracle.com Fri Jan 31 02:12:06 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 Jan 2014 02:12:06 -0800 Subject: Need Second Reviewer Re: RR(S): JDK-7127191 SA JSDB does not display native symbols correctly for transported Linux cores In-Reply-To: <52EB715C.7080506@oracle.com> References: <52DD4822.7080301@oracle.com> <52E90D7D.6070601@oracle.com> <52EAE7F2.9080504@oracle.com> <52EB715C.7080506@oracle.com> Message-ID: <52EB76F6.5080207@oracle.com> Dmitry, It looks good. Thank you for answers and code adjustment. Thanks, Serguei On 1/31/14 1:48 AM, Dmitry Samersoff wrote: > Serguei, > > Thank you for review. I'd updated webrev (see also below) > > http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.03/ > > > On 2014-01-31 04:01, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> >> agent/src/os/linux/libproc_impl.c >> >> Q: To the lines 56-71 (I'm taking a blame for asking stupid questions): >> Is it possible the name argument has no leading slash '/' ? >> Does it work correctly in such a case? >> Is there a need to add a slash after the alt_path? > Linker always put full path to solib image to process .DYNSECTION. The > only exclusion - couple of pseudo-objects providing interface to kernel > like linux-gate.so etc, but SA doesn't handle it. > > I put appropriate comment. > >> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java >> >> Something is wrong with the comment as it is not clear: >> >> 59 /* Typically we don't have too much loaded object here, >> 60 so final efforts to do a linear search less then sort and do >> 61 binary serach */ >> >> Did you want to say: "too many objects" or "to match loaded object" ? >> And what does it mean: >> "so final efforts to do a linear search less then sort and do binary >> serach" ? >> >> Did you want to say something like: >> "do a linear search instead of binary search" > Comments rephrased. > >> agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js >> >> nit: Remove redundant else at line 896, it saves the extra indent. > I`m itching to reformat this function to make it readable since first > time i saw it. > > You gives me enough courage to do it ;) So see webrev. > > >> nit: More simplifications to consider: >> >> function closestSymbolFor(addr) { >> var dso = (sa.cdbg == null) ? null : >> sa.cdbg.loadObjectContainingPC(addr); >> return (dso == null) ? null : dso.closestSymbolToPC(addr); >> } >> >> function loadObjectContainingPC(addr) { >> // sa.cdbg == null: no CDebugger support, return null >> return (sa.cdbg == null) ? null : >> sa.cdbg.loadObjectContainingPC(addr); >> } > I would prefer to keep full if for readability. > > -Dmitry > > >> >> Thanks, >> Serguei >> >> On 1/29/14 6:17 AM, Dmitry Samersoff wrote: >>> Hi Everyone, >>> >>> Please review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.02/ >>> >>> -Dmitry >>> >>> On 2014-01-20 20:00, Dmitry Samersoff wrote: >>>> Hi Everyone, >>>> >>>> Please review the fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-7127191/webrev.01/ >>>> >>>> This fix doesn't solve all problems with symbol lookup in SA, but >>>> address the problem mentioned in bug reports. >>>> >>>> 1. I change algorithm of pathmap_open. Now, it tries to find library >>>> hardly. >>>> >>>> 2. I decided not to fix broken binary search in loadObjectContainingPC, >>>> because with less then 20 DSO's we typically have here performance of >>>> just linear search is approx the same as load, sort, convert to array >>>> and do binary search. >>>> >>>> -Dmitry >>>> > From paul.sandoz at oracle.com Fri Jan 31 03:24:09 2014 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 31 Jan 2014 11:24:09 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20140131112700.AFEF362911@hg.openjdk.java.net> Changeset: 9f098aed44c0 Author: anazarov Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f098aed44c0 8032025: Update repeating annotations demo Reviewed-by: jfranck + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Device.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Kettle.xml + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Module.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/PluginChecker.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Require.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/RequireContainer.java + src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/BoilerPlugin.java + src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/ExtendedBoilerPlugin.java + src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/TimerPlugin.java + src/share/sample/annotations/Validator/src/PositiveIntegerSupplier.java + src/share/sample/annotations/Validator/src/SupplierValidator.java + src/share/sample/annotations/Validator/src/Validate.java + src/share/sample/annotations/Validator/src/Validator.java + src/share/sample/annotations/index.html Changeset: f72a8df6a2ed Author: anazarov Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f72a8df6a2ed 8031650: Update bulk operation demo Reviewed-by: psandoz, mduigou + src/share/sample/lambda/BulkDataOperations/index.html + src/share/sample/lambda/BulkDataOperations/src/CSVProcessor.java + src/share/sample/lambda/BulkDataOperations/src/Grep.java + src/share/sample/lambda/BulkDataOperations/src/PasswordGenerator.java + src/share/sample/lambda/BulkDataOperations/src/WC.java Changeset: 4574011c1689 Author: anazarov Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4574011c1689 8032020: Update try-with-resources demo Reviewed-by: darcy, alanb, smarks + src/share/sample/try-with-resources/index.html + src/share/sample/try-with-resources/src/CustomAutoCloseableSample.java + src/share/sample/try-with-resources/src/Unzip.java + src/share/sample/try-with-resources/src/ZipCat.java Changeset: a4f68fc5f353 Author: psandoz Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4f68fc5f353 8032056: Create demo to illustrate new practices of the default methods usage Reviewed-by: briangoetz, rfield, psandoz Contributed-by: taras.ledkov at oracle.com + src/share/sample/lambda/DefaultMethods/ArrayIterator.java + src/share/sample/lambda/DefaultMethods/DiamondInheritance.java + src/share/sample/lambda/DefaultMethods/Inheritance.java + src/share/sample/lambda/DefaultMethods/MixIn.java + src/share/sample/lambda/DefaultMethods/Reflection.java + src/share/sample/lambda/DefaultMethods/SimplestUsage.java From eric.mccorkle at oracle.com Fri Jan 31 09:13:33 2014 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Fri, 31 Jan 2014 17:13:33 +0000 Subject: hg: jdk8/tl/jdk: 8033278: Missed access checks for Lookup.unreflect* after 8032585 Message-ID: <20140131171358.56F0A62926@hg.openjdk.java.net> Changeset: f684c9773858 Author: vlivanov Date: 2014-01-31 21:07 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f684c9773858 8033278: Missed access checks for Lookup.unreflect* after 8032585 Reviewed-by: jrose, twisti ! src/share/classes/sun/invoke/util/VerifyAccess.java ! test/java/lang/invoke/ProtectedMemberDifferentPackage/Test.java ! test/java/lang/invoke/ProtectedMemberDifferentPackage/p1/T2.java ! test/java/lang/invoke/ProtectedMemberDifferentPackage/p2/T3.java From dmitry.samersoff at oracle.com Fri Jan 31 11:42:01 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 31 Jan 2014 23:42:01 +0400 Subject: RR(S): JDK-8023667 SA: ExceptionBlob and other C2 classes not available in client VM Message-ID: <52EBFC89.3030809@oracle.com> Hi Everybody, Please review the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8023667/webrev.01/ sa.js try to initialize all possible VM structures regardless of type of VM we are running on -- 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 serguei.spitsyn at oracle.com Fri Jan 31 18:58:21 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 Jan 2014 18:58:21 -0800 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") Message-ID: <52EC62CD.8000300@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-6471769 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ Summary: There is a general issue in the suspend equivalent condition mechanism: Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results: - 1-st: true - 2-nd: false This more generic suspend equivalent issue is covered by another bug: https://bugs.openjdk.java.net/browse/JDK-6280037 The bug to fix in this review is a specific manifestation of the 6280037 in the JVMTI GetFrameCount() that has a big impact on the SQE nightly. It is on the Test Stabilization radar (as well as the 6280037). There are many tests intermittently failing because of this. The webrev for review is a one-liner work around the 6280037 for the GetFrameCount(). The JVMTI GetFrameCount() spec tells: "If this function is called for a thread actively executing bytecodes (for example, not the current thread and not suspended), the information returned is transient." So, it is Ok to call the GetFrameCount() for non-suspended target threads. To achieve safety, the frame count for non-suspended threads is calculated at a safepoint. It should be Ok and more safe to do the same for suspended threads as well. There is no big performance impact because it is already on a slow path. It is still important to avoid safepointing when the target thread is current. The bug 6280037 should go out of the Test Stabilization radar (remove the svc-nightly label) as the most of the impacted tests are covered by the 6471769. Testing: In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests Thanks, Serguei From christian.thalinger at oracle.com Fri Jan 31 20:11:59 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 31 Jan 2014 20:11:59 -0800 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52EC62CD.8000300@oracle.com> References: <52EC62CD.8000300@oracle.com> Message-ID: <69A2D902-EBD5-4932-A9C1-E8063CB935B7@oracle.com> I cannot comment on the performance impact but the change looks good. On Jan 31, 2014, at 6:58 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6471769 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ > > Summary: > > There is a general issue in the suspend equivalent condition mechanism: > Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results: > - 1-st: true > - 2-nd: false > > This more generic suspend equivalent issue is covered by another bug: > https://bugs.openjdk.java.net/browse/JDK-6280037 > > The bug to fix in this review is a specific manifestation of the 6280037 > in the JVMTI GetFrameCount() that has a big impact on the SQE nightly. > It is on the Test Stabilization radar (as well as the 6280037). > There are many tests intermittently failing because of this. > > The webrev for review is a one-liner work around the 6280037 for the GetFrameCount(). > > The JVMTI GetFrameCount() spec tells: > "If this function is called for a thread actively executing bytecodes (for example, > not the current thread and not suspended), the information returned is transient." > > So, it is Ok to call the GetFrameCount() for non-suspended target threads. > To achieve safety, the frame count for non-suspended threads is calculated at a safepoint. > It should be Ok and more safe to do the same for suspended threads as well. > There is no big performance impact because it is already on a slow path. > It is still important to avoid safepointing when the target thread is current. > > The bug 6280037 should go out of the Test Stabilization radar (remove the svc-nightly label) > as the most of the impacted tests are covered by the 6471769. > > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests > > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Fri Jan 31 21:43:04 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 Jan 2014 21:43:04 -0800 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <69A2D902-EBD5-4932-A9C1-E8063CB935B7@oracle.com> References: <52EC62CD.8000300@oracle.com> <69A2D902-EBD5-4932-A9C1-E8063CB935B7@oracle.com> Message-ID: <52EC8968.20902@oracle.com> Thanks, Christian! Serguei On 1/31/14 8:11 PM, Christian Thalinger wrote: > I cannot comment on the performance impact but the change looks good. > > On Jan 31, 2014, at 6:58 PM, serguei.spitsyn at oracle.com wrote: > >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6471769 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ >> >> Summary: >> >> There is a general issue in the suspend equivalent condition mechanism: >> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results: >> - 1-st: true >> - 2-nd: false >> >> This more generic suspend equivalent issue is covered by another bug: >> https://bugs.openjdk.java.net/browse/JDK-6280037 >> >> The bug to fix in this review is a specific manifestation of the 6280037 >> in the JVMTI GetFrameCount() that has a big impact on the SQE nightly. >> It is on the Test Stabilization radar (as well as the 6280037). >> There are many tests intermittently failing because of this. >> >> The webrev for review is a one-liner work around the 6280037 for the GetFrameCount(). >> >> The JVMTI GetFrameCount() spec tells: >> "If this function is called for a thread actively executing bytecodes (for example, >> not the current thread and not suspended), the information returned is transient." >> >> So, it is Ok to call the GetFrameCount() for non-suspended target threads. >> To achieve safety, the frame count for non-suspended threads is calculated at a safepoint. >> It should be Ok and more safe to do the same for suspended threads as well. >> There is no big performance impact because it is already on a slow path. >> It is still important to avoid safepointing when the target thread is current. >> >> The bug 6280037 should go out of the Test Stabilization radar (remove the svc-nightly label) >> as the most of the impacted tests are covered by the 6471769. >> >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests >> >> >> Thanks, >> Serguei >>