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 vladimir.kozlov at oracle.com Fri Jan 3 11:58:38 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Jan 2014 11:58:38 -0800 Subject: RFR(L): 8028468: Add inlining information into ciReplay In-Reply-To: <2D5B6C39-5ED3-4FD5-A185-614A3A83D7C8@oracle.com> References: <529E92AB.9060901@oracle.com> <52BE343C.8030500@oracle.com> <2D5B6C39-5ED3-4FD5-A185-614A3A83D7C8@oracle.com> Message-ID: <52C7166E.1080807@oracle.com> On 1/3/14 11:42 AM, Christian Thalinger wrote: > Why are we using a different file for the inline data? I want to keep it smaller when we want only replay inlining. They have only one line with "compile" command and inline information. So they can't be used for normal compilation replay. They are created and used only with commands DumpInline and ReplayInline. Otherwise inlining info is included into replay_*.log file with other replay info. Thanks, Vladimir > > 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 christian.thalinger at oracle.com Fri Jan 3 12:02:33 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 3 Jan 2014 12:02:33 -0800 Subject: RFR(L): 8028468: Add inlining information into ciReplay In-Reply-To: <52C7166E.1080807@oracle.com> References: <529E92AB.9060901@oracle.com> <52BE343C.8030500@oracle.com> <2D5B6C39-5ED3-4FD5-A185-614A3A83D7C8@oracle.com> <52C7166E.1080807@oracle.com> Message-ID: <75A19782-060B-417B-9E5F-AC7ADD2F6E3A@oracle.com> On Jan 3, 2014, at 11:58 AM, Vladimir Kozlov wrote: > > On 1/3/14 11:42 AM, Christian Thalinger wrote: >> Why are we using a different file for the inline data? > > I want to keep it smaller when we want only replay inlining. They have only one line with "compile" command and inline information. So they can't be used for normal compilation replay. They are created and used only with commands DumpInline and ReplayInline. Otherwise inlining info is included into replay_*.log file with other replay info. So we can easily replay the inlining while running the application. That makes sense. Let me finish the review? > > Thanks, > Vladimir > >> >> 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 john.coomes at oracle.com Fri Jan 3 12:54:55 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 20:54:55 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b122 for changeset 347009c58816 Message-ID: <20140103205455.CC87A62376@hg.openjdk.java.net> Changeset: ff1478785e43 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ff1478785e43 Added tag jdk8-b122 for changeset 347009c58816 ! .hgtags From john.coomes at oracle.com Fri Jan 3 12:55:05 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 20:55:05 +0000 Subject: hg: hsx/hotspot-comp/corba: 5 new changesets Message-ID: <20140103205510.53C9562377@hg.openjdk.java.net> Changeset: eb5d3f8ca0ca Author: mfang Date: 2013-12-17 22:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/corba/rev/2a8fa4da6ad3 Merge Changeset: 5ca1b4c282b8 Author: ssides Date: 2013-12-23 18:42 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/corba/rev/0cd687347540 Merge Changeset: 1ecd4619f60c Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/1ecd4619f60c Added tag jdk8-b122 for changeset 0cd687347540 ! .hgtags From john.coomes at oracle.com Fri Jan 3 12:55:22 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 20:55:22 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 7 new changesets Message-ID: <20140103205546.6007162378@hg.openjdk.java.net> Changeset: 3e5bf0372a93 Author: joehw Date: 2013-12-12 11:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxp/rev/9c7e3a68dc77 Merge Changeset: fad4b4d28599 Author: lana Date: 2013-12-23 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/fad4b4d28599 Merge Changeset: 1bedbbce236a Author: joehw Date: 2013-12-20 09:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxp/rev/93bf25903af0 Merge Changeset: 4e35b5b6d2e5 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/4e35b5b6d2e5 Added tag jdk8-b122 for changeset 93bf25903af0 ! .hgtags From john.coomes at oracle.com Fri Jan 3 13:14:42 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 21:14:42 +0000 Subject: hg: hsx/hotspot-comp/nashorn: 8 new changesets Message-ID: <20140103211458.2E81C6237E@hg.openjdk.java.net> Changeset: 752554d45a07 Author: sundar Date: 2013-12-09 09:48 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/nashorn/rev/739f3abdfa55 Merge Changeset: 4706897b4dec Author: attila Date: 2013-12-09 10:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/nashorn/rev/e452a3797290 Merge Changeset: 0225a7ca37ab Author: lana Date: 2013-12-12 19:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/0225a7ca37ab Merge Changeset: 9d112a0e7df7 Author: lana Date: 2013-12-23 14:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/9d112a0e7df7 Merge Changeset: 688f4167f921 Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/688f4167f921 Added tag jdk8-b122 for changeset 9d112a0e7df7 ! .hgtags From john.coomes at oracle.com Fri Jan 3 12:55:58 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 20:55:58 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b122 for changeset bc622ba563f9 Message-ID: <20140103205606.E533F62379@hg.openjdk.java.net> Changeset: 91f5c542ccad Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/91f5c542ccad Added tag jdk8-b122 for changeset bc622ba563f9 ! .hgtags From john.coomes at oracle.com Fri Jan 3 13:13:08 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 21:13:08 +0000 Subject: hg: hsx/hotspot-comp/langtools: 12 new changesets Message-ID: <20140103211426.D164E6237C@hg.openjdk.java.net> Changeset: 2d0a0ae7fa9c Author: ksrini Date: 2013-12-06 09:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/langtools/rev/d80c3d6f4f05 Merge Changeset: 8832b6048e65 Author: vromero Date: 2013-12-13 14:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/232b9cf6303a Merge Changeset: a345cf28faca Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a345cf28faca Added tag jdk8-b122 for changeset 232b9cf6303a ! .hgtags From igor.ignatyev at oracle.com Sat Jan 4 23:27:52 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 05 Jan 2014 11:27:52 +0400 Subject: RFR(XS) : 8031115 : intrinsics for Math.decrementExact(J) and incrementExact(J) don't work Message-ID: <52C90978.2000900@oracle.com> Hi all, Please review patch. Problem: intrinsics _decrementExactL and _incrementExactL have long2_long_signature instead of long_long_signature webrev: http://cr.openjdk.java.net/~iignatyev/8031115/webrev.00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8031115 testing: failing tests (compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java and IncrementExactLongTest.java) -- Igor From christian.thalinger at oracle.com Mon Jan 6 11:11:37 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 Jan 2014 11:11:37 -0800 Subject: [9] RFR (XS): 8031199: _MSC_VER is only defined on _WIN32 Message-ID: <333450A7-7B7F-410D-BE33-E2A0AEE6612D@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8031199 http://cr.openjdk.java.net/~twisti/8031199 8031199: _MSC_VER is only defined on _WIN32 Reviewed-by: Clang complains about _MSC_VER not being defined when compiling ADLC. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140106/6049583d/attachment.html From igor.veresov at oracle.com Mon Jan 6 11:22:45 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 6 Jan 2014 11:22:45 -0800 Subject: [9] RFR (XS): 8031199: _MSC_VER is only defined on _WIN32 In-Reply-To: <333450A7-7B7F-410D-BE33-E2A0AEE6612D@oracle.com> References: <333450A7-7B7F-410D-BE33-E2A0AEE6612D@oracle.com> Message-ID: <84F23831-8CA7-4C1F-8A0F-CFABFFB437F4@oracle.com> Looks good. igor On Jan 6, 2014, at 11:11 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8031199 > http://cr.openjdk.java.net/~twisti/8031199 > > 8031199: _MSC_VER is only defined on _WIN32 > Reviewed-by: > > Clang complains about _MSC_VER not being defined when compiling ADLC. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140106/af67dd05/attachment.html From vladimir.kozlov at oracle.com Mon Jan 6 10:54:55 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Jan 2014 10:54:55 -0800 Subject: RFR(XS) : 8031115 : intrinsics for Math.decrementExact(J) and incrementExact(J) don't work In-Reply-To: <52C90978.2000900@oracle.com> References: <52C90978.2000900@oracle.com> Message-ID: <52CAFBFF.8080103@oracle.com> Looks good. Vladimir On 1/4/14 11:27 PM, Igor Ignatyev wrote: > Hi all, > > Please review patch. > > Problem: > intrinsics _decrementExactL and _incrementExactL have long2_long_signature instead of long_long_signature > > webrev: http://cr.openjdk.java.net/~iignatyev/8031115/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8031115 > testing: failing tests (compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java and IncrementExactLongTest.java) > From vladimir.kozlov at oracle.com Mon Jan 6 11:25:12 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Jan 2014 11:25:12 -0800 Subject: [9] RFR (XS): 8031199: _MSC_VER is only defined on _WIN32 In-Reply-To: <333450A7-7B7F-410D-BE33-E2A0AEE6612D@oracle.com> References: <333450A7-7B7F-410D-BE33-E2A0AEE6612D@oracle.com> Message-ID: <52CB0318.9030505@oracle.com> Good. Vladimir On 1/6/14 11:11 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8031199 > http://cr.openjdk.java.net/~twisti/8031199 > > 8031199: _MSC_VER is only defined on _WIN32 > Reviewed-by: > > Clang complains about _MSC_VER not being defined when compiling ADLC. > From roland.westrelin at oracle.com Mon Jan 6 06:04:11 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 6 Jan 2014 15:04:11 +0100 Subject: RFR(S): 8029873: compiler/uncommontrap/TestStackBangRbp.java crashes with SIGSEGV Message-ID: http://cr.openjdk.java.net/~roland/8029873/webrev.00/ Class loading from the uncommon trap blob calls java code which may trigger a stack overflow. If the overflow happens right before the java code returns to the runtime, the stack is left unguarded when we return to the uncommon trap blob. The stack banging in the uncommon trap blob can trigger a new stack overflow and because the stack is not guarded we crash. The fix consists in reguarding the stack after the class loading if needed (deoptimization.cpp). The test case doesn?t reproduce this problem (I couldn?t get a test case to do it reliably). It triggers another similar problem. A stack overflow can be propagated to a compiled method while the stack is still unguarded. If the compiled method is marked for deoptimization then we go directly go to the deopt blob. If stack banging in the deopt blob triggers a new stack overflow we crash for the same reason as above. The fix is to reguard the stack before we go to the uncommon blob (sharedRuntime.cpp). Roland. From albert.noll at oracle.com Mon Jan 6 00:07:19 2014 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 06 Jan 2014 09:07:19 +0100 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <52B5F005.2070209@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <526EB414.1030705@oracle.com> <52B28FB4.6030609@oracle.com> <52B5F005.2070209@oracle.com> Message-ID: <52CA6437.3070805@oracle.com> Hi Vladimir, thanks for your explanation. I agree with your suggestion. The new version has the corresponding check inside *CompileBroker::assign_compile_id()* >Also why you return only in such case and not for normal native wrappers? Thanks for catching this bug. I fixed it in the new version. Here is the link to the new webrev: http://cr.openjdk.java.net/~anoll/8022494/webrev.05/ Best, Albert On 12/21/2013 08:46 PM, Vladimir Kozlov wrote: > We have to generate method_handle_intrinsic so we can't simple show > warning and continue execution - we can't do that. > I suggested to generate compile_id always in such case and convert > your warning to assert (since it could only happens in debug VM). > Also why you return only in such case and not for normal native wrappers? > > + if (method->is_method_handle_intrinsic()) { > + warning("Must generate wrapper for method handle intrinsic"); > + return; > + } > --- > + assert(!method->is_method_handle_intrinsic()), "Must generate > wrapper for method handle intrinsic"); > + return; > > Thanks, > Vladimir > > On 12/18/13 10:18 PM, Albert Noll wrote: >> Christian, Vladimir, thanks for the review. >> >> @Christian: Thanks for catching the typo >> >> @Vladimir: I am not sure if I understand your suggestion correctly. >> Could you please clarify what you >> mean by "The warning above will be assert after that." >> >> Best, >> Albert >> >> >> On 10/28/2013 07:59 PM, Vladimir Kozlov wrote: >>> Albert, >>> >>> The warning is not correct solution since we HAVE to generate method >>> handle intrinsics if your comment is correct: >>> >>> + // must be generated for method handle intrinsics (8026407), >>> print out a warning. >>> + if (method->is_method_handle_intrinsic()) { >>> + warning("Must generate wrapper for method handle intrinsic"); >>> + return; >>> + } >>> >>> I think assign_compile_id() should generate id in such case >>> regardless CIStart and CIStop values. The warning above >>> will be assert after that. >>> >>> And, please, file RFE (starter task) to cleanup type of compile_id. >>> In some places it declared as 'int' and in an >>> other as 'uint'. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/24/13 1:56 AM, Albert Noll wrote: >>>> Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>>> >>>> >>>> Best, >>>> Albert >>>> >>>> On 24.10.2013 10:21, Albert Noll wrote: >>>>> Hi Aleksey, >>>>> >>>>> thanks for looking at this. >>>>> >>>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>>> Here is the updated webrev: >>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>> Nice to see the locking gone. >>>>>> >>>>>> compileBroker.cpp: >>>>>> * Is that considered correct that OSR and normal compilations are >>>>>> marked differently when running in debug mode, but not in release? I >>>>>> understand the comment before assign_compile_id, so this is more >>>>>> of the >>>>>> philosophical question. >>>>> Compilation IDs are only different if -XX:CICountOSR is set, which is >>>>> defaulted to false. >>>>>> sharedRuntime.cpp: >>>>>> * Why do you need "2653 return;" in the method tail? >>>>> Thanks for spotting this. I missed it during the cleanup. >>>>> >>>>> Best, >>>>> Albert >>>>>> Thanks, >>>>>> -Aleksey. >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140106/06ea5021/attachment-0001.html From christian.thalinger at oracle.com Mon Jan 6 11:40:59 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 Jan 2014 11:40:59 -0800 Subject: [9] RFR (XS): 8031199: _MSC_VER is only defined on _WIN32 In-Reply-To: <52CB0318.9030505@oracle.com> References: <333450A7-7B7F-410D-BE33-E2A0AEE6612D@oracle.com> <52CB0318.9030505@oracle.com> Message-ID: Thanks, Igor and Vladimir. On Jan 6, 2014, at 11:25 AM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 1/6/14 11:11 AM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8031199 >> http://cr.openjdk.java.net/~twisti/8031199 >> >> 8031199: _MSC_VER is only defined on _WIN32 >> Reviewed-by: >> >> Clang complains about _MSC_VER not being defined when compiling ADLC. >> From roland.westrelin at oracle.com Mon Jan 6 06:27:55 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 6 Jan 2014 15:27:55 +0100 Subject: RFR(XS): 8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a Message-ID: <49A0DDDE-9C08-4E27-94AA-D32AD4553101@oracle.com> C1 generated code encodes a compressed oop into to temp register before it stores it. In case of patching, a GC may happen and the compressed oop may be incorrect when it is stored to memory. http://cr.openjdk.java.net/~roland/8028764/webrev.00/ Roland. From christian.thalinger at oracle.com Mon Jan 6 08:55:13 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 Jan 2014 08:55:13 -0800 Subject: RFR(XS) : 8031115 : intrinsics for Math.decrementExact(J) and incrementExact(J) don't work In-Reply-To: <52C90978.2000900@oracle.com> References: <52C90978.2000900@oracle.com> Message-ID: <94AB179A-F162-4E01-BE5A-8E524C7ADB73@oracle.com> Looks good. On Jan 4, 2014, at 11:27 PM, Igor Ignatyev wrote: > Hi all, > > Please review patch. > > Problem: > intrinsics _decrementExactL and _incrementExactL have long2_long_signature instead of long_long_signature > > webrev: http://cr.openjdk.java.net/~iignatyev/8031115/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8031115 > testing: failing tests (compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java and IncrementExactLongTest.java) > > -- > Igor From igor.veresov at oracle.com Mon Jan 6 11:57:53 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 6 Jan 2014 11:57:53 -0800 Subject: RFR(XS): 8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a In-Reply-To: <49A0DDDE-9C08-4E27-94AA-D32AD4553101@oracle.com> References: <49A0DDDE-9C08-4E27-94AA-D32AD4553101@oracle.com> Message-ID: Thanks for finding this! Looks good. igor On Jan 6, 2014, at 6:27 AM, Roland Westrelin wrote: > C1 generated code encodes a compressed oop into to temp register before it stores it. In case of patching, a GC may happen and the compressed oop may be incorrect when it is stored to memory. > > http://cr.openjdk.java.net/~roland/8028764/webrev.00/ > > Roland. From rednaxelafx at gmail.com Mon Jan 6 12:29:31 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 6 Jan 2014 12:29:31 -0800 Subject: Outdated comments in OptoRuntime::uncommon_trap_Type() In-Reply-To: References: Message-ID: Hi all, Ping. Would anybody take a look at this trivial issue now that JDK9 repos are open? Thanks, Kris On Fri, Dec 13, 2013 at 11:35 AM, Krystal Mok wrote: > Hi all, > > There's a bit of comment in OptoRuntime::uncommon_trap_Type(): > > // Symbol* name of class to be loaded > fields[TypeFunc::Parms+0] = TypeInt::INT; > > It had been updated from "symbolOop name of class to be loaded", but this > earlier version had been outdated for quite some time. The parameter passed > into the uncommon trap stub is the "trap_reason", which is an int that > combines the DeoptReason and DeoptAction, instead of a symbolOop or Symbol* > for the name of class to be loaded. Would anybody fix this trivial thing, > please? > > diff -r 8beff993531a src/share/vm/opto/runtime.cpp > --- a/src/share/vm/opto/runtime.cpp Thu Dec 12 18:57:38 2013 -0500 > +++ b/src/share/vm/opto/runtime.cpp Fri Dec 13 11:35:21 2013 -0800 > @@ -568,8 +568,7 @@ > const TypeFunc *OptoRuntime::uncommon_trap_Type() { > // create input type (domain) > const Type **fields = TypeTuple::fields(1); > - // Symbol* name of class to be loaded > - fields[TypeFunc::Parms+0] = TypeInt::INT; > + fields[TypeFunc::Parms+0] = TypeInt::INT; // trap_reason (deopt reason > and action) > const TypeTuple *domain = TypeTuple::make(TypeFunc::Parms+1, fields); > > // create result type (range) > > Thanks, > - Kris (OpenJDK ID: kmo) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140106/3a1c727c/attachment.html From christian.thalinger at oracle.com Mon Jan 6 13:38:06 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 Jan 2014 13:38:06 -0800 Subject: RFR(XS): 8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a In-Reply-To: <49A0DDDE-9C08-4E27-94AA-D32AD4553101@oracle.com> References: <49A0DDDE-9C08-4E27-94AA-D32AD4553101@oracle.com> Message-ID: <0CDE1B28-D5B6-403E-8584-1FF2F5CD5BA0@oracle.com> Looks good. On Jan 6, 2014, at 6:27 AM, Roland Westrelin wrote: > C1 generated code encodes a compressed oop into to temp register before it stores it. In case of patching, a GC may happen and the compressed oop may be incorrect when it is stored to memory. > > http://cr.openjdk.java.net/~roland/8028764/webrev.00/ > > Roland. From christian.thalinger at oracle.com Mon Jan 6 14:13:37 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 Jan 2014 14:13:37 -0800 Subject: [9] RFR (S): 8029305: add type tag to AbstractCompiler Message-ID: <1C5B59E1-7A77-4F13-9945-CC2D4D309C01@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8029305 http://cr.openjdk.java.net/~twisti/8029305 8029305: add type tag to AbstractCompiler Reviewed-by: Add a closed set of concrete compiler classes. Using an tag like this avoids a confusing use of macros around the definition of the is_ methods. As a followup to this change I?m going to replace nmethod::_compiler with a flags field that stores AbstractCompiler::Type values instead: [#JDK-8031211] replace nmethod::_compiler with a flags field that stores AbstractCompiler::Type values instead -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140106/d85928d6/attachment.html From igor.veresov at oracle.com Mon Jan 6 14:23:34 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 6 Jan 2014 14:23:34 -0800 Subject: [9] RFR (S): 8029305: add type tag to AbstractCompiler In-Reply-To: <1C5B59E1-7A77-4F13-9945-CC2D4D309C01@oracle.com> References: <1C5B59E1-7A77-4F13-9945-CC2D4D309C01@oracle.com> Message-ID: Looks good. igor On Jan 6, 2014, at 2:13 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8029305 > http://cr.openjdk.java.net/~twisti/8029305 > > 8029305: add type tag to AbstractCompiler > Reviewed-by: > > Add a closed set of concrete compiler classes. Using an tag like this avoids a confusing use of macros around the definition of the is_ methods. > > As a followup to this change I?m going to replace nmethod::_compiler with a flags field that stores AbstractCompiler::Type values instead: > > [#JDK-8031211] replace nmethod::_compiler with a flags field that stores AbstractCompiler::Type values instead > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140106/af4a5073/attachment.html From christian.thalinger at oracle.com Mon Jan 6 14:31:37 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 Jan 2014 14:31:37 -0800 Subject: RFR(S): 8029873: compiler/uncommontrap/TestStackBangRbp.java crashes with SIGSEGV In-Reply-To: References: Message-ID: Looks good. On Jan 6, 2014, at 6:04 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8029873/webrev.00/ > > Class loading from the uncommon trap blob calls java code which may trigger a stack overflow. If the overflow happens right before the java code returns to the runtime, the stack is left unguarded when we return to the uncommon trap blob. The stack banging in the uncommon trap blob can trigger a new stack overflow and because the stack is not guarded we crash. The fix consists in reguarding the stack after the class loading if needed (deoptimization.cpp). > > The test case doesn?t reproduce this problem (I couldn?t get a test case to do it reliably). It triggers another similar problem. A stack overflow can be propagated to a compiled method while the stack is still unguarded. If the compiled method is marked for deoptimization then we go directly go to the deopt blob. If stack banging in the deopt blob triggers a new stack overflow we crash for the same reason as above. The fix is to reguard the stack before we go to the uncommon blob (sharedRuntime.cpp). > > Roland. > From christian.thalinger at oracle.com Mon Jan 6 14:32:08 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 Jan 2014 14:32:08 -0800 Subject: [9] RFR (S): 8029305: add type tag to AbstractCompiler In-Reply-To: References: <1C5B59E1-7A77-4F13-9945-CC2D4D309C01@oracle.com> Message-ID: <31C1B22B-2578-490B-93C9-DBA2E93A1AF2@oracle.com> Thanks, Igor. On Jan 6, 2014, at 2:23 PM, Igor Veresov wrote: > Looks good. > > igor > > On Jan 6, 2014, at 2:13 PM, Christian Thalinger wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8029305 >> http://cr.openjdk.java.net/~twisti/8029305 >> >> 8029305: add type tag to AbstractCompiler >> Reviewed-by: >> >> Add a closed set of concrete compiler classes. Using an tag like this avoids a confusing use of macros around the definition of the is_ methods. >> >> As a followup to this change I?m going to replace nmethod::_compiler with a flags field that stores AbstractCompiler::Type values instead: >> >> [#JDK-8031211] replace nmethod::_compiler with a flags field that stores AbstractCompiler::Type values instead >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140106/449da548/attachment.html From vladimir.kozlov at oracle.com Mon Jan 6 14:36:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Jan 2014 14:36:58 -0800 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <52CA6437.3070805@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <526EB414.1030705@oracle.com> <52B28FB4.6030609@oracle.com> <52B5F005.2070209@oracle.com> <52CA6437.3070805@oracle.com> Message-ID: <52CB300A.3020506@oracle.com> Albert, Next comment does not sound correct: ! // These counters are used to assign each compilation an unique ID I think the original was more correct with small correction: ! // These counters are used to assign an unique ID to each compilation And you did not fix it as I asked: >> I suggested to generate compile_id always in such case and convert >> your warning to assert (since it could only happens in debug VM). I suggested next: int CompileBroker::assign_compile_id(methodHandle method, int osr_bci) { #ifdef ASSERT bool is_osr = (osr_bci != standard_entry_bci); int id; if (method->is_native()) { assert(!is_osr, "can't be osr"); // Adapters, native wrappers and method handle intrinsics // should be generated always. return Atomic::add(1, &_compilation_id); } else if (CICountOSR && is_osr) { id = Atomic::add(1, &_osr_compilation_id); if (CIStartOSR <= id && id < CIStopOSR) { return id; } } else { id = Atomic::add(1, &_compilation_id); if (CIStart <= id && id < CIStop) { return id; } } // Method was not in the appropriate compilation range. method->set_not_compilable_quietly(); return 0; #else return Atomic::add(1, &_compilation_id); #endif } The assert should stay in create_native_wrapper() as in your previous version: + const int compile_id = CompileBroker::assign_compile_id(method, CompileBroker::standard_entry_bci); + assert(compile_id > 0, "Must generate native wrapper"); Thanks, Vladimir On 1/6/14 12:07 AM, Albert Noll wrote: > Hi Vladimir, > > thanks for your explanation. I agree with your suggestion. The new > version has the > corresponding check inside > > *CompileBroker::assign_compile_id()* > > >Also why you return only in such case and not for normal native wrappers? > > Thanks for catching this bug. I fixed it in the new version. > > > Here is the link to the new webrev: > http://cr.openjdk.java.net/~anoll/8022494/webrev.05/ > > Best, > Albert > > > On 12/21/2013 08:46 PM, Vladimir Kozlov wrote: >> We have to generate method_handle_intrinsic so we can't simple show >> warning and continue execution - we can't do that. >> I suggested to generate compile_id always in such case and convert >> your warning to assert (since it could only happens in debug VM). >> Also why you return only in such case and not for normal native wrappers? >> >> + if (method->is_method_handle_intrinsic()) { >> + warning("Must generate wrapper for method handle intrinsic"); >> + return; >> + } >> --- >> + assert(!method->is_method_handle_intrinsic()), "Must generate >> wrapper for method handle intrinsic"); >> + return; >> >> Thanks, >> Vladimir >> >> On 12/18/13 10:18 PM, Albert Noll wrote: >>> Christian, Vladimir, thanks for the review. >>> >>> @Christian: Thanks for catching the typo >>> >>> @Vladimir: I am not sure if I understand your suggestion correctly. >>> Could you please clarify what you >>> mean by "The warning above will be assert after that." >>> >>> Best, >>> Albert >>> >>> >>> On 10/28/2013 07:59 PM, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> The warning is not correct solution since we HAVE to generate method >>>> handle intrinsics if your comment is correct: >>>> >>>> + // must be generated for method handle intrinsics (8026407), >>>> print out a warning. >>>> + if (method->is_method_handle_intrinsic()) { >>>> + warning("Must generate wrapper for method handle intrinsic"); >>>> + return; >>>> + } >>>> >>>> I think assign_compile_id() should generate id in such case >>>> regardless CIStart and CIStop values. The warning above >>>> will be assert after that. >>>> >>>> And, please, file RFE (starter task) to cleanup type of compile_id. >>>> In some places it declared as 'int' and in an >>>> other as 'uint'. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/24/13 1:56 AM, Albert Noll wrote: >>>>> Here is the updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>>>> >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> On 24.10.2013 10:21, Albert Noll wrote: >>>>>> Hi Aleksey, >>>>>> >>>>>> thanks for looking at this. >>>>>> >>>>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>>>> Here is the updated webrev: >>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>>> Nice to see the locking gone. >>>>>>> >>>>>>> compileBroker.cpp: >>>>>>> * Is that considered correct that OSR and normal compilations are >>>>>>> marked differently when running in debug mode, but not in release? I >>>>>>> understand the comment before assign_compile_id, so this is more >>>>>>> of the >>>>>>> philosophical question. >>>>>> Compilation IDs are only different if -XX:CICountOSR is set, which is >>>>>> defaulted to false. >>>>>>> sharedRuntime.cpp: >>>>>>> * Why do you need "2653 return;" in the method tail? >>>>>> Thanks for spotting this. I missed it during the cleanup. >>>>>> >>>>>> Best, >>>>>> Albert >>>>>>> Thanks, >>>>>>> -Aleksey. >>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Mon Jan 6 14:40:44 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Jan 2014 14:40:44 -0800 Subject: [9] RFR (S): 8029305: add type tag to AbstractCompiler In-Reply-To: <1C5B59E1-7A77-4F13-9945-CC2D4D309C01@oracle.com> References: <1C5B59E1-7A77-4F13-9945-CC2D4D309C01@oracle.com> Message-ID: <52CB30EC.2070204@oracle.com> Looks good. Thanks, Vlaidmir On 1/6/14 2:13 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8029305 > http://cr.openjdk.java.net/~twisti/8029305 > > 8029305: add type tag to AbstractCompiler > Reviewed-by: > > Add a closed set of concrete compiler classes. Using an tag like this > avoids a confusing use of macros around the definition of the > is_ methods. > > As a followup to this change I?m going to replace nmethod::_compiler > with a flags field that stores AbstractCompiler::Type values instead: > > [#JDK-8031211] replace nmethod::_compiler with a flags field that stores > AbstractCompiler::Type values instead > > From vladimir.kozlov at oracle.com Mon Jan 6 15:13:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Jan 2014 15:13:47 -0800 Subject: RFR(S): 8029873: compiler/uncommontrap/TestStackBangRbp.java crashes with SIGSEGV In-Reply-To: References: Message-ID: <52CB38AB.2000201@oracle.com> Seems reasonable. Thanks, Vladimir On 1/6/14 6:04 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8029873/webrev.00/ > > Class loading from the uncommon trap blob calls java code which may trigger a stack overflow. If the overflow happens right before the java code returns to the runtime, the stack is left unguarded when we return to the uncommon trap blob. The stack banging in the uncommon trap blob can trigger a new stack overflow and because the stack is not guarded we crash. The fix consists in reguarding the stack after the class loading if needed (deoptimization.cpp). > > The test case doesn?t reproduce this problem (I couldn?t get a test case to do it reliably). It triggers another similar problem. A stack overflow can be propagated to a compiled method while the stack is still unguarded. If the compiled method is marked for deoptimization then we go directly go to the deopt blob. If stack banging in the deopt blob triggers a new stack overflow we crash for the same reason as above. The fix is to reguard the stack before we go to the uncommon blob (sharedRuntime.cpp). > > Roland. > From vladimir.kozlov at oracle.com Mon Jan 6 15:14:05 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Jan 2014 15:14:05 -0800 Subject: RFR(XS): 8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a In-Reply-To: <49A0DDDE-9C08-4E27-94AA-D32AD4553101@oracle.com> References: <49A0DDDE-9C08-4E27-94AA-D32AD4553101@oracle.com> Message-ID: <52CB38BD.9040909@oracle.com> Good. Vladimir On 1/6/14 6:27 AM, Roland Westrelin wrote: > C1 generated code encodes a compressed oop into to temp register before it stores it. In case of patching, a GC may happen and the compressed oop may be incorrect when it is stored to memory. > > http://cr.openjdk.java.net/~roland/8028764/webrev.00/ > > Roland. > From albert.noll at oracle.com Mon Jan 6 23:23:04 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 07 Jan 2014 08:23:04 +0100 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <52CB300A.3020506@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <526EB414.1030705@oracle.com> <52B28FB4.6030609@oracle.com> <52B5F005.2070209@oracle.com> <52CA6437.3070805@oracle.com> <52CB300A.3020506@oracle.com> Message-ID: <52CBAB58.8070400@oracle.com> Hi Vladimir, sorry, I misunderstood your suggestion, Now it makes sense. Here is the new webrev that contains your proposed solution. http://cr.openjdk.java.net/~anoll/8022494/webrev.06/ Best, Albert On 01/06/2014 11:36 PM, Vladimir Kozlov wrote: > Albert, > > Next comment does not sound correct: > > ! // These counters are used to assign each compilation an unique ID > > I think the original was more correct with small correction: > > ! // These counters are used to assign an unique ID to each compilation > > > And you did not fix it as I asked: > > >> I suggested to generate compile_id always in such case and convert > >> your warning to assert (since it could only happens in debug VM). > > I suggested next: > > int CompileBroker::assign_compile_id(methodHandle method, int osr_bci) { > #ifdef ASSERT > bool is_osr = (osr_bci != standard_entry_bci); > int id; > if (method->is_native()) { > assert(!is_osr, "can't be osr"); > // Adapters, native wrappers and method handle intrinsics > // should be generated always. > return Atomic::add(1, &_compilation_id); > } else if (CICountOSR && is_osr) { > id = Atomic::add(1, &_osr_compilation_id); > if (CIStartOSR <= id && id < CIStopOSR) { > return id; > } > } else { > id = Atomic::add(1, &_compilation_id); > if (CIStart <= id && id < CIStop) { > return id; > } > } > > // Method was not in the appropriate compilation range. > method->set_not_compilable_quietly(); > return 0; > #else > return Atomic::add(1, &_compilation_id); > #endif > } > > The assert should stay in create_native_wrapper() as in your previous > version: > > + const int compile_id = CompileBroker::assign_compile_id(method, > CompileBroker::standard_entry_bci); > + assert(compile_id > 0, "Must generate native wrapper"); > > Thanks, > Vladimir > > > On 1/6/14 12:07 AM, Albert Noll wrote: >> Hi Vladimir, >> >> thanks for your explanation. I agree with your suggestion. The new >> version has the >> corresponding check inside >> >> *CompileBroker::assign_compile_id()* >> >> >Also why you return only in such case and not for normal native >> wrappers? >> >> Thanks for catching this bug. I fixed it in the new version. >> >> >> Here is the link to the new webrev: >> http://cr.openjdk.java.net/~anoll/8022494/webrev.05/ >> >> Best, >> Albert >> >> >> On 12/21/2013 08:46 PM, Vladimir Kozlov wrote: >>> We have to generate method_handle_intrinsic so we can't simple show >>> warning and continue execution - we can't do that. >>> I suggested to generate compile_id always in such case and convert >>> your warning to assert (since it could only happens in debug VM). >>> Also why you return only in such case and not for normal native >>> wrappers? >>> >>> + if (method->is_method_handle_intrinsic()) { >>> + warning("Must generate wrapper for method handle intrinsic"); >>> + return; >>> + } >>> --- >>> + assert(!method->is_method_handle_intrinsic()), "Must generate >>> wrapper for method handle intrinsic"); >>> + return; >>> >>> Thanks, >>> Vladimir >>> >>> On 12/18/13 10:18 PM, Albert Noll wrote: >>>> Christian, Vladimir, thanks for the review. >>>> >>>> @Christian: Thanks for catching the typo >>>> >>>> @Vladimir: I am not sure if I understand your suggestion correctly. >>>> Could you please clarify what you >>>> mean by "The warning above will be assert after that." >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 10/28/2013 07:59 PM, Vladimir Kozlov wrote: >>>>> Albert, >>>>> >>>>> The warning is not correct solution since we HAVE to generate method >>>>> handle intrinsics if your comment is correct: >>>>> >>>>> + // must be generated for method handle intrinsics (8026407), >>>>> print out a warning. >>>>> + if (method->is_method_handle_intrinsic()) { >>>>> + warning("Must generate wrapper for method handle >>>>> intrinsic"); >>>>> + return; >>>>> + } >>>>> >>>>> I think assign_compile_id() should generate id in such case >>>>> regardless CIStart and CIStop values. The warning above >>>>> will be assert after that. >>>>> >>>>> And, please, file RFE (starter task) to cleanup type of compile_id. >>>>> In some places it declared as 'int' and in an >>>>> other as 'uint'. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/24/13 1:56 AM, Albert Noll wrote: >>>>>> Here is the updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>>>>> >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> On 24.10.2013 10:21, Albert Noll wrote: >>>>>>> Hi Aleksey, >>>>>>> >>>>>>> thanks for looking at this. >>>>>>> >>>>>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>>>>> Here is the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>>>> Nice to see the locking gone. >>>>>>>> >>>>>>>> compileBroker.cpp: >>>>>>>> * Is that considered correct that OSR and normal >>>>>>>> compilations are >>>>>>>> marked differently when running in debug mode, but not in >>>>>>>> release? I >>>>>>>> understand the comment before assign_compile_id, so this is more >>>>>>>> of the >>>>>>>> philosophical question. >>>>>>> Compilation IDs are only different if -XX:CICountOSR is set, >>>>>>> which is >>>>>>> defaulted to false. >>>>>>>> sharedRuntime.cpp: >>>>>>>> * Why do you need "2653 return;" in the method tail? >>>>>>> Thanks for spotting this. I missed it during the cleanup. >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>>> Thanks, >>>>>>>> -Aleksey. >>>>>>> >>>>>> >>>> >> From vladimir.kozlov at oracle.com Tue Jan 7 00:02:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Jan 2014 00:02:24 -0800 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <52CBAB58.8070400@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <526EB414.1030705@oracle.com> <52B28FB4.6030609@oracle.com> <52B5F005.2070209@oracle.com> <52CA6437.3070805@oracle.com> <52CB300A.3020506@oracle.com> <52CBAB58.8070400@oracle.com> Message-ID: <52CBB490.1020400@oracle.com> It is good. Thanks, Vladimir On 1/6/14 11:23 PM, Albert Noll wrote: > Hi Vladimir, > > sorry, I misunderstood your suggestion, Now it makes sense. > Here is the new webrev that contains your proposed solution. > > http://cr.openjdk.java.net/~anoll/8022494/webrev.06/ > > Best, > Albert > > On 01/06/2014 11:36 PM, Vladimir Kozlov wrote: >> Albert, >> >> Next comment does not sound correct: >> >> ! // These counters are used to assign each compilation an unique ID >> >> I think the original was more correct with small correction: >> >> ! // These counters are used to assign an unique ID to each compilation >> >> >> And you did not fix it as I asked: >> >> >> I suggested to generate compile_id always in such case and convert >> >> your warning to assert (since it could only happens in debug VM). >> >> I suggested next: >> >> int CompileBroker::assign_compile_id(methodHandle method, int osr_bci) { >> #ifdef ASSERT >> bool is_osr = (osr_bci != standard_entry_bci); >> int id; >> if (method->is_native()) { >> assert(!is_osr, "can't be osr"); >> // Adapters, native wrappers and method handle intrinsics >> // should be generated always. >> return Atomic::add(1, &_compilation_id); >> } else if (CICountOSR && is_osr) { >> id = Atomic::add(1, &_osr_compilation_id); >> if (CIStartOSR <= id && id < CIStopOSR) { >> return id; >> } >> } else { >> id = Atomic::add(1, &_compilation_id); >> if (CIStart <= id && id < CIStop) { >> return id; >> } >> } >> >> // Method was not in the appropriate compilation range. >> method->set_not_compilable_quietly(); >> return 0; >> #else >> return Atomic::add(1, &_compilation_id); >> #endif >> } >> >> The assert should stay in create_native_wrapper() as in your previous version: >> >> + const int compile_id = CompileBroker::assign_compile_id(method, CompileBroker::standard_entry_bci); >> + assert(compile_id > 0, "Must generate native wrapper"); >> >> Thanks, >> Vladimir >> >> >> On 1/6/14 12:07 AM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks for your explanation. I agree with your suggestion. The new >>> version has the >>> corresponding check inside >>> >>> *CompileBroker::assign_compile_id()* >>> >>> >Also why you return only in such case and not for normal native wrappers? >>> >>> Thanks for catching this bug. I fixed it in the new version. >>> >>> >>> Here is the link to the new webrev: >>> http://cr.openjdk.java.net/~anoll/8022494/webrev.05/ >>> >>> Best, >>> Albert >>> >>> >>> On 12/21/2013 08:46 PM, Vladimir Kozlov wrote: >>>> We have to generate method_handle_intrinsic so we can't simple show >>>> warning and continue execution - we can't do that. >>>> I suggested to generate compile_id always in such case and convert >>>> your warning to assert (since it could only happens in debug VM). >>>> Also why you return only in such case and not for normal native wrappers? >>>> >>>> + if (method->is_method_handle_intrinsic()) { >>>> + warning("Must generate wrapper for method handle intrinsic"); >>>> + return; >>>> + } >>>> --- >>>> + assert(!method->is_method_handle_intrinsic()), "Must generate >>>> wrapper for method handle intrinsic"); >>>> + return; >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/18/13 10:18 PM, Albert Noll wrote: >>>>> Christian, Vladimir, thanks for the review. >>>>> >>>>> @Christian: Thanks for catching the typo >>>>> >>>>> @Vladimir: I am not sure if I understand your suggestion correctly. >>>>> Could you please clarify what you >>>>> mean by "The warning above will be assert after that." >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 10/28/2013 07:59 PM, Vladimir Kozlov wrote: >>>>>> Albert, >>>>>> >>>>>> The warning is not correct solution since we HAVE to generate method >>>>>> handle intrinsics if your comment is correct: >>>>>> >>>>>> + // must be generated for method handle intrinsics (8026407), >>>>>> print out a warning. >>>>>> + if (method->is_method_handle_intrinsic()) { >>>>>> + warning("Must generate wrapper for method handle intrinsic"); >>>>>> + return; >>>>>> + } >>>>>> >>>>>> I think assign_compile_id() should generate id in such case >>>>>> regardless CIStart and CIStop values. The warning above >>>>>> will be assert after that. >>>>>> >>>>>> And, please, file RFE (starter task) to cleanup type of compile_id. >>>>>> In some places it declared as 'int' and in an >>>>>> other as 'uint'. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/24/13 1:56 AM, Albert Noll wrote: >>>>>>> Here is the updated webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>>>>>> >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> On 24.10.2013 10:21, Albert Noll wrote: >>>>>>>> Hi Aleksey, >>>>>>>> >>>>>>>> thanks for looking at this. >>>>>>>> >>>>>>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>>>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>>>>>> Here is the updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>>>>> Nice to see the locking gone. >>>>>>>>> >>>>>>>>> compileBroker.cpp: >>>>>>>>> * Is that considered correct that OSR and normal compilations are >>>>>>>>> marked differently when running in debug mode, but not in release? I >>>>>>>>> understand the comment before assign_compile_id, so this is more >>>>>>>>> of the >>>>>>>>> philosophical question. >>>>>>>> Compilation IDs are only different if -XX:CICountOSR is set, which is >>>>>>>> defaulted to false. >>>>>>>>> sharedRuntime.cpp: >>>>>>>>> * Why do you need "2653 return;" in the method tail? >>>>>>>> Thanks for spotting this. I missed it during the cleanup. >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>>> Thanks, >>>>>>>>> -Aleksey. >>>>>>>> >>>>>>> >>>>> >>> > From albert.noll at oracle.com Tue Jan 7 00:05:26 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 07 Jan 2014 09:05:26 +0100 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <52CBB490.1020400@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <526EB414.1030705@oracle.com> <52B28FB4.6030609@oracle.com> <52B5F005.2070209@oracle.com> <52CA6437.3070805@oracle.com> <52CB300A.3020506@oracle.com> <52CBAB58.8070400@oracle.com> <52CBB490.1020400@oracle.com> Message-ID: <52CBB546.1070307@oracle.com> Thank you, Vladimir. Best, Albert On 01/07/2014 09:02 AM, Vladimir Kozlov wrote: > It is good. > > Thanks, > Vladimir > > On 1/6/14 11:23 PM, Albert Noll wrote: >> Hi Vladimir, >> >> sorry, I misunderstood your suggestion, Now it makes sense. >> Here is the new webrev that contains your proposed solution. >> >> http://cr.openjdk.java.net/~anoll/8022494/webrev.06/ >> >> Best, >> Albert >> >> On 01/06/2014 11:36 PM, Vladimir Kozlov wrote: >>> Albert, >>> >>> Next comment does not sound correct: >>> >>> ! // These counters are used to assign each compilation an unique ID >>> >>> I think the original was more correct with small correction: >>> >>> ! // These counters are used to assign an unique ID to each compilation >>> >>> >>> And you did not fix it as I asked: >>> >>> >> I suggested to generate compile_id always in such case and convert >>> >> your warning to assert (since it could only happens in debug VM). >>> >>> I suggested next: >>> >>> int CompileBroker::assign_compile_id(methodHandle method, int >>> osr_bci) { >>> #ifdef ASSERT >>> bool is_osr = (osr_bci != standard_entry_bci); >>> int id; >>> if (method->is_native()) { >>> assert(!is_osr, "can't be osr"); >>> // Adapters, native wrappers and method handle intrinsics >>> // should be generated always. >>> return Atomic::add(1, &_compilation_id); >>> } else if (CICountOSR && is_osr) { >>> id = Atomic::add(1, &_osr_compilation_id); >>> if (CIStartOSR <= id && id < CIStopOSR) { >>> return id; >>> } >>> } else { >>> id = Atomic::add(1, &_compilation_id); >>> if (CIStart <= id && id < CIStop) { >>> return id; >>> } >>> } >>> >>> // Method was not in the appropriate compilation range. >>> method->set_not_compilable_quietly(); >>> return 0; >>> #else >>> return Atomic::add(1, &_compilation_id); >>> #endif >>> } >>> >>> The assert should stay in create_native_wrapper() as in your >>> previous version: >>> >>> + const int compile_id = >>> CompileBroker::assign_compile_id(method, >>> CompileBroker::standard_entry_bci); >>> + assert(compile_id > 0, "Must generate native wrapper"); >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 1/6/14 12:07 AM, Albert Noll wrote: >>>> Hi Vladimir, >>>> >>>> thanks for your explanation. I agree with your suggestion. The new >>>> version has the >>>> corresponding check inside >>>> >>>> *CompileBroker::assign_compile_id()* >>>> >>>> >Also why you return only in such case and not for normal native >>>> wrappers? >>>> >>>> Thanks for catching this bug. I fixed it in the new version. >>>> >>>> >>>> Here is the link to the new webrev: >>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.05/ >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 12/21/2013 08:46 PM, Vladimir Kozlov wrote: >>>>> We have to generate method_handle_intrinsic so we can't simple show >>>>> warning and continue execution - we can't do that. >>>>> I suggested to generate compile_id always in such case and convert >>>>> your warning to assert (since it could only happens in debug VM). >>>>> Also why you return only in such case and not for normal native >>>>> wrappers? >>>>> >>>>> + if (method->is_method_handle_intrinsic()) { >>>>> + warning("Must generate wrapper for method handle >>>>> intrinsic"); >>>>> + return; >>>>> + } >>>>> --- >>>>> + assert(!method->is_method_handle_intrinsic()), "Must generate >>>>> wrapper for method handle intrinsic"); >>>>> + return; >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/18/13 10:18 PM, Albert Noll wrote: >>>>>> Christian, Vladimir, thanks for the review. >>>>>> >>>>>> @Christian: Thanks for catching the typo >>>>>> >>>>>> @Vladimir: I am not sure if I understand your suggestion correctly. >>>>>> Could you please clarify what you >>>>>> mean by "The warning above will be assert after that." >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> >>>>>> On 10/28/2013 07:59 PM, Vladimir Kozlov wrote: >>>>>>> Albert, >>>>>>> >>>>>>> The warning is not correct solution since we HAVE to generate >>>>>>> method >>>>>>> handle intrinsics if your comment is correct: >>>>>>> >>>>>>> + // must be generated for method handle intrinsics >>>>>>> (8026407), >>>>>>> print out a warning. >>>>>>> + if (method->is_method_handle_intrinsic()) { >>>>>>> + warning("Must generate wrapper for method handle >>>>>>> intrinsic"); >>>>>>> + return; >>>>>>> + } >>>>>>> >>>>>>> I think assign_compile_id() should generate id in such case >>>>>>> regardless CIStart and CIStop values. The warning above >>>>>>> will be assert after that. >>>>>>> >>>>>>> And, please, file RFE (starter task) to cleanup type of compile_id. >>>>>>> In some places it declared as 'int' and in an >>>>>>> other as 'uint'. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/24/13 1:56 AM, Albert Noll wrote: >>>>>>>> Here is the updated webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>>>>>>> >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> On 24.10.2013 10:21, Albert Noll wrote: >>>>>>>>> Hi Aleksey, >>>>>>>>> >>>>>>>>> thanks for looking at this. >>>>>>>>> >>>>>>>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>>>>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>>>>>> Nice to see the locking gone. >>>>>>>>>> >>>>>>>>>> compileBroker.cpp: >>>>>>>>>> * Is that considered correct that OSR and normal >>>>>>>>>> compilations are >>>>>>>>>> marked differently when running in debug mode, but not in >>>>>>>>>> release? I >>>>>>>>>> understand the comment before assign_compile_id, so this is more >>>>>>>>>> of the >>>>>>>>>> philosophical question. >>>>>>>>> Compilation IDs are only different if -XX:CICountOSR is set, >>>>>>>>> which is >>>>>>>>> defaulted to false. >>>>>>>>>> sharedRuntime.cpp: >>>>>>>>>> * Why do you need "2653 return;" in the method tail? >>>>>>>>> Thanks for spotting this. I missed it during the cleanup. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>>> Thanks, >>>>>>>>>> -Aleksey. >>>>>>>>> >>>>>>>> >>>>>> >>>> >> From roland.westrelin at oracle.com Tue Jan 7 02:33:34 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 7 Jan 2014 11:33:34 +0100 Subject: RFR(XS): 8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a In-Reply-To: <49A0DDDE-9C08-4E27-94AA-D32AD4553101@oracle.com> References: <49A0DDDE-9C08-4E27-94AA-D32AD4553101@oracle.com> Message-ID: > C1 generated code encodes a compressed oop into to temp register before it stores it. In case of patching, a GC may happen and the compressed oop may be incorrect when it is stored to memory. > > http://cr.openjdk.java.net/~roland/8028764/webrev.00/ I should have acknowledged that all the credit for this bug (investigation and fix) goes to Mikael Gerdin and Erik Helin from the GC team. Thanks to them! Roland. 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 niclas.adlertz at oracle.com Tue Jan 7 03:20:39 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Tue, 07 Jan 2014 12:20:39 +0100 Subject: RFR(XS) 8029446: assert(_cfg.get_block_for_node(proj) == borig) failed: incorrect block for kill projections In-Reply-To: <52B5FA62.6060901@oracle.com> References: <52B064BB.1060001@oracle.com> <460E82CD-AC6E-49B0-B8A0-AE484D1DD857@oracle.com> <52B1B1BA.3090606@oracle.com> <52B5FA62.6060901@oracle.com> Message-ID: <52CBE307.6080008@oracle.com> Hi Vladimir, Thank you for looking at this. http://cr.openjdk.java.net/~adlertz/JDK-8029446/webrev01/ Kind Regards, Niclas Adlertz On 2013-12-21 21:30, Vladimir Kozlov wrote: > Niclas, > > The code should not be platform specific (ppc64 may have the same > problem). The code should be conditional on if base has (one or > several when node kills flags and regs) projection nodes and to be > similar to code in PhaseChaitin::clone_projs() except cloning. You > also forgot to add new live range for projection node. > > Regards, > Vladimir > > On 12/18/13 6:31 AM, Niclas Adlertz wrote: >> Hi Chris, thank you for taking a look at this. >> >>> Why is it AMD64 only? >> >> From what I can tell by the ad-files; >> >> src/cpu/sparc/vm/sparc.ad >> src/cpu/x86/vm/x86_64.ad >> src/cpu/x86/vm/x86_32.ad >> src/cpu/x86/vm/x86.ad >> >> Only x86_64.ad contains something related to kill projections (the >> RFLAGS register) for the loadConP0: >> instruct loadConP0(rRegP dst, immP0 src, rFlagsReg cr) >> >> Whereas sparc.ad looks like: >> instruct loadConP0(iRegP dst, immP0 src) %{ >> >> and x64.ad and x86_32.ad don't contain any definition of loadConP0. >> >> When running a method generating a loadConP0, on x64 I see: >> >> 9 loadConP0 === 1 [[ 10 2 ]] NULL >> >> 10 MachProj === 9 [[]] #1 >> >> >> But on SPARC I only see: >> >> 9 loadConP0 === 1 [[ 2 ]] NULL >> >> >> >> Do you have another opinion on this? >> >>> Can you please add the investigation to the bug report as well? >>> >>> >> Sure! >> >> Kind Regards, >> Niclas Adlertz >> >> >> On 2013-12-17 19:06, Christian Thalinger wrote: >>> Why is it AMD64 only? Can you please add the investigation to the >>> bug report as well? >>> >>> On Dec 17, 2013, at 6:50 AM, Niclas Adlertz >>> wrote: >>> >>>> Hi all, >>>> >>>> Problem: >>>> In this crash we are trying to re-materialize a loadConP0 node. >>>> When cloning it, we also want to clone its kill >>>> projection node (if any) and we check that the kill projection node >>>> is in the same block as the loadConP0 node. The >>>> problem is that the kill projection node is never added to the >>>> loadConP0 node's block when it is created so we end up >>>> failing the assert. >>>> >>>> Solution: >>>> Add the kill projection node to the same block as the loadConP0 >>>> node during creation. >>>> >>>> Kind Regards, >>>> Niclas Adlertz >>>> >>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8029446 >>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8029446/webrev00/ >>>> >> 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 vladimir.kozlov at oracle.com Tue Jan 7 10:53:41 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Jan 2014 10:53:41 -0800 Subject: RFR(XS) 8029446: assert(_cfg.get_block_for_node(proj) == borig) failed: incorrect block for kill projections In-Reply-To: <52CBE307.6080008@oracle.com> References: <52B064BB.1060001@oracle.com> <460E82CD-AC6E-49B0-B8A0-AE484D1DD857@oracle.com> <52B1B1BA.3090606@oracle.com> <52B5FA62.6060901@oracle.com> <52CBE307.6080008@oracle.com> Message-ID: <52CC4D35.8030508@oracle.com> Looks good. Thanks, Vladimir On 1/7/14 3:20 AM, Niclas Adlertz wrote: > Hi Vladimir, > > Thank you for looking at this. > > http://cr.openjdk.java.net/~adlertz/JDK-8029446/webrev01/ > > Kind Regards, > Niclas Adlertz > > On 2013-12-21 21:30, Vladimir Kozlov wrote: >> Niclas, >> >> The code should not be platform specific (ppc64 may have the same >> problem). The code should be conditional on if base has (one or >> several when node kills flags and regs) projection nodes and to be >> similar to code in PhaseChaitin::clone_projs() except cloning. You >> also forgot to add new live range for projection node. >> >> Regards, >> Vladimir >> >> On 12/18/13 6:31 AM, Niclas Adlertz wrote: >>> Hi Chris, thank you for taking a look at this. >>> >>>> Why is it AMD64 only? >>> >>> From what I can tell by the ad-files; >>> >>> src/cpu/sparc/vm/sparc.ad >>> src/cpu/x86/vm/x86_64.ad >>> src/cpu/x86/vm/x86_32.ad >>> src/cpu/x86/vm/x86.ad >>> >>> Only x86_64.ad contains something related to kill projections (the >>> RFLAGS register) for the loadConP0: >>> instruct loadConP0(rRegP dst, immP0 src, rFlagsReg cr) >>> >>> Whereas sparc.ad looks like: >>> instruct loadConP0(iRegP dst, immP0 src) %{ >>> >>> and x64.ad and x86_32.ad don't contain any definition of loadConP0. >>> >>> When running a method generating a loadConP0, on x64 I see: >>> >>> 9 loadConP0 === 1 [[ 10 2 ]] NULL >>> >>> 10 MachProj === 9 [[]] #1 >>> >>> >>> But on SPARC I only see: >>> >>> 9 loadConP0 === 1 [[ 2 ]] NULL >>> >>> >>> >>> Do you have another opinion on this? >>> >>>> Can you please add the investigation to the bug report as well? >>>> >>>> >>> Sure! >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> >>> On 2013-12-17 19:06, Christian Thalinger wrote: >>>> Why is it AMD64 only? Can you please add the investigation to the >>>> bug report as well? >>>> >>>> On Dec 17, 2013, at 6:50 AM, Niclas Adlertz >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Problem: >>>>> In this crash we are trying to re-materialize a loadConP0 node. >>>>> When cloning it, we also want to clone its kill >>>>> projection node (if any) and we check that the kill projection node >>>>> is in the same block as the loadConP0 node. The >>>>> problem is that the kill projection node is never added to the >>>>> loadConP0 node's block when it is created so we end up >>>>> failing the assert. >>>>> >>>>> Solution: >>>>> Add the kill projection node to the same block as the loadConP0 >>>>> node during creation. >>>>> >>>>> Kind Regards, >>>>> Niclas Adlertz >>>>> >>>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8029446 >>>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8029446/webrev00/ >>>>> >>> > From christian.thalinger at oracle.com Tue Jan 7 15:34:04 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 7 Jan 2014 15:34:04 -0800 Subject: [9] RFR (XXS): 8026413: ScopeDesc::is_equal is declared in header file but not implemented Message-ID: https://bugs.openjdk.java.net/browse/JDK-8026413 http://cr.openjdk.java.net/~twisti/8026413/webrev.00 8026413: ScopeDesc::is_equal is declared in header file but not implemented Reviewed-by: Remove the header declaration. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140107/67425a03/attachment.html From christian.thalinger at oracle.com Tue Jan 7 15:56:28 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 7 Jan 2014 15:56:28 -0800 Subject: Outdated comments in OptoRuntime::uncommon_trap_Type() In-Reply-To: References: Message-ID: <76DA6BD0-B4EB-4180-8858-FB065147E68E@oracle.com> Since you are a Commiter in the jdk9 project you should open a bug yourself and provide a ready-to-push changeset (maybe attach it to the bug). On Jan 6, 2014, at 12:29 PM, Krystal Mok wrote: > Hi all, > > Ping. Would anybody take a look at this trivial issue now that JDK9 repos are open? > > Thanks, > Kris > > > On Fri, Dec 13, 2013 at 11:35 AM, Krystal Mok wrote: > Hi all, > > There's a bit of comment in OptoRuntime::uncommon_trap_Type(): > > // Symbol* name of class to be loaded > fields[TypeFunc::Parms+0] = TypeInt::INT; > > It had been updated from "symbolOop name of class to be loaded", but this earlier version had been outdated for quite some time. The parameter passed into the uncommon trap stub is the "trap_reason", which is an int that combines the DeoptReason and DeoptAction, instead of a symbolOop or Symbol* for the name of class to be loaded. Would anybody fix this trivial thing, please? > > diff -r 8beff993531a src/share/vm/opto/runtime.cpp > --- a/src/share/vm/opto/runtime.cpp Thu Dec 12 18:57:38 2013 -0500 > +++ b/src/share/vm/opto/runtime.cpp Fri Dec 13 11:35:21 2013 -0800 > @@ -568,8 +568,7 @@ > const TypeFunc *OptoRuntime::uncommon_trap_Type() { > // create input type (domain) > const Type **fields = TypeTuple::fields(1); > - // Symbol* name of class to be loaded > - fields[TypeFunc::Parms+0] = TypeInt::INT; > + fields[TypeFunc::Parms+0] = TypeInt::INT; // trap_reason (deopt reason and action) > const TypeTuple *domain = TypeTuple::make(TypeFunc::Parms+1, fields); > > // create result type (range) > > Thanks, > - Kris (OpenJDK ID: kmo) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140107/abd9c9ca/attachment.html From vladimir.kozlov at oracle.com Tue Jan 7 16:05:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Jan 2014 16:05:58 -0800 Subject: [9] RFR (XXS): 8026413: ScopeDesc::is_equal is declared in header file but not implemented In-Reply-To: References: Message-ID: <52CC9666.3020009@oracle.com> Why you want to remove this one only? What about Mikael's change for all unused methods? Does SA have something similar to this method? Thanks, Vladimir On 1/7/14 3:34 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8026413 > http://cr.openjdk.java.net/~twisti/8026413/webrev.00 > > 8026413: ScopeDesc::is_equal is declared in header file but not implemented > Reviewed-by: > > Remove the header declaration. > From rednaxelafx at gmail.com Tue Jan 7 16:28:33 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 7 Jan 2014 16:28:33 -0800 Subject: Outdated comments in OptoRuntime::uncommon_trap_Type() In-Reply-To: <76DA6BD0-B4EB-4180-8858-FB065147E68E@oracle.com> References: <76DA6BD0-B4EB-4180-8858-FB065147E68E@oracle.com> Message-ID: Hi Chris, Thanks for the reply. I thought of doing so, but I couldn't log into the bug system on bugs.openjdk.java.net. I'll try again tonight, and will look for help again if I still can't log in. Cheers, Kris On Tue, Jan 7, 2014 at 3:56 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > Since you are a Commiter in the jdk9 project you should open a bug > yourself and provide a ready-to-push changeset (maybe attach it to the bug). > > On Jan 6, 2014, at 12:29 PM, Krystal Mok wrote: > > Hi all, > > Ping. Would anybody take a look at this trivial issue now that JDK9 repos > are open? > > Thanks, > Kris > > > On Fri, Dec 13, 2013 at 11:35 AM, Krystal Mok wrote: > >> Hi all, >> >> There's a bit of comment in OptoRuntime::uncommon_trap_Type(): >> >> // Symbol* name of class to be loaded >> fields[TypeFunc::Parms+0] = TypeInt::INT; >> >> It had been updated from "symbolOop name of class to be loaded", but this >> earlier version had been outdated for quite some time. The parameter passed >> into the uncommon trap stub is the "trap_reason", which is an int that >> combines the DeoptReason and DeoptAction, instead of a symbolOop or Symbol* >> for the name of class to be loaded. Would anybody fix this trivial thing, >> please? >> >> diff -r 8beff993531a src/share/vm/opto/runtime.cpp >> --- a/src/share/vm/opto/runtime.cpp Thu Dec 12 18:57:38 2013 -0500 >> +++ b/src/share/vm/opto/runtime.cpp Fri Dec 13 11:35:21 2013 -0800 >> @@ -568,8 +568,7 @@ >> const TypeFunc *OptoRuntime::uncommon_trap_Type() { >> // create input type (domain) >> const Type **fields = TypeTuple::fields(1); >> - // Symbol* name of class to be loaded >> - fields[TypeFunc::Parms+0] = TypeInt::INT; >> + fields[TypeFunc::Parms+0] = TypeInt::INT; // trap_reason (deopt reason >> and action) >> const TypeTuple *domain = TypeTuple::make(TypeFunc::Parms+1, fields); >> >> // create result type (range) >> >> Thanks, >> - Kris (OpenJDK ID: kmo) >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140107/ee8dd185/attachment.html 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 rednaxelafx at gmail.com Tue Jan 7 23:13:05 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 8 Jan 2014 15:13:05 +0800 Subject: Outdated comments in OptoRuntime::uncommon_trap_Type() In-Reply-To: References: <76DA6BD0-B4EB-4180-8858-FB065147E68E@oracle.com> Message-ID: Hi all, So, yeah, when I try to log in to bugs.openjdk.java.net, it says my account is inactive. Could someone with an active account help me file a bug and sponsor the change, please? Thanks, Kris On Wed, Jan 8, 2014 at 8:28 AM, Krystal Mok wrote: > Hi Chris, > > Thanks for the reply. I thought of doing so, but I couldn't log into the > bug system on bugs.openjdk.java.net. > I'll try again tonight, and will look for help again if I still can't log > in. > > Cheers, > Kris > > > On Tue, Jan 7, 2014 at 3:56 PM, Christian Thalinger < > christian.thalinger at oracle.com> wrote: > >> Since you are a Commiter in the jdk9 project you should open a bug >> yourself and provide a ready-to-push changeset (maybe attach it to the bug). >> >> On Jan 6, 2014, at 12:29 PM, Krystal Mok wrote: >> >> Hi all, >> >> Ping. Would anybody take a look at this trivial issue now that JDK9 repos >> are open? >> >> Thanks, >> Kris >> >> >> On Fri, Dec 13, 2013 at 11:35 AM, Krystal Mok wrote: >> >>> Hi all, >>> >>> There's a bit of comment in OptoRuntime::uncommon_trap_Type(): >>> >>> // Symbol* name of class to be loaded >>> fields[TypeFunc::Parms+0] = TypeInt::INT; >>> >>> It had been updated from "symbolOop name of class to be loaded", but >>> this earlier version had been outdated for quite some time. The parameter >>> passed into the uncommon trap stub is the "trap_reason", which is an int >>> that combines the DeoptReason and DeoptAction, instead of a symbolOop or >>> Symbol* for the name of class to be loaded. Would anybody fix this trivial >>> thing, please? >>> >>> diff -r 8beff993531a src/share/vm/opto/runtime.cpp >>> --- a/src/share/vm/opto/runtime.cpp Thu Dec 12 18:57:38 2013 -0500 >>> +++ b/src/share/vm/opto/runtime.cpp Fri Dec 13 11:35:21 2013 -0800 >>> @@ -568,8 +568,7 @@ >>> const TypeFunc *OptoRuntime::uncommon_trap_Type() { >>> // create input type (domain) >>> const Type **fields = TypeTuple::fields(1); >>> - // Symbol* name of class to be loaded >>> - fields[TypeFunc::Parms+0] = TypeInt::INT; >>> + fields[TypeFunc::Parms+0] = TypeInt::INT; // trap_reason (deopt >>> reason and action) >>> const TypeTuple *domain = TypeTuple::make(TypeFunc::Parms+1, fields); >>> >>> // create result type (range) >>> >>> Thanks, >>> - Kris (OpenJDK ID: kmo) >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140108/cc54c65d/attachment.html 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 roland.westrelin at oracle.com Wed Jan 8 00:48:36 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 8 Jan 2014 09:48:36 +0100 Subject: RFR(S): 8029873: compiler/uncommontrap/TestStackBangRbp.java crashes with SIGSEGV In-Reply-To: References: Message-ID: <04CB5481-2FD7-4D1A-96F4-1DE864ADC011@oracle.com> Thanks for the reviews, Chris & Vladimir. Roland. From niclas.adlertz at oracle.com Wed Jan 8 02:53:06 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 08 Jan 2014 11:53:06 +0100 Subject: RFR(XS) 8029446: assert(_cfg.get_block_for_node(proj) == borig) failed: incorrect block for kill projections In-Reply-To: <52CC4D35.8030508@oracle.com> References: <52B064BB.1060001@oracle.com> <460E82CD-AC6E-49B0-B8A0-AE484D1DD857@oracle.com> <52B1B1BA.3090606@oracle.com> <52B5FA62.6060901@oracle.com> <52CBE307.6080008@oracle.com> <52CC4D35.8030508@oracle.com> Message-ID: <52CD2E12.30505@oracle.com> Thanks. Kind Regards, Niclas Adlertz On 2014-01-07 19:53, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 1/7/14 3:20 AM, Niclas Adlertz wrote: >> Hi Vladimir, >> >> Thank you for looking at this. >> >> http://cr.openjdk.java.net/~adlertz/JDK-8029446/webrev01/ >> >> Kind Regards, >> Niclas Adlertz >> >> On 2013-12-21 21:30, Vladimir Kozlov wrote: >>> Niclas, >>> >>> The code should not be platform specific (ppc64 may have the same >>> problem). The code should be conditional on if base has (one or >>> several when node kills flags and regs) projection nodes and to be >>> similar to code in PhaseChaitin::clone_projs() except cloning. You >>> also forgot to add new live range for projection node. >>> >>> Regards, >>> Vladimir >>> >>> On 12/18/13 6:31 AM, Niclas Adlertz wrote: >>>> Hi Chris, thank you for taking a look at this. >>>> >>>>> Why is it AMD64 only? >>>> >>>> From what I can tell by the ad-files; >>>> >>>> src/cpu/sparc/vm/sparc.ad >>>> src/cpu/x86/vm/x86_64.ad >>>> src/cpu/x86/vm/x86_32.ad >>>> src/cpu/x86/vm/x86.ad >>>> >>>> Only x86_64.ad contains something related to kill projections (the >>>> RFLAGS register) for the loadConP0: >>>> instruct loadConP0(rRegP dst, immP0 src, rFlagsReg cr) >>>> >>>> Whereas sparc.ad looks like: >>>> instruct loadConP0(iRegP dst, immP0 src) %{ >>>> >>>> and x64.ad and x86_32.ad don't contain any definition of loadConP0. >>>> >>>> When running a method generating a loadConP0, on x64 I see: >>>> >>>> 9 loadConP0 === 1 [[ 10 2 ]] NULL >>>> >>>> 10 MachProj === 9 [[]] #1 >>>> >>>> >>>> But on SPARC I only see: >>>> >>>> 9 loadConP0 === 1 [[ 2 ]] NULL >>>> >>>> >>>> >>>> Do you have another opinion on this? >>>> >>>>> Can you please add the investigation to the bug report as well? >>>>> >>>>> >>>> Sure! >>>> >>>> Kind Regards, >>>> Niclas Adlertz >>>> >>>> >>>> On 2013-12-17 19:06, Christian Thalinger wrote: >>>>> Why is it AMD64 only? Can you please add the investigation to the >>>>> bug report as well? >>>>> >>>>> On Dec 17, 2013, at 6:50 AM, Niclas Adlertz >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Problem: >>>>>> In this crash we are trying to re-materialize a loadConP0 node. >>>>>> When cloning it, we also want to clone its kill >>>>>> projection node (if any) and we check that the kill projection node >>>>>> is in the same block as the loadConP0 node. The >>>>>> problem is that the kill projection node is never added to the >>>>>> loadConP0 node's block when it is created so we end up >>>>>> failing the assert. >>>>>> >>>>>> Solution: >>>>>> Add the kill projection node to the same block as the loadConP0 >>>>>> node during creation. >>>>>> >>>>>> Kind Regards, >>>>>> Niclas Adlertz >>>>>> >>>>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8029446 >>>>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8029446/webrev00/ >>>>>> >>>> >> 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 christian.thalinger at oracle.com Wed Jan 8 11:56:35 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 8 Jan 2014 11:56:35 -0800 Subject: [9] RFR (XXS): 8026413: ScopeDesc::is_equal is declared in header file but not implemented In-Reply-To: <52CC9666.3020009@oracle.com> References: <52CC9666.3020009@oracle.com> Message-ID: <5EA055A9-0F4B-4F51-86AF-48628E851A04@oracle.com> On Jan 7, 2014, at 4:05 PM, Vladimir Kozlov wrote: > Why you want to remove this one only? It was reported to me and I filed a bug to not forget it. Now I?m cleaning up all these bugs. > What about Mikael's change for all unused methods? Not sure if Mikael?s patch includes that one because it?s not an unused method; the method does not exist. > > Does SA have something similar to this method? The SA overrides equals in ScopeDesc but that?s something different in my opinion. > > Thanks, > Vladimir > > On 1/7/14 3:34 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8026413 >> http://cr.openjdk.java.net/~twisti/8026413/webrev.00 >> >> 8026413: ScopeDesc::is_equal is declared in header file but not implemented >> Reviewed-by: >> >> Remove the header declaration. >> From christian.thalinger at oracle.com Wed Jan 8 11:59:16 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 8 Jan 2014 11:59:16 -0800 Subject: Outdated comments in OptoRuntime::uncommon_trap_Type() In-Reply-To: References: <76DA6BD0-B4EB-4180-8858-FB065147E68E@oracle.com> Message-ID: You should contact someone about your account. On Jan 7, 2014, at 11:13 PM, Krystal Mok wrote: > Hi all, > > So, yeah, when I try to log in to bugs.openjdk.java.net, it says my account is inactive. > Could someone with an active account help me file a bug and sponsor the change, please? > > Thanks, > Kris > > > On Wed, Jan 8, 2014 at 8:28 AM, Krystal Mok wrote: > Hi Chris, > > Thanks for the reply. I thought of doing so, but I couldn't log into the bug system on bugs.openjdk.java.net. > I'll try again tonight, and will look for help again if I still can't log in. > > Cheers, > Kris > > > On Tue, Jan 7, 2014 at 3:56 PM, Christian Thalinger wrote: > Since you are a Commiter in the jdk9 project you should open a bug yourself and provide a ready-to-push changeset (maybe attach it to the bug). > > On Jan 6, 2014, at 12:29 PM, Krystal Mok wrote: > >> Hi all, >> >> Ping. Would anybody take a look at this trivial issue now that JDK9 repos are open? >> >> Thanks, >> Kris >> >> >> On Fri, Dec 13, 2013 at 11:35 AM, Krystal Mok wrote: >> Hi all, >> >> There's a bit of comment in OptoRuntime::uncommon_trap_Type(): >> >> // Symbol* name of class to be loaded >> fields[TypeFunc::Parms+0] = TypeInt::INT; >> >> It had been updated from "symbolOop name of class to be loaded", but this earlier version had been outdated for quite some time. The parameter passed into the uncommon trap stub is the "trap_reason", which is an int that combines the DeoptReason and DeoptAction, instead of a symbolOop or Symbol* for the name of class to be loaded. Would anybody fix this trivial thing, please? >> >> diff -r 8beff993531a src/share/vm/opto/runtime.cpp >> --- a/src/share/vm/opto/runtime.cpp Thu Dec 12 18:57:38 2013 -0500 >> +++ b/src/share/vm/opto/runtime.cpp Fri Dec 13 11:35:21 2013 -0800 >> @@ -568,8 +568,7 @@ >> const TypeFunc *OptoRuntime::uncommon_trap_Type() { >> // create input type (domain) >> const Type **fields = TypeTuple::fields(1); >> - // Symbol* name of class to be loaded >> - fields[TypeFunc::Parms+0] = TypeInt::INT; >> + fields[TypeFunc::Parms+0] = TypeInt::INT; // trap_reason (deopt reason and action) >> const TypeTuple *domain = TypeTuple::make(TypeFunc::Parms+1, fields); >> >> // create result type (range) >> >> Thanks, >> - Kris (OpenJDK ID: kmo) >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140108/43e2ffe1/attachment.html From vladimir.kozlov at oracle.com Wed Jan 8 11:58:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 08 Jan 2014 11:58:53 -0800 Subject: [9] RFR (XXS): 8026413: ScopeDesc::is_equal is declared in header file but not implemented In-Reply-To: <5EA055A9-0F4B-4F51-86AF-48628E851A04@oracle.com> References: <52CC9666.3020009@oracle.com> <5EA055A9-0F4B-4F51-86AF-48628E851A04@oracle.com> Message-ID: <52CDADFD.3040900@oracle.com> Okay. Thanks, Vlasimir On 1/8/14 11:56 AM, Christian Thalinger wrote: > > On Jan 7, 2014, at 4:05 PM, Vladimir Kozlov wrote: > >> Why you want to remove this one only? > > It was reported to me and I filed a bug to not forget it. Now I?m cleaning up all these bugs. > >> What about Mikael's change for all unused methods? > > Not sure if Mikael?s patch includes that one because it?s not an unused method; the method does not exist. > >> >> Does SA have something similar to this method? > > The SA overrides equals in ScopeDesc but that?s something different in my opinion. > >> >> Thanks, >> Vladimir >> >> On 1/7/14 3:34 PM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8026413 >>> http://cr.openjdk.java.net/~twisti/8026413/webrev.00 >>> >>> 8026413: ScopeDesc::is_equal is declared in header file but not implemented >>> Reviewed-by: >>> >>> Remove the header declaration. >>> > From christian.thalinger at oracle.com Wed Jan 8 12:34:40 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 8 Jan 2014 12:34:40 -0800 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <52CBAB58.8070400@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <526EB414.1030705@oracle.com> <52B28FB4.6030609@oracle.com> <52B5F005.2070209@oracle.com> <52CA6437.3070805@oracle.com> <52CB300A.3020506@oracle.com> <52CBAB58.8070400@oracle.com> Message-ID: <7D27741E-8AB5-4A2E-AFFD-C1D9F44DADCC@oracle.com> One thing we might want to add a comment for is that in a product build we only increase _compilation_id and not _osr_compilation_id. This is fine because CICountOSR is a develop flag with a default value of false but it is confusing to the reader. + id = Atomic::add(1, &_osr_2compilation_id); Typo. Otherwise this looks good. On Jan 6, 2014, at 11:23 PM, Albert Noll wrote: > Hi Vladimir, > > sorry, I misunderstood your suggestion, Now it makes sense. > Here is the new webrev that contains your proposed solution. > > http://cr.openjdk.java.net/~anoll/8022494/webrev.06/ > > Best, > Albert > > On 01/06/2014 11:36 PM, Vladimir Kozlov wrote: >> Albert, >> >> Next comment does not sound correct: >> >> ! // These counters are used to assign each compilation an unique ID >> >> I think the original was more correct with small correction: >> >> ! // These counters are used to assign an unique ID to each compilation >> >> >> And you did not fix it as I asked: >> >> >> I suggested to generate compile_id always in such case and convert >> >> your warning to assert (since it could only happens in debug VM). >> >> I suggested next: >> >> int CompileBroker::assign_compile_id(methodHandle method, int osr_bci) { >> #ifdef ASSERT >> bool is_osr = (osr_bci != standard_entry_bci); >> int id; >> if (method->is_native()) { >> assert(!is_osr, "can't be osr"); >> // Adapters, native wrappers and method handle intrinsics >> // should be generated always. >> return Atomic::add(1, &_compilation_id); >> } else if (CICountOSR && is_osr) { >> id = Atomic::add(1, &_osr_compilation_id); >> if (CIStartOSR <= id && id < CIStopOSR) { >> return id; >> } >> } else { >> id = Atomic::add(1, &_compilation_id); >> if (CIStart <= id && id < CIStop) { >> return id; >> } >> } >> >> // Method was not in the appropriate compilation range. >> method->set_not_compilable_quietly(); >> return 0; >> #else >> return Atomic::add(1, &_compilation_id); >> #endif >> } >> >> The assert should stay in create_native_wrapper() as in your previous version: >> >> + const int compile_id = CompileBroker::assign_compile_id(method, CompileBroker::standard_entry_bci); >> + assert(compile_id > 0, "Must generate native wrapper"); >> >> Thanks, >> Vladimir >> >> >> On 1/6/14 12:07 AM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks for your explanation. I agree with your suggestion. The new >>> version has the >>> corresponding check inside >>> >>> *CompileBroker::assign_compile_id()* >>> >>> >Also why you return only in such case and not for normal native wrappers? >>> >>> Thanks for catching this bug. I fixed it in the new version. >>> >>> >>> Here is the link to the new webrev: >>> http://cr.openjdk.java.net/~anoll/8022494/webrev.05/ >>> >>> Best, >>> Albert >>> >>> >>> On 12/21/2013 08:46 PM, Vladimir Kozlov wrote: >>>> We have to generate method_handle_intrinsic so we can't simple show >>>> warning and continue execution - we can't do that. >>>> I suggested to generate compile_id always in such case and convert >>>> your warning to assert (since it could only happens in debug VM). >>>> Also why you return only in such case and not for normal native wrappers? >>>> >>>> + if (method->is_method_handle_intrinsic()) { >>>> + warning("Must generate wrapper for method handle intrinsic"); >>>> + return; >>>> + } >>>> --- >>>> + assert(!method->is_method_handle_intrinsic()), "Must generate >>>> wrapper for method handle intrinsic"); >>>> + return; >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/18/13 10:18 PM, Albert Noll wrote: >>>>> Christian, Vladimir, thanks for the review. >>>>> >>>>> @Christian: Thanks for catching the typo >>>>> >>>>> @Vladimir: I am not sure if I understand your suggestion correctly. >>>>> Could you please clarify what you >>>>> mean by "The warning above will be assert after that." >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 10/28/2013 07:59 PM, Vladimir Kozlov wrote: >>>>>> Albert, >>>>>> >>>>>> The warning is not correct solution since we HAVE to generate method >>>>>> handle intrinsics if your comment is correct: >>>>>> >>>>>> + // must be generated for method handle intrinsics (8026407), >>>>>> print out a warning. >>>>>> + if (method->is_method_handle_intrinsic()) { >>>>>> + warning("Must generate wrapper for method handle intrinsic"); >>>>>> + return; >>>>>> + } >>>>>> >>>>>> I think assign_compile_id() should generate id in such case >>>>>> regardless CIStart and CIStop values. The warning above >>>>>> will be assert after that. >>>>>> >>>>>> And, please, file RFE (starter task) to cleanup type of compile_id. >>>>>> In some places it declared as 'int' and in an >>>>>> other as 'uint'. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/24/13 1:56 AM, Albert Noll wrote: >>>>>>> Here is the updated webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>>>>>> >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> On 24.10.2013 10:21, Albert Noll wrote: >>>>>>>> Hi Aleksey, >>>>>>>> >>>>>>>> thanks for looking at this. >>>>>>>> >>>>>>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>>>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>>>>>> Here is the updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>>>>> Nice to see the locking gone. >>>>>>>>> >>>>>>>>> compileBroker.cpp: >>>>>>>>> * Is that considered correct that OSR and normal compilations are >>>>>>>>> marked differently when running in debug mode, but not in release? I >>>>>>>>> understand the comment before assign_compile_id, so this is more >>>>>>>>> of the >>>>>>>>> philosophical question. >>>>>>>> Compilation IDs are only different if -XX:CICountOSR is set, which is >>>>>>>> defaulted to false. >>>>>>>>> sharedRuntime.cpp: >>>>>>>>> * Why do you need "2653 return;" in the method tail? >>>>>>>> Thanks for spotting this. I missed it during the cleanup. >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>>> Thanks, >>>>>>>>> -Aleksey. >>>>>>>> >>>>>>> >>>>> >>> > From roland.westrelin at oracle.com Thu Jan 9 00:35:08 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 9 Jan 2014 09:35:08 +0100 Subject: RFR(M): 8026253: New type profiling points: sparc support Message-ID: <866E3055-184D-48D3-BFE1-5EDAABEC446A@oracle.com> http://cr.openjdk.java.net/~roland/8026253/webrev.00/ The main difference with the x86 code is that on sparc, the current profile value is loaded, checked & updated and finally stored rather than checked & updated in place as is done on x86. As a consequence the code is somewhat simpler because concurrent updates to the profile are not possible. Roland. From marcus.lagergren at oracle.com Thu Jan 9 01:02:39 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 9 Jan 2014 10:02:39 +0100 Subject: GC overhead limit exceeded In-Reply-To: References: <52C7B0FC.4040407@threecrickets.com> <52C811F1.4090202@threecrickets.com> <52C8171D.1000402@threecrickets.com> Message-ID: <26DCB270-10F8-4D74-9FF7-0ED268B18299@oracle.com> This almost certainly stems from the implementation from MethodHandle combinators being implemented as lambda forms as anonymous java classes. One of the things that is being done for 8u20 is to drastically reduce the number of lambda forms created. I don?t know of any workaround at the moment. CC:ing hotspot-compiler-dev, so the people there can elaborate a bit. /M On 06 Jan 2014, at 06:57, Benjamin Sieffert wrote: > Hi everyone, > > we have been observing similar symptoms from 7u40 onwards (using > nashorn-backport with j7 -- j8 has the same problems as 7u40 and 7u45... > 7u25 is the last version that works fine) and suspect the cause to be the > JSR-292 changes that took place there. Iirc I already asked over on their > mailing list. Here's the link: > http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-December/005586.html > The fault might as well lie with nashorn, though. It's certainly worth > investigating. > > Regards > > > 2014/1/4 Tal Liron > >> Thanks! I didn't know of these. I'm not sure how to read the log, but this >> doesn't look so good. I get a lot of "allocation failures" that look like >> this: >> >> Java HotSpot(TM) 64-Bit Server VM (25.0-b63) for linux-amd64 JRE >> (1.8.0-ea-b121), built on Dec 19 2013 17:29:18 by "java_re" with gcc 4.3.0 >> 20080428 (Red Hat 4.3.0-8) >> Memory: 4k page, physical 2039276k(849688k free), swap 262140k(256280k >> free) >> CommandLine flags: -XX:InitialHeapSize=32628416 -XX:MaxHeapSize=522054656 >> -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps >> -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers >> -XX:+UseCompressedOops -XX:+UseParallelGC >> 0.108: [GC (Allocation Failure) >> Desired survivor size 524288 bytes, new threshold 7 (max 15) >> [PSYoungGen: 512K->496K(1024K)] 512K->496K(32256K), 0.0013194 secs] >> [Times: user=0.01 sys=0.00, real=0.00 secs] >> >> >> On 01/04/2014 10:02 PM, Ben Evans wrote: >> >>> -Xloggc: -XX:+PrintGCDetails -XX:+PrintTenuringDistribution >>> >> >> > > > -- > Benjamin Sieffert > metrigo GmbH > Sternstr. 106 > 20357 Hamburg > > Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer > Die Gesellschaft ist eingetragen beim Registergericht Hamburg > Nr. HRB 120447. From albert.noll at oracle.com Thu Jan 9 06:28:54 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 09 Jan 2014 15:28:54 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times Message-ID: <52CEB226.9080307@oracle.com> Hi all, could I get reviews for this patch? bug: https://bugs.openjdk.java.net/browse/JDK-7194669 webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.00/ Problem: The dependency verification code in CodeCache::mark_for_deoptimization walks over all live nmethods in the code cache and checks all dependencies for each nmethod. This leads to checking the same dependency multiple times which can take a huge amount of time. Solution: To avoid checking dependencies more than once, dependencies are abstracted by dependency signatures, which consider (i) the type of a dependency and (ii) the identity hashes of the arguments of a dependency. For each dependency that will be checked, a dependency signature is generated and that dependency signature is compared against a set of already checked dependency signatures. If a dependency has already been checked, the check is skipped. Dependency signatures of a specific type are stored in a binary tree to provide a fast lookup. I.e., each dependency type has its own binary tree. The key to the tree is the identity hash of one argument. More details about the data structure are described as comments in the code. Results: An evaluation of the performance gain shows a 4.3x speedup of dependency checking. More concretely, I used nashorn + octane on a 64-bit Linux Hotspot version. The dependency checking time of the original version is 3888 seconds. The dependency checking time of the optimized version is 902 seconds. Passed jprt. Many thanks in advance, Albert From vitalyd at gmail.com Thu Jan 9 06:49:47 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 9 Jan 2014 09:49:47 -0500 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52CEB226.9080307@oracle.com> References: <52CEB226.9080307@oracle.com> Message-ID: Hi Albert, Just a thought - since you don't care about order of dependencies (just uniqueness) wouldn't a hashing container be more optimal than binary search tree? Thanks Sent from my phone On Jan 9, 2014 9:30 AM, "Albert Noll" wrote: > Hi all, > > could I get reviews for this patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-7194669 > webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.00/ > > Problem: > The dependency verification code in CodeCache::mark_for_deoptimization > walks over all live nmethods in the code cache and checks all dependencies > for each nmethod. This leads to checking the same dependency multiple times > which can take a huge amount of time. > > Solution: > To avoid checking dependencies more than once, dependencies are abstracted > by dependency signatures, which consider (i) the type of a dependency and > (ii) the identity hashes of the arguments > of a dependency. For each dependency that will be checked, a dependency > signature is generated > and that dependency signature is compared against a set of already checked > dependency signatures. > If a dependency has already been checked, the check is skipped. > Dependency signatures of a specific type are stored in a binary tree to > provide a fast lookup. I.e., each > dependency type has its own binary tree. The key to the tree is the > identity hash of one argument. More > details about the data structure are described as comments in the code. > > Results: > An evaluation of the performance gain shows a 4.3x speedup of dependency > checking. More concretely, > I used nashorn + octane on a 64-bit Linux Hotspot version. The dependency > checking time of the > original version is 3888 seconds. The dependency checking time of the > optimized version is 902 seconds. > > Passed jprt. > > > Many thanks in advance, > Albert > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140109/c727217a/attachment.html From albert.noll at oracle.com Thu Jan 9 06:50:01 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 09 Jan 2014 15:50:01 +0100 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <7D27741E-8AB5-4A2E-AFFD-C1D9F44DADCC@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <526EB414.1030705@oracle.com> <52B28FB4.6030609@oracle.com> <52B5F005.2070209@oracle.com> <52CA6437.3070805@oracle.com> <52CB300A.3020506@oracle.com> <52CBAB58.8070400@oracle.com> <7D27741E-8AB5-4A2E-AFFD-C1D9F44DADCC@oracle.com> Message-ID: <52CEB719.1090705@oracle.com> Hi Chris, thanks for looking at this again. I added a comment and fixed the typo. Here is the new webrev: http://cr.openjdk.java.net/~anoll/8022494/webrev.07/ Best, Albert On 01/08/2014 09:34 PM, Christian Thalinger wrote: > One thing we might want to add a comment for is that in a product build we only increase _compilation_id and not _osr_compilation_id. This is fine because CICountOSR is a develop flag with a default value of false but it is confusing to the reader. > > + id = Atomic::add(1, &_osr_2compilation_id); > > Typo. > > Otherwise this looks good. > > On Jan 6, 2014, at 11:23 PM, Albert Noll wrote: > >> Hi Vladimir, >> >> sorry, I misunderstood your suggestion, Now it makes sense. >> Here is the new webrev that contains your proposed solution. >> >> http://cr.openjdk.java.net/~anoll/8022494/webrev.06/ >> >> Best, >> Albert >> >> On 01/06/2014 11:36 PM, Vladimir Kozlov wrote: >>> Albert, >>> >>> Next comment does not sound correct: >>> >>> ! // These counters are used to assign each compilation an unique ID >>> >>> I think the original was more correct with small correction: >>> >>> ! // These counters are used to assign an unique ID to each compilation >>> >>> >>> And you did not fix it as I asked: >>> >>>>> I suggested to generate compile_id always in such case and convert >>>>> your warning to assert (since it could only happens in debug VM). >>> I suggested next: >>> >>> int CompileBroker::assign_compile_id(methodHandle method, int osr_bci) { >>> #ifdef ASSERT >>> bool is_osr = (osr_bci != standard_entry_bci); >>> int id; >>> if (method->is_native()) { >>> assert(!is_osr, "can't be osr"); >>> // Adapters, native wrappers and method handle intrinsics >>> // should be generated always. >>> return Atomic::add(1, &_compilation_id); >>> } else if (CICountOSR && is_osr) { >>> id = Atomic::add(1, &_osr_compilation_id); >>> if (CIStartOSR <= id && id < CIStopOSR) { >>> return id; >>> } >>> } else { >>> id = Atomic::add(1, &_compilation_id); >>> if (CIStart <= id && id < CIStop) { >>> return id; >>> } >>> } >>> >>> // Method was not in the appropriate compilation range. >>> method->set_not_compilable_quietly(); >>> return 0; >>> #else >>> return Atomic::add(1, &_compilation_id); >>> #endif >>> } >>> >>> The assert should stay in create_native_wrapper() as in your previous version: >>> >>> + const int compile_id = CompileBroker::assign_compile_id(method, CompileBroker::standard_entry_bci); >>> + assert(compile_id > 0, "Must generate native wrapper"); >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 1/6/14 12:07 AM, Albert Noll wrote: >>>> Hi Vladimir, >>>> >>>> thanks for your explanation. I agree with your suggestion. The new >>>> version has the >>>> corresponding check inside >>>> >>>> *CompileBroker::assign_compile_id()* >>>> >>>>> Also why you return only in such case and not for normal native wrappers? >>>> Thanks for catching this bug. I fixed it in the new version. >>>> >>>> >>>> Here is the link to the new webrev: >>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.05/ >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 12/21/2013 08:46 PM, Vladimir Kozlov wrote: >>>>> We have to generate method_handle_intrinsic so we can't simple show >>>>> warning and continue execution - we can't do that. >>>>> I suggested to generate compile_id always in such case and convert >>>>> your warning to assert (since it could only happens in debug VM). >>>>> Also why you return only in such case and not for normal native wrappers? >>>>> >>>>> + if (method->is_method_handle_intrinsic()) { >>>>> + warning("Must generate wrapper for method handle intrinsic"); >>>>> + return; >>>>> + } >>>>> --- >>>>> + assert(!method->is_method_handle_intrinsic()), "Must generate >>>>> wrapper for method handle intrinsic"); >>>>> + return; >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/18/13 10:18 PM, Albert Noll wrote: >>>>>> Christian, Vladimir, thanks for the review. >>>>>> >>>>>> @Christian: Thanks for catching the typo >>>>>> >>>>>> @Vladimir: I am not sure if I understand your suggestion correctly. >>>>>> Could you please clarify what you >>>>>> mean by "The warning above will be assert after that." >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> >>>>>> On 10/28/2013 07:59 PM, Vladimir Kozlov wrote: >>>>>>> Albert, >>>>>>> >>>>>>> The warning is not correct solution since we HAVE to generate method >>>>>>> handle intrinsics if your comment is correct: >>>>>>> >>>>>>> + // must be generated for method handle intrinsics (8026407), >>>>>>> print out a warning. >>>>>>> + if (method->is_method_handle_intrinsic()) { >>>>>>> + warning("Must generate wrapper for method handle intrinsic"); >>>>>>> + return; >>>>>>> + } >>>>>>> >>>>>>> I think assign_compile_id() should generate id in such case >>>>>>> regardless CIStart and CIStop values. The warning above >>>>>>> will be assert after that. >>>>>>> >>>>>>> And, please, file RFE (starter task) to cleanup type of compile_id. >>>>>>> In some places it declared as 'int' and in an >>>>>>> other as 'uint'. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/24/13 1:56 AM, Albert Noll wrote: >>>>>>>> Here is the updated webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>>>>>>> >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> On 24.10.2013 10:21, Albert Noll wrote: >>>>>>>>> Hi Aleksey, >>>>>>>>> >>>>>>>>> thanks for looking at this. >>>>>>>>> >>>>>>>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>>>>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>>>>>> Nice to see the locking gone. >>>>>>>>>> >>>>>>>>>> compileBroker.cpp: >>>>>>>>>> * Is that considered correct that OSR and normal compilations are >>>>>>>>>> marked differently when running in debug mode, but not in release? I >>>>>>>>>> understand the comment before assign_compile_id, so this is more >>>>>>>>>> of the >>>>>>>>>> philosophical question. >>>>>>>>> Compilation IDs are only different if -XX:CICountOSR is set, which is >>>>>>>>> defaulted to false. >>>>>>>>>> sharedRuntime.cpp: >>>>>>>>>> * Why do you need "2653 return;" in the method tail? >>>>>>>>> Thanks for spotting this. I missed it during the cleanup. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>>> Thanks, >>>>>>>>>> -Aleksey. From roland.westrelin at oracle.com Thu Jan 9 06:54:30 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 9 Jan 2014 15:54:30 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52CEB226.9080307@oracle.com> References: <52CEB226.9080307@oracle.com> Message-ID: <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> Hi Albert, > Problem: > The dependency verification code in CodeCache::mark_for_deoptimization walks over all live nmethods in the code cache and checks all dependencies for each nmethod. This leads to checking the same dependency multiple times which can take a huge amount of time. Isn?t it only when VerifyDependencies is true on non product build? Why does it matter? Roland. From albert.noll at oracle.com Thu Jan 9 07:08:09 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 09 Jan 2014 16:08:09 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: References: <52CEB226.9080307@oracle.com> Message-ID: <52CEBB59.9010301@oracle.com> Hi Vitaly, you are right, hashing would provide a faster lookup. I have to evaluate if using a hash container provides a speedup over the current version or most of the time is spent checking dependencies. Thanks for looking at this. Best, Albert On 01/09/2014 03:49 PM, Vitaly Davidovich wrote: > > Hi Albert, > > Just a thought - since you don't care about order of dependencies > (just uniqueness) wouldn't a hashing container be more optimal than > binary search tree? > > Thanks > > Sent from my phone > > On Jan 9, 2014 9:30 AM, "Albert Noll" > wrote: > > Hi all, > > could I get reviews for this patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-7194669 > webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.00/ > > > Problem: > The dependency verification code in > CodeCache::mark_for_deoptimization walks over all live nmethods in > the code cache and checks all dependencies for each nmethod. This > leads to checking the same dependency multiple times which can > take a huge amount of time. > > Solution: > To avoid checking dependencies more than once, dependencies are > abstracted by dependency signatures, which consider (i) the type > of a dependency and (ii) the identity hashes of the arguments > of a dependency. For each dependency that will be checked, a > dependency signature is generated > and that dependency signature is compared against a set of already > checked dependency signatures. > If a dependency has already been checked, the check is skipped. > Dependency signatures of a specific type are stored in a binary > tree to provide a fast lookup. I.e., each > dependency type has its own binary tree. The key to the tree is > the identity hash of one argument. More > details about the data structure are described as comments in the > code. > > Results: > An evaluation of the performance gain shows a 4.3x speedup of > dependency checking. More concretely, > I used nashorn + octane on a 64-bit Linux Hotspot version. The > dependency checking time of the > original version is 3888 seconds. The dependency checking time of > the optimized version is 902 seconds. > > Passed jprt. > > > Many thanks in advance, > Albert > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140109/1256b1fa/attachment.html From albert.noll at oracle.com Thu Jan 9 07:21:18 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 09 Jan 2014 16:21:18 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> Message-ID: <52CEBE6E.3030000@oracle.com> Hi Roland, yes, VerifyDependencies is only true in debug builds. This patch should make debug builds execute faster. Best, Albert On 01/09/2014 03:54 PM, Roland Westrelin wrote: > Hi Albert, > >> Problem: >> The dependency verification code in CodeCache::mark_for_deoptimization walks over all live nmethods in the code cache and checks all dependencies for each nmethod. This leads to checking the same dependency multiple times which can take a huge amount of time. > Isn?t it only when VerifyDependencies is true on non product build? Why does it matter? > > Roland. From kirk at kodewerk.com Thu Jan 9 07:29:10 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 9 Jan 2014 16:29:10 +0100 Subject: GC overhead limit exceeded In-Reply-To: <26DCB270-10F8-4D74-9FF7-0ED268B18299@oracle.com> References: <52C7B0FC.4040407@threecrickets.com> <52C811F1.4090202@threecrickets.com> <52C8171D.1000402@threecrickets.com> <26DCB270-10F8-4D74-9FF7-0ED268B18299@oracle.com> Message-ID: Hi Marcus, Looks like some of the details have been chopped off. Is there a GC log available? If there is a problem with MethodHandle a work around might be a simple as expanding perm.. but wait, this is meta space now and it should grow as long as your system has memory to give to the process. The only thing I can suggest is that the space to hold compressed class pointers is a fixed size and that if Nashorn is loading a lot of classes is that you consider making that space larger. Full disclosure, this isn?t something that I?ve had a chance to dabble with but I think there is a flag to control the size of that space. Maybe Colleen can offer better insight. Regards, Kirk On Jan 9, 2014, at 10:02 AM, Marcus Lagergren wrote: > This almost certainly stems from the implementation from MethodHandle combinators being implemented as lambda forms as anonymous java classes. One of the things that is being done for 8u20 is to drastically reduce the number of lambda forms created. I don?t know of any workaround at the moment. CC:ing hotspot-compiler-dev, so the people there can elaborate a bit. > > /M > > On 06 Jan 2014, at 06:57, Benjamin Sieffert wrote: > >> Hi everyone, >> >> we have been observing similar symptoms from 7u40 onwards (using >> nashorn-backport with j7 -- j8 has the same problems as 7u40 and 7u45... >> 7u25 is the last version that works fine) and suspect the cause to be the >> JSR-292 changes that took place there. Iirc I already asked over on their >> mailing list. Here's the link: >> http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-December/005586.html >> The fault might as well lie with nashorn, though. It's certainly worth >> investigating. >> >> Regards >> >> >> 2014/1/4 Tal Liron >> >>> Thanks! I didn't know of these. I'm not sure how to read the log, but this >>> doesn't look so good. I get a lot of "allocation failures" that look like >>> this: >>> >>> Java HotSpot(TM) 64-Bit Server VM (25.0-b63) for linux-amd64 JRE >>> (1.8.0-ea-b121), built on Dec 19 2013 17:29:18 by "java_re" with gcc 4.3.0 >>> 20080428 (Red Hat 4.3.0-8) >>> Memory: 4k page, physical 2039276k(849688k free), swap 262140k(256280k >>> free) >>> CommandLine flags: -XX:InitialHeapSize=32628416 -XX:MaxHeapSize=522054656 >>> -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps >>> -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers >>> -XX:+UseCompressedOops -XX:+UseParallelGC >>> 0.108: [GC (Allocation Failure) >>> Desired survivor size 524288 bytes, new threshold 7 (max 15) >>> [PSYoungGen: 512K->496K(1024K)] 512K->496K(32256K), 0.0013194 secs] >>> [Times: user=0.01 sys=0.00, real=0.00 secs] >>> >>> >>> On 01/04/2014 10:02 PM, Ben Evans wrote: >>> >>>> -Xloggc: -XX:+PrintGCDetails -XX:+PrintTenuringDistribution >>>> >>> >>> >> >> >> -- >> Benjamin Sieffert >> metrigo GmbH >> Sternstr. 106 >> 20357 Hamburg >> >> Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer >> Die Gesellschaft ist eingetragen beim Registergericht Hamburg >> Nr. HRB 120447. > From albert.noll at oracle.com Thu Jan 9 07:54:12 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 09 Jan 2014 16:54:12 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: References: <52CEB226.9080307@oracle.com> Message-ID: <52CEC624.3050900@oracle.com> Hi Vitaly, I have just measured where the version that includes the patch spends most time: It turns out that ~90% of the time is used for checking dependencies. The remaining 10% are spent constructing the dependency signature, performing the lookup, and adding dependency signatures. Best, Albert On 01/09/2014 03:49 PM, Vitaly Davidovich wrote: > > Hi Albert, > > Just a thought - since you don't care about order of dependencies > (just uniqueness) wouldn't a hashing container be more optimal than > binary search tree? > > Thanks > > Sent from my phone > > On Jan 9, 2014 9:30 AM, "Albert Noll" > wrote: > > Hi all, > > could I get reviews for this patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-7194669 > webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.00/ > > > Problem: > The dependency verification code in > CodeCache::mark_for_deoptimization walks over all live nmethods in > the code cache and checks all dependencies for each nmethod. This > leads to checking the same dependency multiple times which can > take a huge amount of time. > > Solution: > To avoid checking dependencies more than once, dependencies are > abstracted by dependency signatures, which consider (i) the type > of a dependency and (ii) the identity hashes of the arguments > of a dependency. For each dependency that will be checked, a > dependency signature is generated > and that dependency signature is compared against a set of already > checked dependency signatures. > If a dependency has already been checked, the check is skipped. > Dependency signatures of a specific type are stored in a binary > tree to provide a fast lookup. I.e., each > dependency type has its own binary tree. The key to the tree is > the identity hash of one argument. More > details about the data structure are described as comments in the > code. > > Results: > An evaluation of the performance gain shows a 4.3x speedup of > dependency checking. More concretely, > I used nashorn + octane on a 64-bit Linux Hotspot version. The > dependency checking time of the > original version is 3888 seconds. The dependency checking time of > the optimized version is 902 seconds. > > Passed jprt. > > > Many thanks in advance, > Albert > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140109/72b55ff1/attachment-0001.html From roland.westrelin at oracle.com Thu Jan 9 07:58:18 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 9 Jan 2014 16:58:18 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52CEBE6E.3030000@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> Message-ID: <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> > yes, VerifyDependencies is only true in debug builds. This patch should make debug builds execute > faster. Does that affect execution in a significant way? Roland. From marcus.lagergren at oracle.com Thu Jan 9 08:00:00 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 9 Jan 2014 17:00:00 +0100 Subject: GC overhead limit exceeded In-Reply-To: References: <52C7B0FC.4040407@threecrickets.com> <52C811F1.4090202@threecrickets.com> <52C8171D.1000402@threecrickets.com> <26DCB270-10F8-4D74-9FF7-0ED268B18299@oracle.com> Message-ID: Tal - The GC people 10 meters behind me want to know if you have a repro of your full GC to death problem that they can look at? They?re interested. /M On 09 Jan 2014, at 16:29, Kirk Pepperdine wrote: > Hi Marcus, > > Looks like some of the details have been chopped off. Is there a GC log available? If there is a problem with MethodHandle a work around might be a simple as expanding perm.. but wait, this is meta space now and it should grow as long as your system has memory to give to the process. The only thing I can suggest is that the space to hold compressed class pointers is a fixed size and that if Nashorn is loading a lot of classes is that you consider making that space larger. Full disclosure, this isn?t something that I?ve had a chance to dabble with but I think there is a flag to control the size of that space. Maybe Colleen can offer better insight. > > Regards, > Kirk > > On Jan 9, 2014, at 10:02 AM, Marcus Lagergren wrote: > >> This almost certainly stems from the implementation from MethodHandle combinators being implemented as lambda forms as anonymous java classes. One of the things that is being done for 8u20 is to drastically reduce the number of lambda forms created. I don?t know of any workaround at the moment. CC:ing hotspot-compiler-dev, so the people there can elaborate a bit. >> >> /M >> >> On 06 Jan 2014, at 06:57, Benjamin Sieffert wrote: >> >>> Hi everyone, >>> >>> we have been observing similar symptoms from 7u40 onwards (using >>> nashorn-backport with j7 -- j8 has the same problems as 7u40 and 7u45... >>> 7u25 is the last version that works fine) and suspect the cause to be the >>> JSR-292 changes that took place there. Iirc I already asked over on their >>> mailing list. Here's the link: >>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-December/005586.html >>> The fault might as well lie with nashorn, though. It's certainly worth >>> investigating. >>> >>> Regards >>> >>> >>> 2014/1/4 Tal Liron >>> >>>> Thanks! I didn't know of these. I'm not sure how to read the log, but this >>>> doesn't look so good. I get a lot of "allocation failures" that look like >>>> this: >>>> >>>> Java HotSpot(TM) 64-Bit Server VM (25.0-b63) for linux-amd64 JRE >>>> (1.8.0-ea-b121), built on Dec 19 2013 17:29:18 by "java_re" with gcc 4.3.0 >>>> 20080428 (Red Hat 4.3.0-8) >>>> Memory: 4k page, physical 2039276k(849688k free), swap 262140k(256280k >>>> free) >>>> CommandLine flags: -XX:InitialHeapSize=32628416 -XX:MaxHeapSize=522054656 >>>> -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps >>>> -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers >>>> -XX:+UseCompressedOops -XX:+UseParallelGC >>>> 0.108: [GC (Allocation Failure) >>>> Desired survivor size 524288 bytes, new threshold 7 (max 15) >>>> [PSYoungGen: 512K->496K(1024K)] 512K->496K(32256K), 0.0013194 secs] >>>> [Times: user=0.01 sys=0.00, real=0.00 secs] >>>> >>>> >>>> On 01/04/2014 10:02 PM, Ben Evans wrote: >>>> >>>>> -Xloggc: -XX:+PrintGCDetails -XX:+PrintTenuringDistribution >>>>> >>>> >>>> >>> >>> >>> -- >>> Benjamin Sieffert >>> metrigo GmbH >>> Sternstr. 106 >>> 20357 Hamburg >>> >>> Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer >>> Die Gesellschaft ist eingetragen beim Registergericht Hamburg >>> Nr. HRB 120447. >> > From igor.ignatyev at oracle.com Thu Jan 9 08:16:51 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 09 Jan 2014 20:16:51 +0400 Subject: RFR(XS) : 8031115 : intrinsics for Math.decrementExact(J) and incrementExact(J) don't work In-Reply-To: <52CAFBFF.8080103@oracle.com> References: <52C90978.2000900@oracle.com> <52CAFBFF.8080103@oracle.com> Message-ID: <52CECB73.50404@oracle.com> Chris, Vladimir, Thanks for the review. Igor From john.coomes at oracle.com Fri Jan 3 12:59:21 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Jan 2014 20:59:21 +0000 Subject: hg: hsx/hotspot-comp/jdk: 41 new changesets Message-ID: <20140103210858.45BCB6237B@hg.openjdk.java.net> Changeset: c8c4aef922ff Author: vadim Date: 2013-12-13 11:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jdk/rev/6ecbfe5e211b Merge Changeset: 9e0e8eed676a Author: pchelko Date: 2013-12-06 17:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/4ee27281d27d Merge Changeset: f8da1f34c65c Author: darcy Date: 2013-12-06 11:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/23b89bd740e9 Merge Changeset: a7ed72627c3f Author: mduigou Date: 2013-12-13 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/c841815be720 Merge Changeset: a2339db970e0 Author: lana Date: 2013-12-19 10:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/71ce5e56ca60 Merge Changeset: 1a3de3cdc684 Author: lana Date: 2013-12-26 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jdk/rev/7e10ee00fe41 Added tag jdk8-b122 for changeset e1499442453b ! .hgtags From tal.liron at threecrickets.com Thu Jan 9 08:21:20 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Fri, 10 Jan 2014 00:21:20 +0800 Subject: GC overhead limit exceeded In-Reply-To: References: <52C7B0FC.4040407@threecrickets.com> <52C811F1.4090202@threecrickets.com> <52C8171D.1000402@threecrickets.com> <26DCB270-10F8-4D74-9FF7-0ED268B18299@oracle.com> Message-ID: <52CECC80.7050509@threecrickets.com> You may download the latest release of Prudence, run it and bombard it with hits (use ab or a similar tool): http://threecrickets.com/prudence/download/ To get the GC logs, start it like so: JVM_SWITCHES=\ -Xloggc:/full/path/to/logs/gc.log \ -XX:+PrintGCDetails \ -XX:+PrintTenuringDistribution \ sincerity start prudence To bombard it: ab -n 50000 -c 10 "http://localhost:8080/prudence-example/" Of course, you may also want to restrict the JVM heap size so it will happen sooner. I think. I actually don't understand JVM 8 GC at all, but you guys do, so have a go. All I can tell you is that I have a server running live on the Internet, which I have to restart every 3 days due to this issue. Unfortunately, I don't have an easy way to isolate the problem to something smaller. However, I would think there's probably an advantage in using something as big as possible -- you can probably get very rich dumps of what is polluting the heap. On 01/10/2014 12:00 AM, Marcus Lagergren wrote: > Tal - The GC people 10 meters behind me want to know if you have a repro of your full GC to death problem that they can look at? They?re interested. > > /M > > On 09 Jan 2014, at 16:29, Kirk Pepperdine wrote: > >> Hi Marcus, >> >> Looks like some of the details have been chopped off. Is there a GC log available? If there is a problem with MethodHandle a work around might be a simple as expanding perm.. but wait, this is meta space now and it should grow as long as your system has memory to give to the process. The only thing I can suggest is that the space to hold compressed class pointers is a fixed size and that if Nashorn is loading a lot of classes is that you consider making that space larger. Full disclosure, this isn?t something that I?ve had a chance to dabble with but I think there is a flag to control the size of that space. Maybe Colleen can offer better insight. >> >> Regards, >> Kirk >> >> On Jan 9, 2014, at 10:02 AM, Marcus Lagergren wrote: >> >>> This almost certainly stems from the implementation from MethodHandle combinators being implemented as lambda forms as anonymous java classes. One of the things that is being done for 8u20 is to drastically reduce the number of lambda forms created. I don?t know of any workaround at the moment. CC:ing hotspot-compiler-dev, so the people there can elaborate a bit. >>> >>> /M >>> >>> On 06 Jan 2014, at 06:57, Benjamin Sieffert wrote: >>> >>>> Hi everyone, >>>> >>>> we have been observing similar symptoms from 7u40 onwards (using >>>> nashorn-backport with j7 -- j8 has the same problems as 7u40 and 7u45... >>>> 7u25 is the last version that works fine) and suspect the cause to be the >>>> JSR-292 changes that took place there. Iirc I already asked over on their >>>> mailing list. Here's the link: >>>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-December/005586.html >>>> The fault might as well lie with nashorn, though. It's certainly worth >>>> investigating. >>>> >>>> Regards >>>> >>>> >>>> 2014/1/4 Tal Liron >>>> >>>>> Thanks! I didn't know of these. I'm not sure how to read the log, but this >>>>> doesn't look so good. I get a lot of "allocation failures" that look like >>>>> this: >>>>> >>>>> Java HotSpot(TM) 64-Bit Server VM (25.0-b63) for linux-amd64 JRE >>>>> (1.8.0-ea-b121), built on Dec 19 2013 17:29:18 by "java_re" with gcc 4.3.0 >>>>> 20080428 (Red Hat 4.3.0-8) >>>>> Memory: 4k page, physical 2039276k(849688k free), swap 262140k(256280k >>>>> free) >>>>> CommandLine flags: -XX:InitialHeapSize=32628416 -XX:MaxHeapSize=522054656 >>>>> -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps >>>>> -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers >>>>> -XX:+UseCompressedOops -XX:+UseParallelGC >>>>> 0.108: [GC (Allocation Failure) >>>>> Desired survivor size 524288 bytes, new threshold 7 (max 15) >>>>> [PSYoungGen: 512K->496K(1024K)] 512K->496K(32256K), 0.0013194 secs] >>>>> [Times: user=0.01 sys=0.00, real=0.00 secs] >>>>> >>>>> >>>>> On 01/04/2014 10:02 PM, Ben Evans wrote: >>>>> >>>>>> -Xloggc: -XX:+PrintGCDetails -XX:+PrintTenuringDistribution >>>>>> >>>>> >>>> >>>> -- >>>> Benjamin Sieffert >>>> metrigo GmbH >>>> Sternstr. 106 >>>> 20357 Hamburg >>>> >>>> Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer >>>> Die Gesellschaft ist eingetragen beim Registergericht Hamburg >>>> Nr. HRB 120447. From vladimir.kozlov at oracle.com Thu Jan 9 09:15:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Jan 2014 09:15:58 -0800 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <52CEB719.1090705@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <526EB414.1030705@oracle.com> <52B28FB4.6030609@oracle.com> <52B5F005.2070209@oracle.com> <52CA6437.3070805@oracle.com> <52CB300A.3020506@oracle.com> <52CBAB58.8070400@oracle.com> <7D27741E-8AB5-4A2E-AFFD-C1D9F44DADCC@oracle.com> <52CEB719.1090705@oracle.com> Message-ID: <52CED94E.10305@oracle.com> Good. Vladimir On 1/9/14 6:50 AM, Albert Noll wrote: > Hi Chris, > > thanks for looking at this again. I added a comment and fixed the typo. > Here is the new webrev: > > http://cr.openjdk.java.net/~anoll/8022494/webrev.07/ > > Best, > Albert > > > On 01/08/2014 09:34 PM, Christian Thalinger wrote: >> One thing we might want to add a comment for is that in a product build we only increase _compilation_id and not >> _osr_compilation_id. This is fine because CICountOSR is a develop flag with a default value of false but it is >> confusing to the reader. >> >> + id = Atomic::add(1, &_osr_2compilation_id); >> >> Typo. >> >> Otherwise this looks good. >> >> On Jan 6, 2014, at 11:23 PM, Albert Noll wrote: >> >>> Hi Vladimir, >>> >>> sorry, I misunderstood your suggestion, Now it makes sense. >>> Here is the new webrev that contains your proposed solution. >>> >>> http://cr.openjdk.java.net/~anoll/8022494/webrev.06/ >>> >>> Best, >>> Albert >>> >>> On 01/06/2014 11:36 PM, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> Next comment does not sound correct: >>>> >>>> ! // These counters are used to assign each compilation an unique ID >>>> >>>> I think the original was more correct with small correction: >>>> >>>> ! // These counters are used to assign an unique ID to each compilation >>>> >>>> >>>> And you did not fix it as I asked: >>>> >>>>>> I suggested to generate compile_id always in such case and convert >>>>>> your warning to assert (since it could only happens in debug VM). >>>> I suggested next: >>>> >>>> int CompileBroker::assign_compile_id(methodHandle method, int osr_bci) { >>>> #ifdef ASSERT >>>> bool is_osr = (osr_bci != standard_entry_bci); >>>> int id; >>>> if (method->is_native()) { >>>> assert(!is_osr, "can't be osr"); >>>> // Adapters, native wrappers and method handle intrinsics >>>> // should be generated always. >>>> return Atomic::add(1, &_compilation_id); >>>> } else if (CICountOSR && is_osr) { >>>> id = Atomic::add(1, &_osr_compilation_id); >>>> if (CIStartOSR <= id && id < CIStopOSR) { >>>> return id; >>>> } >>>> } else { >>>> id = Atomic::add(1, &_compilation_id); >>>> if (CIStart <= id && id < CIStop) { >>>> return id; >>>> } >>>> } >>>> >>>> // Method was not in the appropriate compilation range. >>>> method->set_not_compilable_quietly(); >>>> return 0; >>>> #else >>>> return Atomic::add(1, &_compilation_id); >>>> #endif >>>> } >>>> >>>> The assert should stay in create_native_wrapper() as in your previous version: >>>> >>>> + const int compile_id = CompileBroker::assign_compile_id(method, CompileBroker::standard_entry_bci); >>>> + assert(compile_id > 0, "Must generate native wrapper"); >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 1/6/14 12:07 AM, Albert Noll wrote: >>>>> Hi Vladimir, >>>>> >>>>> thanks for your explanation. I agree with your suggestion. The new >>>>> version has the >>>>> corresponding check inside >>>>> >>>>> *CompileBroker::assign_compile_id()* >>>>> >>>>>> Also why you return only in such case and not for normal native wrappers? >>>>> Thanks for catching this bug. I fixed it in the new version. >>>>> >>>>> >>>>> Here is the link to the new webrev: >>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.05/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 12/21/2013 08:46 PM, Vladimir Kozlov wrote: >>>>>> We have to generate method_handle_intrinsic so we can't simple show >>>>>> warning and continue execution - we can't do that. >>>>>> I suggested to generate compile_id always in such case and convert >>>>>> your warning to assert (since it could only happens in debug VM). >>>>>> Also why you return only in such case and not for normal native wrappers? >>>>>> >>>>>> + if (method->is_method_handle_intrinsic()) { >>>>>> + warning("Must generate wrapper for method handle intrinsic"); >>>>>> + return; >>>>>> + } >>>>>> --- >>>>>> + assert(!method->is_method_handle_intrinsic()), "Must generate >>>>>> wrapper for method handle intrinsic"); >>>>>> + return; >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 12/18/13 10:18 PM, Albert Noll wrote: >>>>>>> Christian, Vladimir, thanks for the review. >>>>>>> >>>>>>> @Christian: Thanks for catching the typo >>>>>>> >>>>>>> @Vladimir: I am not sure if I understand your suggestion correctly. >>>>>>> Could you please clarify what you >>>>>>> mean by "The warning above will be assert after that." >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> >>>>>>> On 10/28/2013 07:59 PM, Vladimir Kozlov wrote: >>>>>>>> Albert, >>>>>>>> >>>>>>>> The warning is not correct solution since we HAVE to generate method >>>>>>>> handle intrinsics if your comment is correct: >>>>>>>> >>>>>>>> + // must be generated for method handle intrinsics (8026407), >>>>>>>> print out a warning. >>>>>>>> + if (method->is_method_handle_intrinsic()) { >>>>>>>> + warning("Must generate wrapper for method handle intrinsic"); >>>>>>>> + return; >>>>>>>> + } >>>>>>>> >>>>>>>> I think assign_compile_id() should generate id in such case >>>>>>>> regardless CIStart and CIStop values. The warning above >>>>>>>> will be assert after that. >>>>>>>> >>>>>>>> And, please, file RFE (starter task) to cleanup type of compile_id. >>>>>>>> In some places it declared as 'int' and in an >>>>>>>> other as 'uint'. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/24/13 1:56 AM, Albert Noll wrote: >>>>>>>>> Here is the updated webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>> On 24.10.2013 10:21, Albert Noll wrote: >>>>>>>>>> Hi Aleksey, >>>>>>>>>> >>>>>>>>>> thanks for looking at this. >>>>>>>>>> >>>>>>>>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>>>>>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>>>>>>> Nice to see the locking gone. >>>>>>>>>>> >>>>>>>>>>> compileBroker.cpp: >>>>>>>>>>> * Is that considered correct that OSR and normal compilations are >>>>>>>>>>> marked differently when running in debug mode, but not in release? I >>>>>>>>>>> understand the comment before assign_compile_id, so this is more >>>>>>>>>>> of the >>>>>>>>>>> philosophical question. >>>>>>>>>> Compilation IDs are only different if -XX:CICountOSR is set, which is >>>>>>>>>> defaulted to false. >>>>>>>>>>> sharedRuntime.cpp: >>>>>>>>>>> * Why do you need "2653 return;" in the method tail? >>>>>>>>>> Thanks for spotting this. I missed it during the cleanup. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>>>>> Thanks, >>>>>>>>>>> -Aleksey. > From vladimir.kozlov at oracle.com Thu Jan 9 09:20:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Jan 2014 09:20:36 -0800 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> Message-ID: <52CEDA64.6060006@oracle.com> Roland, As I recall running some nashorn benchmarks takes about 10X more time when using fastdebug VM if VerifyDependencies is not switched off. Thanks, Vladimir On 1/9/14 7:58 AM, Roland Westrelin wrote: >> yes, VerifyDependencies is only true in debug builds. This patch should make debug builds execute >> faster. > > Does that affect execution in a significant way? > > Roland. > From vitalyd at gmail.com Thu Jan 9 09:45:20 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 9 Jan 2014 12:45:20 -0500 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52CEC624.3050900@oracle.com> References: <52CEB226.9080307@oracle.com> <52CEC624.3050900@oracle.com> Message-ID: Thanks Albert. I guess it doesn't really matter then. Regards Sent from my phone On Jan 9, 2014 10:54 AM, "Albert Noll" wrote: > Hi Vitaly, > > I have just measured where the version that includes the patch spends most > time: > It turns out that ~90% of the time is used for checking dependencies. The > remaining 10% > are spent constructing the dependency signature, performing the lookup, > and adding > dependency signatures. > > Best, > Albert > > > On 01/09/2014 03:49 PM, Vitaly Davidovich wrote: > > Hi Albert, > > Just a thought - since you don't care about order of dependencies (just > uniqueness) wouldn't a hashing container be more optimal than binary search > tree? > > Thanks > > Sent from my phone > On Jan 9, 2014 9:30 AM, "Albert Noll" wrote: > >> Hi all, >> >> could I get reviews for this patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-7194669 >> webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.00/ >> >> Problem: >> The dependency verification code in CodeCache::mark_for_deoptimization >> walks over all live nmethods in the code cache and checks all dependencies >> for each nmethod. This leads to checking the same dependency multiple times >> which can take a huge amount of time. >> >> Solution: >> To avoid checking dependencies more than once, dependencies are >> abstracted by dependency signatures, which consider (i) the type of a >> dependency and (ii) the identity hashes of the arguments >> of a dependency. For each dependency that will be checked, a dependency >> signature is generated >> and that dependency signature is compared against a set of already >> checked dependency signatures. >> If a dependency has already been checked, the check is skipped. >> Dependency signatures of a specific type are stored in a binary tree to >> provide a fast lookup. I.e., each >> dependency type has its own binary tree. The key to the tree is the >> identity hash of one argument. More >> details about the data structure are described as comments in the code. >> >> Results: >> An evaluation of the performance gain shows a 4.3x speedup of dependency >> checking. More concretely, >> I used nashorn + octane on a 64-bit Linux Hotspot version. The dependency >> checking time of the >> original version is 3888 seconds. The dependency checking time of the >> optimized version is 902 seconds. >> >> Passed jprt. >> >> >> Many thanks in advance, >> Albert >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140109/83897bb9/attachment-0001.html From roland.westrelin at oracle.com Thu Jan 9 09:57:49 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 9 Jan 2014 18:57:49 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52CEDA64.6060006@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> Message-ID: <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> > As I recall running some nashorn benchmarks takes about 10X more time when using fastdebug VM if VerifyDependencies is not switched off. Thanks Vladimir. What about simply pushing the dependency signatures to an unsorted growableArray() and doing a linear search? Maybe that?s good enough? Roland. From christian.thalinger at oracle.com Thu Jan 9 10:56:35 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 9 Jan 2014 10:56:35 -0800 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <52CEB719.1090705@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <526EB414.1030705@oracle.com> <52B28FB4.6030609@oracle.com> <52B5F005.2070209@oracle.com> <52CA6437.3070805@oracle.com> <52CB300A.3020506@oracle.com> <52CBAB58.8070400@oracle.com> <7D27741E-8AB5-4A2E-AFFD-C1D9F44DADCC@oracle.com> <52CEB719.1090705@oracle.com> Message-ID: <23CE388F-F8BA-4774-8C80-4C9087DB2795@oracle.com> Looks good. Although I would?ve put the comment here: + #else + return Atomic::add(1, &_compilation_id); + #endif On Jan 9, 2014, at 6:50 AM, Albert Noll wrote: > Hi Chris, > > thanks for looking at this again. I added a comment and fixed the typo. > Here is the new webrev: > > http://cr.openjdk.java.net/~anoll/8022494/webrev.07/ > > Best, > Albert > > > On 01/08/2014 09:34 PM, Christian Thalinger wrote: >> One thing we might want to add a comment for is that in a product build we only increase _compilation_id and not _osr_compilation_id. This is fine because CICountOSR is a develop flag with a default value of false but it is confusing to the reader. >> >> + id = Atomic::add(1, &_osr_2compilation_id); >> >> Typo. >> >> Otherwise this looks good. >> >> On Jan 6, 2014, at 11:23 PM, Albert Noll wrote: >> >>> Hi Vladimir, >>> >>> sorry, I misunderstood your suggestion, Now it makes sense. >>> Here is the new webrev that contains your proposed solution. >>> >>> http://cr.openjdk.java.net/~anoll/8022494/webrev.06/ >>> >>> Best, >>> Albert >>> >>> On 01/06/2014 11:36 PM, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> Next comment does not sound correct: >>>> >>>> ! // These counters are used to assign each compilation an unique ID >>>> >>>> I think the original was more correct with small correction: >>>> >>>> ! // These counters are used to assign an unique ID to each compilation >>>> >>>> >>>> And you did not fix it as I asked: >>>> >>>>>> I suggested to generate compile_id always in such case and convert >>>>>> your warning to assert (since it could only happens in debug VM). >>>> I suggested next: >>>> >>>> int CompileBroker::assign_compile_id(methodHandle method, int osr_bci) { >>>> #ifdef ASSERT >>>> bool is_osr = (osr_bci != standard_entry_bci); >>>> int id; >>>> if (method->is_native()) { >>>> assert(!is_osr, "can't be osr"); >>>> // Adapters, native wrappers and method handle intrinsics >>>> // should be generated always. >>>> return Atomic::add(1, &_compilation_id); >>>> } else if (CICountOSR && is_osr) { >>>> id = Atomic::add(1, &_osr_compilation_id); >>>> if (CIStartOSR <= id && id < CIStopOSR) { >>>> return id; >>>> } >>>> } else { >>>> id = Atomic::add(1, &_compilation_id); >>>> if (CIStart <= id && id < CIStop) { >>>> return id; >>>> } >>>> } >>>> >>>> // Method was not in the appropriate compilation range. >>>> method->set_not_compilable_quietly(); >>>> return 0; >>>> #else >>>> return Atomic::add(1, &_compilation_id); >>>> #endif >>>> } >>>> >>>> The assert should stay in create_native_wrapper() as in your previous version: >>>> >>>> + const int compile_id = CompileBroker::assign_compile_id(method, CompileBroker::standard_entry_bci); >>>> + assert(compile_id > 0, "Must generate native wrapper"); >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 1/6/14 12:07 AM, Albert Noll wrote: >>>>> Hi Vladimir, >>>>> >>>>> thanks for your explanation. I agree with your suggestion. The new >>>>> version has the >>>>> corresponding check inside >>>>> >>>>> *CompileBroker::assign_compile_id()* >>>>> >>>>>> Also why you return only in such case and not for normal native wrappers? >>>>> Thanks for catching this bug. I fixed it in the new version. >>>>> >>>>> >>>>> Here is the link to the new webrev: >>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.05/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 12/21/2013 08:46 PM, Vladimir Kozlov wrote: >>>>>> We have to generate method_handle_intrinsic so we can't simple show >>>>>> warning and continue execution - we can't do that. >>>>>> I suggested to generate compile_id always in such case and convert >>>>>> your warning to assert (since it could only happens in debug VM). >>>>>> Also why you return only in such case and not for normal native wrappers? >>>>>> >>>>>> + if (method->is_method_handle_intrinsic()) { >>>>>> + warning("Must generate wrapper for method handle intrinsic"); >>>>>> + return; >>>>>> + } >>>>>> --- >>>>>> + assert(!method->is_method_handle_intrinsic()), "Must generate >>>>>> wrapper for method handle intrinsic"); >>>>>> + return; >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 12/18/13 10:18 PM, Albert Noll wrote: >>>>>>> Christian, Vladimir, thanks for the review. >>>>>>> >>>>>>> @Christian: Thanks for catching the typo >>>>>>> >>>>>>> @Vladimir: I am not sure if I understand your suggestion correctly. >>>>>>> Could you please clarify what you >>>>>>> mean by "The warning above will be assert after that." >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> >>>>>>> On 10/28/2013 07:59 PM, Vladimir Kozlov wrote: >>>>>>>> Albert, >>>>>>>> >>>>>>>> The warning is not correct solution since we HAVE to generate method >>>>>>>> handle intrinsics if your comment is correct: >>>>>>>> >>>>>>>> + // must be generated for method handle intrinsics (8026407), >>>>>>>> print out a warning. >>>>>>>> + if (method->is_method_handle_intrinsic()) { >>>>>>>> + warning("Must generate wrapper for method handle intrinsic"); >>>>>>>> + return; >>>>>>>> + } >>>>>>>> >>>>>>>> I think assign_compile_id() should generate id in such case >>>>>>>> regardless CIStart and CIStop values. The warning above >>>>>>>> will be assert after that. >>>>>>>> >>>>>>>> And, please, file RFE (starter task) to cleanup type of compile_id. >>>>>>>> In some places it declared as 'int' and in an >>>>>>>> other as 'uint'. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/24/13 1:56 AM, Albert Noll wrote: >>>>>>>>> Here is the updated webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>> On 24.10.2013 10:21, Albert Noll wrote: >>>>>>>>>> Hi Aleksey, >>>>>>>>>> >>>>>>>>>> thanks for looking at this. >>>>>>>>>> >>>>>>>>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>>>>>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>>>>>>> Nice to see the locking gone. >>>>>>>>>>> >>>>>>>>>>> compileBroker.cpp: >>>>>>>>>>> * Is that considered correct that OSR and normal compilations are >>>>>>>>>>> marked differently when running in debug mode, but not in release? I >>>>>>>>>>> understand the comment before assign_compile_id, so this is more >>>>>>>>>>> of the >>>>>>>>>>> philosophical question. >>>>>>>>>> Compilation IDs are only different if -XX:CICountOSR is set, which is >>>>>>>>>> defaulted to false. >>>>>>>>>>> sharedRuntime.cpp: >>>>>>>>>>> * Why do you need "2653 return;" in the method tail? >>>>>>>>>> Thanks for spotting this. I missed it during the cleanup. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>>>>> Thanks, >>>>>>>>>>> -Aleksey. > From christian.thalinger at oracle.com Thu Jan 9 11:08:03 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 9 Jan 2014 11:08:03 -0800 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> Message-ID: <5F44D072-E80E-40CE-9CC0-3D1E99A9B9C2@oracle.com> On Jan 9, 2014, at 7:58 AM, Roland Westrelin wrote: >> yes, VerifyDependencies is only true in debug builds. This patch should make debug builds execute >> faster. > > Does that affect execution in a significant way? Yes, it does. The main problem are tests that take unusually long and it?s not immediately clear why (see: https://bugs.openjdk.java.net/browse/JDK-7194662). > > Roland. From albert.noll at oracle.com Thu Jan 9 11:10:24 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 09 Jan 2014 20:10:24 +0100 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <23CE388F-F8BA-4774-8C80-4C9087DB2795@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <526EB414.1030705@oracle.com> <52B28FB4.6030609@oracle.com> <52B5F005.2070209@oracle.com> <52CA6437.3070805@oracle.com> <52CB300A.3020506@oracle.com> <52CBAB58.8070400@oracle.com> <7D27741E-8AB5-4A2E-AFFD-C1D9F44DADCC@oracle.com> <52CEB719.1090705@oracle.com> <23CE388F-F8BA-4774-8C80-4C9087DB2795@oracle.com> Message-ID: <52CEF420.3020507@oracle.com> Vladimir, Chris, thanks for the reviews. I will move the comment as suggested by Chris and push that version. Best, Albert On 01/09/2014 07:56 PM, Christian Thalinger wrote: > Looks good. Although I would?ve put the comment here: > > + #else > + return Atomic::add(1, &_compilation_id); > + #endif > > On Jan 9, 2014, at 6:50 AM, Albert Noll wrote: > >> Hi Chris, >> >> thanks for looking at this again. I added a comment and fixed the typo. >> Here is the new webrev: >> >> http://cr.openjdk.java.net/~anoll/8022494/webrev.07/ >> >> Best, >> Albert >> >> >> On 01/08/2014 09:34 PM, Christian Thalinger wrote: >>> One thing we might want to add a comment for is that in a product build we only increase _compilation_id and not _osr_compilation_id. This is fine because CICountOSR is a develop flag with a default value of false but it is confusing to the reader. >>> >>> + id = Atomic::add(1, &_osr_2compilation_id); >>> >>> Typo. >>> >>> Otherwise this looks good. >>> >>> On Jan 6, 2014, at 11:23 PM, Albert Noll wrote: >>> >>>> Hi Vladimir, >>>> >>>> sorry, I misunderstood your suggestion, Now it makes sense. >>>> Here is the new webrev that contains your proposed solution. >>>> >>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.06/ >>>> >>>> Best, >>>> Albert >>>> >>>> On 01/06/2014 11:36 PM, Vladimir Kozlov wrote: >>>>> Albert, >>>>> >>>>> Next comment does not sound correct: >>>>> >>>>> ! // These counters are used to assign each compilation an unique ID >>>>> >>>>> I think the original was more correct with small correction: >>>>> >>>>> ! // These counters are used to assign an unique ID to each compilation >>>>> >>>>> >>>>> And you did not fix it as I asked: >>>>> >>>>>>> I suggested to generate compile_id always in such case and convert >>>>>>> your warning to assert (since it could only happens in debug VM). >>>>> I suggested next: >>>>> >>>>> int CompileBroker::assign_compile_id(methodHandle method, int osr_bci) { >>>>> #ifdef ASSERT >>>>> bool is_osr = (osr_bci != standard_entry_bci); >>>>> int id; >>>>> if (method->is_native()) { >>>>> assert(!is_osr, "can't be osr"); >>>>> // Adapters, native wrappers and method handle intrinsics >>>>> // should be generated always. >>>>> return Atomic::add(1, &_compilation_id); >>>>> } else if (CICountOSR && is_osr) { >>>>> id = Atomic::add(1, &_osr_compilation_id); >>>>> if (CIStartOSR <= id && id < CIStopOSR) { >>>>> return id; >>>>> } >>>>> } else { >>>>> id = Atomic::add(1, &_compilation_id); >>>>> if (CIStart <= id && id < CIStop) { >>>>> return id; >>>>> } >>>>> } >>>>> >>>>> // Method was not in the appropriate compilation range. >>>>> method->set_not_compilable_quietly(); >>>>> return 0; >>>>> #else >>>>> return Atomic::add(1, &_compilation_id); >>>>> #endif >>>>> } >>>>> >>>>> The assert should stay in create_native_wrapper() as in your previous version: >>>>> >>>>> + const int compile_id = CompileBroker::assign_compile_id(method, CompileBroker::standard_entry_bci); >>>>> + assert(compile_id > 0, "Must generate native wrapper"); >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 1/6/14 12:07 AM, Albert Noll wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> thanks for your explanation. I agree with your suggestion. The new >>>>>> version has the >>>>>> corresponding check inside >>>>>> >>>>>> *CompileBroker::assign_compile_id()* >>>>>> >>>>>>> Also why you return only in such case and not for normal native wrappers? >>>>>> Thanks for catching this bug. I fixed it in the new version. >>>>>> >>>>>> >>>>>> Here is the link to the new webrev: >>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.05/ >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> >>>>>> On 12/21/2013 08:46 PM, Vladimir Kozlov wrote: >>>>>>> We have to generate method_handle_intrinsic so we can't simple show >>>>>>> warning and continue execution - we can't do that. >>>>>>> I suggested to generate compile_id always in such case and convert >>>>>>> your warning to assert (since it could only happens in debug VM). >>>>>>> Also why you return only in such case and not for normal native wrappers? >>>>>>> >>>>>>> + if (method->is_method_handle_intrinsic()) { >>>>>>> + warning("Must generate wrapper for method handle intrinsic"); >>>>>>> + return; >>>>>>> + } >>>>>>> --- >>>>>>> + assert(!method->is_method_handle_intrinsic()), "Must generate >>>>>>> wrapper for method handle intrinsic"); >>>>>>> + return; >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 12/18/13 10:18 PM, Albert Noll wrote: >>>>>>>> Christian, Vladimir, thanks for the review. >>>>>>>> >>>>>>>> @Christian: Thanks for catching the typo >>>>>>>> >>>>>>>> @Vladimir: I am not sure if I understand your suggestion correctly. >>>>>>>> Could you please clarify what you >>>>>>>> mean by "The warning above will be assert after that." >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> >>>>>>>> On 10/28/2013 07:59 PM, Vladimir Kozlov wrote: >>>>>>>>> Albert, >>>>>>>>> >>>>>>>>> The warning is not correct solution since we HAVE to generate method >>>>>>>>> handle intrinsics if your comment is correct: >>>>>>>>> >>>>>>>>> + // must be generated for method handle intrinsics (8026407), >>>>>>>>> print out a warning. >>>>>>>>> + if (method->is_method_handle_intrinsic()) { >>>>>>>>> + warning("Must generate wrapper for method handle intrinsic"); >>>>>>>>> + return; >>>>>>>>> + } >>>>>>>>> >>>>>>>>> I think assign_compile_id() should generate id in such case >>>>>>>>> regardless CIStart and CIStop values. The warning above >>>>>>>>> will be assert after that. >>>>>>>>> >>>>>>>>> And, please, file RFE (starter task) to cleanup type of compile_id. >>>>>>>>> In some places it declared as 'int' and in an >>>>>>>>> other as 'uint'. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/24/13 1:56 AM, Albert Noll wrote: >>>>>>>>>> Here is the updated webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>>>>> On 24.10.2013 10:21, Albert Noll wrote: >>>>>>>>>>> Hi Aleksey, >>>>>>>>>>> >>>>>>>>>>> thanks for looking at this. >>>>>>>>>>> >>>>>>>>>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>>>>>>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>>>>>>>> Nice to see the locking gone. >>>>>>>>>>>> >>>>>>>>>>>> compileBroker.cpp: >>>>>>>>>>>> * Is that considered correct that OSR and normal compilations are >>>>>>>>>>>> marked differently when running in debug mode, but not in release? I >>>>>>>>>>>> understand the comment before assign_compile_id, so this is more >>>>>>>>>>>> of the >>>>>>>>>>>> philosophical question. >>>>>>>>>>> Compilation IDs are only different if -XX:CICountOSR is set, which is >>>>>>>>>>> defaulted to false. >>>>>>>>>>>> sharedRuntime.cpp: >>>>>>>>>>>> * Why do you need "2653 return;" in the method tail? >>>>>>>>>>> Thanks for spotting this. I missed it during the cleanup. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Albert >>>>>>>>>>>> Thanks, >>>>>>>>>>>> -Aleksey. From christian.thalinger at oracle.com Thu Jan 9 11:13:17 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 9 Jan 2014 11:13:17 -0800 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> Message-ID: <204BF71D-9938-4010-9CEC-8D21BCA56CA1@oracle.com> On Jan 9, 2014, at 9:57 AM, Roland Westrelin wrote: >> As I recall running some nashorn benchmarks takes about 10X more time when using fastdebug VM if VerifyDependencies is not switched off. > > Thanks Vladimir. > What about simply pushing the dependency signatures to an unsorted growableArray() and doing a linear search? Maybe that?s good enough? Although the binary tree implementation is not complicated I would also prefer to reuse an existing data structure. Wouldn?t it be nice if we were using STL? > > Roland. > From christian.thalinger at oracle.com Thu Jan 9 12:36:11 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 9 Jan 2014 12:36:11 -0800 Subject: RFR(M): 8026253: New type profiling points: sparc support In-Reply-To: <866E3055-184D-48D3-BFE1-5EDAABEC446A@oracle.com> References: <866E3055-184D-48D3-BFE1-5EDAABEC446A@oracle.com> Message-ID: src/share/vm/c1/c1_LIRGenerator.cpp: ! ciKlass* exact = profile_type(md, 0, md->byte_offset_of_slot(data, ret->type_offset()), ! ciKlass* exact = profile_type(md, md->byte_offset_of_slot(data, ret->type_offset()), 0, What is this change? src/cpu/sparc/vm/interp_masm_sparc.cpp: + // We're right after the type profile for the last + // argument. tmp is the number of cell left in the + // CallTypeData/VirtualCallTypeData to reach its end. Non null + // if there's a return to profile. + assert(ReturnTypeEntry::static_cell_count() < TypeStackSlotEntries::per_arg_count(), "can't move past ret type"); + sll(tmp1, exact_log2(DataLayout::cell_size), tmp1); + add(ImethodDataPtr, tmp1, ImethodDataPtr); I think ?tmp? is referring to ?tmp1? and ?cell? should be plural, shouldn?t it? Some comments are missing the final ?.?. Also, I didn?t verify the machine instructions in detail but a quick scan didn?t bring up anything obviously wrong. I guess you did some testing. Looks good. On Jan 9, 2014, at 12:35 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8026253/webrev.00/ > > The main difference with the x86 code is that on sparc, the current profile value is loaded, checked & updated and finally stored rather than checked & updated in place as is done on x86. As a consequence the code is somewhat simpler because concurrent updates to the profile are not possible. > > Roland. From dean.long at oracle.com Thu Jan 9 12:58:33 2014 From: dean.long at oracle.com (Dean Long) Date: Thu, 09 Jan 2014 12:58:33 -0800 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52CEB226.9080307@oracle.com> References: <52CEB226.9080307@oracle.com> Message-ID: <52CF0D79.1040401@oracle.com> What if different dependency arguments have the same identity hash? dl On 1/9/2014 6:28 AM, Albert Noll wrote: > Hi all, > > could I get reviews for this patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-7194669 > webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.00/ > > Problem: > The dependency verification code in CodeCache::mark_for_deoptimization > walks over all live nmethods in the code cache and checks all > dependencies for each nmethod. This leads to checking the same > dependency multiple times which can take a huge amount of time. > > Solution: > To avoid checking dependencies more than once, dependencies are > abstracted by dependency signatures, which consider (i) the type of a > dependency and (ii) the identity hashes of the arguments > of a dependency. For each dependency that will be checked, a > dependency signature is generated > and that dependency signature is compared against a set of already > checked dependency signatures. > If a dependency has already been checked, the check is skipped. > Dependency signatures of a specific type are stored in a binary tree > to provide a fast lookup. I.e., each > dependency type has its own binary tree. The key to the tree is the > identity hash of one argument. More > details about the data structure are described as comments in the code. > > Results: > An evaluation of the performance gain shows a 4.3x speedup of > dependency checking. More concretely, > I used nashorn + octane on a 64-bit Linux Hotspot version. The > dependency checking time of the > original version is 3888 seconds. The dependency checking time of the > optimized version is 902 seconds. > > Passed jprt. > > > Many thanks in advance, > Albert From vladimir.kozlov at oracle.com Thu Jan 9 14:23:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Jan 2014 14:23:29 -0800 Subject: RFR(M): 8026253: New type profiling points: sparc support In-Reply-To: <866E3055-184D-48D3-BFE1-5EDAABEC446A@oracle.com> References: <866E3055-184D-48D3-BFE1-5EDAABEC446A@oracle.com> Message-ID: <52CF2161.2030208@oracle.com> Roland, c1_LIRAssembler_sparc.cpp: consider using not short branch instruction because the distance could be big (stop() generates a lot of code): 3135 __ ba_short(next); Otherwise it seems good. Thanks, Vladimir On 1/9/14 12:35 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8026253/webrev.00/ > > The main difference with the x86 code is that on sparc, the current profile value is loaded, checked & updated and finally stored rather than checked & updated in place as is done on x86. As a consequence the code is somewhat simpler because concurrent updates to the profile are not possible. > > Roland. > From vladimir.kozlov at oracle.com Thu Jan 9 14:53:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Jan 2014 14:53:33 -0800 Subject: Tips for diagnosing C2 compile crashes? In-Reply-To: References: <68C2260F6E4C6C4FA24DAD217D6818014A5662EBBA@EXCHANGE2007.kantega.lan> Message-ID: <52CF286D.4090704@oracle.com> I recalled this discussion and since I pushed related changes yesterday I want to comment. Better later than never :) To get the same compilation you need to get the same profiling counters information and inlining. And it is difficult with big programs. An other problem is, even if you can reproduce the problem with product version of VM, there is additional difficulties to reproduce and investigate the problem in debug VM. In JDK8 we added new feature ReplayCompiles. When VM crashes in JIT compiler it dumps replay_pid123.log file which contains information to replay the compilation. And I added inlining information to replay data with my changes for 8028468 yesterday into jdk9 Hotspot and I hope to backport it into one of 8 updates. This should help in situation like this. Note, you need to build debug VM to replay compilation. But it should not be a problem since Hotspot sources are open. http://openjdk.java.net/ Even if you don't have replay compilation tool (jdk7), it is good idea to build fastdebug VM and try to reproduce the problem with it. Debug VM has a lot of asserts which may help. Crash in build_loop_late_post() may happen for a lot of reasons which produce incorrect ideal IR graph and cause the crash. That is why it is so common. Regards, Vladimir On 7/26/13 2:10 AM, Volker Simonis wrote: > On Thu, Jul 25, 2013 at 4:33 PM, J?rgen Austvik > wrote: >> Hi, >> >> we have a problem where C2 SIGSEGVs in PhaseIdealLoop::build_loop_late_post(Node*) seen in 1.7.0_17-b02 and 1.7.0_25-b15 on linux-amd64. When I google sigsegv build_loop_late_post, I see that I am not alone (play framework community seems to be hit with some fascinating cargo cult workarounds). >> >> V [libjvm.so+0x6835b4] PhaseIdealLoop::build_loop_late_post(Node*)+0x154 >> V [libjvm.so+0x683b1c] PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0x13c >> V [libjvm.so+0x68ab07] PhaseIdealLoop::build_and_optimize(bool, bool)+0x7d7 >> V [libjvm.so+0x3b805a] Compile::Optimize()+0xbea >> V [libjvm.so+0x3b8f5c] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool)+0xdac >> V [libjvm.so+0x32ae52] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x142 >> >> It always crashes (on different linux distributions/machines/JVM versions) on the same method (from jetty-util-8.1.8.v20121106.jar): >> >> Current CompileTask: >> C2:687410906 66 % org.eclipse.jetty.util.URIUtil::canonicalPath @ 26 (633 bytes) >> > > The "%" indicates that it is an "OnStackReplacment" compilation > >> Since this was a public static method I naively thought I could reproduce the crash with a simple for-loop, the same JVM on the same host with the same library version - and with -XX:+PrintCompilation I could see that the method was compiled, but it didn't crash. >> >> OK, so maybe the method had to be in its "natural environment" I thought, and started up the server process that uses Jetty, and ran our standard performance test on it. It crashed beautifully with hs_err and core the first time I ran it, so I wanted to see if it could be reproduces. I started again, saw that canonicalPath() was compiled, but it doesn't crash. I have tried to run the load against the server while restarting it every 2 minutes to trigger compilations, and it doesn't crash, so I think the crashes must be depending on how the compilation happens (the statistical information collected could trigger different compilations?). >> > > Is it compiled as OSR again (i.e. does PrintCompilation still report > "%") when it does not crash? > >> Q: Is there any way to trigger different compilations of that method so that I can try to figure out which compilation setting/methods that causes the SIGSEGV? >> > > You could try to play around with the following options: > > product_pd(intx, CompileThreshold, \ > "number of interpreted method invocations before (re-)compiling") \ > \ > product_pd(intx, BackEdgeThreshold, \ > "Interpreter Back edge threshold at which an OSR compilation > is invoked")\ > > For x86 they have the following default values: > > define_pd_global(intx, CompileThreshold, 10000); > define_pd_global(intx, BackEdgeThreshold, 100000); > > Another problem may be that the inlining is different. In the case > where it does not crash you can see what has been inlined with the > dignostic option "-XX:+PrintInlining" option. Unfortunately you won't > see what?s different for the crashing case because it will crash > before it can print that information:) > >> Best Regards >> J?rgen Austvik >> >> -- >> Kantega AS >> Erling Skakkes gt. 25, 7013 Trondheim >> E-post: jorgen.austvik at kantega.no >> Mobil: +47 90 19 78 86 >> Sentralbord: +47 73 80 68 00 >> Fax: +47 73 80 68 01 >> www.kantega.no >> >> >> >> From vladimir.kozlov at oracle.com Thu Jan 9 17:02:12 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Jan 2014 17:02:12 -0800 Subject: RFR(XS) 8029464: assert(ft == ttkp->cast_to_ptr_type(jtkp->ptr()) || ft->isa_narrowoop() In-Reply-To: <52CF208E.4090403@oracle.com> References: <52CF208E.4090403@oracle.com> Message-ID: <52CF4694.8020903@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8029464 http://cr.openjdk.java.net/~kvn/8029464/webrev/ Fix the assert check for narrow klass pointer. Thanks to Roland for finding the cause and suggested fix. Thanks, Vladimir From christian.thalinger at oracle.com Thu Jan 9 17:59:38 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 9 Jan 2014 17:59:38 -0800 Subject: RFR(XS) 8029464: assert(ft == ttkp->cast_to_ptr_type(jtkp->ptr()) || ft->isa_narrowoop() In-Reply-To: <52CF4694.8020903@oracle.com> References: <52CF208E.4090403@oracle.com> <52CF4694.8020903@oracle.com> Message-ID: Looks good. On Jan 9, 2014, at 5:02 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8029464 > http://cr.openjdk.java.net/~kvn/8029464/webrev/ > > Fix the assert check for narrow klass pointer. > > Thanks to Roland for finding the cause and suggested fix. > > Thanks, > Vladimir > From christian.thalinger at oracle.com Thu Jan 9 18:04:38 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 9 Jan 2014 18:04:38 -0800 Subject: [9] RFR (XXS): 8026413: ScopeDesc::is_equal is declared in header file but not implemented In-Reply-To: <52CDADFD.3040900@oracle.com> References: <52CC9666.3020009@oracle.com> <5EA055A9-0F4B-4F51-86AF-48628E851A04@oracle.com> <52CDADFD.3040900@oracle.com> Message-ID: Thanks. On Jan 8, 2014, at 11:58 AM, Vladimir Kozlov wrote: > Okay. > > Thanks, > Vlasimir > > On 1/8/14 11:56 AM, Christian Thalinger wrote: >> >> On Jan 7, 2014, at 4:05 PM, Vladimir Kozlov wrote: >> >>> Why you want to remove this one only? >> >> It was reported to me and I filed a bug to not forget it. Now I?m cleaning up all these bugs. >> >>> What about Mikael's change for all unused methods? >> >> Not sure if Mikael?s patch includes that one because it?s not an unused method; the method does not exist. >> >>> >>> Does SA have something similar to this method? >> >> The SA overrides equals in ScopeDesc but that?s something different in my opinion. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 1/7/14 3:34 PM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8026413 >>>> http://cr.openjdk.java.net/~twisti/8026413/webrev.00 >>>> >>>> 8026413: ScopeDesc::is_equal is declared in header file but not implemented >>>> Reviewed-by: >>>> >>>> Remove the header declaration. >>>> >> From vladimir.kozlov at oracle.com Thu Jan 9 19:01:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Jan 2014 19:01:06 -0800 Subject: RFR(XS) 8029464: assert(ft == ttkp->cast_to_ptr_type(jtkp->ptr()) || ft->isa_narrowoop() In-Reply-To: References: <52CF208E.4090403@oracle.com> <52CF4694.8020903@oracle.com> Message-ID: <52CF6272.2060003@oracle.com> Thank you, Christian Vladimir On 1/9/14 5:59 PM, Christian Thalinger wrote: > Looks good. > > On Jan 9, 2014, at 5:02 PM, Vladimir Kozlov wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8029464 >> http://cr.openjdk.java.net/~kvn/8029464/webrev/ >> >> Fix the assert check for narrow klass pointer. >> >> Thanks to Roland for finding the cause and suggested fix. >> >> Thanks, >> Vladimir >> > From andrew_nuss at yahoo.com Thu Jan 9 20:39:19 2014 From: andrew_nuss at yahoo.com (Andy Nuss) Date: Thu, 9 Jan 2014 20:39:19 -0800 (PST) Subject: sneaky throwing Message-ID: <1389328759.63714.YahooMailNeo@web141103.mail.bf1.yahoo.com> Hi, I had a lot of reasons to sneaky throw exceptions just as they are but without having the function that throws them declare the exception.? This saves me alot of trouble, especially with reflective errors that I know shouldn't ever happen. To do this, I declared an interface that throws Throwable and the throwing function taking a single argument, the Throwable, and just providing a simple implementation for it.? Compiled to a .class and saved the byte code file as a small hex string.? Meanwhile, I declared another version of the interface that is identical in every way except that it does not declare that its throwing function throws Throwable.? I then use the saved bytecodes as the implementation for this interface, and use a singleton to provide the public static function.? Apparently, at the bytecode level, this is ok. This has worked nicely all the way from JDK4 to JDK7.? Will it work with JDK8?? For example, lets say I have a tomcat servlet which throws 2 kinds of declared exceptions.? But I in fact sneaky throw many others during development.? This is ok right now. Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140109/8a45b6d0/attachment.html From christian.thalinger at oracle.com Thu Jan 9 21:03:08 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 9 Jan 2014 21:03:08 -0800 Subject: sneaky throwing In-Reply-To: <1389328759.63714.YahooMailNeo@web141103.mail.bf1.yahoo.com> References: <1389328759.63714.YahooMailNeo@web141103.mail.bf1.yahoo.com> Message-ID: <0C1C8E86-5DD8-4C6D-A6CC-AEE114973646@oracle.com> On Jan 9, 2014, at 8:39 PM, Andy Nuss wrote: > Hi, > > I had a lot of reasons to sneaky throw exceptions just as they are but without having the function that throws them declare the exception. This saves me alot of trouble, especially with reflective errors that I know shouldn't ever happen. > > To do this, I declared an interface that throws Throwable and the throwing function taking a single argument, the Throwable, and just providing a simple implementation for it. Compiled to a .class and saved the byte code file as a small hex string. Meanwhile, I declared another version of the interface that is identical in every way except that it does not declare that its throwing function throws Throwable. I then use the saved bytecodes as the implementation for this interface, and use a singleton to provide the public static function. Apparently, at the bytecode level, this is ok. > > This has worked nicely all the way from JDK4 to JDK7. Will it work with JDK8? For example, lets say I have a tomcat servlet which throws 2 kinds of declared exceptions. But I in fact sneaky throw many others during development. This is ok right now. (I think) this is the wrong mailing list. I?m not exactly sure which list to suggest because I?m having a hard time to parse the message for the question. Can you rephrase the question and be more precise? > > Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140109/9ab9dd87/attachment.html From uschindler at apache.org Fri Jan 10 00:18:22 2014 From: uschindler at apache.org (Uwe Schindler) Date: Fri, 10 Jan 2014 09:18:22 +0100 Subject: sneaky throwing In-Reply-To: <1389328759.63714.YahooMailNeo@web141103.mail.bf1.yahoo.com> References: <1389328759.63714.YahooMailNeo@web141103.mail.bf1.yahoo.com> Message-ID: <01a901cf0ddc$86e5d850$94b188f0$@apache.org> Hi Andy, This is indeed the wrong mailing list! Maybe I help to answer your question: There are several ways to ?sneaky throw? checked Exceptions, but your approach looks very complicated. In fact, the JVM does not check ?throws? clauses at runtime. It does not matter to the JVM if it is a checked or RuntimException/Error whatever (see also Java Language Spec). The ?throws? clause is just a hint for the compiler, so it can complain if an Exception is not correctly catched. Your approach seems to also use this, but does use some precompiled interface classes in two different versions to make compiler happy. Two easy ways to throw checked Exceptions without declaring them are: - The way that simply tricks out the compiler is: http://fossies.org/linux/www/lucene-4.6.0-src.tgz:a/lucene-4.6.0/test-framework/src/java/org/apache/lucene/util/Rethrow.java or http://java.dzone.com/articles/throw-checked-exceptions (these tricks use generics to declare Exceptions - which are lost when the Java compiler erasures the generic type). Please note, this approach is not a bug in the compiler and works with every JVM 1.5+! The first code part is taken from a book from Joshua Bloch: http://www.javapuzzlers.com ! - Thread.currentThread().stop(exception); // this is the ?oldest way? and works since early beginning, but completely misuses already deprecated methods. It also depends on native methods, that are per my description above not needed. So don?t use!!! The first Lucene/JavaPuzzlers-based approach works definitely also with Java 8 (why should it not, its all according to language specs?). We are running that in our test cases day-by-day with Java 8. The second approach is risky and may no longer work with later JVMs. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Chair / Committer Bremen, Germany http://lucene.apache.org/ From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Andy Nuss Sent: Friday, January 10, 2014 5:39 AM To: hotspot Subject: sneaky throwing Hi, I had a lot of reasons to sneaky throw exceptions just as they are but without having the function that throws them declare the exception. This saves me alot of trouble, especially with reflective errors that I know shouldn't ever happen. To do this, I declared an interface that throws Throwable and the throwing function taking a single argument, the Throwable, and just providing a simple implementation for it. Compiled to a .class and saved the byte code file as a small hex string. Meanwhile, I declared another version of the interface that is identical in every way except that it does not declare that its throwing function throws Throwable. I then use the saved bytecodes as the implementation for this interface, and use a singleton to provide the public static function. Apparently, at the bytecode level, this is ok. This has worked nicely all the way from JDK4 to JDK7. Will it work with JDK8? For example, lets say I have a tomcat servlet which throws 2 kinds of declared exceptions. But I in fact sneaky throw many others during development. This is ok right now. Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140110/6ecf013c/attachment-0001.html From aleksey.shipilev at oracle.com Fri Jan 10 00:23:32 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 10 Jan 2014 12:23:32 +0400 Subject: -XX:+UseOldInlining Message-ID: <52CFAE04.9000309@oracle.com> Hi, Does anyone remember the story behind -XX:+UseOldInlining? I have googled, wandered through HotSpot code, searched through JIRA, grepped through Mercurial to no avail. The history on this predates OpenJDK. In seems we have it unconditionally turned on. It makes the inlining policy a little less understandable to have additional branch here and there. Should we purge this option from the VM codebase? If so, I can prepare the proper revision of this scratch change: http://cr.openjdk.java.net/~shade/scratch/purge-old-inlining.patch Thanks, -Aleksey. From roland.westrelin at oracle.com Fri Jan 10 01:46:54 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 10 Jan 2014 10:46:54 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <528BC0BF.8070803@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> Message-ID: Hi Vladimir, Here is a new webrev for this: http://cr.openjdk.java.net/~roland/8027422/webrev.01/ I fixed the issues you mentioned in your review. I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). I also added a verification method: NodeHash::check_speculative_types() to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() Roland. On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: > On 11/19/13 11:45 AM, Roland Westrelin wrote: >> Thanks for reviewing this, Vladimir. >> >> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >> >>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>> >>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>> >>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>> >>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >> >> You?re right. It probably should. >> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? > > Right, passing 'true' will work in all cases then. > > Thanks, > Vladimir > >> >>> Could you make printing code with 'this_t' aligned again in Type::meet()? >> >> Sure. >> >> Roland. >> >>> >>> thanks, >>> Vladimir >>> >>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>> higher_equal() >>>> meet() >>>> join() >>>> filter() >>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>> >>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>> >>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>> >>>> Roland. >>>> >> From mikael.gerdin at oracle.com Fri Jan 10 04:03:40 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 10 Jan 2014 13:03:40 +0100 Subject: -XX:+UseOldInlining In-Reply-To: <52CFAE04.9000309@oracle.com> References: <52CFAE04.9000309@oracle.com> Message-ID: <15619902.8MtnO6Lifq@mgerdin03> On Friday 10 January 2014 12.23.32 Aleksey Shipilev wrote: > Hi, > > Does anyone remember the story behind -XX:+UseOldInlining? I have > googled, wandered through HotSpot code, searched through JIRA, grepped > through Mercurial to no avail. The history on this predates OpenJDK. If, in the future, you want to dig around in the prehistoric source management system, check out OpenGrok: http://opengrok.ie.oracle.com:8080/opengrok/search?q=UseOldInlining&project=jdk7b23_sccs&defs=&refs=&path=&hist= /Mikael > > In seems we have it unconditionally turned on. It makes the inlining > policy a little less understandable to have additional branch here and > there. Should we purge this option from the VM codebase? If so, I can > prepare the proper revision of this scratch change: > http://cr.openjdk.java.net/~shade/scratch/purge-old-inlining.patch > > Thanks, > -Aleksey. From mikael.gerdin at oracle.com Fri Jan 10 04:15:57 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 10 Jan 2014 13:15:57 +0100 Subject: -XX:+UseOldInlining In-Reply-To: <15619902.8MtnO6Lifq@mgerdin03> References: <52CFAE04.9000309@oracle.com> <15619902.8MtnO6Lifq@mgerdin03> Message-ID: <1554613.Ts12lamzx3@mgerdin03> On Friday 10 January 2014 13.03.40 Mikael Gerdin wrote: > On Friday 10 January 2014 12.23.32 Aleksey Shipilev wrote: > > Hi, > > > > Does anyone remember the story behind -XX:+UseOldInlining? I have > > googled, wandered through HotSpot code, searched through JIRA, grepped > > through Mercurial to no avail. The history on this predates OpenJDK. > > If, in the future, you want to dig around in the prehistoric source > management system, check out OpenGrok: > http://opengrok.ie.oracle.com:8080/opengrok/search?q=UseOldInlining&project= > jdk7b23_sccs&defs=&refs=&path=&hist= Sorry, that's an internal url :( > > /Mikael > > > In seems we have it unconditionally turned on. It makes the inlining > > policy a little less understandable to have additional branch here and > > there. Should we purge this option from the VM codebase? If so, I can > > > > prepare the proper revision of this scratch change: > > http://cr.openjdk.java.net/~shade/scratch/purge-old-inlining.patch > > > > Thanks, > > -Aleksey. From kirk at kodewerk.com Fri Jan 10 04:31:29 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 10 Jan 2014 13:31:29 +0100 Subject: -XX:+UseOldInlining In-Reply-To: <1554613.Ts12lamzx3@mgerdin03> References: <52CFAE04.9000309@oracle.com> <15619902.8MtnO6Lifq@mgerdin03> <1554613.Ts12lamzx3@mgerdin03> Message-ID: <0997ED89-BC64-44F4-BD8C-018732E9F1C2@kodewerk.com> Is it possible to externalize the information? Regards, Kirk On Jan 10, 2014, at 1:15 PM, Mikael Gerdin wrote: > On Friday 10 January 2014 13.03.40 Mikael Gerdin wrote: >> On Friday 10 January 2014 12.23.32 Aleksey Shipilev wrote: >>> Hi, >>> >>> Does anyone remember the story behind -XX:+UseOldInlining? I have >>> googled, wandered through HotSpot code, searched through JIRA, grepped >>> through Mercurial to no avail. The history on this predates OpenJDK. >> >> If, in the future, you want to dig around in the prehistoric source >> management system, check out OpenGrok: >> http://opengrok.ie.oracle.com:8080/opengrok/search?q=UseOldInlining&project= >> jdk7b23_sccs&defs=&refs=&path=&hist= > > Sorry, that's an internal url :( > >> >> /Mikael >> >>> In seems we have it unconditionally turned on. It makes the inlining >>> policy a little less understandable to have additional branch here and >>> there. Should we purge this option from the VM codebase? If so, I can >>> >>> prepare the proper revision of this scratch change: >>> http://cr.openjdk.java.net/~shade/scratch/purge-old-inlining.patch >>> >>> Thanks, >>> -Aleksey. > From roland.westrelin at oracle.com Fri Jan 10 04:44:32 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 10 Jan 2014 13:44:32 +0100 Subject: RFR(M): 8026253: New type profiling points: sparc support In-Reply-To: <52CF2161.2030208@oracle.com> References: <866E3055-184D-48D3-BFE1-5EDAABEC446A@oracle.com> <52CF2161.2030208@oracle.com> Message-ID: Hi Vladimir, Thanks for reviewing this. > c1_LIRAssembler_sparc.cpp: consider using not short branch instruction because the distance could be big (stop() generates a lot of code): > > 3135 __ ba_short(next); I did a specjvm98 run on a T4 with VerifyOops on and the code as it is runs fine. The interpreter code is ok unless TypeProfileArgsLimit is set to something unreasonable (10). The ba_short that you mention above is the most likely to cause problem on the compiler side. I could convert it to a non short branch just to be safe. What do you think? Roland. > Otherwise it seems good. > > Thanks, > Vladimir > > On 1/9/14 12:35 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8026253/webrev.00/ >> >> The main difference with the x86 code is that on sparc, the current profile value is loaded, checked & updated and finally stored rather than checked & updated in place as is done on x86. As a consequence the code is somewhat simpler because concurrent updates to the profile are not possible. >> >> Roland. >> From roland.westrelin at oracle.com Fri Jan 10 04:59:59 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 10 Jan 2014 13:59:59 +0100 Subject: RFR(M): 8026253: New type profiling points: sparc support In-Reply-To: References: <866E3055-184D-48D3-BFE1-5EDAABEC446A@oracle.com> Message-ID: <5DDD1B93-D92C-41E5-9D37-CEAEA0D436B4@oracle.com> Thanks for reviewing this, Chris. > src/share/vm/c1/c1_LIRGenerator.cpp: > > ! ciKlass* exact = profile_type(md, 0, md->byte_offset_of_slot(data, ret->type_offset()), > ! ciKlass* exact = profile_type(md, md->byte_offset_of_slot(data, ret->type_offset()), 0, > > What is this change? The 2nd argument to profile_type is the offset within the MDO of the ProfileData about to be updated. The 3rd argument is the offset within the ProfileData of the entry to update. So for parameters for instance, the 2nd argument is the offset within the MDO of the ParametersTypeData and the 3rd argument is then set to the offset within the ParametersTypeData of the argument we want to profile, for each argument. The 2nd argument is used to set up a register with a pointer that is used for subsequent updates by using addresses relative to that register. Return value profiling is a special case because there?s only one profile to update so 2nd and 3rd arguments can be exchanged. I swapped them because otherwise the 3rd argument is an offset that doesn?t always fit in a single sparc load/store instruction. An extra instruction is always emitted but the code is simpler. > src/cpu/sparc/vm/interp_masm_sparc.cpp: > > + // We're right after the type profile for the last > + // argument. tmp is the number of cell left in the > + // CallTypeData/VirtualCallTypeData to reach its end. Non null > + // if there's a return to profile. > + assert(ReturnTypeEntry::static_cell_count() < TypeStackSlotEntries::per_arg_count(), "can't move past ret type"); > + sll(tmp1, exact_log2(DataLayout::cell_size), tmp1); > + add(ImethodDataPtr, tmp1, ImethodDataPtr); > > I think ?tmp? is referring to ?tmp1? and ?cell? should be plural, shouldn?t it? Yes. Thanks. > Some comments are missing the final ?.?. Will fix that. > Also, I didn?t verify the machine instructions in detail but a quick scan didn?t bring up anything obviously wrong. I guess you did some testing. I sanity checked with a simple test program that expected profiling is collected. I also did the usual testing to check that nothing unexpected happens when this is on. Roland. > > Looks good. > > On Jan 9, 2014, at 12:35 AM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~roland/8026253/webrev.00/ >> >> The main difference with the x86 code is that on sparc, the current profile value is loaded, checked & updated and finally stored rather than checked & updated in place as is done on x86. As a consequence the code is somewhat simpler because concurrent updates to the profile are not possible. >> >> Roland. > From albert.noll at oracle.com Fri Jan 10 05:28:24 2014 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 10 Jan 2014 14:28:24 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> Message-ID: <52CFF578.7080204@oracle.com> Hi, I've evaluated the performance difference (nashorn + octane) between binary search and a linear search. The linear-search version uses one GrowableArray for each dependency type. The difference in dependency checking time is 15-20%, i.e., binary search is 15-20% faster than linear search. However, using linear search to cache checked dependencies is still ~4X faster compared to checking all dependencies. I guess 15-20% is not enough to justify using the new data structure. Here is the new webrev that uses linear search: http://cr.openjdk.java.net/~anoll/7194669/webrev.01/ Best, Albert On 01/09/2014 06:57 PM, Roland Westrelin wrote: >> As I recall running some nashorn benchmarks takes about 10X more time when using fastdebug VM if VerifyDependencies is not switched off. > Thanks Vladimir. > What about simply pushing the dependency signatures to an unsorted growableArray() and doing a linear search? Maybe that?s good enough? > > Roland. > From roland.westrelin at oracle.com Fri Jan 10 06:04:49 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 10 Jan 2014 15:04:49 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52CFF578.7080204@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> Message-ID: <3240EEEC-B60F-45AC-A788-41EED3393211@oracle.com> Hi Albert, > I've evaluated the performance difference (nashorn + octane) between binary search > and a linear search. The linear-search version uses one GrowableArray > for each dependency type. The difference in dependency checking time is 15-20%, i.e., binary > search is 15-20% faster than linear search. However, using linear search to cache checked > dependencies is still ~4X faster compared to checking all dependencies. Thanks for making the experiment. > I guess 15-20% is not enough to justify using the new data structure. Here is the new > webrev that uses linear search: > http://cr.openjdk.java.net/~anoll/7194669/webrev.01/ Can a safepoint occur during verification? It doesn?t look like it to me. It could be verified with a No_Safepoint_Verifier. No safepoint would mean that objects don?t move and then: uintptr_t Dependencies::DepStream::get_identity_hash(int i) { if (has_oop_argument()) { return (uintpr_t)argument_oop(i); } else { return (uinptr_t)argument(i); } } And then there?s no need to worry about the issue that Dean raised: identity hash not being unique. Roland. From vladimir.kozlov at oracle.com Fri Jan 10 08:26:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Jan 2014 08:26:27 -0800 Subject: RFR(M): 8026253: New type profiling points: sparc support In-Reply-To: References: <866E3055-184D-48D3-BFE1-5EDAABEC446A@oracle.com> <52CF2161.2030208@oracle.com> Message-ID: <52D01F33.3040004@oracle.com> On 1/10/14 4:44 AM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for reviewing this. > >> c1_LIRAssembler_sparc.cpp: consider using not short branch instruction because the distance could be big (stop() generates a lot of code): >> >> 3135 __ ba_short(next); > > I did a specjvm98 run on a T4 with VerifyOops on and the code as it is runs fine. > The interpreter code is ok unless TypeProfileArgsLimit is set to something unreasonable (10). > The ba_short that you mention above is the most likely to cause problem on the compiler side. I could convert it to a non short branch just to be safe. What do you think? Yes, I was only concern about that particular branch which is most far from destination. Even if it is fine now, later change to the code can tip it over. So, please, change it to far branch. Thanks, Vladimir > > Roland. > >> Otherwise it seems good. >> >> Thanks, >> Vladimir >> >> On 1/9/14 12:35 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8026253/webrev.00/ >>> >>> The main difference with the x86 code is that on sparc, the current profile value is loaded, checked & updated and finally stored rather than checked & updated in place as is done on x86. As a consequence the code is somewhat simpler because concurrent updates to the profile are not possible. >>> >>> Roland. >>> > From mark.reinhold at oracle.com Fri Jan 10 08:27:18 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 10 Jan 2014 08:27:18 -0800 Subject: -XX:+UseOldInlining In-Reply-To: <0997ED89-BC64-44F4-BD8C-018732E9F1C2@kodewerk.com> References: <52CFAE04.9000309@oracle.com>, <15619902.8MtnO6Lifq@mgerdin03>, <1554613.Ts12lamzx3@mgerdin03>, <0997ED89-BC64-44F4-BD8C-018732E9F1C2@kodewerk.com> Message-ID: <20140110082718.733160@eggemoggin.niobe.net> 2014/1/9 20:31 -0800, kirk at kodewerk.com: > Is it possible to externalize the information? No, because it's source code that predates OpenJDK and thus has not been cleared for publication. - Mark From kirk at kodewerk.com Fri Jan 10 08:29:14 2014 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 10 Jan 2014 17:29:14 +0100 Subject: -XX:+UseOldInlining In-Reply-To: <20140110082718.733160@eggemoggin.niobe.net> References: <52CFAE04.9000309@oracle.com>, <15619902.8MtnO6Lifq@mgerdin03>, <1554613.Ts12lamzx3@mgerdin03>, <0997ED89-BC64-44F4-BD8C-018732E9F1C2@kodewerk.com> <20140110082718.733160@eggemoggin.niobe.net> Message-ID: Hi Mark, Thanks for confirming. Regards, Kirk P.S. I can be a pain if you want ;-) On Jan 10, 2014, at 5:27 PM, mark.reinhold at oracle.com wrote: > 2014/1/9 20:31 -0800, kirk at kodewerk.com: >> Is it possible to externalize the information? > > No, because it's source code that predates OpenJDK and thus has not been > cleared for publication. > > - Mark From vladimir.kozlov at oracle.com Fri Jan 10 09:36:17 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Jan 2014 09:36:17 -0800 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> Message-ID: <52D02F91.4080701@oracle.com> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. Passing 'true' parameter is not very informative. You can use local variable: bool include_speculative = true; t->filter(_type, include_speculative); An other way to make code more informative is to add a comment to parameter: t->filter(_type, true /* include_speculative */); Either way is fine. Thanks, Vladimir On 1/10/14 1:46 AM, Roland Westrelin wrote: > Hi Vladimir, > > Here is a new webrev for this: > http://cr.openjdk.java.net/~roland/8027422/webrev.01/ > > I fixed the issues you mentioned in your review. > I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). > I also added a verification method: > NodeHash::check_speculative_types() > to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() > > Roland. > > On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: > >> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>> Thanks for reviewing this, Vladimir. >>> >>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>> >>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>> >>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>> >>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>> >>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>> >>> You?re right. It probably should. >>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >> >> Right, passing 'true' will work in all cases then. >> >> Thanks, >> Vladimir >> >>> >>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>> >>> Sure. >>> >>> Roland. >>> >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>> higher_equal() >>>>> meet() >>>>> join() >>>>> filter() >>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>> >>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>> >>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>> >>>>> Roland. >>>>> >>> > From john.coomes at oracle.com Fri Jan 10 12:44:13 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 20:44:13 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b123 for changeset 1ecd4619f60c Message-ID: <20140110204417.9669A624E3@hg.openjdk.java.net> Changeset: afecd2878aee Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/afecd2878aee Added tag jdk8-b123 for changeset 1ecd4619f60c ! .hgtags From john.coomes at oracle.com Fri Jan 10 12:44:23 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 20:44:23 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b123 for changeset 4e35b5b6d2e5 Message-ID: <20140110204433.C87D9624E4@hg.openjdk.java.net> Changeset: 1a28f773c894 Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/1a28f773c894 Added tag jdk8-b123 for changeset 4e35b5b6d2e5 ! .hgtags From john.coomes at oracle.com Fri Jan 10 12:44:37 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 20:44:37 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b123 for changeset 91f5c542ccad Message-ID: <20140110204445.9630A624E5@hg.openjdk.java.net> Changeset: 241e4effed6d Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/241e4effed6d Added tag jdk8-b123 for changeset 91f5c542ccad ! .hgtags From john.coomes at oracle.com Fri Jan 10 12:44:09 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 20:44:09 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b123 for changeset ff1478785e43 Message-ID: <20140110204409.48F30624E2@hg.openjdk.java.net> Changeset: c330fa67c4da Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/c330fa67c4da Added tag jdk8-b123 for changeset ff1478785e43 ! .hgtags From john.coomes at oracle.com Fri Jan 10 12:48:35 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 20:48:35 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b123 for changeset a345cf28faca Message-ID: <20140110204902.5AEA7624E8@hg.openjdk.java.net> Changeset: d5aab8300d3b Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d5aab8300d3b Added tag jdk8-b123 for changeset a345cf28faca ! .hgtags From john.coomes at oracle.com Fri Jan 10 12:49:16 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 20:49:16 +0000 Subject: hg: hsx/hotspot-comp/nashorn: Added tag jdk8-b123 for changeset 688f4167f921 Message-ID: <20140110204922.29D6B624E9@hg.openjdk.java.net> Changeset: 0b4301c79225 Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/0b4301c79225 Added tag jdk8-b123 for changeset 688f4167f921 ! .hgtags From christian.thalinger at oracle.com Fri Jan 10 12:59:50 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 10 Jan 2014 12:59:50 -0800 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52CFF578.7080204@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> Message-ID: <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> This looks good. Just a suggestion (you can ignore that if you want): GrowableArray has find() and contains() methods. If you would override operator== in DependencySignature you could use GrowableArray::find(). On Jan 10, 2014, at 5:28 AM, Albert Noll wrote: > Hi, > > I've evaluated the performance difference (nashorn + octane) between binary search > and a linear search. The linear-search version uses one GrowableArray > for each dependency type. The difference in dependency checking time is 15-20%, i.e., binary > search is 15-20% faster than linear search. However, using linear search to cache checked > dependencies is still ~4X faster compared to checking all dependencies. > > I guess 15-20% is not enough to justify using the new data structure. Here is the new > webrev that uses linear search: > http://cr.openjdk.java.net/~anoll/7194669/webrev.01/ > > Best, > Albert > > On 01/09/2014 06:57 PM, Roland Westrelin wrote: >>> As I recall running some nashorn benchmarks takes about 10X more time when using fastdebug VM if VerifyDependencies is not switched off. >> Thanks Vladimir. >> What about simply pushing the dependency signatures to an unsorted growableArray() and doing a linear search? Maybe that?s good enough? >> >> Roland. >> > From christian.thalinger at oracle.com Fri Jan 10 13:04:47 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 10 Jan 2014 13:04:47 -0800 Subject: -XX:+UseOldInlining In-Reply-To: <52CFAE04.9000309@oracle.com> References: <52CFAE04.9000309@oracle.com> Message-ID: <0D813784-F015-4620-B0A9-0D3D31E325F6@oracle.com> John is on vacation right now but here is what I know. Years and years ago John wanted to rewrite the inlining policy and so the existing one got moved under UseOldInlining. It turned out (and here starts the guesswork) that the new inlining was either not as good or wasn?t finished and so was never turned on. Since then we run with UseOldInlining. I?ve talked to John about this in the past and if I remember correctly he agreed that we can get rid of it. Let?s wait for him to come back and decide then what to do. Can you file a bug so we don?t forget? On Jan 10, 2014, at 12:23 AM, Aleksey Shipilev wrote: > Hi, > > Does anyone remember the story behind -XX:+UseOldInlining? I have > googled, wandered through HotSpot code, searched through JIRA, grepped > through Mercurial to no avail. The history on this predates OpenJDK. > > In seems we have it unconditionally turned on. It makes the inlining > policy a little less understandable to have additional branch here and > there. Should we purge this option from the VM codebase? If so, I can > prepare the proper revision of this scratch change: > http://cr.openjdk.java.net/~shade/scratch/purge-old-inlining.patch > > Thanks, > -Aleksey. From john.coomes at oracle.com Fri Jan 10 12:44:55 2014 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jan 2014 20:44:55 +0000 Subject: hg: hsx/hotspot-comp/jdk: 2 new changesets Message-ID: <20140110204638.01028624E6@hg.openjdk.java.net> Changeset: 484e16c0a040 Author: nikgor Date: 2014-01-07 12:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jdk/rev/13b28cffa140 Added tag jdk8-b123 for changeset 484e16c0a040 ! .hgtags From christian.thalinger at oracle.com Fri Jan 10 13:30:10 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 10 Jan 2014 13:30:10 -0800 Subject: RFR(M): 8026253: New type profiling points: sparc support In-Reply-To: <5DDD1B93-D92C-41E5-9D37-CEAEA0D436B4@oracle.com> References: <866E3055-184D-48D3-BFE1-5EDAABEC446A@oracle.com> <5DDD1B93-D92C-41E5-9D37-CEAEA0D436B4@oracle.com> Message-ID: On Jan 10, 2014, at 4:59 AM, Roland Westrelin wrote: > Thanks for reviewing this, Chris. > >> src/share/vm/c1/c1_LIRGenerator.cpp: >> >> ! ciKlass* exact = profile_type(md, 0, md->byte_offset_of_slot(data, ret->type_offset()), >> ! ciKlass* exact = profile_type(md, md->byte_offset_of_slot(data, ret->type_offset()), 0, >> >> What is this change? > > The 2nd argument to profile_type is the offset within the MDO of the ProfileData about to be updated. The 3rd argument is the offset within the ProfileData of the entry to update. So for parameters for instance, the 2nd argument is the offset within the MDO of the ParametersTypeData and the 3rd argument is then set to the offset within the ParametersTypeData of the argument we want to profile, for each argument. The 2nd argument is used to set up a register with a pointer that is used for subsequent updates by using addresses relative to that register. > Return value profiling is a special case because there?s only one profile to update so 2nd and 3rd arguments can be exchanged. I swapped them because otherwise the 3rd argument is an offset that doesn?t always fit in a single sparc load/store instruction. An extra instruction is always emitted but the code is simpler. Are these arguments also swapped on x86? If not, please add a comment to explain why this was done. > >> src/cpu/sparc/vm/interp_masm_sparc.cpp: >> >> + // We're right after the type profile for the last >> + // argument. tmp is the number of cell left in the >> + // CallTypeData/VirtualCallTypeData to reach its end. Non null >> + // if there's a return to profile. >> + assert(ReturnTypeEntry::static_cell_count() < TypeStackSlotEntries::per_arg_count(), "can't move past ret type"); >> + sll(tmp1, exact_log2(DataLayout::cell_size), tmp1); >> + add(ImethodDataPtr, tmp1, ImethodDataPtr); >> >> I think ?tmp? is referring to ?tmp1? and ?cell? should be plural, shouldn?t it? > > Yes. Thanks. > >> Some comments are missing the final ?.?. > > Will fix that. > >> Also, I didn?t verify the machine instructions in detail but a quick scan didn?t bring up anything obviously wrong. I guess you did some testing. > > I sanity checked with a simple test program that expected profiling is collected. I also did the usual testing to check that nothing unexpected happens when this is on. > > Roland. > >> >> Looks good. >> >> On Jan 9, 2014, at 12:35 AM, Roland Westrelin wrote: >> >>> http://cr.openjdk.java.net/~roland/8026253/webrev.00/ >>> >>> The main difference with the x86 code is that on sparc, the current profile value is loaded, checked & updated and finally stored rather than checked & updated in place as is done on x86. As a consequence the code is somewhat simpler because concurrent updates to the profile are not possible. >>> >>> Roland. >> > From roland.westrelin at oracle.com Mon Jan 13 00:40:13 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 13 Jan 2014 09:40:13 +0100 Subject: RFR(M): 8026253: New type profiling points: sparc support In-Reply-To: References: <866E3055-184D-48D3-BFE1-5EDAABEC446A@oracle.com> <5DDD1B93-D92C-41E5-9D37-CEAEA0D436B4@oracle.com> Message-ID: <6B9F7690-25D2-4E1C-8BC9-BADECC557870@oracle.com> > Are these arguments also swapped on x86? If not, please add a comment to explain why this was done. I will add a comment. Roland. From stefan.karlsson at oracle.com Mon Jan 13 01:26:57 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 13 Jan 2014 10:26:57 +0100 Subject: GC overhead limit exceeded In-Reply-To: References: <52C7B0FC.4040407@threecrickets.com> <52C811F1.4090202@threecrickets.com> <52C8171D.1000402@threecrickets.com> <26DCB270-10F8-4D74-9FF7-0ED268B18299@oracle.com> Message-ID: <52D3B161.9010607@oracle.com> On 2014-01-09 16:29, Kirk Pepperdine wrote: > Hi Marcus, > > Looks like some of the details have been chopped off. Is there a GC log available? If there is a problem with MethodHandle a work around might be a simple as expanding perm.. but wait, this is meta space now and it should grow as long as your system has memory to give to the process. The only thing I can suggest is that the space to hold compressed class pointers is a fixed size and that if Nashorn is loading a lot of classes is that you consider making that space larger. Full disclosure, this isn?t something that I?ve had a chance to dabble with but I think there is a flag to control the size of that space. Maybe Colleen can offer better insight. You can monitor the Metaspace memory usage with the -XX:+PrintHeapAtGC JVM flag. If you want to limit the memory committed to the Metaspace you can use -XX:MaxMetaspaceSize=. For example: -XX:MaxMetaspaceSize=256m StefanK > > Regards, > Kirk > > On Jan 9, 2014, at 10:02 AM, Marcus Lagergren wrote: > >> This almost certainly stems from the implementation from MethodHandle combinators being implemented as lambda forms as anonymous java classes. One of the things that is being done for 8u20 is to drastically reduce the number of lambda forms created. I don?t know of any workaround at the moment. CC:ing hotspot-compiler-dev, so the people there can elaborate a bit. >> >> /M >> >> On 06 Jan 2014, at 06:57, Benjamin Sieffert wrote: >> >>> Hi everyone, >>> >>> we have been observing similar symptoms from 7u40 onwards (using >>> nashorn-backport with j7 -- j8 has the same problems as 7u40 and 7u45... >>> 7u25 is the last version that works fine) and suspect the cause to be the >>> JSR-292 changes that took place there. Iirc I already asked over on their >>> mailing list. Here's the link: >>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-December/005586.html >>> The fault might as well lie with nashorn, though. It's certainly worth >>> investigating. >>> >>> Regards >>> >>> >>> 2014/1/4 Tal Liron >>> >>>> Thanks! I didn't know of these. I'm not sure how to read the log, but this >>>> doesn't look so good. I get a lot of "allocation failures" that look like >>>> this: >>>> >>>> Java HotSpot(TM) 64-Bit Server VM (25.0-b63) for linux-amd64 JRE >>>> (1.8.0-ea-b121), built on Dec 19 2013 17:29:18 by "java_re" with gcc 4.3.0 >>>> 20080428 (Red Hat 4.3.0-8) >>>> Memory: 4k page, physical 2039276k(849688k free), swap 262140k(256280k >>>> free) >>>> CommandLine flags: -XX:InitialHeapSize=32628416 -XX:MaxHeapSize=522054656 >>>> -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps >>>> -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers >>>> -XX:+UseCompressedOops -XX:+UseParallelGC >>>> 0.108: [GC (Allocation Failure) >>>> Desired survivor size 524288 bytes, new threshold 7 (max 15) >>>> [PSYoungGen: 512K->496K(1024K)] 512K->496K(32256K), 0.0013194 secs] >>>> [Times: user=0.01 sys=0.00, real=0.00 secs] >>>> >>>> >>>> On 01/04/2014 10:02 PM, Ben Evans wrote: >>>> >>>>> -Xloggc: -XX:+PrintGCDetails -XX:+PrintTenuringDistribution >>>>> >>>> >>> >>> -- >>> Benjamin Sieffert >>> metrigo GmbH >>> Sternstr. 106 >>> 20357 Hamburg >>> >>> Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer >>> Die Gesellschaft ist eingetragen beim Registergericht Hamburg >>> Nr. HRB 120447. From roland.westrelin at oracle.com Mon Jan 13 02:03:12 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 13 Jan 2014 11:03:12 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <52D02F91.4080701@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> Message-ID: <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> > compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. Thanks for catching that. Is: // Verify that after the IGVN is over no speculative type has resurfaced good as a comment? > Passing 'true' parameter is not very informative. You can use local variable: > > bool include_speculative = true; > t->filter(_type, include_speculative); > > An other way to make code more informative is to add a comment to parameter: > > t->filter(_type, true /* include_speculative */); > > Either way is fine. Will do one of these. Thanks, Roland. > > Thanks, > Vladimir > > On 1/10/14 1:46 AM, Roland Westrelin wrote: >> Hi Vladimir, >> >> Here is a new webrev for this: >> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >> >> I fixed the issues you mentioned in your review. >> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >> I also added a verification method: >> NodeHash::check_speculative_types() >> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >> >> Roland. >> >> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >> >>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>> Thanks for reviewing this, Vladimir. >>>> >>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>> >>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>> >>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>> >>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>> >>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>> >>>> You?re right. It probably should. >>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>> >>> Right, passing 'true' will work in all cases then. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>> >>>> Sure. >>>> >>>> Roland. >>>> >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>> higher_equal() >>>>>> meet() >>>>>> join() >>>>>> filter() >>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>> >>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>> >>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>> >>>>>> Roland. >>>>>> >>>> >> From rednaxelafx at gmail.com Mon Jan 13 10:36:53 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 14 Jan 2014 02:36:53 +0800 Subject: Changing lots of files - mainly GC code In-Reply-To: <52D3E50E.5040308@oracle.com> References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com> <52D017CE.6090509@oracle.com> <52D3E50E.5040308@oracle.com> Message-ID: Hi Jesper, Thanks! I took a look and the change was fine. I do have a couple of other comment fixes that I'd like to hitchhike: 1. oops/method.hpp The comments say ConstMethod* and MethodData* are oops, which they aren't anymore. I'm not sure if the wording for "putting oops and method_size first for better gc cache locality" still matters. It probably doesn't matter anymore, since GC doesn't have to mark through these fields with the PermGen removal. 2. ci/ciField.hpp, ci/ciField.cpp The comments say in order to consider a field as a constant, it cannot hold an non-perm-space oop. I believe this limitation has been removed. Could someone from the compiler team verify if that's true? The diff is at the end of this mail. Thanks, Kris diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp --- a/src/share/vm/ci/ciField.cpp Fri Dec 27 07:51:07 2013 -0800 +++ b/src/share/vm/ci/ciField.cpp Mon Jan 13 10:31:17 2014 -0800 @@ -202,13 +202,9 @@ } // This field just may be constant. The only cases where it will - // not be constant are: + // not be constant is: // - // 1. The field holds a non-perm-space oop. The field is, strictly - // speaking, constant but we cannot embed non-perm-space oops into - // generated code. For the time being we need to consider the - // field to be not constant. - // 2. The field is a *special* static&final field whose value + // 1. The field is a *special* static&final field whose value // may change. The three examples are java.lang.System.in, // java.lang.System.out, and java.lang.System.err. diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp --- a/src/share/vm/ci/ciField.hpp Fri Dec 27 07:51:07 2013 -0800 +++ b/src/share/vm/ci/ciField.hpp Mon Jan 13 10:31:17 2014 -0800 @@ -130,9 +130,7 @@ // 1. The field is both static and final // 2. The canonical holder of the field has undergone // static initialization. - // 3. If the field is an object or array, then the oop - // in question is allocated in perm space. - // 4. The field is not one of the special static/final + // 3. The field is not one of the special static/final // non-constant fields. These are java.lang.System.in // and java.lang.System.out. Abomination. // diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp --- a/src/share/vm/oops/method.hpp Fri Dec 27 07:51:07 2013 -0800 +++ b/src/share/vm/oops/method.hpp Mon Jan 13 10:31:17 2014 -0800 @@ -38,13 +38,11 @@ #include "utilities/accessFlags.hpp" #include "utilities/growableArray.hpp" -// A Method* represents a Java method. +// A Method represents a Java method. // // Memory layout (each line represents a word). Note that most applications load thousands of methods, // so keeping the size of this structure small has a big impact on footprint. // -// We put all oops and method_size first for better gc cache locality. -// // The actual bytecodes are inlined after the end of the Method struct. // // There are bits in the access_flags telling whether inlined tables are present. @@ -64,17 +62,17 @@ // | header | // | klass | // |------------------------------------------------------| -// | ConstMethod* (oop) | +// | ConstMethod* (metadata) | // |------------------------------------------------------| -// | methodData (oop) | -// | methodCounters | +// | MethodData* (metadata) | +// | MethodCounters | // |------------------------------------------------------| // | access_flags | // | vtable_index | // |------------------------------------------------------| // | result_index (C++ interpreter only) | // |------------------------------------------------------| -// | method_size | intrinsic_id| flags | +// | method_size | intrinsic_id | flags | // |------------------------------------------------------| // | code (pointer) | // | i2i (pointer) | On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > Hi Kris! > > No problem, I'll add it to the change. Please verify that it looks OK in > the updated webrev (same link as before). > > http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/ > > /Jesper > > > Krystal Mok skrev 10/1/14 7:17 PM: > >> Hi Jesper, >> >> Nice to see cleaner code! >> >> Hitchhike: It'd be nice if you could include this typo in: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler- >> dev/2014-January/012944.html >> I didn't really like sending one-liner comment typo fix anyway...with a >> lot of >> other typos, the story is different ;-) >> >> Thanks, >> Kris >> >> >> >> On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore < >> coleen.phillimore at oracle.com >> > wrote: >> >> Seems fine with me also. Could you find typos in the comments in the >> runtime code "by accident" too? :) >> thanks, >> Coleen >> >> >> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote: >> >> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote: >> >> Hi, >> >> I have a change out for review that fixes a huge pile of >> typos in >> the comments in the GC code. The RFR was sent to the GC list, >> but I >> want to give a heads up in case anyone else is changing GC >> code and >> want to avoid merge conflicts. >> >> The patch: http://cr.openjdk.java.net/~__ >> jwilhelm/8025856/webrev.1/ >> >> >> >> >> There are also a few files where I happened to find a few >> typos "by >> accident" in code that is not strictly GC code. These are: >> >> src/share/vm/memory/heap.cpp >> src/share/vm/memory/heap.hpp >> src/share/vm/memory/__allocation.hpp >> src/share/vm/memory/__resourceArea.hpp >> src/share/vm/runtime/thread.__cpp >> >> >> There is a total of eight typos fixed in these files so I >> think the >> risk of merge conflicts here is minimal. Are there any >> objections to >> including these fixes in the change? >> >> >> Vote: go for it! >> >> Dan >> >> >> Thanks, >> /Jesper >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140114/ddd939f8/attachment-0001.html From doug.simon at oracle.com Mon Jan 13 14:55:53 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 13 Jan 2014 23:55:53 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent Message-ID: Hi all, I would like to request a review for a change to the Dependencies class such that it can be used to register assumptions based on either ci* values or raw values. The motivation is support compilers (such as Graal) that don't use the ci interface. jbs: https://bugs.openjdk.java.net/browse/JDK-8031639 webrev: http://cr.openjdk.java.net/~dnsimon/JDK-8031639/ -Doug From christian.thalinger at oracle.com Mon Jan 13 22:42:28 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Jan 2014 22:42:28 -0800 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: References: Message-ID: <81D9523B-0086-4AFC-930F-50A33482D722@oracle.com> I like the change. What was the motivation for choosing: positive: metadata, negative: object If it would be the other way around you wouldn't have to negate the sort key: + // Used to sort values in ascending order of index() with metadata values preceding object values + int sort_key() const { return -_id; } src/share/vm/code/dependencies.hpp: + bool note_dep_seen(int dept, DepValue x) { + assert(dept < BitsPerInt, "oops"); + // place metadata deps at even indexes, object deps at odd indexes + int x_id = x.is_metadata() ? x.index() * 2 : (x.index() * 2) + 1; This means we?re using twice as much memory for seen dependencies but I guess it doesn?t matter much. On a related note to the comment above if _id would be: + _id = (rec->find_index(metadata) << 1) | 1; we would have unique, ready-to-use indexes. Is there a reason why metadata and object values need to be grouped together? On Jan 13, 2014, at 2:55 PM, Doug Simon wrote: > Hi all, > > I would like to request a review for a change to the Dependencies class such that it can be used to register assumptions based on either ci* values or raw values. The motivation is support compilers (such as Graal) that don't use the ci interface. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8031639 > webrev: http://cr.openjdk.java.net/~dnsimon/JDK-8031639/ > > -Doug > From roland.westrelin at oracle.com Tue Jan 14 00:43:47 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 14 Jan 2014 09:43:47 +0100 Subject: RFR(XS): 8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a In-Reply-To: <52CB38BD.9040909@oracle.com> References: <49A0DDDE-9C08-4E27-94AA-D32AD4553101@oracle.com> <52CB38BD.9040909@oracle.com> Message-ID: Thanks Igor, Chris and Vladimir for the reviews. Roland. From roland.westrelin at oracle.com Tue Jan 14 01:13:03 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 14 Jan 2014 10:13:03 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> Message-ID: http://cr.openjdk.java.net/~roland/8027422/webrev.02/ I fixed the verification code at the end of Compile::remove_speculative_types(), used this format everywhere: t->filter(_type, true /* include_speculative */); renamed NodeHash::check_speculative_types() to NodeHash::check_no_speculative_types(), added PhaseIterGVN::check_no_speculative_types() and now call it from the verification code of Compile::remove_speculative_types(). Do I need more than 1 review for this? Roland. On Jan 13, 2014, at 11:03 AM, Roland Westrelin wrote: >> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. > > Thanks for catching that. > Is: > // Verify that after the IGVN is over no speculative type has resurfaced > good as a comment? > >> Passing 'true' parameter is not very informative. You can use local variable: >> >> bool include_speculative = true; >> t->filter(_type, include_speculative); >> >> An other way to make code more informative is to add a comment to parameter: >> >> t->filter(_type, true /* include_speculative */); >> >> Either way is fine. > > Will do one of these. > > Thanks, > Roland. > >> >> Thanks, >> Vladimir >> >> On 1/10/14 1:46 AM, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>> Here is a new webrev for this: >>> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >>> >>> I fixed the issues you mentioned in your review. >>> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >>> I also added a verification method: >>> NodeHash::check_speculative_types() >>> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >>> >>> Roland. >>> >>> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >>> >>>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>>> Thanks for reviewing this, Vladimir. >>>>> >>>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>>> >>>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>>> >>>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>>> >>>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>>> >>>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>>> >>>>> You?re right. It probably should. >>>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>>> >>>> Right, passing 'true' will work in all cases then. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>>> >>>>> Sure. >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>>> higher_equal() >>>>>>> meet() >>>>>>> join() >>>>>>> filter() >>>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>>> >>>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>>> >>>>>>> Roland. >>>>>>> >>>>> >>> > From albert.noll at oracle.com Tue Jan 14 02:21:32 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 14 Jan 2014 11:21:32 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> Message-ID: <52D50FAC.6020008@oracle.com> Hi, thanks for looking at the patch. @Roland: Thanks for your suggestion. The current version follows your suggestion and uses pointers to the dependency arguments as identifiers. As a result, the argument identifiers are guaranteed to be unique if no safepoint occurs. A No_SafepointVerifier checks this assumption. For testing, used -XX:+SafepointALot; so far, no problem. @Dean: I hope the above explanation answers your question. @Christian: The current version uses an overloaded '==' operator in the class DependencySignature. Here is the new webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.02/ Best, Albert On 01/10/2014 09:59 PM, Christian Thalinger wrote: > This looks good. Just a suggestion (you can ignore that if you want): GrowableArray has find() and contains() methods. If you would override operator== in DependencySignature you could use GrowableArray::find(). > > On Jan 10, 2014, at 5:28 AM, Albert Noll wrote: > >> Hi, >> >> I've evaluated the performance difference (nashorn + octane) between binary search >> and a linear search. The linear-search version uses one GrowableArray >> for each dependency type. The difference in dependency checking time is 15-20%, i.e., binary >> search is 15-20% faster than linear search. However, using linear search to cache checked >> dependencies is still ~4X faster compared to checking all dependencies. >> >> I guess 15-20% is not enough to justify using the new data structure. Here is the new >> webrev that uses linear search: >> http://cr.openjdk.java.net/~anoll/7194669/webrev.01/ >> >> Best, >> Albert >> >> On 01/09/2014 06:57 PM, Roland Westrelin wrote: >>>> As I recall running some nashorn benchmarks takes about 10X more time when using fastdebug VM if VerifyDependencies is not switched off. >>> Thanks Vladimir. >>> What about simply pushing the dependency signatures to an unsorted growableArray() and doing a linear search? Maybe that?s good enough? >>> >>> Roland. >>> From roland.westrelin at oracle.com Tue Jan 14 03:26:34 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 14 Jan 2014 12:26:34 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52D50FAC.6020008@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> <52D50FAC.6020008@oracle.com> Message-ID: <201BDC86-5A66-4A07-AE72-7879D528908C@oracle.com> Hi Albert, > @Christian: The current version uses an overloaded '==' operator in the class DependencySignature. Isn?t the reason to overload == that you can then use find/contains methods from GrowableArray? Unless I?m missing something I don?t see that it is the case. Roland. From roland.westrelin at oracle.com Tue Jan 14 03:46:28 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 14 Jan 2014 12:46:28 +0100 Subject: RFR(XS): 8030662: "assert(counter_changed) failed: failed dependencies, but counter didn't change" still fails In-Reply-To: <52B5E9AF.2050806@oracle.com> References: <052D3374-6B6E-444F-8DC4-3ADC457E395C@oracle.com> <52B5E9AF.2050806@oracle.com> Message-ID: <2BC7AB5A-5DEC-4CB5-B0F6-1AF85E8BD080@oracle.com> Thanks Chris, Igor and Vladimir for the reviews. Roland. From albert.noll at oracle.com Tue Jan 14 03:53:39 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 14 Jan 2014 12:53:39 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <201BDC86-5A66-4A07-AE72-7879D528908C@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> <52D50FAC.6020008@oracle.com> <201BDC86-5A66-4A07-AE72-7879D528908C@oracle.com> Message-ID: <52D52543.6040607@oracle.com> Hi Roland, thanks for looking at the patch. You are right, the overloaded '==' operator is not used as proposed by Christian. I think this is not possible in the current version, since the GrowableArray stores pointers to DependencySinatures. This version does not overload the '==' operator. Two DependencySignatures are compared by an 'equals()' function. Here is the new webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.03/ Best, Albert On 01/14/2014 12:26 PM, Roland Westrelin wrote: > Hi Albert, > >> @Christian: The current version uses an overloaded '==' operator in the class DependencySignature. > Isn?t the reason to overload == that you can then use find/contains methods from GrowableArray? Unless I?m missing something I don?t see that it is the case. > > Roland. From roland.westrelin at oracle.com Tue Jan 14 04:45:52 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 14 Jan 2014 13:45:52 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52D52543.6040607@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> <52D50FAC.6020008@oracle.com> <201BDC86-5A66-4A07-AE72-7879D528908C@oracle.com> <52D52543.6040607@oracle.com> Message-ID: > http://cr.openjdk.java.net/~anoll/7194669/webrev.03/ dependencies.cpp No need to cast twice: 688 return (uintptr_t)(oopDesc*)argument_oop(i); What is that for? 747 void* DependencySignature::operator new (size_t size) throw() { 748 return NEW_RESOURCE_ARRAY(DependencySignature, 1); 749 } Shouldn?t we abort if we find something wrong? Printing stuff will easily go unnoticed. Roland. From doug.simon at oracle.com Tue Jan 14 05:14:17 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 14 Jan 2014 14:14:17 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: <81D9523B-0086-4AFC-930F-50A33482D722@oracle.com> References: <81D9523B-0086-4AFC-930F-50A33482D722@oracle.com> Message-ID: <56964A83-93F9-4520-9D0A-BB94FDCFA4F7@oracle.com> On Jan 14, 2014, at 7:42 AM, Christian Thalinger wrote: > I like the change. What was the motivation for choosing: > > positive: metadata, negative: object To avoid collisions since the id is based on indexes in separate data structures (OopRecorder::_metadata and OopRecorder::_oops). This choice of which is negative and positive is arbitrary. > If it would be the other way around you wouldn't have to negate the sort key: > > + // Used to sort values in ascending order of index() with metadata values preceding object values > + int sort_key() const { return -_id; } I don?t think it matters that metadata sort before object values, just as long as they are distinguished from each. That is, the comment is describing what sort order is produced as opposed to being a requirement on the sort order. > > src/share/vm/code/dependencies.hpp: > > + bool note_dep_seen(int dept, DepValue x) { > + assert(dept < BitsPerInt, "oops"); > + // place metadata deps at even indexes, object deps at odd indexes > + int x_id = x.is_metadata() ? x.index() * 2 : (x.index() * 2) + 1; > > This means we?re using twice as much memory for seen dependencies but I guess it doesn?t matter much. I don?t think it matters. > On a related note to the comment above if _id would be: > > + _id = (rec->find_index(metadata) << 1) | 1; > > we would have unique, ready-to-use indexes. If this is applied to DepValues for oops as well, then yes, almost. We?d still need the negation for objects and DepValue::index() would have to do the reverse shift. Not sure if makes any real difference. > Is there a reason why metadata and object values need to be grouped together? Grouped together where? -Doug > On Jan 13, 2014, at 2:55 PM, Doug Simon wrote: > >> Hi all, >> >> I would like to request a review for a change to the Dependencies class such that it can be used to register assumptions based on either ci* values or raw values. The motivation is support compilers (such as Graal) that don't use the ci interface. >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8031639 >> webrev: http://cr.openjdk.java.net/~dnsimon/JDK-8031639/ >> >> -Doug >> > From niclas.adlertz at oracle.com Tue Jan 14 05:15:29 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Tue, 14 Jan 2014 14:15:29 +0100 Subject: RFR(L) 8034198: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() Message-ID: <52D53871.40606@oracle.com> Hi all, This is a first step to clean up the register allocator in C2. In this change we have divided the very long method build_ifg_physical() into many smaller ones, making it easier to see the steps when building the IFG (and computing the block pressure). We have also cleaned up old comments and improved old code, both by better naming and by simplifying expressions. I personally think that the easiest way to review this change is to have the old and new ifg.cpp side by side, and start from build_ifg_physical(). The next step is to create a new class for these methods, isolating them and removing them from PhaseChaitin. WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 Kind Regards, Niclas Adlertz From rickard.backman at oracle.com Tue Jan 14 06:03:53 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 14 Jan 2014 15:03:53 +0100 Subject: RFR(L) 8034198: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <52D53871.40606@oracle.com> References: <52D53871.40606@oracle.com> Message-ID: <20140114140353.GB9323@rbackman> Just a few comments on the C++ parts. I haven't verified that the logic is still the same. 1) It seems like there are a couple of functions that could be created in the new Pressure class to avoid code duplication. One example is the check_for_high_pressure_block method. 2) All places that checks lrg._is_float also check lrg._is_vector. That check could be made into a boolean method on the LRG instead. The same for is_UP() & mask_size(). 3) To make code more generic the int_pressure and float_pressure instances could be passed the INTPRESSURE and FLOATPRESSURE and keep those as instance variables. Good work. /R On 01/14, Niclas Adlertz wrote: > Hi all, > > This is a first step to clean up the register allocator in C2. In this change we have divided the very long method build_ifg_physical() into many smaller ones, making it easier to see the steps when building the IFG (and computing the block pressure). > We have also cleaned up old comments and improved old code, both by better naming and by simplifying expressions. > I personally think that the easiest way to review this change is to have the old and new ifg.cpp side by side, and start from build_ifg_physical(). > The next step is to create a new class for these methods, isolating them and removing them from PhaseChaitin. > WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ > BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 > > Kind Regards, > Niclas Adlertz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140114/1091e743/attachment.bin From jesper.wilhelmsson at oracle.com Tue Jan 14 05:38:07 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 14 Jan 2014 14:38:07 +0100 Subject: Changing lots of files - mainly GC code In-Reply-To: References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com> <52D017CE.6090509@oracle.com> <52D3E50E.5040308@oracle.com> Message-ID: <52D53DBF.9040500@oracle.com> Sure, no problem. Webrev is updated, please verify. I took the liberty of changing the layout of the comment in ciField.cpp. Since there was only one case left it didn't feel motivated to have a list of cases. /Jesper Krystal Mok skrev 13/1/14 7:36 PM: > Hi Jesper, > > Thanks! I took a look and the change was fine. > > I do have a couple of other comment fixes that I'd like to hitchhike: > > 1. oops/method.hpp > > The comments say ConstMethod* and MethodData* are oops, which they aren't anymore. > I'm not sure if the wording for "putting oops and method_size first for better > gc cache locality" still matters. It probably doesn't matter anymore, since GC > doesn't have to mark through these fields with the PermGen removal. > > 2. ci/ciField.hpp, ci/ciField.cpp > > The comments say in order to consider a field as a constant, it cannot hold an > non-perm-space oop. I believe this limitation has been removed. Could someone > from the compiler team verify if that's true? > > The diff is at the end of this mail. > > Thanks, > Kris > > diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp > --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 -0800 > +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 -0800 > @@ -202,13 +202,9 @@ > } > // This field just may be constant. The only cases where it will > - // not be constant are: > + // not be constant is: > // > - // 1. The field holds a non-perm-space oop. The field is, strictly > - // speaking, constant but we cannot embed non-perm-space oops into > - // generated code. For the time being we need to consider the > - // field to be not constant. > - // 2. The field is a *special* static&final field whose value > + // 1. The field is a *special* static&final field whose value > // may change. The three examples are java.lang.System.in > , > // java.lang.System.out, and java.lang.System.err. > diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp > --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 -0800 > +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 -0800 > @@ -130,9 +130,7 @@ > // 1. The field is both static and final > // 2. The canonical holder of the field has undergone > // static initialization. > - // 3. If the field is an object or array, then the oop > - // in question is allocated in perm space. > - // 4. The field is not one of the special static/final > + // 3. The field is not one of the special static/final > // non-constant fields. These are java.lang.System.in > > // and java.lang.System.out. Abomination. > // > diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp > --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 2013 -0800 > +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 2014 -0800 > @@ -38,13 +38,11 @@ > #include "utilities/accessFlags.hpp" > #include "utilities/growableArray.hpp" > -// A Method* represents a Java method. > +// A Method represents a Java method. > // > // Memory layout (each line represents a word). Note that most applications > load thousands of methods, > // so keeping the size of this structure small has a big impact on footprint. > // > -// We put all oops and method_size first for better gc cache locality. > -// > // The actual bytecodes are inlined after the end of the Method struct. > // > // There are bits in the access_flags telling whether inlined tables are present. > @@ -64,17 +62,17 @@ > // | header | > // | klass | > // |------------------------------------------------------| > -// | ConstMethod* (oop) | > +// | ConstMethod* (metadata) | > // |------------------------------------------------------| > -// | methodData (oop) | > -// | methodCounters | > +// | MethodData* (metadata) | > +// | MethodCounters | > // |------------------------------------------------------| > // | access_flags | > // | vtable_index | > // |------------------------------------------------------| > // | result_index (C++ interpreter only) | > // |------------------------------------------------------| > -// | method_size | intrinsic_id| flags | > +// | method_size | intrinsic_id | flags | > // |------------------------------------------------------| > // | code (pointer) | > // | i2i (pointer) | > > > > > On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson > > wrote: > > Hi Kris! > > No problem, I'll add it to the change. Please verify that it looks OK in the > updated webrev (same link as before). > > http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/ > > > /Jesper > > > Krystal Mok skrev 10/1/14 7:17 PM: > > Hi Jesper, > > Nice to see cleaner code! > > Hitchhike: It'd be nice if you could include this typo in: > http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__dev/2014-January/012944.html > > I didn't really like sending one-liner comment typo fix anyway...with a > lot of > other typos, the story is different ;-) > > Thanks, > Kris > > > > On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore > > >> wrote: > > Seems fine with me also. Could you find typos in the comments in the > runtime code "by accident" too? :) > thanks, > Coleen > > > On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote: > > On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote: > > Hi, > > I have a change out for review that fixes a huge pile of > typos in > the comments in the GC code. The RFR was sent to the GC > list, but I > want to give a heads up in case anyone else is changing GC > code and > want to avoid merge conflicts. > > The patch: > http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/ > > > > > > > There are also a few files where I happened to find a few > typos "by > accident" in code that is not strictly GC code. These are: > > src/share/vm/memory/heap.cpp > src/share/vm/memory/heap.hpp > src/share/vm/memory/____allocation.hpp > src/share/vm/memory/____resourceArea.hpp > src/share/vm/runtime/thread.____cpp > > > There is a total of eight typos fixed in these files so I > think the > risk of merge conflicts here is minimal. Are there any > objections to > including these fixes in the change? > > > Vote: go for it! > > Dan > > > Thanks, > /Jesper > > > > > From vladimir.kozlov at oracle.com Tue Jan 14 07:25:34 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jan 2014 07:25:34 -0800 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> Message-ID: <52D556EE.8000307@oracle.com> Looks good to me. On 1/14/14 1:13 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8027422/webrev.02/ > > I fixed the verification code at the end of Compile::remove_speculative_types(), used this format everywhere: > t->filter(_type, true /* include_speculative */); > > renamed NodeHash::check_speculative_types() to NodeHash::check_no_speculative_types(), added PhaseIterGVN::check_no_speculative_types() and now call it from the verification code of Compile::remove_speculative_types(). > > Do I need more than 1 review for this? Yes, you need an other review for this change. Ask Chris or Igor. Thanks, Vladimir > > Roland. > > > On Jan 13, 2014, at 11:03 AM, Roland Westrelin wrote: > >>> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. >> >> Thanks for catching that. >> Is: >> // Verify that after the IGVN is over no speculative type has resurfaced >> good as a comment? >> >>> Passing 'true' parameter is not very informative. You can use local variable: >>> >>> bool include_speculative = true; >>> t->filter(_type, include_speculative); >>> >>> An other way to make code more informative is to add a comment to parameter: >>> >>> t->filter(_type, true /* include_speculative */); >>> >>> Either way is fine. >> >> Will do one of these. >> >> Thanks, >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 1/10/14 1:46 AM, Roland Westrelin wrote: >>>> Hi Vladimir, >>>> >>>> Here is a new webrev for this: >>>> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >>>> >>>> I fixed the issues you mentioned in your review. >>>> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >>>> I also added a verification method: >>>> NodeHash::check_speculative_types() >>>> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >>>> >>>> Roland. >>>> >>>> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >>>> >>>>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>>>> Thanks for reviewing this, Vladimir. >>>>>> >>>>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>>>> >>>>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>>>> >>>>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>>>> >>>>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>>>> >>>>>> You?re right. It probably should. >>>>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>>>> >>>>> Right, passing 'true' will work in all cases then. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>>>> >>>>>> Sure. >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>>>> higher_equal() >>>>>>>> meet() >>>>>>>> join() >>>>>>>> filter() >>>>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>>>> >>>>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>> >>>> >> > From albert.noll at oracle.com Tue Jan 14 07:51:07 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 14 Jan 2014 16:51:07 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> <52D50FAC.6020008@oracle.com> <201BDC86-5A66-4A07-AE72-7879D528908C@oracle.com> <52D52543.6040607@oracle.com> Message-ID: <52D55CEB.1050809@oracle.com> Hi Roland, thanks again for looking at the patch. Please see comments inline: On 01/14/2014 01:45 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~anoll/7194669/webrev.03/ > dependencies.cpp > > No need to cast twice: > 688 return (uintptr_t)(oopDesc*)argument_oop(i); If I skip the cast to (oopDesc*), the compiler gives the following error: dependencies.cpp:688:51: error: invalid cast from type ?oop? to type ?uintptr_t {aka long unsigned int}? > > What is that for? > 747 void* DependencySignature::operator new (size_t size) throw() { > 748 return NEW_RESOURCE_ARRAY(DependencySignature, 1); > 749 } I guess this is not the usual way to allocate objects into a ResourceMark. The updated version derives DependencySignature from : public ResourceObj. I hope this is fine. > Shouldn?t we abort if we find something wrong? Printing stuff will easily go unnoticed. I agree. This version fails with an assert if dependency checking fails. > Roland. Here is the new webrev: http://cr.openjdk.java.net/~anoll/7194669/webrev.04/ Best, Albert From roland.westrelin at oracle.com Tue Jan 14 08:30:00 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 14 Jan 2014 17:30:00 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52D55CEB.1050809@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> <52D50FAC.6020008@oracle.com> <201BDC86-5A66-4A07-AE72-7879D528908C@oracle.com> <52D52543.6040607@oracle.com> <52D55CEB.1050809@oracle.com> Message-ID: > http://cr.openjdk.java.net/~anoll/7194669/webrev.04/ Thanks Albert. That looks good to me. Roland. From roland.westrelin at oracle.com Tue Jan 14 08:46:00 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 14 Jan 2014 17:46:00 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <52D556EE.8000307@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> <52D556EE.8000307@oracle.com> Message-ID: <82739039-60B0-4E95-8986-47222663564B@oracle.com> Thanks, Vladimir. Roland. On Jan 14, 2014, at 4:25 PM, Vladimir Kozlov wrote: > Looks good to me. > > On 1/14/14 1:13 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8027422/webrev.02/ >> >> I fixed the verification code at the end of Compile::remove_speculative_types(), used this format everywhere: >> t->filter(_type, true /* include_speculative */); >> >> renamed NodeHash::check_speculative_types() to NodeHash::check_no_speculative_types(), added PhaseIterGVN::check_no_speculative_types() and now call it from the verification code of Compile::remove_speculative_types(). >> >> Do I need more than 1 review for this? > > Yes, you need an other review for this change. Ask Chris or Igor. > > Thanks, > Vladimir > >> >> Roland. >> >> >> On Jan 13, 2014, at 11:03 AM, Roland Westrelin wrote: >> >>>> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. >>> >>> Thanks for catching that. >>> Is: >>> // Verify that after the IGVN is over no speculative type has resurfaced >>> good as a comment? >>> >>>> Passing 'true' parameter is not very informative. You can use local variable: >>>> >>>> bool include_speculative = true; >>>> t->filter(_type, include_speculative); >>>> >>>> An other way to make code more informative is to add a comment to parameter: >>>> >>>> t->filter(_type, true /* include_speculative */); >>>> >>>> Either way is fine. >>> >>> Will do one of these. >>> >>> Thanks, >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/10/14 1:46 AM, Roland Westrelin wrote: >>>>> Hi Vladimir, >>>>> >>>>> Here is a new webrev for this: >>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >>>>> >>>>> I fixed the issues you mentioned in your review. >>>>> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >>>>> I also added a verification method: >>>>> NodeHash::check_speculative_types() >>>>> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >>>>> >>>>> Roland. >>>>> >>>>> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>>>>> Thanks for reviewing this, Vladimir. >>>>>>> >>>>>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>>>>> >>>>>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>>>>> >>>>>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>>>>> >>>>>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>>>>> >>>>>>> You?re right. It probably should. >>>>>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>>>>> >>>>>> Right, passing 'true' will work in all cases then. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>>>>> >>>>>>> Sure. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>>>>> higher_equal() >>>>>>>>> meet() >>>>>>>>> join() >>>>>>>>> filter() >>>>>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>>>>> >>>>>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>> >>>>> >>> >> From vladimir.kozlov at oracle.com Tue Jan 14 08:48:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jan 2014 08:48:49 -0800 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> <52D50FAC.6020008@oracle.com> <201BDC86-5A66-4A07-AE72-7879D528908C@oracle.com> <52D52543.6040607@oracle.com> <52D55CEB.1050809@oracle.com> Message-ID: <52D56A71.5070601@oracle.com> +1 It is good. Thanks, Vladimir On 1/14/14 8:30 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~anoll/7194669/webrev.04/ > > Thanks Albert. That looks good to me. > > Roland. > From christian.thalinger at oracle.com Tue Jan 14 09:37:45 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 14 Jan 2014 09:37:45 -0800 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: <56964A83-93F9-4520-9D0A-BB94FDCFA4F7@oracle.com> References: <81D9523B-0086-4AFC-930F-50A33482D722@oracle.com> <56964A83-93F9-4520-9D0A-BB94FDCFA4F7@oracle.com> Message-ID: <16674146-DC5B-42D7-9834-9641D5F0A009@oracle.com> On Jan 14, 2014, at 5:14 AM, Doug Simon wrote: > > On Jan 14, 2014, at 7:42 AM, Christian Thalinger wrote: > >> I like the change. What was the motivation for choosing: >> >> positive: metadata, negative: object > > To avoid collisions since the id is based on indexes in separate data structures (OopRecorder::_metadata and OopRecorder::_oops). This choice of which is negative and positive is arbitrary. > >> If it would be the other way around you wouldn't have to negate the sort key: >> >> + // Used to sort values in ascending order of index() with metadata values preceding object values >> + int sort_key() const { return -_id; } > > I don?t think it matters that metadata sort before object values, just as long as they are distinguished from each. That is, the comment is describing what sort order is produced as opposed to being a requirement on the sort order. > >> >> src/share/vm/code/dependencies.hpp: >> >> + bool note_dep_seen(int dept, DepValue x) { >> + assert(dept < BitsPerInt, "oops"); >> + // place metadata deps at even indexes, object deps at odd indexes >> + int x_id = x.is_metadata() ? x.index() * 2 : (x.index() * 2) + 1; >> >> This means we?re using twice as much memory for seen dependencies but I guess it doesn?t matter much. > > I don?t think it matters. > >> On a related note to the comment above if _id would be: >> >> + _id = (rec->find_index(metadata) << 1) | 1; >> >> we would have unique, ready-to-use indexes. > > If this is applied to DepValues for oops as well, then yes, almost. We?d still need the negation for objects and DepValue::index() would have to do the reverse shift. Not sure if makes any real difference. Why would we need the negation? All indexes would be positive then. The only reason I?d like to see that is because users of DepValue::index() could just use the value without having to avoid collisions like above. > >> Is there a reason why metadata and object values need to be grouped together? > > Grouped together where? I was referring to the comment: + // Used to sort values in ascending order of index() with metadata values preceding object values + int sort_key() const { return -_id; } That sorting groups metadata and objects but I guess it?s not important. > > -Doug > >> On Jan 13, 2014, at 2:55 PM, Doug Simon wrote: >> >>> Hi all, >>> >>> I would like to request a review for a change to the Dependencies class such that it can be used to register assumptions based on either ci* values or raw values. The motivation is support compilers (such as Graal) that don't use the ci interface. >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8031639 >>> webrev: http://cr.openjdk.java.net/~dnsimon/JDK-8031639/ >>> >>> -Doug >>> >> > From rednaxelafx at gmail.com Tue Jan 14 09:53:34 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 15 Jan 2014 01:53:34 +0800 Subject: Changing lots of files - mainly GC code In-Reply-To: <52D53DBF.9040500@oracle.com> References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com> <52D017CE.6090509@oracle.com> <52D3E50E.5040308@oracle.com> <52D53DBF.9040500@oracle.com> Message-ID: Hi Jesper, That looks fine to me. Thank you! It's still better if someone from the runtime team could verify the change in oops/method.hpp, and someone from the compiler team could verify the change in ci/ciField.hpp|cpp Thanks, Kris On Tue, Jan 14, 2014 at 9:38 PM, Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > Sure, no problem. Webrev is updated, please verify. > I took the liberty of changing the layout of the comment in ciField.cpp. > Since there was only one case left it didn't feel motivated to have a list > of cases. > /Jesper > > Krystal Mok skrev 13/1/14 7:36 PM: > >> Hi Jesper, >> >> Thanks! I took a look and the change was fine. >> >> I do have a couple of other comment fixes that I'd like to hitchhike: >> >> 1. oops/method.hpp >> >> The comments say ConstMethod* and MethodData* are oops, which they aren't >> anymore. >> I'm not sure if the wording for "putting oops and method_size first for >> better >> gc cache locality" still matters. It probably doesn't matter anymore, >> since GC >> doesn't have to mark through these fields with the PermGen removal. >> >> 2. ci/ciField.hpp, ci/ciField.cpp >> >> The comments say in order to consider a field as a constant, it cannot >> hold an >> non-perm-space oop. I believe this limitation has been removed. Could >> someone >> from the compiler team verify if that's true? >> >> The diff is at the end of this mail. >> >> Thanks, >> Kris >> >> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp >> --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 -0800 >> +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 -0800 >> >> @@ -202,13 +202,9 @@ >> } >> // This field just may be constant. The only cases where it will >> - // not be constant are: >> + // not be constant is: >> // >> - // 1. The field holds a non-perm-space oop. The field is, strictly >> - // speaking, constant but we cannot embed non-perm-space oops into >> - // generated code. For the time being we need to consider the >> - // field to be not constant. >> - // 2. The field is a *special* static&final field whose value >> + // 1. The field is a *special* static&final field whose value >> // may change. The three examples are java.lang.System.in >> , >> >> // java.lang.System.out, and java.lang.System.err. >> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp >> --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 -0800 >> +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 -0800 >> >> @@ -130,9 +130,7 @@ >> // 1. The field is both static and final >> // 2. The canonical holder of the field has undergone >> // static initialization. >> - // 3. If the field is an object or array, then the oop >> - // in question is allocated in perm space. >> - // 4. The field is not one of the special static/final >> + // 3. The field is not one of the special static/final >> // non-constant fields. These are java.lang.System.in >> >> >> // and java.lang.System.out. Abomination. >> // >> diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp >> --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 2013 -0800 >> +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 2014 -0800 >> >> @@ -38,13 +38,11 @@ >> #include "utilities/accessFlags.hpp" >> #include "utilities/growableArray.hpp" >> -// A Method* represents a Java method. >> +// A Method represents a Java method. >> // >> // Memory layout (each line represents a word). Note that most >> applications >> load thousands of methods, >> // so keeping the size of this structure small has a big impact on >> footprint. >> // >> -// We put all oops and method_size first for better gc cache locality. >> -// >> // The actual bytecodes are inlined after the end of the Method struct. >> // >> // There are bits in the access_flags telling whether inlined tables >> are present. >> @@ -64,17 +62,17 @@ >> // | header | >> // | klass | >> // |------------------------------------------------------| >> -// | ConstMethod* (oop) | >> +// | ConstMethod* (metadata) | >> // |------------------------------------------------------| >> -// | methodData (oop) | >> -// | methodCounters | >> +// | MethodData* (metadata) | >> +// | MethodCounters | >> // |------------------------------------------------------| >> // | access_flags | >> // | vtable_index | >> // |------------------------------------------------------| >> // | result_index (C++ interpreter only) | >> // |------------------------------------------------------| >> -// | method_size | intrinsic_id| flags | >> +// | method_size | intrinsic_id | flags | >> // |------------------------------------------------------| >> // | code (pointer) | >> // | i2i (pointer) | >> >> >> >> >> On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson >> > >> wrote: >> >> Hi Kris! >> >> No problem, I'll add it to the change. Please verify that it looks OK >> in the >> updated webrev (same link as before). >> >> http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/ >> >> >> >> /Jesper >> >> >> Krystal Mok skrev 10/1/14 7:17 PM: >> >> Hi Jesper, >> >> Nice to see cleaner code! >> >> Hitchhike: It'd be nice if you could include this typo in: >> http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__ >> dev/2014-January/012944.html >> >> > dev/2014-January/012944.html> >> I didn't really like sending one-liner comment typo fix >> anyway...with a >> lot of >> other typos, the story is different ;-) >> >> Thanks, >> Kris >> >> >> >> On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore >> > oracle.com> >> > >> >> wrote: >> >> Seems fine with me also. Could you find typos in the >> comments in the >> runtime code "by accident" too? :) >> thanks, >> Coleen >> >> >> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote: >> >> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote: >> >> Hi, >> >> I have a change out for review that fixes a huge >> pile of >> typos in >> the comments in the GC code. The RFR was sent to the >> GC >> list, but I >> want to give a heads up in case anyone else is >> changing GC >> code and >> want to avoid merge conflicts. >> >> The patch: >> http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/ >> >> >> >> > _jwilhelm/8025856/webrev.1/ >> > >> >> >> There are also a few files where I happened to find >> a few >> typos "by >> accident" in code that is not strictly GC code. >> These are: >> >> src/share/vm/memory/heap.cpp >> src/share/vm/memory/heap.hpp >> src/share/vm/memory/____allocation.hpp >> src/share/vm/memory/____resourceArea.hpp >> src/share/vm/runtime/thread.____cpp >> >> >> >> There is a total of eight typos fixed in these files >> so I >> think the >> risk of merge conflicts here is minimal. Are there >> any >> objections to >> including these fixes in the change? >> >> >> Vote: go for it! >> >> Dan >> >> >> Thanks, >> /Jesper >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140115/549fa0ca/attachment-0001.html From christian.thalinger at oracle.com Tue Jan 14 09:56:11 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 14 Jan 2014 09:56:11 -0800 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: <16674146-DC5B-42D7-9834-9641D5F0A009@oracle.com> References: <81D9523B-0086-4AFC-930F-50A33482D722@oracle.com> <56964A83-93F9-4520-9D0A-BB94FDCFA4F7@oracle.com> <16674146-DC5B-42D7-9834-9641D5F0A009@oracle.com> Message-ID: On Jan 14, 2014, at 9:37 AM, Christian Thalinger wrote: > > On Jan 14, 2014, at 5:14 AM, Doug Simon wrote: > >> >> On Jan 14, 2014, at 7:42 AM, Christian Thalinger wrote: >> >>> I like the change. What was the motivation for choosing: >>> >>> positive: metadata, negative: object >> >> To avoid collisions since the id is based on indexes in separate data structures (OopRecorder::_metadata and OopRecorder::_oops). This choice of which is negative and positive is arbitrary. >> >>> If it would be the other way around you wouldn't have to negate the sort key: >>> >>> + // Used to sort values in ascending order of index() with metadata values preceding object values >>> + int sort_key() const { return -_id; } >> >> I don?t think it matters that metadata sort before object values, just as long as they are distinguished from each. That is, the comment is describing what sort order is produced as opposed to being a requirement on the sort order. >> >>> >>> src/share/vm/code/dependencies.hpp: >>> >>> + bool note_dep_seen(int dept, DepValue x) { >>> + assert(dept < BitsPerInt, "oops"); >>> + // place metadata deps at even indexes, object deps at odd indexes >>> + int x_id = x.is_metadata() ? x.index() * 2 : (x.index() * 2) + 1; >>> >>> This means we?re using twice as much memory for seen dependencies but I guess it doesn?t matter much. >> >> I don?t think it matters. >> >>> On a related note to the comment above if _id would be: >>> >>> + _id = (rec->find_index(metadata) << 1) | 1; >>> >>> we would have unique, ready-to-use indexes. >> >> If this is applied to DepValues for oops as well, then yes, almost. We?d still need the negation for objects and DepValue::index() would have to do the reverse shift. Not sure if makes any real difference. > > Why would we need the negation? All indexes would be positive then. The only reason I?d like to see that is because users of DepValue::index() could just use the value without having to avoid collisions like above. I take all back. I was missing the fact that we need to original OopRecorder index in Dependencies::encode_content_bytes. Then my suggestion doesn?t make sense. > >> >>> Is there a reason why metadata and object values need to be grouped together? >> >> Grouped together where? > > I was referring to the comment: > > + // Used to sort values in ascending order of index() with metadata values preceding object values > + int sort_key() const { return -_id; } > > That sorting groups metadata and objects but I guess it?s not important. > >> >> -Doug >> >>> On Jan 13, 2014, at 2:55 PM, Doug Simon wrote: >>> >>>> Hi all, >>>> >>>> I would like to request a review for a change to the Dependencies class such that it can be used to register assumptions based on either ci* values or raw values. The motivation is support compilers (such as Graal) that don't use the ci interface. >>>> >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8031639 >>>> webrev: http://cr.openjdk.java.net/~dnsimon/JDK-8031639/ >>>> >>>> -Doug From albert.noll at oracle.com Tue Jan 14 10:32:47 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 14 Jan 2014 19:32:47 +0100 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52D56A71.5070601@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> <52D50FAC.6020008@oracle.com> <201BDC86-5A66-4A07-AE72-7879D528908C@oracle.com> <52D52543.6040607@oracle.com> <52D55CEB.1050809@oracle.com> <52D56A71.5070601@oracle.com> Message-ID: <52D582CF.9090503@oracle.com> Roland, Vladimir, thanks for reviewing. Best, Albert On 01/14/2014 05:48 PM, Vladimir Kozlov wrote: > +1 > > It is good. > > Thanks, > Vladimir > > On 1/14/14 8:30 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~anoll/7194669/webrev.04/ >> >> Thanks Albert. That looks good to me. >> >> Roland. >> From coleen.phillimore at oracle.com Tue Jan 14 10:46:36 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Jan 2014 13:46:36 -0500 Subject: Changing lots of files - mainly GC code In-Reply-To: References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com> <52D017CE.6090509@oracle.com> <52D3E50E.5040308@oracle.com> <52D53DBF.9040500@oracle.com> Message-ID: <52D5860C.4010107@oracle.com> These changes you have look good for Method except a lot of the comment is out of date. The block comment about the layout of fields in Method is redundant with the actual declaration and wrong. It's a nice visual but I don't see the point of keeping redundant information like that. Also, it the comment describes some of the fields that were moved to ConstMethod years ago. I don't think you want to try to correct these things with this typo change, but we should (I could) file an RFE to correct them later. thanks, Coleen On 01/14/2014 12:53 PM, Krystal Mok wrote: > Hi Jesper, > > That looks fine to me. Thank you! > It's still better if someone from the runtime team could verify the > change in oops/method.hpp, and someone from the compiler team could > verify the change in ci/ciField.hpp|cpp > > Thanks, > Kris > > > On Tue, Jan 14, 2014 at 9:38 PM, Jesper Wilhelmsson > > > wrote: > > Sure, no problem. Webrev is updated, please verify. > I took the liberty of changing the layout of the comment in > ciField.cpp. Since there was only one case left it didn't feel > motivated to have a list of cases. > /Jesper > > Krystal Mok skrev 13/1/14 7:36 PM: > > Hi Jesper, > > Thanks! I took a look and the change was fine. > > I do have a couple of other comment fixes that I'd like to > hitchhike: > > 1. oops/method.hpp > > The comments say ConstMethod* and MethodData* are oops, which > they aren't anymore. > I'm not sure if the wording for "putting oops and method_size > first for better > gc cache locality" still matters. It probably doesn't matter > anymore, since GC > doesn't have to mark through these fields with the PermGen > removal. > > 2. ci/ciField.hpp, ci/ciField.cpp > > The comments say in order to consider a field as a constant, > it cannot hold an > non-perm-space oop. I believe this limitation has been > removed. Could someone > from the compiler team verify if that's true? > > The diff is at the end of this mail. > > Thanks, > Kris > > diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp > --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 -0800 > +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 -0800 > > @@ -202,13 +202,9 @@ > } > // This field just may be constant. The only cases > where it will > - // not be constant are: > + // not be constant is: > // > - // 1. The field holds a non-perm-space oop. The field > is, strictly > - // speaking, constant but we cannot embed > non-perm-space oops into > - // generated code. For the time being we need to > consider the > - // field to be not constant. > - // 2. The field is a *special* static&final field whose value > + // 1. The field is a *special* static&final field whose value > // may change. The three examples are > java.lang.System.in > , > > // java.lang.System.out, and java.lang.System.err. > diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp > --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 -0800 > +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 -0800 > > @@ -130,9 +130,7 @@ > // 1. The field is both static and final > // 2. The canonical holder of the field has undergone > // static initialization. > - // 3. If the field is an object or array, then the oop > - // in question is allocated in perm space. > - // 4. The field is not one of the special static/final > + // 3. The field is not one of the special static/final > // non-constant fields. These are > java.lang.System.in > > > // and java.lang.System.out. Abomination. > // > diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp > --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 2013 -0800 > +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 2014 -0800 > > @@ -38,13 +38,11 @@ > #include "utilities/accessFlags.hpp" > #include "utilities/growableArray.hpp" > -// A Method* represents a Java method. > +// A Method represents a Java method. > // > // Memory layout (each line represents a word). Note that > most applications > load thousands of methods, > // so keeping the size of this structure small has a big > impact on footprint. > // > -// We put all oops and method_size first for better gc cache > locality. > -// > // The actual bytecodes are inlined after the end of the > Method struct. > // > // There are bits in the access_flags telling whether > inlined tables are present. > @@ -64,17 +62,17 @@ > // | header | > // | klass | > // |------------------------------------------------------| > -// | ConstMethod* (oop) | > +// | ConstMethod* (metadata) | > // |------------------------------------------------------| > -// | methodData (oop) | > -// | methodCounters | > +// | MethodData* (metadata) | > +// | MethodCounters | > // |------------------------------------------------------| > // | access_flags | > // | vtable_index | > // |------------------------------------------------------| > // | result_index (C++ interpreter only) | > // |------------------------------------------------------| > -// | method_size | intrinsic_id| flags | > +// | method_size | intrinsic_id | flags | > // |------------------------------------------------------| > // | code (pointer) | > // | i2i (pointer) | > > > > > On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson > > >> wrote: > > Hi Kris! > > No problem, I'll add it to the change. Please verify that > it looks OK in the > updated webrev (same link as before). > > http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/ > > > > > > /Jesper > > > Krystal Mok skrev 10/1/14 7:17 PM: > > Hi Jesper, > > Nice to see cleaner code! > > Hitchhike: It'd be nice if you could include this typo in: > http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__dev/2014-January/012944.html > > > > > I didn't really like sending one-liner comment typo > fix anyway...with a > lot of > other typos, the story is different ;-) > > Thanks, > Kris > > > > On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore > > > > __oracle.com > > >>> wrote: > > Seems fine with me also. Could you find typos in > the comments in the > runtime code "by accident" too? :) > thanks, > Coleen > > > On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote: > > On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote: > > Hi, > > I have a change out for review that fixes > a huge pile of > typos in > the comments in the GC code. The RFR was > sent to the GC > list, but I > want to give a heads up in case anyone > else is changing GC > code and > want to avoid merge conflicts. > > The patch: > http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/ > > > > > > > > > > >> > > > There are also a few files where I > happened to find a few > typos "by > accident" in code that is not strictly GC > code. These are: > > src/share/vm/memory/heap.cpp > src/share/vm/memory/heap.hpp > src/share/vm/memory/____allocation.hpp > src/share/vm/memory/____resourceArea.hpp > src/share/vm/runtime/thread.____cpp > > > > There is a total of eight typos fixed in > these files so I > think the > risk of merge conflicts here is minimal. > Are there any > objections to > including these fixes in the change? > > > Vote: go for it! > > Dan > > > Thanks, > /Jesper > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140114/0a67943d/attachment-0001.html From rednaxelafx at gmail.com Tue Jan 14 11:29:21 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 15 Jan 2014 03:29:21 +0800 Subject: Changing lots of files - mainly GC code In-Reply-To: <52D5860C.4010107@oracle.com> References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com> <52D017CE.6090509@oracle.com> <52D3E50E.5040308@oracle.com> <52D53DBF.9040500@oracle.com> <52D5860C.4010107@oracle.com> Message-ID: Hi Coleen, Thanks for the review. I'm all for getting things right, and I agree there's more comments that needs some love. I'm okay with leaving the changes in method.hpp out for now, and correct them later. Thanks, Kris On Wed, Jan 15, 2014 at 2:46 AM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > These changes you have look good for Method except a lot of the comment is > out of date. The block comment about the layout of fields in Method is > redundant with the actual declaration and wrong. It's a nice visual but I > don't see the point of keeping redundant information like that. Also, it > the comment describes some of the fields that were moved to ConstMethod > years ago. I don't think you want to try to correct these things with > this typo change, but we should (I could) file an RFE to correct them later. > > thanks, > Coleen > > > On 01/14/2014 12:53 PM, Krystal Mok wrote: > > Hi Jesper, > > That looks fine to me. Thank you! > It's still better if someone from the runtime team could verify the change > in oops/method.hpp, and someone from the compiler team could verify the > change in ci/ciField.hpp|cpp > > Thanks, > Kris > > > On Tue, Jan 14, 2014 at 9:38 PM, Jesper Wilhelmsson < > jesper.wilhelmsson at oracle.com> wrote: > >> Sure, no problem. Webrev is updated, please verify. >> I took the liberty of changing the layout of the comment in ciField.cpp. >> Since there was only one case left it didn't feel motivated to have a list >> of cases. >> /Jesper >> >> Krystal Mok skrev 13/1/14 7:36 PM: >> >>> Hi Jesper, >>> >>> Thanks! I took a look and the change was fine. >>> >>> I do have a couple of other comment fixes that I'd like to hitchhike: >>> >>> 1. oops/method.hpp >>> >>> The comments say ConstMethod* and MethodData* are oops, which they >>> aren't anymore. >>> I'm not sure if the wording for "putting oops and method_size first for >>> better >>> gc cache locality" still matters. It probably doesn't matter anymore, >>> since GC >>> doesn't have to mark through these fields with the PermGen removal. >>> >>> 2. ci/ciField.hpp, ci/ciField.cpp >>> >>> The comments say in order to consider a field as a constant, it cannot >>> hold an >>> non-perm-space oop. I believe this limitation has been removed. Could >>> someone >>> from the compiler team verify if that's true? >>> >>> The diff is at the end of this mail. >>> >>> Thanks, >>> Kris >>> >>> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp >>> --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 -0800 >>> +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 -0800 >>> >>> @@ -202,13 +202,9 @@ >>> } >>> // This field just may be constant. The only cases where it will >>> - // not be constant are: >>> + // not be constant is: >>> // >>> - // 1. The field holds a non-perm-space oop. The field is, strictly >>> - // speaking, constant but we cannot embed non-perm-space oops >>> into >>> - // generated code. For the time being we need to consider the >>> - // field to be not constant. >>> - // 2. The field is a *special* static&final field whose value >>> + // 1. The field is a *special* static&final field whose value >>> // may change. The three examples are java.lang.System.in >>> , >>> >>> // java.lang.System.out, and java.lang.System.err. >>> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp >>> --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 -0800 >>> +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 -0800 >>> >>> @@ -130,9 +130,7 @@ >>> // 1. The field is both static and final >>> // 2. The canonical holder of the field has undergone >>> // static initialization. >>> - // 3. If the field is an object or array, then the oop >>> - // in question is allocated in perm space. >>> - // 4. The field is not one of the special static/final >>> + // 3. The field is not one of the special static/final >>> // non-constant fields. These are java.lang.System.in >>> >>> >>> // and java.lang.System.out. Abomination. >>> // >>> diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp >>> --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 2013 -0800 >>> +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 2014 -0800 >>> >>> @@ -38,13 +38,11 @@ >>> #include "utilities/accessFlags.hpp" >>> #include "utilities/growableArray.hpp" >>> -// A Method* represents a Java method. >>> +// A Method represents a Java method. >>> // >>> // Memory layout (each line represents a word). Note that most >>> applications >>> load thousands of methods, >>> // so keeping the size of this structure small has a big impact on >>> footprint. >>> // >>> -// We put all oops and method_size first for better gc cache locality. >>> -// >>> // The actual bytecodes are inlined after the end of the Method struct. >>> // >>> // There are bits in the access_flags telling whether inlined tables >>> are present. >>> @@ -64,17 +62,17 @@ >>> // | header | >>> // | klass | >>> // |------------------------------------------------------| >>> -// | ConstMethod* (oop) | >>> +// | ConstMethod* (metadata) | >>> // |------------------------------------------------------| >>> -// | methodData (oop) | >>> -// | methodCounters | >>> +// | MethodData* (metadata) | >>> +// | MethodCounters | >>> // |------------------------------------------------------| >>> // | access_flags | >>> // | vtable_index | >>> // |------------------------------------------------------| >>> // | result_index (C++ interpreter only) | >>> // |------------------------------------------------------| >>> -// | method_size | intrinsic_id| flags | >>> +// | method_size | intrinsic_id | flags | >>> // |------------------------------------------------------| >>> // | code (pointer) | >>> // | i2i (pointer) | >>> >>> >>> >>> >>> On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson >>> > >>> wrote: >>> >>> Hi Kris! >>> >>> No problem, I'll add it to the change. Please verify that it looks >>> OK in the >>> updated webrev (same link as before). >>> >>> http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/ >>> >>> >>> >>> /Jesper >>> >>> >>> Krystal Mok skrev 10/1/14 7:17 PM: >>> >>> Hi Jesper, >>> >>> Nice to see cleaner code! >>> >>> Hitchhike: It'd be nice if you could include this typo in: >>> >>> http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__dev/2014-January/012944.html >>> >>> < >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012944.html >>> > >>> I didn't really like sending one-liner comment typo fix >>> anyway...with a >>> lot of >>> other typos, the story is different ;-) >>> >>> Thanks, >>> Kris >>> >>> >>> >>> On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore >>> >> coleen.phillimore at oracle.com> >>> >> >>> >> wrote: >>> >>> Seems fine with me also. Could you find typos in the >>> comments in the >>> runtime code "by accident" too? :) >>> thanks, >>> Coleen >>> >>> >>> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote: >>> >>> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote: >>> >>> Hi, >>> >>> I have a change out for review that fixes a huge >>> pile of >>> typos in >>> the comments in the GC code. The RFR was sent to >>> the GC >>> list, but I >>> want to give a heads up in case anyone else is >>> changing GC >>> code and >>> want to avoid merge conflicts. >>> >>> The patch: >>> http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/ >>> >>> >>> >>> < >>> http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/ >>> > >>> >>> >>> There are also a few files where I happened to find >>> a few >>> typos "by >>> accident" in code that is not strictly GC code. >>> These are: >>> >>> src/share/vm/memory/heap.cpp >>> src/share/vm/memory/heap.hpp >>> src/share/vm/memory/____allocation.hpp >>> src/share/vm/memory/____resourceArea.hpp >>> src/share/vm/runtime/thread.____cpp >>> >>> >>> >>> There is a total of eight typos fixed in these >>> files so I >>> think the >>> risk of merge conflicts here is minimal. Are there >>> any >>> objections to >>> including these fixes in the change? >>> >>> >>> Vote: go for it! >>> >>> Dan >>> >>> >>> Thanks, >>> /Jesper >>> >>> >>> >>> >>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140115/dad984e0/attachment-0001.html From coleen.phillimore at oracle.com Tue Jan 14 12:40:54 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Jan 2014 15:40:54 -0500 Subject: Changing lots of files - mainly GC code In-Reply-To: References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com> <52D017CE.6090509@oracle.com> <52D3E50E.5040308@oracle.com> <52D53DBF.9040500@oracle.com> <52D5860C.4010107@oracle.com> Message-ID: <52D5A0D6.3090602@oracle.com> On 01/14/2014 02:29 PM, Krystal Mok wrote: > Hi Coleen, > > Thanks for the review. I'm all for getting things right, and I agree > there's more comments that needs some love. > I'm okay with leaving the changes in method.hpp out for now, and > correct them later. The ones you and Jesper have so far are fine. You can leave them in. I would like you to leave them in. I was only pointing out that there are more changes needed that could be done by themselves later. Coleen > > Thanks, > Kris > > > On Wed, Jan 15, 2014 at 2:46 AM, Coleen Phillimore > > > wrote: > > > These changes you have look good for Method except a lot of the > comment is out of date. The block comment about the layout of > fields in Method is redundant with the actual declaration and > wrong. It's a nice visual but I don't see the point of keeping > redundant information like that. Also, it the comment describes > some of the fields that were moved to ConstMethod years ago. I > don't think you want to try to correct these things with this typo > change, but we should (I could) file an RFE to correct them later. > > thanks, > Coleen > > > On 01/14/2014 12:53 PM, Krystal Mok wrote: >> Hi Jesper, >> >> That looks fine to me. Thank you! >> It's still better if someone from the runtime team could verify >> the change in oops/method.hpp, and someone from the compiler team >> could verify the change in ci/ciField.hpp|cpp >> >> Thanks, >> Kris >> >> >> On Tue, Jan 14, 2014 at 9:38 PM, Jesper Wilhelmsson >> > > wrote: >> >> Sure, no problem. Webrev is updated, please verify. >> I took the liberty of changing the layout of the comment in >> ciField.cpp. Since there was only one case left it didn't >> feel motivated to have a list of cases. >> /Jesper >> >> Krystal Mok skrev 13/1/14 7:36 PM: >> >> Hi Jesper, >> >> Thanks! I took a look and the change was fine. >> >> I do have a couple of other comment fixes that I'd like >> to hitchhike: >> >> 1. oops/method.hpp >> >> The comments say ConstMethod* and MethodData* are oops, >> which they aren't anymore. >> I'm not sure if the wording for "putting oops and >> method_size first for better >> gc cache locality" still matters. It probably doesn't >> matter anymore, since GC >> doesn't have to mark through these fields with the >> PermGen removal. >> >> 2. ci/ciField.hpp, ci/ciField.cpp >> >> The comments say in order to consider a field as a >> constant, it cannot hold an >> non-perm-space oop. I believe this limitation has been >> removed. Could someone >> from the compiler team verify if that's true? >> >> The diff is at the end of this mail. >> >> Thanks, >> Kris >> >> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp >> --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 >> -0800 >> +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 >> -0800 >> >> @@ -202,13 +202,9 @@ >> } >> // This field just may be constant. The only cases >> where it will >> - // not be constant are: >> + // not be constant is: >> // >> - // 1. The field holds a non-perm-space oop. The >> field is, strictly >> - // speaking, constant but we cannot embed >> non-perm-space oops into >> - // generated code. For the time being we need to >> consider the >> - // field to be not constant. >> - // 2. The field is a *special* static&final field >> whose value >> + // 1. The field is a *special* static&final field >> whose value >> // may change. The three examples are >> java.lang.System.in >> , >> >> // java.lang.System.out, and java.lang.System.err. >> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp >> --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 >> -0800 >> +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 >> -0800 >> >> @@ -130,9 +130,7 @@ >> // 1. The field is both static and final >> // 2. The canonical holder of the field has undergone >> // static initialization. >> - // 3. If the field is an object or array, then the oop >> - // in question is allocated in perm space. >> - // 4. The field is not one of the special static/final >> + // 3. The field is not one of the special static/final >> // non-constant fields. These are >> java.lang.System.in >> >> >> // and java.lang.System.out. Abomination. >> // >> diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp >> --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 >> 2013 -0800 >> +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 >> 2014 -0800 >> >> @@ -38,13 +38,11 @@ >> #include "utilities/accessFlags.hpp" >> #include "utilities/growableArray.hpp" >> -// A Method* represents a Java method. >> +// A Method represents a Java method. >> // >> // Memory layout (each line represents a word). Note >> that most applications >> load thousands of methods, >> // so keeping the size of this structure small has a >> big impact on footprint. >> // >> -// We put all oops and method_size first for better gc >> cache locality. >> -// >> // The actual bytecodes are inlined after the end of >> the Method struct. >> // >> // There are bits in the access_flags telling whether >> inlined tables are present. >> @@ -64,17 +62,17 @@ >> // | header | >> // | klass | >> // |------------------------------------------------------| >> -// | ConstMethod* (oop) | >> +// | ConstMethod* (metadata) | >> // |------------------------------------------------------| >> -// | methodData (oop) | >> -// | methodCounters | >> +// | MethodData* (metadata) | >> +// | MethodCounters | >> // |------------------------------------------------------| >> // | access_flags | >> // | vtable_index | >> // |------------------------------------------------------| >> // | result_index (C++ interpreter only) | >> // |------------------------------------------------------| >> -// | method_size | intrinsic_id| flags | >> +// | method_size | intrinsic_id | flags | >> // |------------------------------------------------------| >> // | code (pointer) | >> // | i2i (pointer) | >> >> >> >> >> On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson >> > >> > >> wrote: >> >> Hi Kris! >> >> No problem, I'll add it to the change. Please verify >> that it looks OK in the >> updated webrev (same link as before). >> >> http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/ >> >> >> >> > > >> >> /Jesper >> >> >> Krystal Mok skrev 10/1/14 7:17 PM: >> >> Hi Jesper, >> >> Nice to see cleaner code! >> >> Hitchhike: It'd be nice if you could include this >> typo in: >> http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__dev/2014-January/012944.html >> >> >> >> >> I didn't really like sending one-liner comment >> typo fix anyway...with a >> lot of >> other typos, the story is different ;-) >> >> Thanks, >> Kris >> >> >> >> On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore >> > >> > > >> > __oracle.com >> >> > >>> wrote: >> >> Seems fine with me also. Could you find >> typos in the comments in the >> runtime code "by accident" too? :) >> thanks, >> Coleen >> >> >> On 1/10/2014 10:39 AM, Daniel D. Daugherty >> wrote: >> >> On 1/10/14 5:49 AM, Jesper Wilhelmsson >> wrote: >> >> Hi, >> >> I have a change out for review that >> fixes a huge pile of >> typos in >> the comments in the GC code. The RFR >> was sent to the GC >> list, but I >> want to give a heads up in case >> anyone else is changing GC >> code and >> want to avoid merge conflicts. >> >> The patch: >> http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/ >> >> > > >> >> >> >> >> >> >> > >> >> >> >> There are also a few files where I >> happened to find a few >> typos "by >> accident" in code that is not >> strictly GC code. These are: >> >> src/share/vm/memory/heap.cpp >> src/share/vm/memory/heap.hpp >> src/share/vm/memory/____allocation.hpp >> src/share/vm/memory/____resourceArea.hpp >> src/share/vm/runtime/thread.____cpp >> >> >> >> There is a total of eight typos >> fixed in these files so I >> think the >> risk of merge conflicts here is >> minimal. Are there any >> objections to >> including these fixes in the change? >> >> >> Vote: go for it! >> >> Dan >> >> >> Thanks, >> /Jesper >> >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140114/c8fd077f/attachment-0001.html From rednaxelafx at gmail.com Tue Jan 14 15:21:36 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 15 Jan 2014 07:21:36 +0800 Subject: Changing lots of files - mainly GC code In-Reply-To: <52D5A0D6.3090602@oracle.com> References: <52CFEC4D.5000908@oracle.com> <52D0141F.3070900@oracle.com> <52D017CE.6090509@oracle.com> <52D3E50E.5040308@oracle.com> <52D53DBF.9040500@oracle.com> <52D5860C.4010107@oracle.com> <52D5A0D6.3090602@oracle.com> Message-ID: No problem with that either. :-) Thanks, Coleen! - Kris On Wed, Jan 15, 2014 at 4:40 AM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > On 01/14/2014 02:29 PM, Krystal Mok wrote: > > Hi Coleen, > > Thanks for the review. I'm all for getting things right, and I agree > there's more comments that needs some love. > I'm okay with leaving the changes in method.hpp out for now, and correct > them later. > > > The ones you and Jesper have so far are fine. You can leave them in. I > would like you to leave them in. I was only pointing out that there are > more changes needed that could be done by themselves later. > > Coleen > > > > Thanks, > Kris > > > On Wed, Jan 15, 2014 at 2:46 AM, Coleen Phillimore < > coleen.phillimore at oracle.com> wrote: > >> >> These changes you have look good for Method except a lot of the comment >> is out of date. The block comment about the layout of fields in Method is >> redundant with the actual declaration and wrong. It's a nice visual but I >> don't see the point of keeping redundant information like that. Also, it >> the comment describes some of the fields that were moved to ConstMethod >> years ago. I don't think you want to try to correct these things with >> this typo change, but we should (I could) file an RFE to correct them later. >> >> thanks, >> Coleen >> >> >> On 01/14/2014 12:53 PM, Krystal Mok wrote: >> >> Hi Jesper, >> >> That looks fine to me. Thank you! >> It's still better if someone from the runtime team could verify the >> change in oops/method.hpp, and someone from the compiler team could verify >> the change in ci/ciField.hpp|cpp >> >> Thanks, >> Kris >> >> >> On Tue, Jan 14, 2014 at 9:38 PM, Jesper Wilhelmsson < >> jesper.wilhelmsson at oracle.com> wrote: >> >>> Sure, no problem. Webrev is updated, please verify. >>> I took the liberty of changing the layout of the comment in ciField.cpp. >>> Since there was only one case left it didn't feel motivated to have a list >>> of cases. >>> /Jesper >>> >>> Krystal Mok skrev 13/1/14 7:36 PM: >>> >>>> Hi Jesper, >>>> >>>> Thanks! I took a look and the change was fine. >>>> >>>> I do have a couple of other comment fixes that I'd like to hitchhike: >>>> >>>> 1. oops/method.hpp >>>> >>>> The comments say ConstMethod* and MethodData* are oops, which they >>>> aren't anymore. >>>> I'm not sure if the wording for "putting oops and method_size first for >>>> better >>>> gc cache locality" still matters. It probably doesn't matter anymore, >>>> since GC >>>> doesn't have to mark through these fields with the PermGen removal. >>>> >>>> 2. ci/ciField.hpp, ci/ciField.cpp >>>> >>>> The comments say in order to consider a field as a constant, it cannot >>>> hold an >>>> non-perm-space oop. I believe this limitation has been removed. Could >>>> someone >>>> from the compiler team verify if that's true? >>>> >>>> The diff is at the end of this mail. >>>> >>>> Thanks, >>>> Kris >>>> >>>> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.cpp >>>> --- a/src/share/vm/ci/ciField.cppFri Dec 27 07:51:07 2013 -0800 >>>> +++ b/src/share/vm/ci/ciField.cppMon Jan 13 10:31:17 2014 -0800 >>>> >>>> @@ -202,13 +202,9 @@ >>>> } >>>> // This field just may be constant. The only cases where it will >>>> - // not be constant are: >>>> + // not be constant is: >>>> // >>>> - // 1. The field holds a non-perm-space oop. The field is, strictly >>>> - // speaking, constant but we cannot embed non-perm-space oops >>>> into >>>> - // generated code. For the time being we need to consider the >>>> - // field to be not constant. >>>> - // 2. The field is a *special* static&final field whose value >>>> + // 1. The field is a *special* static&final field whose value >>>> // may change. The three examples are java.lang.System.in >>>> , >>>> >>>> // java.lang.System.out, and java.lang.System.err. >>>> diff -r 9d39e8a8ff61 src/share/vm/ci/ciField.hpp >>>> --- a/src/share/vm/ci/ciField.hppFri Dec 27 07:51:07 2013 -0800 >>>> +++ b/src/share/vm/ci/ciField.hppMon Jan 13 10:31:17 2014 -0800 >>>> >>>> @@ -130,9 +130,7 @@ >>>> // 1. The field is both static and final >>>> // 2. The canonical holder of the field has undergone >>>> // static initialization. >>>> - // 3. If the field is an object or array, then the oop >>>> - // in question is allocated in perm space. >>>> - // 4. The field is not one of the special static/final >>>> + // 3. The field is not one of the special static/final >>>> // non-constant fields. These are java.lang.System.in >>>> >>>> >>>> // and java.lang.System.out. Abomination. >>>> // >>>> diff -r 9d39e8a8ff61 src/share/vm/oops/method.hpp >>>> --- a/src/share/vm/oops/method.hppFri Dec 27 07:51:07 2013 -0800 >>>> +++ b/src/share/vm/oops/method.hppMon Jan 13 10:31:17 2014 -0800 >>>> >>>> @@ -38,13 +38,11 @@ >>>> #include "utilities/accessFlags.hpp" >>>> #include "utilities/growableArray.hpp" >>>> -// A Method* represents a Java method. >>>> +// A Method represents a Java method. >>>> // >>>> // Memory layout (each line represents a word). Note that most >>>> applications >>>> load thousands of methods, >>>> // so keeping the size of this structure small has a big impact on >>>> footprint. >>>> // >>>> -// We put all oops and method_size first for better gc cache locality. >>>> -// >>>> // The actual bytecodes are inlined after the end of the Method >>>> struct. >>>> // >>>> // There are bits in the access_flags telling whether inlined tables >>>> are present. >>>> @@ -64,17 +62,17 @@ >>>> // | header | >>>> // | klass | >>>> // |------------------------------------------------------| >>>> -// | ConstMethod* (oop) | >>>> +// | ConstMethod* (metadata) | >>>> // |------------------------------------------------------| >>>> -// | methodData (oop) | >>>> -// | methodCounters | >>>> +// | MethodData* (metadata) | >>>> +// | MethodCounters | >>>> // |------------------------------------------------------| >>>> // | access_flags | >>>> // | vtable_index | >>>> // |------------------------------------------------------| >>>> // | result_index (C++ interpreter only) | >>>> // |------------------------------------------------------| >>>> -// | method_size | intrinsic_id| flags | >>>> +// | method_size | intrinsic_id | flags | >>>> // |------------------------------------------------------| >>>> // | code (pointer) | >>>> // | i2i (pointer) | >>>> >>>> >>>> >>>> >>>> On Mon, Jan 13, 2014 at 9:07 PM, Jesper Wilhelmsson >>>> > >>>> wrote: >>>> >>>> Hi Kris! >>>> >>>> No problem, I'll add it to the change. Please verify that it looks >>>> OK in the >>>> updated webrev (same link as before). >>>> >>>> http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/ >>>> >>>> >>>> >>>> /Jesper >>>> >>>> >>>> Krystal Mok skrev 10/1/14 7:17 PM: >>>> >>>> Hi Jesper, >>>> >>>> Nice to see cleaner code! >>>> >>>> Hitchhike: It'd be nice if you could include this typo in: >>>> >>>> http://mail.openjdk.java.net/__pipermail/hotspot-compiler-__dev/2014-January/012944.html >>>> >>>> < >>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012944.html >>>> > >>>> I didn't really like sending one-liner comment typo fix >>>> anyway...with a >>>> lot of >>>> other typos, the story is different ;-) >>>> >>>> Thanks, >>>> Kris >>>> >>>> >>>> >>>> On Fri, Jan 10, 2014 at 11:54 PM, Coleen Phillmore >>>> >>> coleen.phillimore at oracle.com> >>>> >>> >>>> >> wrote: >>>> >>>> Seems fine with me also. Could you find typos in the >>>> comments in the >>>> runtime code "by accident" too? :) >>>> thanks, >>>> Coleen >>>> >>>> >>>> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote: >>>> >>>> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote: >>>> >>>> Hi, >>>> >>>> I have a change out for review that fixes a huge >>>> pile of >>>> typos in >>>> the comments in the GC code. The RFR was sent to >>>> the GC >>>> list, but I >>>> want to give a heads up in case anyone else is >>>> changing GC >>>> code and >>>> want to avoid merge conflicts. >>>> >>>> The patch: >>>> http://cr.openjdk.java.net/~____jwilhelm/8025856/webrev.1/ >>>> >>>> >>>> >>>> < >>>> http://cr.openjdk.java.net/~__jwilhelm/8025856/webrev.1/ >>>> > >>>> >>>> >>>> There are also a few files where I happened to >>>> find a few >>>> typos "by >>>> accident" in code that is not strictly GC code. >>>> These are: >>>> >>>> src/share/vm/memory/heap.cpp >>>> src/share/vm/memory/heap.hpp >>>> src/share/vm/memory/____allocation.hpp >>>> src/share/vm/memory/____resourceArea.hpp >>>> src/share/vm/runtime/thread.____cpp >>>> >>>> >>>> >>>> There is a total of eight typos fixed in these >>>> files so I >>>> think the >>>> risk of merge conflicts here is minimal. Are there >>>> any >>>> objections to >>>> including these fixes in the change? >>>> >>>> >>>> Vote: go for it! >>>> >>>> Dan >>>> >>>> >>>> Thanks, >>>> /Jesper >>>> >>>> >>>> >>>> >>>> >>>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140115/50e1f1ad/attachment-0001.html From christian.thalinger at oracle.com Tue Jan 14 16:58:17 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 14 Jan 2014 16:58:17 -0800 Subject: [9] RFR(M): 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times In-Reply-To: <52D55CEB.1050809@oracle.com> References: <52CEB226.9080307@oracle.com> <82B1F1DE-791F-4DFF-85D1-5D2662374E8E@oracle.com> <52CEBE6E.3030000@oracle.com> <036DDF86-C6E1-4EC6-97CD-501BAA0F8ED7@oracle.com> <52CEDA64.6060006@oracle.com> <3DED57A3-4B82-4AFD-A06D-B8A029C4513A@oracle.com> <52CFF578.7080204@oracle.com> <6D3AFAEC-3E79-4CBC-A2EA-42231D7E9F21@oracle.com> <52D50FAC.6020008@oracle.com> <201BDC86-5A66-4A07-AE72-7879D528908C@oracle.com> <52D52543.6040607@oracle.com> <52D55CEB.1050809@oracle.com> Message-ID: <24788753-C982-418D-BE56-5BF4CEB9BCCE@oracle.com> Looks good. On Jan 14, 2014, at 7:51 AM, Albert Noll wrote: > Hi Roland, > > thanks again for looking at the patch. Please see comments inline: > > > On 01/14/2014 01:45 PM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~anoll/7194669/webrev.03/ >> dependencies.cpp >> >> No need to cast twice: >> 688 return (uintptr_t)(oopDesc*)argument_oop(i); > If I skip the cast to (oopDesc*), the compiler gives the following error: > dependencies.cpp:688:51: error: invalid cast from type ?oop? to type ?uintptr_t {aka long unsigned int}? >> >> What is that for? >> 747 void* DependencySignature::operator new (size_t size) throw() { >> 748 return NEW_RESOURCE_ARRAY(DependencySignature, 1); >> 749 } > I guess this is not the usual way to allocate objects into a ResourceMark. > The updated version derives DependencySignature from : public ResourceObj. > I hope this is fine. >> Shouldn?t we abort if we find something wrong? Printing stuff will easily go unnoticed. > I agree. This version fails with an assert if dependency checking fails. >> Roland. > Here is the new webrev: > http://cr.openjdk.java.net/~anoll/7194669/webrev.04/ > > Best, > Albert From roland.westrelin at oracle.com Wed Jan 15 03:19:54 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 15 Jan 2014 12:19:54 +0100 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different Message-ID: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. Roland. From niclas.adlertz at oracle.com Wed Jan 15 05:26:17 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 15 Jan 2014 14:26:17 +0100 Subject: RFR(L) 8034198: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <20140114140353.GB9323@rbackman> References: <52D53871.40606@oracle.com> <20140114140353.GB9323@rbackman> Message-ID: <52D68C79.6070800@oracle.com> Hi Rickard, Thank you for your comments. http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev01/ Kind Regards, Niclas Adlertz On 2014-01-14 15:03, Rickard B?ckman wrote: > Just a few comments on the C++ parts. I haven't verified that the logic > is still the same. > > 1) It seems like there are a couple of functions that could be created > in the new Pressure class to avoid code duplication. One example is the > check_for_high_pressure_block method. > > 2) All places that checks lrg._is_float also check lrg._is_vector. That > check could be made into a boolean method on the LRG instead. The same > for is_UP() & mask_size(). > > 3) To make code more generic the int_pressure and float_pressure > instances could be passed the INTPRESSURE and FLOATPRESSURE and keep > those as instance variables. > > Good work. > > /R > > On 01/14, Niclas Adlertz wrote: >> Hi all, >> >> This is a first step to clean up the register allocator in C2. In this change we have divided the very long method build_ifg_physical() into many smaller ones, making it easier to see the steps when building the IFG (and computing the block pressure). >> We have also cleaned up old comments and improved old code, both by better naming and by simplifying expressions. >> I personally think that the easiest way to review this change is to have the old and new ifg.cpp side by side, and start from build_ifg_physical(). >> The next step is to create a new class for these methods, isolating them and removing them from PhaseChaitin. >> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ >> BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 >> >> Kind Regards, >> Niclas Adlertz From niclas.adlertz at oracle.com Wed Jan 15 05:45:10 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 15 Jan 2014 14:45:10 +0100 Subject: RFR(L) 8034198: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <52D68C79.6070800@oracle.com> References: <52D53871.40606@oracle.com> <20140114140353.GB9323@rbackman> <52D68C79.6070800@oracle.com> Message-ID: <52D690E6.50908@oracle.com> Hi again, I found a commented section that I forgot to remove in chaitin.hpp: // stores the first low-to-high transition (starting from the top of block) //uint final_high_pressure_index; Updated the webrev: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev02/ On 2014-01-15 14:26, Niclas Adlertz wrote: > Hi Rickard, > > Thank you for your comments. > > http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev01/ > > Kind Regards, > Niclas Adlertz > > On 2014-01-14 15:03, Rickard B?ckman wrote: >> Just a few comments on the C++ parts. I haven't verified that the logic >> is still the same. >> >> 1) It seems like there are a couple of functions that could be created >> in the new Pressure class to avoid code duplication. One example is the >> check_for_high_pressure_block method. >> >> 2) All places that checks lrg._is_float also check lrg._is_vector. That >> check could be made into a boolean method on the LRG instead. The same >> for is_UP() & mask_size(). >> >> 3) To make code more generic the int_pressure and float_pressure >> instances could be passed the INTPRESSURE and FLOATPRESSURE and keep >> those as instance variables. >> >> Good work. >> >> /R >> >> On 01/14, Niclas Adlertz wrote: >>> Hi all, >>> >>> This is a first step to clean up the register allocator in C2. In this change we have divided the very long method build_ifg_physical() into many smaller ones, making it easier to see the steps when building the IFG (and computing the block pressure). >>> We have also cleaned up old comments and improved old code, both by better naming and by simplifying expressions. >>> I personally think that the easiest way to review this change is to have the old and new ifg.cpp side by side, and start from build_ifg_physical(). >>> The next step is to create a new class for these methods, isolating them and removing them from PhaseChaitin. >>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ >>> BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 >>> >>> Kind Regards, >>> Niclas Adlertz > From vladimir.x.ivanov at oracle.com Wed Jan 15 07:31:04 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Jan 2014 19:31:04 +0400 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter Message-ID: <52D6A9B8.2040906@oracle.com> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8031502 InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm when invoking a method from Object declared in an interface. The problem is the following: (1) java.lang.CharSequence interface declares abstract method "String toString()"; (2) after 8014013 fix, VM resolves CharSequence::toString()/invokeInterface to CharSequence::toString()/invokeVirtual; (3) during LambdaForm compilation, CharSequence is considered statically invocable (see InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for CharSequence::toString() is issued, which is wrong (invokevirtual throws ICCE if it references an interface); The fix is straightforward: during LambdaForm compilation, switch back from invokevirtual to invokeinterface instruction when invoking a method on an interface. The fix is targeted for 8. Will be also integrated into 9. Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, nashorn, jruby. Thanks! Best regards, Vladimir Ivanov From david.r.chase at oracle.com Wed Jan 15 07:44:54 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 15 Jan 2014 10:44:54 -0500 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D6A9B8.2040906@oracle.com> References: <52D6A9B8.2040906@oracle.com> Message-ID: <40D7D8F4-7909-46F5-B4FD-9481E8889F47@oracle.com> On 2014-01-15, at 10:31 AM, Vladimir Ivanov wrote: > The fix is targeted for 8. Will be also integrated into 9. > > Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, > nashorn, jruby. Vladimir, Did you test also on defmeth, or has that been incorporated into one of the other test suites? David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140115/1581be6d/signature.asc From vladimir.x.ivanov at oracle.com Wed Jan 15 08:09:27 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Jan 2014 20:09:27 +0400 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <40D7D8F4-7909-46F5-B4FD-9481E8889F47@oracle.com> References: <52D6A9B8.2040906@oracle.com> <40D7D8F4-7909-46F5-B4FD-9481E8889F47@oracle.com> Message-ID: <52D6B2B7.8030004@oracle.com> David, thanks for looking at the fix. Good suggestion. Just ran tests on default methods - all pass. Best regards, Vladimir Ivanov On 1/15/14 7:44 PM, David Chase wrote: > > On 2014-01-15, at 10:31 AM, Vladimir Ivanov wrote: >> The fix is targeted for 8. Will be also integrated into 9. >> >> Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, >> nashorn, jruby. > > > Vladimir, > > Did you test also on defmeth, or has that been incorporated into one of the other test suites? > > David > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From christian.thalinger at oracle.com Wed Jan 15 09:51:09 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Jan 2014 09:51:09 -0800 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D6A9B8.2040906@oracle.com> References: <52D6A9B8.2040906@oracle.com> Message-ID: <0DA570E9-814A-44B5-8CDA-6F7C9A92B423@oracle.com> [I?m resending something I sent earlier today to Vladimir directly.] On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8031502 > > InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm > when invoking a method from Object declared in an interface. > > The problem is the following: > (1) java.lang.CharSequence interface declares abstract method "String > toString()"; > > (2) after 8014013 fix, VM resolves > CharSequence::toString()/invokeInterface to > CharSequence::toString()/invokeVirtual; Without having looked at the changes of 8014013, why did the invoke type change? Is it an optimization that was added? > > (3) during LambdaForm compilation, CharSequence is considered > statically invocable (see > InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for > CharSequence::toString() is issued, which is wrong (invokevirtual throws > ICCE if it references an interface); > > The fix is straightforward: during LambdaForm compilation, switch back > from invokevirtual to invokeinterface instruction when invoking a method > on an interface. I find this risky. Right now MemberName is only used in a couple places in java.lang.invoke but in the future it might be used for other things (e.g. java.lang.reflect). The information MemberName contains should be correct and usable without changing. Otherwise all users have to patch the information the same way as you do in your patch. I would like to see the VM passing correct information (whatever the definition of correct is here). > > The fix is targeted for 8. Will be also integrated into 9. > > Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, > nashorn, jruby. > > Thanks! > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From vladimir.x.ivanov at oracle.com Wed Jan 15 11:41:09 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Jan 2014 23:41:09 +0400 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <0DA570E9-814A-44B5-8CDA-6F7C9A92B423@oracle.com> References: <52D6A9B8.2040906@oracle.com> <0DA570E9-814A-44B5-8CDA-6F7C9A92B423@oracle.com> Message-ID: <52D6E455.4050607@oracle.com> Chris, Thanks for looking into this. See my answers inline. Best regards, Vladimir Ivanov On 1/15/14 9:51 PM, Christian Thalinger wrote: > [I?m resending something I sent earlier today to Vladimir directly.] > > On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8031502 >> >> InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm >> when invoking a method from Object declared in an interface. >> >> The problem is the following: >> (1) java.lang.CharSequence interface declares abstract method "String >> toString()"; >> >> (2) after 8014013 fix, VM resolves >> CharSequence::toString()/invokeInterface to >> CharSequence::toString()/invokeVirtual; > > Without having looked at the changes of 8014013, why did the invoke type change? Is it an optimization that was added? > After 8014013, LinkResolver::resolve_interface_call returns virtual (_call_kind = CallInfo::vtable_call), instead of interface method and MethodHandles::init_method_MemberName uses it as is (without any fine tuning, which was done before). It's caused by the following: - LinkResolver::linktime_resolve_interface_method returns CharSequence::toString method, but it has vtable index, instead of itable index; - LinkResolver::runtime_resolve_interface_method looks at resolved method and sets _call_kind to vtable_call, since resolved method doesn't have itable index. - then MethodHandles::init_method_MemberName looks at CallInfo passed in and sets the reference kind flag to JVM_REF_invokeVirtual. That's how the conversion from invokeInterface to invokeVirtual occurs. I did a quick debugging session with pre-8014013 hotspot to check how it worked before, but don't remember all the details now. >> >> (3) during LambdaForm compilation, CharSequence is considered >> statically invocable (see >> InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for >> CharSequence::toString() is issued, which is wrong (invokevirtual throws >> ICCE if it references an interface); >> >> The fix is straightforward: during LambdaForm compilation, switch back >> from invokevirtual to invokeinterface instruction when invoking a method >> on an interface. > > I find this risky. Right now MemberName is only used in a couple places in java.lang.invoke but in the future it might be used for other things (e.g. java.lang.reflect). The information MemberName contains should be correct and usable without changing. Otherwise all users have to patch the information the same way as you do in your patch. > > I would like to see the VM passing correct information (whatever the definition of correct is here). > It's an interesting question what kind of correctness is required for MemberName and I don't know the answer. Looking through the code, I got an impression MemberName isn't designed to provide information to be used "as is" for bytecode generation, because, at least: - MemberName::referenceKindIsConsistent already expects (clazz.isInterface() && refKind == REF_invokeVirtual && isObjectPublicMethod()) case; - InvokeBytecodeGenerator::emitStaticInvoke already has a special case for REF_invokeSpecial referenceKind, converting it to REF_invokeVirtual; Best regards, Vladimir Ivanov From christian.thalinger at oracle.com Wed Jan 15 17:41:13 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Jan 2014 17:41:13 -0800 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <52D556EE.8000307@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> <52D556EE.8000307@oracle.com> Message-ID: <410AB800-645F-4BBE-A95A-77ED239CBF89@oracle.com> src/share/vm/opto/type.cpp: ! const TypeAry *tary = _ary->meet(tap->_ary, true /* include_speculative */ /* include_speculative */)->is_ary(); Double comment. Seeing all these: true /* include_speculative */ I wonder if we should add new methods for these. It would make it easier to see the users of the speculative versions. On Jan 14, 2014, at 7:25 AM, Vladimir Kozlov wrote: > Looks good to me. > > On 1/14/14 1:13 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8027422/webrev.02/ >> >> I fixed the verification code at the end of Compile::remove_speculative_types(), used this format everywhere: >> t->filter(_type, true /* include_speculative */); >> >> renamed NodeHash::check_speculative_types() to NodeHash::check_no_speculative_types(), added PhaseIterGVN::check_no_speculative_types() and now call it from the verification code of Compile::remove_speculative_types(). >> >> Do I need more than 1 review for this? > > Yes, you need an other review for this change. Ask Chris or Igor. > > Thanks, > Vladimir > >> >> Roland. >> >> >> On Jan 13, 2014, at 11:03 AM, Roland Westrelin wrote: >> >>>> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. >>> >>> Thanks for catching that. >>> Is: >>> // Verify that after the IGVN is over no speculative type has resurfaced >>> good as a comment? >>> >>>> Passing 'true' parameter is not very informative. You can use local variable: >>>> >>>> bool include_speculative = true; >>>> t->filter(_type, include_speculative); >>>> >>>> An other way to make code more informative is to add a comment to parameter: >>>> >>>> t->filter(_type, true /* include_speculative */); >>>> >>>> Either way is fine. >>> >>> Will do one of these. >>> >>> Thanks, >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/10/14 1:46 AM, Roland Westrelin wrote: >>>>> Hi Vladimir, >>>>> >>>>> Here is a new webrev for this: >>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >>>>> >>>>> I fixed the issues you mentioned in your review. >>>>> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >>>>> I also added a verification method: >>>>> NodeHash::check_speculative_types() >>>>> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >>>>> >>>>> Roland. >>>>> >>>>> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>>>>> Thanks for reviewing this, Vladimir. >>>>>>> >>>>>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>>>>> >>>>>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>>>>> >>>>>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>>>>> >>>>>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>>>>> >>>>>>> You?re right. It probably should. >>>>>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>>>>> >>>>>> Right, passing 'true' will work in all cases then. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>>>>> >>>>>>> Sure. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>>>>> higher_equal() >>>>>>>>> meet() >>>>>>>>> join() >>>>>>>>> filter() >>>>>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>>>>> >>>>>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>> >>>>> >>> >> From christian.thalinger at oracle.com Wed Jan 15 18:37:04 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Jan 2014 18:37:04 -0800 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> Message-ID: All these print_data_on changes are a pain: ! virtual void print_data_on(outputStream* st, const char* extra) const { I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? src/share/vm/oops/methodData.cpp: + case Bytecodes::_invokestatic: + return UseTypeSpeculation; + } + return false; Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). int empty_bc_count = 0; // number of bytecodes lacking data + bool has_spec_bc = false; That name is hard to understand for people new to the code. At least the first ugly name has a comment. + DataLayout* MethodData::next_extra(DataLayout* dp) { + int nb_cells = 0; + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { + nb_cells = BitData::static_cell_count(); + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { + nb_cells = SpeculativeTrapData::static_cell_count(); + } else { + fatal(err_msg("unexpected tag %d", dp->tag())); + } It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. src/share/vm/opto/compile.cpp: ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { Can you factor this to a local variable as you do later: + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; if ((per_bc_reason == Deoptimization::Reason_none ! || md->has_trap_at(bci, m, reason) != 0) ? src/share/vm/runtime/globals.hpp: + product(intx, PerMethodSpecTrapLimit, 5000, \ + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ + product(intx, SpecTrapLimitExtraEntries, 3, \ + "Extra method data trap entries for speculation") \ Do we need these new flags to be product flags? src/share/vm/ci/ciMethodData.cpp: ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { ! st->print_cr("Parametertypes"); ! st->print_cr("ciParameterTypesData?); Typo replaced with a typo :-) On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8031752/webrev.00/ > > When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). > > If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. > > When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. > > With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. > > This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. > > I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. > > I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. > > Roland. > > From christian.thalinger at oracle.com Wed Jan 15 18:49:30 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Jan 2014 18:49:30 -0800 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D6E455.4050607@oracle.com> References: <52D6A9B8.2040906@oracle.com> <0DA570E9-814A-44B5-8CDA-6F7C9A92B423@oracle.com> <52D6E455.4050607@oracle.com> Message-ID: On Jan 15, 2014, at 11:41 AM, Vladimir Ivanov wrote: > Chris, > > Thanks for looking into this. See my answers inline. > > Best regards, > Vladimir Ivanov > > On 1/15/14 9:51 PM, Christian Thalinger wrote: >> [I?m resending something I sent earlier today to Vladimir directly.] >> >> On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8031502 >>> >>> InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm >>> when invoking a method from Object declared in an interface. >>> >>> The problem is the following: >>> (1) java.lang.CharSequence interface declares abstract method "String >>> toString()"; >>> >>> (2) after 8014013 fix, VM resolves >>> CharSequence::toString()/invokeInterface to >>> CharSequence::toString()/invokeVirtual; >> >> Without having looked at the changes of 8014013, why did the invoke type change? Is it an optimization that was added? >> > > After 8014013, LinkResolver::resolve_interface_call returns virtual > (_call_kind = CallInfo::vtable_call), instead of interface method and > MethodHandles::init_method_MemberName uses it as is (without any fine > tuning, which was done before). > > It's caused by the following: > - LinkResolver::linktime_resolve_interface_method returns > CharSequence::toString method, but it has vtable index, instead of > itable index; > > - LinkResolver::runtime_resolve_interface_method looks at resolved > method and sets _call_kind to vtable_call, since resolved method doesn't > have itable index. > > - then MethodHandles::init_method_MemberName looks at CallInfo passed > in and sets the reference kind flag to JVM_REF_invokeVirtual. > > That's how the conversion from invokeInterface to invokeVirtual occurs. > > I did a quick debugging session with pre-8014013 hotspot to check how it > worked before, but don't remember all the details now. > >>> >>> (3) during LambdaForm compilation, CharSequence is considered >>> statically invocable (see >>> InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for >>> CharSequence::toString() is issued, which is wrong (invokevirtual throws >>> ICCE if it references an interface); >>> >>> The fix is straightforward: during LambdaForm compilation, switch back >>> from invokevirtual to invokeinterface instruction when invoking a method >>> on an interface. >> >> I find this risky. Right now MemberName is only used in a couple places in java.lang.invoke but in the future it might be used for other things (e.g. java.lang.reflect). The information MemberName contains should be correct and usable without changing. Otherwise all users have to patch the information the same way as you do in your patch. >> >> I would like to see the VM passing correct information (whatever the definition of correct is here). >> > > It's an interesting question what kind of correctness is required for > MemberName and I don't know the answer. Looking through the code, I got > an impression MemberName isn't designed to provide information to be > used "as is" for bytecode generation, because, at least: > - MemberName::referenceKindIsConsistent already expects > (clazz.isInterface() && refKind == REF_invokeVirtual && > isObjectPublicMethod()) case; > > - InvokeBytecodeGenerator::emitStaticInvoke already has a special > case for REF_invokeSpecial referenceKind, converting it to > REF_invokeVirtual; John would know the answer. Given this change should go into JDK 8 I think we should push for now. If we can come up with a better way to handle these situations we can push another change for 9 or 8u20. > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From vladimir.kozlov at oracle.com Thu Jan 16 00:11:09 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jan 2014 00:11:09 -0800 Subject: RFR(L) 8034198: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <52D690E6.50908@oracle.com> References: <52D53871.40606@oracle.com> <20140114140353.GB9323@rbackman> <52D68C79.6070800@oracle.com> <52D690E6.50908@oracle.com> Message-ID: <52D7941D.2050801@oracle.com> Niclas, Changes are good. I have few notes. Vectors are separate from floats. Please, rename the method to is_float_or_vector(). class Pressure. Field names start with '_' to separate then from variables. Why you don't like to path pointer to liveout? It helped only in few places but code in interfere_with_live() become complicated (IndexSet& liveout and then elements(&liveout)). Thanks, Vladimir On 1/15/14 5:45 AM, Niclas Adlertz wrote: > Hi again, > > I found a commented section that I forgot to remove in chaitin.hpp: > > // stores the first low-to-high transition (starting from the top of block) > //uint final_high_pressure_index; > > Updated the webrev: > http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev02/ > > On 2014-01-15 14:26, Niclas Adlertz wrote: >> Hi Rickard, >> >> Thank you for your comments. >> >> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev01/ >> >> Kind Regards, >> Niclas Adlertz >> >> On 2014-01-14 15:03, Rickard B?ckman wrote: >>> Just a few comments on the C++ parts. I haven't verified that the logic >>> is still the same. >>> >>> 1) It seems like there are a couple of functions that could be created >>> in the new Pressure class to avoid code duplication. One example is the >>> check_for_high_pressure_block method. >>> >>> 2) All places that checks lrg._is_float also check lrg._is_vector. That >>> check could be made into a boolean method on the LRG instead. The same >>> for is_UP() & mask_size(). >>> >>> 3) To make code more generic the int_pressure and float_pressure >>> instances could be passed the INTPRESSURE and FLOATPRESSURE and keep >>> those as instance variables. >>> >>> Good work. >>> >>> /R >>> >>> On 01/14, Niclas Adlertz wrote: >>>> Hi all, >>>> >>>> This is a first step to clean up the register allocator in C2. In this change we have divided the very long method >>>> build_ifg_physical() into many smaller ones, making it easier to see the steps when building the IFG (and computing >>>> the block pressure). >>>> We have also cleaned up old comments and improved old code, both by better naming and by simplifying expressions. >>>> I personally think that the easiest way to review this change is to have the old and new ifg.cpp side by side, and >>>> start from build_ifg_physical(). >>>> The next step is to create a new class for these methods, isolating them and removing them from PhaseChaitin. >>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ >>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 >>>> >>>> Kind Regards, >>>> Niclas Adlertz >> > From roland.westrelin at oracle.com Thu Jan 16 01:05:04 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 16 Jan 2014 10:05:04 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <410AB800-645F-4BBE-A95A-77ED239CBF89@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> <52D556EE.8000307@oracle.com> <410AB800-645F-4BBE-A95A-77ED239CBF89@oracle.com> Message-ID: <8788446E-73DF-4BCA-B0C2-CBD7C94A83BB@oracle.com> Thanks for reviewing this, Christian. > Seeing all these: > > true /* include_speculative */ > > I wonder if we should add new methods for these. It would make it easier to see the users of the speculative versions. A new meet_speculative() method? I?m ok with it. Vladimir, what do you think? Roland. > > On Jan 14, 2014, at 7:25 AM, Vladimir Kozlov wrote: > >> Looks good to me. >> >> On 1/14/14 1:13 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8027422/webrev.02/ >>> >>> I fixed the verification code at the end of Compile::remove_speculative_types(), used this format everywhere: >>> t->filter(_type, true /* include_speculative */); >>> >>> renamed NodeHash::check_speculative_types() to NodeHash::check_no_speculative_types(), added PhaseIterGVN::check_no_speculative_types() and now call it from the verification code of Compile::remove_speculative_types(). >>> >>> Do I need more than 1 review for this? >> >> Yes, you need an other review for this change. Ask Chris or Igor. >> >> Thanks, >> Vladimir >> >>> >>> Roland. >>> >>> >>> On Jan 13, 2014, at 11:03 AM, Roland Westrelin wrote: >>> >>>>> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. >>>> >>>> Thanks for catching that. >>>> Is: >>>> // Verify that after the IGVN is over no speculative type has resurfaced >>>> good as a comment? >>>> >>>>> Passing 'true' parameter is not very informative. You can use local variable: >>>>> >>>>> bool include_speculative = true; >>>>> t->filter(_type, include_speculative); >>>>> >>>>> An other way to make code more informative is to add a comment to parameter: >>>>> >>>>> t->filter(_type, true /* include_speculative */); >>>>> >>>>> Either way is fine. >>>> >>>> Will do one of these. >>>> >>>> Thanks, >>>> Roland. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/10/14 1:46 AM, Roland Westrelin wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> Here is a new webrev for this: >>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >>>>>> >>>>>> I fixed the issues you mentioned in your review. >>>>>> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >>>>>> I also added a verification method: >>>>>> NodeHash::check_speculative_types() >>>>>> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >>>>>> >>>>>> Roland. >>>>>> >>>>>> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>>>>>> Thanks for reviewing this, Vladimir. >>>>>>>> >>>>>>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>>>>>> >>>>>>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>>>>>> >>>>>>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>>>>>> >>>>>>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>>>>>> >>>>>>>> You?re right. It probably should. >>>>>>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>>>>>> >>>>>>> Right, passing 'true' will work in all cases then. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>>>>>> >>>>>>>> Sure. >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>>>>>> higher_equal() >>>>>>>>>> meet() >>>>>>>>>> join() >>>>>>>>>> filter() >>>>>>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>>>>>> >>>>>>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From vladimir.kozlov at oracle.com Thu Jan 16 01:11:21 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jan 2014 01:11:21 -0800 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <8788446E-73DF-4BCA-B0C2-CBD7C94A83BB@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> <52D556EE.8000307@oracle.com> <410AB800-645F-4BBE-A95A-77ED239CBF89@oracle.com> <8788446E-73DF-4BCA-B0C2-CBD7C94A83BB@oracle.com> Message-ID: <52D7A239.60806@oracle.com> On 1/16/14 1:05 AM, Roland Westrelin wrote: > > Thanks for reviewing this, Christian. > >> Seeing all these: >> >> true /* include_speculative */ >> >> I wonder if we should add new methods for these. It would make it easier to see the users of the speculative versions. > > A new meet_speculative() method? > I?m ok with it. Vladimir, what do you think? I was going to suggest it too but then you need additional methods for other methods: join(), higher_equal(), filter(). So I am fine with it if you do all of them. Vladimir > > Roland. > >> >> On Jan 14, 2014, at 7:25 AM, Vladimir Kozlov wrote: >> >>> Looks good to me. >>> >>> On 1/14/14 1:13 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~roland/8027422/webrev.02/ >>>> >>>> I fixed the verification code at the end of Compile::remove_speculative_types(), used this format everywhere: >>>> t->filter(_type, true /* include_speculative */); >>>> >>>> renamed NodeHash::check_speculative_types() to NodeHash::check_no_speculative_types(), added PhaseIterGVN::check_no_speculative_types() and now call it from the verification code of Compile::remove_speculative_types(). >>>> >>>> Do I need more than 1 review for this? >>> >>> Yes, you need an other review for this change. Ask Chris or Igor. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Roland. >>>> >>>> >>>> On Jan 13, 2014, at 11:03 AM, Roland Westrelin wrote: >>>> >>>>>> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. >>>>> >>>>> Thanks for catching that. >>>>> Is: >>>>> // Verify that after the IGVN is over no speculative type has resurfaced >>>>> good as a comment? >>>>> >>>>>> Passing 'true' parameter is not very informative. You can use local variable: >>>>>> >>>>>> bool include_speculative = true; >>>>>> t->filter(_type, include_speculative); >>>>>> >>>>>> An other way to make code more informative is to add a comment to parameter: >>>>>> >>>>>> t->filter(_type, true /* include_speculative */); >>>>>> >>>>>> Either way is fine. >>>>> >>>>> Will do one of these. >>>>> >>>>> Thanks, >>>>> Roland. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 1/10/14 1:46 AM, Roland Westrelin wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> Here is a new webrev for this: >>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >>>>>>> >>>>>>> I fixed the issues you mentioned in your review. >>>>>>> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >>>>>>> I also added a verification method: >>>>>>> NodeHash::check_speculative_types() >>>>>>> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>>>>>>> Thanks for reviewing this, Vladimir. >>>>>>>>> >>>>>>>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>>>>>>> >>>>>>>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>>>>>>> >>>>>>>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>>>>>>> >>>>>>>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>>>>>>> >>>>>>>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>>>>>>> >>>>>>>>> You?re right. It probably should. >>>>>>>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>>>>>>> >>>>>>>> Right, passing 'true' will work in all cases then. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>>>>>>> >>>>>>>>> Sure. >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>>>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>>>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>>>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>>>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>>>>>>> higher_equal() >>>>>>>>>>> meet() >>>>>>>>>>> join() >>>>>>>>>>> filter() >>>>>>>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>>>>>>> >>>>>>>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>>>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> > From roland.westrelin at oracle.com Thu Jan 16 01:13:44 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 16 Jan 2014 10:13:44 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <52D7A239.60806@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> <52D556EE.8000307@oracle.com> <410AB800-645F-4BBE-A95A-77ED239CBF89@oracle.com> <8788446E-73DF-4BCA-B0C2-CBD7C94A83BB@oracle.com> <52D7A239.60806@oracle.com> Message-ID: <1453984A-0465-429C-8E01-8E41011CF88C@oracle.com> > I was going to suggest it too but then you need additional methods for other methods: join(), higher_equal(), filter(). So I am fine with it if you do all of them. Thanks, Vladimir. I?ll send an updated webrev. Roland. From vladimir.x.ivanov at oracle.com Thu Jan 16 01:37:43 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 16 Jan 2014 13:37:43 +0400 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D79B00.5080804@gmx.org> References: <52D6A9B8.2040906@oracle.com> <52D79B00.5080804@gmx.org> Message-ID: <52D7A867.8070008@oracle.com> Jochen, The test provokes the bug, since it sets compilation threshold to 0: -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=0 Best regards, Vladimir Ivanov On 1/16/14 12:40 PM, Jochen Theodorou wrote: > Hi, > > since I am indirectly the reporter of this bug I have one remark for the > test. The error happens only for compiled lambda forms. The given test > does imho not use a compiled lambda form. In other words, afaik the test > would pass without the fix. As such it would be useless as regression test. > > Am 15.01.2014 16:31, schrieb Vladimir Ivanov: >> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8031502 >> >> InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm >> when invoking a method from Object declared in an interface. >> >> The problem is the following: >> (1) java.lang.CharSequence interface declares abstract method "String >> toString()"; >> >> (2) after 8014013 fix, VM resolves >> CharSequence::toString()/invokeInterface to >> CharSequence::toString()/invokeVirtual; >> >> (3) during LambdaForm compilation, CharSequence is considered >> statically invocable (see >> InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for >> CharSequence::toString() is issued, which is wrong (invokevirtual throws >> ICCE if it references an interface); >> >> The fix is straightforward: during LambdaForm compilation, switch back >> from invokevirtual to invokeinterface instruction when invoking a method >> on an interface. >> >> The fix is targeted for 8. Will be also integrated into 9. >> >> Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, >> nashorn, jruby. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > From blackdrag at gmx.org Thu Jan 16 00:40:32 2014 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 16 Jan 2014 09:40:32 +0100 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D6A9B8.2040906@oracle.com> References: <52D6A9B8.2040906@oracle.com> Message-ID: <52D79B00.5080804@gmx.org> Hi, since I am indirectly the reporter of this bug I have one remark for the test. The error happens only for compiled lambda forms. The given test does imho not use a compiled lambda form. In other words, afaik the test would pass without the fix. As such it would be useless as regression test. Am 15.01.2014 16:31, schrieb Vladimir Ivanov: > http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8031502 > > InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm > when invoking a method from Object declared in an interface. > > The problem is the following: > (1) java.lang.CharSequence interface declares abstract method "String > toString()"; > > (2) after 8014013 fix, VM resolves > CharSequence::toString()/invokeInterface to > CharSequence::toString()/invokeVirtual; > > (3) during LambdaForm compilation, CharSequence is considered > statically invocable (see > InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for > CharSequence::toString() is issued, which is wrong (invokevirtual throws > ICCE if it references an interface); > > The fix is straightforward: during LambdaForm compilation, switch back > from invokevirtual to invokeinterface instruction when invoking a method > on an interface. > > The fix is targeted for 8. Will be also integrated into 9. > > Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, > nashorn, jruby. > > Thanks! > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From roland.westrelin at oracle.com Thu Jan 16 08:32:55 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 16 Jan 2014 17:32:55 +0100 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> Message-ID: <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> Thanks for reviewing this, Chris. Here is a new webrev: http://cr.openjdk.java.net/~roland/8031752/webrev.01/ And comments below: > All these print_data_on changes are a pain: > > ! virtual void print_data_on(outputStream* st, const char* extra) const { > > I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? I want the speculative traps to be listed together with the byte code they affect. Diagnosing a missed optimization is much easier that way. Here is an example output: 6 ldc_w TestTrapSpeculate$B 9 if_acmpne 19 64 bci: 9 BranchData trap(class_check recompiled) trap/ TestTrapSpeculate::m2(class_check recompiled) trap/ TestTrapSpeculate::m1(class_check recompiled) not taken(10) 12 fast_aload_0 But the speculative traps are not stored with the ProfileData for each byte code. So I need to pass something to each ProfileData::print_data_on() that can be used to print the speculative traps. I decided to pass a formatted string with the trap stuff. Which is then passed to ProfileData::print_shared() where the per byte code line is printed. > src/share/vm/oops/methodData.cpp: > > + case Bytecodes::_invokestatic: > + return UseTypeSpeculation; > + } > + return false; > > Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). Ok. > > int empty_bc_count = 0; // number of bytecodes lacking data > + bool has_spec_bc = false; > > That name is hard to understand for people new to the code. At least the first ugly name has a comment. Would needs_speculative_traps be better? > > + DataLayout* MethodData::next_extra(DataLayout* dp) { > + int nb_cells = 0; > + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { > + nb_cells = BitData::static_cell_count(); > + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { > + nb_cells = SpeculativeTrapData::static_cell_count(); > + } else { > + fatal(err_msg("unexpected tag %d", dp->tag())); > + } > > It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: > > assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); > > is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. Ok. So I tried to use switches when iterating over the extra data everywhere. The problem is that break, breaks out of the switch but not out of the loop anymore. The new MethodData::next_extra() doesn?t know how to move past a arg_info_data_tag because it?s a static method. It?s a static method because it?s used by ciMethodData as well. So I need to break out of the loop before calling the last MethodData::next_extra(). Anyway, I refactored the code so that the loops are in their own methods and then I can return from them to jump out of the switch and loop. > > src/share/vm/opto/compile.cpp: > > ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { > > Can you factor this to a local variable as you do later: > > + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; > if ((per_bc_reason == Deoptimization::Reason_none > ! || md->has_trap_at(bci, m, reason) != 0) > > ? > Ok. > src/share/vm/runtime/globals.hpp: > > + product(intx, PerMethodSpecTrapLimit, 5000, \ > + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ > > + product(intx, SpecTrapLimitExtraEntries, 3, \ > + "Extra method data trap entries for speculation") \ > > Do we need these new flags to be product flags? At this point, it?s unclear whether those values are going to be good enough so I think we need to be able to adjust the parameters in benchmark runs. > src/share/vm/ci/ciMethodData.cpp: > > ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { > ! st->print_cr("Parametertypes"); > ! st->print_cr("ciParameterTypesData?); > > Typo replaced with a typo :-) Indeed. Roland. > > On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ >> >> When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). >> >> If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. >> >> When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. >> >> With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. >> >> This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. >> >> I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. >> >> I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. >> >> Roland. >> >> > From christian.thalinger at oracle.com Thu Jan 16 11:53:14 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Jan 2014 11:53:14 -0800 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> Message-ID: <0C905816-F507-4D82-AB02-DE18A4A77560@oracle.com> On Jan 16, 2014, at 8:32 AM, Roland Westrelin wrote: > Thanks for reviewing this, Chris. > > Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8031752/webrev.01/ ! bool MethodData::speculative_trap_bytecode(Bytecodes::Code code) { It would be good if this method would have an ?is? in the name. Something like is_speculative_trap_bytecode or is_bytecode_speculative_trap. > > And comments below: > >> All these print_data_on changes are a pain: >> >> ! virtual void print_data_on(outputStream* st, const char* extra) const { >> >> I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? > > I want the speculative traps to be listed together with the byte code they affect. Diagnosing a missed optimization is much easier that way. Here is an example output: > > 6 ldc_w TestTrapSpeculate$B > 9 if_acmpne 19 > 64 bci: 9 BranchData trap(class_check recompiled) trap/ TestTrapSpeculate::m2(class_check recompiled) trap/ TestTrapSpeculate::m1(class_check recompiled) > not taken(10) > 12 fast_aload_0 > > But the speculative traps are not stored with the ProfileData for each byte code. So I need to pass something to each ProfileData::print_data_on() that can be used to print the speculative traps. I decided to pass a formatted string with the trap stuff. Which is then passed to ProfileData::print_shared() where the per byte code line is printed. Ok. Oh, one other thing I forgot to mention: should we have a default value for extra? ! virtual void print_data_on(outputStream* st, const char* extra = NULL) const { > >> src/share/vm/oops/methodData.cpp: >> >> + case Bytecodes::_invokestatic: >> + return UseTypeSpeculation; >> + } >> + return false; >> >> Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). > > Ok. + default: + return false; + } + return false; + } Isn?t the compiler warning about unreached code here? > >> >> int empty_bc_count = 0; // number of bytecodes lacking data >> + bool has_spec_bc = false; >> >> That name is hard to understand for people new to the code. At least the first ugly name has a comment. > > Would needs_speculative_traps be better? Yes, thanks. > >> >> + DataLayout* MethodData::next_extra(DataLayout* dp) { >> + int nb_cells = 0; >> + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { >> + nb_cells = BitData::static_cell_count(); >> + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { >> + nb_cells = SpeculativeTrapData::static_cell_count(); >> + } else { >> + fatal(err_msg("unexpected tag %d", dp->tag())); >> + } >> >> It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: >> >> assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); >> >> is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. > > Ok. So I tried to use switches when iterating over the extra data everywhere. The problem is that break, breaks out of the switch but not out of the loop anymore. Can?t you use continue in that case? Oh, I just saw you did. > The new MethodData::next_extra() doesn?t know how to move past a arg_info_data_tag because it?s a static method. It?s a static method because it?s used by ciMethodData as well. So I need to break out of the loop before calling the last MethodData::next_extra(). Anyway, I refactored the code so that the loops are in their own methods and then I can return from them to jump out of the switch and loop. Thanks. Looks much better now. > >> >> src/share/vm/opto/compile.cpp: >> >> ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { >> >> Can you factor this to a local variable as you do later: >> >> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >> if ((per_bc_reason == Deoptimization::Reason_none >> ! || md->has_trap_at(bci, m, reason) != 0) >> >> ? >> > > Ok. > >> src/share/vm/runtime/globals.hpp: >> >> + product(intx, PerMethodSpecTrapLimit, 5000, \ >> + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ >> >> + product(intx, SpecTrapLimitExtraEntries, 3, \ >> + "Extra method data trap entries for speculation") \ >> >> Do we need these new flags to be product flags? > > At this point, it?s unclear whether those values are going to be good enough so I think we need to be able to adjust the parameters in benchmark runs. I have mentioned this in a previous review but we need something like diagnostic flags but for non-diagnostic ones. Vladimir and I just talked to Mikael about this and we should use experimental for such flags; the flag is used for experiments (as you say for benchmark runs or similar things) and can either go away or be made a develop flag in the future. > >> src/share/vm/ci/ciMethodData.cpp: >> >> ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { >> ! st->print_cr("Parametertypes"); >> ! st->print_cr("ciParameterTypesData?); >> >> Typo replaced with a typo :-) > > Indeed. > > Roland. > >> >> On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: >> >>> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ >>> >>> When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). >>> >>> If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. >>> >>> When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. >>> >>> With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. >>> >>> This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. >>> >>> I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. >>> >>> I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. >>> >>> Roland. From jon.masamitsu at oracle.com Thu Jan 16 12:51:22 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 16 Jan 2014 12:51:22 -0800 Subject: Request for review (s) - 8031290: Adjust call to getisax() for additional words returned Message-ID: <52D8464A.8090009@oracle.com> 8031290: Adjust call to getisax() for additional words returned Accept the 2nd word returned by getisax() on Solaris and use its contents to recognize AV2_SPARC_SPARC5 instructions. http://cr.openjdk.java.net/~jmasa/8031290/webrev.00/ Should this integrate through hotspot-compiler? Thanks to Vladimir for most of this fix. Jon From vladimir.kozlov at oracle.com Thu Jan 16 13:23:12 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jan 2014 13:23:12 -0800 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> Message-ID: <52D84DC0.7030609@oracle.com> Can you pass method to has_trap_at() and check the reason inside instead of current assert? Thanks, Vladimir On 1/16/14 8:32 AM, Roland Westrelin wrote: > Thanks for reviewing this, Chris. > > Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8031752/webrev.01/ > > And comments below: > >> All these print_data_on changes are a pain: >> >> ! virtual void print_data_on(outputStream* st, const char* extra) const { >> >> I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? > > I want the speculative traps to be listed together with the byte code they affect. Diagnosing a missed optimization is much easier that way. Here is an example output: > > 6 ldc_w TestTrapSpeculate$B > 9 if_acmpne 19 > 64 bci: 9 BranchData trap(class_check recompiled) trap/ TestTrapSpeculate::m2(class_check recompiled) trap/ TestTrapSpeculate::m1(class_check recompiled) > not taken(10) > 12 fast_aload_0 > > But the speculative traps are not stored with the ProfileData for each byte code. So I need to pass something to each ProfileData::print_data_on() that can be used to print the speculative traps. I decided to pass a formatted string with the trap stuff. Which is then passed to ProfileData::print_shared() where the per byte code line is printed. > >> src/share/vm/oops/methodData.cpp: >> >> + case Bytecodes::_invokestatic: >> + return UseTypeSpeculation; >> + } >> + return false; >> >> Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). > > Ok. > >> >> int empty_bc_count = 0; // number of bytecodes lacking data >> + bool has_spec_bc = false; >> >> That name is hard to understand for people new to the code. At least the first ugly name has a comment. > > Would needs_speculative_traps be better? > >> >> + DataLayout* MethodData::next_extra(DataLayout* dp) { >> + int nb_cells = 0; >> + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { >> + nb_cells = BitData::static_cell_count(); >> + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { >> + nb_cells = SpeculativeTrapData::static_cell_count(); >> + } else { >> + fatal(err_msg("unexpected tag %d", dp->tag())); >> + } >> >> It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: >> >> assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); >> >> is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. > > Ok. So I tried to use switches when iterating over the extra data everywhere. The problem is that break, breaks out of the switch but not out of the loop anymore. The new MethodData::next_extra() doesn?t know how to move past a arg_info_data_tag because it?s a static method. It?s a static method because it?s used by ciMethodData as well. So I need to break out of the loop before calling the last MethodData::next_extra(). Anyway, I refactored the code so that the loops are in their own methods and then I can return from them to jump out of the switch and loop. > >> >> src/share/vm/opto/compile.cpp: >> >> ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { >> >> Can you factor this to a local variable as you do later: >> >> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >> if ((per_bc_reason == Deoptimization::Reason_none >> ! || md->has_trap_at(bci, m, reason) != 0) >> >> ? >> > > Ok. > >> src/share/vm/runtime/globals.hpp: >> >> + product(intx, PerMethodSpecTrapLimit, 5000, \ >> + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ >> >> + product(intx, SpecTrapLimitExtraEntries, 3, \ >> + "Extra method data trap entries for speculation") \ >> >> Do we need these new flags to be product flags? > > At this point, it?s unclear whether those values are going to be good enough so I think we need to be able to adjust the parameters in benchmark runs. > >> src/share/vm/ci/ciMethodData.cpp: >> >> ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { >> ! st->print_cr("Parametertypes"); >> ! st->print_cr("ciParameterTypesData?); >> >> Typo replaced with a typo :-) > > Indeed. > > Roland. > >> >> On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: >> >>> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ >>> >>> When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). >>> >>> If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. >>> >>> When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. >>> >>> With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. >>> >>> This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. >>> >>> I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. >>> >>> I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. >>> >>> Roland. >>> >>> >> > From vladimir.kozlov at oracle.com Thu Jan 16 13:38:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jan 2014 13:38:14 -0800 Subject: Request for review (s) - 8031290: Adjust call to getisax() for additional words returned In-Reply-To: <52D8464A.8090009@oracle.com> References: <52D8464A.8090009@oracle.com> Message-ID: <52D85146.2040904@oracle.com> Jon, In vm_version_solaris_sparc.cpp you should change print_cr() to print() in next line: tty->print_cr("getisax(2) returned: " PTR32_FORMAT, av); You can push into any repo, it is not time critical. Thanks, Vladimir On 1/16/14 12:51 PM, Jon Masamitsu wrote: > 8031290: Adjust call to getisax() for additional words returned > > Accept the 2nd word returned by getisax() on Solaris and use > its contents to recognize AV2_SPARC_SPARC5 instructions. > > http://cr.openjdk.java.net/~jmasa/8031290/webrev.00/ > > Should this integrate through hotspot-compiler? > > Thanks to Vladimir for most of this fix. > > Jon From christian.thalinger at oracle.com Thu Jan 16 13:49:45 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Jan 2014 13:49:45 -0800 Subject: [8] RFR (XXS): 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests Message-ID: <3CB043C7-B7F7-41D9-B5E6-8771CCBC596A@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8022395 http://cr.openjdk.java.net/~twisti/8022395/webrev.00 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests Reviewed-by: C1's instrinsic for java.util.zip.CRC32.update(int b) on x86 destroys the input value b but the register is not marked to be destroyed. This can lead to a wrong value if CRC32.update is inlined. The fix is to mark the LIRItem to be destroyed. This will make C1 to insert a spill move. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140116/9f760cfc/attachment.html From vladimir.kozlov at oracle.com Thu Jan 16 14:13:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jan 2014 14:13:01 -0800 Subject: [8] RFR (XXS): 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests In-Reply-To: <3CB043C7-B7F7-41D9-B5E6-8771CCBC596A@oracle.com> References: <3CB043C7-B7F7-41D9-B5E6-8771CCBC596A@oracle.com> Message-ID: <52D8596D.7050303@oracle.com> Looks good. Thanks, Vladimir On 1/16/14 1:49 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8022395 > http://cr.openjdk.java.net/~twisti/8022395/webrev.00 > > 8022395: java.util.zip.ZipException: Not in GZIP format in > JT_JDK/test/java/util/zip/GZIP tests > Reviewed-by: > > C1's instrinsic for java.util.zip.CRC32.update(int b) on x86 destroys > the input value b but the register is not marked to be destroyed. This > can lead to a wrong value if CRC32.update is inlined. > > The fix is to mark the LIRItem to be destroyed. This will make C1 to > insert a spill move. > From igor.veresov at oracle.com Thu Jan 16 15:48:32 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 16 Jan 2014 15:48:32 -0800 Subject: [8] RFR (XXS): 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests In-Reply-To: <3CB043C7-B7F7-41D9-B5E6-8771CCBC596A@oracle.com> References: <3CB043C7-B7F7-41D9-B5E6-8771CCBC596A@oracle.com> Message-ID: <55E9B519-9BD8-49DC-8C96-E3757D4AEAF1@oracle.com> Looks fine. igor On Jan 16, 2014, at 1:49 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8022395 > http://cr.openjdk.java.net/~twisti/8022395/webrev.00 > > 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests > Reviewed-by: > > C1's instrinsic for java.util.zip.CRC32.update(int b) on x86 destroys the input value b but the register is not marked to be destroyed. This can lead to a wrong value if CRC32.update is inlined. > > The fix is to mark the LIRItem to be destroyed. This will make C1 to insert a spill move. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140116/20551d15/attachment-0001.html From christian.thalinger at oracle.com Thu Jan 16 16:25:25 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Jan 2014 16:25:25 -0800 Subject: [8] RFR (XXS): 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests In-Reply-To: <55E9B519-9BD8-49DC-8C96-E3757D4AEAF1@oracle.com> References: <3CB043C7-B7F7-41D9-B5E6-8771CCBC596A@oracle.com> <55E9B519-9BD8-49DC-8C96-E3757D4AEAF1@oracle.com> Message-ID: <2218B036-E041-481A-A8AC-5DE640A29F0E@oracle.com> Thank you, Vladimir and Igor. I?m going to push this to jdk9 too. On Jan 16, 2014, at 3:48 PM, Igor Veresov wrote: > Looks fine. > > igor > > On Jan 16, 2014, at 1:49 PM, Christian Thalinger wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8022395 >> http://cr.openjdk.java.net/~twisti/8022395/webrev.00 >> >> 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests >> Reviewed-by: >> >> C1's instrinsic for java.util.zip.CRC32.update(int b) on x86 destroys the input value b but the register is not marked to be destroyed. This can lead to a wrong value if CRC32.update is inlined. >> >> The fix is to mark the LIRItem to be destroyed. This will make C1 to insert a spill move. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140116/9c3e05f6/attachment.html From yumin.qi at oracle.com Thu Jan 16 22:10:58 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 16 Jan 2014 22:10:58 -0800 Subject: RFR: 6498581: ThreadInterruptTest3 produces wrong output on Windows In-Reply-To: <52D86707.5080500@oracle.com> References: <52D5DDB9.8000700@oracle.com> <52D77A72.2030808@oracle.com> <52D8442D.7010702@oracle.com> <52D84592.3070009@oracle.com> <52D84E19.7000502@oracle.com> <52D86707.5080500@oracle.com> Message-ID: <52D8C972.6050104@oracle.com> Now I got it: //------------------------inline_native_isInterrupted------------------ // private native boolean java.lang.Thread.isInterrupted(boolean ClearInterrupted); bool LibraryCallKit::inline_native_isInterrupted() { // Add a fast path to t.isInterrupted(clear_int): // (t == Thread.current() && (!TLS._osthread._interrupted || !clear_int)) // ? TLS._osthread._interrupted : /*slow path:*/ t.isInterrupted(clear_int) // So, in the common case that the interrupt bit is false, // we avoid making a call into the VM. Even if the interrupt bit // is true, if the clear_int argument is false, we avoid the VM call. // However, if the receiver is not currentThread, we must call the VM, // because there must be some locking done around the operation. // We only go to the fast case code if we pass two guards. // Paths which do not pass are accumulated in the slow_region. this code does not work both before and after the fix then. Maybe we should not go with fast path then. CC to compiler team. Thanks Yumin On 1/16/2014 3:11 PM, David Holmes wrote: > On 17/01/2014 7:24 AM, Yumin Qi wrote: >> Dan, >> >> >> On 1/16/2014 12:48 PM, Daniel D. Daugherty wrote: >>> On 1/16/14 1:42 PM, Yumin Qi wrote: >>>> David, >>>> >>>> Thanks for the detail analysis so far and supply suggested fix. >>>> >>>> On 1/15/2014 10:21 PM, David Holmes wrote: >>>>> Hi Yumin, >>>>> >>>>> Unfortunately the complexities of this continue to expose >>>>> themselves :( >>>>> >>>>> On 15/01/2014 11:00 AM, Yumin Qi wrote: >>>>>> Can I have your codereview of the change >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/6498581/webrev00 >>>>>> >>>>>> >>>>>> Summary: There is race condition between os::interrupt and >>>>>> os::is_interrupted on Windows. See bug comments in detail. When >>>>>> thread >>>>>> sleep check if it gets interrupted, it may see interrupted but not >>>>>> really interrupted so cause spurious waking up (early return from >>>>>> sleep). Fix by checking if a real interrupt sent to thread interrupt >>>>>> event can prevent such false return. On windows we can get away the >>>>>> interrupted field but to keep consistent with other platforms, I >>>>>> choose >>>>>> to leave it as it is. >>>>>> >>>>>> Contributed-By: David Holmes >>>>> >>>>> Not really. :) I suggested using WaitForSingleObject on the >>>>> interrupt event to detect if the event was signalled or not, and >>>>> hence whether the thread was interrupted or not. I had envisaged it >>>>> replacing use of the interrupted field altogether on windows - but I >>>>> had overlooked the fact that the _interrupted field of osThread is >>>>> maintained in shared code, and further that there is an intrinsic >>>>> for Thread.isInterrupted that uses that field! >>>>> >>>> I can add myself after you, the main contributor for this fix. >>>>> The fix you have provided in os::is_interrupted deals nicely with >>>>> the race between setting/clearing the field and setting/clearing the >>>>> event. Because of the strong ordering in os::interrupt: >>>>> >>>>> 1. osthread->set_interrupted(true); >>>>> 2. OrderAccess::release(); >>>>> 3. SetEvent(osthread->interrupt_event()); >>>>> >>>>> we can require both conditions to be met to define that the thread >>>>> is indeed interrupted. If we have set the field but not the event >>>>> then is_interrupted will return false without touching the field or >>>>> the event. If the thread then blocks it will either unblock >>>>> immediately if setEvent has now been called, or will unblock when >>>>> setEvent is eventually called. That all seems to work fine. >>>>> >>>>> The intrinsic is a fast-path that inlines the access to the >>>>> _interrupted field, but only for the current thread and only when >>>>> not trying to also clear the interrupted state (ie only for >>>>> Thread.currentThread().isInterrupted()**). That seems mostly >>>>> harmless even if the thread is concurrently halfway through being >>>>> interrupted (ie the field is set but not the event) as any interrupt >>>>> responsive operation will at some point call the actual >>>>> os::is_interrupted() runtime code. >>>>> >>>>> The only glitch I see is that it would now be possible for the >>>>> following code to throw the exception: >>>>> >>>>> boolean a = Thread.currentThread().isInterrupted(); >>>>> boolean b = Thread.interrupted(); >>>>> if (a && !b) >>>>> throw new Error("inconsistent Thread interrupt state observed"); >>>>> >>>> Hope no one will write code like this --- but there is other >>>> possibility that multiple interrupting actions sent to the thread so >>>> such check can not guarantee it returns consistent result. I see the >>>> problem here but think such coding is very rare. With we return real >>>> status of Event, 'a' get false means the Event is not set yet ---- >>>> and os::is_interrupted returns false is right. >>> >>> I think you may have missed David's point here. The earlier check: >>> >>> boolean a = Thread.currentThread().isInterrupted(); >>> >>> is returning 'true' and a later check: >>> >>> boolean b = Thread.interrupted(); >>> >>> is returning 'false'. If variable 'a' is 'true', then 'b' must >>> also be 'true' to be consistent. >>> >> 1) a = true, b = true >> a: it will not clear interrupted field. So if we get a 'true', means >> interrupted field is true and Event signaled. But from code: >> >> if (interrupted && clear_interrupted) { >> osthread->set_interrupted(false); >> ResetEvent(osthread->interrupt_event()); >> } // Otherwise leave the interrupted state alone >> >> We did not do this since clear_interrupted is false. > > You are missing the point. If Thread.currentThread().isInterrupted() > is compiled at runtime using the intrinisc then it will return true if > the field is set even if the Event is not. At that point the > non-intrinsic Thread.interrupted would return false. This would give > the appearance that the thread was interrupted then not interrupted > but that is impossible based on the specs for those methods. > > David > ----- > > >> b: now we query with clear_interrupted is true. >> Note the Event still signaled ( We assume no other interrupt actions >> from other threads), the os::is_interrupted will return 'true' since >> field is 'true' and Event in signaled status. >> We do the clear before return 'true' so next if we have call say, c, >> will get 'false'. >> >> 2) a = false b= true >> There is a situation like >> a: get a 'false' ---- the interrupt is going on and SetEvent not called >> yet, but field already set to interrupted so get a 'false'. >> b: When b called, interrupt action done, so now field is interrupted >> and Event signaled. We get a 'true'. >> >> (Assume only one interrupt) >> >> But, anyway, a = false and b = true should not be a problem I think. We >> treat interrupted as both field and Event set. >> It can not get a is true and b is false in the situation. >> >> Thanks >> Yumin >> >> >> >> >> >>> Dan >>> >>> >>>> >>>>> I don't think this is a realistic situation given for the issue to >>>>> arise you need the interrupting thread to be effectively descheduled >>>>> after setting the field but before setting the event. But still it >>>>> is possible and could be observable. I'm inclined to accept this >>>>> possibility but I think Karen should make that call. I also think we >>>>> would need to document this possibility just in case it does arise. >>>>> >>>>> ** I've no idea why this intrinsic exists as it is a fairly uncommon >>>>> usage. I guess at some point it was thought that this would be >>>>> common, but most interrupt responsive code uses Thread.interrupted >>>>> to clear the interrupt state as well as query it. >>>>> >>>> agree. >>>> >>>> Thanks >>>> Yumin >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Tests: vm.quick.testlist, specjbb2005, original test case, JPRT >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>> >>> >> From david.holmes at oracle.com Thu Jan 16 23:01:02 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jan 2014 17:01:02 +1000 Subject: RFR: 6498581: ThreadInterruptTest3 produces wrong output on Windows In-Reply-To: <52D8C972.6050104@oracle.com> References: <52D5DDB9.8000700@oracle.com> <52D77A72.2030808@oracle.com> <52D8442D.7010702@oracle.com> <52D84592.3070009@oracle.com> <52D84E19.7000502@oracle.com> <52D86707.5080500@oracle.com> <52D8C972.6050104@oracle.com> Message-ID: <52D8D52E.6010802@oracle.com> Hi Yumin, No need to bother the compiler folks with this (still cc'd but can be dropped on any reply). We just need to decide if we can tolerate this inconsistency between the intrinsic and non-intrinsic forms. Otherwise we may choose to disable the intrinsic on Windows - I really don't see that it can be adding much value as Thread.currentThread().isInterrupted(false) is hardly a performance critical action. But we would need benchmarking to confirm that. David On 17/01/2014 4:10 PM, Yumin Qi wrote: > Now I got it: > > //------------------------inline_native_isInterrupted------------------ > // private native boolean java.lang.Thread.isInterrupted(boolean > ClearInterrupted); > bool LibraryCallKit::inline_native_isInterrupted() { > // Add a fast path to t.isInterrupted(clear_int): > // (t == Thread.current() && (!TLS._osthread._interrupted || > !clear_int)) > // ? TLS._osthread._interrupted : /*slow path:*/ > t.isInterrupted(clear_int) > // So, in the common case that the interrupt bit is false, > // we avoid making a call into the VM. Even if the interrupt bit > // is true, if the clear_int argument is false, we avoid the VM call. > // However, if the receiver is not currentThread, we must call the VM, > // because there must be some locking done around the operation. > > // We only go to the fast case code if we pass two guards. > // Paths which do not pass are accumulated in the slow_region. > > this code does not work both before and after the fix then. > Maybe we should not go with fast path then. CC to compiler team. > > Thanks > Yumin > > > On 1/16/2014 3:11 PM, David Holmes wrote: >> On 17/01/2014 7:24 AM, Yumin Qi wrote: >>> Dan, >>> >>> >>> On 1/16/2014 12:48 PM, Daniel D. Daugherty wrote: >>>> On 1/16/14 1:42 PM, Yumin Qi wrote: >>>>> David, >>>>> >>>>> Thanks for the detail analysis so far and supply suggested fix. >>>>> >>>>> On 1/15/2014 10:21 PM, David Holmes wrote: >>>>>> Hi Yumin, >>>>>> >>>>>> Unfortunately the complexities of this continue to expose >>>>>> themselves :( >>>>>> >>>>>> On 15/01/2014 11:00 AM, Yumin Qi wrote: >>>>>>> Can I have your codereview of the change >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/6498581/webrev00 >>>>>>> >>>>>>> >>>>>>> Summary: There is race condition between os::interrupt and >>>>>>> os::is_interrupted on Windows. See bug comments in detail. When >>>>>>> thread >>>>>>> sleep check if it gets interrupted, it may see interrupted but not >>>>>>> really interrupted so cause spurious waking up (early return from >>>>>>> sleep). Fix by checking if a real interrupt sent to thread interrupt >>>>>>> event can prevent such false return. On windows we can get away the >>>>>>> interrupted field but to keep consistent with other platforms, I >>>>>>> choose >>>>>>> to leave it as it is. >>>>>>> >>>>>>> Contributed-By: David Holmes >>>>>> >>>>>> Not really. :) I suggested using WaitForSingleObject on the >>>>>> interrupt event to detect if the event was signalled or not, and >>>>>> hence whether the thread was interrupted or not. I had envisaged it >>>>>> replacing use of the interrupted field altogether on windows - but I >>>>>> had overlooked the fact that the _interrupted field of osThread is >>>>>> maintained in shared code, and further that there is an intrinsic >>>>>> for Thread.isInterrupted that uses that field! >>>>>> >>>>> I can add myself after you, the main contributor for this fix. >>>>>> The fix you have provided in os::is_interrupted deals nicely with >>>>>> the race between setting/clearing the field and setting/clearing the >>>>>> event. Because of the strong ordering in os::interrupt: >>>>>> >>>>>> 1. osthread->set_interrupted(true); >>>>>> 2. OrderAccess::release(); >>>>>> 3. SetEvent(osthread->interrupt_event()); >>>>>> >>>>>> we can require both conditions to be met to define that the thread >>>>>> is indeed interrupted. If we have set the field but not the event >>>>>> then is_interrupted will return false without touching the field or >>>>>> the event. If the thread then blocks it will either unblock >>>>>> immediately if setEvent has now been called, or will unblock when >>>>>> setEvent is eventually called. That all seems to work fine. >>>>>> >>>>>> The intrinsic is a fast-path that inlines the access to the >>>>>> _interrupted field, but only for the current thread and only when >>>>>> not trying to also clear the interrupted state (ie only for >>>>>> Thread.currentThread().isInterrupted()**). That seems mostly >>>>>> harmless even if the thread is concurrently halfway through being >>>>>> interrupted (ie the field is set but not the event) as any interrupt >>>>>> responsive operation will at some point call the actual >>>>>> os::is_interrupted() runtime code. >>>>>> >>>>>> The only glitch I see is that it would now be possible for the >>>>>> following code to throw the exception: >>>>>> >>>>>> boolean a = Thread.currentThread().isInterrupted(); >>>>>> boolean b = Thread.interrupted(); >>>>>> if (a && !b) >>>>>> throw new Error("inconsistent Thread interrupt state observed"); >>>>>> >>>>> Hope no one will write code like this --- but there is other >>>>> possibility that multiple interrupting actions sent to the thread so >>>>> such check can not guarantee it returns consistent result. I see the >>>>> problem here but think such coding is very rare. With we return real >>>>> status of Event, 'a' get false means the Event is not set yet ---- >>>>> and os::is_interrupted returns false is right. >>>> >>>> I think you may have missed David's point here. The earlier check: >>>> >>>> boolean a = Thread.currentThread().isInterrupted(); >>>> >>>> is returning 'true' and a later check: >>>> >>>> boolean b = Thread.interrupted(); >>>> >>>> is returning 'false'. If variable 'a' is 'true', then 'b' must >>>> also be 'true' to be consistent. >>>> >>> 1) a = true, b = true >>> a: it will not clear interrupted field. So if we get a 'true', means >>> interrupted field is true and Event signaled. But from code: >>> >>> if (interrupted && clear_interrupted) { >>> osthread->set_interrupted(false); >>> ResetEvent(osthread->interrupt_event()); >>> } // Otherwise leave the interrupted state alone >>> >>> We did not do this since clear_interrupted is false. >> >> You are missing the point. If Thread.currentThread().isInterrupted() >> is compiled at runtime using the intrinisc then it will return true if >> the field is set even if the Event is not. At that point the >> non-intrinsic Thread.interrupted would return false. This would give >> the appearance that the thread was interrupted then not interrupted >> but that is impossible based on the specs for those methods. >> >> David >> ----- >> >> >>> b: now we query with clear_interrupted is true. >>> Note the Event still signaled ( We assume no other interrupt actions >>> from other threads), the os::is_interrupted will return 'true' since >>> field is 'true' and Event in signaled status. >>> We do the clear before return 'true' so next if we have call say, c, >>> will get 'false'. >>> >>> 2) a = false b= true >>> There is a situation like >>> a: get a 'false' ---- the interrupt is going on and SetEvent not called >>> yet, but field already set to interrupted so get a 'false'. >>> b: When b called, interrupt action done, so now field is interrupted >>> and Event signaled. We get a 'true'. >>> >>> (Assume only one interrupt) >>> >>> But, anyway, a = false and b = true should not be a problem I think. We >>> treat interrupted as both field and Event set. >>> It can not get a is true and b is false in the situation. >>> >>> Thanks >>> Yumin >>> >>> >>> >>> >>> >>>> Dan >>>> >>>> >>>>> >>>>>> I don't think this is a realistic situation given for the issue to >>>>>> arise you need the interrupting thread to be effectively descheduled >>>>>> after setting the field but before setting the event. But still it >>>>>> is possible and could be observable. I'm inclined to accept this >>>>>> possibility but I think Karen should make that call. I also think we >>>>>> would need to document this possibility just in case it does arise. >>>>>> >>>>>> ** I've no idea why this intrinsic exists as it is a fairly uncommon >>>>>> usage. I guess at some point it was thought that this would be >>>>>> common, but most interrupt responsive code uses Thread.interrupted >>>>>> to clear the interrupt state as well as query it. >>>>>> >>>>> agree. >>>>> >>>>> Thanks >>>>> Yumin >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> Tests: vm.quick.testlist, specjbb2005, original test case, JPRT >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> >>>>> >>>> >>> > From igor.ignatyev at oracle.com Fri Jan 17 01:04:28 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 17 Jan 2014 13:04:28 +0400 Subject: [8] RFR (XXS): 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests In-Reply-To: <2218B036-E041-481A-A8AC-5DE640A29F0E@oracle.com> References: <3CB043C7-B7F7-41D9-B5E6-8771CCBC596A@oracle.com> <55E9B519-9BD8-49DC-8C96-E3757D4AEAF1@oracle.com> <2218B036-E041-481A-A8AC-5DE640A29F0E@oracle.com> Message-ID: <52D8F21C.7020702@oracle.com> Hi Chris, What about regression test for this? As I understood from your comment[1], you have it, but the webrev and changeset don't contain it. [1] https://bugs.openjdk.java.net/browse/JDK-8022395?focusedCommentId=13447393&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13447393 Igor On 01/17/2014 04:25 AM, Christian Thalinger wrote: > Thank you, Vladimir and Igor. I?m going to push this to jdk9 too. > > On Jan 16, 2014, at 3:48 PM, Igor Veresov > wrote: > >> Looks fine. >> >> igor >> >> On Jan 16, 2014, at 1:49 PM, Christian Thalinger >> > > wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8022395 >>> http://cr.openjdk.java.net/~twisti/8022395/webrev.00 >>> >>> 8022395: java.util.zip.ZipException: Not in GZIP format in >>> JT_JDK/test/java/util/zip/GZIP tests >>> Reviewed-by: >>> >>> C1's instrinsic for java.util.zip.CRC32.update(int b) on x86 destroys >>> the input value b but the register is not marked to be destroyed. >>> This can lead to a wrong value if CRC32.update is inlined. >>> >>> The fix is to mark the LIRItem to be destroyed. This will make C1 to >>> insert a spill move. >>> >> > From niclas.adlertz at oracle.com Fri Jan 17 01:53:32 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Fri, 17 Jan 2014 10:53:32 +0100 Subject: RFR(L) 8034198: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <52D7941D.2050801@oracle.com> References: <52D53871.40606@oracle.com> <20140114140353.GB9323@rbackman> <52D68C79.6070800@oracle.com> <52D690E6.50908@oracle.com> <52D7941D.2050801@oracle.com> Message-ID: <52D8FD9C.4090808@oracle.com> Vladimir, Thank you for your comments! > Vectors are separate from floats. Please, rename the method to > is_float_or_vector(). Done > > class Pressure. Field names start with '_' to separate then from > variables. > Done > Why you don't like to path pointer to liveout? It helped only in few > places but code in interfere_with_live() become complicated (IndexSet& > liveout and then elements(&liveout)). I thought it looked better to send in the liveout as a reference since it was allocated on stack in build_ifg_physical: IndexSet liveout(_live->live(block)); But if you want me revert the change I can do that. http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev03/ Kind Regards, Niclas Adlertz On 2014-01-16 09:11, Vladimir Kozlov wrote: > Niclas, > > Changes are good. I have few notes. > > Vectors are separate from floats. Please, rename the method to > is_float_or_vector(). > > class Pressure. Field names start with '_' to separate then from > variables. > > Why you don't like to path pointer to liveout? It helped only in few > places but code in interfere_with_live() become complicated (IndexSet& > liveout and then elements(&liveout)). > > Thanks, > Vladimir > > On 1/15/14 5:45 AM, Niclas Adlertz wrote: >> Hi again, >> >> I found a commented section that I forgot to remove in chaitin.hpp: >> >> // stores the first low-to-high transition (starting from the top of >> block) >> //uint final_high_pressure_index; >> >> Updated the webrev: >> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev02/ >> >> On 2014-01-15 14:26, Niclas Adlertz wrote: >>> Hi Rickard, >>> >>> Thank you for your comments. >>> >>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev01/ >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> On 2014-01-14 15:03, Rickard B?ckman wrote: >>>> Just a few comments on the C++ parts. I haven't verified that the >>>> logic >>>> is still the same. >>>> >>>> 1) It seems like there are a couple of functions that could be created >>>> in the new Pressure class to avoid code duplication. One example is >>>> the >>>> check_for_high_pressure_block method. >>>> >>>> 2) All places that checks lrg._is_float also check lrg._is_vector. >>>> That >>>> check could be made into a boolean method on the LRG instead. The same >>>> for is_UP() & mask_size(). >>>> >>>> 3) To make code more generic the int_pressure and float_pressure >>>> instances could be passed the INTPRESSURE and FLOATPRESSURE and keep >>>> those as instance variables. >>>> >>>> Good work. >>>> >>>> /R >>>> >>>> On 01/14, Niclas Adlertz wrote: >>>>> Hi all, >>>>> >>>>> This is a first step to clean up the register allocator in C2. In >>>>> this change we have divided the very long method >>>>> build_ifg_physical() into many smaller ones, making it easier to >>>>> see the steps when building the IFG (and computing >>>>> the block pressure). >>>>> We have also cleaned up old comments and improved old code, both >>>>> by better naming and by simplifying expressions. >>>>> I personally think that the easiest way to review this change is >>>>> to have the old and new ifg.cpp side by side, and >>>>> start from build_ifg_physical(). >>>>> The next step is to create a new class for these methods, >>>>> isolating them and removing them from PhaseChaitin. >>>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ >>>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 >>>>> >>>>> Kind Regards, >>>>> Niclas Adlertz >>> >> From roland.westrelin at oracle.com Fri Jan 17 02:19:53 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 17 Jan 2014 11:19:53 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <52D7A239.60806@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> <52D556EE.8000307@oracle.com> <410AB800-645F-4BBE-A95A-77ED239CBF89@oracle.com> <8788446E-73DF-4BCA-B0C2-CBD7C94A83BB@oracle.com> <52D7A239.60806@oracle.com> Message-ID: <97443F6C-F071-4800-98EE-B597A789B91B@oracle.com> What about this? http://cr.openjdk.java.net/~roland/8027422/webrev.03/ Roland. On Jan 16, 2014, at 10:11 AM, Vladimir Kozlov wrote: > On 1/16/14 1:05 AM, Roland Westrelin wrote: >> >> Thanks for reviewing this, Christian. >> >>> Seeing all these: >>> >>> true /* include_speculative */ >>> >>> I wonder if we should add new methods for these. It would make it easier to see the users of the speculative versions. >> >> A new meet_speculative() method? >> I?m ok with it. Vladimir, what do you think? > > I was going to suggest it too but then you need additional methods for other methods: join(), higher_equal(), filter(). So I am fine with it if you do all of them. > > Vladimir > >> >> Roland. >> >>> >>> On Jan 14, 2014, at 7:25 AM, Vladimir Kozlov wrote: >>> >>>> Looks good to me. >>>> >>>> On 1/14/14 1:13 AM, Roland Westrelin wrote: >>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.02/ >>>>> >>>>> I fixed the verification code at the end of Compile::remove_speculative_types(), used this format everywhere: >>>>> t->filter(_type, true /* include_speculative */); >>>>> >>>>> renamed NodeHash::check_speculative_types() to NodeHash::check_no_speculative_types(), added PhaseIterGVN::check_no_speculative_types() and now call it from the verification code of Compile::remove_speculative_types(). >>>>> >>>>> Do I need more than 1 review for this? >>>> >>>> Yes, you need an other review for this change. Ask Chris or Igor. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Roland. >>>>> >>>>> >>>>> On Jan 13, 2014, at 11:03 AM, Roland Westrelin wrote: >>>>> >>>>>>> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. >>>>>> >>>>>> Thanks for catching that. >>>>>> Is: >>>>>> // Verify that after the IGVN is over no speculative type has resurfaced >>>>>> good as a comment? >>>>>> >>>>>>> Passing 'true' parameter is not very informative. You can use local variable: >>>>>>> >>>>>>> bool include_speculative = true; >>>>>>> t->filter(_type, include_speculative); >>>>>>> >>>>>>> An other way to make code more informative is to add a comment to parameter: >>>>>>> >>>>>>> t->filter(_type, true /* include_speculative */); >>>>>>> >>>>>>> Either way is fine. >>>>>> >>>>>> Will do one of these. >>>>>> >>>>>> Thanks, >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 1/10/14 1:46 AM, Roland Westrelin wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> Here is a new webrev for this: >>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >>>>>>>> >>>>>>>> I fixed the issues you mentioned in your review. >>>>>>>> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >>>>>>>> I also added a verification method: >>>>>>>> NodeHash::check_speculative_types() >>>>>>>> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>>>>>>>> Thanks for reviewing this, Vladimir. >>>>>>>>>> >>>>>>>>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>>>>>>>> >>>>>>>>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>>>>>>>> >>>>>>>>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>>>>>>>> >>>>>>>>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>>>>>>>> >>>>>>>>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>>>>>>>> >>>>>>>>>> You?re right. It probably should. >>>>>>>>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>>>>>>>> >>>>>>>>> Right, passing 'true' will work in all cases then. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>>>>>>>> >>>>>>>>>> Sure. >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>>>>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>>>>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>>>>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>>>>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>>>>>>>> higher_equal() >>>>>>>>>>>> meet() >>>>>>>>>>>> join() >>>>>>>>>>>> filter() >>>>>>>>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>>>>>>>> >>>>>>>>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>>>>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Roland. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> From roland.westrelin at oracle.com Fri Jan 17 03:49:26 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 17 Jan 2014 12:49:26 +0100 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: <0C905816-F507-4D82-AB02-DE18A4A77560@oracle.com> References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> <0C905816-F507-4D82-AB02-DE18A4A77560@oracle.com> Message-ID: Thanks for taking another look. Comments inlined... On Jan 16, 2014, at 8:53 PM, Christian Thalinger wrote: > > On Jan 16, 2014, at 8:32 AM, Roland Westrelin wrote: > >> Thanks for reviewing this, Chris. >> >> Here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8031752/webrev.01/ > > ! bool MethodData::speculative_trap_bytecode(Bytecodes::Code code) { > > It would be good if this method would have an ?is? in the name. Something like is_speculative_trap_bytecode or is_bytecode_speculative_trap. Ok. > >> >> And comments below: >> >>> All these print_data_on changes are a pain: >>> >>> ! virtual void print_data_on(outputStream* st, const char* extra) const { >>> >>> I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? >> >> I want the speculative traps to be listed together with the byte code they affect. Diagnosing a missed optimization is much easier that way. Here is an example output: >> >> 6 ldc_w TestTrapSpeculate$B >> 9 if_acmpne 19 >> 64 bci: 9 BranchData trap(class_check recompiled) trap/ TestTrapSpeculate::m2(class_check recompiled) trap/ TestTrapSpeculate::m1(class_check recompiled) >> not taken(10) >> 12 fast_aload_0 >> >> But the speculative traps are not stored with the ProfileData for each byte code. So I need to pass something to each ProfileData::print_data_on() that can be used to print the speculative traps. I decided to pass a formatted string with the trap stuff. Which is then passed to ProfileData::print_shared() where the per byte code line is printed. > > Ok. Oh, one other thing I forgot to mention: should we have a default value for extra? > > ! virtual void print_data_on(outputStream* st, const char* extra = NULL) const { Ok. > >> >>> src/share/vm/oops/methodData.cpp: >>> >>> + case Bytecodes::_invokestatic: >>> + return UseTypeSpeculation; >>> + } >>> + return false; >>> >>> Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). >> >> Ok. > > + default: > + return false; > + } > + return false; > + } > > Isn?t the compiler warning about unreached code here? I would expect the compiler to complain because of the lack of final return if I remove it. Pretty hard to figure out which is good given the number of platforms we support and compilers that change the way they behave from one version to another. > >> >>> >>> int empty_bc_count = 0; // number of bytecodes lacking data >>> + bool has_spec_bc = false; >>> >>> That name is hard to understand for people new to the code. At least the first ugly name has a comment. >> >> Would needs_speculative_traps be better? > > Yes, thanks. > >> >>> >>> + DataLayout* MethodData::next_extra(DataLayout* dp) { >>> + int nb_cells = 0; >>> + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { >>> + nb_cells = BitData::static_cell_count(); >>> + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { >>> + nb_cells = SpeculativeTrapData::static_cell_count(); >>> + } else { >>> + fatal(err_msg("unexpected tag %d", dp->tag())); >>> + } >>> >>> It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: >>> >>> assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); >>> >>> is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. >> >> Ok. So I tried to use switches when iterating over the extra data everywhere. The problem is that break, breaks out of the switch but not out of the loop anymore. > > Can?t you use continue in that case? Oh, I just saw you did. > >> The new MethodData::next_extra() doesn?t know how to move past a arg_info_data_tag because it?s a static method. It?s a static method because it?s used by ciMethodData as well. So I need to break out of the loop before calling the last MethodData::next_extra(). Anyway, I refactored the code so that the loops are in their own methods and then I can return from them to jump out of the switch and loop. > > Thanks. Looks much better now. > >> >>> >>> src/share/vm/opto/compile.cpp: >>> >>> ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { >>> >>> Can you factor this to a local variable as you do later: >>> >>> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >>> if ((per_bc_reason == Deoptimization::Reason_none >>> ! || md->has_trap_at(bci, m, reason) != 0) >>> >>> ? >>> >> >> Ok. >> >>> src/share/vm/runtime/globals.hpp: >>> >>> + product(intx, PerMethodSpecTrapLimit, 5000, \ >>> + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ >>> >>> + product(intx, SpecTrapLimitExtraEntries, 3, \ >>> + "Extra method data trap entries for speculation") \ >>> >>> Do we need these new flags to be product flags? >> >> At this point, it?s unclear whether those values are going to be good enough so I think we need to be able to adjust the parameters in benchmark runs. > > I have mentioned this in a previous review but we need something like diagnostic flags but for non-diagnostic ones. Vladimir and I just talked to Mikael about this and we should use experimental for such flags; the flag is used for experiments (as you say for benchmark runs or similar things) and can either go away or be made a develop flag in the future. Ok. What do you suggest I do with the existing: product(intx, PerMethodTrapLimit, 100, \ "Limit on traps (of one kind) in a method (includes inlines)") \ \ product(intx, PerBytecodeTrapLimit, 4, \ "Limit on traps (of one kind) at a particular BCI") \ \ ? Roland. > >> >>> src/share/vm/ci/ciMethodData.cpp: >>> >>> ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { >>> ! st->print_cr("Parametertypes"); >>> ! st->print_cr("ciParameterTypesData?); >>> >>> Typo replaced with a typo :-) >> >> Indeed. >> >> Roland. >> >>> >>> On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: >>> >>>> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ >>>> >>>> When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). >>>> >>>> If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. >>>> >>>> When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. >>>> >>>> With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. >>>> >>>> This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. >>>> >>>> I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. >>>> >>>> I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. >>>> >>>> Roland. From roland.westrelin at oracle.com Fri Jan 17 05:03:25 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 17 Jan 2014 14:03:25 +0100 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: <52D84DC0.7030609@oracle.com> References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> <52D84DC0.7030609@oracle.com> Message-ID: <9E69EF09-B3A5-42CC-8480-1A5C2CBF2375@oracle.com> Hi Vladimir, Thanks for taking a loot at this. > Can you pass method to has_trap_at() and check the reason inside instead of current assert? Sorry, but I don?t understand what change you?d like to see. Is this the assert you?re talking about: int has_trap_at(int bci, ciMethod* m, int reason) { assert((m != NULL) == Deoptimization::reason_is_speculate(reason), "inconsistent method/reason"); return has_trap_at(bci_to_data(bci, m), reason); } Roland. > > Thanks, > Vladimir > > On 1/16/14 8:32 AM, Roland Westrelin wrote: >> Thanks for reviewing this, Chris. >> >> Here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8031752/webrev.01/ >> >> And comments below: >> >>> All these print_data_on changes are a pain: >>> >>> ! virtual void print_data_on(outputStream* st, const char* extra) const { >>> >>> I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? >> >> I want the speculative traps to be listed together with the byte code they affect. Diagnosing a missed optimization is much easier that way. Here is an example output: >> >> 6 ldc_w TestTrapSpeculate$B >> 9 if_acmpne 19 >> 64 bci: 9 BranchData trap(class_check recompiled) trap/ TestTrapSpeculate::m2(class_check recompiled) trap/ TestTrapSpeculate::m1(class_check recompiled) >> not taken(10) >> 12 fast_aload_0 >> >> But the speculative traps are not stored with the ProfileData for each byte code. So I need to pass something to each ProfileData::print_data_on() that can be used to print the speculative traps. I decided to pass a formatted string with the trap stuff. Which is then passed to ProfileData::print_shared() where the per byte code line is printed. >> >>> src/share/vm/oops/methodData.cpp: >>> >>> + case Bytecodes::_invokestatic: >>> + return UseTypeSpeculation; >>> + } >>> + return false; >>> >>> Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). >> >> Ok. >> >>> >>> int empty_bc_count = 0; // number of bytecodes lacking data >>> + bool has_spec_bc = false; >>> >>> That name is hard to understand for people new to the code. At least the first ugly name has a comment. >> >> Would needs_speculative_traps be better? >> >>> >>> + DataLayout* MethodData::next_extra(DataLayout* dp) { >>> + int nb_cells = 0; >>> + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { >>> + nb_cells = BitData::static_cell_count(); >>> + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { >>> + nb_cells = SpeculativeTrapData::static_cell_count(); >>> + } else { >>> + fatal(err_msg("unexpected tag %d", dp->tag())); >>> + } >>> >>> It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: >>> >>> assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); >>> >>> is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. >> >> Ok. So I tried to use switches when iterating over the extra data everywhere. The problem is that break, breaks out of the switch but not out of the loop anymore. The new MethodData::next_extra() doesn?t know how to move past a arg_info_data_tag because it?s a static method. It?s a static method because it?s used by ciMethodData as well. So I need to break out of the loop before calling the last MethodData::next_extra(). Anyway, I refactored the code so that the loops are in their own methods and then I can return from them to jump out of the switch and loop. >> >>> >>> src/share/vm/opto/compile.cpp: >>> >>> ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { >>> >>> Can you factor this to a local variable as you do later: >>> >>> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >>> if ((per_bc_reason == Deoptimization::Reason_none >>> ! || md->has_trap_at(bci, m, reason) != 0) >>> >>> ? >>> >> >> Ok. >> >>> src/share/vm/runtime/globals.hpp: >>> >>> + product(intx, PerMethodSpecTrapLimit, 5000, \ >>> + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ >>> >>> + product(intx, SpecTrapLimitExtraEntries, 3, \ >>> + "Extra method data trap entries for speculation") \ >>> >>> Do we need these new flags to be product flags? >> >> At this point, it?s unclear whether those values are going to be good enough so I think we need to be able to adjust the parameters in benchmark runs. >> >>> src/share/vm/ci/ciMethodData.cpp: >>> >>> ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { >>> ! st->print_cr("Parametertypes"); >>> ! st->print_cr("ciParameterTypesData?); >>> >>> Typo replaced with a typo :-) >> >> Indeed. >> >> Roland. >> >>> >>> On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: >>> >>>> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ >>>> >>>> When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). >>>> >>>> If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. >>>> >>>> When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. >>>> >>>> With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. >>>> >>>> This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. >>>> >>>> I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. >>>> >>>> I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. >>>> >>>> Roland. >>>> >>>> >>> >> From vladimir.kozlov at oracle.com Fri Jan 17 09:09:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jan 2014 09:09:48 -0800 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: <9E69EF09-B3A5-42CC-8480-1A5C2CBF2375@oracle.com> References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> <52D84DC0.7030609@oracle.com> <9E69EF09-B3A5-42CC-8480-1A5C2CBF2375@oracle.com> Message-ID: <52D963DC.8000301@oracle.com> Sorry, I was not clear. I suggested to move next reason check + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; + if (md->has_trap_at(bci, m, reason) != 0) { inside has_trap_at(): int has_trap_at(int bci, ciMethod* m, int reason) { if (!Deoptimization::reason_is_speculate(reason)) { m = NULL; } return has_trap_at(bci_to_data(bci, m), reason); } and path method always: + if (md->has_trap_at(bci, this->method(), reason) != 0) { The are 2 places where you do that. But I see that in the second case 'm' is also passed to trap_recompiled_at(). So my suggestion may be not good. IT is up to you. Thanks, Vladimir On 1/17/14 5:03 AM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for taking a loot at this. > >> Can you pass method to has_trap_at() and check the reason inside instead of current assert? > > Sorry, but I don?t understand what change you?d like to see. > Is this the assert you?re talking about: > > int has_trap_at(int bci, ciMethod* m, int reason) { > assert((m != NULL) == Deoptimization::reason_is_speculate(reason), "inconsistent method/reason"); > return has_trap_at(bci_to_data(bci, m), reason); > } > > Roland. > >> >> Thanks, >> Vladimir >> >> On 1/16/14 8:32 AM, Roland Westrelin wrote: >>> Thanks for reviewing this, Chris. >>> >>> Here is a new webrev: >>> >>> http://cr.openjdk.java.net/~roland/8031752/webrev.01/ >>> >>> And comments below: >>> >>>> All these print_data_on changes are a pain: >>>> >>>> ! virtual void print_data_on(outputStream* st, const char* extra) const { >>>> >>>> I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? >>> >>> I want the speculative traps to be listed together with the byte code they affect. Diagnosing a missed optimization is much easier that way. Here is an example output: >>> >>> 6 ldc_w TestTrapSpeculate$B >>> 9 if_acmpne 19 >>> 64 bci: 9 BranchData trap(class_check recompiled) trap/ TestTrapSpeculate::m2(class_check recompiled) trap/ TestTrapSpeculate::m1(class_check recompiled) >>> not taken(10) >>> 12 fast_aload_0 >>> >>> But the speculative traps are not stored with the ProfileData for each byte code. So I need to pass something to each ProfileData::print_data_on() that can be used to print the speculative traps. I decided to pass a formatted string with the trap stuff. Which is then passed to ProfileData::print_shared() where the per byte code line is printed. >>> >>>> src/share/vm/oops/methodData.cpp: >>>> >>>> + case Bytecodes::_invokestatic: >>>> + return UseTypeSpeculation; >>>> + } >>>> + return false; >>>> >>>> Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). >>> >>> Ok. >>> >>>> >>>> int empty_bc_count = 0; // number of bytecodes lacking data >>>> + bool has_spec_bc = false; >>>> >>>> That name is hard to understand for people new to the code. At least the first ugly name has a comment. >>> >>> Would needs_speculative_traps be better? >>> >>>> >>>> + DataLayout* MethodData::next_extra(DataLayout* dp) { >>>> + int nb_cells = 0; >>>> + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { >>>> + nb_cells = BitData::static_cell_count(); >>>> + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { >>>> + nb_cells = SpeculativeTrapData::static_cell_count(); >>>> + } else { >>>> + fatal(err_msg("unexpected tag %d", dp->tag())); >>>> + } >>>> >>>> It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: >>>> >>>> assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); >>>> >>>> is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. >>> >>> Ok. So I tried to use switches when iterating over the extra data everywhere. The problem is that break, breaks out of the switch but not out of the loop anymore. The new MethodData::next_extra() doesn?t know how to move past a arg_info_data_tag because it?s a static method. It?s a static method because it?s used by ciMethodData as well. So I need to break out of the loop before calling the last MethodData::next_extra(). Anyway, I refactored the code so that the loops are in their own methods and then I can return from them to jump out of the switch and loop. >>> >>>> >>>> src/share/vm/opto/compile.cpp: >>>> >>>> ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { >>>> >>>> Can you factor this to a local variable as you do later: >>>> >>>> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >>>> if ((per_bc_reason == Deoptimization::Reason_none >>>> ! || md->has_trap_at(bci, m, reason) != 0) >>>> >>>> ? >>>> >>> >>> Ok. >>> >>>> src/share/vm/runtime/globals.hpp: >>>> >>>> + product(intx, PerMethodSpecTrapLimit, 5000, \ >>>> + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ >>>> >>>> + product(intx, SpecTrapLimitExtraEntries, 3, \ >>>> + "Extra method data trap entries for speculation") \ >>>> >>>> Do we need these new flags to be product flags? >>> >>> At this point, it?s unclear whether those values are going to be good enough so I think we need to be able to adjust the parameters in benchmark runs. >>> >>>> src/share/vm/ci/ciMethodData.cpp: >>>> >>>> ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { >>>> ! st->print_cr("Parametertypes"); >>>> ! st->print_cr("ciParameterTypesData?); >>>> >>>> Typo replaced with a typo :-) >>> >>> Indeed. >>> >>> Roland. >>> >>>> >>>> On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: >>>> >>>>> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ >>>>> >>>>> When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). >>>>> >>>>> If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. >>>>> >>>>> When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. >>>>> >>>>> With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. >>>>> >>>>> This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. >>>>> >>>>> I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. >>>>> >>>>> I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. >>>>> >>>>> Roland. >>>>> >>>>> >>>> >>> > From jon.masamitsu at oracle.com Fri Jan 17 11:45:09 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 17 Jan 2014 11:45:09 -0800 Subject: Request for review (s) - 8031290: Adjust call to getisax() for additional words returned In-Reply-To: <52D85146.2040904@oracle.com> References: <52D8464A.8090009@oracle.com> <52D85146.2040904@oracle.com> Message-ID: <52D98845.3000305@oracle.com> On 1/16/2014 1:38 PM, Vladimir Kozlov wrote: > Jon, > > In vm_version_solaris_sparc.cpp you should change print_cr() to > print() in next line: > > tty->print_cr("getisax(2) returned: " PTR32_FORMAT, av); Fixed. Thanks. > > You can push into any repo, it is not time critical. > > Thanks, > Vladimir > > On 1/16/14 12:51 PM, Jon Masamitsu wrote: >> 8031290: Adjust call to getisax() for additional words returned >> >> Accept the 2nd word returned by getisax() on Solaris and use >> its contents to recognize AV2_SPARC_SPARC5 instructions. >> >> http://cr.openjdk.java.net/~jmasa/8031290/webrev.00/ >> >> Should this integrate through hotspot-compiler? >> >> Thanks to Vladimir for most of this fix. >> >> Jon From christian.thalinger at oracle.com Fri Jan 17 13:21:35 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 17 Jan 2014 13:21:35 -0800 Subject: [8] RFR (XXS): 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests In-Reply-To: <52D8F21C.7020702@oracle.com> References: <3CB043C7-B7F7-41D9-B5E6-8771CCBC596A@oracle.com> <55E9B519-9BD8-49DC-8C96-E3757D4AEAF1@oracle.com> <2218B036-E041-481A-A8AC-5DE640A29F0E@oracle.com> <52D8F21C.7020702@oracle.com> Message-ID: <65682F19-AD75-432D-B208-AF4BDFAE7511@oracle.com> The bug was found with an already existing regression test in the JDK. I don?t think we have to duplicate that test somewhere else. On Jan 17, 2014, at 1:04 AM, Igor Ignatyev wrote: > Hi Chris, > > What about regression test for this? As I understood from your comment[1], you have it, but the webrev and changeset don't contain it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8022395?focusedCommentId=13447393&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13447393 > Igor > > On 01/17/2014 04:25 AM, Christian Thalinger wrote: >> Thank you, Vladimir and Igor. I?m going to push this to jdk9 too. >> >> On Jan 16, 2014, at 3:48 PM, Igor Veresov > > wrote: >> >>> Looks fine. >>> >>> igor >>> >>> On Jan 16, 2014, at 1:49 PM, Christian Thalinger >>> >> > wrote: >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8022395 >>>> http://cr.openjdk.java.net/~twisti/8022395/webrev.00 >>>> >>>> 8022395: java.util.zip.ZipException: Not in GZIP format in >>>> JT_JDK/test/java/util/zip/GZIP tests >>>> Reviewed-by: >>>> >>>> C1's instrinsic for java.util.zip.CRC32.update(int b) on x86 destroys >>>> the input value b but the register is not marked to be destroyed. >>>> This can lead to a wrong value if CRC32.update is inlined. >>>> >>>> The fix is to mark the LIRItem to be destroyed. This will make C1 to >>>> insert a spill move. >>>> >>> >> From igor.ignatyev at oracle.com Fri Jan 17 13:53:21 2014 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Sat, 18 Jan 2014 01:53:21 +0400 Subject: =?utf-8?B?UmU6IFs4XSBSRlIgKFhYUyk6IDgwMjIzOTU6IGphdmEudXRpbC56aXAuWmlwRXhj?= =?utf-8?B?ZXB0aW9uOiBOb3QgaW4gR1pJUCBmb3JtYXQgaW4gSlRfSkRLL3Rlc3QvamF2YS91?= =?utf-8?B?dGlsL3ppcC9HWklQIHRlc3Rz?= Message-ID: <201401172153.s0HLrTu2003910@userz7022.oracle.com> Got it. It would be nice to add 8022395 to the @bug tag of the tests, but since these tests are from jdk, it can lead to additional efforts, so it's not really necessary. I'm not sure that we have a corresponding noreg- label for it, but if it exists please add it into the issue. Thanks. -- Igor ----- Reply message ----- From: "Christian Thalinger" To: "Igor Ignatyev" Cc: "hotspot compiler" Subject: [8] RFR (XXS): 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests Date: Sat, Jan 18, 2014 01:21 The bug was found with an already existing regression test in the JDK. I don?t think we have to duplicate that test somewhere else. On Jan 17, 2014, at 1:04 AM, Igor Ignatyev wrote: > Hi Chris, > > What about regression test for this? As I understood from your comment[1], you have it, but the webrev and changeset don't contain it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8022395?focusedCommentId=13447393&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13447393 > Igor > > On 01/17/2014 04:25 AM, Christian Thalinger wrote: >> Thank you, Vladimir and Igor. I?m going to push this to jdk9 too. >> >> On Jan 16, 2014, at 3:48 PM, Igor Veresov > > wrote: >> >>> Looks fine. >>> >>> igor >>> >>> On Jan 16, 2014, at 1:49 PM, Christian Thalinger >>> >> > wrote: >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8022395 >>>> http://cr.openjdk.java.net/~twisti/8022395/webrev.00 >>>> >>>> 8022395: java.util.zip.ZipException: Not in GZIP format in >>>> JT_JDK/test/java/util/zip/GZIP tests >>>> Reviewed-by: >>>> >>>> C1's instrinsic for java.util.zip.CRC32.update(int b) on x86 destroys >>>> the input value b but the register is not marked to be destroyed. >>>> This can lead to a wrong value if CRC32.update is inlined. >>>> >>>> The fix is to mark the LIRItem to be destroyed. This will make C1 to >>>> insert a spill move. >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140118/9c6cb85e/attachment.html From vladimir.kozlov at oracle.com Fri Jan 17 15:29:32 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jan 2014 15:29:32 -0800 Subject: RFR(L) 8034198: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <52D8FD9C.4090808@oracle.com> References: <52D53871.40606@oracle.com> <20140114140353.GB9323@rbackman> <52D68C79.6070800@oracle.com> <52D690E6.50908@oracle.com> <52D7941D.2050801@oracle.com> <52D8FD9C.4090808@oracle.com> Message-ID: <52D9BCDC.8050100@oracle.com> On 1/17/14 1:53 AM, Niclas Adlertz wrote: > Vladimir, > > Thank you for your comments! > >> Vectors are separate from floats. Please, rename the method to >> is_float_or_vector(). > Done > >> >> class Pressure. Field names start with '_' to separate then from >> variables. >> > Done > >> Why you don't like to path pointer to liveout? It helped only in few >> places but code in interfere_with_live() become complicated (IndexSet& >> liveout and then elements(&liveout)). > I thought it looked better to send in the liveout as a reference since > it was allocated on stack in build_ifg_physical: > IndexSet liveout(_live->live(block)); > But if you want me revert the change I can do that. The final consumer IndexSetIterator of liveout needs pointer. You have to add additional conversion in sources which I don't like: foo(IndexSet& liveout) { IndexSetIterator elements(&liveout); It makes code more complex to understand. Also in build_ifg_physical() you have too many empty lines. Thanks, Vladimir > > > http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev03/ > > Kind Regards, > Niclas Adlertz > > > On 2014-01-16 09:11, Vladimir Kozlov wrote: >> Niclas, >> >> Changes are good. I have few notes. >> >> Vectors are separate from floats. Please, rename the method to >> is_float_or_vector(). >> >> class Pressure. Field names start with '_' to separate then from >> variables. >> >> Why you don't like to path pointer to liveout? It helped only in few >> places but code in interfere_with_live() become complicated (IndexSet& >> liveout and then elements(&liveout)). >> >> Thanks, >> Vladimir >> >> On 1/15/14 5:45 AM, Niclas Adlertz wrote: >>> Hi again, >>> >>> I found a commented section that I forgot to remove in chaitin.hpp: >>> >>> // stores the first low-to-high transition (starting from the top of >>> block) >>> //uint final_high_pressure_index; >>> >>> Updated the webrev: >>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev02/ >>> >>> On 2014-01-15 14:26, Niclas Adlertz wrote: >>>> Hi Rickard, >>>> >>>> Thank you for your comments. >>>> >>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev01/ >>>> >>>> Kind Regards, >>>> Niclas Adlertz >>>> >>>> On 2014-01-14 15:03, Rickard B?ckman wrote: >>>>> Just a few comments on the C++ parts. I haven't verified that the >>>>> logic >>>>> is still the same. >>>>> >>>>> 1) It seems like there are a couple of functions that could be created >>>>> in the new Pressure class to avoid code duplication. One example is >>>>> the >>>>> check_for_high_pressure_block method. >>>>> >>>>> 2) All places that checks lrg._is_float also check lrg._is_vector. >>>>> That >>>>> check could be made into a boolean method on the LRG instead. The same >>>>> for is_UP() & mask_size(). >>>>> >>>>> 3) To make code more generic the int_pressure and float_pressure >>>>> instances could be passed the INTPRESSURE and FLOATPRESSURE and keep >>>>> those as instance variables. >>>>> >>>>> Good work. >>>>> >>>>> /R >>>>> >>>>> On 01/14, Niclas Adlertz wrote: >>>>>> Hi all, >>>>>> >>>>>> This is a first step to clean up the register allocator in C2. In >>>>>> this change we have divided the very long method >>>>>> build_ifg_physical() into many smaller ones, making it easier to >>>>>> see the steps when building the IFG (and computing >>>>>> the block pressure). >>>>>> We have also cleaned up old comments and improved old code, both >>>>>> by better naming and by simplifying expressions. >>>>>> I personally think that the easiest way to review this change is >>>>>> to have the old and new ifg.cpp side by side, and >>>>>> start from build_ifg_physical(). >>>>>> The next step is to create a new class for these methods, >>>>>> isolating them and removing them from PhaseChaitin. >>>>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ >>>>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 >>>>>> >>>>>> Kind Regards, >>>>>> Niclas Adlertz >>>> >>> > From igor.veresov at oracle.com Fri Jan 17 16:13:10 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 17 Jan 2014 16:13:10 -0800 Subject: RFR(XXS): 8032207 C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size Message-ID: <05EF5932-B017-4DD5-9B32-5438F535B700@oracle.com> Nodes using set() of an unknown constant cannot have fixed size. Webrev: http://cr.openjdk.java.net/~iveresov/8032207/webrev.00/ Thanks! igor From vladimir.kozlov at oracle.com Fri Jan 17 16:20:34 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jan 2014 16:20:34 -0800 Subject: RFR(XXS): 8032207 C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size In-Reply-To: <05EF5932-B017-4DD5-9B32-5438F535B700@oracle.com> References: <05EF5932-B017-4DD5-9B32-5438F535B700@oracle.com> Message-ID: <52D9C8D2.5080508@oracle.com> Good. Vladimir On 1/17/14 4:13 PM, Igor Veresov wrote: > Nodes using set() of an unknown constant cannot have fixed size. > > Webrev: http://cr.openjdk.java.net/~iveresov/8032207/webrev.00/ > > Thanks! > igor > From igor.veresov at oracle.com Fri Jan 17 16:26:48 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 17 Jan 2014 16:26:48 -0800 Subject: RFR(XXS): 8032207 C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size In-Reply-To: <05EF5932-B017-4DD5-9B32-5438F535B700@oracle.com> References: <05EF5932-B017-4DD5-9B32-5438F535B700@oracle.com> Message-ID: Forgot to add a test: http://cr.openjdk.java.net/~iveresov/8032207/webrev.01/ igor On Jan 17, 2014, at 4:13 PM, Igor Veresov wrote: > Nodes using set() of an unknown constant cannot have fixed size. > > Webrev: http://cr.openjdk.java.net/~iveresov/8032207/webrev.00/ > > Thanks! > igor From azeem.jiva at oracle.com Fri Jan 17 16:28:45 2014 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Fri, 17 Jan 2014 16:28:45 -0800 Subject: RFR(XXS): 8032207 C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size In-Reply-To: <05EF5932-B017-4DD5-9B32-5438F535B700@oracle.com> References: <05EF5932-B017-4DD5-9B32-5438F535B700@oracle.com> Message-ID: <5293FDE0-1336-4CD5-974E-C358C7B7A978@oracle.com> Looks good. Can we get the test case attached to the bug integrated with this fix? -- Azeem Jiva @javawithjiva On Jan 17, 2014, at 4:13 PM, Igor Veresov wrote: > Nodes using set() of an unknown constant cannot have fixed size. > > Webrev: http://cr.openjdk.java.net/~iveresov/8032207/webrev.00/ > > Thanks! > igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140117/3b306867/attachment.html From vladimir.kozlov at oracle.com Fri Jan 17 16:35:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jan 2014 16:35:49 -0800 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <97443F6C-F071-4800-98EE-B597A789B91B@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> <52D556EE.8000307@oracle.com> <410AB800-645F-4BBE-A95A-77ED239CBF89@oracle.com> <8788446E-73DF-4BCA-B0C2-CBD7C94A83BB@oracle.com> <52D7A239.60806@oracle.com> <97443F6C-F071-4800-98EE-B597A789B91B@oracle.com> Message-ID: <52D9CC65.9070108@oracle.com> Very good. You need to use 2014 Copyright year in the test (no need for re-review). Thanks, Vladimir On 1/17/14 2:19 AM, Roland Westrelin wrote: > What about this? > > http://cr.openjdk.java.net/~roland/8027422/webrev.03/ > > Roland. > > > On Jan 16, 2014, at 10:11 AM, Vladimir Kozlov wrote: > >> On 1/16/14 1:05 AM, Roland Westrelin wrote: >>> >>> Thanks for reviewing this, Christian. >>> >>>> Seeing all these: >>>> >>>> true /* include_speculative */ >>>> >>>> I wonder if we should add new methods for these. It would make it easier to see the users of the speculative versions. >>> >>> A new meet_speculative() method? >>> I?m ok with it. Vladimir, what do you think? >> >> I was going to suggest it too but then you need additional methods for other methods: join(), higher_equal(), filter(). So I am fine with it if you do all of them. >> >> Vladimir >> >>> >>> Roland. >>> >>>> >>>> On Jan 14, 2014, at 7:25 AM, Vladimir Kozlov wrote: >>>> >>>>> Looks good to me. >>>>> >>>>> On 1/14/14 1:13 AM, Roland Westrelin wrote: >>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.02/ >>>>>> >>>>>> I fixed the verification code at the end of Compile::remove_speculative_types(), used this format everywhere: >>>>>> t->filter(_type, true /* include_speculative */); >>>>>> >>>>>> renamed NodeHash::check_speculative_types() to NodeHash::check_no_speculative_types(), added PhaseIterGVN::check_no_speculative_types() and now call it from the verification code of Compile::remove_speculative_types(). >>>>>> >>>>>> Do I need more than 1 review for this? >>>>> >>>>> Yes, you need an other review for this change. Ask Chris or Igor. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Roland. >>>>>> >>>>>> >>>>>> On Jan 13, 2014, at 11:03 AM, Roland Westrelin wrote: >>>>>> >>>>>>>> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. >>>>>>> >>>>>>> Thanks for catching that. >>>>>>> Is: >>>>>>> // Verify that after the IGVN is over no speculative type has resurfaced >>>>>>> good as a comment? >>>>>>> >>>>>>>> Passing 'true' parameter is not very informative. You can use local variable: >>>>>>>> >>>>>>>> bool include_speculative = true; >>>>>>>> t->filter(_type, include_speculative); >>>>>>>> >>>>>>>> An other way to make code more informative is to add a comment to parameter: >>>>>>>> >>>>>>>> t->filter(_type, true /* include_speculative */); >>>>>>>> >>>>>>>> Either way is fine. >>>>>>> >>>>>>> Will do one of these. >>>>>>> >>>>>>> Thanks, >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 1/10/14 1:46 AM, Roland Westrelin wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> Here is a new webrev for this: >>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >>>>>>>>> >>>>>>>>> I fixed the issues you mentioned in your review. >>>>>>>>> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >>>>>>>>> I also added a verification method: >>>>>>>>> NodeHash::check_speculative_types() >>>>>>>>> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >>>>>>>>> >>>>>>>>>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>>>>>>>>> Thanks for reviewing this, Vladimir. >>>>>>>>>>> >>>>>>>>>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>>>>>>>>> >>>>>>>>>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>>>>>>>>> >>>>>>>>>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>>>>>>>>> >>>>>>>>>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>>>>>>>>> >>>>>>>>>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>>>>>>>>> >>>>>>>>>>> You?re right. It probably should. >>>>>>>>>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>>>>>>>>> >>>>>>>>>> Right, passing 'true' will work in all cases then. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>>>>>>>>> >>>>>>>>>>> Sure. >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>>>>>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>>>>>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>>>>>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>>>>>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>>>>>>>>> higher_equal() >>>>>>>>>>>>> meet() >>>>>>>>>>>>> join() >>>>>>>>>>>>> filter() >>>>>>>>>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>>>>>>>>> >>>>>>>>>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>>>>>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Roland. >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> > From vladimir.kozlov at oracle.com Fri Jan 17 16:37:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jan 2014 16:37:11 -0800 Subject: RFR(XXS): 8032207 C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size In-Reply-To: References: <05EF5932-B017-4DD5-9B32-5438F535B700@oracle.com> Message-ID: <52D9CCB7.5070104@oracle.com> Good. Vladimir On 1/17/14 4:26 PM, Igor Veresov wrote: > Forgot to add a test: http://cr.openjdk.java.net/~iveresov/8032207/webrev.01/ > > igor > > On Jan 17, 2014, at 4:13 PM, Igor Veresov wrote: > >> Nodes using set() of an unknown constant cannot have fixed size. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8032207/webrev.00/ >> >> Thanks! >> igor > From igor.veresov at oracle.com Fri Jan 17 16:41:56 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 17 Jan 2014 16:41:56 -0800 Subject: RFR(XXS): 8032207 C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size In-Reply-To: <52D9CCB7.5070104@oracle.com> References: <05EF5932-B017-4DD5-9B32-5438F535B700@oracle.com> <52D9CCB7.5070104@oracle.com> Message-ID: Thanks, Vladimir! igor On Jan 17, 2014, at 4:37 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 1/17/14 4:26 PM, Igor Veresov wrote: >> Forgot to add a test: http://cr.openjdk.java.net/~iveresov/8032207/webrev.01/ >> >> igor >> >> On Jan 17, 2014, at 4:13 PM, Igor Veresov wrote: >> >>> Nodes using set() of an unknown constant cannot have fixed size. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8032207/webrev.00/ >>> >>> Thanks! >>> igor >> From igor.veresov at oracle.com Fri Jan 17 16:59:20 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 17 Jan 2014 16:59:20 -0800 Subject: RFR(XXS): 8032207 C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size In-Reply-To: <5293FDE0-1336-4CD5-974E-C358C7B7A978@oracle.com> References: <05EF5932-B017-4DD5-9B32-5438F535B700@oracle.com> <5293FDE0-1336-4CD5-974E-C358C7B7A978@oracle.com> Message-ID: I?ll add the test. Thanks for the review! igor On Jan 17, 2014, at 4:28 PM, Azeem Jiva wrote: > Looks good. Can we get the test case attached to the bug integrated with this fix? > > -- > Azeem Jiva > @javawithjiva > > On Jan 17, 2014, at 4:13 PM, Igor Veresov wrote: > >> Nodes using set() of an unknown constant cannot have fixed size. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8032207/webrev.00/ >> >> Thanks! >> igor > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140117/47f68099/attachment.html From igor.veresov at oracle.com Sat Jan 18 12:51:35 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 18 Jan 2014 12:51:35 -0800 Subject: RFR(S) 8031743: C2: loadI2L_immI broken for negative memory values Message-ID: <2508E0EE-D01C-4DF3-A26B-D20F7F8480BA@oracle.com> Transformation of (ConvI2L (AndI (LoadI mem) mask)) to (AndI (LoadUI2L (mem) mask) is only valid for positive mask, otherwise the sign extending effect of ConvI2L is missed. The solution is to restrict the optimization for the positive values of mask. Webrev: http://cr.openjdk.java.net/~iveresov/8031743/webrev.00/ Testing: new regression test, jprt Thanks! igor From vladimir.kozlov at oracle.com Sat Jan 18 13:02:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 18 Jan 2014 13:02:52 -0800 Subject: RFR(S) 8031743: C2: loadI2L_immI broken for negative memory values In-Reply-To: <2508E0EE-D01C-4DF3-A26B-D20F7F8480BA@oracle.com> References: <2508E0EE-D01C-4DF3-A26B-D20F7F8480BA@oracle.com> Message-ID: <52DAEBFC.5050401@oracle.com> immU32 name is not correct, it should be immU31. Vladimir K On 1/18/14 12:51 PM, Igor Veresov wrote: > Transformation of (ConvI2L (AndI (LoadI mem) mask)) to (AndI (LoadUI2L (mem) mask) is only valid for positive mask, otherwise the sign extending effect of ConvI2L is missed. The solution is to restrict the optimization for the positive values of mask. > > Webrev: http://cr.openjdk.java.net/~iveresov/8031743/webrev.00/ > Testing: new regression test, jprt > > Thanks! > igor > From igor.veresov at oracle.com Sat Jan 18 13:18:46 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 18 Jan 2014 13:18:46 -0800 Subject: RFR(S) 8031743: C2: loadI2L_immI broken for negative memory values In-Reply-To: <52DAEBFC.5050401@oracle.com> References: <2508E0EE-D01C-4DF3-A26B-D20F7F8480BA@oracle.com> <52DAEBFC.5050401@oracle.com> Message-ID: We have this convention already in quite some places, so I was trying to follow it... For example on sparc there is immU13, which actually means simm13 & >= 0, which means it?s actually 12 bit. Likewise on ARM we have immURot that works that same way. So, the way these things go, I think, is that immUX means: fits in X bits and is positive. igor On Jan 18, 2014, at 1:02 PM, Vladimir Kozlov wrote: > immU32 name is not correct, it should be immU31. > > Vladimir K > > On 1/18/14 12:51 PM, Igor Veresov wrote: >> Transformation of (ConvI2L (AndI (LoadI mem) mask)) to (AndI (LoadUI2L (mem) mask) is only valid for positive mask, otherwise the sign extending effect of ConvI2L is missed. The solution is to restrict the optimization for the positive values of mask. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8031743/webrev.00/ >> Testing: new regression test, jprt >> >> Thanks! >> igor >> From vladimir.kozlov at oracle.com Sat Jan 18 13:21:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 18 Jan 2014 13:21:52 -0800 Subject: RFR(S) 8031743: C2: loadI2L_immI broken for negative memory values In-Reply-To: References: <2508E0EE-D01C-4DF3-A26B-D20F7F8480BA@oracle.com> <52DAEBFC.5050401@oracle.com> Message-ID: <52DAF070.5050404@oracle.com> Integer positive fits into 31 bits not into 32. Vladimir On 1/18/14 1:18 PM, Igor Veresov wrote: > We have this convention already in quite some places, so I was trying to follow it... For example on sparc there is immU13, which actually means simm13 & >= 0, which means it?s actually 12 bit. Likewise on ARM we have immURot that works that same way. So, the way these things go, I think, is that immUX means: fits in X bits and is positive. > > igor > > On Jan 18, 2014, at 1:02 PM, Vladimir Kozlov wrote: > >> immU32 name is not correct, it should be immU31. >> >> Vladimir K >> >> On 1/18/14 12:51 PM, Igor Veresov wrote: >>> Transformation of (ConvI2L (AndI (LoadI mem) mask)) to (AndI (LoadUI2L (mem) mask) is only valid for positive mask, otherwise the sign extending effect of ConvI2L is missed. The solution is to restrict the optimization for the positive values of mask. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8031743/webrev.00/ >>> Testing: new regression test, jprt >>> >>> Thanks! >>> igor >>> > From igor.veresov at oracle.com Sat Jan 18 17:48:52 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 18 Jan 2014 17:48:52 -0800 Subject: RFR(S) 8031743: C2: loadI2L_immI broken for negative memory values In-Reply-To: <52DAF070.5050404@oracle.com> References: <2508E0EE-D01C-4DF3-A26B-D20F7F8480BA@oracle.com> <52DAEBFC.5050401@oracle.com> <52DAF070.5050404@oracle.com> Message-ID: <70865AB1-78E8-4755-BD59-2034B3A28519@oracle.com> Here?s the updated review: http://cr.openjdk.java.net/~iveresov/8031743/webrev.01/ igor On Jan 18, 2014, at 1:21 PM, Vladimir Kozlov wrote: > Integer positive fits into 31 bits not into 32. > > Vladimir > > On 1/18/14 1:18 PM, Igor Veresov wrote: >> We have this convention already in quite some places, so I was trying to follow it... For example on sparc there is immU13, which actually means simm13 & >= 0, which means it?s actually 12 bit. Likewise on ARM we have immURot that works that same way. So, the way these things go, I think, is that immUX means: fits in X bits and is positive. >> >> igor >> >> On Jan 18, 2014, at 1:02 PM, Vladimir Kozlov wrote: >> >>> immU32 name is not correct, it should be immU31. >>> >>> Vladimir K >>> >>> On 1/18/14 12:51 PM, Igor Veresov wrote: >>>> Transformation of (ConvI2L (AndI (LoadI mem) mask)) to (AndI (LoadUI2L (mem) mask) is only valid for positive mask, otherwise the sign extending effect of ConvI2L is missed. The solution is to restrict the optimization for the positive values of mask. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8031743/webrev.00/ >>>> Testing: new regression test, jprt >>>> >>>> Thanks! >>>> igor >>>> >> From vladimir.kozlov at oracle.com Sat Jan 18 18:40:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 18 Jan 2014 18:40:47 -0800 Subject: RFR(S) 8031743: C2: loadI2L_immI broken for negative memory values In-Reply-To: <70865AB1-78E8-4755-BD59-2034B3A28519@oracle.com> References: <2508E0EE-D01C-4DF3-A26B-D20F7F8480BA@oracle.com> <52DAEBFC.5050401@oracle.com> <52DAF070.5050404@oracle.com> <70865AB1-78E8-4755-BD59-2034B3A28519@oracle.com> Message-ID: <52DB3B2F.2020705@oracle.com> It is good. Thanks, Vladimir On 1/18/14 5:48 PM, Igor Veresov wrote: > Here?s the updated review: http://cr.openjdk.java.net/~iveresov/8031743/webrev.01/ > > igor > > On Jan 18, 2014, at 1:21 PM, Vladimir Kozlov wrote: > >> Integer positive fits into 31 bits not into 32. >> >> Vladimir >> >> On 1/18/14 1:18 PM, Igor Veresov wrote: >>> We have this convention already in quite some places, so I was trying to follow it... For example on sparc there is immU13, which actually means simm13 & >= 0, which means it?s actually 12 bit. Likewise on ARM we have immURot that works that same way. So, the way these things go, I think, is that immUX means: fits in X bits and is positive. >>> >>> igor >>> >>> On Jan 18, 2014, at 1:02 PM, Vladimir Kozlov wrote: >>> >>>> immU32 name is not correct, it should be immU31. >>>> >>>> Vladimir K >>>> >>>> On 1/18/14 12:51 PM, Igor Veresov wrote: >>>>> Transformation of (ConvI2L (AndI (LoadI mem) mask)) to (AndI (LoadUI2L (mem) mask) is only valid for positive mask, otherwise the sign extending effect of ConvI2L is missed. The solution is to restrict the optimization for the positive values of mask. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8031743/webrev.00/ >>>>> Testing: new regression test, jprt >>>>> >>>>> Thanks! >>>>> igor >>>>> >>> > From igor.veresov at oracle.com Sat Jan 18 21:19:07 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 18 Jan 2014 21:19:07 -0800 Subject: RFR(S) 8031743: C2: loadI2L_immI broken for negative memory values In-Reply-To: <52DB3B2F.2020705@oracle.com> References: <2508E0EE-D01C-4DF3-A26B-D20F7F8480BA@oracle.com> <52DAEBFC.5050401@oracle.com> <52DAF070.5050404@oracle.com> <70865AB1-78E8-4755-BD59-2034B3A28519@oracle.com> <52DB3B2F.2020705@oracle.com> Message-ID: <7DA99D0A-CFEE-4A25-B6B8-E4B04CE46933@oracle.com> Thanks, Vladimir! igor On Jan 18, 2014, at 6:40 PM, Vladimir Kozlov wrote: > It is good. > > Thanks, > Vladimir > > On 1/18/14 5:48 PM, Igor Veresov wrote: >> Here?s the updated review: http://cr.openjdk.java.net/~iveresov/8031743/webrev.01/ >> >> igor >> >> On Jan 18, 2014, at 1:21 PM, Vladimir Kozlov wrote: >> >>> Integer positive fits into 31 bits not into 32. >>> >>> Vladimir >>> >>> On 1/18/14 1:18 PM, Igor Veresov wrote: >>>> We have this convention already in quite some places, so I was trying to follow it... For example on sparc there is immU13, which actually means simm13 & >= 0, which means it?s actually 12 bit. Likewise on ARM we have immURot that works that same way. So, the way these things go, I think, is that immUX means: fits in X bits and is positive. >>>> >>>> igor >>>> >>>> On Jan 18, 2014, at 1:02 PM, Vladimir Kozlov wrote: >>>> >>>>> immU32 name is not correct, it should be immU31. >>>>> >>>>> Vladimir K >>>>> >>>>> On 1/18/14 12:51 PM, Igor Veresov wrote: >>>>>> Transformation of (ConvI2L (AndI (LoadI mem) mask)) to (AndI (LoadUI2L (mem) mask) is only valid for positive mask, otherwise the sign extending effect of ConvI2L is missed. The solution is to restrict the optimization for the positive values of mask. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8031743/webrev.00/ >>>>>> Testing: new regression test, jprt >>>>>> >>>>>> Thanks! >>>>>> igor >>>>>> >>>> >> From roland.westrelin at oracle.com Mon Jan 20 02:09:27 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 20 Jan 2014 11:09:27 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <52D9CC65.9070108@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> <52D556EE.8000307@oracle.com> <410AB800-645F-4BBE-A95A-77ED239CBF89@oracle.com> <8788446E-73DF-4BCA-B0C2-CBD7C94A83BB@oracle.com> <52D7A239.60806@oracle.com> <97443F6C-F071-4800-98EE-B597A789B91B@oracle.com> <52D9CC65.9070108@oracle.com> Message-ID: <6212A762-67AB-4F5F-8C92-616430877D3F@oracle.com> > Very good. > > You need to use 2014 Copyright year in the test (no need for re-review). Thanks, Vladimir. What about you, Chris? Do you think it?s ok now? Roland. > > Thanks, > Vladimir > > On 1/17/14 2:19 AM, Roland Westrelin wrote: >> What about this? >> >> http://cr.openjdk.java.net/~roland/8027422/webrev.03/ >> >> Roland. >> >> >> On Jan 16, 2014, at 10:11 AM, Vladimir Kozlov wrote: >> >>> On 1/16/14 1:05 AM, Roland Westrelin wrote: >>>> >>>> Thanks for reviewing this, Christian. >>>> >>>>> Seeing all these: >>>>> >>>>> true /* include_speculative */ >>>>> >>>>> I wonder if we should add new methods for these. It would make it easier to see the users of the speculative versions. >>>> >>>> A new meet_speculative() method? >>>> I?m ok with it. Vladimir, what do you think? >>> >>> I was going to suggest it too but then you need additional methods for other methods: join(), higher_equal(), filter(). So I am fine with it if you do all of them. >>> >>> Vladimir >>> >>>> >>>> Roland. >>>> >>>>> >>>>> On Jan 14, 2014, at 7:25 AM, Vladimir Kozlov wrote: >>>>> >>>>>> Looks good to me. >>>>>> >>>>>> On 1/14/14 1:13 AM, Roland Westrelin wrote: >>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.02/ >>>>>>> >>>>>>> I fixed the verification code at the end of Compile::remove_speculative_types(), used this format everywhere: >>>>>>> t->filter(_type, true /* include_speculative */); >>>>>>> >>>>>>> renamed NodeHash::check_speculative_types() to NodeHash::check_no_speculative_types(), added PhaseIterGVN::check_no_speculative_types() and now call it from the verification code of Compile::remove_speculative_types(). >>>>>>> >>>>>>> Do I need more than 1 review for this? >>>>>> >>>>>> Yes, you need an other review for this change. Ask Chris or Igor. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>> >>>>>>> On Jan 13, 2014, at 11:03 AM, Roland Westrelin wrote: >>>>>>> >>>>>>>>> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. >>>>>>>> >>>>>>>> Thanks for catching that. >>>>>>>> Is: >>>>>>>> // Verify that after the IGVN is over no speculative type has resurfaced >>>>>>>> good as a comment? >>>>>>>> >>>>>>>>> Passing 'true' parameter is not very informative. You can use local variable: >>>>>>>>> >>>>>>>>> bool include_speculative = true; >>>>>>>>> t->filter(_type, include_speculative); >>>>>>>>> >>>>>>>>> An other way to make code more informative is to add a comment to parameter: >>>>>>>>> >>>>>>>>> t->filter(_type, true /* include_speculative */); >>>>>>>>> >>>>>>>>> Either way is fine. >>>>>>>> >>>>>>>> Will do one of these. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Roland. >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 1/10/14 1:46 AM, Roland Westrelin wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> Here is a new webrev for this: >>>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >>>>>>>>>> >>>>>>>>>> I fixed the issues you mentioned in your review. >>>>>>>>>> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >>>>>>>>>> I also added a verification method: >>>>>>>>>> NodeHash::check_speculative_types() >>>>>>>>>> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>>>> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >>>>>>>>>> >>>>>>>>>>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>>>>>>>>>> Thanks for reviewing this, Vladimir. >>>>>>>>>>>> >>>>>>>>>>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>>>>>>>>>> >>>>>>>>>>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>>>>>>>>>> >>>>>>>>>>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>>>>>>>>>> >>>>>>>>>>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>>>>>>>>>> >>>>>>>>>>>> You?re right. It probably should. >>>>>>>>>>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>>>>>>>>>> >>>>>>>>>>> Right, passing 'true' will work in all cases then. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>>>>>>>>>> >>>>>>>>>>>> Sure. >>>>>>>>>>>> >>>>>>>>>>>> Roland. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>>>>>>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>>>>>>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>>>>>>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>>>>>>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>>>>>>>>>> higher_equal() >>>>>>>>>>>>>> meet() >>>>>>>>>>>>>> join() >>>>>>>>>>>>>> filter() >>>>>>>>>>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>>>>>>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Roland. >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> From roland.westrelin at oracle.com Mon Jan 20 02:28:24 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 20 Jan 2014 11:28:24 +0100 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: <52D963DC.8000301@oracle.com> References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> <52D84DC0.7030609@oracle.com> <9E69EF09-B3A5-42CC-8480-1A5C2CBF2375@oracle.com> <52D963DC.8000301@oracle.com> Message-ID: Here is a new webrev with Chris? suggestions: http://cr.openjdk.java.net/~roland/8031752/webrev.02/ Vladimir, I didn?t include your suggestion because as you mention trap_recompiled_at() needs the method argument. Roland. On Jan 17, 2014, at 6:09 PM, Vladimir Kozlov wrote: > Sorry, I was not clear. I suggested to move next reason check > > + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; > + if (md->has_trap_at(bci, m, reason) != 0) { > > inside has_trap_at(): > > int has_trap_at(int bci, ciMethod* m, int reason) { > if (!Deoptimization::reason_is_speculate(reason)) { > m = NULL; > } > return has_trap_at(bci_to_data(bci, m), reason); > } > > and path method always: > > + if (md->has_trap_at(bci, this->method(), reason) != 0) { > > The are 2 places where you do that. But I see that in the second case 'm' is also passed to trap_recompiled_at(). So my suggestion may be not good. IT is up to you. > > Thanks, > Vladimir > > On 1/17/14 5:03 AM, Roland Westrelin wrote: >> Hi Vladimir, >> >> Thanks for taking a loot at this. >> >>> Can you pass method to has_trap_at() and check the reason inside instead of current assert? >> >> Sorry, but I don?t understand what change you?d like to see. >> Is this the assert you?re talking about: >> >> int has_trap_at(int bci, ciMethod* m, int reason) { >> assert((m != NULL) == Deoptimization::reason_is_speculate(reason), "inconsistent method/reason"); >> return has_trap_at(bci_to_data(bci, m), reason); >> } >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 1/16/14 8:32 AM, Roland Westrelin wrote: >>>> Thanks for reviewing this, Chris. >>>> >>>> Here is a new webrev: >>>> >>>> http://cr.openjdk.java.net/~roland/8031752/webrev.01/ >>>> >>>> And comments below: >>>> >>>>> All these print_data_on changes are a pain: >>>>> >>>>> ! virtual void print_data_on(outputStream* st, const char* extra) const { >>>>> >>>>> I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? >>>> >>>> I want the speculative traps to be listed together with the byte code they affect. Diagnosing a missed optimization is much easier that way. Here is an example output: >>>> >>>> 6 ldc_w TestTrapSpeculate$B >>>> 9 if_acmpne 19 >>>> 64 bci: 9 BranchData trap(class_check recompiled) trap/ TestTrapSpeculate::m2(class_check recompiled) trap/ TestTrapSpeculate::m1(class_check recompiled) >>>> not taken(10) >>>> 12 fast_aload_0 >>>> >>>> But the speculative traps are not stored with the ProfileData for each byte code. So I need to pass something to each ProfileData::print_data_on() that can be used to print the speculative traps. I decided to pass a formatted string with the trap stuff. Which is then passed to ProfileData::print_shared() where the per byte code line is printed. >>>> >>>>> src/share/vm/oops/methodData.cpp: >>>>> >>>>> + case Bytecodes::_invokestatic: >>>>> + return UseTypeSpeculation; >>>>> + } >>>>> + return false; >>>>> >>>>> Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). >>>> >>>> Ok. >>>> >>>>> >>>>> int empty_bc_count = 0; // number of bytecodes lacking data >>>>> + bool has_spec_bc = false; >>>>> >>>>> That name is hard to understand for people new to the code. At least the first ugly name has a comment. >>>> >>>> Would needs_speculative_traps be better? >>>> >>>>> >>>>> + DataLayout* MethodData::next_extra(DataLayout* dp) { >>>>> + int nb_cells = 0; >>>>> + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { >>>>> + nb_cells = BitData::static_cell_count(); >>>>> + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { >>>>> + nb_cells = SpeculativeTrapData::static_cell_count(); >>>>> + } else { >>>>> + fatal(err_msg("unexpected tag %d", dp->tag())); >>>>> + } >>>>> >>>>> It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: >>>>> >>>>> assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); >>>>> >>>>> is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. >>>> >>>> Ok. So I tried to use switches when iterating over the extra data everywhere. The problem is that break, breaks out of the switch but not out of the loop anymore. The new MethodData::next_extra() doesn?t know how to move past a arg_info_data_tag because it?s a static method. It?s a static method because it?s used by ciMethodData as well. So I need to break out of the loop before calling the last MethodData::next_extra(). Anyway, I refactored the code so that the loops are in their own methods and then I can return from them to jump out of the switch and loop. >>>> >>>>> >>>>> src/share/vm/opto/compile.cpp: >>>>> >>>>> ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { >>>>> >>>>> Can you factor this to a local variable as you do later: >>>>> >>>>> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >>>>> if ((per_bc_reason == Deoptimization::Reason_none >>>>> ! || md->has_trap_at(bci, m, reason) != 0) >>>>> >>>>> ? >>>>> >>>> >>>> Ok. >>>> >>>>> src/share/vm/runtime/globals.hpp: >>>>> >>>>> + product(intx, PerMethodSpecTrapLimit, 5000, \ >>>>> + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ >>>>> >>>>> + product(intx, SpecTrapLimitExtraEntries, 3, \ >>>>> + "Extra method data trap entries for speculation") \ >>>>> >>>>> Do we need these new flags to be product flags? >>>> >>>> At this point, it?s unclear whether those values are going to be good enough so I think we need to be able to adjust the parameters in benchmark runs. >>>> >>>>> src/share/vm/ci/ciMethodData.cpp: >>>>> >>>>> ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { >>>>> ! st->print_cr("Parametertypes"); >>>>> ! st->print_cr("ciParameterTypesData?); >>>>> >>>>> Typo replaced with a typo :-) >>>> >>>> Indeed. >>>> >>>> Roland. >>>> >>>>> >>>>> On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ >>>>>> >>>>>> When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). >>>>>> >>>>>> If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. >>>>>> >>>>>> When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. >>>>>> >>>>>> With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. >>>>>> >>>>>> This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. >>>>>> >>>>>> I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. >>>>>> >>>>>> I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. >>>>>> >>>>>> Roland. >>>>>> >>>>>> >>>>> >>>> >> From igor.ignatyev at oracle.com Mon Jan 20 04:27:50 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 20 Jan 2014 16:27:50 +0400 Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in need_compact3 test group Message-ID: <52DD1646.8030505@oracle.com> Hi all, Please review patch: Problem: tests 'compiler/tiered/NonTieredLevelsTest.java' and 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group Fix: tests are added into 'need_compact3' webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8028482 -- Igor From niclas.adlertz at oracle.com Mon Jan 20 04:47:26 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Mon, 20 Jan 2014 13:47:26 +0100 Subject: RFR(L) 8034198: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <52D9BCDC.8050100@oracle.com> References: <52D53871.40606@oracle.com> <20140114140353.GB9323@rbackman> <52D68C79.6070800@oracle.com> <52D690E6.50908@oracle.com> <52D7941D.2050801@oracle.com> <52D8FD9C.4090808@oracle.com> <52D9BCDC.8050100@oracle.com> Message-ID: <52DD1ADE.5050109@oracle.com> Thank you Vladimir. I removed the references and removed some of the line breaks. http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev04/ Kind Regards, Niclas Adlertz On 2014-01-18 00:29, Vladimir Kozlov wrote: > On 1/17/14 1:53 AM, Niclas Adlertz wrote: >> Vladimir, >> >> Thank you for your comments! >> >>> Vectors are separate from floats. Please, rename the method to >>> is_float_or_vector(). >> Done >> >>> >>> class Pressure. Field names start with '_' to separate then from >>> variables. >>> >> Done >> >>> Why you don't like to path pointer to liveout? It helped only in few >>> places but code in interfere_with_live() become complicated (IndexSet& >>> liveout and then elements(&liveout)). >> I thought it looked better to send in the liveout as a reference since >> it was allocated on stack in build_ifg_physical: >> IndexSet liveout(_live->live(block)); >> But if you want me revert the change I can do that. > > The final consumer IndexSetIterator of liveout needs pointer. You have > to add additional conversion in sources which I don't like: > > foo(IndexSet& liveout) { > IndexSetIterator elements(&liveout); > > It makes code more complex to understand. > > Also in build_ifg_physical() you have too many empty lines. > > Thanks, > Vladimir > >> >> >> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev03/ >> >> Kind Regards, >> Niclas Adlertz >> >> >> On 2014-01-16 09:11, Vladimir Kozlov wrote: >>> Niclas, >>> >>> Changes are good. I have few notes. >>> >>> Vectors are separate from floats. Please, rename the method to >>> is_float_or_vector(). >>> >>> class Pressure. Field names start with '_' to separate then from >>> variables. >>> >>> Why you don't like to path pointer to liveout? It helped only in few >>> places but code in interfere_with_live() become complicated (IndexSet& >>> liveout and then elements(&liveout)). >>> >>> Thanks, >>> Vladimir >>> >>> On 1/15/14 5:45 AM, Niclas Adlertz wrote: >>>> Hi again, >>>> >>>> I found a commented section that I forgot to remove in chaitin.hpp: >>>> >>>> // stores the first low-to-high transition (starting from the top of >>>> block) >>>> //uint final_high_pressure_index; >>>> >>>> Updated the webrev: >>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev02/ >>>> >>>> On 2014-01-15 14:26, Niclas Adlertz wrote: >>>>> Hi Rickard, >>>>> >>>>> Thank you for your comments. >>>>> >>>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev01/ >>>>> >>>>> Kind Regards, >>>>> Niclas Adlertz >>>>> >>>>> On 2014-01-14 15:03, Rickard B?ckman wrote: >>>>>> Just a few comments on the C++ parts. I haven't verified that the >>>>>> logic >>>>>> is still the same. >>>>>> >>>>>> 1) It seems like there are a couple of functions that could be >>>>>> created >>>>>> in the new Pressure class to avoid code duplication. One example is >>>>>> the >>>>>> check_for_high_pressure_block method. >>>>>> >>>>>> 2) All places that checks lrg._is_float also check lrg._is_vector. >>>>>> That >>>>>> check could be made into a boolean method on the LRG instead. The >>>>>> same >>>>>> for is_UP() & mask_size(). >>>>>> >>>>>> 3) To make code more generic the int_pressure and float_pressure >>>>>> instances could be passed the INTPRESSURE and FLOATPRESSURE and keep >>>>>> those as instance variables. >>>>>> >>>>>> Good work. >>>>>> >>>>>> /R >>>>>> >>>>>> On 01/14, Niclas Adlertz wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> This is a first step to clean up the register allocator in C2. In >>>>>>> this change we have divided the very long method >>>>>>> build_ifg_physical() into many smaller ones, making it easier to >>>>>>> see the steps when building the IFG (and computing >>>>>>> the block pressure). >>>>>>> We have also cleaned up old comments and improved old code, both >>>>>>> by better naming and by simplifying expressions. >>>>>>> I personally think that the easiest way to review this change is >>>>>>> to have the old and new ifg.cpp side by side, and >>>>>>> start from build_ifg_physical(). >>>>>>> The next step is to create a new class for these methods, >>>>>>> isolating them and removing them from PhaseChaitin. >>>>>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ >>>>>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 >>>>>>> >>>>>>> Kind Regards, >>>>>>> Niclas Adlertz >>>>> >>>> >> From igor.ignatyev at oracle.com Mon Jan 20 05:48:27 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 20 Jan 2014 17:48:27 +0400 Subject: RFR(XS) : 8027257 : [TESTBUG] compiler/ciReplay/TestVM.sh : Error: Could not find or load main class negative_test Message-ID: <52DD292B.3010403@oracle.com> Hi all, Please review patch: Problem: - there's odd 'negative_test ...' line in common.sh - 'cleanup' doesn't execute after each iteration of stop_level-loop in TestVM.sh Fix: - the redundant line is removed - 'cleanup' is moved into the loop webrev: http://cr.openjdk.java.net/~iignatyev/8027257/webrev.00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8027257 -- Igor From roland.westrelin at oracle.com Mon Jan 20 08:13:20 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 20 Jan 2014 17:13:20 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: References: Message-ID: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> Hi Doug, > webrev: http://cr.openjdk.java.net/~dnsimon/JDK-8031639/ More informative assert messages than ?oops? would be appreciated. dependencies.hpp: comment needs to be fixed: 249 GrowableArray* _dep_seen; // (seen[h->ident] & (1<klass(); 123 check_ctxk(ctxk); 124 assert_common_2(call_site_target_value, DepValue(_oop_recorder, call_site), DepValue(_oop_recorder, method_handle)); 125 } Don?t you need a VM_ENTRY? Have you verified that compilation time is not affected? I don?t really feel comfortable with this change. I wonder if it wouldn?t be simpler to have a base class for Dependencies, then one subclass for Dependencies that work on ci objects and one subclass that work directly on objects and Metadata. Then either accept code duplication or maybe use a parallel hierarchy for DepValue. Anyway, I?m not strongly against this either and I welcome another opinion. Roland. From roland.westrelin at oracle.com Mon Jan 20 08:21:19 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 20 Jan 2014 17:21:19 +0100 Subject: RFR(XS) : 8027257 : [TESTBUG] compiler/ciReplay/TestVM.sh : Error: Could not find or load main class negative_test In-Reply-To: <52DD292B.3010403@oracle.com> References: <52DD292B.3010403@oracle.com> Message-ID: <6B1F6957-3700-4574-8399-F41E9C891BE4@oracle.com> > webrev: http://cr.openjdk.java.net/~iignatyev/8027257/webrev.00/ That looks good to me. Roland. From roland.westrelin at oracle.com Mon Jan 20 08:21:59 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 20 Jan 2014 17:21:59 +0100 Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in need_compact3 test group In-Reply-To: <52DD1646.8030505@oracle.com> References: <52DD1646.8030505@oracle.com> Message-ID: > webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/ That looks good to me. Roland. From doug.simon at oracle.com Mon Jan 20 08:46:31 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 20 Jan 2014 17:46:31 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> References: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> Message-ID: Hi Roland, Thanks for the review. Responses inline below: On Jan 20, 2014, at 5:13 PM, Roland Westrelin wrote: > Hi Doug, > >> webrev: http://cr.openjdk.java.net/~dnsimon/JDK-8031639/ > > More informative assert messages than ?oops? would be appreciated. Sorry, I?ll change the message to something more descriptive. > > dependencies.hpp: > > comment needs to be fixed: > 249 GrowableArray* _dep_seen; // (seen[h->ident] & (1< dependencies.cpp: > > 75 if (is_java_primitive(elemt)) return; // Ex: int[][] > align comment with // Ex: String[][] Will do. > 121 void Dependencies::assert_call_site_target_value(jobject call_site, jobject method_handle) { > 122 Klass* ctxk = JNIHandles::resolve(call_site)->klass(); > 123 check_ctxk(ctxk); > 124 assert_common_2(call_site_target_value, DepValue(_oop_recorder, call_site), DepValue(_oop_recorder, method_handle)); > 125 } > > Don?t you need a VM_ENTRY? Actually, the signature and implementation in this patch is a little of our date with respect to the current Graal code base. It?s now: void Dependencies::assert_call_site_target_value(oop call_site, oop method_handle) { assert_common_2(call_site_target_value, DepValue(_oop_recorder, JNIHandles::make_local(call_site)), DepValue(_oop_recorder, JNIHandles::make_local(method_handle))); } This is only called from a point within a VM_ENTRY so I don?t think it needs another VM_ENTRY marker, right? Is there someway to assert whether code is within a VM_ENTRY? > Have you verified that compilation time is not affected? No. Can you please suggest a reliable way to do this? I?m assuming something like CompileTheWorld? > I don?t really feel comfortable with this change. I wonder if it wouldn?t be simpler to have a base class for Dependencies, then one subclass for Dependencies that work on ci objects and one subclass that work directly on objects and Metadata. Then either accept code duplication or maybe use a parallel hierarchy for DepValue. If the compilation time is not impacted, wouldn?t it be better to avoid code duplication altogether? I?ll post another webrev after waiting a bit for further feedback. -Doug From staffan.larsen at oracle.com Mon Jan 20 10:02:15 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 20 Jan 2014 19:02:15 +0100 Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in need_compact3 test group In-Reply-To: References: <52DD1646.8030505@oracle.com> Message-ID: <7584D6FF-25B8-40BD-AFF6-593BFBD341AB@oracle.com> Looks good! Thanks, /Staffan On 20 jan 2014, at 17:21, Roland Westrelin wrote: >> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/ > > That looks good to me. > > Roland. > From roland.westrelin at oracle.com Mon Jan 20 10:05:59 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 20 Jan 2014 19:05:59 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: References: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> Message-ID: Doug, Comments inlined below > Thanks for the review. Responses inline below: > > On Jan 20, 2014, at 5:13 PM, Roland Westrelin wrote: > >> Hi Doug, >> >>> webrev: http://cr.openjdk.java.net/~dnsimon/JDK-8031639/ >> >> More informative assert messages than ?oops? would be appreciated. > > Sorry, I?ll change the message to something more descriptive. >> >> dependencies.hpp: >> >> comment needs to be fixed: >> 249 GrowableArray* _dep_seen; // (seen[h->ident] & (1< > How would you like it changed (I don?t think I modified this from its original). Are you suggesting the comment needs to reflect its usage in both the original and the #ifdef GRAAL world? I think h->ident is a reference to _ident from ciBaseObject which you don?t use anymore. A comment that states that you?re using some unique identifier as computed by DepValue would be clearer. >> dependencies.cpp: >> >> 75 if (is_java_primitive(elemt)) return; // Ex: int[][] >> align comment with // Ex: String[][] > > Will do. > >> 121 void Dependencies::assert_call_site_target_value(jobject call_site, jobject method_handle) { >> 122 Klass* ctxk = JNIHandles::resolve(call_site)->klass(); >> 123 check_ctxk(ctxk); >> 124 assert_common_2(call_site_target_value, DepValue(_oop_recorder, call_site), DepValue(_oop_recorder, method_handle)); >> 125 } >> >> Don?t you need a VM_ENTRY? > > Actually, the signature and implementation in this patch is a little of our date with respect to the current Graal code base. It?s now: > > void Dependencies::assert_call_site_target_value(oop call_site, oop method_handle) { > assert_common_2(call_site_target_value, DepValue(_oop_recorder, JNIHandles::make_local(call_site)), DepValue(_oop_recorder, JNIHandles::make_local(method_handle))); > } > > This is only called from a point within a VM_ENTRY so I don?t think it needs another VM_ENTRY marker, right? Is there someway to assert whether code is within a VM_ENTRY? ASSERT_IN_VM is what you would use, I think. I don?t see the VM_ENTRY when it?s called from GraphBuilder::access_field() for instance. > >> Have you verified that compilation time is not affected? > > No. Can you please suggest a reliable way to do this? I?m assuming something like CompileTheWorld? I was not suggesting a thorough experiment. Running your favorite benchmark with -XX:+CITime and checking nothing surprising happens is what I had in mind. >> I don?t really feel comfortable with this change. I wonder if it wouldn?t be simpler to have a base class for Dependencies, then one subclass for Dependencies that work on ci objects and one subclass that work directly on objects and Metadata. Then either accept code duplication or maybe use a parallel hierarchy for DepValue. > > If the compilation time is not impacted, wouldn?t it be better to avoid code duplication altogether? To me, this change doesn?t fit well with existing abstractions. I don?t think ciObject::constant_encoding() exists so that we can call JNIHandles::resolve() on the result and get a naked oop. All metadata references are still embedded in ciMetadata and even though it?s safe to grab a direct pointer to a Metadata from the compilers with the current implementation of the meta data, we don?t do it. That?s why I?m not comfortable with this change. I don?t have a nice solution to suggest either. Roland. > > I?ll post another webrev after waiting a bit for further feedback. > > -Doug From doug.simon at oracle.com Mon Jan 20 13:12:15 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 20 Jan 2014 22:12:15 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: References: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> Message-ID: <4E9CEB56-BE25-4785-96AC-84FDE07D2957@oracle.com> On Jan 20, 2014, at 7:05 PM, Roland Westrelin wrote: > Doug, > > Comments inlined below > >> Thanks for the review. Responses inline below: >> >> On Jan 20, 2014, at 5:13 PM, Roland Westrelin wrote: >> >>> Hi Doug, >>> >>>> webrev: http://cr.openjdk.java.net/~dnsimon/JDK-8031639/ >>> >>> More informative assert messages than ?oops? would be appreciated. >> >> Sorry, I?ll change the message to something more descriptive. >>> >>> dependencies.hpp: >>> >>> comment needs to be fixed: >>> 249 GrowableArray* _dep_seen; // (seen[h->ident] & (1<> >> How would you like it changed (I don?t think I modified this from its original). Are you suggesting the comment needs to reflect its usage in both the original and the #ifdef GRAAL world? > > I think h->ident is a reference to _ident from ciBaseObject which you don?t use anymore. A comment that states that you?re using some unique identifier as computed by DepValue would be clearer. > >>> dependencies.cpp: >>> >>> 75 if (is_java_primitive(elemt)) return; // Ex: int[][] >>> align comment with // Ex: String[][] >> >> Will do. >> >>> 121 void Dependencies::assert_call_site_target_value(jobject call_site, jobject method_handle) { >>> 122 Klass* ctxk = JNIHandles::resolve(call_site)->klass(); >>> 123 check_ctxk(ctxk); >>> 124 assert_common_2(call_site_target_value, DepValue(_oop_recorder, call_site), DepValue(_oop_recorder, method_handle)); >>> 125 } >>> >>> Don?t you need a VM_ENTRY? >> >> Actually, the signature and implementation in this patch is a little of our date with respect to the current Graal code base. It?s now: >> >> void Dependencies::assert_call_site_target_value(oop call_site, oop method_handle) { >> assert_common_2(call_site_target_value, DepValue(_oop_recorder, JNIHandles::make_local(call_site)), DepValue(_oop_recorder, JNIHandles::make_local(method_handle))); >> } Ignore my above ?correction? - it only applies to the code we have today because we maintain the Graal way of doing things separately from the ci* way of doing things. It?s exactly this duplication this changeset aims to remove. >> This is only called from a point within a VM_ENTRY so I don?t think it needs another VM_ENTRY marker, right? Is there someway to assert whether code is within a VM_ENTRY? > > ASSERT_IN_VM is what you would use, I think. > > I don?t see the VM_ENTRY when it?s called from GraphBuilder::access_field() for instance. Stepping back a moment, what is the requirement for VM_ENTRY here? >>> Have you verified that compilation time is not affected? >> >> No. Can you please suggest a reliable way to do this? I?m assuming something like CompileTheWorld? > > I was not suggesting a thorough experiment. Running your favorite benchmark with -XX:+CITime and checking nothing surprising happens is what I had in mind. It does?t seem to make any real difference. In fact, the "Code Installation? time after applying the changes decreased by about 4% although it?s hard to say what the error bars are for this measurement. See the details of my mini-experiement at the end of this message. >>> I don?t really feel comfortable with this change. I wonder if it wouldn?t be simpler to have a base class for Dependencies, then one subclass for Dependencies that work on ci objects and one subclass that work directly on objects and Metadata. Then either accept code duplication or maybe use a parallel hierarchy for DepValue. >> >> If the compilation time is not impacted, wouldn?t it be better to avoid code duplication altogether? > > To me, this change doesn?t fit well with existing abstractions. I don?t think ciObject::constant_encoding() exists so that we can call JNIHandles::resolve() on the result and get a naked oop. This change never exposes a naked oop - they all remain in jobjects. > All metadata references are still embedded in ciMetadata and even though it?s safe to grab a direct pointer to a Metadata from the compilers with the current implementation of the meta data, we don?t do it. That?s why I?m not comfortable with this change. I don?t have a nice solution to suggest either. I can understand that extracting the raw pointers from ciMetadata needs to be done carefully. However, the only difference this change makes is that it extracts the raw values earlier (i.e. as dependencies are recorded) instead of when they are serialized (in Dependencies::encode_content_bytes()). -Doug ==== Testing compilation time impact with -XX:+CITime and the DaCapo tradebeans benchmark ==== Original: $ java -server -XX:+CITime -jar lib/dacapo-9.12-bach.jar tradebeans -n 10 Using scaled threading model. 8 processors detected, 8 threads used to drive the workload, in a possible range of [1,512] Booting Geronimo Kernel (in Java 1.8.0-ea)? ? Accumulated compiler times (for compiled methods only) ------------------------------------------------ Total compilation time : 24.882 s Standard compilation : 23.599 s, Average : 0.004 On stack replacement : 1.283 s, Average : 0.019 Detailed C1 Timings Setup time: 0.000 s ( 0.0%) Build IR: 1.295 s (41.8%) Optimize: 0.046 s ( 1.5%) RCE: 0.010 s ( 0.3%) Emit LIR: 0.798 s (25.8%) LIR Gen: 0.196 s ( 6.3%) Linear Scan: 0.595 s (19.2%) LIR Schedule: 0.000 s ( 0.0%) Code Emission: 0.255 s ( 8.2%) Code Installation: 0.748 s (24.2%) Instruction Nodes: 435649 nodes Total compiled methods : 6528 methods Standard compilation : 6461 methods On stack replacement : 67 methods Total compiled bytecodes : 1305736 bytes Standard compilation : 1256020 bytes On stack replacement : 49716 bytes Average compilation speed: 52475 bytes/s nmethod code size : 12021920 bytes nmethod total size : 22180800 bytes Modified: $ java -server -XX:+CITime -jar lib/dacapo-9.12-bach.jar tradebeans -n 10 Using scaled threading model. 8 processors detected, 8 threads used to drive the workload, in a possible range of [1,512] Booting Geronimo Kernel (in Java 1.8.0-ea)? ? Accumulated compiler times (for compiled methods only) ------------------------------------------------ Total compilation time : 23.023 s Standard compilation : 21.679 s, Average : 0.003 On stack replacement : 1.344 s, Average : 0.024 Detailed C1 Timings Setup time: 0.000 s ( 0.0%) Build IR: 1.275 s (42.9%) Optimize: 0.043 s ( 1.4%) RCE: 0.009 s ( 0.3%) Emit LIR: 0.863 s (29.1%) LIR Gen: 0.278 s ( 9.4%) Linear Scan: 0.579 s (19.5%) LIR Schedule: 0.000 s ( 0.0%) Code Emission: 0.244 s ( 8.2%) Code Installation: 0.589 s (19.8%) Instruction Nodes: 439540 nodes Total compiled methods : 6437 methods Standard compilation : 6382 methods On stack replacement : 55 methods Total compiled bytecodes : 1289495 bytes Standard compilation : 1242674 bytes On stack replacement : 46821 bytes Average compilation speed: 56009 bytes/s nmethod code size : 12182368 bytes nmethod total size : 22058816 bytes From roland.westrelin at oracle.com Mon Jan 20 13:57:10 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 20 Jan 2014 22:57:10 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: <4E9CEB56-BE25-4785-96AC-84FDE07D2957@oracle.com> References: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> <4E9CEB56-BE25-4785-96AC-84FDE07D2957@oracle.com> Message-ID: <94B49859-0A3B-4AFA-8E54-978FB3D1EC28@oracle.com> > Stepping back a moment, what is the requirement for VM_ENTRY here? The compiler threads run concurrently with the GC. You get an oop from JNIHandles::resolve(call_site) and then load its klass. The GC may run in between, move objects around and when the klass is read, what you get may be garbage. > It does?t seem to make any real difference. In fact, the "Code Installation? time after applying the changes decreased by about 4% although it?s hard to say what the error bars are for this measurement. See the details of my mini-experiement at the end of this message. Thanks for doing the experiments. > I can understand that extracting the raw pointers from ciMetadata needs to be done carefully. However, the only difference this change makes is that it extracts the raw values earlier (i.e. as dependencies are recorded) instead of when they are serialized (in Dependencies::encode_content_bytes()). If we take your change as it is then it means the ciMetadata subtree of classes are effectively deprecated and should be removed. I wonder whether we want that or not. Roland. From doug.simon at oracle.com Mon Jan 20 14:52:21 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 20 Jan 2014 23:52:21 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: <94B49859-0A3B-4AFA-8E54-978FB3D1EC28@oracle.com> References: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> <4E9CEB56-BE25-4785-96AC-84FDE07D2957@oracle.com> <94B49859-0A3B-4AFA-8E54-978FB3D1EC28@oracle.com> Message-ID: <9BB16464-03B0-4A59-9CB6-EABDE86F8CFD@oracle.com> I?ve uploaded a new webrev to http://cr.openjdk.java.net/~dnsimon/JDK-8031639-v2/ One thing I?m not sure about is whether I?ve guarded assert_call_site_target_value properly now. Given that Graal calls this method while already in a VM_ENTRY, I don?t think I can blindly add VM_ENTRY_MARK here (or can the VM be entered recursively?). Unfortunately this means the non-Graal callers need to do their own VM_ENTRY_MARK. On Jan 20, 2014, at 10:57 PM, Roland Westrelin wrote: >> Stepping back a moment, what is the requirement for VM_ENTRY here? > > The compiler threads run concurrently with the GC. > You get an oop from JNIHandles::resolve(call_site) and then load its klass. The GC may run in between, move objects around and when the klass is read, what you get may be garbage. > >> It does?t seem to make any real difference. In fact, the "Code Installation? time after applying the changes decreased by about 4% although it?s hard to say what the error bars are for this measurement. See the details of my mini-experiement at the end of this message. > > Thanks for doing the experiments. > >> I can understand that extracting the raw pointers from ciMetadata needs to be done carefully. However, the only difference this change makes is that it extracts the raw values earlier (i.e. as dependencies are recorded) instead of when they are serialized (in Dependencies::encode_content_bytes()). > > If we take your change as it is then it means the ciMetadata subtree of classes are effectively deprecated and should be removed. I wonder whether we want that or not. You?re saying ciMethod, ciKlass, ciMethodData etc are no longer needed? I can?t imagine that?s true as they seemed to be used extensively. -Doug From david.holmes at oracle.com Mon Jan 20 19:01:54 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jan 2014 13:01:54 +1000 Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in need_compact3 test group In-Reply-To: <52DD1646.8030505@oracle.com> References: <52DD1646.8030505@oracle.com> Message-ID: <52DDE322.9060108@oracle.com> Hi Igor, On 20/01/2014 10:27 PM, Igor Ignatyev wrote: > Hi all, > > Please review patch: > > Problem: > tests 'compiler/tiered/NonTieredLevelsTest.java' and > 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group I don't see any direct JMX use in those tests. Is it coming in via the Whitebox API? That would be unfortunate. Thanks, David > Fix: > tests are added into 'need_compact3' > > webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8028482 From igor.ignatyev at oracle.com Tue Jan 21 01:41:45 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 21 Jan 2014 13:41:45 +0400 Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in need_compact3 test group In-Reply-To: <52DDE322.9060108@oracle.com> References: <52DD1646.8030505@oracle.com> <52DDE322.9060108@oracle.com> Message-ID: <52DE40D9.6090604@oracle.com> Hi David, Whitebox API itself doesn't use JMX, but CompilerWhiteBoxTest, super-class of these tests, uses it. Igor On 01/21/2014 07:01 AM, David Holmes wrote: > Hi Igor, > > On 20/01/2014 10:27 PM, Igor Ignatyev wrote: >> Hi all, >> >> Please review patch: >> >> Problem: >> tests 'compiler/tiered/NonTieredLevelsTest.java' and >> 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group > > I don't see any direct JMX use in those tests. Is it coming in via the > Whitebox API? That would be unfortunate. > > Thanks, > David > > >> Fix: >> tests are added into 'need_compact3' >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/ >> jbs: https://bugs.openjdk.java.net/browse/JDK-8028482 From david.holmes at oracle.com Tue Jan 21 03:55:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jan 2014 21:55:28 +1000 Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in need_compact3 test group In-Reply-To: <52DE40D9.6090604@oracle.com> References: <52DD1646.8030505@oracle.com> <52DDE322.9060108@oracle.com> <52DE40D9.6090604@oracle.com> Message-ID: <52DE6030.4090500@oracle.com> On 21/01/2014 7:41 PM, Igor Ignatyev wrote: > Hi David, > > Whitebox API itself doesn't use JMX, but CompilerWhiteBoxTest, > super-class of these tests, uses it. I see. That is unfortunate as it constrains the test environment for users of the Whitebox API even if they don't need the JMX part directly. Whomever owns this should see if they can rectify this some how. Thanks, David > Igor > > On 01/21/2014 07:01 AM, David Holmes wrote: >> Hi Igor, >> >> On 20/01/2014 10:27 PM, Igor Ignatyev wrote: >>> Hi all, >>> >>> Please review patch: >>> >>> Problem: >>> tests 'compiler/tiered/NonTieredLevelsTest.java' and >>> 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group >> >> I don't see any direct JMX use in those tests. Is it coming in via the >> Whitebox API? That would be unfortunate. >> >> Thanks, >> David >> >> >>> Fix: >>> tests are added into 'need_compact3' >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/ >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028482 From igor.ignatyev at oracle.com Tue Jan 21 05:04:33 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 21 Jan 2014 17:04:33 +0400 Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in need_compact3 test group In-Reply-To: <52DE6030.4090500@oracle.com> References: <52DD1646.8030505@oracle.com> <52DDE322.9060108@oracle.com> <52DE40D9.6090604@oracle.com> <52DE6030.4090500@oracle.com> Message-ID: <52DE7061.2050607@oracle.com> I will file an RFE to get rid of JMX in CompilerWhiteBoxTest. Can I count you as an reviewer? Igor On 01/21/2014 03:55 PM, David Holmes wrote: > On 21/01/2014 7:41 PM, Igor Ignatyev wrote: >> Hi David, >> >> Whitebox API itself doesn't use JMX, but CompilerWhiteBoxTest, >> super-class of these tests, uses it. > > I see. That is unfortunate as it constrains the test environment for > users of the Whitebox API even if they don't need the JMX part directly. > Whomever owns this should see if they can rectify this some how. > > Thanks, > David > >> Igor >> >> On 01/21/2014 07:01 AM, David Holmes wrote: >>> Hi Igor, >>> >>> On 20/01/2014 10:27 PM, Igor Ignatyev wrote: >>>> Hi all, >>>> >>>> Please review patch: >>>> >>>> Problem: >>>> tests 'compiler/tiered/NonTieredLevelsTest.java' and >>>> 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group >>> >>> I don't see any direct JMX use in those tests. Is it coming in via the >>> Whitebox API? That would be unfortunate. >>> >>> Thanks, >>> David >>> >>> >>>> Fix: >>>> tests are added into 'need_compact3' >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/ >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028482 From igor.ignatyev at oracle.com Tue Jan 21 05:05:57 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 21 Jan 2014 17:05:57 +0400 Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in need_compact3 test group In-Reply-To: <7584D6FF-25B8-40BD-AFF6-593BFBD341AB@oracle.com> References: <52DD1646.8030505@oracle.com> <7584D6FF-25B8-40BD-AFF6-593BFBD341AB@oracle.com> Message-ID: <52DE70B5.8020000@oracle.com> Roland/Staffan Thanks for reviewing this. Igor On 01/20/2014 10:02 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 20 jan 2014, at 17:21, Roland Westrelin wrote: > >>> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/ >> >> That looks good to me. >> >> Roland. >> > From igor.ignatyev at oracle.com Tue Jan 21 05:09:29 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 21 Jan 2014 17:09:29 +0400 Subject: RFR(XS) : 8027257 : [TESTBUG] compiler/ciReplay/TestVM.sh : Error: Could not find or load main class negative_test In-Reply-To: <6B1F6957-3700-4574-8399-F41E9C891BE4@oracle.com> References: <52DD292B.3010403@oracle.com> <6B1F6957-3700-4574-8399-F41E9C891BE4@oracle.com> Message-ID: <52DE7189.70909@oracle.com> Roland, Thanks for reviewing this. Could I get a second review for this? -- Igor On 01/20/2014 08:21 PM, Roland Westrelin wrote: >> webrev: http://cr.openjdk.java.net/~iignatyev/8027257/webrev.00/ > > That looks good to me. > > Roland. > From igor.ignatyev at oracle.com Tue Jan 21 05:10:51 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 21 Jan 2014 17:10:51 +0400 Subject: RFR (XS) : 8027124 : [TESTBUG] NonTieredLevelsTest: java.lang.RuntimeException: private TestCase$Helper(java.lang.Object) must be osr_compiled In-Reply-To: <52A4AFD7.7040302@oracle.com> References: <529CEFF2.3080505@oracle.com> <529CFBE4.4070309@oracle.com> <529D89DD.3060804@oracle.com> <529D8DBE.5090306@oracle.com> <52A49B4A.3030405@oracle.com> <52A4AFD7.7040302@oracle.com> Message-ID: <52DE71DB.6090608@oracle.com> Vladimir, thank you for the review. Can I get a second review for this? Igor On 12/08/2013 09:43 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 12/8/13 8:16 AM, Igor Ignatyev wrote: >> Vladimir, >> >> Thanks for review, I've added CompilerWhiteBoxTest::skipXcompOSR(), >> see updated webrev: >> http://cr.openjdk.java.net/~iignatyev/8027124/webrev.01/ >> >> I reran compiler/tiered and compiler/whitebox tests in Xcomp and >> Xmixed modes >> >> On 12/03/2013 11:52 AM, Vladimir Kozlov wrote: >>> On 12/2/13 11:35 PM, Igor Ignatyev wrote: >>>> Vladimir, >>>> >>>> > Why space needed "ed "? >>>> just to make sure that it's the begin of 'compiled mode' >>> >>> Okay. >>> >>>> >>>> > I don't think we should pollute output with messages which does not >>>> > help. Or this message is used to mark test passed? >>>> > >>>> no, it doesn't mark test as passed, it's just a warning message. I >>>> will wrap it w/ 'if (IS_VERBOSE)' statement. >>> >>> Okay. >>> >>>> >>>> It's the same code which is used in 'compiler/whitebox' tests (fix for >>>> JDK-8023452), so would you prefer me to change >>>> they in a similar way? >>> >>> Yes, please. Can you move checks and warning message into a separate >>> method and use it everywhere? Something like: >>> >>> if (CompilerWhiteBoxTest.skipTest(testCase)) { >>> return; >>> } >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> Igor >>>> >>>> On 12/03/2013 01:30 AM, Vladimir Kozlov wrote: >>>>> Don't split the line: >>>>> >>>>> + if (testCase.isOsr && CompilerWhiteBoxTest.MODE.startsWith( >>>>> + "compiled ")) { >>>>> >>>>> Why space needed "ed "? >>>>> >>>>> I don't think we should pollute output with messages which does not >>>>> help. Or this message is used to mark test passed? >>>>> >>>>> Add comment. >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 12/2/13 12:39 PM, Igor Ignatyev wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review patch. >>>>>> >>>>>> Problem: >>>>>> OSR test cases in 'compiler/tiered' tests are not applicable in >>>>>> -Xcomp >>>>>> mode, since there is no way to provoke OSR compilation >>>>>> >>>>>> Fix: >>>>>> Added skipping of OSR test cases, if -Xcomp is enabled >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8027124/webrev.00/ >>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8027124 >>>>>> testing: compiler/tiered in -Xcomp, -Xmixed, -Xint and default mode From roland.westrelin at oracle.com Tue Jan 21 05:31:54 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 21 Jan 2014 14:31:54 +0100 Subject: RFR (XS) : 8027124 : [TESTBUG] NonTieredLevelsTest: java.lang.RuntimeException: private TestCase$Helper(java.lang.Object) must be osr_compiled In-Reply-To: <52A49B4A.3030405@oracle.com> References: <529CEFF2.3080505@oracle.com> <529CFBE4.4070309@oracle.com> <529D89DD.3060804@oracle.com> <529D8DBE.5090306@oracle.com> <52A49B4A.3030405@oracle.com> Message-ID: <4A12F804-D4F9-4FE4-A394-F78DD3CD2341@oracle.com> > Thanks for review, I've added CompilerWhiteBoxTest::skipXcompOSR(), see updated webrev: > http://cr.openjdk.java.net/~iignatyev/8027124/webrev.01/ That looks good to me. Roland. From roland.westrelin at oracle.com Tue Jan 21 08:19:59 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 21 Jan 2014 17:19:59 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: <9BB16464-03B0-4A59-9CB6-EABDE86F8CFD@oracle.com> References: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> <4E9CEB56-BE25-4785-96AC-84FDE07D2957@oracle.com> <94B49859-0A3B-4AFA-8E54-978FB3D1EC28@oracle.com> <9BB16464-03B0-4A59-9CB6-EABDE86F8CFD@oracle.com> Message-ID: > You?re saying ciMethod, ciKlass, ciMethodData etc are no longer needed? I can?t imagine that?s true as they seemed to be used extensively. C1 & C2 run concurrently with GCs as much as possible. This is achieved through the CI machinery. The CI objects mirror actual objects of the JVM and they cache information useful to the compilers. So most of the time, the compilers only work with the CI objects. If the compilers need something that is not cached in a CI object, they need access to the actual underlying JVM object, and then the compilers must ?enter the VM? and become subject to the GC. Before permgen removal, Klasses and Methods and MethodDatas could move as well. That?s why the ciMethod, ciKlass etc exist. Now that the permgen is gone, Klasses and Methods can?t move anymore and ciMethod, ciKlass etc. lost a big part of their reason for existence. That?s also why it?s ok to call get_Method() or get_Klass() on a ciMethod or ciKlass in your patch without ?entering the VM?. But it?s not the pattern that the rest of the code follows. So yes, ciMethod and friends are used all over the place. But whether it is only for historical reasons (it was easier during the switch to no perm gen to keep them around) or because we think they have actual value is unclear to me. FWIW I played with an alternate way of doing this: wrap the CI objects in a DepValue earlier and make the core of the Dependencies code work only with DepValue objects: http://cr.openjdk.java.net/~roland/dependencies/webrev/ Similarly: void assert_evol_method(Method* m); void assert_leaf_type(Klass* ctxk); void assert_abstract_with_unique_concrete_subtype(Klass* ctxk, Klass* conck); void assert_abstract_with_no_concrete_subtype(Klass* ctxk); void assert_concrete_with_no_concrete_subtype(Klass* ctxk); void assert_unique_concrete_method(Klass* ctxk, Method* uniqm); void assert_abstract_with_exclusive_concrete_subtypes(Klass* ctxk, Klass* k1, Klass* k2); void assert_exclusive_concrete_methods(Klass* ctxk, Method* m1, Method* m2); void assert_has_no_finalizable_subclasses(Klass* ctxk); void assert_call_site_target_value(jobject call_site, jobject method_handle); Could be implemented so they wrap Method*, Klass* etc in DepValue objects and DepValue::is_instance_klass() etc. could be implemented to work with Metadata* and jobject. I wonder if templates could be used after refactoring the Dependencies class. Roland. From doug.simon at oracle.com Tue Jan 21 08:56:29 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 21 Jan 2014 17:56:29 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: References: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> <4E9CEB56-BE25-4785-96AC-84FDE07D2957@oracle.com> <94B49859-0A3B-4AFA-8E54-978FB3D1EC28@oracle.com> <9BB16464-03B0-4A59-9CB6-EABDE86F8CFD@oracle.com> Message-ID: <83FE2BE7-2AF9-4597-9245-1E6BCA00F52A@oracle.com> On Jan 21, 2014, at 5:19 PM, Roland Westrelin wrote: >> You?re saying ciMethod, ciKlass, ciMethodData etc are no longer needed? I can?t imagine that?s true as they seemed to be used extensively. > > C1 & C2 run concurrently with GCs as much as possible. This is achieved through the CI machinery. The CI objects mirror actual objects of the JVM and they cache information useful to the compilers. So most of the time, the compilers only work with the CI objects. If the compilers need something that is not cached in a CI object, they need access to the actual underlying JVM object, and then the compilers must ?enter the VM? and become subject to the GC. Before permgen removal, Klasses and Methods and MethodDatas could move as well. That?s why the ciMethod, ciKlass etc exist. Now that the permgen is gone, Klasses and Methods can?t move anymore and ciMethod, ciKlass etc. lost a big part of their reason for existence. That?s also why it?s ok to call get_Method() or get_Klass() on a ciMethod or ciKlass in your patch without ?entering the VM?. But it?s not the pattern that the rest of the code follows. > > So yes, ciMethod and friends are used all over the place. But whether it is only for historical reasons (it was easier during the switch to no perm gen to keep them around) or because we think they have actual value is unclear to me. I?ll leave that discussion/decision to the more experienced. However, getting rid of an abstraction that only serves a historic purpose sounds like an excellent idea! > FWIW I played with an alternate way of doing this: wrap the CI objects in a DepValue earlier and make the core of the Dependencies code work only with DepValue objects: > > http://cr.openjdk.java.net/~roland/dependencies/webrev/ 102 uint ident() const { 103 switch(type()) { 104 case dep_ci_object: 105 return ci_obj()->ident(); 106 case dep_metadata: 107 case dep_jobject: 108 default: 109 fatal("unexpected type"); 110 } 111 } I assume that lines 106 and 107 above are incomplete. How would you compute an ident for these values and ensure the indents for each of the 3 DepValue types don?t clash with each other? Or are you relying on a Dependencies client to either be using dep_ci_object (e.g., c1 and c2) or dep_metadata and dep_jobject (e.g., Graal) and the client ensures that ident values are unique for all DepValues added to a Dependencies object? > > Similarly: > > void assert_evol_method(Method* m); > void assert_leaf_type(Klass* ctxk); > void assert_abstract_with_unique_concrete_subtype(Klass* ctxk, Klass* conck); > void assert_abstract_with_no_concrete_subtype(Klass* ctxk); > void assert_concrete_with_no_concrete_subtype(Klass* ctxk); > void assert_unique_concrete_method(Klass* ctxk, Method* uniqm); > void assert_abstract_with_exclusive_concrete_subtypes(Klass* ctxk, Klass* k1, Klass* k2); > void assert_exclusive_concrete_methods(Klass* ctxk, Method* m1, Method* m2); > void assert_has_no_finalizable_subclasses(Klass* ctxk); > void assert_call_site_target_value(jobject call_site, jobject method_handle); > > Could be implemented so they wrap Method*, Klass* etc in DepValue objects and DepValue::is_instance_klass() etc. could be implemented to work with Metadata* and jobject. Maybe you could hum a few bars on the advantages of this approach? Is it mainly about avoiding all VM_ENTRY concerns? -Doug From john.r.rose at oracle.com Tue Jan 21 11:25:32 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 21 Jan 2014 11:25:32 -0800 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: References: <52D6A9B8.2040906@oracle.com> <0DA570E9-814A-44B5-8CDA-6F7C9A92B423@oracle.com> <52D6E455.4050607@oracle.com> Message-ID: On Jan 15, 2014, at 6:49 PM, Christian Thalinger wrote: > John would know the answer. > > Given this change should go into JDK 8 I think we should push for now. If we can come up with a better way to handle these situations we can push another change for 9 or 8u20. (Back from vacation.) Vladimir's change for bytecode generation is safe. It assumes something stable, which is that virtual invocation mode can apply to interfaces only because they inherit Object. Therefore we can back off from invokevirtual to invokeinterface, without changing behavior. FTR, this fix may be redundant with this changeset: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/9063bd8808a7 ...and specifically with the line of code which says "m_klass = m_klass_non_interface". This redundancy is of the belt-and-suspenders kind; it could be changed to an assert, but is fine the way it is. Thanks for fixing this! ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140121/37ace1e3/attachment-0001.html From aleksey.shipilev at oracle.com Tue Jan 21 14:47:23 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 22 Jan 2014 02:47:23 +0400 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction Message-ID: <52DEF8FB.3020707@oracle.com> Hi, Please review the experimental patch for switching the research VM mode which unconditionally emits the memory barrier at the end of constructor: http://cr.openjdk.java.net/~shade/8031818/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8031818 This would be convenient to have in mainline, because it will also propagate to another arch ports (notably PPC C2 port), and will ease the performance research for the upcoming JMM update. Thanks, -Aleksey. From vladimir.kozlov at oracle.com Tue Jan 21 15:25:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jan 2014 15:25:31 -0800 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> <52D84DC0.7030609@oracle.com> <9E69EF09-B3A5-42CC-8480-1A5C2CBF2375@oracle.com> <52D963DC.8000301@oracle.com> Message-ID: <52DF01EB.3040506@oracle.com> On 1/20/14 2:28 AM, Roland Westrelin wrote: > Here is a new webrev with Chris? suggestions: > > http://cr.openjdk.java.net/~roland/8031752/webrev.02/ > > Vladimir, I didn?t include your suggestion because as you mention trap_recompiled_at() needs the method argument. Okay. Looks fine. Vladimir > > Roland. > > On Jan 17, 2014, at 6:09 PM, Vladimir Kozlov wrote: > >> Sorry, I was not clear. I suggested to move next reason check >> >> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >> + if (md->has_trap_at(bci, m, reason) != 0) { >> >> inside has_trap_at(): >> >> int has_trap_at(int bci, ciMethod* m, int reason) { >> if (!Deoptimization::reason_is_speculate(reason)) { >> m = NULL; >> } >> return has_trap_at(bci_to_data(bci, m), reason); >> } >> >> and path method always: >> >> + if (md->has_trap_at(bci, this->method(), reason) != 0) { >> >> The are 2 places where you do that. But I see that in the second case 'm' is also passed to trap_recompiled_at(). So my suggestion may be not good. IT is up to you. >> >> Thanks, >> Vladimir >> >> On 1/17/14 5:03 AM, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>> Thanks for taking a loot at this. >>> >>>> Can you pass method to has_trap_at() and check the reason inside instead of current assert? >>> >>> Sorry, but I don?t understand what change you?d like to see. >>> Is this the assert you?re talking about: >>> >>> int has_trap_at(int bci, ciMethod* m, int reason) { >>> assert((m != NULL) == Deoptimization::reason_is_speculate(reason), "inconsistent method/reason"); >>> return has_trap_at(bci_to_data(bci, m), reason); >>> } >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/16/14 8:32 AM, Roland Westrelin wrote: >>>>> Thanks for reviewing this, Chris. >>>>> >>>>> Here is a new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~roland/8031752/webrev.01/ >>>>> >>>>> And comments below: >>>>> >>>>>> All these print_data_on changes are a pain: >>>>>> >>>>>> ! virtual void print_data_on(outputStream* st, const char* extra) const { >>>>>> >>>>>> I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? >>>>> >>>>> I want the speculative traps to be listed together with the byte code they affect. Diagnosing a missed optimization is much easier that way. Here is an example output: >>>>> >>>>> 6 ldc_w TestTrapSpeculate$B >>>>> 9 if_acmpne 19 >>>>> 64 bci: 9 BranchData trap(class_check recompiled) trap/ TestTrapSpeculate::m2(class_check recompiled) trap/ TestTrapSpeculate::m1(class_check recompiled) >>>>> not taken(10) >>>>> 12 fast_aload_0 >>>>> >>>>> But the speculative traps are not stored with the ProfileData for each byte code. So I need to pass something to each ProfileData::print_data_on() that can be used to print the speculative traps. I decided to pass a formatted string with the trap stuff. Which is then passed to ProfileData::print_shared() where the per byte code line is printed. >>>>> >>>>>> src/share/vm/oops/methodData.cpp: >>>>>> >>>>>> + case Bytecodes::_invokestatic: >>>>>> + return UseTypeSpeculation; >>>>>> + } >>>>>> + return false; >>>>>> >>>>>> Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). >>>>> >>>>> Ok. >>>>> >>>>>> >>>>>> int empty_bc_count = 0; // number of bytecodes lacking data >>>>>> + bool has_spec_bc = false; >>>>>> >>>>>> That name is hard to understand for people new to the code. At least the first ugly name has a comment. >>>>> >>>>> Would needs_speculative_traps be better? >>>>> >>>>>> >>>>>> + DataLayout* MethodData::next_extra(DataLayout* dp) { >>>>>> + int nb_cells = 0; >>>>>> + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { >>>>>> + nb_cells = BitData::static_cell_count(); >>>>>> + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { >>>>>> + nb_cells = SpeculativeTrapData::static_cell_count(); >>>>>> + } else { >>>>>> + fatal(err_msg("unexpected tag %d", dp->tag())); >>>>>> + } >>>>>> >>>>>> It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: >>>>>> >>>>>> assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); >>>>>> >>>>>> is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. >>>>> >>>>> Ok. So I tried to use switches when iterating over the extra data everywhere. The problem is that break, breaks out of the switch but not out of the loop anymore. The new MethodData::next_extra() doesn?t know how to move past a arg_info_data_tag because it?s a static method. It?s a static method because it?s used by ciMethodData as well. So I need to break out of the loop before calling the last MethodData::next_extra(). Anyway, I refactored the code so that the loops are in their own methods and then I can return from them to jump out of the switch and loop. >>>>> >>>>>> >>>>>> src/share/vm/opto/compile.cpp: >>>>>> >>>>>> ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { >>>>>> >>>>>> Can you factor this to a local variable as you do later: >>>>>> >>>>>> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >>>>>> if ((per_bc_reason == Deoptimization::Reason_none >>>>>> ! || md->has_trap_at(bci, m, reason) != 0) >>>>>> >>>>>> ? >>>>>> >>>>> >>>>> Ok. >>>>> >>>>>> src/share/vm/runtime/globals.hpp: >>>>>> >>>>>> + product(intx, PerMethodSpecTrapLimit, 5000, \ >>>>>> + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ >>>>>> >>>>>> + product(intx, SpecTrapLimitExtraEntries, 3, \ >>>>>> + "Extra method data trap entries for speculation") \ >>>>>> >>>>>> Do we need these new flags to be product flags? >>>>> >>>>> At this point, it?s unclear whether those values are going to be good enough so I think we need to be able to adjust the parameters in benchmark runs. >>>>> >>>>>> src/share/vm/ci/ciMethodData.cpp: >>>>>> >>>>>> ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { >>>>>> ! st->print_cr("Parametertypes"); >>>>>> ! st->print_cr("ciParameterTypesData?); >>>>>> >>>>>> Typo replaced with a typo :-) >>>>> >>>>> Indeed. >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ >>>>>>> >>>>>>> When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). >>>>>>> >>>>>>> If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. >>>>>>> >>>>>>> When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. >>>>>>> >>>>>>> With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. >>>>>>> >>>>>>> This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. >>>>>>> >>>>>>> I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. >>>>>>> >>>>>>> I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>> >>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Tue Jan 21 15:27:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jan 2014 15:27:30 -0800 Subject: RFR(XS) : 8027257 : [TESTBUG] compiler/ciReplay/TestVM.sh : Error: Could not find or load main class negative_test In-Reply-To: <52DD292B.3010403@oracle.com> References: <52DD292B.3010403@oracle.com> Message-ID: <52DF0262.1070306@oracle.com> Looks good. Thanks, Vladimir On 1/20/14 5:48 AM, Igor Ignatyev wrote: > Hi all, > > Please review patch: > > Problem: > - there's odd 'negative_test ...' line in common.sh > - 'cleanup' doesn't execute after each iteration of stop_level-loop in > TestVM.sh > > Fix: > - the redundant line is removed > - 'cleanup' is moved into the loop > > webrev: http://cr.openjdk.java.net/~iignatyev/8027257/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8027257 From david.holmes at oracle.com Tue Jan 21 17:49:18 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2014 11:49:18 +1000 Subject: RFR(XS) : 8028482 : [TESTBUG] tests that use JMX should be in need_compact3 test group In-Reply-To: <52DE7061.2050607@oracle.com> References: <52DD1646.8030505@oracle.com> <52DDE322.9060108@oracle.com> <52DE40D9.6090604@oracle.com> <52DE6030.4090500@oracle.com> <52DE7061.2050607@oracle.com> Message-ID: <52DF239E.1010507@oracle.com> On 21/01/2014 11:04 PM, Igor Ignatyev wrote: > I will file an RFE to get rid of JMX in CompilerWhiteBoxTest. Thanks. Will need to remember to revert this change then too. > Can I count you as an reviewer? Yes - sorry that wasn't clear. Thanks, David > Igor > > On 01/21/2014 03:55 PM, David Holmes wrote: >> On 21/01/2014 7:41 PM, Igor Ignatyev wrote: >>> Hi David, >>> >>> Whitebox API itself doesn't use JMX, but CompilerWhiteBoxTest, >>> super-class of these tests, uses it. >> >> I see. That is unfortunate as it constrains the test environment for >> users of the Whitebox API even if they don't need the JMX part directly. >> Whomever owns this should see if they can rectify this some how. >> >> Thanks, >> David >> >>> Igor >>> >>> On 01/21/2014 07:01 AM, David Holmes wrote: >>>> Hi Igor, >>>> >>>> On 20/01/2014 10:27 PM, Igor Ignatyev wrote: >>>>> Hi all, >>>>> >>>>> Please review patch: >>>>> >>>>> Problem: >>>>> tests 'compiler/tiered/NonTieredLevelsTest.java' and >>>>> 'TieredLevelsTest.java' use JMX, but not in 'need_compact3' test group >>>> >>>> I don't see any direct JMX use in those tests. Is it coming in via the >>>> Whitebox API? That would be unfortunate. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Fix: >>>>> tests are added into 'need_compact3' >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8028482/webrev.00/ >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028482 From dean.long at oracle.com Tue Jan 21 19:00:14 2014 From: dean.long at oracle.com (Dean Long) Date: Tue, 21 Jan 2014 19:00:14 -0800 Subject: RFR(S) 8031743: C2: loadI2L_immI broken for negative memory values In-Reply-To: <70865AB1-78E8-4755-BD59-2034B3A28519@oracle.com> References: <2508E0EE-D01C-4DF3-A26B-D20F7F8480BA@oracle.com> <52DAEBFC.5050401@oracle.com> <52DAF070.5050404@oracle.com> <70865AB1-78E8-4755-BD59-2034B3A28519@oracle.com> Message-ID: <52DF343E.3080702@oracle.com> If you still need another review: it looks good. dl On 1/18/2014 5:48 PM, Igor Veresov wrote: > Here?s the updated review: http://cr.openjdk.java.net/~iveresov/8031743/webrev.01/ > > igor > > On Jan 18, 2014, at 1:21 PM, Vladimir Kozlov wrote: > >> Integer positive fits into 31 bits not into 32. >> >> Vladimir >> >> On 1/18/14 1:18 PM, Igor Veresov wrote: >>> We have this convention already in quite some places, so I was trying to follow it... For example on sparc there is immU13, which actually means simm13 & >= 0, which means it?s actually 12 bit. Likewise on ARM we have immURot that works that same way. So, the way these things go, I think, is that immUX means: fits in X bits and is positive. >>> >>> igor >>> >>> On Jan 18, 2014, at 1:02 PM, Vladimir Kozlov wrote: >>> >>>> immU32 name is not correct, it should be immU31. >>>> >>>> Vladimir K >>>> >>>> On 1/18/14 12:51 PM, Igor Veresov wrote: >>>>> Transformation of (ConvI2L (AndI (LoadI mem) mask)) to (AndI (LoadUI2L (mem) mask) is only valid for positive mask, otherwise the sign extending effect of ConvI2L is missed. The solution is to restrict the optimization for the positive values of mask. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8031743/webrev.00/ >>>>> Testing: new regression test, jprt >>>>> >>>>> Thanks! >>>>> igor >>>>> From igor.veresov at oracle.com Tue Jan 21 20:03:21 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 21 Jan 2014 20:03:21 -0800 Subject: RFR(S) 8031743: C2: loadI2L_immI broken for negative memory values In-Reply-To: <52DF343E.3080702@oracle.com> References: <2508E0EE-D01C-4DF3-A26B-D20F7F8480BA@oracle.com> <52DAEBFC.5050401@oracle.com> <52DAF070.5050404@oracle.com> <70865AB1-78E8-4755-BD59-2034B3A28519@oracle.com> <52DF343E.3080702@oracle.com> Message-ID: <36097384-1167-439D-BA94-1B1687411848@oracle.com> Thanks, Dean! igor On Jan 21, 2014, at 7:00 PM, Dean Long wrote: > If you still need another review: it looks good. > > dl > > On 1/18/2014 5:48 PM, Igor Veresov wrote: >> Here?s the updated review: http://cr.openjdk.java.net/~iveresov/8031743/webrev.01/ >> >> igor >> >> On Jan 18, 2014, at 1:21 PM, Vladimir Kozlov wrote: >> >>> Integer positive fits into 31 bits not into 32. >>> >>> Vladimir >>> >>> On 1/18/14 1:18 PM, Igor Veresov wrote: >>>> We have this convention already in quite some places, so I was trying to follow it... For example on sparc there is immU13, which actually means simm13 & >= 0, which means it?s actually 12 bit. Likewise on ARM we have immURot that works that same way. So, the way these things go, I think, is that immUX means: fits in X bits and is positive. >>>> >>>> igor >>>> >>>> On Jan 18, 2014, at 1:02 PM, Vladimir Kozlov wrote: >>>> >>>>> immU32 name is not correct, it should be immU31. >>>>> >>>>> Vladimir K >>>>> >>>>> On 1/18/14 12:51 PM, Igor Veresov wrote: >>>>>> Transformation of (ConvI2L (AndI (LoadI mem) mask)) to (AndI (LoadUI2L (mem) mask) is only valid for positive mask, otherwise the sign extending effect of ConvI2L is missed. The solution is to restrict the optimization for the positive values of mask. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8031743/webrev.00/ >>>>>> Testing: new regression test, jprt >>>>>> >>>>>> Thanks! >>>>>> igor >>>>>> > From vladimir.kozlov at oracle.com Tue Jan 21 21:10:43 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jan 2014 21:10:43 -0800 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52DEF8FB.3020707@oracle.com> References: <52DEF8FB.3020707@oracle.com> Message-ID: <52DF52D3.2000906@oracle.com> May be we should use bitset enums to record types of stores to fields. Next changes touch the same C2 code: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/c6d7e7406136 It uses method()->is_initializer() instead of (method()->name() == ciSymbol::object_initializer_name()). The main problem that new flag check will be executed always. It will not be optimized by C++. Regards, Vladimir On 1/21/14 2:47 PM, Aleksey Shipilev wrote: > Hi, > > Please review the experimental patch for switching the research VM mode > which unconditionally emits the memory barrier at the end of constructor: > http://cr.openjdk.java.net/~shade/8031818/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8031818 > > This would be convenient to have in mainline, because it will also > propagate to another arch ports (notably PPC C2 port), and will ease the > performance research for the upcoming JMM update. > > Thanks, > -Aleksey. > From vladimir.kozlov at oracle.com Wed Jan 22 00:07:07 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 00:07:07 -0800 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52DF52D3.2000906@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> Message-ID: <52DF7C2B.70200@oracle.com> On 1/21/14 9:10 PM, Vladimir Kozlov wrote: > May be we should use bitset enums to record types of stores to fields. Next changes touch the same C2 code: > > http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/c6d7e7406136 > > It uses method()->is_initializer() instead of (method()->name() == ciSymbol::object_initializer_name()). > > The main problem that new flag check will be executed always. It will not be optimized by C++. On other hand we already have experimental flags (for example, AggressiveUnboxing) so it is not big deal. Vladimir > > Regards, > Vladimir > > On 1/21/14 2:47 PM, Aleksey Shipilev wrote: >> Hi, >> >> Please review the experimental patch for switching the research VM mode >> which unconditionally emits the memory barrier at the end of constructor: >> http://cr.openjdk.java.net/~shade/8031818/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8031818 >> >> This would be convenient to have in mainline, because it will also >> propagate to another arch ports (notably PPC C2 port), and will ease the >> performance research for the upcoming JMM update. >> >> Thanks, >> -Aleksey. >> From roland.westrelin at oracle.com Wed Jan 22 00:20:10 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 22 Jan 2014 09:20:10 +0100 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: <52DF01EB.3040506@oracle.com> References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> <52D84DC0.7030609@oracle.com> <9E69EF09-B3A5-42CC-8480-1A5C2CBF2375@oracle.com> <52D963DC.8000301@oracle.com> <52DF01EB.3040506@oracle.com> Message-ID: >> Here is a new webrev with Chris? suggestions: >> >> http://cr.openjdk.java.net/~roland/8031752/webrev.02/ >> >> Vladimir, I didn?t include your suggestion because as you mention trap_recompiled_at() needs the method argument. > > Okay. Looks fine. Thanks for the review, Vladimir. Roland. > > Vladimir > >> >> Roland. >> >> On Jan 17, 2014, at 6:09 PM, Vladimir Kozlov wrote: >> >>> Sorry, I was not clear. I suggested to move next reason check >>> >>> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >>> + if (md->has_trap_at(bci, m, reason) != 0) { >>> >>> inside has_trap_at(): >>> >>> int has_trap_at(int bci, ciMethod* m, int reason) { >>> if (!Deoptimization::reason_is_speculate(reason)) { >>> m = NULL; >>> } >>> return has_trap_at(bci_to_data(bci, m), reason); >>> } >>> >>> and path method always: >>> >>> + if (md->has_trap_at(bci, this->method(), reason) != 0) { >>> >>> The are 2 places where you do that. But I see that in the second case 'm' is also passed to trap_recompiled_at(). So my suggestion may be not good. IT is up to you. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/17/14 5:03 AM, Roland Westrelin wrote: >>>> Hi Vladimir, >>>> >>>> Thanks for taking a loot at this. >>>> >>>>> Can you pass method to has_trap_at() and check the reason inside instead of current assert? >>>> >>>> Sorry, but I don?t understand what change you?d like to see. >>>> Is this the assert you?re talking about: >>>> >>>> int has_trap_at(int bci, ciMethod* m, int reason) { >>>> assert((m != NULL) == Deoptimization::reason_is_speculate(reason), "inconsistent method/reason"); >>>> return has_trap_at(bci_to_data(bci, m), reason); >>>> } >>>> >>>> Roland. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/16/14 8:32 AM, Roland Westrelin wrote: >>>>>> Thanks for reviewing this, Chris. >>>>>> >>>>>> Here is a new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~roland/8031752/webrev.01/ >>>>>> >>>>>> And comments below: >>>>>> >>>>>>> All these print_data_on changes are a pain: >>>>>>> >>>>>>> ! virtual void print_data_on(outputStream* st, const char* extra) const { >>>>>>> >>>>>>> I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? >>>>>> >>>>>> I want the speculative traps to be listed together with the byte code they affect. Diagnosing a missed optimization is much easier that way. Here is an example output: >>>>>> >>>>>> 6 ldc_w TestTrapSpeculate$B >>>>>> 9 if_acmpne 19 >>>>>> 64 bci: 9 BranchData trap(class_check recompiled) trap/ TestTrapSpeculate::m2(class_check recompiled) trap/ TestTrapSpeculate::m1(class_check recompiled) >>>>>> not taken(10) >>>>>> 12 fast_aload_0 >>>>>> >>>>>> But the speculative traps are not stored with the ProfileData for each byte code. So I need to pass something to each ProfileData::print_data_on() that can be used to print the speculative traps. I decided to pass a formatted string with the trap stuff. Which is then passed to ProfileData::print_shared() where the per byte code line is printed. >>>>>> >>>>>>> src/share/vm/oops/methodData.cpp: >>>>>>> >>>>>>> + case Bytecodes::_invokestatic: >>>>>>> + return UseTypeSpeculation; >>>>>>> + } >>>>>>> + return false; >>>>>>> >>>>>>> Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). >>>>>> >>>>>> Ok. >>>>>> >>>>>>> >>>>>>> int empty_bc_count = 0; // number of bytecodes lacking data >>>>>>> + bool has_spec_bc = false; >>>>>>> >>>>>>> That name is hard to understand for people new to the code. At least the first ugly name has a comment. >>>>>> >>>>>> Would needs_speculative_traps be better? >>>>>> >>>>>>> >>>>>>> + DataLayout* MethodData::next_extra(DataLayout* dp) { >>>>>>> + int nb_cells = 0; >>>>>>> + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { >>>>>>> + nb_cells = BitData::static_cell_count(); >>>>>>> + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { >>>>>>> + nb_cells = SpeculativeTrapData::static_cell_count(); >>>>>>> + } else { >>>>>>> + fatal(err_msg("unexpected tag %d", dp->tag())); >>>>>>> + } >>>>>>> >>>>>>> It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: >>>>>>> >>>>>>> assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); >>>>>>> >>>>>>> is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. >>>>>> >>>>>> Ok. So I tried to use switches when iterating over the extra data everywhere. The problem is that break, breaks out of the switch but not out of the loop anymore. The new MethodData::next_extra() doesn?t know how to move past a arg_info_data_tag because it?s a static method. It?s a static method because it?s used by ciMethodData as well. So I need to break out of the loop before calling the last MethodData::next_extra(). Anyway, I refactored the code so that the loops are in their own methods and then I can return from them to jump out of the switch and loop. >>>>>> >>>>>>> >>>>>>> src/share/vm/opto/compile.cpp: >>>>>>> >>>>>>> ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { >>>>>>> >>>>>>> Can you factor this to a local variable as you do later: >>>>>>> >>>>>>> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >>>>>>> if ((per_bc_reason == Deoptimization::Reason_none >>>>>>> ! || md->has_trap_at(bci, m, reason) != 0) >>>>>>> >>>>>>> ? >>>>>>> >>>>>> >>>>>> Ok. >>>>>> >>>>>>> src/share/vm/runtime/globals.hpp: >>>>>>> >>>>>>> + product(intx, PerMethodSpecTrapLimit, 5000, \ >>>>>>> + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ >>>>>>> >>>>>>> + product(intx, SpecTrapLimitExtraEntries, 3, \ >>>>>>> + "Extra method data trap entries for speculation") \ >>>>>>> >>>>>>> Do we need these new flags to be product flags? >>>>>> >>>>>> At this point, it?s unclear whether those values are going to be good enough so I think we need to be able to adjust the parameters in benchmark runs. >>>>>> >>>>>>> src/share/vm/ci/ciMethodData.cpp: >>>>>>> >>>>>>> ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { >>>>>>> ! st->print_cr("Parametertypes"); >>>>>>> ! st->print_cr("ciParameterTypesData?); >>>>>>> >>>>>>> Typo replaced with a typo :-) >>>>>> >>>>>> Indeed. >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ >>>>>>>> >>>>>>>> When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). >>>>>>>> >>>>>>>> If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. >>>>>>>> >>>>>>>> When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. >>>>>>>> >>>>>>>> With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. >>>>>>>> >>>>>>>> This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. >>>>>>>> >>>>>>>> I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. >>>>>>>> >>>>>>>> I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From forax at univ-mlv.fr Wed Jan 22 00:44:13 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 22 Jan 2014 09:44:13 +0100 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52DEF8FB.3020707@oracle.com> References: <52DEF8FB.3020707@oracle.com> Message-ID: <52DF84DD.6050500@univ-mlv.fr> On 01/21/2014 11:47 PM, Aleksey Shipilev wrote: > Hi, > > Please review the experimental patch for switching the research VM mode > which unconditionally emits the memory barrier at the end of constructor: > http://cr.openjdk.java.net/~shade/8031818/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8031818 > > This would be convenient to have in mainline, because it will also > propagate to another arch ports (notably PPC C2 port), and will ease the > performance research for the upcoming JMM update. > > Thanks, > -Aleksey. My mail is a little OT but anyway, Aleksey, I don't understand why the performance are not mostly identical. Correct me if I'm wrong, for TSO architecture, you basically do nothing so no impact. For ARM or PPC, you need a barrier but anyway you need to emit a barrier when you store the class pointer in the header of the object, so it should not perf at all the JIT is able to see that the class pointer is not read in the constructor (if 'this' doesn't escape and no invokevirtual/invokeinterface/instanceof etc). cheers, R?mi From aleksey.shipilev at oracle.com Wed Jan 22 01:12:03 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 22 Jan 2014 13:12:03 +0400 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52DF84DD.6050500@univ-mlv.fr> References: <52DEF8FB.3020707@oracle.com> <52DF84DD.6050500@univ-mlv.fr> Message-ID: <52DF8B63.2060700@oracle.com> Hi Remi, On 01/22/2014 12:44 PM, Remi Forax wrote: > My mail is a little OT but anyway, Aleksey, I don't understand why the > performance are not mostly identical. ...modulo quality of implementation issues. Rigorously quantify the real-world impact is the rationale of introducing this experimental feature in the mainline VM. This is what we learned so far (in progress; so unless you are really anxious and bored, don't read it yet): http://shipilev.net/blog/2014/all-fields-are-final/ > Correct me if I'm wrong, for TSO architecture, you basically do nothing > so no impact. Right, but also prohibit the compiler reorderings, which can matter. > For ARM or PPC, you need a barrier but anyway you need to > emit a barrier when you store the class pointer in the header of the > object, so it should not perf at all the JIT is able to see that the > class pointer is not read in the constructor There is also the tidbit: securing the field stores with StoreStore is arguably not enough, which is why C2 emits MemBarRelease (LoadStore+StoreStore) at the end of constructor. It is heavier than ordinary StoreStore, at least for ARMs. Anyhow, fixing this requires StoreStore/(LoadStore+StoreStore) barrier coalescing logic, which is still missing. The performance model in the absence of smart optimizing compiler is still of interest in spec work. More on that later. -Aleksey. From aleksey.shipilev at oracle.com Wed Jan 22 01:19:43 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 22 Jan 2014 13:19:43 +0400 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52DF7C2B.70200@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> Message-ID: <52DF8D2F.1030507@oracle.com> Thanks, Vladimir! On 01/22/2014 12:07 PM, Vladimir Kozlov wrote: > On 1/21/14 9:10 PM, Vladimir Kozlov wrote: >> May be we should use bitset enums to record types of stores to fields. And the benefit is? I come from the notion Parse is a throw-away instance anyhow, do we actually care for additional transient byte of footprint per compilation? >> Next changes touch the same C2 code: >> >> http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/c6d7e7406136 >> >> It uses method()->is_initializer() instead of (method()->name() == >> ciSymbol::object_initializer_name()). Copied from C1 code, and I agree "method()->is_initializer()" seems more readable, although it also matches the static initializers. Unless there is a readability concern, I'd rather leave it as is to match C1 behavior. >> The main problem that new flag check will be executed always. It will >> not be optimized by C++. > > On other hand we already have experimental flags (for example, > AggressiveUnboxing) so it is not big deal. That's what I'm thinking as well. -Aleksey. From roland.westrelin at oracle.com Wed Jan 22 01:42:06 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 22 Jan 2014 10:42:06 +0100 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method Message-ID: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> When a node already has a speculative type, and parsing encounters extra profiling data, the new profiling data is ignored. So profiling data coming from profile points closer to the root of the compilation is favored which I think makes sense: it's the data that is most specific to the context of this compilation. During runs, profile data is not always entirely coherent so we may hit something like this: m1() { m3(); } m() { m1(); m2(); } With: m3() and m2() have profile data for the same node. The first profile data to be encountered during parsing is from m3() and profile data from m2() is ignored but profile data from m2() is the one that is actually the most specific and is the one that should be favored. When a speculative type is created, this change records the inline depth at which the profile point is. The inline depth is then propagated together with the rest of the type information. When new profile data is available for a node that already has a speculative type, the current inline depth and the inline depth of the current speculative type are used to decide whether the new data should be used to replace the existing speculative type. This change helps stabilize performance with nashorn. http://cr.openjdk.java.net/~roland/8031754/webrev.00/ Roland. From vladimir.kozlov at oracle.com Wed Jan 22 11:07:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 11:07:29 -0800 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52DF8D2F.1030507@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> Message-ID: <52E016F1.80901@oracle.com> Aleksey, Question first: can you wait about 2 weeks when we merge ppc64 changes? I was not clear. The enum is not important. What I want is instead of unreadable code like next: if (wrote_final() || (AlwaysSafeConstructors && wrote_fields() && method()->name() == ciSymbol::object_initializer_name()) PPC64_ONLY(|| (wrote_volatile() && method()->is_initializer()))) { to have if (need_membar_on_exit()) { and bool Parse::need_membar_on_exit() { return wrote_final() || method()->is_initializer() && (AlwaysSafeConstructors && wrote_fields() PPC64_ONLY( || wrote_volatile() )); } with comments of cause. Thanks, Vladimir On 1/22/14 1:19 AM, Aleksey Shipilev wrote: > Thanks, Vladimir! > > On 01/22/2014 12:07 PM, Vladimir Kozlov wrote: >> On 1/21/14 9:10 PM, Vladimir Kozlov wrote: >>> May be we should use bitset enums to record types of stores to fields. > > And the benefit is? I come from the notion Parse is a throw-away > instance anyhow, do we actually care for additional transient byte of > footprint per compilation? > >>> Next changes touch the same C2 code: >>> >>> http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/c6d7e7406136 >>> >>> It uses method()->is_initializer() instead of (method()->name() == >>> ciSymbol::object_initializer_name()). > > Copied from C1 code, and I agree "method()->is_initializer()" seems more > readable, although it also matches the static initializers. Unless there > is a readability concern, I'd rather leave it as is to match C1 behavior. > >>> The main problem that new flag check will be executed always. It will >>> not be optimized by C++. >> >> On other hand we already have experimental flags (for example, >> AggressiveUnboxing) so it is not big deal. > > That's what I'm thinking as well. > > -Aleksey. > From aleksey.shipilev at oracle.com Wed Jan 22 11:13:18 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 22 Jan 2014 23:13:18 +0400 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52E016F1.80901@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> Message-ID: <52E0184E.2090004@oracle.com> Hi Vladimir, On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: > Question first: can you wait about 2 weeks when we merge ppc64 changes? I think we can wait. I don't want to collide with PPC merge either. In fact, it would be even more convenient for us to grab PPC C2 in the experiments from the mainline. > I was not clear. The enum is not important. What I want is instead of > unreadable code like next: > > if (wrote_final() || > (AlwaysSafeConstructors && wrote_fields() && > method()->name() == ciSymbol::object_initializer_name()) > PPC64_ONLY(|| (wrote_volatile() && method()->is_initializer()))) { Ugh. Yes, together with PPC changes the predicate is overblown. Makes total sense to extract the method, will do that in updated webrev once PPC change lands. Thanks, -Aleksey. From aleksey.shipilev at oracle.com Wed Jan 22 11:46:18 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 22 Jan 2014 23:46:18 +0400 Subject: -XX:+UseOldInlining In-Reply-To: <0D813784-F015-4620-B0A9-0D3D31E325F6@oracle.com> References: <52CFAE04.9000309@oracle.com> <0D813784-F015-4620-B0A9-0D3D31E325F6@oracle.com> Message-ID: <52E0200A.6050407@oracle.com> It's hard to remember to submit the bug :) https://bugs.openjdk.java.net/browse/JDK-8032490 John, you seem to be back from vacation? Do you think we should purge this from VM code? -Aleksey. On 01/11/2014 01:04 AM, Christian Thalinger wrote: > John is on vacation right now but here is what I know. Years and > years ago John wanted to rewrite the inlining policy and so the > existing one got moved under UseOldInlining. It turned out (and here > starts the guesswork) that the new inlining was either not as good or > wasn?t finished and so was never turned on. Since then we run with > UseOldInlining. > > I?ve talked to John about this in the past and if I remember > correctly he agreed that we can get rid of it. Let?s wait for him to > come back and decide then what to do. Can you file a bug so we don?t > forget? > > On Jan 10, 2014, at 12:23 AM, Aleksey Shipilev > wrote: > >> Hi, >> >> Does anyone remember the story behind -XX:+UseOldInlining? I have >> googled, wandered through HotSpot code, searched through JIRA, >> grepped through Mercurial to no avail. The history on this predates >> OpenJDK. >> >> In seems we have it unconditionally turned on. It makes the >> inlining policy a little less understandable to have additional >> branch here and there. Should we purge this option from the VM >> codebase? If so, I can prepare the proper revision of this scratch >> change: >> http://cr.openjdk.java.net/~shade/scratch/purge-old-inlining.patch >> >> Thanks, -Aleksey. > From john.r.rose at oracle.com Wed Jan 22 11:50:24 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Jan 2014 11:50:24 -0800 Subject: -XX:+UseOldInlining In-Reply-To: <52CFAE04.9000309@oracle.com> References: <52CFAE04.9000309@oracle.com> Message-ID: <7125FBD3-3C37-4929-ADD6-E92E03B0F351@oracle.com> On Jan 10, 2014, at 12:23 AM, Aleksey Shipilev wrote: > Does anyone remember the story behind -XX:+UseOldInlining? I have > googled, wandered through HotSpot code, searched through JIRA, grepped > through Mercurial to no avail. The history on this predates OpenJDK. > > In seems we have it unconditionally turned on. It makes the inlining > policy a little less understandable to have additional branch here and > there. Should we purge this option from the VM codebase? If so, I can > prepare the proper revision of this scratch change: > http://cr.openjdk.java.net/~shade/scratch/purge-old-inlining.patch Yes, purge it. It marks a road not taken long ago. ? John From vladimir.kozlov at oracle.com Wed Jan 22 13:24:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 13:24:29 -0800 Subject: RFR(L) 8031498: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <52DD1ADE.5050109@oracle.com> References: <52D53871.40606@oracle.com> <20140114140353.GB9323@rbackman> <52D68C79.6070800@oracle.com> <52D690E6.50908@oracle.com> <52D7941D.2050801@oracle.com> <52D8FD9C.4090808@oracle.com> <52D9BCDC.8050100@oracle.com> <52DD1ADE.5050109@oracle.com> Message-ID: <52E0370D.3020906@oracle.com> The bug id in the mail's Subject is incorrect. Should be 8031498. I fixed it. Changes looks good. Thanks, Vladimir On 1/20/14 4:47 AM, Niclas Adlertz wrote: > Thank you Vladimir. > > I removed the references and removed some of the line breaks. > > http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev04/ > > Kind Regards, > Niclas Adlertz > > On 2014-01-18 00:29, Vladimir Kozlov wrote: >> On 1/17/14 1:53 AM, Niclas Adlertz wrote: >>> Vladimir, >>> >>> Thank you for your comments! >>> >>>> Vectors are separate from floats. Please, rename the method to >>>> is_float_or_vector(). >>> Done >>> >>>> >>>> class Pressure. Field names start with '_' to separate then from >>>> variables. >>>> >>> Done >>> >>>> Why you don't like to path pointer to liveout? It helped only in few >>>> places but code in interfere_with_live() become complicated (IndexSet& >>>> liveout and then elements(&liveout)). >>> I thought it looked better to send in the liveout as a reference since >>> it was allocated on stack in build_ifg_physical: >>> IndexSet liveout(_live->live(block)); >>> But if you want me revert the change I can do that. >> >> The final consumer IndexSetIterator of liveout needs pointer. You have >> to add additional conversion in sources which I don't like: >> >> foo(IndexSet& liveout) { >> IndexSetIterator elements(&liveout); >> >> It makes code more complex to understand. >> >> Also in build_ifg_physical() you have too many empty lines. >> >> Thanks, >> Vladimir >> >>> >>> >>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev03/ >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> >>> On 2014-01-16 09:11, Vladimir Kozlov wrote: >>>> Niclas, >>>> >>>> Changes are good. I have few notes. >>>> >>>> Vectors are separate from floats. Please, rename the method to >>>> is_float_or_vector(). >>>> >>>> class Pressure. Field names start with '_' to separate then from >>>> variables. >>>> >>>> Why you don't like to path pointer to liveout? It helped only in few >>>> places but code in interfere_with_live() become complicated (IndexSet& >>>> liveout and then elements(&liveout)). >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/15/14 5:45 AM, Niclas Adlertz wrote: >>>>> Hi again, >>>>> >>>>> I found a commented section that I forgot to remove in chaitin.hpp: >>>>> >>>>> // stores the first low-to-high transition (starting from the top of >>>>> block) >>>>> //uint final_high_pressure_index; >>>>> >>>>> Updated the webrev: >>>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev02/ >>>>> >>>>> On 2014-01-15 14:26, Niclas Adlertz wrote: >>>>>> Hi Rickard, >>>>>> >>>>>> Thank you for your comments. >>>>>> >>>>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev01/ >>>>>> >>>>>> Kind Regards, >>>>>> Niclas Adlertz >>>>>> >>>>>> On 2014-01-14 15:03, Rickard B?ckman wrote: >>>>>>> Just a few comments on the C++ parts. I haven't verified that the >>>>>>> logic >>>>>>> is still the same. >>>>>>> >>>>>>> 1) It seems like there are a couple of functions that could be >>>>>>> created >>>>>>> in the new Pressure class to avoid code duplication. One example is >>>>>>> the >>>>>>> check_for_high_pressure_block method. >>>>>>> >>>>>>> 2) All places that checks lrg._is_float also check lrg._is_vector. >>>>>>> That >>>>>>> check could be made into a boolean method on the LRG instead. The >>>>>>> same >>>>>>> for is_UP() & mask_size(). >>>>>>> >>>>>>> 3) To make code more generic the int_pressure and float_pressure >>>>>>> instances could be passed the INTPRESSURE and FLOATPRESSURE and keep >>>>>>> those as instance variables. >>>>>>> >>>>>>> Good work. >>>>>>> >>>>>>> /R >>>>>>> >>>>>>> On 01/14, Niclas Adlertz wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> This is a first step to clean up the register allocator in C2. In >>>>>>>> this change we have divided the very long method >>>>>>>> build_ifg_physical() into many smaller ones, making it easier to >>>>>>>> see the steps when building the IFG (and computing >>>>>>>> the block pressure). >>>>>>>> We have also cleaned up old comments and improved old code, both >>>>>>>> by better naming and by simplifying expressions. >>>>>>>> I personally think that the easiest way to review this change is >>>>>>>> to have the old and new ifg.cpp side by side, and >>>>>>>> start from build_ifg_physical(). >>>>>>>> The next step is to create a new class for these methods, >>>>>>>> isolating them and removing them from PhaseChaitin. >>>>>>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ >>>>>>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 >>>>>>>> >>>>>>>> Kind Regards, >>>>>>>> Niclas Adlertz >>>>>> >>>>> >>> > From rednaxelafx at gmail.com Wed Jan 22 19:43:41 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 22 Jan 2014 19:43:41 -0800 Subject: RFR: 8025856 - Fix typos in the GC code In-Reply-To: <21216.33671.590417.69599@mykonos.us.oracle.com> References: <52CD70B3.8090406@oracle.com> <1389620575.2570.48.camel@cirrus> <52D3FA12.5080407@oracle.com> <21216.33671.590417.69599@mykonos.us.oracle.com> Message-ID: Hi John, On Wed, Jan 22, 2014 at 6:50 PM, John Coomes wrote: > > opto/runtime.cpp: > > fields[TypeFunc::Parms+0] = TypeInt::INT; // trap_reason (deopt reason > and action) > > The comment you added is not obviously correct; did someone from > the compiler team check this? If the comment is correct, the code > is crazily obscure! > > Yes, I proposed this change. The old comment had been out of date even before JDK6. duke at 0: line 392 of http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/a61af66fc99e/src/share/vm/opto/runtime.cpp The corresponding runtime call goes through SharedRuntime::uncommon_trap_blob to: Deoptimization::UnrollBlock* Deoptimization::uncommon_trap(JavaThread* thread, jint trap_request) The "thread" argument came from uncommon_trap_blob; the "trap_request" argument came from constant embedded in compiled code. And this "trap_request" is the thing described by OptoRuntime::uncommon_trap_Type(). Back in JDK1.4.2-ish or maybe even earlier, the signature of this function was: Deoptimization::UnrollBlock*, Deoptimization::uncommon_trap(JavaThread* thread, jint unloaded_class_index) where "unloaded_class_index" was a constant pool index of a class if >= 0, or other deopt cases if < 0. I'm not sure when it changed to its current form... waiting for someone else to share the history :-) Maybe the comment had been out of date longer then I thought. Speaking of this, the comment in SharedRuntime::generate_uncommon_trap_blob() is also out of date: e.g. hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp // compiler left unloaded_class_index in j_rarg0 move to where the // runtime expects it. __ movl(c_rarg1, j_rarg0); "unloaded_class_index" should be "trap_reason" now. > > -John > > -- > John Coomes Oracle, MS USCA22-3?? > john.coomes at oracle.com 4220 Network Circle > 408-276-7048 Santa Clara, CA 95054-1778 > *** Support GreenPeace and we'll all breathe easier. *** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140122/a227236e/attachment.html From vladimir.kozlov at oracle.com Wed Jan 22 19:51:44 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 19:51:44 -0800 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method In-Reply-To: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> References: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> Message-ID: <52E091D0.3010508@oracle.com> Roland, I don't see how inlining depth can define type's accuracy in general case. why it can't be reverse: more accurate type from most deeply inlined method? I thought you only have speculative type if it is the only one type record in MDO. How in your case you can have different types? Can you be more specific? Thanks, Vladimir On 1/22/14 1:42 AM, Roland Westrelin wrote: > When a node already has a speculative type, and parsing encounters extra profiling data, the new profiling data is ignored. So profiling data coming from profile points closer to the root of the compilation is favored which I think makes sense: it's the data that is most specific to the context of this compilation. > > During runs, profile data is not always entirely coherent so we may hit something like this: > m1() { > m3(); > } > > m() { > m1(); > m2(); > } > > With: m3() and m2() have profile data for the same node. The first profile data to be encountered during parsing is from m3() and profile data from m2() is ignored but profile data from m2() is the one that is actually the most specific and is the one that should be favored. > > When a speculative type is created, this change records the inline depth at which the profile point is. The inline depth is then propagated together with the rest of the type information. When new profile data is available for a node that already has a speculative type, the current inline depth and the inline depth of the current speculative type are used to decide whether the new data should be used to replace the existing speculative type. > > This change helps stabilize performance with nashorn. > > http://cr.openjdk.java.net/~roland/8031754/webrev.00/ > > Roland. > From rednaxelafx at gmail.com Wed Jan 22 19:57:18 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 22 Jan 2014 19:57:18 -0800 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method In-Reply-To: <52E091D0.3010508@oracle.com> References: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> <52E091D0.3010508@oracle.com> Message-ID: Hi Vladimir, My wild guess is that the outermost method generally gives you the best (cleanest) context information. The inner callees may have been called from various callers, and so their type profiles may have been polluted by other callers. - Kris On Wed, Jan 22, 2014 at 7:51 PM, Vladimir Kozlov wrote: > Roland, > > I don't see how inlining depth can define type's accuracy in general case. > why it can't be reverse: more accurate type from most deeply inlined method? > > I thought you only have speculative type if it is the only one type record > in MDO. How in your case you can have different types? > > Can you be more specific? > > Thanks, > Vladimir > > > On 1/22/14 1:42 AM, Roland Westrelin wrote: > >> When a node already has a speculative type, and parsing encounters extra >> profiling data, the new profiling data is ignored. So profiling data coming >> from profile points closer to the root of the compilation is favored which >> I think makes sense: it's the data that is most specific to the context of >> this compilation. >> >> During runs, profile data is not always entirely coherent so we may hit >> something like this: >> m1() { >> m3(); >> } >> >> m() { >> m1(); >> m2(); >> } >> >> With: m3() and m2() have profile data for the same node. The first >> profile data to be encountered during parsing is from m3() and profile data >> from m2() is ignored but profile data from m2() is the one that is actually >> the most specific and is the one that should be favored. >> >> When a speculative type is created, this change records the inline depth >> at which the profile point is. The inline depth is then propagated together >> with the rest of the type information. When new profile data is available >> for a node that already has a speculative type, the current inline depth >> and the inline depth of the current speculative type are used to decide >> whether the new data should be used to replace the existing speculative >> type. >> >> This change helps stabilize performance with nashorn. >> >> http://cr.openjdk.java.net/~roland/8031754/webrev.00/ >> >> Roland. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140122/211c9e9c/attachment.html From vladimir.kozlov at oracle.com Wed Jan 22 20:05:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 20:05:58 -0800 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method In-Reply-To: References: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> <52E091D0.3010508@oracle.com> Message-ID: <52E09526.7030907@oracle.com> On 1/22/14 7:57 PM, Krystal Mok wrote: > Hi Vladimir, > > My wild guess is that the outermost method generally gives you the best > (cleanest) context information. The inner callees may have been called > from various callers, and so their type profiles may have been polluted > by other callers. They can't be polluted. We record only one speculative type. If Interpreter see a different type it will set flags and that type information will not be used. At least that is how I understand it works. That is why I am asking Roland to clarify this. If you have merging case: if (x) m1() else m2() I don't understand why at merge point information from m2 will be more precise then from m3() called from m1(). Thanks, Vladimir > > - Kris > > > On Wed, Jan 22, 2014 at 7:51 PM, Vladimir Kozlov > > wrote: > > Roland, > > I don't see how inlining depth can define type's accuracy in general > case. why it can't be reverse: more accurate type from most deeply > inlined method? > > I thought you only have speculative type if it is the only one type > record in MDO. How in your case you can have different types? > > Can you be more specific? > > Thanks, > Vladimir > > > On 1/22/14 1:42 AM, Roland Westrelin wrote: > > When a node already has a speculative type, and parsing > encounters extra profiling data, the new profiling data is > ignored. So profiling data coming from profile points closer to > the root of the compilation is favored which I think makes > sense: it's the data that is most specific to the context of > this compilation. > > During runs, profile data is not always entirely coherent so we > may hit something like this: > m1() { > m3(); > } > > m() { > m1(); > m2(); > } > > With: m3() and m2() have profile data for the same node. The > first profile data to be encountered during parsing is from m3() > and profile data from m2() is ignored but profile data from m2() > is the one that is actually the most specific and is the one > that should be favored. > > When a speculative type is created, this change records the > inline depth at which the profile point is. The inline depth is > then propagated together with the rest of the type information. > When new profile data is available for a node that already has a > speculative type, the current inline depth and the inline depth > of the current speculative type are used to decide whether the > new data should be used to replace the existing speculative type. > > This change helps stabilize performance with nashorn. > > http://cr.openjdk.java.net/~__roland/8031754/webrev.00/ > > > Roland. > > From vladimir.kozlov at oracle.com Wed Jan 22 20:06:23 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 20:06:23 -0800 Subject: RFR: 8025856 - Fix typos in the GC code In-Reply-To: References: <52CD70B3.8090406@oracle.com> <1389620575.2570.48.camel@cirrus> <52D3FA12.5080407@oracle.com> <21216.33671.590417.69599@mykonos.us.oracle.com> Message-ID: <52E0953F.7060404@oracle.com> New comment is correct, uncommon traps are generated as call with one input parameter - trap_reason. Thanks, Vladimir On 1/22/14 7:43 PM, Krystal Mok wrote: > Hi John, > > On Wed, Jan 22, 2014 at 6:50 PM, John Coomes > wrote: > > opto/runtime.cpp: > > fields[TypeFunc::Parms+0] = TypeInt::INT; // trap_reason (deopt > reason and action) > > The comment you added is not obviously correct; did someone from > the compiler team check this? If the comment is correct, the code > is crazily obscure! > > Yes, I proposed this change. The old comment had been out of date even > before JDK6. > > duke at 0: > line 392 of > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/a61af66fc99e/src/share/vm/opto/runtime.cpp > > The corresponding runtime call goes through > SharedRuntime::uncommon_trap_blob to: > > Deoptimization::UnrollBlock* Deoptimization::uncommon_trap(JavaThread* > thread, jint trap_request) > > The "thread" argument came from uncommon_trap_blob; the "trap_request" > argument came from constant embedded in compiled code. > And this "trap_request" is the thing described by > OptoRuntime::uncommon_trap_Type(). > > Back in JDK1.4.2-ish or maybe even earlier, the signature of this > function was: > > Deoptimization::UnrollBlock*, Deoptimization::uncommon_trap(JavaThread* > thread, jint unloaded_class_index) > > where "unloaded_class_index" was a constant pool index of a class if >= > 0, or other deopt cases if < 0. > > I'm not sure when it changed to its current form... waiting for someone > else to share the history :-) > Maybe the comment had been out of date longer then I thought. > > Speaking of this, the comment > in SharedRuntime::generate_uncommon_trap_blob() is also out of date: > > e.g. hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp > > // compiler left unloaded_class_index in j_rarg0 move to where the > // runtime expects it. > __ movl(c_rarg1, j_rarg0); > > "unloaded_class_index" should be "trap_reason" now. > > > -John > > -- > John Coomes Oracle, MS USCA22-3?? > john.coomes at oracle.com > 4220 Network Circle > 408-276-7048 Santa > Clara, CA 95054-1778 > *** Support GreenPeace and we'll all breathe easier. *** > > From rednaxelafx at gmail.com Wed Jan 22 20:37:16 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 22 Jan 2014 20:37:16 -0800 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method In-Reply-To: <52E09526.7030907@oracle.com> References: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> <52E091D0.3010508@oracle.com> <52E09526.7030907@oracle.com> Message-ID: Hi Vladimir, Oops, then my wild guess was way off... I haven't followed the recent addition of profiling and speculative types so just ignore me on this one. Sorry about the noise. Thanks, Kris On Wed, Jan 22, 2014 at 8:05 PM, Vladimir Kozlov wrote: > On 1/22/14 7:57 PM, Krystal Mok wrote: > >> Hi Vladimir, >> >> My wild guess is that the outermost method generally gives you the best >> (cleanest) context information. The inner callees may have been called >> from various callers, and so their type profiles may have been polluted >> by other callers. >> > > They can't be polluted. We record only one speculative type. If > Interpreter see a different type it will set flags and that type > information will not be used. At least that is how I understand it works. > That is why I am asking Roland to clarify this. > > If you have merging case: > > if (x) > m1() > else > m2() > > I don't understand why at merge point information from m2 will be more > precise then from m3() called from m1(). > > Thanks, > Vladimir > > >> - Kris >> >> >> On Wed, Jan 22, 2014 at 7:51 PM, Vladimir Kozlov >> > wrote: >> >> Roland, >> >> I don't see how inlining depth can define type's accuracy in general >> case. why it can't be reverse: more accurate type from most deeply >> inlined method? >> >> I thought you only have speculative type if it is the only one type >> record in MDO. How in your case you can have different types? >> >> Can you be more specific? >> >> Thanks, >> Vladimir >> >> >> On 1/22/14 1:42 AM, Roland Westrelin wrote: >> >> When a node already has a speculative type, and parsing >> encounters extra profiling data, the new profiling data is >> ignored. So profiling data coming from profile points closer to >> the root of the compilation is favored which I think makes >> sense: it's the data that is most specific to the context of >> this compilation. >> >> During runs, profile data is not always entirely coherent so we >> may hit something like this: >> m1() { >> m3(); >> } >> >> m() { >> m1(); >> m2(); >> } >> >> With: m3() and m2() have profile data for the same node. The >> first profile data to be encountered during parsing is from m3() >> and profile data from m2() is ignored but profile data from m2() >> is the one that is actually the most specific and is the one >> that should be favored. >> >> When a speculative type is created, this change records the >> inline depth at which the profile point is. The inline depth is >> then propagated together with the rest of the type information. >> When new profile data is available for a node that already has a >> speculative type, the current inline depth and the inline depth >> of the current speculative type are used to decide whether the >> new data should be used to replace the existing speculative type. >> >> This change helps stabilize performance with nashorn. >> >> http://cr.openjdk.java.net/~__roland/8031754/webrev.00/ >> >> >> Roland. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140122/50bd79f8/attachment.html From roland.westrelin at oracle.com Thu Jan 23 02:01:19 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 23 Jan 2014 11:01:19 +0100 Subject: RFR(L) 8031498: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <52E0370D.3020906@oracle.com> References: <52D53871.40606@oracle.com> <20140114140353.GB9323@rbackman> <52D68C79.6070800@oracle.com> <52D690E6.50908@oracle.com> <52D7941D.2050801@oracle.com> <52D8FD9C.4090808@oracle.com> <52D9BCDC.8050100@oracle.com> <52DD1ADE.5050109@oracle.com> <52E0370D.3020906@oracle.com> Message-ID: <88758943-1881-4882-8674-C67F9C9984A2@oracle.com> Hi Niclas, It looks good to me. Nice cleanup. A few minor comments. No need to send another webrev: Isn?t assignment in tests: 294 while ((interfering_lid = elements.next()) != 0) { 399 while ((lidx = elements.next()) != 0) { 414 while ((lidx = elements.next()) != 0) { 507 while ((lid = elements.next()) != 0) { something we try to avoid? Messages in asserts are nice: 439 assert(int_pressure._current_pressure == count_int_pressure(liveout), "" ); 440 assert(float_pressure._current_pressure == count_float_pressure(liveout), ""); if (idx != 0) { is better than 627 if (idx) { Roland. On Jan 22, 2014, at 10:24 PM, Vladimir Kozlov wrote: > The bug id in the mail's Subject is incorrect. Should be 8031498. I fixed it. > > Changes looks good. > > Thanks, > Vladimir > > On 1/20/14 4:47 AM, Niclas Adlertz wrote: >> Thank you Vladimir. >> >> I removed the references and removed some of the line breaks. >> >> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev04/ >> >> Kind Regards, >> Niclas Adlertz >> >> On 2014-01-18 00:29, Vladimir Kozlov wrote: >>> On 1/17/14 1:53 AM, Niclas Adlertz wrote: >>>> Vladimir, >>>> >>>> Thank you for your comments! >>>> >>>>> Vectors are separate from floats. Please, rename the method to >>>>> is_float_or_vector(). >>>> Done >>>> >>>>> >>>>> class Pressure. Field names start with '_' to separate then from >>>>> variables. >>>>> >>>> Done >>>> >>>>> Why you don't like to path pointer to liveout? It helped only in few >>>>> places but code in interfere_with_live() become complicated (IndexSet& >>>>> liveout and then elements(&liveout)). >>>> I thought it looked better to send in the liveout as a reference since >>>> it was allocated on stack in build_ifg_physical: >>>> IndexSet liveout(_live->live(block)); >>>> But if you want me revert the change I can do that. >>> >>> The final consumer IndexSetIterator of liveout needs pointer. You have >>> to add additional conversion in sources which I don't like: >>> >>> foo(IndexSet& liveout) { >>> IndexSetIterator elements(&liveout); >>> >>> It makes code more complex to understand. >>> >>> Also in build_ifg_physical() you have too many empty lines. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> >>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev03/ >>>> >>>> Kind Regards, >>>> Niclas Adlertz >>>> >>>> >>>> On 2014-01-16 09:11, Vladimir Kozlov wrote: >>>>> Niclas, >>>>> >>>>> Changes are good. I have few notes. >>>>> >>>>> Vectors are separate from floats. Please, rename the method to >>>>> is_float_or_vector(). >>>>> >>>>> class Pressure. Field names start with '_' to separate then from >>>>> variables. >>>>> >>>>> Why you don't like to path pointer to liveout? It helped only in few >>>>> places but code in interfere_with_live() become complicated (IndexSet& >>>>> liveout and then elements(&liveout)). >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/15/14 5:45 AM, Niclas Adlertz wrote: >>>>>> Hi again, >>>>>> >>>>>> I found a commented section that I forgot to remove in chaitin.hpp: >>>>>> >>>>>> // stores the first low-to-high transition (starting from the top of >>>>>> block) >>>>>> //uint final_high_pressure_index; >>>>>> >>>>>> Updated the webrev: >>>>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev02/ >>>>>> >>>>>> On 2014-01-15 14:26, Niclas Adlertz wrote: >>>>>>> Hi Rickard, >>>>>>> >>>>>>> Thank you for your comments. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev01/ >>>>>>> >>>>>>> Kind Regards, >>>>>>> Niclas Adlertz >>>>>>> >>>>>>> On 2014-01-14 15:03, Rickard B?ckman wrote: >>>>>>>> Just a few comments on the C++ parts. I haven't verified that the >>>>>>>> logic >>>>>>>> is still the same. >>>>>>>> >>>>>>>> 1) It seems like there are a couple of functions that could be >>>>>>>> created >>>>>>>> in the new Pressure class to avoid code duplication. One example is >>>>>>>> the >>>>>>>> check_for_high_pressure_block method. >>>>>>>> >>>>>>>> 2) All places that checks lrg._is_float also check lrg._is_vector. >>>>>>>> That >>>>>>>> check could be made into a boolean method on the LRG instead. The >>>>>>>> same >>>>>>>> for is_UP() & mask_size(). >>>>>>>> >>>>>>>> 3) To make code more generic the int_pressure and float_pressure >>>>>>>> instances could be passed the INTPRESSURE and FLOATPRESSURE and keep >>>>>>>> those as instance variables. >>>>>>>> >>>>>>>> Good work. >>>>>>>> >>>>>>>> /R >>>>>>>> >>>>>>>> On 01/14, Niclas Adlertz wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> This is a first step to clean up the register allocator in C2. In >>>>>>>>> this change we have divided the very long method >>>>>>>>> build_ifg_physical() into many smaller ones, making it easier to >>>>>>>>> see the steps when building the IFG (and computing >>>>>>>>> the block pressure). >>>>>>>>> We have also cleaned up old comments and improved old code, both >>>>>>>>> by better naming and by simplifying expressions. >>>>>>>>> I personally think that the easiest way to review this change is >>>>>>>>> to have the old and new ifg.cpp side by side, and >>>>>>>>> start from build_ifg_physical(). >>>>>>>>> The next step is to create a new class for these methods, >>>>>>>>> isolating them and removing them from PhaseChaitin. >>>>>>>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ >>>>>>>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 >>>>>>>>> >>>>>>>>> Kind Regards, >>>>>>>>> Niclas Adlertz >>>>>>> >>>>>> >>>> >> From rickard.backman at oracle.com Thu Jan 23 03:27:23 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Thu, 23 Jan 2014 12:27:23 +0100 Subject: RFR(M): 8027754: Enable loop optimizations for loops with MathExact inside Message-ID: <20140123112723.GG9323@rbackman> Hi all, this change is going to 9 (and backporting to 8u20). Can I please have this change reviewed? The implementation of different j.l.Math.mathExact() didn't work very well with different optimizations because there was one node that generated both control and data. This change has a new implementation where each call to j.l.Math.mathExact() generates a Overflow node and a normal math operation node (in the integer add example: OverflowAddINode and a AddINode). The Overflow node is responsible for generating control. In the end we generate assembly like: mov rdx, rdi add rdx, rsi ... mov rax, rdi add rax, rsi jo With one add instruction for the data and one for flags. Future improvements could be to try to match the Overflow and the math operation and remove one of them. Bug: https://bugs.openjdk.java.net/browse/JDK-8027754 Webrev: http://cr.openjdk.java.net/~rbackman/8027754/ Thanks /R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140123/3d24f123/attachment.bin From roland.westrelin at oracle.com Thu Jan 23 07:06:25 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 23 Jan 2014 16:06:25 +0100 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method In-Reply-To: <52E09526.7030907@oracle.com> References: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> <52E091D0.3010508@oracle.com> <52E09526.7030907@oracle.com> Message-ID: <865C3299-3E60-40D4-84AA-8EEA27ADAF99@oracle.com> Thanks for looking at this, Vladimir. >> My wild guess is that the outermost method generally gives you the best >> (cleanest) context information. The inner callees may have been called >> from various callers, and so their type profiles may have been polluted >> by other callers. > > They can't be polluted. We record only one speculative type. If Interpreter see a different type it will set flags and that type information will not be used. At least that is how I understand it works. That is why I am asking Roland to clarify this. That?s the way they work. What can happen for this (and what happens sometimes I believe): m1() { m3(); } m() { m1(); m2(); } is that m3() is a heavily used method called from some other place early during the application run. Some profile is recorded. The method becomes so hot that it gets compiled with c2. So we stop profiling. Then m3() is called from m1() but because it?s already compiled we don?t record the conflicting profile. When m() is compiled we are stuck with an incorrect profile and we may miss some optimization opportunities. As Krys said, intuitively "the outermost method generally gives you the best (cleanest) context information?. It?s only a heuristic and as such, it?s certainly easy to build a test case for which this heuristic doesn?t do a good job. It does help for experiments I made with nashorn so I?d like to see it used to confirm it does help. Roland. > > If you have merging case: > > if (x) > m1() > else > m2() > > I don't understand why at merge point information from m2 will be more precise then from m3() called from m1(). > > Thanks, > Vladimir > >> >> - Kris >> >> >> On Wed, Jan 22, 2014 at 7:51 PM, Vladimir Kozlov >> > wrote: >> >> Roland, >> >> I don't see how inlining depth can define type's accuracy in general >> case. why it can't be reverse: more accurate type from most deeply >> inlined method? >> >> I thought you only have speculative type if it is the only one type >> record in MDO. How in your case you can have different types? >> >> Can you be more specific? >> >> Thanks, >> Vladimir >> >> >> On 1/22/14 1:42 AM, Roland Westrelin wrote: >> >> When a node already has a speculative type, and parsing >> encounters extra profiling data, the new profiling data is >> ignored. So profiling data coming from profile points closer to >> the root of the compilation is favored which I think makes >> sense: it's the data that is most specific to the context of >> this compilation. >> >> During runs, profile data is not always entirely coherent so we >> may hit something like this: >> m1() { >> m3(); >> } >> >> m() { >> m1(); >> m2(); >> } >> >> With: m3() and m2() have profile data for the same node. The >> first profile data to be encountered during parsing is from m3() >> and profile data from m2() is ignored but profile data from m2() >> is the one that is actually the most specific and is the one >> that should be favored. >> >> When a speculative type is created, this change records the >> inline depth at which the profile point is. The inline depth is >> then propagated together with the rest of the type information. >> When new profile data is available for a node that already has a >> speculative type, the current inline depth and the inline depth >> of the current speculative type are used to decide whether the >> new data should be used to replace the existing speculative type. >> >> This change helps stabilize performance with nashorn. >> >> http://cr.openjdk.java.net/~__roland/8031754/webrev.00/ >> >> >> Roland. From roland.westrelin at oracle.com Thu Jan 23 07:08:32 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 23 Jan 2014 16:08:32 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: <83FE2BE7-2AF9-4597-9245-1E6BCA00F52A@oracle.com> References: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> <4E9CEB56-BE25-4785-96AC-84FDE07D2957@oracle.com> <94B49859-0A3B-4AFA-8E54-978FB3D1EC28@oracle.com> <9BB16464-03B0-4A59-9CB6-EABDE86F8CFD@oracle.com> <83FE2BE7-2AF9-4597-9245-1E6BCA00F52A@oracle.com> Message-ID: <3F043ADE-8FD6-4A80-86D0-E3970FCDE14C@oracle.com> > I assume that lines 106 and 107 above are incomplete. Yes. > How would you compute an ident for these values and ensure the indents for each of the 3 DepValue types don?t clash with each other? Or are you relying on a Dependencies client to either be using dep_ci_object (e.g., c1 and c2) or dep_metadata and dep_jobject (e.g., Graal) and the client ensures that ident values are unique for all DepValues added to a Dependencies object? Yes, I would be relying on the fact that it?s either c1/c2 or graal. > Maybe you could hum a few bars on the advantages of this approach? Is it mainly about avoiding all VM_ENTRY concerns? It tries to use the CI objects without breaking into them. Anyway, I don?t find my solution pretty either. I?d like someone else from the team to take a look at this. Roland. From doug.simon at oracle.com Thu Jan 23 07:14:16 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 23 Jan 2014 16:14:16 +0100 Subject: RFR: 8031639: make dependency management (mostly) ci independent In-Reply-To: <3F043ADE-8FD6-4A80-86D0-E3970FCDE14C@oracle.com> References: <07112BDD-E2DC-44F3-A8A4-F77A326B2914@oracle.com> <4E9CEB56-BE25-4785-96AC-84FDE07D2957@oracle.com> <94B49859-0A3B-4AFA-8E54-978FB3D1EC28@oracle.com> <9BB16464-03B0-4A59-9CB6-EABDE86F8CFD@oracle.com> <83FE2BE7-2AF9-4597-9245-1E6BCA00F52A@oracle.com> <3F043ADE-8FD6-4A80-86D0-E3970FCDE14C@oracle.com> Message-ID: <13D47D39-99B2-4408-A925-9DED2E6289EB@oracle.com> On Jan 23, 2014, at 4:08 PM, Roland Westrelin wrote: >> I assume that lines 106 and 107 above are incomplete. > > Yes. > >> How would you compute an ident for these values and ensure the indents for each of the 3 DepValue types don?t clash with each other? Or are you relying on a Dependencies client to either be using dep_ci_object (e.g., c1 and c2) or dep_metadata and dep_jobject (e.g., Graal) and the client ensures that ident values are unique for all DepValues added to a Dependencies object? > > Yes, I would be relying on the fact that it?s either c1/c2 or graal. Ok. >> Maybe you could hum a few bars on the advantages of this approach? Is it mainly about avoiding all VM_ENTRY concerns? > > It tries to use the CI objects without breaking into them. Anyway, I don?t find my solution pretty either. I?d like someone else from the team to take a look at this. Sure. Just let me know if there?s any further input I can give. Thanks. -Doug From aleksey.shipilev at oracle.com Thu Jan 23 07:50:38 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 23 Jan 2014 19:50:38 +0400 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining Message-ID: <52E13A4E.6070102@oracle.com> Hi, Please review the simple cleanup patch removing -XX:UseOldInlining: http://cr.openjdk.java.net/~shade/8032490/webrev.00/ Testing: - full JPRT vs hotspot-comp Thanks, -Aleksey. From vladimir.kozlov at oracle.com Thu Jan 23 08:10:15 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jan 2014 08:10:15 -0800 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <52E13A4E.6070102@oracle.com> References: <52E13A4E.6070102@oracle.com> Message-ID: <52E13EE7.8000104@oracle.com> InlineTree constructor which had assert(!UseOldInlining can be removed too. Vladimir On 1/23/14 7:50 AM, Aleksey Shipilev wrote: > Hi, > > Please review the simple cleanup patch removing -XX:UseOldInlining: > http://cr.openjdk.java.net/~shade/8032490/webrev.00/ > > Testing: > - full JPRT vs hotspot-comp > > Thanks, > -Aleksey. > From aleksey.shipilev at oracle.com Thu Jan 23 08:28:54 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 23 Jan 2014 20:28:54 +0400 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <52E13EE7.8000104@oracle.com> References: <52E13A4E.6070102@oracle.com> <52E13EE7.8000104@oracle.com> Message-ID: <52E14346.50906@oracle.com> Right, thanks for spotting that! Updated: http://cr.openjdk.java.net/~shade/8032490/webrev.01/ Seems a simple update, so I haven't rerun JPRT on this one, only local Linux x86_64 build, which is successful. Want me to do JPRT? -Aleksey. On 01/23/2014 08:10 PM, Vladimir Kozlov wrote: > InlineTree constructor which had assert(!UseOldInlining can be removed too. > > Vladimir > > On 1/23/14 7:50 AM, Aleksey Shipilev wrote: >> Hi, >> >> Please review the simple cleanup patch removing -XX:UseOldInlining: >> http://cr.openjdk.java.net/~shade/8032490/webrev.00/ >> >> Testing: >> - full JPRT vs hotspot-comp >> >> Thanks, >> -Aleksey. >> From vladimir.kozlov at oracle.com Thu Jan 23 08:35:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jan 2014 08:35:16 -0800 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <52E14346.50906@oracle.com> References: <52E13A4E.6070102@oracle.com> <52E13EE7.8000104@oracle.com> <52E14346.50906@oracle.com> Message-ID: <52E144C4.1090804@oracle.com> On 1/23/14 8:28 AM, Aleksey Shipilev wrote: > Right, thanks for spotting that! > > Updated: > http://cr.openjdk.java.net/~shade/8032490/webrev.01/ Good. > > Seems a simple update, so I haven't rerun JPRT on this one, only local > Linux x86_64 build, which is successful. Want me to do JPRT? No, local build should be enough. Thanks, Vladimir PS: You still need sponsor? > > -Aleksey. > > On 01/23/2014 08:10 PM, Vladimir Kozlov wrote: >> InlineTree constructor which had assert(!UseOldInlining can be removed too. >> >> Vladimir >> >> On 1/23/14 7:50 AM, Aleksey Shipilev wrote: >>> Hi, >>> >>> Please review the simple cleanup patch removing -XX:UseOldInlining: >>> http://cr.openjdk.java.net/~shade/8032490/webrev.00/ >>> >>> Testing: >>> - full JPRT vs hotspot-comp >>> >>> Thanks, >>> -Aleksey. >>> > From aleksey.shipilev at oracle.com Thu Jan 23 08:39:12 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 23 Jan 2014 20:39:12 +0400 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <52E144C4.1090804@oracle.com> References: <52E13A4E.6070102@oracle.com> <52E13EE7.8000104@oracle.com> <52E14346.50906@oracle.com> <52E144C4.1090804@oracle.com> Message-ID: <52E145B0.2010605@oracle.com> On 01/23/2014 08:35 PM, Vladimir Kozlov wrote: > On 1/23/14 8:28 AM, Aleksey Shipilev wrote: >> Right, thanks for spotting that! >> >> Updated: >> http://cr.openjdk.java.net/~shade/8032490/webrev.01/ > > Good. Thanks for the review! > PS: You still need sponsor? Yes, I do. -Aleksey. From christian.thalinger at oracle.com Thu Jan 23 13:16:41 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 Jan 2014 13:16:41 -0800 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <6212A762-67AB-4F5F-8C92-616430877D3F@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> <52D556EE.8000307@oracle.com> <410AB800-645F-4BBE-A95A-77ED239CBF89@oracle.com> <8788446E-73DF-4BCA-B0C2-CBD7C94A83BB@oracle.com> <52D7A239.60806@oracle.com> <97443F6C-F071-4800-98EE-B597A789B91B@oracle.com> <52D9CC65.9070108@oracle.com> <6212A762-67AB-4F5F-8C92-616430877D3F@oracle.com> Message-ID: <23EC49E4-1752-48E2-9771-040991E1E98D@oracle.com> Yes, much better. Thank you. On Jan 20, 2014, at 2:09 AM, Roland Westrelin wrote: >> Very good. >> >> You need to use 2014 Copyright year in the test (no need for re-review). > > Thanks, Vladimir. > > What about you, Chris? Do you think it?s ok now? > > Roland. > >> >> Thanks, >> Vladimir >> >> On 1/17/14 2:19 AM, Roland Westrelin wrote: >>> What about this? >>> >>> http://cr.openjdk.java.net/~roland/8027422/webrev.03/ >>> >>> Roland. >>> >>> >>> On Jan 16, 2014, at 10:11 AM, Vladimir Kozlov wrote: >>> >>>> On 1/16/14 1:05 AM, Roland Westrelin wrote: >>>>> >>>>> Thanks for reviewing this, Christian. >>>>> >>>>>> Seeing all these: >>>>>> >>>>>> true /* include_speculative */ >>>>>> >>>>>> I wonder if we should add new methods for these. It would make it easier to see the users of the speculative versions. >>>>> >>>>> A new meet_speculative() method? >>>>> I?m ok with it. Vladimir, what do you think? >>>> >>>> I was going to suggest it too but then you need additional methods for other methods: join(), higher_equal(), filter(). So I am fine with it if you do all of them. >>>> >>>> Vladimir >>>> >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> On Jan 14, 2014, at 7:25 AM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Looks good to me. >>>>>>> >>>>>>> On 1/14/14 1:13 AM, Roland Westrelin wrote: >>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.02/ >>>>>>>> >>>>>>>> I fixed the verification code at the end of Compile::remove_speculative_types(), used this format everywhere: >>>>>>>> t->filter(_type, true /* include_speculative */); >>>>>>>> >>>>>>>> renamed NodeHash::check_speculative_types() to NodeHash::check_no_speculative_types(), added PhaseIterGVN::check_no_speculative_types() and now call it from the verification code of Compile::remove_speculative_types(). >>>>>>>> >>>>>>>> Do I need more than 1 review for this? >>>>>>> >>>>>>> Yes, you need an other review for this change. Ask Chris or Igor. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>> >>>>>>>> On Jan 13, 2014, at 11:03 AM, Roland Westrelin wrote: >>>>>>>> >>>>>>>>>> compile.cpp: new verification code (under ASSERT) at the end of remove_speculative_types() checks only the root node - nothing else is pushed on worklist. Also add comment to this new code. >>>>>>>>> >>>>>>>>> Thanks for catching that. >>>>>>>>> Is: >>>>>>>>> // Verify that after the IGVN is over no speculative type has resurfaced >>>>>>>>> good as a comment? >>>>>>>>> >>>>>>>>>> Passing 'true' parameter is not very informative. You can use local variable: >>>>>>>>>> >>>>>>>>>> bool include_speculative = true; >>>>>>>>>> t->filter(_type, include_speculative); >>>>>>>>>> >>>>>>>>>> An other way to make code more informative is to add a comment to parameter: >>>>>>>>>> >>>>>>>>>> t->filter(_type, true /* include_speculative */); >>>>>>>>>> >>>>>>>>>> Either way is fine. >>>>>>>>> >>>>>>>>> Will do one of these. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 1/10/14 1:46 AM, Roland Westrelin wrote: >>>>>>>>>>> Hi Vladimir, >>>>>>>>>>> >>>>>>>>>>> Here is a new webrev for this: >>>>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> I fixed the issues you mentioned in your review. >>>>>>>>>>> I added a call to remove_speculative() to the ConNode constructor. When a node becomes constant, its speculative part can be not null. The IGVN doesn?t kill ConNodes so without a call to remove_speculative() a ConNode with a speculative part can sneak past the call to Compile::remove_speculative_types(). >>>>>>>>>>> I also added a verification method: >>>>>>>>>>> NodeHash::check_speculative_types() >>>>>>>>>>> to check that no TypeNode with a speculative type is still in the IGVN hash table after Compile::remove_speculative_types() >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>>>> On Nov 19, 2013, at 8:49 PM, Vladimir Kozlov wrote: >>>>>>>>>>> >>>>>>>>>>>> On 11/19/13 11:45 AM, Roland Westrelin wrote: >>>>>>>>>>>>> Thanks for reviewing this, Vladimir. >>>>>>>>>>>>> >>>>>>>>>>>>> On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >>>>>>>>>>>>>> >>>>>>>>>>>>>> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? >>>>>>>>>>>>> >>>>>>>>>>>>> You?re right. It probably should. >>>>>>>>>>>>> So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? >>>>>>>>>>>> >>>>>>>>>>>> Right, passing 'true' will work in all cases then. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Could you make printing code with 'this_t' aligned again in Type::meet()? >>>>>>>>>>>>> >>>>>>>>>>>>> Sure. >>>>>>>>>>>>> >>>>>>>>>>>>> Roland. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>>>>>>>>>>>>>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>>>>>>>>>>>>>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>>>>>>>>>>>>>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>>>>>>>>>>>>>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>>>>>>>>>>>>>> higher_equal() >>>>>>>>>>>>>>> meet() >>>>>>>>>>>>>>> join() >>>>>>>>>>>>>>> filter() >>>>>>>>>>>>>>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>>>>>>>>>>>>>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Roland. >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> > From aleksey.shipilev at oracle.com Thu Jan 23 15:25:47 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 24 Jan 2014 03:25:47 +0400 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <52E145B0.2010605@oracle.com> References: <52E13A4E.6070102@oracle.com> <52E13EE7.8000104@oracle.com> <52E14346.50906@oracle.com> <52E144C4.1090804@oracle.com> <52E145B0.2010605@oracle.com> Message-ID: <52E1A4FB.20300@oracle.com> On 01/23/2014 08:39 PM, Aleksey Shipilev wrote: > On 01/23/2014 08:35 PM, Vladimir Kozlov wrote: >> On 1/23/14 8:28 AM, Aleksey Shipilev wrote: >>> Right, thanks for spotting that! >>> >>> Updated: >>> http://cr.openjdk.java.net/~shade/8032490/webrev.01/ >> >> Good. Rebased for jdk9/hs-comp: http://cr.openjdk.java.net/~shade/8032490/webrev.02/ -Aleksey. From john.r.rose at oracle.com Thu Jan 23 15:35:12 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 23 Jan 2014 15:35:12 -0800 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <52E1A4FB.20300@oracle.com> References: <52E13A4E.6070102@oracle.com> <52E13EE7.8000104@oracle.com> <52E14346.50906@oracle.com> <52E144C4.1090804@oracle.com> <52E145B0.2010605@oracle.com> <52E1A4FB.20300@oracle.com> Message-ID: <6CF16FE1-1620-4CB2-91C7-36F93F5EAC72@oracle.com> It is good. You can count me as a reviewer also. ? John On Jan 23, 2014, at 3:25 PM, Aleksey Shipilev wrote: > On 01/23/2014 08:39 PM, Aleksey Shipilev wrote: >> On 01/23/2014 08:35 PM, Vladimir Kozlov wrote: >>> On 1/23/14 8:28 AM, Aleksey Shipilev wrote: >>>> Right, thanks for spotting that! >>>> >>>> Updated: >>>> http://cr.openjdk.java.net/~shade/8032490/webrev.01/ >>> >>> Good. > > Rebased for jdk9/hs-comp: > http://cr.openjdk.java.net/~shade/8032490/webrev.02/ > > > -Aleksey. From igor.veresov at oracle.com Thu Jan 23 15:54:28 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 23 Jan 2014 15:54:28 -0800 Subject: RFR(M): 8027754: Enable loop optimizations for loops with MathExact inside In-Reply-To: <20140123112723.GG9323@rbackman> References: <20140123112723.GG9323@rbackman> Message-ID: <8BB2E6B3-81C3-48A1-B7C0-846338498C18@oracle.com> Nice! In library_call.cpp: Could the LibaryCallKit::inline_math*() family of functions be factored with templates to shave a few lines? There is quite a lot of common code. I think the overflow idiom insertion can be something like: template void LibraryCallKit::inline_overflow(Node* arg1, Node* arg2) { Node* op = _gvn.transform(new(C) OperationNodeType(arg1, arg2)); Node* of = _gvn.transform(new(C) OverflowNodeType(arg1, arg2)); inline_math_mathExact(op, of); } In mathexactnode.cpp: You?ve already commoned many things up by introducing OverflowINode and OverflowLNode in hierarchy. But it feels like some of the code there could factored up as well using template helpers. In many cases the code looks exactly the same for ints and longs, differing only in some types. igor On Jan 23, 2014, at 3:27 AM, Rickard B?ckman wrote: > Hi all, > > this change is going to 9 (and backporting to 8u20). Can I please have > this change reviewed? > > The implementation of different j.l.Math.mathExact() didn't work very > well with different optimizations because there was one node that > generated both control and data. This change has a new implementation > where each call to j.l.Math.mathExact() generates a Overflow node and a > normal math operation node (in the integer add example: OverflowAddINode > and a AddINode). The Overflow node is responsible for generating > control. > > In the end we generate assembly like: > > mov rdx, rdi > add rdx, rsi > ... > mov rax, rdi > add rax, rsi > jo > > With one add instruction for the data and one for flags. Future > improvements could be to try to match the Overflow and the math > operation and remove one of them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027754 > Webrev: http://cr.openjdk.java.net/~rbackman/8027754/ > > Thanks > /R -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140123/3689b0b1/attachment.html From christian.thalinger at oracle.com Thu Jan 23 19:23:22 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 Jan 2014 19:23:22 -0800 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <52E1A4FB.20300@oracle.com> References: <52E13A4E.6070102@oracle.com> <52E13EE7.8000104@oracle.com> <52E14346.50906@oracle.com> <52E144C4.1090804@oracle.com> <52E145B0.2010605@oracle.com> <52E1A4FB.20300@oracle.com> Message-ID: <44769464-4A47-41E1-91D2-4F4EBB487BE0@oracle.com> Since it?s a product flag: - product(bool, UseOldInlining, true, \ - "Enable the 1.3 inlining strategy") \ do we have to put it in the obsolete flags list (obsolete_jvm_flags) or even file a CCC request? I wouldn?t think so because turning UseOldInlining off didn?t work anyway, as far as I know. On Jan 23, 2014, at 3:25 PM, Aleksey Shipilev wrote: > On 01/23/2014 08:39 PM, Aleksey Shipilev wrote: >> On 01/23/2014 08:35 PM, Vladimir Kozlov wrote: >>> On 1/23/14 8:28 AM, Aleksey Shipilev wrote: >>>> Right, thanks for spotting that! >>>> >>>> Updated: >>>> http://cr.openjdk.java.net/~shade/8032490/webrev.01/ >>> >>> Good. > > Rebased for jdk9/hs-comp: > http://cr.openjdk.java.net/~shade/8032490/webrev.02/ > > > -Aleksey. From vladimir.kozlov at oracle.com Thu Jan 23 20:13:34 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jan 2014 20:13:34 -0800 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <44769464-4A47-41E1-91D2-4F4EBB487BE0@oracle.com> References: <52E13A4E.6070102@oracle.com> <52E13EE7.8000104@oracle.com> <52E14346.50906@oracle.com> <52E144C4.1090804@oracle.com> <52E145B0.2010605@oracle.com> <52E1A4FB.20300@oracle.com> <44769464-4A47-41E1-91D2-4F4EBB487BE0@oracle.com> Message-ID: <52E1E86E.4070205@oracle.com> Yes, I think it is reasonable to put it into obsolete_jvm_flags (in arguments.cpp) but not CCC. Thank you, Christian for reminding. Vladimir On 1/23/14 7:23 PM, Christian Thalinger wrote: > Since it?s a product flag: > > - product(bool, UseOldInlining, true, \ > - "Enable the 1.3 inlining strategy") \ > > do we have to put it in the obsolete flags list (obsolete_jvm_flags) or even file a CCC request? I wouldn?t think so because turning UseOldInlining off didn?t work anyway, as far as I know. > > On Jan 23, 2014, at 3:25 PM, Aleksey Shipilev wrote: > >> On 01/23/2014 08:39 PM, Aleksey Shipilev wrote: >>> On 01/23/2014 08:35 PM, Vladimir Kozlov wrote: >>>> On 1/23/14 8:28 AM, Aleksey Shipilev wrote: >>>>> Right, thanks for spotting that! >>>>> >>>>> Updated: >>>>> http://cr.openjdk.java.net/~shade/8032490/webrev.01/ >>>> >>>> Good. >> >> Rebased for jdk9/hs-comp: >> http://cr.openjdk.java.net/~shade/8032490/webrev.02/ >> >> >> -Aleksey. > From roland.westrelin at oracle.com Fri Jan 24 00:37:25 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 24 Jan 2014 09:37:25 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <23EC49E4-1752-48E2-9771-040991E1E98D@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> <528BC0BF.8070803@oracle.com> <52D02F91.4080701@oracle.com> <703607B0-EEF4-4B04-AE47-E7EE005DD35B@oracle.com> <52D556EE.8000307@oracle.com> <410AB800-645F-4BBE-A95A-77ED239CBF89@oracle.com> <8788446E-73DF-4BCA-B0C2-CBD7C94A83BB@oracle.com> <52D7A239.60806@oracle.com> <97443F6C-F071-4800-98EE-B597A789B91B@oracle.com> <52D9CC65.9070108@oracle.com> <6212A762-67AB-4F5F-8C92-616430877D3F@oracle.com> <23EC49E4-1752-48E2-9771-040991E1E98D@oracle.com> Message-ID: <83D0E24D-16E0-4E33-B825-747915E59F97@oracle.com> > Yes, much better. Thank you. Thanks, Chris. Roland. From fweimer at redhat.com Fri Jan 24 01:09:13 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 24 Jan 2014 10:09:13 +0100 Subject: RFR(M): 8027754: Enable loop optimizations for loops with MathExact inside In-Reply-To: <20140123112723.GG9323@rbackman> References: <20140123112723.GG9323@rbackman> Message-ID: <52E22DB9.2000707@redhat.com> On 01/23/2014 12:27 PM, Rickard B?ckman wrote: > In the end we generate assembly like: > > mov rdx, rdi > add rdx, rsi > ... > mov rax, rdi > add rax, rsi > jo > > With one add instruction for the data and one for flags. Future > improvements could be to try to match the Overflow and the math > operation and remove one of them. You could use cmp instead of sub on x86 for the overflow case, which should be beneficial because the cmp instruction preserves both inputs and only updates the flags. Unfortunately, there is no similar companion instruction in the other cases, so I'm not sure if that's worth the effort. The mulofI_rReg_imm pattern definitions in x86_32.ad and x86_64.ad do not include the immediate operand in the format string. -- Florian Weimer / Red Hat Product Security Team From aleksey.shipilev at oracle.com Fri Jan 24 03:29:58 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 24 Jan 2014 15:29:58 +0400 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <52E1E86E.4070205@oracle.com> References: <52E13A4E.6070102@oracle.com> <52E13EE7.8000104@oracle.com> <52E14346.50906@oracle.com> <52E144C4.1090804@oracle.com> <52E145B0.2010605@oracle.com> <52E1A4FB.20300@oracle.com> <44769464-4A47-41E1-91D2-4F4EBB487BE0@oracle.com> <52E1E86E.4070205@oracle.com> Message-ID: <52E24EB6.7000800@oracle.com> Ok, here's the update: http://cr.openjdk.java.net/~shade/8032490/webrev.04/ (There is also the changeset ready to ease the push) -Aleksey. On 01/24/2014 08:13 AM, Vladimir Kozlov wrote: > Yes, I think it is reasonable to put it into obsolete_jvm_flags (in > arguments.cpp) but not CCC. Thank you, Christian for reminding. > > Vladimir > > On 1/23/14 7:23 PM, Christian Thalinger wrote: >> Since it?s a product flag: >> >> - product(bool, UseOldInlining, >> true, \ >> - "Enable the 1.3 inlining >> strategy") \ >> >> do we have to put it in the obsolete flags list (obsolete_jvm_flags) >> or even file a CCC request? I wouldn?t think so because turning >> UseOldInlining off didn?t work anyway, as far as I know. >> >> On Jan 23, 2014, at 3:25 PM, Aleksey Shipilev >> wrote: >> >>> On 01/23/2014 08:39 PM, Aleksey Shipilev wrote: >>>> On 01/23/2014 08:35 PM, Vladimir Kozlov wrote: >>>>> On 1/23/14 8:28 AM, Aleksey Shipilev wrote: >>>>>> Right, thanks for spotting that! >>>>>> >>>>>> Updated: >>>>>> http://cr.openjdk.java.net/~shade/8032490/webrev.01/ >>>>> >>>>> Good. >>> >>> Rebased for jdk9/hs-comp: >>> http://cr.openjdk.java.net/~shade/8032490/webrev.02/ >>> >>> >>> -Aleksey. >> From rickard.backman at oracle.com Fri Jan 24 03:48:01 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 24 Jan 2014 12:48:01 +0100 Subject: RFR(M): 8027754: Enable loop optimizations for loops with MathExact inside In-Reply-To: <52E22DB9.2000707@redhat.com> References: <20140123112723.GG9323@rbackman> <52E22DB9.2000707@redhat.com> Message-ID: <20140124114801.GJ9323@rbackman> Florian, thanks for the suggestion and catching that mistake. New webrev is on its ways. /R On 01/24, Florian Weimer wrote: > On 01/23/2014 12:27 PM, Rickard B?ckman wrote: > > >In the end we generate assembly like: > > > >mov rdx, rdi > >add rdx, rsi > >... > >mov rax, rdi > >add rax, rsi > >jo > > > >With one add instruction for the data and one for flags. Future > >improvements could be to try to match the Overflow and the math > >operation and remove one of them. > > You could use cmp instead of sub on x86 for the overflow case, which > should be beneficial because the cmp instruction preserves both > inputs and only updates the flags. Unfortunately, there is no > similar companion instruction in the other cases, so I'm not sure if > that's worth the effort. > > The mulofI_rReg_imm pattern definitions in x86_32.ad and x86_64.ad > do not include the immediate operand in the format string. > > -- > Florian Weimer / Red Hat Product Security Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140124/4574107f/attachment.bin From niclas.adlertz at oracle.com Fri Jan 24 03:59:29 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Fri, 24 Jan 2014 12:59:29 +0100 Subject: RFR(L) 8031498: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <52E0370D.3020906@oracle.com> References: <52D53871.40606@oracle.com> <20140114140353.GB9323@rbackman> <52D68C79.6070800@oracle.com> <52D690E6.50908@oracle.com> <52D7941D.2050801@oracle.com> <52D8FD9C.4090808@oracle.com> <52D9BCDC.8050100@oracle.com> <52DD1ADE.5050109@oracle.com> <52E0370D.3020906@oracle.com> Message-ID: <52E255A1.5070803@oracle.com> Thank you Vladimir. Kind Regards, Niclas Adlertz On 2014-01-22 22:24, Vladimir Kozlov wrote: > The bug id in the mail's Subject is incorrect. Should be 8031498. I > fixed it. > > Changes looks good. > > Thanks, > Vladimir > > On 1/20/14 4:47 AM, Niclas Adlertz wrote: >> Thank you Vladimir. >> >> I removed the references and removed some of the line breaks. >> >> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev04/ >> >> Kind Regards, >> Niclas Adlertz >> >> On 2014-01-18 00:29, Vladimir Kozlov wrote: >>> On 1/17/14 1:53 AM, Niclas Adlertz wrote: >>>> Vladimir, >>>> >>>> Thank you for your comments! >>>> >>>>> Vectors are separate from floats. Please, rename the method to >>>>> is_float_or_vector(). >>>> Done >>>> >>>>> >>>>> class Pressure. Field names start with '_' to separate then from >>>>> variables. >>>>> >>>> Done >>>> >>>>> Why you don't like to path pointer to liveout? It helped only in few >>>>> places but code in interfere_with_live() become complicated >>>>> (IndexSet& >>>>> liveout and then elements(&liveout)). >>>> I thought it looked better to send in the liveout as a reference since >>>> it was allocated on stack in build_ifg_physical: >>>> IndexSet liveout(_live->live(block)); >>>> But if you want me revert the change I can do that. >>> >>> The final consumer IndexSetIterator of liveout needs pointer. You have >>> to add additional conversion in sources which I don't like: >>> >>> foo(IndexSet& liveout) { >>> IndexSetIterator elements(&liveout); >>> >>> It makes code more complex to understand. >>> >>> Also in build_ifg_physical() you have too many empty lines. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> >>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev03/ >>>> >>>> Kind Regards, >>>> Niclas Adlertz >>>> >>>> >>>> On 2014-01-16 09:11, Vladimir Kozlov wrote: >>>>> Niclas, >>>>> >>>>> Changes are good. I have few notes. >>>>> >>>>> Vectors are separate from floats. Please, rename the method to >>>>> is_float_or_vector(). >>>>> >>>>> class Pressure. Field names start with '_' to separate then from >>>>> variables. >>>>> >>>>> Why you don't like to path pointer to liveout? It helped only in few >>>>> places but code in interfere_with_live() become complicated >>>>> (IndexSet& >>>>> liveout and then elements(&liveout)). >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/15/14 5:45 AM, Niclas Adlertz wrote: >>>>>> Hi again, >>>>>> >>>>>> I found a commented section that I forgot to remove in chaitin.hpp: >>>>>> >>>>>> // stores the first low-to-high transition (starting from the top of >>>>>> block) >>>>>> //uint final_high_pressure_index; >>>>>> >>>>>> Updated the webrev: >>>>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev02/ >>>>>> >>>>>> On 2014-01-15 14:26, Niclas Adlertz wrote: >>>>>>> Hi Rickard, >>>>>>> >>>>>>> Thank you for your comments. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev01/ >>>>>>> >>>>>>> Kind Regards, >>>>>>> Niclas Adlertz >>>>>>> >>>>>>> On 2014-01-14 15:03, Rickard B?ckman wrote: >>>>>>>> Just a few comments on the C++ parts. I haven't verified that the >>>>>>>> logic >>>>>>>> is still the same. >>>>>>>> >>>>>>>> 1) It seems like there are a couple of functions that could be >>>>>>>> created >>>>>>>> in the new Pressure class to avoid code duplication. One >>>>>>>> example is >>>>>>>> the >>>>>>>> check_for_high_pressure_block method. >>>>>>>> >>>>>>>> 2) All places that checks lrg._is_float also check lrg._is_vector. >>>>>>>> That >>>>>>>> check could be made into a boolean method on the LRG instead. The >>>>>>>> same >>>>>>>> for is_UP() & mask_size(). >>>>>>>> >>>>>>>> 3) To make code more generic the int_pressure and float_pressure >>>>>>>> instances could be passed the INTPRESSURE and FLOATPRESSURE and >>>>>>>> keep >>>>>>>> those as instance variables. >>>>>>>> >>>>>>>> Good work. >>>>>>>> >>>>>>>> /R >>>>>>>> >>>>>>>> On 01/14, Niclas Adlertz wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> This is a first step to clean up the register allocator in C2. In >>>>>>>>> this change we have divided the very long method >>>>>>>>> build_ifg_physical() into many smaller ones, making it easier to >>>>>>>>> see the steps when building the IFG (and computing >>>>>>>>> the block pressure). >>>>>>>>> We have also cleaned up old comments and improved old code, both >>>>>>>>> by better naming and by simplifying expressions. >>>>>>>>> I personally think that the easiest way to review this change is >>>>>>>>> to have the old and new ifg.cpp side by side, and >>>>>>>>> start from build_ifg_physical(). >>>>>>>>> The next step is to create a new class for these methods, >>>>>>>>> isolating them and removing them from PhaseChaitin. >>>>>>>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ >>>>>>>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 >>>>>>>>> >>>>>>>>> Kind Regards, >>>>>>>>> Niclas Adlertz >>>>>>> >>>>>> >>>> >> From niclas.adlertz at oracle.com Fri Jan 24 04:00:36 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Fri, 24 Jan 2014 13:00:36 +0100 Subject: RFR(L) 8031498: Cleanup and re-factorize PhaseChaitin::build_ifg_physical() In-Reply-To: <88758943-1881-4882-8674-C67F9C9984A2@oracle.com> References: <52D53871.40606@oracle.com> <20140114140353.GB9323@rbackman> <52D68C79.6070800@oracle.com> <52D690E6.50908@oracle.com> <52D7941D.2050801@oracle.com> <52D8FD9C.4090808@oracle.com> <52D9BCDC.8050100@oracle.com> <52DD1ADE.5050109@oracle.com> <52E0370D.3020906@oracle.com> <88758943-1881-4882-8674-C67F9C9984A2@oracle.com> Message-ID: <52E255E4.3070004@oracle.com> Thank you Roland. I've corrected the things you asked me to do. Kind Regards, Niclas Adlertz On 2014-01-23 11:01, Roland Westrelin wrote: > Hi Niclas, > > It looks good to me. Nice cleanup. A few minor comments. No need to send another webrev: > > Isn?t assignment in tests: > > 294 while ((interfering_lid = elements.next()) != 0) { > 399 while ((lidx = elements.next()) != 0) { > 414 while ((lidx = elements.next()) != 0) { > 507 while ((lid = elements.next()) != 0) { > > something we try to avoid? > > Messages in asserts are nice: > 439 assert(int_pressure._current_pressure == count_int_pressure(liveout), "" ); > 440 assert(float_pressure._current_pressure == count_float_pressure(liveout), ""); > > if (idx != 0) { > > is better than > > 627 if (idx) { > > > Roland. > > On Jan 22, 2014, at 10:24 PM, Vladimir Kozlov wrote: > >> The bug id in the mail's Subject is incorrect. Should be 8031498. I fixed it. >> >> Changes looks good. >> >> Thanks, >> Vladimir >> >> On 1/20/14 4:47 AM, Niclas Adlertz wrote: >>> Thank you Vladimir. >>> >>> I removed the references and removed some of the line breaks. >>> >>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev04/ >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> On 2014-01-18 00:29, Vladimir Kozlov wrote: >>>> On 1/17/14 1:53 AM, Niclas Adlertz wrote: >>>>> Vladimir, >>>>> >>>>> Thank you for your comments! >>>>> >>>>>> Vectors are separate from floats. Please, rename the method to >>>>>> is_float_or_vector(). >>>>> Done >>>>> >>>>>> class Pressure. Field names start with '_' to separate then from >>>>>> variables. >>>>>> >>>>> Done >>>>> >>>>>> Why you don't like to path pointer to liveout? It helped only in few >>>>>> places but code in interfere_with_live() become complicated (IndexSet& >>>>>> liveout and then elements(&liveout)). >>>>> I thought it looked better to send in the liveout as a reference since >>>>> it was allocated on stack in build_ifg_physical: >>>>> IndexSet liveout(_live->live(block)); >>>>> But if you want me revert the change I can do that. >>>> The final consumer IndexSetIterator of liveout needs pointer. You have >>>> to add additional conversion in sources which I don't like: >>>> >>>> foo(IndexSet& liveout) { >>>> IndexSetIterator elements(&liveout); >>>> >>>> It makes code more complex to understand. >>>> >>>> Also in build_ifg_physical() you have too many empty lines. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev03/ >>>>> >>>>> Kind Regards, >>>>> Niclas Adlertz >>>>> >>>>> >>>>> On 2014-01-16 09:11, Vladimir Kozlov wrote: >>>>>> Niclas, >>>>>> >>>>>> Changes are good. I have few notes. >>>>>> >>>>>> Vectors are separate from floats. Please, rename the method to >>>>>> is_float_or_vector(). >>>>>> >>>>>> class Pressure. Field names start with '_' to separate then from >>>>>> variables. >>>>>> >>>>>> Why you don't like to path pointer to liveout? It helped only in few >>>>>> places but code in interfere_with_live() become complicated (IndexSet& >>>>>> liveout and then elements(&liveout)). >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 1/15/14 5:45 AM, Niclas Adlertz wrote: >>>>>>> Hi again, >>>>>>> >>>>>>> I found a commented section that I forgot to remove in chaitin.hpp: >>>>>>> >>>>>>> // stores the first low-to-high transition (starting from the top of >>>>>>> block) >>>>>>> //uint final_high_pressure_index; >>>>>>> >>>>>>> Updated the webrev: >>>>>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev02/ >>>>>>> >>>>>>> On 2014-01-15 14:26, Niclas Adlertz wrote: >>>>>>>> Hi Rickard, >>>>>>>> >>>>>>>> Thank you for your comments. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev01/ >>>>>>>> >>>>>>>> Kind Regards, >>>>>>>> Niclas Adlertz >>>>>>>> >>>>>>>> On 2014-01-14 15:03, Rickard B?ckman wrote: >>>>>>>>> Just a few comments on the C++ parts. I haven't verified that the >>>>>>>>> logic >>>>>>>>> is still the same. >>>>>>>>> >>>>>>>>> 1) It seems like there are a couple of functions that could be >>>>>>>>> created >>>>>>>>> in the new Pressure class to avoid code duplication. One example is >>>>>>>>> the >>>>>>>>> check_for_high_pressure_block method. >>>>>>>>> >>>>>>>>> 2) All places that checks lrg._is_float also check lrg._is_vector. >>>>>>>>> That >>>>>>>>> check could be made into a boolean method on the LRG instead. The >>>>>>>>> same >>>>>>>>> for is_UP() & mask_size(). >>>>>>>>> >>>>>>>>> 3) To make code more generic the int_pressure and float_pressure >>>>>>>>> instances could be passed the INTPRESSURE and FLOATPRESSURE and keep >>>>>>>>> those as instance variables. >>>>>>>>> >>>>>>>>> Good work. >>>>>>>>> >>>>>>>>> /R >>>>>>>>> >>>>>>>>> On 01/14, Niclas Adlertz wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> This is a first step to clean up the register allocator in C2. In >>>>>>>>>> this change we have divided the very long method >>>>>>>>>> build_ifg_physical() into many smaller ones, making it easier to >>>>>>>>>> see the steps when building the IFG (and computing >>>>>>>>>> the block pressure). >>>>>>>>>> We have also cleaned up old comments and improved old code, both >>>>>>>>>> by better naming and by simplifying expressions. >>>>>>>>>> I personally think that the easiest way to review this change is >>>>>>>>>> to have the old and new ifg.cpp side by side, and >>>>>>>>>> start from build_ifg_physical(). >>>>>>>>>> The next step is to create a new class for these methods, >>>>>>>>>> isolating them and removing them from PhaseChaitin. >>>>>>>>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8031498/webrev00/ >>>>>>>>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8031498 >>>>>>>>>> >>>>>>>>>> Kind Regards, >>>>>>>>>> Niclas Adlertz From albert.noll at oracle.com Fri Jan 24 05:50:35 2014 From: albert.noll at oracle.com (Albert) Date: Fri, 24 Jan 2014 14:50:35 +0100 Subject: [9] RFR(XXS): 8009738: compiler/6826736/Test.java times out on big machines Message-ID: <52E26FAB.5090804@oracle.com> Hi, could I get reviews for this small patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8009738 webrev: http://cr.openjdk.java.net/~anoll/8009738/webrev.00/ Problem: test times out on big machines Solution: add -Xmx256m -XX:ParallelGCThreads=4 to @run command (as described in the bug description). I verified that the old bug is still triggered with the added flags by undoing the changes (except for asserts) that where committed with https://bugs.openjdk.java.net/browse/JDK-6826736 . The test does not complete, since and fails with an assert: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/export/anoll/latest/src/share/vm/compiler/oopMap.cpp:438), pid=24776, tid=140280127788800 # assert(Universe::heap()->is_in_or_null(*loc)) failed: found non oop pointer A rough performance evaluation on a 32-core linux (64-bit) system shows that the execution time of the test goes down to ~40 seconds. Without the suggested changes, the execution time is around 9 minutes on the same machine. Best, Albert These changes trigger the assert described above: --- old/src/share/vm/compiler/oopMap.cpp 2014-01-24 14:46:14.370474128 +0100 +++ new/src/share/vm/compiler/oopMap.cpp 2014-01-24 14:46:14.302474129 +0100 @@ -392,14 +392,15 @@ oop *base_loc = fr->oopmapreg_to_location(omv.content_reg(), reg_map); oop *derived_loc = loc; oop val = *base_loc; - if (val == (oop)NULL || Universe::is_narrow_oop_base(val)) { + derived_oop_fn(base_loc, derived_loc); + /*if (val == (oop)NULL || Universe::is_narrow_oop_base(val)) { // Ignore NULL oops and decoded NULL narrow oops which // equal to Universe::narrow_oop_base when a narrow oop // implicit null check is used in compiled code. // The narrow_oop_base could be NULL or be the address // of the page below heap depending on compressed oops mode. } else - derived_oop_fn(base_loc, derived_loc); + derived_oop_fn(base_loc, derived_loc);*/ } oms.next(); } while (!oms.is_done()); @@ -414,7 +415,7 @@ oop* loc = fr->oopmapreg_to_location(omv.reg(),reg_map); if ( loc != NULL ) { if ( omv.type() == OopMapValue::oop_value ) { - oop val = *loc; + /* oop val = *loc; if (val == (oop)NULL || Universe::is_narrow_oop_base(val)) { // Ignore NULL oops and decoded NULL narrow oops which // equal to Universe::narrow_oop_base when a narrow oop @@ -422,7 +423,7 @@ // The narrow_oop_base could be NULL or be the address // of the page below heap depending on compressed oops mode. continue; - } + }*/ #ifdef ASSERT if ((((uintptr_t)loc & (sizeof(*loc)-1)) != 0) || !Universe::heap()->is_in_or_null(*loc)) { --- old/src/share/vm/runtime/stackValue.cpp 2014-01-24 14:46:14.374474128 +0100 +++ new/src/share/vm/runtime/stackValue.cpp 2014-01-24 14:46:14.302474129 +0100 @@ -108,7 +108,8 @@ } #endif case Location::oop: { - oop val = *(oop *)value_addr; + Handle h(*(oop *)value_addr); // Wrap a handle around the oop + /*oop val = *(oop *)value_addr; #ifdef _LP64 if (Universe::is_narrow_oop_base(val)) { // Compiled code may produce decoded oop = narrow_oop_base @@ -118,7 +119,7 @@ val = (oop)NULL; } #endif - Handle h(val); // Wrap a handle around the oop + Handle h(val); // Wrap a handle around the oop*/ return new StackValue(h); } case Location::addr: { -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140124/d2cee8d5/attachment.html From vladimir.kozlov at oracle.com Fri Jan 24 06:53:13 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 06:53:13 -0800 Subject: [9] RFR(XXS): 8009738: compiler/6826736/Test.java times out on big machines In-Reply-To: <52E26FAB.5090804@oracle.com> References: <52E26FAB.5090804@oracle.com> Message-ID: <52E27E59.9060402@oracle.com> Albert, You made typo: -Xms256m instead of -Xmx256m You limit only young gen. Thanks, Vladimir On 1/24/14 5:50 AM, Albert wrote: > Hi, > > could I get reviews for this small patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8009738 > webrev: http://cr.openjdk.java.net/~anoll/8009738/webrev.00/ > > Problem: test times out on big machines > > Solution: add -Xmx256m -XX:ParallelGCThreads=4 to @run command (as described in the bug description). > I verified that the old bug is still triggered with the added flags by undoing the > changes (except for asserts) that where committed with https://bugs.openjdk.java.net/browse/JDK-6826736 . > The test does not complete, since and fails with an assert: > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/export/anoll/latest/src/share/vm/compiler/oopMap.cpp:438), pid=24776, tid=140280127788800 > # assert(Universe::heap()->is_in_or_null(*loc)) failed: found non oop pointer > > A rough performance evaluation on a 32-core linux (64-bit) system shows that the execution time > of the test goes down to ~40 seconds. Without the suggested changes, the execution time is around > 9 minutes on the same machine. > > Best, > Albert > > These changes trigger the assert described above: > > --- old/src/share/vm/compiler/oopMap.cpp 2014-01-24 14:46:14.370474128 +0100 > +++ new/src/share/vm/compiler/oopMap.cpp 2014-01-24 14:46:14.302474129 +0100 > @@ -392,14 +392,15 @@ > oop *base_loc = fr->oopmapreg_to_location(omv.content_reg(), reg_map); > oop *derived_loc = loc; > oop val = *base_loc; > - if (val == (oop)NULL || Universe::is_narrow_oop_base(val)) { > + derived_oop_fn(base_loc, derived_loc); > + /*if (val == (oop)NULL || Universe::is_narrow_oop_base(val)) { > // Ignore NULL oops and decoded NULL narrow oops which > // equal to Universe::narrow_oop_base when a narrow oop > // implicit null check is used in compiled code. > // The narrow_oop_base could be NULL or be the address > // of the page below heap depending on compressed oops mode. > } else > - derived_oop_fn(base_loc, derived_loc); > + derived_oop_fn(base_loc, derived_loc);*/ > } > oms.next(); > } while (!oms.is_done()); > @@ -414,7 +415,7 @@ > oop* loc = fr->oopmapreg_to_location(omv.reg(),reg_map); > if ( loc != NULL ) { > if ( omv.type() == OopMapValue::oop_value ) { > - oop val = *loc; > + /* oop val = *loc; > if (val == (oop)NULL || Universe::is_narrow_oop_base(val)) { > // Ignore NULL oops and decoded NULL narrow oops which > // equal to Universe::narrow_oop_base when a narrow oop > @@ -422,7 +423,7 @@ > // The narrow_oop_base could be NULL or be the address > // of the page below heap depending on compressed oops mode. > continue; > - } > + }*/ > #ifdef ASSERT > if ((((uintptr_t)loc & (sizeof(*loc)-1)) != 0) || > !Universe::heap()->is_in_or_null(*loc)) { > --- old/src/share/vm/runtime/stackValue.cpp 2014-01-24 14:46:14.374474128 +0100 > +++ new/src/share/vm/runtime/stackValue.cpp 2014-01-24 14:46:14.302474129 +0100 > @@ -108,7 +108,8 @@ > } > #endif > case Location::oop: { > - oop val = *(oop *)value_addr; > + Handle h(*(oop *)value_addr); // Wrap a handle around the oop > + /*oop val = *(oop *)value_addr; > #ifdef _LP64 > if (Universe::is_narrow_oop_base(val)) { > // Compiled code may produce decoded oop = narrow_oop_base > @@ -118,7 +119,7 @@ > val = (oop)NULL; > } > #endif > - Handle h(val); // Wrap a handle around the oop > + Handle h(val); // Wrap a handle around the oop*/ > return new StackValue(h); > } > case Location::addr: { From staffan.larsen at oracle.com Fri Jan 24 07:09:43 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 24 Jan 2014 16:09:43 +0100 Subject: RFR(S): JDK-8032662 : test/compiler/ciReplay/TestSA.sh should report ulimit issues Message-ID: <19BDACDA-E7A3-46BC-8980-DBC57A205386@oracle.com> Please review this small fix to a test to provide additional diagnostics on failures. webrev: http://cr.openjdk.java.net/~sla/8032662/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8032662 Thanks, /Staffan From vladimir.kozlov at oracle.com Fri Jan 24 07:16:02 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 07:16:02 -0800 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <52E24EB6.7000800@oracle.com> References: <52E13A4E.6070102@oracle.com> <52E13EE7.8000104@oracle.com> <52E14346.50906@oracle.com> <52E144C4.1090804@oracle.com> <52E145B0.2010605@oracle.com> <52E1A4FB.20300@oracle.com> <44769464-4A47-41E1-91D2-4F4EBB487BE0@oracle.com> <52E1E86E.4070205@oracle.com> <52E24EB6.7000800@oracle.com> Message-ID: <52E283B2.9020701@oracle.com> Good. I will push it. thanks, Vladimir On 1/24/14 3:29 AM, Aleksey Shipilev wrote: > Ok, here's the update: > http://cr.openjdk.java.net/~shade/8032490/webrev.04/ > > (There is also the changeset ready to ease the push) > > -Aleksey. > > On 01/24/2014 08:13 AM, Vladimir Kozlov wrote: >> Yes, I think it is reasonable to put it into obsolete_jvm_flags (in >> arguments.cpp) but not CCC. Thank you, Christian for reminding. >> >> Vladimir >> >> On 1/23/14 7:23 PM, Christian Thalinger wrote: >>> Since it?s a product flag: >>> >>> - product(bool, UseOldInlining, >>> true, \ >>> - "Enable the 1.3 inlining >>> strategy") \ >>> >>> do we have to put it in the obsolete flags list (obsolete_jvm_flags) >>> or even file a CCC request? I wouldn?t think so because turning >>> UseOldInlining off didn?t work anyway, as far as I know. >>> >>> On Jan 23, 2014, at 3:25 PM, Aleksey Shipilev >>> wrote: >>> >>>> On 01/23/2014 08:39 PM, Aleksey Shipilev wrote: >>>>> On 01/23/2014 08:35 PM, Vladimir Kozlov wrote: >>>>>> On 1/23/14 8:28 AM, Aleksey Shipilev wrote: >>>>>>> Right, thanks for spotting that! >>>>>>> >>>>>>> Updated: >>>>>>> http://cr.openjdk.java.net/~shade/8032490/webrev.01/ >>>>>> >>>>>> Good. >>>> >>>> Rebased for jdk9/hs-comp: >>>> http://cr.openjdk.java.net/~shade/8032490/webrev.02/ >>>> >>>> >>>> -Aleksey. >>> > From vladimir.kozlov at oracle.com Fri Jan 24 07:22:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 07:22:11 -0800 Subject: RFR(S): JDK-8032662 : test/compiler/ciReplay/TestSA.sh should report ulimit issues In-Reply-To: <19BDACDA-E7A3-46BC-8980-DBC57A205386@oracle.com> References: <19BDACDA-E7A3-46BC-8980-DBC57A205386@oracle.com> Message-ID: <52E28523.5010607@oracle.com> Looks fine to me but I want Igor's opinion as well since he is the author. Thanks, Vladimir On 1/24/14 7:09 AM, Staffan Larsen wrote: > Please review this small fix to a test to provide additional diagnostics on failures. > > webrev: http://cr.openjdk.java.net/~sla/8032662/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8032662 > > Thanks, > /Staffan > From igor.ignatyev at oracle.com Fri Jan 24 07:25:48 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 24 Jan 2014 19:25:48 +0400 Subject: RFR(S): JDK-8032662 : test/compiler/ciReplay/TestSA.sh should report ulimit issues In-Reply-To: <52E28523.5010607@oracle.com> References: <19BDACDA-E7A3-46BC-8980-DBC57A205386@oracle.com> <52E28523.5010607@oracle.com> Message-ID: <52E285FC.6030806@oracle.com> I'm not sure that all system returns 'unlimited', some of them may return '-1', so I'd prefer '$new_ulimit != "unlimited" -a $new_ulimit != "-1"' as the condition. In the rest, looks good. Igor On 01/24/2014 07:22 PM, Vladimir Kozlov wrote: > Looks fine to me but I want Igor's opinion as well since he is the author. > > Thanks, > Vladimir > > On 1/24/14 7:09 AM, Staffan Larsen wrote: >> Please review this small fix to a test to provide additional >> diagnostics on failures. >> >> webrev: http://cr.openjdk.java.net/~sla/8032662/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8032662 >> >> Thanks, >> /Staffan >> From aleksey.shipilev at oracle.com Fri Jan 24 07:30:11 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 24 Jan 2014 19:30:11 +0400 Subject: RFR (S) 8032490: Remove -XX:+-UseOldInlining In-Reply-To: <52E283B2.9020701@oracle.com> References: <52E13A4E.6070102@oracle.com> <52E13EE7.8000104@oracle.com> <52E14346.50906@oracle.com> <52E144C4.1090804@oracle.com> <52E145B0.2010605@oracle.com> <52E1A4FB.20300@oracle.com> <44769464-4A47-41E1-91D2-4F4EBB487BE0@oracle.com> <52E1E86E.4070205@oracle.com> <52E24EB6.7000800@oracle.com> <52E283B2.9020701@oracle.com> Message-ID: <52E28703.5070702@oracle.com> Thanks! -Aleksey. On 01/24/2014 07:16 PM, Vladimir Kozlov wrote: > Good. I will push it. > > thanks, > Vladimir > > On 1/24/14 3:29 AM, Aleksey Shipilev wrote: >> Ok, here's the update: >> http://cr.openjdk.java.net/~shade/8032490/webrev.04/ >> >> (There is also the changeset ready to ease the push) >> >> -Aleksey. >> >> On 01/24/2014 08:13 AM, Vladimir Kozlov wrote: >>> Yes, I think it is reasonable to put it into obsolete_jvm_flags (in >>> arguments.cpp) but not CCC. Thank you, Christian for reminding. >>> >>> Vladimir >>> >>> On 1/23/14 7:23 PM, Christian Thalinger wrote: >>>> Since it?s a product flag: >>>> >>>> - product(bool, UseOldInlining, >>>> true, \ >>>> - "Enable the 1.3 inlining >>>> strategy") \ >>>> >>>> do we have to put it in the obsolete flags list (obsolete_jvm_flags) >>>> or even file a CCC request? I wouldn?t think so because turning >>>> UseOldInlining off didn?t work anyway, as far as I know. >>>> >>>> On Jan 23, 2014, at 3:25 PM, Aleksey Shipilev >>>> wrote: >>>> >>>>> On 01/23/2014 08:39 PM, Aleksey Shipilev wrote: >>>>>> On 01/23/2014 08:35 PM, Vladimir Kozlov wrote: >>>>>>> On 1/23/14 8:28 AM, Aleksey Shipilev wrote: >>>>>>>> Right, thanks for spotting that! >>>>>>>> >>>>>>>> Updated: >>>>>>>> http://cr.openjdk.java.net/~shade/8032490/webrev.01/ >>>>>>> >>>>>>> Good. >>>>> >>>>> Rebased for jdk9/hs-comp: >>>>> http://cr.openjdk.java.net/~shade/8032490/webrev.02/ >>>>> >>>>> >>>>> -Aleksey. >>>> >> From staffan.larsen at oracle.com Fri Jan 24 08:05:38 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 24 Jan 2014 17:05:38 +0100 Subject: RFR(S): JDK-8032662 : test/compiler/ciReplay/TestSA.sh should report ulimit issues In-Reply-To: <52E285FC.6030806@oracle.com> References: <19BDACDA-E7A3-46BC-8980-DBC57A205386@oracle.com> <52E28523.5010607@oracle.com> <52E285FC.6030806@oracle.com> Message-ID: <72F6C9C5-0A64-426C-A9FA-F4BFBBACCC6A@oracle.com> That sounds like a good idea. new webrev: http://cr.openjdk.java.net/~sla/8032662/webrev.01/ /Staffan On 24 jan 2014, at 16:25, Igor Ignatyev wrote: > I'm not sure that all system returns 'unlimited', some of them may return '-1', so I'd prefer '$new_ulimit != "unlimited" -a $new_ulimit != "-1"' as the condition. > > In the rest, looks good. > > Igor > > On 01/24/2014 07:22 PM, Vladimir Kozlov wrote: >> Looks fine to me but I want Igor's opinion as well since he is the author. >> >> Thanks, >> Vladimir >> >> On 1/24/14 7:09 AM, Staffan Larsen wrote: >>> Please review this small fix to a test to provide additional >>> diagnostics on failures. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8032662/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8032662 >>> >>> Thanks, >>> /Staffan >>> From vladimir.kozlov at oracle.com Fri Jan 24 08:29:07 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 08:29:07 -0800 Subject: RFR(S): JDK-8032662 : test/compiler/ciReplay/TestSA.sh should report ulimit issues In-Reply-To: <72F6C9C5-0A64-426C-A9FA-F4BFBBACCC6A@oracle.com> References: <19BDACDA-E7A3-46BC-8980-DBC57A205386@oracle.com> <52E28523.5010607@oracle.com> <52E285FC.6030806@oracle.com> <72F6C9C5-0A64-426C-A9FA-F4BFBBACCC6A@oracle.com> Message-ID: <52E294D3.4050902@oracle.com> Good. Vladimir On 1/24/14 8:05 AM, Staffan Larsen wrote: > That sounds like a good idea. > > new webrev: http://cr.openjdk.java.net/~sla/8032662/webrev.01/ > > /Staffan > > On 24 jan 2014, at 16:25, Igor Ignatyev wrote: > >> I'm not sure that all system returns 'unlimited', some of them may return '-1', so I'd prefer '$new_ulimit != "unlimited" -a $new_ulimit != "-1"' as the condition. >> >> In the rest, looks good. >> >> Igor >> >> On 01/24/2014 07:22 PM, Vladimir Kozlov wrote: >>> Looks fine to me but I want Igor's opinion as well since he is the author. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/24/14 7:09 AM, Staffan Larsen wrote: >>>> Please review this small fix to a test to provide additional >>>> diagnostics on failures. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8032662/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032662 >>>> >>>> Thanks, >>>> /Staffan >>>> > From albert.noll at oracle.com Fri Jan 24 11:20:57 2014 From: albert.noll at oracle.com (Albert) Date: Fri, 24 Jan 2014 20:20:57 +0100 Subject: [9] RFR(XXS): 8009738: compiler/6826736/Test.java times out on big machines In-Reply-To: <52E27E59.9060402@oracle.com> References: <52E26FAB.5090804@oracle.com> <52E27E59.9060402@oracle.com> Message-ID: <52E2BD19.7000509@oracle.com> Hi Vladimir, thanks for looking at the patch and catching the error. Here is the corrected version. http://cr.openjdk.java.net/~anoll/8009738/webrev.01/ Best, Albert On 01/24/2014 03:53 PM, Vladimir Kozlov wrote: > Albert, > > You made typo: -Xms256m instead of -Xmx256m > You limit only young gen. > > Thanks, > Vladimir > > On 1/24/14 5:50 AM, Albert wrote: >> Hi, >> >> could I get reviews for this small patch? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8009738 >> webrev: http://cr.openjdk.java.net/~anoll/8009738/webrev.00/ >> >> >> Problem: test times out on big machines >> >> Solution: add -Xmx256m -XX:ParallelGCThreads=4 to @run command (as >> described in the bug description). >> I verified that the old bug is still triggered with the added flags >> by undoing the >> changes (except for asserts) that where committed with >> https://bugs.openjdk.java.net/browse/JDK-6826736 . >> The test does not complete, since and fails with an assert: >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> (/export/anoll/latest/src/share/vm/compiler/oopMap.cpp:438), >> pid=24776, tid=140280127788800 >> # assert(Universe::heap()->is_in_or_null(*loc)) failed: found non >> oop pointer >> >> A rough performance evaluation on a 32-core linux (64-bit) system >> shows that the execution time >> of the test goes down to ~40 seconds. Without the suggested changes, >> the execution time is around >> 9 minutes on the same machine. >> >> Best, >> Albert >> >> These changes trigger the assert described above: >> >> --- old/src/share/vm/compiler/oopMap.cpp 2014-01-24 >> 14:46:14.370474128 +0100 >> +++ new/src/share/vm/compiler/oopMap.cpp 2014-01-24 >> 14:46:14.302474129 +0100 >> @@ -392,14 +392,15 @@ >> oop *base_loc = >> fr->oopmapreg_to_location(omv.content_reg(), reg_map); >> oop *derived_loc = loc; >> oop val = *base_loc; >> - if (val == (oop)NULL || Universe::is_narrow_oop_base(val)) { >> + derived_oop_fn(base_loc, derived_loc); >> + /*if (val == (oop)NULL || >> Universe::is_narrow_oop_base(val)) { >> // Ignore NULL oops and decoded NULL narrow oops which >> // equal to Universe::narrow_oop_base when a narrow oop >> // implicit null check is used in compiled code. >> // The narrow_oop_base could be NULL or be the address >> // of the page below heap depending on compressed oops >> mode. >> } else >> - derived_oop_fn(base_loc, derived_loc); >> + derived_oop_fn(base_loc, derived_loc);*/ >> } >> oms.next(); >> } while (!oms.is_done()); >> @@ -414,7 +415,7 @@ >> oop* loc = fr->oopmapreg_to_location(omv.reg(),reg_map); >> if ( loc != NULL ) { >> if ( omv.type() == OopMapValue::oop_value ) { >> - oop val = *loc; >> + /* oop val = *loc; >> if (val == (oop)NULL || Universe::is_narrow_oop_base(val)) { >> // Ignore NULL oops and decoded NULL narrow oops which >> // equal to Universe::narrow_oop_base when a narrow oop >> @@ -422,7 +423,7 @@ >> // The narrow_oop_base could be NULL or be the address >> // of the page below heap depending on compressed oops >> mode. >> continue; >> - } >> + }*/ >> #ifdef ASSERT >> if ((((uintptr_t)loc & (sizeof(*loc)-1)) != 0) || >> !Universe::heap()->is_in_or_null(*loc)) { >> --- old/src/share/vm/runtime/stackValue.cpp 2014-01-24 >> 14:46:14.374474128 +0100 >> +++ new/src/share/vm/runtime/stackValue.cpp 2014-01-24 >> 14:46:14.302474129 +0100 >> @@ -108,7 +108,8 @@ >> } >> #endif >> case Location::oop: { >> - oop val = *(oop *)value_addr; >> + Handle h(*(oop *)value_addr); // Wrap a handle around the oop >> + /*oop val = *(oop *)value_addr; >> #ifdef _LP64 >> if (Universe::is_narrow_oop_base(val)) { >> // Compiled code may produce decoded oop = narrow_oop_base >> @@ -118,7 +119,7 @@ >> val = (oop)NULL; >> } >> #endif >> - Handle h(val); // Wrap a handle around the oop >> + Handle h(val); // Wrap a handle around the oop*/ >> return new StackValue(h); >> } >> case Location::addr: { -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140124/e74728e0/attachment-0001.html From vladimir.kozlov at oracle.com Fri Jan 24 11:41:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 11:41:00 -0800 Subject: [9] RFR(XXS): 8009738: compiler/6826736/Test.java times out on big machines In-Reply-To: <52E2BD19.7000509@oracle.com> References: <52E26FAB.5090804@oracle.com> <52E27E59.9060402@oracle.com> <52E2BD19.7000509@oracle.com> Message-ID: <52E2C1CC.2030306@oracle.com> Good. Thanks, Vladimir On 1/24/14 11:20 AM, Albert wrote: > Hi Vladimir, > > thanks for looking at the patch and catching the error. > Here is the corrected version. > > http://cr.openjdk.java.net/~anoll/8009738/webrev.01/ > > > Best, > Albert > > On 01/24/2014 03:53 PM, Vladimir Kozlov wrote: >> Albert, >> >> You made typo: -Xms256m instead of -Xmx256m >> You limit only young gen. >> >> Thanks, >> Vladimir >> >> On 1/24/14 5:50 AM, Albert wrote: >>> Hi, >>> >>> could I get reviews for this small patch? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8009738 >>> webrev: http://cr.openjdk.java.net/~anoll/8009738/webrev.00/ >>> >>> >>> Problem: test times out on big machines >>> >>> Solution: add -Xmx256m -XX:ParallelGCThreads=4 to @run command (as >>> described in the bug description). >>> I verified that the old bug is still triggered with the added flags >>> by undoing the >>> changes (except for asserts) that where committed with >>> https://bugs.openjdk.java.net/browse/JDK-6826736 . >>> The test does not complete, since and fails with an assert: >>> >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error >>> (/export/anoll/latest/src/share/vm/compiler/oopMap.cpp:438), >>> pid=24776, tid=140280127788800 >>> # assert(Universe::heap()->is_in_or_null(*loc)) failed: found non >>> oop pointer >>> >>> A rough performance evaluation on a 32-core linux (64-bit) system >>> shows that the execution time >>> of the test goes down to ~40 seconds. Without the suggested changes, >>> the execution time is around >>> 9 minutes on the same machine. >>> >>> Best, >>> Albert >>> >>> These changes trigger the assert described above: >>> >>> --- old/src/share/vm/compiler/oopMap.cpp 2014-01-24 >>> 14:46:14.370474128 +0100 >>> +++ new/src/share/vm/compiler/oopMap.cpp 2014-01-24 >>> 14:46:14.302474129 +0100 >>> @@ -392,14 +392,15 @@ >>> oop *base_loc = >>> fr->oopmapreg_to_location(omv.content_reg(), reg_map); >>> oop *derived_loc = loc; >>> oop val = *base_loc; >>> - if (val == (oop)NULL || Universe::is_narrow_oop_base(val)) { >>> + derived_oop_fn(base_loc, derived_loc); >>> + /*if (val == (oop)NULL || >>> Universe::is_narrow_oop_base(val)) { >>> // Ignore NULL oops and decoded NULL narrow oops which >>> // equal to Universe::narrow_oop_base when a narrow oop >>> // implicit null check is used in compiled code. >>> // The narrow_oop_base could be NULL or be the address >>> // of the page below heap depending on compressed oops >>> mode. >>> } else >>> - derived_oop_fn(base_loc, derived_loc); >>> + derived_oop_fn(base_loc, derived_loc);*/ >>> } >>> oms.next(); >>> } while (!oms.is_done()); >>> @@ -414,7 +415,7 @@ >>> oop* loc = fr->oopmapreg_to_location(omv.reg(),reg_map); >>> if ( loc != NULL ) { >>> if ( omv.type() == OopMapValue::oop_value ) { >>> - oop val = *loc; >>> + /* oop val = *loc; >>> if (val == (oop)NULL || Universe::is_narrow_oop_base(val)) { >>> // Ignore NULL oops and decoded NULL narrow oops which >>> // equal to Universe::narrow_oop_base when a narrow oop >>> @@ -422,7 +423,7 @@ >>> // The narrow_oop_base could be NULL or be the address >>> // of the page below heap depending on compressed oops >>> mode. >>> continue; >>> - } >>> + }*/ >>> #ifdef ASSERT >>> if ((((uintptr_t)loc & (sizeof(*loc)-1)) != 0) || >>> !Universe::heap()->is_in_or_null(*loc)) { >>> --- old/src/share/vm/runtime/stackValue.cpp 2014-01-24 >>> 14:46:14.374474128 +0100 >>> +++ new/src/share/vm/runtime/stackValue.cpp 2014-01-24 >>> 14:46:14.302474129 +0100 >>> @@ -108,7 +108,8 @@ >>> } >>> #endif >>> case Location::oop: { >>> - oop val = *(oop *)value_addr; >>> + Handle h(*(oop *)value_addr); // Wrap a handle around the oop >>> + /*oop val = *(oop *)value_addr; >>> #ifdef _LP64 >>> if (Universe::is_narrow_oop_base(val)) { >>> // Compiled code may produce decoded oop = narrow_oop_base >>> @@ -118,7 +119,7 @@ >>> val = (oop)NULL; >>> } >>> #endif >>> - Handle h(val); // Wrap a handle around the oop >>> + Handle h(val); // Wrap a handle around the oop*/ >>> return new StackValue(h); >>> } >>> case Location::addr: { > From christian.thalinger at oracle.com Fri Jan 24 12:25:02 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 24 Jan 2014 12:25:02 -0800 Subject: RFR(M): 8031752: Failed speculative optimization should be reattempted when root of compilation is different In-Reply-To: References: <53AF84F9-E4CD-413D-A93D-697C2A22DC31@oracle.com> <59433D21-24FF-4C91-965C-17B2C0049A92@oracle.com> <52D84DC0.7030609@oracle.com> <9E69EF09-B3A5-42CC-8480-1A5C2CBF2375@oracle.com> <52D963DC.8000301@oracle.com> Message-ID: Looks good. On Jan 20, 2014, at 2:28 AM, Roland Westrelin wrote: > Here is a new webrev with Chris? suggestions: > > http://cr.openjdk.java.net/~roland/8031752/webrev.02/ > > Vladimir, I didn?t include your suggestion because as you mention trap_recompiled_at() needs the method argument. > > Roland. > > On Jan 17, 2014, at 6:09 PM, Vladimir Kozlov wrote: > >> Sorry, I was not clear. I suggested to move next reason check >> >> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >> + if (md->has_trap_at(bci, m, reason) != 0) { >> >> inside has_trap_at(): >> >> int has_trap_at(int bci, ciMethod* m, int reason) { >> if (!Deoptimization::reason_is_speculate(reason)) { >> m = NULL; >> } >> return has_trap_at(bci_to_data(bci, m), reason); >> } >> >> and path method always: >> >> + if (md->has_trap_at(bci, this->method(), reason) != 0) { >> >> The are 2 places where you do that. But I see that in the second case 'm' is also passed to trap_recompiled_at(). So my suggestion may be not good. IT is up to you. >> >> Thanks, >> Vladimir >> >> On 1/17/14 5:03 AM, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>> Thanks for taking a loot at this. >>> >>>> Can you pass method to has_trap_at() and check the reason inside instead of current assert? >>> >>> Sorry, but I don?t understand what change you?d like to see. >>> Is this the assert you?re talking about: >>> >>> int has_trap_at(int bci, ciMethod* m, int reason) { >>> assert((m != NULL) == Deoptimization::reason_is_speculate(reason), "inconsistent method/reason"); >>> return has_trap_at(bci_to_data(bci, m), reason); >>> } >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/16/14 8:32 AM, Roland Westrelin wrote: >>>>> Thanks for reviewing this, Chris. >>>>> >>>>> Here is a new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~roland/8031752/webrev.01/ >>>>> >>>>> And comments below: >>>>> >>>>>> All these print_data_on changes are a pain: >>>>>> >>>>>> ! virtual void print_data_on(outputStream* st, const char* extra) const { >>>>>> >>>>>> I see you actually pass something in only in one place. How does the output look like? Can?t you print the ?extra? output in ProfileData::print_data_on directly after the other output? >>>>> >>>>> I want the speculative traps to be listed together with the byte code they affect. Diagnosing a missed optimization is much easier that way. Here is an example output: >>>>> >>>>> 6 ldc_w TestTrapSpeculate$B >>>>> 9 if_acmpne 19 >>>>> 64 bci: 9 BranchData trap(class_check recompiled) trap/ TestTrapSpeculate::m2(class_check recompiled) trap/ TestTrapSpeculate::m1(class_check recompiled) >>>>> not taken(10) >>>>> 12 fast_aload_0 >>>>> >>>>> But the speculative traps are not stored with the ProfileData for each byte code. So I need to pass something to each ProfileData::print_data_on() that can be used to print the speculative traps. I decided to pass a formatted string with the trap stuff. Which is then passed to ProfileData::print_shared() where the per byte code line is printed. >>>>> >>>>>> src/share/vm/oops/methodData.cpp: >>>>>> >>>>>> + case Bytecodes::_invokestatic: >>>>>> + return UseTypeSpeculation; >>>>>> + } >>>>>> + return false; >>>>>> >>>>>> Could you move the return false into a default case of the switch? At some point I would like to enable the compiler warnings about switches not having all cases (-Wswitch). >>>>> >>>>> Ok. >>>>> >>>>>> >>>>>> int empty_bc_count = 0; // number of bytecodes lacking data >>>>>> + bool has_spec_bc = false; >>>>>> >>>>>> That name is hard to understand for people new to the code. At least the first ugly name has a comment. >>>>> >>>>> Would needs_speculative_traps be better? >>>>> >>>>>> >>>>>> + DataLayout* MethodData::next_extra(DataLayout* dp) { >>>>>> + int nb_cells = 0; >>>>>> + if (dp->tag() == DataLayout::bit_data_tag || dp->tag() == DataLayout::no_tag) { >>>>>> + nb_cells = BitData::static_cell_count(); >>>>>> + } else if (dp->tag() == DataLayout::speculative_trap_data_tag) { >>>>>> + nb_cells = SpeculativeTrapData::static_cell_count(); >>>>>> + } else { >>>>>> + fatal(err_msg("unexpected tag %d", dp->tag())); >>>>>> + } >>>>>> >>>>>> It would be easier to read with a switch instead of if-else. Maybe also in MethodData::print_data_on. The assert: >>>>>> >>>>>> assert(dp->tag() == DataLayout::arg_info_data_tag, "must be BitData or ArgInfo?); >>>>>> >>>>>> is now out-of-date and the code could have a fatal instead. Same in MethodData::clean_method_data. >>>>> >>>>> Ok. So I tried to use switches when iterating over the extra data everywhere. The problem is that break, breaks out of the switch but not out of the loop anymore. The new MethodData::next_extra() doesn?t know how to move past a arg_info_data_tag because it?s a static method. It?s a static method because it?s used by ciMethodData as well. So I need to break out of the loop before calling the last MethodData::next_extra(). Anyway, I refactored the code so that the loops are in their own methods and then I can return from them to jump out of the switch and loop. >>>>> >>>>>> >>>>>> src/share/vm/opto/compile.cpp: >>>>>> >>>>>> ! if (md->has_trap_at(bci, Deoptimization::reason_is_speculate(reason) ? this->method() : NULL, reason) != 0) { >>>>>> >>>>>> Can you factor this to a local variable as you do later: >>>>>> >>>>>> + ciMethod* m = Deoptimization::reason_is_speculate(reason) ? this->method() : NULL; >>>>>> if ((per_bc_reason == Deoptimization::Reason_none >>>>>> ! || md->has_trap_at(bci, m, reason) != 0) >>>>>> >>>>>> ? >>>>>> >>>>> >>>>> Ok. >>>>> >>>>>> src/share/vm/runtime/globals.hpp: >>>>>> >>>>>> + product(intx, PerMethodSpecTrapLimit, 5000, \ >>>>>> + "Limit on speculative traps (of one kind) in a method (includes inlines)") \ >>>>>> >>>>>> + product(intx, SpecTrapLimitExtraEntries, 3, \ >>>>>> + "Extra method data trap entries for speculation") \ >>>>>> >>>>>> Do we need these new flags to be product flags? >>>>> >>>>> At this point, it?s unclear whether those values are going to be good enough so I think we need to be able to adjust the parameters in benchmark runs. >>>>> >>>>>> src/share/vm/ci/ciMethodData.cpp: >>>>>> >>>>>> ! void ciParametersTypeData::print_data_on(outputStream* st, const char* extra) const { >>>>>> ! st->print_cr("Parametertypes"); >>>>>> ! st->print_cr("ciParameterTypesData?); >>>>>> >>>>>> Typo replaced with a typo :-) >>>>> >>>>> Indeed. >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> On Jan 15, 2014, at 3:19 AM, Roland Westrelin wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8031752/webrev.00/ >>>>>>> >>>>>>> When C2 optimizes the code based on type profiling, it emits a guard. If the guard fails, the code "traps" and the location of the trap (method, bci) and cause (class check) are recorded. When C2 generates code for that method again, it doesn't perform any optimization of that type (class check) at that location (bci). >>>>>>> >>>>>>> If, say, the trap occurs at (m, bci) when m is inlined in m1. When m2 that inlines m is compiled, no class check optimization is performed at (m, bci) because of the trap triggered in m1. With type speculation, type information is flowing from many profiling points in the application code. So in the example above, the profile data used at (m, bci) may come from m1 when the compiled method is m1 and it may be come from m2 when the compiled method is m2. And so the trap at (m,bci) in compiled method m1 doesn't say much about the validity of a speculative optimization at (m,bci) when the compiled method is m2. >>>>>>> >>>>>>> When a trap occurs from a speculative optimization, the trap should record: (method, bci, compiled method) so that in the example above: erroneous optimization at (m, bci) is not reattempted if m1 is re-compiled but is attempted when m2 is compiled. >>>>>>> >>>>>>> With nashorn, peak performance varies a lot from one run to another for some benchmarks. This is one of the causes. Depending on the order of compilations, what?s compiled or not, what?s inlined or not, some optimizations may or may not be performed. >>>>>>> >>>>>>> This change adds a new type of traps (SpeculativeTrapData). They record the nmethod?s method where the trap occurs. They are allocated in the extra data space of the MDO. If no more space is available in the extra data space, the VM fallbacks to standard traps. >>>>>>> >>>>>>> I also added a PerMethodSpecTrapLimit similar to PerMethodTrapLimit but for speculative traps. Its value is much higher. That appears to be required as well to have reproducible peak performance results from one run to another. >>>>>>> >>>>>>> I have a couple more changes that help reduce performance variation with nashorn and that I will send for review later. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>> >>>>>> >>>>> >>> > From albert.noll at oracle.com Fri Jan 24 12:52:26 2014 From: albert.noll at oracle.com (Albert) Date: Fri, 24 Jan 2014 21:52:26 +0100 Subject: [9] RFR(XXS): 8009738: compiler/6826736/Test.java times out on big machines In-Reply-To: <52E2C1CC.2030306@oracle.com> References: <52E26FAB.5090804@oracle.com> <52E27E59.9060402@oracle.com> <52E2BD19.7000509@oracle.com> <52E2C1CC.2030306@oracle.com> Message-ID: <52E2D28A.9040301@oracle.com> Thank you, Vladimir. Best, Albert On 01/24/2014 08:41 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 1/24/14 11:20 AM, Albert wrote: >> Hi Vladimir, >> >> thanks for looking at the patch and catching the error. >> Here is the corrected version. >> >> http://cr.openjdk.java.net/~anoll/8009738/webrev.01/ >> >> >> Best, >> Albert >> >> On 01/24/2014 03:53 PM, Vladimir Kozlov wrote: >>> Albert, >>> >>> You made typo: -Xms256m instead of -Xmx256m >>> You limit only young gen. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/24/14 5:50 AM, Albert wrote: >>>> Hi, >>>> >>>> could I get reviews for this small patch? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8009738 >>>> webrev: http://cr.openjdk.java.net/~anoll/8009738/webrev.00/ >>>> >>>> >>>> Problem: test times out on big machines >>>> >>>> Solution: add -Xmx256m -XX:ParallelGCThreads=4 to @run command (as >>>> described in the bug description). >>>> I verified that the old bug is still triggered with the added flags >>>> by undoing the >>>> changes (except for asserts) that where committed with >>>> https://bugs.openjdk.java.net/browse/JDK-6826736 . >>>> The test does not complete, since and fails with an assert: >>>> >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # Internal Error >>>> (/export/anoll/latest/src/share/vm/compiler/oopMap.cpp:438), >>>> pid=24776, tid=140280127788800 >>>> # assert(Universe::heap()->is_in_or_null(*loc)) failed: found non >>>> oop pointer >>>> >>>> A rough performance evaluation on a 32-core linux (64-bit) system >>>> shows that the execution time >>>> of the test goes down to ~40 seconds. Without the suggested changes, >>>> the execution time is around >>>> 9 minutes on the same machine. >>>> >>>> Best, >>>> Albert >>>> >>>> These changes trigger the assert described above: >>>> >>>> --- old/src/share/vm/compiler/oopMap.cpp 2014-01-24 >>>> 14:46:14.370474128 +0100 >>>> +++ new/src/share/vm/compiler/oopMap.cpp 2014-01-24 >>>> 14:46:14.302474129 +0100 >>>> @@ -392,14 +392,15 @@ >>>> oop *base_loc = >>>> fr->oopmapreg_to_location(omv.content_reg(), reg_map); >>>> oop *derived_loc = loc; >>>> oop val = *base_loc; >>>> - if (val == (oop)NULL || >>>> Universe::is_narrow_oop_base(val)) { >>>> + derived_oop_fn(base_loc, derived_loc); >>>> + /*if (val == (oop)NULL || >>>> Universe::is_narrow_oop_base(val)) { >>>> // Ignore NULL oops and decoded NULL narrow oops which >>>> // equal to Universe::narrow_oop_base when a narrow oop >>>> // implicit null check is used in compiled code. >>>> // The narrow_oop_base could be NULL or be the address >>>> // of the page below heap depending on compressed oops >>>> mode. >>>> } else >>>> - derived_oop_fn(base_loc, derived_loc); >>>> + derived_oop_fn(base_loc, derived_loc);*/ >>>> } >>>> oms.next(); >>>> } while (!oms.is_done()); >>>> @@ -414,7 +415,7 @@ >>>> oop* loc = fr->oopmapreg_to_location(omv.reg(),reg_map); >>>> if ( loc != NULL ) { >>>> if ( omv.type() == OopMapValue::oop_value ) { >>>> - oop val = *loc; >>>> + /* oop val = *loc; >>>> if (val == (oop)NULL || >>>> Universe::is_narrow_oop_base(val)) { >>>> // Ignore NULL oops and decoded NULL narrow oops which >>>> // equal to Universe::narrow_oop_base when a narrow oop >>>> @@ -422,7 +423,7 @@ >>>> // The narrow_oop_base could be NULL or be the address >>>> // of the page below heap depending on compressed oops >>>> mode. >>>> continue; >>>> - } >>>> + }*/ >>>> #ifdef ASSERT >>>> if ((((uintptr_t)loc & (sizeof(*loc)-1)) != 0) || >>>> !Universe::heap()->is_in_or_null(*loc)) { >>>> --- old/src/share/vm/runtime/stackValue.cpp 2014-01-24 >>>> 14:46:14.374474128 +0100 >>>> +++ new/src/share/vm/runtime/stackValue.cpp 2014-01-24 >>>> 14:46:14.302474129 +0100 >>>> @@ -108,7 +108,8 @@ >>>> } >>>> #endif >>>> case Location::oop: { >>>> - oop val = *(oop *)value_addr; >>>> + Handle h(*(oop *)value_addr); // Wrap a handle around the oop >>>> + /*oop val = *(oop *)value_addr; >>>> #ifdef _LP64 >>>> if (Universe::is_narrow_oop_base(val)) { >>>> // Compiled code may produce decoded oop = narrow_oop_base >>>> @@ -118,7 +119,7 @@ >>>> val = (oop)NULL; >>>> } >>>> #endif >>>> - Handle h(val); // Wrap a handle around the oop >>>> + Handle h(val); // Wrap a handle around the oop*/ >>>> return new StackValue(h); >>>> } >>>> case Location::addr: { >> From jon.masamitsu at oracle.com Fri Jan 24 14:05:22 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 24 Jan 2014 14:05:22 -0800 Subject: Request for review (s) - 8031290: Adjust call to getisax() for additional words returned In-Reply-To: <52D8464A.8090009@oracle.com> References: <52D8464A.8090009@oracle.com> Message-ID: <52E2E3A2.3020501@oracle.com> I've made fixes for all review comments and remerged. New webrev is at http://cr.openjdk.java.net/~jmasa/8031290/webrev.01/ Thanks. Jon On 1/16/2014 12:51 PM, Jon Masamitsu wrote: > 8031290: Adjust call to getisax() for additional words returned > > Accept the 2nd word returned by getisax() on Solaris and use > its contents to recognize AV2_SPARC_SPARC5 instructions. > > http://cr.openjdk.java.net/~jmasa/8031290/webrev.00/ > > Should this integrate through hotspot-compiler? > > Thanks to Vladimir for most of this fix. > > Jon From vladimir.kozlov at oracle.com Fri Jan 24 15:16:21 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 15:16:21 -0800 Subject: Request for review (s) - 8031290: Adjust call to getisax() for additional words returned In-Reply-To: <52E2E3A2.3020501@oracle.com> References: <52D8464A.8090009@oracle.com> <52E2E3A2.3020501@oracle.com> Message-ID: <52E2F445.3050006@oracle.com> Good. Vladimir On 1/24/14 2:05 PM, Jon Masamitsu wrote: > I've made fixes for all review comments and remerged. New > webrev is at > > http://cr.openjdk.java.net/~jmasa/8031290/webrev.01/ > > Thanks. > > Jon > > On 1/16/2014 12:51 PM, Jon Masamitsu wrote: >> 8031290: Adjust call to getisax() for additional words returned >> >> Accept the 2nd word returned by getisax() on Solaris and use >> its contents to recognize AV2_SPARC_SPARC5 instructions. >> >> http://cr.openjdk.java.net/~jmasa/8031290/webrev.00/ >> >> Should this integrate through hotspot-compiler? >> >> Thanks to Vladimir for most of this fix. >> >> Jon > From vladimir.kozlov at oracle.com Fri Jan 24 17:53:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 17:53:30 -0800 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method In-Reply-To: <865C3299-3E60-40D4-84AA-8EEA27ADAF99@oracle.com> References: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> <52E091D0.3010508@oracle.com> <52E09526.7030907@oracle.com> <865C3299-3E60-40D4-84AA-8EEA27ADAF99@oracle.com> Message-ID: <52E3191A.60604@oracle.com> On 1/23/14 7:06 AM, Roland Westrelin wrote: > Thanks for looking at this, Vladimir. > >>> My wild guess is that the outermost method generally gives you the best >>> (cleanest) context information. The inner callees may have been called >>> from various callers, and so their type profiles may have been polluted >>> by other callers. >> >> They can't be polluted. We record only one speculative type. If Interpreter see a different type it will set flags and that type information will not be used. At least that is how I understand it works. That is why I am asking Roland to clarify this. > > That?s the way they work. What can happen for this (and what happens sometimes I believe): > > m1() { > m3(); > } > > m() { > m1(); > m2(); > } > > is that m3() is a heavily used method called from some other place early during the application run. Some profile is recorded. The method becomes so hot that it gets compiled with c2. So we stop profiling. Then m3() is called from m1() but because it?s already compiled we don?t record the conflicting profile. When m() is compiled we are stuck with an incorrect profile and we may miss some optimization opportunities. Okay, it makes sense. So m3() has totally unrelated to current compilation type information. But you should have some uncommon traps which will force deoptimization of m3() if type is wrong when you run m1(). On other hand deoptimization may not happen fast enough before we compile m(). I agree we can have such case. What about case when m3() calls m4() only when m3() is called from m()->m1()? In such situation m4() will collect correct type for m() compilation(). But it will be overwritten by bad type from m3(). > > As Krys said, intuitively "the outermost method generally gives you the best (cleanest) context information?. It?s only a heuristic and as such, it?s certainly easy to build a test case for which this heuristic doesn?t do a good job. It does help for experiments I made with nashorn so I?d like to see it used to confirm it does help. Is it possible to detect type discrepancy in m3() and ignore (by special marking) all non-matching speculative types in m3()? You already do prefer speculative type from call's parameters over type collected for input arguments. Right? May be use that as indication that types in inlined method could be wrong. Thanks, Vladimir > > Roland. > > >> >> If you have merging case: >> >> if (x) >> m1() >> else >> m2() >> >> I don't understand why at merge point information from m2 will be more precise then from m3() called from m1(). >> >> Thanks, >> Vladimir >> >>> >>> - Kris >>> >>> >>> On Wed, Jan 22, 2014 at 7:51 PM, Vladimir Kozlov >>> > wrote: >>> >>> Roland, >>> >>> I don't see how inlining depth can define type's accuracy in general >>> case. why it can't be reverse: more accurate type from most deeply >>> inlined method? >>> >>> I thought you only have speculative type if it is the only one type >>> record in MDO. How in your case you can have different types? >>> >>> Can you be more specific? >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 1/22/14 1:42 AM, Roland Westrelin wrote: >>> >>> When a node already has a speculative type, and parsing >>> encounters extra profiling data, the new profiling data is >>> ignored. So profiling data coming from profile points closer to >>> the root of the compilation is favored which I think makes >>> sense: it's the data that is most specific to the context of >>> this compilation. >>> >>> During runs, profile data is not always entirely coherent so we >>> may hit something like this: >>> m1() { >>> m3(); >>> } >>> >>> m() { >>> m1(); >>> m2(); >>> } >>> >>> With: m3() and m2() have profile data for the same node. The >>> first profile data to be encountered during parsing is from m3() >>> and profile data from m2() is ignored but profile data from m2() >>> is the one that is actually the most specific and is the one >>> that should be favored. >>> >>> When a speculative type is created, this change records the >>> inline depth at which the profile point is. The inline depth is >>> then propagated together with the rest of the type information. >>> When new profile data is available for a node that already has a >>> speculative type, the current inline depth and the inline depth >>> of the current speculative type are used to decide whether the >>> new data should be used to replace the existing speculative type. >>> >>> This change helps stabilize performance with nashorn. >>> >>> http://cr.openjdk.java.net/~__roland/8031754/webrev.00/ >>> >>> >>> Roland. > From vladimir.kozlov at oracle.com Sun Jan 26 12:41:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 26 Jan 2014 12:41:29 -0800 Subject: Escape Analysis and Stack Allocation In-Reply-To: References: Message-ID: <52E572F9.2020304@oracle.com> Hi Benedict, Thank you for your detailed analysis. You did not point the paper you are referencing. I assume it is "Escape Analysis in the Context of Dynamic Compilation and Deoptimization" from Linz. Note, the implementation described in the paper was done for Client compiler (C1). In production Hotspot Server compiler (C2) we use only "Interprocedural Analysis" from that work (code in bcEscapeAnalyzer). The escape analysis for compiled method in C2 (escape.cpp) is based on different paper: "Escape Analysis for Java" [Choi99]. There is big difference how "Interprocedural Analysis" is used in C2. In the first paper "the interprocedural analysis supports the compiler in inlining decisions". In current implementation in C2 it is only used to determine the GLOBAL escaping state of arguments passed to non-inlined methods. The escape state of arguments is already ArgEscape since we have to pass parameters to a call in generated code. I agree that current usage of interprocedural analysis is too conservative and we could modify code in bcEscapeAnalyzer to serve better for C2. About set_method_escape(). You are right, it is used to indicate that we need to keep pointer to object and can't scalar replace it. In current implementation the only important case is the load from an object fields or from an object array. This information is used in escape.cpp to indicate that fields or array elements can globally escape: set_fields_escape_state. I agree that using set_method_escape() for stores into primitive arrays is useless but it is harmless. But we should not do that for stores into object arrays or into field because the store does not modify the state of objects in array or in field. And, yes, it is inconsistent with putfield code which does use set_method_escape(). About set_global_escape() for an object stored into an array or a field. The Interprocedural analysis is done using only one pass over bytecode. We don't know if the array or the object into which we store will globally escape later. We conservatively assume it does escape. The code doesn't keep a record which object is stored into which array (or field), so we can't adjust its state after analysis is finished. I agree that functions names are confusing and not always reflect the meaning. I filed RFE: "Improve Inter-procedural Escape Analysis" to cleanup bcEscapeAnalyzer: https://bugs.openjdk.java.net/browse/JDK-8032761 Currently C2 does not allocate non-escaped objects on native stack. Such objects are still allocated in java heap. We only remove locks for such objects. Allocation on stack would require significant changes in JIT code and especially in GC. Currently GC only supports java objects in CONTINUES java heap. Note, allocation in java heap is very fast (pointer arithmetic) so stack allocation will not help to throughput performance. It may only help to reduce frequency of GC. But GC time may increase since GC have to do special casing for stack allocated objects. But it would be interesting to see an actual data from a research anyway. Regards, Vladimir On 1/25/14 10:04 PM, Benedict Elliott Smith wrote: > Hi, > > I was digging into some (to me) unexpected behaviour of escape analysis, > namely that some references that clearly weren't escaping, and easily > determined to be so, were not being stack allocated. > > So, after some digging through the hotspot code, I discovered some things > that were probably obvious to everyone on this list, but also some things > I'm still a little perplexed about. I was hoping somebody could enlighten > me about the latter. > > 1) I cannot see a reason why stores to a primitive array, for instance, > should cause the argument to escape in bcEscapeAnalyser.cpp > *iterate_one_block()*; most interestingly, a store to an object array does > not result in this, which seems incongruous; > > 2) An object array store *does* however result in *set_global_escape()* for > the value being stored, which makes sense, except that this should only be > *set_method_escape()*, as per the paper, in the case where the target array > is one of the method arguments. This seems to be missing, here and for > *putfield*. > > Some other weird ones are *arraylength*, *getfield*, *ifnonnull*, etc. The > fact that these all result in *set_method_escape()*, and that *putfield*and > *aastore* don't optimise *set_global_escape()* to > *set_method_escape()*where possible, seem to point to the conclusion > that *_is_arg_stack > / set_method_escape()* actually encode only *!is_scalar_replaceable*. Is > this the case? If so, why the confusing name?* > > > Which leads to a much trickier but more interesting question, which is: > what are the barriers to performing actual stack allocation of full > objects, instead of scalar replacement? It is something I would be keen to > investigate, but given my lack of familiarity with the codebase, it would > be immensely helpful to hear what the major difficulties / showstoppers > might be before trying to attack it. > > Thanks in advance, > > Benedict > > > *I do note that in escape.cpp *ArgEscape* is defined and is explicitly > overloaded to include some of the characteristics of *is_scalar_replaceable*. > However the *is_arg_stack()* method is commented with "The given argument > escapes the callee, but does not become globally reachable." which seems to > correspond to *ArgEscape* in the paper, but only *invoke()* seems to follow > the spec, when invoking a method that cannot be analysed, and this would > also be true for *!is_scalar_replaceable.* > From albert.noll at oracle.com Mon Jan 27 00:15:12 2014 From: albert.noll at oracle.com (Albert) Date: Mon, 27 Jan 2014 09:15:12 +0100 Subject: [9] RFR(XS): 8032642: Fix testbugs in compiler/startup/.* Message-ID: <52E61590.7010804@oracle.com> Hi, could I get reviews for these small changes? bug: https://bugs.openjdk.java.net/browse/JDK-8032642 webrev: http://cr.openjdk.java.net/~anoll/8032642/webrev.00/ Problems: (1) compiler/startup/SmallCodeCacheStartup.java should use "@run main/othervm" (2) compiler/startup/StartupOutput.java should use correct @library path Many thanks in advance, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140127/e8f11803/attachment.html From vladimir.kozlov at oracle.com Mon Jan 27 01:03:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jan 2014 01:03:14 -0800 Subject: [9] RFR(XS): 8032642: Fix testbugs in compiler/startup/.* In-Reply-To: <52E61590.7010804@oracle.com> References: <52E61590.7010804@oracle.com> Message-ID: <52E620D2.2060400@oracle.com> Looks good. Thanks, Vladimir On 1/27/14 12:15 AM, Albert wrote: > Hi, > > could I get reviews for these small changes? > > bug: https://bugs.openjdk.java.net/browse/JDK-8032642 > webrev: http://cr.openjdk.java.net/~anoll/8032642/webrev.00/ > > Problems: > (1) compiler/startup/SmallCodeCacheStartup.java should use "@run main/othervm" > (2) compiler/startup/StartupOutput.java should use correct @library path > > Many thanks in advance, > Albert From albert.noll at oracle.com Mon Jan 27 01:44:32 2014 From: albert.noll at oracle.com (Albert) Date: Mon, 27 Jan 2014 10:44:32 +0100 Subject: [9] RFR(XS): 8032642: Fix testbugs in compiler/startup/.* In-Reply-To: <52E620D2.2060400@oracle.com> References: <52E61590.7010804@oracle.com> <52E620D2.2060400@oracle.com> Message-ID: <52E62A80.2020408@oracle.com> Thank you, Vladimir. Best, Albert On 01/27/2014 10:03 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 1/27/14 12:15 AM, Albert wrote: >> Hi, >> >> could I get reviews for these small changes? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8032642 >> webrev: http://cr.openjdk.java.net/~anoll/8032642/webrev.00/ >> >> >> Problems: >> (1) compiler/startup/SmallCodeCacheStartup.java should use "@run >> main/othervm" >> (2) compiler/startup/StartupOutput.java should use correct @library path >> >> Many thanks in advance, >> Albert From staffan.larsen at oracle.com Mon Jan 27 01:58:40 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 27 Jan 2014 10:58:40 +0100 Subject: RFR(S): JDK-8032662 : test/compiler/ciReplay/TestSA.sh should report ulimit issues In-Reply-To: <52E294D3.4050902@oracle.com> References: <19BDACDA-E7A3-46BC-8980-DBC57A205386@oracle.com> <52E28523.5010607@oracle.com> <52E285FC.6030806@oracle.com> <72F6C9C5-0A64-426C-A9FA-F4BFBBACCC6A@oracle.com> <52E294D3.4050902@oracle.com> Message-ID: Thanks! On 24 jan 2014, at 17:29, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 1/24/14 8:05 AM, Staffan Larsen wrote: >> That sounds like a good idea. >> >> new webrev: http://cr.openjdk.java.net/~sla/8032662/webrev.01/ >> >> /Staffan >> >> On 24 jan 2014, at 16:25, Igor Ignatyev wrote: >> >>> I'm not sure that all system returns 'unlimited', some of them may return '-1', so I'd prefer '$new_ulimit != "unlimited" -a $new_ulimit != "-1"' as the condition. >>> >>> In the rest, looks good. >>> >>> Igor >>> >>> On 01/24/2014 07:22 PM, Vladimir Kozlov wrote: >>>> Looks fine to me but I want Igor's opinion as well since he is the author. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/24/14 7:09 AM, Staffan Larsen wrote: >>>>> Please review this small fix to a test to provide additional >>>>> diagnostics on failures. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sla/8032662/webrev.00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032662 >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >> From christian.thalinger at oracle.com Mon Jan 27 09:11:20 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Jan 2014 09:11:20 -0800 Subject: [9] RFR(XS): 8032642: Fix testbugs in compiler/startup/.* In-Reply-To: <52E61590.7010804@oracle.com> References: <52E61590.7010804@oracle.com> Message-ID: <27FA3232-AAFA-4850-9227-6436DFD0F246@oracle.com> The changes look good but I have a question. Is there potentially another way to test this without using: -XX:ReservedCodeCacheSize=3m -XX:CICompilerCount=64 ? On Jan 27, 2014, at 12:15 AM, Albert wrote: > Hi, > > could I get reviews for these small changes? > > bug: https://bugs.openjdk.java.net/browse/JDK-8032642 > webrev: http://cr.openjdk.java.net/~anoll/8032642/webrev.00/ > > Problems: > (1) compiler/startup/SmallCodeCacheStartup.java should use "@run main/othervm" > (2) compiler/startup/StartupOutput.java should use correct @library path > > Many thanks in advance, > Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140127/ea5162a4/attachment.html From vladimir.kozlov at oracle.com Mon Jan 27 09:23:25 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jan 2014 09:23:25 -0800 Subject: RFR (XS): 8032566: Crash in JIT when running Scala compiler (and compiling Scala std lib) In-Reply-To: <52E2A52C.3080801@oracle.com> References: <52E2A52C.3080801@oracle.com> Message-ID: <52E6960D.9060006@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8032566 http://cr.openjdk.java.net/~kvn/8032566/webrev/ Switch off EliminateAutoBox flag by default in jdk8 release. Appropriate fix will be done in 8u20 later. Thanks, Vladimir From igor.veresov at oracle.com Mon Jan 27 09:29:01 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 27 Jan 2014 09:29:01 -0800 Subject: RFR (XS): 8032566: Crash in JIT when running Scala compiler (and compiling Scala std lib) In-Reply-To: <52E6960D.9060006@oracle.com> References: <52E2A52C.3080801@oracle.com> <52E6960D.9060006@oracle.com> Message-ID: Looks good. igor On Jan 27, 2014, at 9:23 AM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8032566 > http://cr.openjdk.java.net/~kvn/8032566/webrev/ > > Switch off EliminateAutoBox flag by default in jdk8 release. > Appropriate fix will be done in 8u20 later. > > Thanks, > Vladimir > > > From vladimir.kozlov at oracle.com Mon Jan 27 09:29:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jan 2014 09:29:53 -0800 Subject: RFR (XS): 8032566: Crash in JIT when running Scala compiler (and compiling Scala std lib) In-Reply-To: References: <52E2A52C.3080801@oracle.com> <52E6960D.9060006@oracle.com> Message-ID: <52E69791.1040407@oracle.com> Thank you, Igor Vladimir On 1/27/14 9:29 AM, Igor Veresov wrote: > Looks good. > > igor > > On Jan 27, 2014, at 9:23 AM, Vladimir Kozlov wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8032566 >> http://cr.openjdk.java.net/~kvn/8032566/webrev/ >> >> Switch off EliminateAutoBox flag by default in jdk8 release. >> Appropriate fix will be done in 8u20 later. >> >> Thanks, >> Vladimir >> >> >> > From roland.westrelin at oracle.com Mon Jan 27 09:58:07 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 27 Jan 2014 18:58:07 +0100 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method In-Reply-To: <52E3191A.60604@oracle.com> References: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> <52E091D0.3010508@oracle.com> <52E09526.7030907@oracle.com> <865C3299-3E60-40D4-84AA-8EEA27ADAF99@oracle.com> <52E3191A.60604@oracle.com> Message-ID: <3FE1C7FB-C7E3-4032-9A40-946061F7A97D@oracle.com> Hi Vladimir, >> Thanks for looking at this, Vladimir. >> >>>> My wild guess is that the outermost method generally gives you the best >>>> (cleanest) context information. The inner callees may have been called >>>> from various callers, and so their type profiles may have been polluted >>>> by other callers. >>> >>> They can't be polluted. We record only one speculative type. If Interpreter see a different type it will set flags and that type information will not be used. At least that is how I understand it works. That is why I am asking Roland to clarify this. >> >> That?s the way they work. What can happen for this (and what happens sometimes I believe): >> >> m1() { >> m3(); >> } >> >> m() { >> m1(); >> m2(); >> } >> >> is that m3() is a heavily used method called from some other place early during the application run. Some profile is recorded. The method becomes so hot that it gets compiled with c2. So we stop profiling. Then m3() is called from m1() but because it?s already compiled we don?t record the conflicting profile. When m() is compiled we are stuck with an incorrect profile and we may miss some optimization opportunities. > > Okay, it makes sense. So m3() has totally unrelated to current compilation type information. But you should have some uncommon traps which will force deoptimization of m3() if type is wrong when you run m1(). On other hand deoptimization may not happen fast enough before we compile m(). I agree we can have such case. > > What about case when m3() calls m4() only when m3() is called from m()->m1()? In such situation m4() will collect correct type for m() compilation(). But it will be overwritten by bad type from m3(). But in this case, for m4() to have profile, the branch that calls m4() must have been run and the profile there should be consistent with the profile in m3()? >> >> As Krys said, intuitively "the outermost method generally gives you the best (cleanest) context information?. It?s only a heuristic and as such, it?s certainly easy to build a test case for which this heuristic doesn?t do a good job. It does help for experiments I made with nashorn so I?d like to see it used to confirm it does help. > > Is it possible to detect type discrepancy in m3() and ignore (by special marking) all non-matching speculative types in m3()? > > You already do prefer speculative type from call's parameters over type collected for input arguments. Right? May be use that as indication that types in inlined method could be wrong. That doesn?t sound very robust to me. If profile is inaccurate in the callee, most likely we haven?t run the caller long enough to have profiling, right? Another thing that could be done is record the type that causes the deoptimization in the speculative trap. Then, presumably if we hit a trap everything runs interpreted again, profile is updated and when we recompile and we see that a trap was hit, we can compare the new type with the type that caused the deoptimization and if they differ, try optimizing again. That?s more space required in the method data. I found this problem when running nashorn but I don?t seem to able to hit it again for some reason. So I could withdraw this change for now. I?m concerned it will show up again sooner or later anyway and time will be needed to figure out what is happening. Roland. > > Thanks, > Vladimir > >> >> Roland. >> >> >>> >>> If you have merging case: >>> >>> if (x) >>> m1() >>> else >>> m2() >>> >>> I don't understand why at merge point information from m2 will be more precise then from m3() called from m1(). >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> - Kris >>>> >>>> >>>> On Wed, Jan 22, 2014 at 7:51 PM, Vladimir Kozlov >>>> > wrote: >>>> >>>> Roland, >>>> >>>> I don't see how inlining depth can define type's accuracy in general >>>> case. why it can't be reverse: more accurate type from most deeply >>>> inlined method? >>>> >>>> I thought you only have speculative type if it is the only one type >>>> record in MDO. How in your case you can have different types? >>>> >>>> Can you be more specific? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 1/22/14 1:42 AM, Roland Westrelin wrote: >>>> >>>> When a node already has a speculative type, and parsing >>>> encounters extra profiling data, the new profiling data is >>>> ignored. So profiling data coming from profile points closer to >>>> the root of the compilation is favored which I think makes >>>> sense: it's the data that is most specific to the context of >>>> this compilation. >>>> >>>> During runs, profile data is not always entirely coherent so we >>>> may hit something like this: >>>> m1() { >>>> m3(); >>>> } >>>> >>>> m() { >>>> m1(); >>>> m2(); >>>> } >>>> >>>> With: m3() and m2() have profile data for the same node. The >>>> first profile data to be encountered during parsing is from m3() >>>> and profile data from m2() is ignored but profile data from m2() >>>> is the one that is actually the most specific and is the one >>>> that should be favored. >>>> >>>> When a speculative type is created, this change records the >>>> inline depth at which the profile point is. The inline depth is >>>> then propagated together with the rest of the type information. >>>> When new profile data is available for a node that already has a >>>> speculative type, the current inline depth and the inline depth >>>> of the current speculative type are used to decide whether the >>>> new data should be used to replace the existing speculative type. >>>> >>>> This change helps stabilize performance with nashorn. >>>> >>>> http://cr.openjdk.java.net/~__roland/8031754/webrev.00/ >>>> >>>> >>>> Roland. From roland.westrelin at oracle.com Mon Jan 27 10:15:21 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 27 Jan 2014 19:15:21 +0100 Subject: RFR(XXS): 8032633: Enable type speculation by default Message-ID: <91AD9A95-1C77-432D-813D-A5E4BE3F6AE7@oracle.com> Enable type speculation by default for 9. Will later backport it to 8u20. http://cr.openjdk.java.net/~roland/8032633/webrev.00/ Roland. From vladimir.kozlov at oracle.com Mon Jan 27 10:25:02 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jan 2014 10:25:02 -0800 Subject: RFR(XXS): 8032633: Enable type speculation by default In-Reply-To: <91AD9A95-1C77-432D-813D-A5E4BE3F6AE7@oracle.com> References: <91AD9A95-1C77-432D-813D-A5E4BE3F6AE7@oracle.com> Message-ID: <52E6A47E.7050205@oracle.com> Looks good. Vladimir On 1/27/14 10:15 AM, Roland Westrelin wrote: > Enable type speculation by default for 9. Will later backport it to 8u20. > > http://cr.openjdk.java.net/~roland/8032633/webrev.00/ > > Roland. > From roland.westrelin at oracle.com Mon Jan 27 10:33:17 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 27 Jan 2014 19:33:17 +0100 Subject: RFR(XXS): 8032633: Enable type speculation by default In-Reply-To: <52E6A47E.7050205@oracle.com> References: <91AD9A95-1C77-432D-813D-A5E4BE3F6AE7@oracle.com> <52E6A47E.7050205@oracle.com> Message-ID: Thanks, Vladimir. Roland. On Jan 27, 2014, at 7:25 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 1/27/14 10:15 AM, Roland Westrelin wrote: >> Enable type speculation by default for 9. Will later backport it to 8u20. >> >> http://cr.openjdk.java.net/~roland/8032633/webrev.00/ >> >> Roland. >> From vladimir.kozlov at oracle.com Mon Jan 27 14:03:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jan 2014 14:03:10 -0800 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method In-Reply-To: <3FE1C7FB-C7E3-4032-9A40-946061F7A97D@oracle.com> References: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> <52E091D0.3010508@oracle.com> <52E09526.7030907@oracle.com> <865C3299-3E60-40D4-84AA-8EEA27ADAF99@oracle.com> <52E3191A.60604@oracle.com> <3FE1C7FB-C7E3-4032-9A40-946061F7A97D@oracle.com> Message-ID: <52E6D79E.2010505@oracle.com> Yes, intuitively it looks correct but I am still not sure that we should do that. How big affect this has on score? I don't see any data. Can you write microbenchmark to show such behavior and benefits from these changes? Thanks, Vladimir On 1/27/14 9:58 AM, Roland Westrelin wrote: > Hi Vladimir, > >>> Thanks for looking at this, Vladimir. >>> >>>>> My wild guess is that the outermost method generally gives you the best >>>>> (cleanest) context information. The inner callees may have been called >>>>> from various callers, and so their type profiles may have been polluted >>>>> by other callers. >>>> >>>> They can't be polluted. We record only one speculative type. If Interpreter see a different type it will set flags and that type information will not be used. At least that is how I understand it works. That is why I am asking Roland to clarify this. >>> >>> That?s the way they work. What can happen for this (and what happens sometimes I believe): >>> >>> m1() { >>> m3(); >>> } >>> >>> m() { >>> m1(); >>> m2(); >>> } >>> >>> is that m3() is a heavily used method called from some other place early during the application run. Some profile is recorded. The method becomes so hot that it gets compiled with c2. So we stop profiling. Then m3() is called from m1() but because it?s already compiled we don?t record the conflicting profile. When m() is compiled we are stuck with an incorrect profile and we may miss some optimization opportunities. >> >> Okay, it makes sense. So m3() has totally unrelated to current compilation type information. But you should have some uncommon traps which will force deoptimization of m3() if type is wrong when you run m1(). On other hand deoptimization may not happen fast enough before we compile m(). I agree we can have such case. >> >> What about case when m3() calls m4() only when m3() is called from m()->m1()? In such situation m4() will collect correct type for m() compilation(). But it will be overwritten by bad type from m3(). > > But in this case, for m4() to have profile, the branch that calls m4() must have been run and the profile there should be consistent with the profile in m3()? > >>> >>> As Krys said, intuitively "the outermost method generally gives you the best (cleanest) context information?. It?s only a heuristic and as such, it?s certainly easy to build a test case for which this heuristic doesn?t do a good job. It does help for experiments I made with nashorn so I?d like to see it used to confirm it does help. >> >> Is it possible to detect type discrepancy in m3() and ignore (by special marking) all non-matching speculative types in m3()? >> >> You already do prefer speculative type from call's parameters over type collected for input arguments. Right? May be use that as indication that types in inlined method could be wrong. > > That doesn?t sound very robust to me. If profile is inaccurate in the callee, most likely we haven?t run the caller long enough to have profiling, right? > > Another thing that could be done is record the type that causes the deoptimization in the speculative trap. Then, presumably if we hit a trap everything runs interpreted again, profile is updated and when we recompile and we see that a trap was hit, we can compare the new type with the type that caused the deoptimization and if they differ, try optimizing again. That?s more space required in the method data. > > I found this problem when running nashorn but I don?t seem to able to hit it again for some reason. So I could withdraw this change for now. I?m concerned it will show up again sooner or later anyway and time will be needed to figure out what is happening. > > Roland. > >> >> Thanks, >> Vladimir >> >>> >>> Roland. >>> >>> >>>> >>>> If you have merging case: >>>> >>>> if (x) >>>> m1() >>>> else >>>> m2() >>>> >>>> I don't understand why at merge point information from m2 will be more precise then from m3() called from m1(). >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> - Kris >>>>> >>>>> >>>>> On Wed, Jan 22, 2014 at 7:51 PM, Vladimir Kozlov >>>>> > wrote: >>>>> >>>>> Roland, >>>>> >>>>> I don't see how inlining depth can define type's accuracy in general >>>>> case. why it can't be reverse: more accurate type from most deeply >>>>> inlined method? >>>>> >>>>> I thought you only have speculative type if it is the only one type >>>>> record in MDO. How in your case you can have different types? >>>>> >>>>> Can you be more specific? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 1/22/14 1:42 AM, Roland Westrelin wrote: >>>>> >>>>> When a node already has a speculative type, and parsing >>>>> encounters extra profiling data, the new profiling data is >>>>> ignored. So profiling data coming from profile points closer to >>>>> the root of the compilation is favored which I think makes >>>>> sense: it's the data that is most specific to the context of >>>>> this compilation. >>>>> >>>>> During runs, profile data is not always entirely coherent so we >>>>> may hit something like this: >>>>> m1() { >>>>> m3(); >>>>> } >>>>> >>>>> m() { >>>>> m1(); >>>>> m2(); >>>>> } >>>>> >>>>> With: m3() and m2() have profile data for the same node. The >>>>> first profile data to be encountered during parsing is from m3() >>>>> and profile data from m2() is ignored but profile data from m2() >>>>> is the one that is actually the most specific and is the one >>>>> that should be favored. >>>>> >>>>> When a speculative type is created, this change records the >>>>> inline depth at which the profile point is. The inline depth is >>>>> then propagated together with the rest of the type information. >>>>> When new profile data is available for a node that already has a >>>>> speculative type, the current inline depth and the inline depth >>>>> of the current speculative type are used to decide whether the >>>>> new data should be used to replace the existing speculative type. >>>>> >>>>> This change helps stabilize performance with nashorn. >>>>> >>>>> http://cr.openjdk.java.net/~__roland/8031754/webrev.00/ >>>>> >>>>> >>>>> Roland. > From albert.noll at oracle.com Mon Jan 27 21:40:53 2014 From: albert.noll at oracle.com (Albert) Date: Tue, 28 Jan 2014 06:40:53 +0100 Subject: [9] RFR(XS): 8032642: Fix testbugs in compiler/startup/.* In-Reply-To: <27FA3232-AAFA-4850-9227-6436DFD0F246@oracle.com> References: <52E61590.7010804@oracle.com> <27FA3232-AAFA-4850-9227-6436DFD0F246@oracle.com> Message-ID: <52E742E5.8050500@oracle.com> Hi Christian, thanks for looking at this patch. The test wants to create a situation in which there is not enough free space in the code cache to allocate the C1 buffer bob (CompilerThread::get_buffer_blob()). The buffer blob is allocated once per C1 compiler thread when the thread is initialized. Unfortunately, I do not know an alternative to trigger this state. I know, the test is not particularly portable and might need to be maintained over time.. Best, Albert On 01/27/2014 06:11 PM, Christian Thalinger wrote: > The changes look good but I have a question. Is there potentially > another way to test this without using: > *-XX:ReservedCodeCacheSize=3m -XX:CICompilerCount=64* > ? > > On Jan 27, 2014, at 12:15 AM, Albert > wrote: > >> Hi, >> >> could I get reviews for these small changes? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8032642 >> webrev: http://cr.openjdk.java.net/~anoll/8032642/webrev.00/ >> >> >> Problems: >> (1) compiler/startup/SmallCodeCacheStartup.java should use "@run >> main/othervm" >> (2) compiler/startup/StartupOutput.java should use correct @library path >> >> Many thanks in advance, >> Albert > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140128/adba7b68/attachment.html From niclas.adlertz at oracle.com Tue Jan 28 02:07:44 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Tue, 28 Jan 2014 11:07:44 +0100 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information Message-ID: <52E78170.3090507@oracle.com> Hi all, When debugging or visualizing spills/splits/moves in C2 it's hard to know what caused an insertion of a certain MachSpillCopy. I've made this easier by creating subclasses of the MachSpillCopyNode. webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ bug: https://bugs.openjdk.java.net/browse/JDK-8032656 Kind Regards, Niclas Adlertz From vladimir.x.ivanov at oracle.com Tue Jan 28 02:50:53 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Jan 2014 14:50:53 +0400 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E78170.3090507@oracle.com> References: <52E78170.3090507@oracle.com> Message-ID: <52E78B8D.5030207@oracle.com> Niclas, Why didn't you introduce an enum instead and pass the reason to constructor? Introducing 13 subclasses just to overload Name() method in debug builds looks like an overkill to me. Best regards, Vladimir Ivanov On 1/28/14 2:07 PM, Niclas Adlertz wrote: > Hi all, > > When debugging or visualizing spills/splits/moves in C2 it's hard to > know what caused an insertion of a certain MachSpillCopy. I've made this > easier by creating subclasses of the MachSpillCopyNode. > > webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8032656 > > Kind Regards, > Niclas Adlertz From niclas.adlertz at oracle.com Tue Jan 28 03:18:03 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Tue, 28 Jan 2014 12:18:03 +0100 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E78B8D.5030207@oracle.com> References: <52E78170.3090507@oracle.com> <52E78B8D.5030207@oracle.com> Message-ID: <52E791EB.2020806@oracle.com> Hi Vladimir, Thank you for your response. That is a possibility as well. By using an enum I still have the problem of deciding what to return in Name(). I could have either * an array of const char* with the names and index into it by using the enum when returning a name * a switch-case on the enums in the Name() method. However, I think sub-classing the MachSpillCopyNode looks cleaner. The sub-classing approach could also be of use in a product build when debugging a crash and we want to check what type of node we are at. If it's ok with you, I'll wait and see what the others think. If more people think the enum approach is better I can use enums instead. Kind Regards, Niclas Adlertz On 2014-01-28 11:50, Vladimir Ivanov wrote: > Niclas, > > Why didn't you introduce an enum instead and pass the reason to > constructor? Introducing 13 subclasses just to overload Name() method > in debug builds looks like an overkill to me. > > Best regards, > Vladimir Ivanov > > On 1/28/14 2:07 PM, Niclas Adlertz wrote: >> Hi all, >> >> When debugging or visualizing spills/splits/moves in C2 it's hard to >> know what caused an insertion of a certain MachSpillCopy. I've made this >> easier by creating subclasses of the MachSpillCopyNode. >> >> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8032656 >> >> Kind Regards, >> Niclas Adlertz From nils.eliasson at oracle.com Tue Jan 28 07:02:09 2014 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 28 Jan 2014 16:02:09 +0100 Subject: RFR(S) 8007270: Make IsMethodCompilable test work with tiered Message-ID: <52E7C671.4030705@oracle.com> Hi all, I need a review for this change. http://cr.openjdk.java.net/~neliasso/8007270/webrev.01/ This test was disabled since it didn't work very well with tiered (or client). It tests the PerMethodRecompilationCutoff that was introduced to disable c2-compilations of a method when it has been deoptimized too many times. The bug report suggested we should disable c1 compilations as well but I don't think that was the intent of the cutoff feature. I have changed the following in the test * skip test when running client only (not supported by jtreg at the moment) * check what compilation level was used when compiling so that it can keep track of the number of c2 compiles (and deopts) correctly in tiered mode * compile and deopt up to the cutoff limit only once * added PerMethodRecompilationCutoff=4 flag to commandline to reduce wasted time in test (default 400) Now the test works and the running time has been reduced to seconds instead of minutes. Kind regards, Nils Eliasson From vladimir.kozlov at oracle.com Tue Jan 28 09:14:09 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jan 2014 09:14:09 -0800 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E78B8D.5030207@oracle.com> References: <52E78170.3090507@oracle.com> <52E78B8D.5030207@oracle.com> Message-ID: <52E7E561.7020906@oracle.com> +1 I also feel uncomfortable with this approach. Thanks, Vladimir K On 1/28/14 2:50 AM, Vladimir Ivanov wrote: > Niclas, > > Why didn't you introduce an enum instead and pass the reason to constructor? Introducing 13 subclasses just to overload > Name() method in debug builds looks like an overkill to me. > > Best regards, > Vladimir Ivanov > > On 1/28/14 2:07 PM, Niclas Adlertz wrote: >> Hi all, >> >> When debugging or visualizing spills/splits/moves in C2 it's hard to >> know what caused an insertion of a certain MachSpillCopy. I've made this >> easier by creating subclasses of the MachSpillCopyNode. >> >> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8032656 >> >> Kind Regards, >> Niclas Adlertz From vladimir.kozlov at oracle.com Tue Jan 28 09:21:32 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jan 2014 09:21:32 -0800 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E791EB.2020806@oracle.com> References: <52E78170.3090507@oracle.com> <52E78B8D.5030207@oracle.com> <52E791EB.2020806@oracle.com> Message-ID: <52E7E71C.7090404@oracle.com> On 1/28/14 3:18 AM, Niclas Adlertz wrote: > Hi Vladimir, > > Thank you for your response. > That is a possibility as well. > > By using an enum I still have the problem of deciding what to return in Name(). > I could have either > * an array of const char* with the names and index into it by using the enum when returning a name > * a switch-case on the enums in the Name() method. Switch by enum in Name(). > > However, I think sub-classing the MachSpillCopyNode looks cleaner. > The sub-classing approach could also be of use in a product build when debugging a crash and we want to check what type > of node we are at. You can determine type by enum value too. Thanks, Vladimir > > If it's ok with you, I'll wait and see what the others think. If more people think the enum approach is better I can use > enums instead. > > Kind Regards, > Niclas Adlertz > > On 2014-01-28 11:50, Vladimir Ivanov wrote: >> Niclas, >> >> Why didn't you introduce an enum instead and pass the reason to constructor? Introducing 13 subclasses just to >> overload Name() method in debug builds looks like an overkill to me. >> >> Best regards, >> Vladimir Ivanov >> >> On 1/28/14 2:07 PM, Niclas Adlertz wrote: >>> Hi all, >>> >>> When debugging or visualizing spills/splits/moves in C2 it's hard to >>> know what caused an insertion of a certain MachSpillCopy. I've made this >>> easier by creating subclasses of the MachSpillCopyNode. >>> >>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8032656 >>> >>> Kind Regards, >>> Niclas Adlertz > From vladimir.kozlov at oracle.com Tue Jan 28 20:22:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jan 2014 20:22:11 -0800 Subject: RFR(S) 8007270: Make IsMethodCompilable test work with tiered In-Reply-To: <52E7C671.4030705@oracle.com> References: <52E7C671.4030705@oracle.com> Message-ID: <52E881F3.7050602@oracle.com> Hi Nils, Why only on first iteration and not always increment when C2 is not used? : + if (level < COMP_LEVEL_FULL_OPTIMIZATION) { + if (i == 0) { + // Add one if a lower tier is compiled on first iteration + cutoff++; + } thanks, Vladimir On 1/28/14 7:02 AM, Nils Eliasson wrote: > Hi all, > > I need a review for this change. > > http://cr.openjdk.java.net/~neliasso/8007270/webrev.01/ > > This test was disabled since it didn't work very well with tiered (or > client). It tests the PerMethodRecompilationCutoff that was introduced > to disable c2-compilations of a method when it has been deoptimized too > many times. The bug report suggested we should disable c1 compilations > as well but I don't think that was the intent of the cutoff feature. > > I have changed the following in the test > * skip test when running client only (not supported by jtreg at the moment) > * check what compilation level was used when compiling so that it can > keep track of the number of c2 compiles (and deopts) correctly in tiered > mode > * compile and deopt up to the cutoff limit only once > * added PerMethodRecompilationCutoff=4 flag to commandline to reduce > wasted time in test (default 400) > > Now the test works and the running time has been reduced to seconds > instead of minutes. > > Kind regards, > Nils Eliasson > > From nils.eliasson at oracle.com Wed Jan 29 00:29:44 2014 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 29 Jan 2014 09:29:44 +0100 Subject: RFR(S) 8007270: Make IsMethodCompilable test work with tiered In-Reply-To: <52E881F3.7050602@oracle.com> References: <52E7C671.4030705@oracle.com> <52E881F3.7050602@oracle.com> Message-ID: <52E8BBF8.5030509@oracle.com> Only to guard that it is the low-tier ramp up and nothing else that is compensated for. If some other compiler, policy or compilation level is introduced the test will have to be fixed, and this way it will be found right away. Thanks, //N On 2014-01-29 05:22, Vladimir Kozlov wrote: > Hi Nils, > > Why only on first iteration and not always increment when C2 is not > used? : > > + if (level < COMP_LEVEL_FULL_OPTIMIZATION) { > + if (i == 0) { > + // Add one if a lower tier is compiled on first iteration > + cutoff++; > + } > > thanks, > Vladimir > > On 1/28/14 7:02 AM, Nils Eliasson wrote: >> Hi all, >> >> I need a review for this change. >> >> http://cr.openjdk.java.net/~neliasso/8007270/webrev.01/ >> >> This test was disabled since it didn't work very well with tiered (or >> client). It tests the PerMethodRecompilationCutoff that was introduced >> to disable c2-compilations of a method when it has been deoptimized too >> many times. The bug report suggested we should disable c1 compilations >> as well but I don't think that was the intent of the cutoff feature. >> >> I have changed the following in the test >> * skip test when running client only (not supported by jtreg at the >> moment) >> * check what compilation level was used when compiling so that it can >> keep track of the number of c2 compiles (and deopts) correctly in tiered >> mode >> * compile and deopt up to the cutoff limit only once >> * added PerMethodRecompilationCutoff=4 flag to commandline to reduce >> wasted time in test (default 400) >> >> Now the test works and the running time has been reduced to seconds >> instead of minutes. >> >> Kind regards, >> Nils Eliasson >> >> From igor.ignatyev at oracle.com Wed Jan 29 02:11:18 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 29 Jan 2014 14:11:18 +0400 Subject: RFR(S) 8007270: Make IsMethodCompilable test work with tiered In-Reply-To: <52E7C671.4030705@oracle.com> References: <52E7C671.4030705@oracle.com> Message-ID: <52E8D3C6.6090704@oracle.com> Hi Nils, you can skip running on client by yourself, see attached diff. Igor On 01/28/2014 07:02 PM, Nils Eliasson wrote: > Hi all, > > I need a review for this change. > > http://cr.openjdk.java.net/~neliasso/8007270/webrev.01/ > > This test was disabled since it didn't work very well with tiered (or > client). It tests the PerMethodRecompilationCutoff that was introduced > to disable c2-compilations of a method when it has been deoptimized too > many times. The bug report suggested we should disable c1 compilations > as well but I don't think that was the intent of the cutoff feature. > > I have changed the following in the test > * skip test when running client only (not supported by jtreg at the moment) > * check what compilation level was used when compiling so that it can > keep track of the number of c2 compiles (and deopts) correctly in tiered > mode > * compile and deopt up to the cutoff limit only once > * added PerMethodRecompilationCutoff=4 flag to commandline to reduce > wasted time in test (default 400) > > Now the test works and the running time has been reduced to seconds > instead of minutes. > > Kind regards, > Nils Eliasson > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8007270.diff Type: text/x-patch Size: 1867 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140129/c26de762/8007270.diff From niclas.adlertz at oracle.com Wed Jan 29 03:14:39 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 29 Jan 2014 12:14:39 +0100 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E7E71C.7090404@oracle.com> References: <52E78170.3090507@oracle.com> <52E78B8D.5030207@oracle.com> <52E791EB.2020806@oracle.com> <52E7E71C.7090404@oracle.com> Message-ID: <52E8E29F.1010908@oracle.com> Hi Vladimir K, Thank you for your response. Here is an updated webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev01/ Kind Regards, Niclas Adlertz On 2014-01-28 18:21, Vladimir Kozlov wrote: > On 1/28/14 3:18 AM, Niclas Adlertz wrote: >> Hi Vladimir, >> >> Thank you for your response. >> That is a possibility as well. >> >> By using an enum I still have the problem of deciding what to return >> in Name(). >> I could have either >> * an array of const char* with the names and index into it by using >> the enum when returning a name >> * a switch-case on the enums in the Name() method. > > Switch by enum in Name(). > >> >> However, I think sub-classing the MachSpillCopyNode looks cleaner. >> The sub-classing approach could also be of use in a product build >> when debugging a crash and we want to check what type >> of node we are at. > > You can determine type by enum value too. > > Thanks, > Vladimir > >> >> If it's ok with you, I'll wait and see what the others think. If more >> people think the enum approach is better I can use >> enums instead. >> >> Kind Regards, >> Niclas Adlertz >> >> On 2014-01-28 11:50, Vladimir Ivanov wrote: >>> Niclas, >>> >>> Why didn't you introduce an enum instead and pass the reason to >>> constructor? Introducing 13 subclasses just to >>> overload Name() method in debug builds looks like an overkill to me. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 1/28/14 2:07 PM, Niclas Adlertz wrote: >>>> Hi all, >>>> >>>> When debugging or visualizing spills/splits/moves in C2 it's hard to >>>> know what caused an insertion of a certain MachSpillCopy. I've made >>>> this >>>> easier by creating subclasses of the MachSpillCopyNode. >>>> >>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032656 >>>> >>>> Kind Regards, >>>> Niclas Adlertz >> From goetz.lindenmaier at sap.com Wed Jan 29 03:50:13 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 29 Jan 2014 11:50:13 +0000 Subject: RFR (XS): 8033117: PPC64: Adapt to 8002074: Support for AES on SPARC Message-ID: <4295855A5C1DE049A61835A1887419CC2CE90B71@DEWDFEMB12A.global.corp.sap> Hi, The ppc port must implement Matcher::pass_original_key_for_aes() introduced to jdk9 after the last merge to the staging repo. Please review http://cr.openjdk.java.net/~goetz/webrevs/8033117-1-aes/ for jdk9/hs-comp and also for downport to ppc-aix-port/stage which will be integrated to jdk8u at some point. The change affects only ppc64 files. Thanks and best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140129/75d8e394/attachment.html From niclas.adlertz at oracle.com Wed Jan 29 04:09:38 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 29 Jan 2014 13:09:38 +0100 Subject: RFR(XS) 8032894: Remove dead code in Pressure::lower Message-ID: <52E8EF82.2000908@oracle.com> Hi all, When building the physical IFG, we step backwards in each block, and remove things that are defined from the LIVE_OUT, (and lower the current pressure) and add input to the LIVE_OUT (and raising the current pressure). Each time we lower or raise the current pressure, we check if it's bigger than the current maximum pressure, known as final_pressure. However the final_pressure can never increase when removing definitions (i.e. lower the current pressure) so the check for a new final_pressure in Pressure::lower is useless. webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032894/webrev00/ bug: https://bugs.openjdk.java.net/browse/JDK-8032894 Kind Regards, Niclas Adlertz From vladimir.kozlov at oracle.com Wed Jan 29 08:45:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jan 2014 08:45:20 -0800 Subject: RFR (XS): 8033117: PPC64: Adapt to 8002074: Support for AES on SPARC In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE90B71@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE90B71@DEWDFEMB12A.global.corp.sap> Message-ID: <52E93020.6050705@oracle.com> Thanks, Goetz Changes are good. I will push it today. 8002074 is not in 8u20 yet so no need backport for now. Thanks, Vladimir On 1/29/14 3:50 AM, Lindenmaier, Goetz wrote: > Hi, > > The ppc port must implement Matcher::pass_original_key_for_aes() introduced to > jdk9 after the last merge to the staging repo. > > Please review > http://cr.openjdk.java.net/~goetz/webrevs/8033117-1-aes/ > for jdk9/hs-comp and also for downport to ppc-aix-port/stage which will > be integrated to jdk8u at some point. > > The change affects only ppc64 files. > > Thanks and best regards, > Goetz. > From christian.thalinger at oracle.com Wed Jan 29 10:46:29 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 29 Jan 2014 10:46:29 -0800 Subject: [9] RFR(XS): 8032642: Fix testbugs in compiler/startup/.* In-Reply-To: <52E742E5.8050500@oracle.com> References: <52E61590.7010804@oracle.com> <27FA3232-AAFA-4850-9227-6436DFD0F246@oracle.com> <52E742E5.8050500@oracle.com> Message-ID: Yeah, that?s what I figured. I thought I ask anyway :-) On Jan 27, 2014, at 9:40 PM, Albert wrote: > Hi Christian, > > thanks for looking at this patch. > > The test wants to create a situation in which there is not enough free space > in the code cache to allocate the C1 buffer bob (CompilerThread::get_buffer_blob()). > The buffer blob is allocated once per C1 compiler thread when the thread is > initialized. > > Unfortunately, I do not know an alternative to trigger this state. I know, the test > is not particularly portable and might need to be maintained over time.. > > Best, > Albert > > > On 01/27/2014 06:11 PM, Christian Thalinger wrote: >> The changes look good but I have a question. Is there potentially another way to test this without using: >> -XX:ReservedCodeCacheSize=3m -XX:CICompilerCount=64 >> ? >> >> On Jan 27, 2014, at 12:15 AM, Albert wrote: >> >>> Hi, >>> >>> could I get reviews for these small changes? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8032642 >>> webrev: http://cr.openjdk.java.net/~anoll/8032642/webrev.00/ >>> >>> Problems: >>> (1) compiler/startup/SmallCodeCacheStartup.java should use "@run main/othervm" >>> (2) compiler/startup/StartupOutput.java should use correct @library path >>> >>> Many thanks in advance, >>> Albert >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140129/a994dfd6/attachment.html From vladimir.kozlov at oracle.com Wed Jan 29 10:46:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jan 2014 10:46:58 -0800 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E8E29F.1010908@oracle.com> References: <52E78170.3090507@oracle.com> <52E78B8D.5030207@oracle.com> <52E791EB.2020806@oracle.com> <52E7E71C.7090404@oracle.com> <52E8E29F.1010908@oracle.com> Message-ID: <52E94CA2.7080904@oracle.com> Niclas, Changes are fine but names should be adjusted. I think we should use original "SpillCopy" suffix instead of "SpillNode". "RegToMem" and "MemToReg" are missing the suffux. Thanks, Vladimir On 1/29/14 3:14 AM, Niclas Adlertz wrote: > Hi Vladimir K, > > Thank you for your response. > > Here is an updated webrev: > http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev01/ > > Kind Regards, > Niclas Adlertz > > > On 2014-01-28 18:21, Vladimir Kozlov wrote: >> On 1/28/14 3:18 AM, Niclas Adlertz wrote: >>> Hi Vladimir, >>> >>> Thank you for your response. >>> That is a possibility as well. >>> >>> By using an enum I still have the problem of deciding what to return >>> in Name(). >>> I could have either >>> * an array of const char* with the names and index into it by using >>> the enum when returning a name >>> * a switch-case on the enums in the Name() method. >> >> Switch by enum in Name(). >> >>> >>> However, I think sub-classing the MachSpillCopyNode looks cleaner. >>> The sub-classing approach could also be of use in a product build >>> when debugging a crash and we want to check what type >>> of node we are at. >> >> You can determine type by enum value too. >> >> Thanks, >> Vladimir >> >>> >>> If it's ok with you, I'll wait and see what the others think. If more >>> people think the enum approach is better I can use >>> enums instead. >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> On 2014-01-28 11:50, Vladimir Ivanov wrote: >>>> Niclas, >>>> >>>> Why didn't you introduce an enum instead and pass the reason to >>>> constructor? Introducing 13 subclasses just to >>>> overload Name() method in debug builds looks like an overkill to me. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 1/28/14 2:07 PM, Niclas Adlertz wrote: >>>>> Hi all, >>>>> >>>>> When debugging or visualizing spills/splits/moves in C2 it's hard to >>>>> know what caused an insertion of a certain MachSpillCopy. I've made >>>>> this >>>>> easier by creating subclasses of the MachSpillCopyNode. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032656 >>>>> >>>>> Kind Regards, >>>>> Niclas Adlertz >>> > From vladimir.kozlov at oracle.com Wed Jan 29 10:53:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jan 2014 10:53:24 -0800 Subject: RFR(XS) 8032894: Remove dead code in Pressure::lower In-Reply-To: <52E8EF82.2000908@oracle.com> References: <52E8EF82.2000908@oracle.com> Message-ID: <52E94E24.8090605@oracle.com> What is initial state of _current_pressure, _high_pressure_limit, _final_pressure? How we can get case (_current_pressure == _high_pressure_limit)? May be we should replace the code with assert: assert(_current_pressure <= _final_pressure Thanks, Vladimir On 1/29/14 4:09 AM, Niclas Adlertz wrote: > Hi all, > > When building the physical IFG, we step backwards in each block, and > remove things that are defined from the LIVE_OUT, (and lower the current > pressure) and add input to the LIVE_OUT (and raising the current > pressure). Each time we lower or raise the current pressure, we check if > it's bigger than the current maximum pressure, known as final_pressure. > However the final_pressure can never increase when removing definitions > (i.e. lower the current pressure) so the check for a new final_pressure > in Pressure::lower is useless. > > webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032894/webrev00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8032894 > > Kind Regards, > Niclas Adlertz From niclas.adlertz at oracle.com Wed Jan 29 14:02:25 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 29 Jan 2014 23:02:25 +0100 Subject: RFR(XS) 8032894: Remove dead code in Pressure::lower In-Reply-To: <52E94E24.8090605@oracle.com> References: <52E8EF82.2000908@oracle.com> <52E94E24.8090605@oracle.com> Message-ID: <52E97A71.5040306@oracle.com> Hi Vladimir, The initial states of _current_pressure and _final_pressure are computed in PhaseChaitin::compute_initial_block_pressure(). We loop through all live ranges that are in the LIVE_OUT of the block, and raise the _current_pressure (for either int or float) for each live range. If the _current_pressure is bigger than the _final_pressure (which is initially 0), we set the _final_pressure to be _current_pressure. We check this each time we increase the _current_pressure. This is done in Pressure::raise(). (I.e. the _final_pressure is the highest value of _current_pressure that we ever encounter in the block) The _high_pressure_limit is passed into the constructor of the Pressure class. This is done in the beginning of the build_ifg_physical(): Pressure int_pressure(last_inst + 1, INTPRESSURE); Pressure float_pressure(last_inst + 1, FLOATPRESSURE); > How we can get case (_current_pressure == _high_pressure_limit)? When we lower the pressure, it is assumed that we lower each time by 1 (this happens every time we remove a definition from the LIVE_OUT when stepping backwards in the block). So if _current_pressure is greater than _high_pressure_limit, and we lower the _current_pressure, we might hit the case when _current_pressure == _high_pressure_limit. If so, we have found a Low to High pressure transition in the block. (Low to High when starting from the top of the block) However, there is one problem with this case, since the pressure could be lowered by more than 1. (Long or Double will lower it by 2). So we might miss a transition when lowering. There is already a bug (JDK-8032886) filed for this which will be out soon. I didn't fix this bug in the clean up since I wanted them to be separate commits. Kind Regards, Niclas Adlertz On 2014-01-29 19:53, Vladimir Kozlov wrote: > What is initial state of _current_pressure, _high_pressure_limit, _final_pressure? How we can get case (_current_pressure == _high_pressure_limit)? May be we should replace the code with assert: > > assert(_current_pressure <= _final_pressure > > Thanks, > Vladimir > > On 1/29/14 4:09 AM, Niclas Adlertz wrote: >> Hi all, >> >> When building the physical IFG, we step backwards in each block, and >> remove things that are defined from the LIVE_OUT, (and lower the current >> pressure) and add input to the LIVE_OUT (and raising the current >> pressure). Each time we lower or raise the current pressure, we check if >> it's bigger than the current maximum pressure, known as final_pressure. >> However the final_pressure can never increase when removing definitions >> (i.e. lower the current pressure) so the check for a new final_pressure >> in Pressure::lower is useless. >> >> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032894/webrev00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8032894 >> >> Kind Regards, >> Niclas Adlertz From niclas.adlertz at oracle.com Wed Jan 29 14:27:27 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 29 Jan 2014 23:27:27 +0100 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E94CA2.7080904@oracle.com> References: <52E78170.3090507@oracle.com> <52E78B8D.5030207@oracle.com> <52E791EB.2020806@oracle.com> <52E7E71C.7090404@oracle.com> <52E8E29F.1010908@oracle.com> <52E94CA2.7080904@oracle.com> Message-ID: <52E9804F.90203@oracle.com> Hi Vladimir, Thank you. Here is the new webrev:http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev02/ I also included machnode.hpp in chaitin.hpp since we need the definition of MachSpillCopyNode::SpillType. (Build failed on Solaris otherwise). Kind Regards, Niclas Adlertz On 2014-01-29 19:46, Vladimir Kozlov wrote: > Niclas, > > Changes are fine but names should be adjusted. I think we should use original "SpillCopy" suffix instead of "SpillNode". "RegToMem" and "MemToReg" are missing the suffux. > > Thanks, > Vladimir > > On 1/29/14 3:14 AM, Niclas Adlertz wrote: >> Hi Vladimir K, >> >> Thank you for your response. >> >> Here is an updated webrev: >> http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev01/ >> >> Kind Regards, >> Niclas Adlertz >> >> >> On 2014-01-28 18:21, Vladimir Kozlov wrote: >>> On 1/28/14 3:18 AM, Niclas Adlertz wrote: >>>> Hi Vladimir, >>>> >>>> Thank you for your response. >>>> That is a possibility as well. >>>> >>>> By using an enum I still have the problem of deciding what to return >>>> in Name(). >>>> I could have either >>>> * an array of const char* with the names and index into it by using >>>> the enum when returning a name >>>> * a switch-case on the enums in the Name() method. >>> >>> Switch by enum in Name(). >>> >>>> >>>> However, I think sub-classing the MachSpillCopyNode looks cleaner. >>>> The sub-classing approach could also be of use in a product build >>>> when debugging a crash and we want to check what type >>>> of node we are at. >>> >>> You can determine type by enum value too. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> If it's ok with you, I'll wait and see what the others think. If more >>>> people think the enum approach is better I can use >>>> enums instead. >>>> >>>> Kind Regards, >>>> Niclas Adlertz >>>> >>>> On 2014-01-28 11:50, Vladimir Ivanov wrote: >>>>> Niclas, >>>>> >>>>> Why didn't you introduce an enum instead and pass the reason to >>>>> constructor? Introducing 13 subclasses just to >>>>> overload Name() method in debug builds looks like an overkill to me. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 1/28/14 2:07 PM, Niclas Adlertz wrote: >>>>>> Hi all, >>>>>> >>>>>> When debugging or visualizing spills/splits/moves in C2 it's hard to >>>>>> know what caused an insertion of a certain MachSpillCopy. I've made >>>>>> this >>>>>> easier by creating subclasses of the MachSpillCopyNode. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032656 >>>>>> >>>>>> Kind Regards, >>>>>> Niclas Adlertz >>>> >> From vladimir.kozlov at oracle.com Wed Jan 29 14:31:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jan 2014 14:31:20 -0800 Subject: RFR(XS) 8032894: Remove dead code in Pressure::lower In-Reply-To: <52E97A71.5040306@oracle.com> References: <52E8EF82.2000908@oracle.com> <52E94E24.8090605@oracle.com> <52E97A71.5040306@oracle.com> Message-ID: <52E98138.7000802@oracle.com> Hi Niclas On 1/29/14 2:02 PM, Niclas Adlertz wrote: > Hi Vladimir, > > The initial states of _current_pressure and _final_pressure are computed > in PhaseChaitin::compute_initial_block_pressure(). > We loop through all live ranges that are in the LIVE_OUT of the block, > and raise the _current_pressure (for either int or float) for each live > range. If the _current_pressure is bigger than the _final_pressure > (which is initially 0), we set the _final_pressure to be > _current_pressure. We check this each time we increase the > _current_pressure. This is done in Pressure::raise(). (I.e. the > _final_pressure is the highest value of _current_pressure that we ever > encounter in the block) It is not accurate, it could be higher. You overwrite it in check_for_high_pressure_transition_at_fatproj(). May be all _*_pressure fields should be private and code which updates them is located in one place. Then it would be more obvious that code you are removing is useless. > > The _high_pressure_limit is passed into the constructor of the Pressure > class. This is done in the beginning of the build_ifg_physical(): > > Pressure int_pressure(last_inst + 1, INTPRESSURE); > Pressure float_pressure(last_inst + 1, FLOATPRESSURE); > >> How we can get case (_current_pressure == _high_pressure_limit)? > When we lower the pressure, it is assumed that we lower each time by 1 > (this happens every time we remove a definition from the LIVE_OUT when > stepping backwards in the block). So if _current_pressure is greater > than _high_pressure_limit, and we lower the _current_pressure, we might > hit the case when _current_pressure == _high_pressure_limit. If so, we > have found a Low to High pressure transition in the block. (Low to High > when starting from the top of the block) > However, there is one problem with this case, since the pressure could > be lowered by more than 1. (Long or Double will lower it by 2). So we > might miss a transition when lowering. There is already a bug > (JDK-8032886) filed for this which will be out soon. I didn't fix this > bug in the clean up since I wanted them to be separate commits. Okay, sounds good. Thanks, Vladimir > > Kind Regards, > Niclas Adlertz > > > On 2014-01-29 19:53, Vladimir Kozlov wrote: >> What is initial state of _current_pressure, _high_pressure_limit, >> _final_pressure? How we can get case (_current_pressure == >> _high_pressure_limit)? May be we should replace the code with assert: >> >> assert(_current_pressure <= _final_pressure >> >> Thanks, >> Vladimir >> >> On 1/29/14 4:09 AM, Niclas Adlertz wrote: >>> Hi all, >>> >>> When building the physical IFG, we step backwards in each block, and >>> remove things that are defined from the LIVE_OUT, (and lower the current >>> pressure) and add input to the LIVE_OUT (and raising the current >>> pressure). Each time we lower or raise the current pressure, we check if >>> it's bigger than the current maximum pressure, known as final_pressure. >>> However the final_pressure can never increase when removing definitions >>> (i.e. lower the current pressure) so the check for a new final_pressure >>> in Pressure::lower is useless. >>> >>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032894/webrev00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8032894 >>> >>> Kind Regards, >>> Niclas Adlertz > From vladimir.kozlov at oracle.com Wed Jan 29 14:34:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jan 2014 14:34:31 -0800 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E9804F.90203@oracle.com> References: <52E78170.3090507@oracle.com> <52E78B8D.5030207@oracle.com> <52E791EB.2020806@oracle.com> <52E7E71C.7090404@oracle.com> <52E8E29F.1010908@oracle.com> <52E94CA2.7080904@oracle.com> <52E9804F.90203@oracle.com> Message-ID: <52E981F7.6010208@oracle.com> Looks fine. NOTE: our repo is closed. Please, hold with the push. Thanks, Vlaidmir On 1/29/14 2:27 PM, Niclas Adlertz wrote: > Hi Vladimir, > > Thank you. > Here is the new > webrev:http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev02/ > I also included machnode.hpp in chaitin.hpp since we need the definition > of MachSpillCopyNode::SpillType. (Build failed on Solaris otherwise). > > Kind Regards, > Niclas Adlertz > > On 2014-01-29 19:46, Vladimir Kozlov wrote: >> Niclas, >> >> Changes are fine but names should be adjusted. I think we should use >> original "SpillCopy" suffix instead of "SpillNode". "RegToMem" and >> "MemToReg" are missing the suffux. >> >> Thanks, >> Vladimir >> >> On 1/29/14 3:14 AM, Niclas Adlertz wrote: >>> Hi Vladimir K, >>> >>> Thank you for your response. >>> >>> Here is an updated webrev: >>> http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev01/ >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> >>> On 2014-01-28 18:21, Vladimir Kozlov wrote: >>>> On 1/28/14 3:18 AM, Niclas Adlertz wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thank you for your response. >>>>> That is a possibility as well. >>>>> >>>>> By using an enum I still have the problem of deciding what to return >>>>> in Name(). >>>>> I could have either >>>>> * an array of const char* with the names and index into it by using >>>>> the enum when returning a name >>>>> * a switch-case on the enums in the Name() method. >>>> >>>> Switch by enum in Name(). >>>> >>>>> >>>>> However, I think sub-classing the MachSpillCopyNode looks cleaner. >>>>> The sub-classing approach could also be of use in a product build >>>>> when debugging a crash and we want to check what type >>>>> of node we are at. >>>> >>>> You can determine type by enum value too. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> If it's ok with you, I'll wait and see what the others think. If more >>>>> people think the enum approach is better I can use >>>>> enums instead. >>>>> >>>>> Kind Regards, >>>>> Niclas Adlertz >>>>> >>>>> On 2014-01-28 11:50, Vladimir Ivanov wrote: >>>>>> Niclas, >>>>>> >>>>>> Why didn't you introduce an enum instead and pass the reason to >>>>>> constructor? Introducing 13 subclasses just to >>>>>> overload Name() method in debug builds looks like an overkill to me. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 1/28/14 2:07 PM, Niclas Adlertz wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> When debugging or visualizing spills/splits/moves in C2 it's hard to >>>>>>> know what caused an insertion of a certain MachSpillCopy. I've made >>>>>>> this >>>>>>> easier by creating subclasses of the MachSpillCopyNode. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032656 >>>>>>> >>>>>>> Kind Regards, >>>>>>> Niclas Adlertz >>>>> >>> > From niclas.adlertz at oracle.com Wed Jan 29 14:56:55 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 29 Jan 2014 23:56:55 +0100 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E981F7.6010208@oracle.com> References: <52E78170.3090507@oracle.com> <52E78B8D.5030207@oracle.com> <52E791EB.2020806@oracle.com> <52E7E71C.7090404@oracle.com> <52E8E29F.1010908@oracle.com> <52E94CA2.7080904@oracle.com> <52E9804F.90203@oracle.com> <52E981F7.6010208@oracle.com> Message-ID: <52E98737.4070605@oracle.com> Hi Vladimir, On 2014-01-29 23:31, Vladimir Kozlov wrote:> Hi Niclas > > On 1/29/14 2:02 PM, Niclas Adlertz wrote: >> Hi Vladimir, >> >> The initial states of _current_pressure and _final_pressure are computed >> in PhaseChaitin::compute_initial_block_pressure(). >> We loop through all live ranges that are in the LIVE_OUT of the block, >> and raise the _current_pressure (for either int or float) for each live >> range. If the _current_pressure is bigger than the _final_pressure >> (which is initially 0), we set the _final_pressure to be >> _current_pressure. We check this each time we increase the >> _current_pressure. This is done in Pressure::raise(). (I.e. the >> _final_pressure is the highest value of _current_pressure that we ever >> encounter in the block) > > It is not accurate, it could be higher. You overwrite it in check_for_high_pressure_transition_at_fatproj(). In a way it is accurate, because at a fat_proj the _current_pressure will be raised and then lowered right after (stepping backwards) since the fat_proj is only "live" at its definition. (That's why we never change the _current_pressure at a fat_proj but still look for a _final_pressure change). > > May be all _*_pressure fields should be private and code which updates them is located in one place. Then it would be more obvious that code you are removing is useless. > >> >> The _high_pressure_limit is passed into the constructor of the Pressure >> class. This is done in the beginning of the build_ifg_physical(): >> >> Pressure int_pressure(last_inst + 1, INTPRESSURE); >> Pressure float_pressure(last_inst + 1, FLOATPRESSURE); >> >>> How we can get case (_current_pressure == _high_pressure_limit)? >> When we lower the pressure, it is assumed that we lower each time by 1 >> (this happens every time we remove a definition from the LIVE_OUT when >> stepping backwards in the block). So if _current_pressure is greater >> than _high_pressure_limit, and we lower the _current_pressure, we might >> hit the case when _current_pressure == _high_pressure_limit. If so, we >> have found a Low to High pressure transition in the block. (Low to High >> when starting from the top of the block) >> However, there is one problem with this case, since the pressure could >> be lowered by more than 1. (Long or Double will lower it by 2). So we >> might miss a transition when lowering. There is already a bug >> (JDK-8032886) filed for this which will be out soon. I didn't fix this >> bug in the clean up since I wanted them to be separate commits. > > Okay, sounds good. > > Thanks, > Vladimir > Do you still want me to add the assert even though we only find a new _final_pressure when raising? Kind Regards, Niclas Adlertz >> >> Kind Regards, >> Niclas Adlertz >> >> >> On 2014-01-29 19:53, Vladimir Kozlov wrote: >>> What is initial state of _current_pressure, _high_pressure_limit, >>> _final_pressure? How we can get case (_current_pressure == >>> _high_pressure_limit)? May be we should replace the code with assert: >>> >>> assert(_current_pressure <= _final_pressure >>> >>> Thanks, >>> Vladimir >>> >>> On 1/29/14 4:09 AM, Niclas Adlertz wrote: >>>> Hi all, >>>> >>>> When building the physical IFG, we step backwards in each block, and >>>> remove things that are defined from the LIVE_OUT, (and lower the current >>>> pressure) and add input to the LIVE_OUT (and raising the current >>>> pressure). Each time we lower or raise the current pressure, we check if >>>> it's bigger than the current maximum pressure, known as final_pressure. >>>> However the final_pressure can never increase when removing definitions >>>> (i.e. lower the current pressure) so the check for a new final_pressure >>>> in Pressure::lower is useless. >>>> >>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032894/webrev00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032894 >>>> >>>> Kind Regards, >>>> Niclas Adlertz >> From niclas.adlertz at oracle.com Wed Jan 29 15:02:29 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 30 Jan 2014 00:02:29 +0100 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E981F7.6010208@oracle.com> References: <52E78170.3090507@oracle.com> <52E78B8D.5030207@oracle.com> <52E791EB.2020806@oracle.com> <52E7E71C.7090404@oracle.com> <52E8E29F.1010908@oracle.com> <52E94CA2.7080904@oracle.com> <52E9804F.90203@oracle.com> <52E981F7.6010208@oracle.com> Message-ID: <52E98885.5000702@oracle.com> Ok, thank you. Kind Regards, Niclas Adlertz On 2014-01-29 23:34, Vladimir Kozlov wrote: > Looks fine. NOTE: our repo is closed. Please, hold with the push. > > Thanks, > Vlaidmir > > On 1/29/14 2:27 PM, Niclas Adlertz wrote: >> Hi Vladimir, >> >> Thank you. >> Here is the new >> webrev:http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev02/ >> I also included machnode.hpp in chaitin.hpp since we need the definition >> of MachSpillCopyNode::SpillType. (Build failed on Solaris otherwise). >> >> Kind Regards, >> Niclas Adlertz >> >> On 2014-01-29 19:46, Vladimir Kozlov wrote: >>> Niclas, >>> >>> Changes are fine but names should be adjusted. I think we should use >>> original "SpillCopy" suffix instead of "SpillNode". "RegToMem" and >>> "MemToReg" are missing the suffux. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/29/14 3:14 AM, Niclas Adlertz wrote: >>>> Hi Vladimir K, >>>> >>>> Thank you for your response. >>>> >>>> Here is an updated webrev: >>>> http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev01/ >>>> >>>> Kind Regards, >>>> Niclas Adlertz >>>> >>>> >>>> On 2014-01-28 18:21, Vladimir Kozlov wrote: >>>>> On 1/28/14 3:18 AM, Niclas Adlertz wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> Thank you for your response. >>>>>> That is a possibility as well. >>>>>> >>>>>> By using an enum I still have the problem of deciding what to return >>>>>> in Name(). >>>>>> I could have either >>>>>> * an array of const char* with the names and index into it by using >>>>>> the enum when returning a name >>>>>> * a switch-case on the enums in the Name() method. >>>>> >>>>> Switch by enum in Name(). >>>>> >>>>>> >>>>>> However, I think sub-classing the MachSpillCopyNode looks cleaner. >>>>>> The sub-classing approach could also be of use in a product build >>>>>> when debugging a crash and we want to check what type >>>>>> of node we are at. >>>>> >>>>> You can determine type by enum value too. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> If it's ok with you, I'll wait and see what the others think. If more >>>>>> people think the enum approach is better I can use >>>>>> enums instead. >>>>>> >>>>>> Kind Regards, >>>>>> Niclas Adlertz >>>>>> >>>>>> On 2014-01-28 11:50, Vladimir Ivanov wrote: >>>>>>> Niclas, >>>>>>> >>>>>>> Why didn't you introduce an enum instead and pass the reason to >>>>>>> constructor? Introducing 13 subclasses just to >>>>>>> overload Name() method in debug builds looks like an overkill to me. >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 1/28/14 2:07 PM, Niclas Adlertz wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> When debugging or visualizing spills/splits/moves in C2 it's hard to >>>>>>>> know what caused an insertion of a certain MachSpillCopy. I've made >>>>>>>> this >>>>>>>> easier by creating subclasses of the MachSpillCopyNode. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032656 >>>>>>>> >>>>>>>> Kind Regards, >>>>>>>> Niclas Adlertz >>>>>> >>>> >> From niclas.adlertz at oracle.com Wed Jan 29 15:05:13 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 30 Jan 2014 00:05:13 +0100 Subject: RFR(XS) 8032894: Remove dead code in Pressure::lower In-Reply-To: <52E98138.7000802@oracle.com> References: <52E8EF82.2000908@oracle.com> <52E94E24.8090605@oracle.com> <52E97A71.5040306@oracle.com> <52E98138.7000802@oracle.com> Message-ID: <52E98929.1070503@oracle.com> Hi Vladimir, On 2014-01-29 23:31, Vladimir Kozlov wrote:> Hi Niclas > > On 1/29/14 2:02 PM, Niclas Adlertz wrote: >> Hi Vladimir, >> >> The initial states of _current_pressure and _final_pressure are computed >> in PhaseChaitin::compute_initial_block_pressure(). >> We loop through all live ranges that are in the LIVE_OUT of the block, >> and raise the _current_pressure (for either int or float) for each live >> range. If the _current_pressure is bigger than the _final_pressure >> (which is initially 0), we set the _final_pressure to be >> _current_pressure. We check this each time we increase the >> _current_pressure. This is done in Pressure::raise(). (I.e. the >> _final_pressure is the highest value of _current_pressure that we ever >> encounter in the block) > > It is not accurate, it could be higher. You overwrite it in check_for_high_pressure_transition_at_fatproj(). In a way it is accurate, because at a fat_proj the _current_pressure will be raised and then lowered right after (stepping backwards) since the fat_proj is only "live" at its definition. (That's why we never change the _current_pressure at a fat_proj but still look for a _final_pressure change). > > May be all _*_pressure fields should be private and code which updates them is located in one place. Then it would be more obvious that code you are removing is useless. > >> >> The _high_pressure_limit is passed into the constructor of the Pressure >> class. This is done in the beginning of the build_ifg_physical(): >> >> Pressure int_pressure(last_inst + 1, INTPRESSURE); >> Pressure float_pressure(last_inst + 1, FLOATPRESSURE); >> >>> How we can get case (_current_pressure == _high_pressure_limit)? >> When we lower the pressure, it is assumed that we lower each time by 1 >> (this happens every time we remove a definition from the LIVE_OUT when >> stepping backwards in the block). So if _current_pressure is greater >> than _high_pressure_limit, and we lower the _current_pressure, we might >> hit the case when _current_pressure == _high_pressure_limit. If so, we >> have found a Low to High pressure transition in the block. (Low to High >> when starting from the top of the block) >> However, there is one problem with this case, since the pressure could >> be lowered by more than 1. (Long or Double will lower it by 2). So we >> might miss a transition when lowering. There is already a bug >> (JDK-8032886) filed for this which will be out soon. I didn't fix this >> bug in the clean up since I wanted them to be separate commits. > > Okay, sounds good. > > Thanks, > Vladimir > Do you still want me to add the assert even though we only find a new _final_pressure when raising? Kind Regards, Niclas Adlertz >> >> Kind Regards, >> Niclas Adlertz >> >> >> On 2014-01-29 19:53, Vladimir Kozlov wrote: >>> What is initial state of _current_pressure, _high_pressure_limit, >>> _final_pressure? How we can get case (_current_pressure == >>> _high_pressure_limit)? May be we should replace the code with assert: >>> >>> assert(_current_pressure <= _final_pressure >>> >>> Thanks, >>> Vladimir >>> >>> On 1/29/14 4:09 AM, Niclas Adlertz wrote: >>>> Hi all, >>>> >>>> When building the physical IFG, we step backwards in each block, and >>>> remove things that are defined from the LIVE_OUT, (and lower the current >>>> pressure) and add input to the LIVE_OUT (and raising the current >>>> pressure). Each time we lower or raise the current pressure, we check if >>>> it's bigger than the current maximum pressure, known as final_pressure. >>>> However the final_pressure can never increase when removing definitions >>>> (i.e. lower the current pressure) so the check for a new final_pressure >>>> in Pressure::lower is useless. >>>> >>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032894/webrev00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032894 >>>> >>>> Kind Regards, >>>> Niclas Adlertz From niclas.adlertz at oracle.com Wed Jan 29 15:05:50 2014 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 30 Jan 2014 00:05:50 +0100 Subject: RFR(S) 8032656: Tag the MachSpillCopies with purpose information In-Reply-To: <52E98737.4070605@oracle.com> References: <52E78170.3090507@oracle.com> <52E78B8D.5030207@oracle.com> <52E791EB.2020806@oracle.com> <52E7E71C.7090404@oracle.com> <52E8E29F.1010908@oracle.com> <52E94CA2.7080904@oracle.com> <52E9804F.90203@oracle.com> <52E981F7.6010208@oracle.com> <52E98737.4070605@oracle.com> Message-ID: <52E9894E.1090907@oracle.com> Sorry, ignore this email. Posted in wrong thread. Kind Regards, Niclas Adlertz On 2014-01-29 23:56, Niclas Adlertz wrote: > Hi Vladimir, > > On 2014-01-29 23:31, Vladimir Kozlov wrote:> Hi Niclas >> >> On 1/29/14 2:02 PM, Niclas Adlertz wrote: >>> Hi Vladimir, >>> >>> The initial states of _current_pressure and _final_pressure are computed >>> in PhaseChaitin::compute_initial_block_pressure(). >>> We loop through all live ranges that are in the LIVE_OUT of the block, >>> and raise the _current_pressure (for either int or float) for each live >>> range. If the _current_pressure is bigger than the _final_pressure >>> (which is initially 0), we set the _final_pressure to be >>> _current_pressure. We check this each time we increase the >>> _current_pressure. This is done in Pressure::raise(). (I.e. the >>> _final_pressure is the highest value of _current_pressure that we ever >>> encounter in the block) >> >> It is not accurate, it could be higher. You overwrite it in check_for_high_pressure_transition_at_fatproj(). > In a way it is accurate, because at a fat_proj the _current_pressure will be raised and then lowered right after (stepping backwards) since the fat_proj is only "live" at its definition. > (That's why we never change the _current_pressure at a fat_proj but still look for a _final_pressure change). > >> >> May be all _*_pressure fields should be private and code which updates them is located in one place. Then it would be more obvious that code you are removing is useless. >> >>> >>> The _high_pressure_limit is passed into the constructor of the Pressure >>> class. This is done in the beginning of the build_ifg_physical(): >>> >>> Pressure int_pressure(last_inst + 1, INTPRESSURE); >>> Pressure float_pressure(last_inst + 1, FLOATPRESSURE); >>> >>>> How we can get case (_current_pressure == _high_pressure_limit)? >>> When we lower the pressure, it is assumed that we lower each time by 1 >>> (this happens every time we remove a definition from the LIVE_OUT when >>> stepping backwards in the block). So if _current_pressure is greater >>> than _high_pressure_limit, and we lower the _current_pressure, we might >>> hit the case when _current_pressure == _high_pressure_limit. If so, we >>> have found a Low to High pressure transition in the block. (Low to High >>> when starting from the top of the block) >>> However, there is one problem with this case, since the pressure could >>> be lowered by more than 1. (Long or Double will lower it by 2). So we >>> might miss a transition when lowering. There is already a bug >>> (JDK-8032886) filed for this which will be out soon. I didn't fix this >>> bug in the clean up since I wanted them to be separate commits. >> >> Okay, sounds good. >> >> Thanks, >> Vladimir >> > > Do you still want me to add the assert even though we only find a new _final_pressure when raising? > > Kind Regards, > Niclas Adlertz > >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> >>> On 2014-01-29 19:53, Vladimir Kozlov wrote: >>>> What is initial state of _current_pressure, _high_pressure_limit, >>>> _final_pressure? How we can get case (_current_pressure == >>>> _high_pressure_limit)? May be we should replace the code with assert: >>>> >>>> assert(_current_pressure <= _final_pressure >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/29/14 4:09 AM, Niclas Adlertz wrote: >>>>> Hi all, >>>>> >>>>> When building the physical IFG, we step backwards in each block, and >>>>> remove things that are defined from the LIVE_OUT, (and lower the current >>>>> pressure) and add input to the LIVE_OUT (and raising the current >>>>> pressure). Each time we lower or raise the current pressure, we check if >>>>> it's bigger than the current maximum pressure, known as final_pressure. >>>>> However the final_pressure can never increase when removing definitions >>>>> (i.e. lower the current pressure) so the check for a new final_pressure >>>>> in Pressure::lower is useless. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032894/webrev00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032894 >>>>> >>>>> Kind Regards, >>>>> Niclas Adlertz >>> > From vladimir.kozlov at oracle.com Wed Jan 29 15:22:38 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jan 2014 15:22:38 -0800 Subject: RFR(XS) 8032894: Remove dead code in Pressure::lower In-Reply-To: <52E98929.1070503@oracle.com> References: <52E8EF82.2000908@oracle.com> <52E94E24.8090605@oracle.com> <52E97A71.5040306@oracle.com> <52E98138.7000802@oracle.com> <52E98929.1070503@oracle.com> Message-ID: <52E98D3E.2090202@oracle.com> > Do you still want me to add the assert even though we only find a new > _final_pressure when raising? No, but I want you to look on my suggestion: > May be all _*_pressure fields should be private and code which updates > them is located in one place. Then it would be more obvious that code > you are removing is useless. Thanks, Vladimir On 1/29/14 3:05 PM, Niclas Adlertz wrote: > Hi Vladimir, > > On 2014-01-29 23:31, Vladimir Kozlov wrote:> Hi Niclas >> >> On 1/29/14 2:02 PM, Niclas Adlertz wrote: >>> Hi Vladimir, >>> >>> The initial states of _current_pressure and _final_pressure are computed >>> in PhaseChaitin::compute_initial_block_pressure(). >>> We loop through all live ranges that are in the LIVE_OUT of the block, >>> and raise the _current_pressure (for either int or float) for each live >>> range. If the _current_pressure is bigger than the _final_pressure >>> (which is initially 0), we set the _final_pressure to be >>> _current_pressure. We check this each time we increase the >>> _current_pressure. This is done in Pressure::raise(). (I.e. the >>> _final_pressure is the highest value of _current_pressure that we ever >>> encounter in the block) >> >> It is not accurate, it could be higher. You overwrite it in >> check_for_high_pressure_transition_at_fatproj(). > In a way it is accurate, because at a fat_proj the _current_pressure > will be raised and then lowered right after (stepping backwards) since > the fat_proj is only "live" at its definition. > (That's why we never change the _current_pressure at a fat_proj but > still look for a _final_pressure change). > >> >> May be all _*_pressure fields should be private and code which updates >> them is located in one place. Then it would be more obvious that code >> you are removing is useless. >> >>> >>> The _high_pressure_limit is passed into the constructor of the Pressure >>> class. This is done in the beginning of the build_ifg_physical(): >>> >>> Pressure int_pressure(last_inst + 1, INTPRESSURE); >>> Pressure float_pressure(last_inst + 1, FLOATPRESSURE); >>> >>>> How we can get case (_current_pressure == _high_pressure_limit)? >>> When we lower the pressure, it is assumed that we lower each time by 1 >>> (this happens every time we remove a definition from the LIVE_OUT when >>> stepping backwards in the block). So if _current_pressure is greater >>> than _high_pressure_limit, and we lower the _current_pressure, we might >>> hit the case when _current_pressure == _high_pressure_limit. If so, we >>> have found a Low to High pressure transition in the block. (Low to High >>> when starting from the top of the block) >>> However, there is one problem with this case, since the pressure could >>> be lowered by more than 1. (Long or Double will lower it by 2). So we >>> might miss a transition when lowering. There is already a bug >>> (JDK-8032886) filed for this which will be out soon. I didn't fix this >>> bug in the clean up since I wanted them to be separate commits. >> >> Okay, sounds good. >> >> Thanks, >> Vladimir >> > > Do you still want me to add the assert even though we only find a new > _final_pressure when raising? > > Kind Regards, > Niclas Adlertz > >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> >>> On 2014-01-29 19:53, Vladimir Kozlov wrote: >>>> What is initial state of _current_pressure, _high_pressure_limit, >>>> _final_pressure? How we can get case (_current_pressure == >>>> _high_pressure_limit)? May be we should replace the code with assert: >>>> >>>> assert(_current_pressure <= _final_pressure >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/29/14 4:09 AM, Niclas Adlertz wrote: >>>>> Hi all, >>>>> >>>>> When building the physical IFG, we step backwards in each block, and >>>>> remove things that are defined from the LIVE_OUT, (and lower the >>>>> current >>>>> pressure) and add input to the LIVE_OUT (and raising the current >>>>> pressure). Each time we lower or raise the current pressure, we >>>>> check if >>>>> it's bigger than the current maximum pressure, known as >>>>> final_pressure. >>>>> However the final_pressure can never increase when removing >>>>> definitions >>>>> (i.e. lower the current pressure) so the check for a new >>>>> final_pressure >>>>> in Pressure::lower is useless. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032894/webrev00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032894 >>>>> >>>>> Kind Regards, >>>>> Niclas Adlertz From igor.veresov at oracle.com Wed Jan 29 22:35:56 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 29 Jan 2014 22:35:56 -0800 Subject: RFR(XS): 8025644 java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java fails with TestData$OfRef): failure java.lang.AssertionError: expected [true] but found [false] Message-ID: <9751AD16-434C-45AA-A391-FBC0E3233C46@oracle.com> When we parse an aastore one of the optimizations we try is to statically cast the speculative type of the object that we obtained during profiling to the type of the superklass (which is the type of the array element) and then do a dynamic check that the type of the object is exactly what we expect. To work correctly the type of superklass must be exact. The following change adds this check. Webrev: http://cr.openjdk.java.net/~iveresov/8025644/webrev.00/ Testing: jtreg, jprt, the failing regression test Thanks, igor From vladimir.kozlov at oracle.com Wed Jan 29 23:35:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jan 2014 23:35:47 -0800 Subject: RFR(XS): 8025644 java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java fails with TestData$OfRef): failure java.lang.AssertionError: expected [true] but found [false] In-Reply-To: <9751AD16-434C-45AA-A391-FBC0E3233C46@oracle.com> References: <9751AD16-434C-45AA-A391-FBC0E3233C46@oracle.com> Message-ID: <52EA00D3.2000902@oracle.com> Igor, I need more explanation. I don't see how exactness of object type affects generation of type check in maybe_cast_profiled_receiver(). Is it because it returns NULL since static_subtype_check() does not return SSC_always_true and type_check_receiver() is not generated? type_check_receiver() generates dynamic check of klass from profiling vs klass loaded from object's header, it can't collapse. Thanks, Vladimir On 1/29/14 10:35 PM, Igor Veresov wrote: > When we parse an aastore one of the optimizations we try is to statically cast the speculative type of the object that we obtained during profiling to the type of the superklass (which is the type of the array element) and then do a dynamic check that the type of the object is exactly what we expect. To work correctly the type of superklass must be exact. The following change adds this check. > > Webrev: http://cr.openjdk.java.net/~iveresov/8025644/webrev.00/ > Testing: jtreg, jprt, the failing regression test > > Thanks, > igor > From mikael.gerdin at oracle.com Thu Jan 30 01:10:16 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 30 Jan 2014 10:10:16 +0100 Subject: RFR (M) [7u60]: Backport of JDK-8014555 G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <1596268.5X5t2hab6c@mgerdin03> References: <1596268.5X5t2hab6c@mgerdin03> Message-ID: <5823396.8n0bj8p6r9@mgerdin03> Hi, it would be great if someone with compiler knowledge could look through the assembler* and compiler changes in this change. Thanks /Mikael On Tuesday 28 January 2014 15.01.12 you wrote: > Hi all, > > Please review this backport for the introduction of the StoreLoad barrier > into G1's write barrier. > > The patch from 8 does not apply cleanly to 7u60 since the MacroAssembler > code was broken out of assembler_*.[ch]pp into macroAssembler_*.[ch]pp. > When I manually edited the patch file to apply the change to the > assembler*- files the patch applies with a line offset so the code has not > been changed, just moved. > > (this fix depends on JDK-8029335, however that change backports cleanly so > as per the process no extra code review is required for the backport.) > > Webrev: http://cr.openjdk.java.net/~mgerdin/8014555-backport/webrev.0 > Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 > > /Mikael From roland.westrelin at oracle.com Thu Jan 30 01:35:41 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 30 Jan 2014 10:35:41 +0100 Subject: RFR (M) [7u60]: Backport of JDK-8014555 G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <5823396.8n0bj8p6r9@mgerdin03> References: <1596268.5X5t2hab6c@mgerdin03> <5823396.8n0bj8p6r9@mgerdin03> Message-ID: <4482B6CD-D740-457D-9FDF-522CA08CC57B@oracle.com> Hi Mikael, > it would be great if someone with compiler knowledge could look through the > assembler* and compiler changes in this change. The assembler* and compiler changes look good. Roland. From igor.veresov at oracle.com Thu Jan 30 01:42:17 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 30 Jan 2014 01:42:17 -0800 Subject: RFR(XS): 8025644 java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java fails with TestData$OfRef): failure java.lang.AssertionError: expected [true] but found [false] In-Reply-To: <52EA00D3.2000902@oracle.com> References: <9751AD16-434C-45AA-A391-FBC0E3233C46@oracle.com> <52EA00D3.2000902@oracle.com> Message-ID: <5318D3C6-BADC-472A-98A4-4857D9B3B495@oracle.com> On Jan 29, 2014, at 11:35 PM, Vladimir Kozlov wrote: > Igor, > > I need more explanation. I don't see how exactness of object type affects generation of type check in maybe_cast_profiled_receiver(). It?s the exactness of the array element klass type. Here is the normal scenario: In Parse::array_store_check() we speculatively assume the klass of the array (see the check and the UCT we emit there). If we pass the check the type of the array is exact and hence the type of klass the array element is exact. We pass that klass of the element as the superklass to gen_checkcast(). The maybe_cast_profiled_receiver() kicks in and tries to statically cast the speculative type of the object that we want to store into the array to the superklass, if it can do that (SSC_always_true) the only other thing we need to check is that the type of the object is indeed the type we expect (another check and UCT). If we cannot do the static cast, maybe_cast_profiled_receiver() returns null and we emit a full blown check. Now the bad scenario: We deopted too much in the array klass check we emitted in Parse::array_store_check(). So when we recompile we skip the opportunity to assert the exactness of the klass of the array (too_many_traps(Deoptimization::Reason_array_check) == true), and just load the element type klass from the inexact array klass. The element klass type would be j.l.Object and not exact (we cannot really know in this case until we load). We go into gen_checkcast() and into maybe_cast_profiled_receiver() assuming this element klass is the superklass. And we happily rely of the non-exact type to statically cast our speculative type of the stores object to j.l.Object. Which is wrong. The whole thing only works if the superklass is the true exact superklass. So, the fix is not to do the second part of the speculation if we don?t really know the exact type of the element, which is really a requirement for it all to work. Instead we just emit the full check? Does it make sense? igor > Is it because it returns NULL since static_subtype_check() does not return SSC_always_true and type_check_receiver() is not generated? type_check_receiver() generates dynamic check of klass from profiling vs klass loaded from object's header, it can't collapse. > > Thanks, > Vladimir > > On 1/29/14 10:35 PM, Igor Veresov wrote: >> When we parse an aastore one of the optimizations we try is to statically cast the speculative type of the object that we obtained during profiling to the type of the superklass (which is the type of the array element) and then do a dynamic check that the type of the object is exactly what we expect. To work correctly the type of superklass must be exact. The following change adds this check. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8025644/webrev.00/ >> Testing: jtreg, jprt, the failing regression test >> >> Thanks, >> igor >> From mikael.gerdin at oracle.com Thu Jan 30 02:11:19 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 30 Jan 2014 11:11:19 +0100 Subject: RFR (M) [7u60]: Backport of JDK-8014555 G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <4482B6CD-D740-457D-9FDF-522CA08CC57B@oracle.com> References: <1596268.5X5t2hab6c@mgerdin03> <5823396.8n0bj8p6r9@mgerdin03> <4482B6CD-D740-457D-9FDF-522CA08CC57B@oracle.com> Message-ID: <3178981.H846CPx309@mgerdin03> On Thursday 30 January 2014 10.35.41 Roland Westrelin wrote: > Hi Mikael, > > > it would be great if someone with compiler knowledge could look through > > the > > assembler* and compiler changes in this change. > > The assembler* and compiler changes look good. Thanks Roland. /Mikael > > Roland. From rickard.backman at oracle.com Thu Jan 30 05:10:56 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Thu, 30 Jan 2014 14:10:56 +0100 Subject: RFR(M): 8027754: Enable loop optimizations for loops with MathExact inside In-Reply-To: <8BB2E6B3-81C3-48A1-B7C0-846338498C18@oracle.com> References: <20140123112723.GG9323@rbackman> <8BB2E6B3-81C3-48A1-B7C0-846338498C18@oracle.com> Message-ID: <20140130131027.GN9323@rbackman> Igor, thanks for looking at this and the suggestions. I added some templates to reduce the amount of code. Webrev: http://cr.openjdk.java.net/~rbackman/8027754.1/ Thanks /R On 01/23, Igor Veresov wrote: > Nice! > > In library_call.cpp: > > Could the LibaryCallKit::inline_math*() family of functions be factored with templates to shave a few lines? There is quite a lot of common code. > I think the overflow idiom insertion can be something like: > > template > void LibraryCallKit::inline_overflow(Node* arg1, Node* arg2) { > Node* op = _gvn.transform(new(C) OperationNodeType(arg1, arg2)); > Node* of = _gvn.transform(new(C) OverflowNodeType(arg1, arg2)); > inline_math_mathExact(op, of); > } > > In mathexactnode.cpp: > You?ve already commoned many things up by introducing OverflowINode and OverflowLNode in hierarchy. > But it feels like some of the code there could factored up as well using template helpers. In many cases the code looks exactly the same for ints and longs, differing only in some types. > > > igor > > > On Jan 23, 2014, at 3:27 AM, Rickard B?ckman wrote: > > > Hi all, > > > > this change is going to 9 (and backporting to 8u20). Can I please have > > this change reviewed? > > > > The implementation of different j.l.Math.mathExact() didn't work very > > well with different optimizations because there was one node that > > generated both control and data. This change has a new implementation > > where each call to j.l.Math.mathExact() generates a Overflow node and a > > normal math operation node (in the integer add example: OverflowAddINode > > and a AddINode). The Overflow node is responsible for generating > > control. > > > > In the end we generate assembly like: > > > > mov rdx, rdi > > add rdx, rsi > > ... > > mov rax, rdi > > add rax, rsi > > jo > > > > With one add instruction for the data and one for flags. Future > > improvements could be to try to match the Overflow and the math > > operation and remove one of them. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027754 > > Webrev: http://cr.openjdk.java.net/~rbackman/8027754/ > > > > Thanks > > /R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140130/9e6076d5/attachment.bin From goetz.lindenmaier at sap.com Thu Jan 30 06:26:51 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 30 Jan 2014 14:26:51 +0000 Subject: RFR (S): 8033168: PPC64: gcc 4.8 warning in output_c.cpp Message-ID: <4295855A5C1DE049A61835A1887419CC2CE9152D@DEWDFEMB12A.global.corp.sap> Hi, Please review and test this change: http://cr.openjdk.java.net/~goetz/webrevs/8033168-1-warn It fixes the warnings with gcc 4.8 when compiling adlc introduced in 8003854 with the ppc port. This also needs to be downported to jdk8u via ppc-aix-port/stage. Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140130/7fb797de/attachment.html From vladimir.kozlov at oracle.com Thu Jan 30 10:22:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jan 2014 10:22:37 -0800 Subject: RFR(XS): 8025644 java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java fails with TestData$OfRef): failure java.lang.AssertionError: expected [true] but found [false] In-Reply-To: <5318D3C6-BADC-472A-98A4-4857D9B3B495@oracle.com> References: <9751AD16-434C-45AA-A391-FBC0E3233C46@oracle.com> <52EA00D3.2000902@oracle.com> <5318D3C6-BADC-472A-98A4-4857D9B3B495@oracle.com> Message-ID: <52EA986D.9020308@oracle.com> Igor, Please, add this explanation to the bug report. You said before that a dynamic check was missed and I mistakenly thought it was check in maybe_cast_profiled_receiver() but it was in array_store_check(). Now it makes sense. Changes are good. Please, also run CTW tests. Note: our repo hs-comp is closed only for ppc-aix fixes. Please, hold on your push. Thanks, Vladimir On 1/30/14 1:42 AM, Igor Veresov wrote: > > On Jan 29, 2014, at 11:35 PM, Vladimir Kozlov wrote: > >> Igor, >> >> I need more explanation. I don't see how exactness of object type affects generation of type check in maybe_cast_profiled_receiver(). > > It?s the exactness of the array element klass type. > > Here is the normal scenario: > In Parse::array_store_check() we speculatively assume the klass of the array (see the check and the UCT we emit there). If we pass the check the type of the array is exact and hence the type of klass the array element is exact. We pass that klass of the element as the superklass to gen_checkcast(). The maybe_cast_profiled_receiver() kicks in and tries to statically cast the speculative type of the object that we want to store into the array to the superklass, if it can do that (SSC_always_true) the only other thing we need to check is that the type of the object is indeed the type we expect (another check and UCT). If we cannot do the static cast, maybe_cast_profiled_receiver() returns null and we emit a full blown check. > > Now the bad scenario: > We deopted too much in the array klass check we emitted in Parse::array_store_check(). So when we recompile we skip the opportunity to assert the exactness of the klass of the array (too_many_traps(Deoptimization::Reason_array_check) == true), and just load the element type klass from the inexact array klass. The element klass type would be j.l.Object and not exact (we cannot really know in this case until we load). We go into gen_checkcast() and into maybe_cast_profiled_receiver() assuming this element klass is the superklass. And we happily rely of the non-exact type to statically cast our speculative type of the stores object to j.l.Object. Which is wrong. The whole thing only works if the superklass is the true exact superklass. > > So, the fix is not to do the second part of the speculation if we don?t really know the exact type of the element, which is really a requirement for it all to work. > Instead we just emit the full check? > > Does it make sense? > > igor > > >> Is it because it returns NULL since static_subtype_check() does not return SSC_always_true and type_check_receiver() is not generated? type_check_receiver() generates dynamic check of klass from profiling vs klass loaded from object's header, it can't collapse. >> >> Thanks, >> Vladimir >> >> On 1/29/14 10:35 PM, Igor Veresov wrote: >>> When we parse an aastore one of the optimizations we try is to statically cast the speculative type of the object that we obtained during profiling to the type of the superklass (which is the type of the array element) and then do a dynamic check that the type of the object is exactly what we expect. To work correctly the type of superklass must be exact. The following change adds this check. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8025644/webrev.00/ >>> Testing: jtreg, jprt, the failing regression test >>> >>> Thanks, >>> igor >>> > From igor.veresov at oracle.com Thu Jan 30 11:58:12 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 30 Jan 2014 11:58:12 -0800 Subject: RFR(M): 8027754: Enable loop optimizations for loops with MathExact inside In-Reply-To: <20140130131027.GN9323@rbackman> References: <20140123112723.GG9323@rbackman> <8BB2E6B3-81C3-48A1-B7C0-846338498C18@oracle.com> <20140130131027.GN9323@rbackman> Message-ID: Hi Rickard, In library_call.cpp: May be it?s just me but I?d get rid of bool LibraryCallKit::inline_math_overflow(bool is_unary) and reference the arguments explicitly. Otherwise it feels like too much depth to follow through when reading the code(since we keep specialized functions like inline_math_addExactI() anyway). Something like: bool LibraryCallKit::inline_math_addExactI(bool is_increment) { return inline_math_overflow(argument(0), is_increment ? intcon(1) : argument(1)); } Which will also allow you to avoid adding the IsLong enum. In mathexactnode.cpp: I?d move the AddHelper, SubHelper, MulHelper to the cpp file and reference them directly in a more verbose way. Something like: bool OverflowAddINode::will_overflow(jint v1, jint v2) const { return AddHelper::will_overflow(v1, v2); } Otherwise the reader has to go and find out what OverflowHelper means in a particular context. This will also reduce the amount of implementation specifics in the hpp. Is there a particular reason why you define will_overflow() and can_overflow() to do ShoundNotReachHere() is the base classes instead of making them pure virtual and let the compiler make sure that you define them? I guess there is an expectation that there are going to be overflow nodes that don?t redefine these methods but are there really going to be any? You also define const Type* sub(const Type* t1, const Type* t2) const as ShouldNotReachHere() and never redefine it. What are your plans for it? igor On Jan 30, 2014, at 5:10 AM, Rickard B?ckman wrote: > Igor, > > thanks for looking at this and the suggestions. I added some templates > to reduce the amount of code. > > Webrev: http://cr.openjdk.java.net/~rbackman/8027754.1/ > > Thanks > /R > > On 01/23, Igor Veresov wrote: >> Nice! >> >> In library_call.cpp: >> >> Could the LibaryCallKit::inline_math*() family of functions be factored with templates to shave a few lines? There is quite a lot of common code. >> I think the overflow idiom insertion can be something like: >> >> template >> void LibraryCallKit::inline_overflow(Node* arg1, Node* arg2) { >> Node* op = _gvn.transform(new(C) OperationNodeType(arg1, arg2)); >> Node* of = _gvn.transform(new(C) OverflowNodeType(arg1, arg2)); >> inline_math_mathExact(op, of); >> } >> >> In mathexactnode.cpp: >> You?ve already commoned many things up by introducing OverflowINode and OverflowLNode in hierarchy. >> But it feels like some of the code there could factored up as well using template helpers. In many cases the code looks exactly the same for ints and longs, differing only in some types. >> >> >> igor >> >> >> On Jan 23, 2014, at 3:27 AM, Rickard B?ckman wrote: >> >>> Hi all, >>> >>> this change is going to 9 (and backporting to 8u20). Can I please have >>> this change reviewed? >>> >>> The implementation of different j.l.Math.mathExact() didn't work very >>> well with different optimizations because there was one node that >>> generated both control and data. This change has a new implementation >>> where each call to j.l.Math.mathExact() generates a Overflow node and a >>> normal math operation node (in the integer add example: OverflowAddINode >>> and a AddINode). The Overflow node is responsible for generating >>> control. >>> >>> In the end we generate assembly like: >>> >>> mov rdx, rdi >>> add rdx, rsi >>> ... >>> mov rax, rdi >>> add rax, rsi >>> jo >>> >>> With one add instruction for the data and one for flags. Future >>> improvements could be to try to match the Overflow and the math >>> operation and remove one of them. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027754 >>> Webrev: http://cr.openjdk.java.net/~rbackman/8027754/ >>> >>> Thanks >>> /R From aleksey.shipilev at oracle.com Thu Jan 30 12:15:56 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 31 Jan 2014 00:15:56 +0400 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52E0184E.2090004@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> Message-ID: <52EAB2FC.1080203@oracle.com> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: > On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >> Question first: can you wait about 2 weeks when we merge ppc64 changes? > > I think we can wait. I don't want to collide with PPC merge either. In > fact, it would be even more convenient for us to grab PPC C2 in the > experiments from the mainline. Are we open already? I see PPC changes had collided with my patch. Even if it's too early to push the patch, I merged the upstream changes into the updated webrev: http://cr.openjdk.java.net/~shade/8031818/webrev.01/ Instead of introducing a new method, I rewired the predicate and rearranged the comments to make its structure clear. I think extracting method is not required now. Also, a few typos corrected. Testing: - full cycle JPRT -Aleksey. From vladimir.kozlov at oracle.com Thu Jan 30 13:53:13 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jan 2014 13:53:13 -0800 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EAB2FC.1080203@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> Message-ID: <52EAC9C9.2090105@oracle.com> Aleksey, hs-comp is closed for almost 2 weeks until SQE done all testing. Only ppc merge related fixes are allowed. You check is_initializer() for all types of fields in do_exits(). But is_final() is also set for @Stable field which could any methods based on the comment in do_put_xxx(). Thanks, Vladimir On 1/30/14 12:15 PM, Aleksey Shipilev wrote: > On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>> Question first: can you wait about 2 weeks when we merge ppc64 changes? >> >> I think we can wait. I don't want to collide with PPC merge either. In >> fact, it would be even more convenient for us to grab PPC C2 in the >> experiments from the mainline. > > Are we open already? I see PPC changes had collided with my patch. Even > if it's too early to push the patch, I merged the upstream changes into > the updated webrev: > http://cr.openjdk.java.net/~shade/8031818/webrev.01/ > > Instead of introducing a new method, I rewired the predicate and > rearranged the comments to make its structure clear. I think extracting > method is not required now. Also, a few typos corrected. > > Testing: > - full cycle JPRT > > -Aleksey. > From aleksey.shipilev at oracle.com Thu Jan 30 14:14:51 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 31 Jan 2014 02:14:51 +0400 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EAC9C9.2090105@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> Message-ID: <52EACEDB.4070903@oracle.com> On 01/31/2014 01:53 AM, Vladimir Kozlov wrote: > hs-comp is closed for almost 2 weeks until SQE done all testing. Only > ppc merge related fixes are allowed. Understood, no pressure. > You check is_initializer() for all types of fields in do_exits(). But > is_final() is also set for @Stable field which could any methods based > on the comment in do_put_xxx(). Well, that's disturbing. In pure spec-induced sense, the block emitting the barrier in do_exits() is only valid for initializers. That means, @Stable can indeed mimic its constructor store as the final field store. However, piggybacking on the same code to produce the barrier for an arbitrary method seems very error-prone (and even contradicting the comment in do_exits() which assumes [wrote_final == true] => [method.is_initializer() == true]). If @Stable writes out the value in an arbitrary method, then it requires release barrier on it's own. It is a pure luck finals _also_ have MemBar_Release, while they could have more relaxed form... especially when/if JMM 9 effort would allow this relaxation. Conflating memory semantics for finals and @Stable seems wrong. Hence, I think the change is sound. It keeps @Stable semantics for constructor stores. @Stable needs more work to emit release barriers for the arbitrary methods if required (why?), and I think given the failure scenario affects only non-TSO platforms, it can be done separately. Thoughts? (Vladimir Ivanov, please report in!) -Aleksey. > Thanks, > Vladimir > > On 1/30/14 12:15 PM, Aleksey Shipilev wrote: >> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>>> Question first: can you wait about 2 weeks when we merge ppc64 changes? >>> >>> I think we can wait. I don't want to collide with PPC merge either. In >>> fact, it would be even more convenient for us to grab PPC C2 in the >>> experiments from the mainline. >> >> Are we open already? I see PPC changes had collided with my patch. Even >> if it's too early to push the patch, I merged the upstream changes into >> the updated webrev: >> http://cr.openjdk.java.net/~shade/8031818/webrev.01/ >> >> Instead of introducing a new method, I rewired the predicate and >> rearranged the comments to make its structure clear. I think extracting >> method is not required now. Also, a few typos corrected. >> >> Testing: >> - full cycle JPRT >> >> -Aleksey. >> From vladimir.kozlov at oracle.com Thu Jan 30 14:47:50 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jan 2014 14:47:50 -0800 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EACEDB.4070903@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> <52EACEDB.4070903@oracle.com> Message-ID: <52EAD696.9090406@oracle.com> Can we simple separate stable stores to wrote_stable() with own code in do_exit() and comments? Thanks, Vladimir K On 1/30/14 2:14 PM, Aleksey Shipilev wrote: > On 01/31/2014 01:53 AM, Vladimir Kozlov wrote: >> hs-comp is closed for almost 2 weeks until SQE done all testing. Only >> ppc merge related fixes are allowed. > > Understood, no pressure. > >> You check is_initializer() for all types of fields in do_exits(). But >> is_final() is also set for @Stable field which could any methods based >> on the comment in do_put_xxx(). > > Well, that's disturbing. > > In pure spec-induced sense, the block emitting the barrier in do_exits() > is only valid for initializers. That means, @Stable can indeed mimic its > constructor store as the final field store. However, piggybacking on the > same code to produce the barrier for an arbitrary method seems very > error-prone (and even contradicting the comment in do_exits() which > assumes [wrote_final == true] => [method.is_initializer() == true]). > > If @Stable writes out the value in an arbitrary method, then it requires > release barrier on it's own. It is a pure luck finals _also_ have > MemBar_Release, while they could have more relaxed form... especially > when/if JMM 9 effort would allow this relaxation. Conflating memory > semantics for finals and @Stable seems wrong. > > Hence, I think the change is sound. It keeps @Stable semantics for > constructor stores. @Stable needs more work to emit release barriers for > the arbitrary methods if required (why?), and I think given the failure > scenario affects only non-TSO platforms, it can be done separately. > > Thoughts? (Vladimir Ivanov, please report in!) > > -Aleksey. > >> Thanks, >> Vladimir >> >> On 1/30/14 12:15 PM, Aleksey Shipilev wrote: >>> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >>>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>>>> Question first: can you wait about 2 weeks when we merge ppc64 changes? >>>> >>>> I think we can wait. I don't want to collide with PPC merge either. In >>>> fact, it would be even more convenient for us to grab PPC C2 in the >>>> experiments from the mainline. >>> >>> Are we open already? I see PPC changes had collided with my patch. Even >>> if it's too early to push the patch, I merged the upstream changes into >>> the updated webrev: >>> http://cr.openjdk.java.net/~shade/8031818/webrev.01/ >>> >>> Instead of introducing a new method, I rewired the predicate and >>> rearranged the comments to make its structure clear. I think extracting >>> method is not required now. Also, a few typos corrected. >>> >>> Testing: >>> - full cycle JPRT >>> >>> -Aleksey. >>> > From aleksey.shipilev at oracle.com Thu Jan 30 14:54:59 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 31 Jan 2014 02:54:59 +0400 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EAD696.9090406@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> <52EACEDB.4070903@oracle.com> <52EAD696.9090406@oracle.com> Message-ID: <52EAD843.1030500@oracle.com> Yes we can. Do you want me to do this in this CR? -Aleksey. On 01/31/2014 02:47 AM, Vladimir Kozlov wrote: > Can we simple separate stable stores to wrote_stable() with own code in > do_exit() and comments? > > Thanks, > Vladimir K > > On 1/30/14 2:14 PM, Aleksey Shipilev wrote: >> On 01/31/2014 01:53 AM, Vladimir Kozlov wrote: >>> hs-comp is closed for almost 2 weeks until SQE done all testing. Only >>> ppc merge related fixes are allowed. >> >> Understood, no pressure. >> >>> You check is_initializer() for all types of fields in do_exits(). But >>> is_final() is also set for @Stable field which could any methods based >>> on the comment in do_put_xxx(). >> >> Well, that's disturbing. >> >> In pure spec-induced sense, the block emitting the barrier in do_exits() >> is only valid for initializers. That means, @Stable can indeed mimic its >> constructor store as the final field store. However, piggybacking on the >> same code to produce the barrier for an arbitrary method seems very >> error-prone (and even contradicting the comment in do_exits() which >> assumes [wrote_final == true] => [method.is_initializer() == true]). >> >> If @Stable writes out the value in an arbitrary method, then it requires >> release barrier on it's own. It is a pure luck finals _also_ have >> MemBar_Release, while they could have more relaxed form... especially >> when/if JMM 9 effort would allow this relaxation. Conflating memory >> semantics for finals and @Stable seems wrong. >> >> Hence, I think the change is sound. It keeps @Stable semantics for >> constructor stores. @Stable needs more work to emit release barriers for >> the arbitrary methods if required (why?), and I think given the failure >> scenario affects only non-TSO platforms, it can be done separately. >> >> Thoughts? (Vladimir Ivanov, please report in!) >> >> -Aleksey. >> >>> Thanks, >>> Vladimir >>> >>> On 1/30/14 12:15 PM, Aleksey Shipilev wrote: >>>> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >>>>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>>>>> Question first: can you wait about 2 weeks when we merge ppc64 >>>>>> changes? >>>>> >>>>> I think we can wait. I don't want to collide with PPC merge either. In >>>>> fact, it would be even more convenient for us to grab PPC C2 in the >>>>> experiments from the mainline. >>>> >>>> Are we open already? I see PPC changes had collided with my patch. Even >>>> if it's too early to push the patch, I merged the upstream changes into >>>> the updated webrev: >>>> http://cr.openjdk.java.net/~shade/8031818/webrev.01/ >>>> >>>> Instead of introducing a new method, I rewired the predicate and >>>> rearranged the comments to make its structure clear. I think extracting >>>> method is not required now. Also, a few typos corrected. >>>> >>>> Testing: >>>> - full cycle JPRT >>>> >>>> -Aleksey. >>>> >> From vladimir.kozlov at oracle.com Thu Jan 30 15:19:08 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jan 2014 15:19:08 -0800 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EAD843.1030500@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> <52EACEDB.4070903@oracle.com> <52EAD696.9090406@oracle.com> <52EAD843.1030500@oracle.com> Message-ID: <52EADDEC.7060609@oracle.com> On 1/30/14 2:54 PM, Aleksey Shipilev wrote: > Yes we can. > Do you want me to do this in this CR? Yes, please. Thanks, Vladimir > > -Aleksey. > > On 01/31/2014 02:47 AM, Vladimir Kozlov wrote: >> Can we simple separate stable stores to wrote_stable() with own code in >> do_exit() and comments? >> >> Thanks, >> Vladimir K >> >> On 1/30/14 2:14 PM, Aleksey Shipilev wrote: >>> On 01/31/2014 01:53 AM, Vladimir Kozlov wrote: >>>> hs-comp is closed for almost 2 weeks until SQE done all testing. Only >>>> ppc merge related fixes are allowed. >>> >>> Understood, no pressure. >>> >>>> You check is_initializer() for all types of fields in do_exits(). But >>>> is_final() is also set for @Stable field which could any methods based >>>> on the comment in do_put_xxx(). >>> >>> Well, that's disturbing. >>> >>> In pure spec-induced sense, the block emitting the barrier in do_exits() >>> is only valid for initializers. That means, @Stable can indeed mimic its >>> constructor store as the final field store. However, piggybacking on the >>> same code to produce the barrier for an arbitrary method seems very >>> error-prone (and even contradicting the comment in do_exits() which >>> assumes [wrote_final == true] => [method.is_initializer() == true]). >>> >>> If @Stable writes out the value in an arbitrary method, then it requires >>> release barrier on it's own. It is a pure luck finals _also_ have >>> MemBar_Release, while they could have more relaxed form... especially >>> when/if JMM 9 effort would allow this relaxation. Conflating memory >>> semantics for finals and @Stable seems wrong. >>> >>> Hence, I think the change is sound. It keeps @Stable semantics for >>> constructor stores. @Stable needs more work to emit release barriers for >>> the arbitrary methods if required (why?), and I think given the failure >>> scenario affects only non-TSO platforms, it can be done separately. >>> >>> Thoughts? (Vladimir Ivanov, please report in!) >>> >>> -Aleksey. >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/30/14 12:15 PM, Aleksey Shipilev wrote: >>>>> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >>>>>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>>>>>> Question first: can you wait about 2 weeks when we merge ppc64 >>>>>>> changes? >>>>>> >>>>>> I think we can wait. I don't want to collide with PPC merge either. In >>>>>> fact, it would be even more convenient for us to grab PPC C2 in the >>>>>> experiments from the mainline. >>>>> >>>>> Are we open already? I see PPC changes had collided with my patch. Even >>>>> if it's too early to push the patch, I merged the upstream changes into >>>>> the updated webrev: >>>>> http://cr.openjdk.java.net/~shade/8031818/webrev.01/ >>>>> >>>>> Instead of introducing a new method, I rewired the predicate and >>>>> rearranged the comments to make its structure clear. I think extracting >>>>> method is not required now. Also, a few typos corrected. >>>>> >>>>> Testing: >>>>> - full cycle JPRT >>>>> >>>>> -Aleksey. >>>>> >>> > From rickard.backman at oracle.com Fri Jan 31 03:44:43 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 31 Jan 2014 12:44:43 +0100 Subject: RFR(M): 8027754: Enable loop optimizations for loops with MathExact inside In-Reply-To: References: <20140123112723.GG9323@rbackman> <8BB2E6B3-81C3-48A1-B7C0-846338498C18@oracle.com> <20140130131027.GN9323@rbackman> Message-ID: <20140131114443.GP9323@rbackman> Igor, I changed the calls in library_call.cpp according to your suggestions. The same with mathexactnode.cpp. Also did some additional cleanup there. Made will_overflow and can_overflow pure virtual in the base classes. The sub method is required as OverflowNode inherits from CmpNode. Updated webrev: http://cr.openjdk.java.net/~rbackman/8028997.2/ Thanks /R On 01/30, Igor Veresov wrote: > Hi Rickard, > > In library_call.cpp: > > May be it?s just me but I?d get rid of bool LibraryCallKit::inline_math_overflow(bool is_unary) and reference the arguments explicitly. Otherwise it feels like too much depth to follow through when reading the code(since we keep specialized functions like inline_math_addExactI() anyway). > > Something like: > bool LibraryCallKit::inline_math_addExactI(bool is_increment) { > return inline_math_overflow(argument(0), is_increment ? intcon(1) : argument(1)); > } > Which will also allow you to avoid adding the IsLong enum. > > In mathexactnode.cpp: > > I?d move the AddHelper, SubHelper, MulHelper to the cpp file and reference them directly in a more verbose way. > Something like: > bool OverflowAddINode::will_overflow(jint v1, jint v2) const { > return AddHelper::will_overflow(v1, v2); > } > Otherwise the reader has to go and find out what OverflowHelper means in a particular context. This will also reduce the amount of implementation specifics in the hpp. > > > Is there a particular reason why you define will_overflow() and can_overflow() to do ShoundNotReachHere() is the base classes instead of making them pure virtual and let the compiler make sure that you define them? I guess there is an expectation that there are going to be overflow nodes that don?t redefine these methods but are there really going to be any? > > You also define const Type* sub(const Type* t1, const Type* t2) const as ShouldNotReachHere() and never redefine it. What are your plans for it? > > igor > > > > > > On Jan 30, 2014, at 5:10 AM, Rickard B?ckman wrote: > > > Igor, > > > > thanks for looking at this and the suggestions. I added some templates > > to reduce the amount of code. > > > > Webrev: http://cr.openjdk.java.net/~rbackman/8027754.1/ > > > > Thanks > > /R > > > > On 01/23, Igor Veresov wrote: > >> Nice! > >> > >> In library_call.cpp: > >> > >> Could the LibaryCallKit::inline_math*() family of functions be factored with templates to shave a few lines? There is quite a lot of common code. > >> I think the overflow idiom insertion can be something like: > >> > >> template > >> void LibraryCallKit::inline_overflow(Node* arg1, Node* arg2) { > >> Node* op = _gvn.transform(new(C) OperationNodeType(arg1, arg2)); > >> Node* of = _gvn.transform(new(C) OverflowNodeType(arg1, arg2)); > >> inline_math_mathExact(op, of); > >> } > >> > >> In mathexactnode.cpp: > >> You?ve already commoned many things up by introducing OverflowINode and OverflowLNode in hierarchy. > >> But it feels like some of the code there could factored up as well using template helpers. In many cases the code looks exactly the same for ints and longs, differing only in some types. > >> > >> > >> igor > >> > >> > >> On Jan 23, 2014, at 3:27 AM, Rickard B?ckman wrote: > >> > >>> Hi all, > >>> > >>> this change is going to 9 (and backporting to 8u20). Can I please have > >>> this change reviewed? > >>> > >>> The implementation of different j.l.Math.mathExact() didn't work very > >>> well with different optimizations because there was one node that > >>> generated both control and data. This change has a new implementation > >>> where each call to j.l.Math.mathExact() generates a Overflow node and a > >>> normal math operation node (in the integer add example: OverflowAddINode > >>> and a AddINode). The Overflow node is responsible for generating > >>> control. > >>> > >>> In the end we generate assembly like: > >>> > >>> mov rdx, rdi > >>> add rdx, rsi > >>> ... > >>> mov rax, rdi > >>> add rax, rsi > >>> jo > >>> > >>> With one add instruction for the data and one for flags. Future > >>> improvements could be to try to match the Overflow and the math > >>> operation and remove one of them. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027754 > >>> Webrev: http://cr.openjdk.java.net/~rbackman/8027754/ > >>> > >>> Thanks > >>> /R > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140131/dfb7ae23/attachment.bin From aleksey.shipilev at oracle.com Fri Jan 31 05:35:31 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 31 Jan 2014 17:35:31 +0400 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EADDEC.7060609@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> <52EACEDB.4070903@oracle.com> <52EAD696.9090406@oracle.com> <52EAD843.1030500@oracle.com> <52EADDEC.7060609@oracle.com> Message-ID: <52EBA6A3.2010400@oracle.com> Ok, here you go: http://cr.openjdk.java.net/~shade/8031818/webrev.02/ Testing: - full JPRT cycle - microbenchmarks with -XX:(+|-)AlwaysSafeConstructors Thanks, -Aleksey On 01/31/2014 03:19 AM, Vladimir Kozlov wrote: > On 1/30/14 2:54 PM, Aleksey Shipilev wrote: >> Yes we can. >> Do you want me to do this in this CR? > > Yes, please. > > Thanks, > Vladimir > >> >> -Aleksey. >> >> On 01/31/2014 02:47 AM, Vladimir Kozlov wrote: >>> Can we simple separate stable stores to wrote_stable() with own code in >>> do_exit() and comments? >>> >>> Thanks, >>> Vladimir K >>> >>> On 1/30/14 2:14 PM, Aleksey Shipilev wrote: >>>> On 01/31/2014 01:53 AM, Vladimir Kozlov wrote: >>>>> hs-comp is closed for almost 2 weeks until SQE done all testing. Only >>>>> ppc merge related fixes are allowed. >>>> >>>> Understood, no pressure. >>>> >>>>> You check is_initializer() for all types of fields in do_exits(). But >>>>> is_final() is also set for @Stable field which could any methods based >>>>> on the comment in do_put_xxx(). >>>> >>>> Well, that's disturbing. >>>> >>>> In pure spec-induced sense, the block emitting the barrier in >>>> do_exits() >>>> is only valid for initializers. That means, @Stable can indeed mimic >>>> its >>>> constructor store as the final field store. However, piggybacking on >>>> the >>>> same code to produce the barrier for an arbitrary method seems very >>>> error-prone (and even contradicting the comment in do_exits() which >>>> assumes [wrote_final == true] => [method.is_initializer() == true]). >>>> >>>> If @Stable writes out the value in an arbitrary method, then it >>>> requires >>>> release barrier on it's own. It is a pure luck finals _also_ have >>>> MemBar_Release, while they could have more relaxed form... especially >>>> when/if JMM 9 effort would allow this relaxation. Conflating memory >>>> semantics for finals and @Stable seems wrong. >>>> >>>> Hence, I think the change is sound. It keeps @Stable semantics for >>>> constructor stores. @Stable needs more work to emit release barriers >>>> for >>>> the arbitrary methods if required (why?), and I think given the failure >>>> scenario affects only non-TSO platforms, it can be done separately. >>>> >>>> Thoughts? (Vladimir Ivanov, please report in!) >>>> >>>> -Aleksey. >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/30/14 12:15 PM, Aleksey Shipilev wrote: >>>>>> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >>>>>>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>>>>>>> Question first: can you wait about 2 weeks when we merge ppc64 >>>>>>>> changes? >>>>>>> >>>>>>> I think we can wait. I don't want to collide with PPC merge >>>>>>> either. In >>>>>>> fact, it would be even more convenient for us to grab PPC C2 in the >>>>>>> experiments from the mainline. >>>>>> >>>>>> Are we open already? I see PPC changes had collided with my patch. >>>>>> Even >>>>>> if it's too early to push the patch, I merged the upstream changes >>>>>> into >>>>>> the updated webrev: >>>>>> http://cr.openjdk.java.net/~shade/8031818/webrev.01/ >>>>>> >>>>>> Instead of introducing a new method, I rewired the predicate and >>>>>> rearranged the comments to make its structure clear. I think >>>>>> extracting >>>>>> method is not required now. Also, a few typos corrected. >>>>>> >>>>>> Testing: >>>>>> - full cycle JPRT >>>>>> >>>>>> -Aleksey. >>>>>> >>>> >> From roland.westrelin at oracle.com Fri Jan 31 07:10:48 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 31 Jan 2014 16:10:48 +0100 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method In-Reply-To: <52E6D79E.2010505@oracle.com> References: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> <52E091D0.3010508@oracle.com> <52E09526.7030907@oracle.com> <865C3299-3E60-40D4-84AA-8EEA27ADAF99@oracle.com> <52E3191A.60604@oracle.com> <3FE1C7FB-C7E3-4032-9A40-946061F7A97D@oracle.com> <52E6D79E.2010505@oracle.com> Message-ID: Hi Vladimir, > Yes, intuitively it looks correct but I am still not sure that we should do that. > > How big affect this has on score? I don't see any data. > Can you write microbenchmark to show such behavior and benefits from these changes? This is a test that triggers the problem: http://cr.openjdk.java.net/~roland/8031754/TestInlineDepth.java m3() is the method that is compiled early. It doesn?t use the profile so there?s no uncommon trap and it doesn?t get a chance to run interpreted again and so update the profile. m5() is inlined in m1() and ideally inlines C.m(). Without this patch, the profile from m3() is the one that is used for inlining in m5() and A.m() is inlined. That causes an uncommon trap when the compile code for m1() runs and so m1() is recompiled. It inlines A.m() again but this time with a slow case of doing the call. With the change that I?m proposing, C.m() is inlined in m1(). There?s no uncommon trap. Still no numbers. But with this test case it would be a simple matter of finding code that optimizes very well once C.m() is inlined to make it look very good, right? With nashorn, one run of the richards.js benchmark was be good and the next one would be 40% slower because of a missed optimization. I believe this is one of the causes (the big one being the trap change that was reviewed recently). But for some reason, I can?t reproduce it anymore as I said in a previous mail. Roland. > > Thanks, > Vladimir > > On 1/27/14 9:58 AM, Roland Westrelin wrote: >> Hi Vladimir, >> >>>> Thanks for looking at this, Vladimir. >>>> >>>>>> My wild guess is that the outermost method generally gives you the best >>>>>> (cleanest) context information. The inner callees may have been called >>>>>> from various callers, and so their type profiles may have been polluted >>>>>> by other callers. >>>>> >>>>> They can't be polluted. We record only one speculative type. If Interpreter see a different type it will set flags and that type information will not be used. At least that is how I understand it works. That is why I am asking Roland to clarify this. >>>> >>>> That?s the way they work. What can happen for this (and what happens sometimes I believe): >>>> >>>> m1() { >>>> m3(); >>>> } >>>> >>>> m() { >>>> m1(); >>>> m2(); >>>> } >>>> >>>> is that m3() is a heavily used method called from some other place early during the application run. Some profile is recorded. The method becomes so hot that it gets compiled with c2. So we stop profiling. Then m3() is called from m1() but because it?s already compiled we don?t record the conflicting profile. When m() is compiled we are stuck with an incorrect profile and we may miss some optimization opportunities. >>> >>> Okay, it makes sense. So m3() has totally unrelated to current compilation type information. But you should have some uncommon traps which will force deoptimization of m3() if type is wrong when you run m1(). On other hand deoptimization may not happen fast enough before we compile m(). I agree we can have such case. >>> >>> What about case when m3() calls m4() only when m3() is called from m()->m1()? In such situation m4() will collect correct type for m() compilation(). But it will be overwritten by bad type from m3(). >> >> But in this case, for m4() to have profile, the branch that calls m4() must have been run and the profile there should be consistent with the profile in m3()? >> >>>> >>>> As Krys said, intuitively "the outermost method generally gives you the best (cleanest) context information?. It?s only a heuristic and as such, it?s certainly easy to build a test case for which this heuristic doesn?t do a good job. It does help for experiments I made with nashorn so I?d like to see it used to confirm it does help. >>> >>> Is it possible to detect type discrepancy in m3() and ignore (by special marking) all non-matching speculative types in m3()? >>> >>> You already do prefer speculative type from call's parameters over type collected for input arguments. Right? May be use that as indication that types in inlined method could be wrong. >> >> That doesn?t sound very robust to me. If profile is inaccurate in the callee, most likely we haven?t run the caller long enough to have profiling, right? >> >> Another thing that could be done is record the type that causes the deoptimization in the speculative trap. Then, presumably if we hit a trap everything runs interpreted again, profile is updated and when we recompile and we see that a trap was hit, we can compare the new type with the type that caused the deoptimization and if they differ, try optimizing again. That?s more space required in the method data. >> >> I found this problem when running nashorn but I don?t seem to able to hit it again for some reason. So I could withdraw this change for now. I?m concerned it will show up again sooner or later anyway and time will be needed to figure out what is happening. >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Roland. >>>> >>>> >>>>> >>>>> If you have merging case: >>>>> >>>>> if (x) >>>>> m1() >>>>> else >>>>> m2() >>>>> >>>>> I don't understand why at merge point information from m2 will be more precise then from m3() called from m1(). >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> - Kris >>>>>> >>>>>> >>>>>> On Wed, Jan 22, 2014 at 7:51 PM, Vladimir Kozlov >>>>>> > wrote: >>>>>> >>>>>> Roland, >>>>>> >>>>>> I don't see how inlining depth can define type's accuracy in general >>>>>> case. why it can't be reverse: more accurate type from most deeply >>>>>> inlined method? >>>>>> >>>>>> I thought you only have speculative type if it is the only one type >>>>>> record in MDO. How in your case you can have different types? >>>>>> >>>>>> Can you be more specific? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> >>>>>> On 1/22/14 1:42 AM, Roland Westrelin wrote: >>>>>> >>>>>> When a node already has a speculative type, and parsing >>>>>> encounters extra profiling data, the new profiling data is >>>>>> ignored. So profiling data coming from profile points closer to >>>>>> the root of the compilation is favored which I think makes >>>>>> sense: it's the data that is most specific to the context of >>>>>> this compilation. >>>>>> >>>>>> During runs, profile data is not always entirely coherent so we >>>>>> may hit something like this: >>>>>> m1() { >>>>>> m3(); >>>>>> } >>>>>> >>>>>> m() { >>>>>> m1(); >>>>>> m2(); >>>>>> } >>>>>> >>>>>> With: m3() and m2() have profile data for the same node. The >>>>>> first profile data to be encountered during parsing is from m3() >>>>>> and profile data from m2() is ignored but profile data from m2() >>>>>> is the one that is actually the most specific and is the one >>>>>> that should be favored. >>>>>> >>>>>> When a speculative type is created, this change records the >>>>>> inline depth at which the profile point is. The inline depth is >>>>>> then propagated together with the rest of the type information. >>>>>> When new profile data is available for a node that already has a >>>>>> speculative type, the current inline depth and the inline depth >>>>>> of the current speculative type are used to decide whether the >>>>>> new data should be used to replace the existing speculative type. >>>>>> >>>>>> This change helps stabilize performance with nashorn. >>>>>> >>>>>> http://cr.openjdk.java.net/~__roland/8031754/webrev.00/ >>>>>> >>>>>> >>>>>> Roland. >> From vladimir.kozlov at oracle.com Fri Jan 31 08:33:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 31 Jan 2014 08:33:11 -0800 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EBA6A3.2010400@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> <52EACEDB.4070903@oracle.com> <52EAD696.9090406@oracle.com> <52EAD843.1030500@oracle.com> <52EADDEC.7060609@oracle.com> <52EBA6A3.2010400@oracle.com> Message-ID: <52EBD047.9020202@oracle.com> Thanks, Aleksey Looks good to me. One thing I don't see is Stable fields processing in C1. I also looked on original @Stable changes and don't see change in Interpreter too. I don't know why I did not asked about it when reviewed those changes. Please, talk to Vladimir Ivanov and file a bug if it is needed and missed. Your current fix is fine, no need additional changes for Stable. Thanks, Vladimir On 1/31/14 5:35 AM, Aleksey Shipilev wrote: > Ok, here you go: > http://cr.openjdk.java.net/~shade/8031818/webrev.02/ > > Testing: > - full JPRT cycle > - microbenchmarks with -XX:(+|-)AlwaysSafeConstructors > > Thanks, > -Aleksey > > On 01/31/2014 03:19 AM, Vladimir Kozlov wrote: >> On 1/30/14 2:54 PM, Aleksey Shipilev wrote: >>> Yes we can. >>> Do you want me to do this in this CR? >> >> Yes, please. >> >> Thanks, >> Vladimir >> >>> >>> -Aleksey. >>> >>> On 01/31/2014 02:47 AM, Vladimir Kozlov wrote: >>>> Can we simple separate stable stores to wrote_stable() with own code in >>>> do_exit() and comments? >>>> >>>> Thanks, >>>> Vladimir K >>>> >>>> On 1/30/14 2:14 PM, Aleksey Shipilev wrote: >>>>> On 01/31/2014 01:53 AM, Vladimir Kozlov wrote: >>>>>> hs-comp is closed for almost 2 weeks until SQE done all testing. Only >>>>>> ppc merge related fixes are allowed. >>>>> >>>>> Understood, no pressure. >>>>> >>>>>> You check is_initializer() for all types of fields in do_exits(). But >>>>>> is_final() is also set for @Stable field which could any methods based >>>>>> on the comment in do_put_xxx(). >>>>> >>>>> Well, that's disturbing. >>>>> >>>>> In pure spec-induced sense, the block emitting the barrier in >>>>> do_exits() >>>>> is only valid for initializers. That means, @Stable can indeed mimic >>>>> its >>>>> constructor store as the final field store. However, piggybacking on >>>>> the >>>>> same code to produce the barrier for an arbitrary method seems very >>>>> error-prone (and even contradicting the comment in do_exits() which >>>>> assumes [wrote_final == true] => [method.is_initializer() == true]). >>>>> >>>>> If @Stable writes out the value in an arbitrary method, then it >>>>> requires >>>>> release barrier on it's own. It is a pure luck finals _also_ have >>>>> MemBar_Release, while they could have more relaxed form... especially >>>>> when/if JMM 9 effort would allow this relaxation. Conflating memory >>>>> semantics for finals and @Stable seems wrong. >>>>> >>>>> Hence, I think the change is sound. It keeps @Stable semantics for >>>>> constructor stores. @Stable needs more work to emit release barriers >>>>> for >>>>> the arbitrary methods if required (why?), and I think given the failure >>>>> scenario affects only non-TSO platforms, it can be done separately. >>>>> >>>>> Thoughts? (Vladimir Ivanov, please report in!) >>>>> >>>>> -Aleksey. >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 1/30/14 12:15 PM, Aleksey Shipilev wrote: >>>>>>> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >>>>>>>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>>>>>>>> Question first: can you wait about 2 weeks when we merge ppc64 >>>>>>>>> changes? >>>>>>>> >>>>>>>> I think we can wait. I don't want to collide with PPC merge >>>>>>>> either. In >>>>>>>> fact, it would be even more convenient for us to grab PPC C2 in the >>>>>>>> experiments from the mainline. >>>>>>> >>>>>>> Are we open already? I see PPC changes had collided with my patch. >>>>>>> Even >>>>>>> if it's too early to push the patch, I merged the upstream changes >>>>>>> into >>>>>>> the updated webrev: >>>>>>> http://cr.openjdk.java.net/~shade/8031818/webrev.01/ >>>>>>> >>>>>>> Instead of introducing a new method, I rewired the predicate and >>>>>>> rearranged the comments to make its structure clear. I think >>>>>>> extracting >>>>>>> method is not required now. Also, a few typos corrected. >>>>>>> >>>>>>> Testing: >>>>>>> - full cycle JPRT >>>>>>> >>>>>>> -Aleksey. >>>>>>> >>>>> >>> > From vladimir.x.ivanov at oracle.com Fri Jan 31 09:03:36 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 31 Jan 2014 21:03:36 +0400 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EBD047.9020202@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> <52EACEDB.4070903@oracle.com> <52EAD696.9090406@oracle.com> <52EAD843.1030500@oracle.com> <52EADDEC.7060609@oracle.com> <52EBA6A3.2010400@oracle.com> <52EBD047.9020202@oracle.com> Message-ID: <52EBD768.80802@oracle.com> Vladimir K, At that moment, we targeted @Stable for C2 only. That's why there's no @Stable support in C1 & interpreter. Regarding interpreter, the only thing we discussed was verification mode for @Stable values. I filed a RFE for that [1]. Aleksey, Can you also test with -XX:+FoldStableValues -XX:+UseImplicitStableValues since you changed relevant code and run HS regression tests (and CTW preferably). Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8024042 On 1/31/14 8:33 PM, Vladimir Kozlov wrote: > Thanks, Aleksey > > Looks good to me. > > One thing I don't see is Stable fields processing in C1. I also looked > on original @Stable changes and don't see change in Interpreter too. I > don't know why I did not asked about it when reviewed those changes. > Please, talk to Vladimir Ivanov and file a bug if it is needed and > missed. Your current fix is fine, no need additional changes for Stable. > > Thanks, > Vladimir > > On 1/31/14 5:35 AM, Aleksey Shipilev wrote: >> Ok, here you go: >> http://cr.openjdk.java.net/~shade/8031818/webrev.02/ >> >> Testing: >> - full JPRT cycle >> - microbenchmarks with -XX:(+|-)AlwaysSafeConstructors >> >> Thanks, >> -Aleksey >> >> On 01/31/2014 03:19 AM, Vladimir Kozlov wrote: >>> On 1/30/14 2:54 PM, Aleksey Shipilev wrote: >>>> Yes we can. >>>> Do you want me to do this in this CR? >>> >>> Yes, please. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> -Aleksey. >>>> >>>> On 01/31/2014 02:47 AM, Vladimir Kozlov wrote: >>>>> Can we simple separate stable stores to wrote_stable() with own >>>>> code in >>>>> do_exit() and comments? >>>>> >>>>> Thanks, >>>>> Vladimir K >>>>> >>>>> On 1/30/14 2:14 PM, Aleksey Shipilev wrote: >>>>>> On 01/31/2014 01:53 AM, Vladimir Kozlov wrote: >>>>>>> hs-comp is closed for almost 2 weeks until SQE done all testing. >>>>>>> Only >>>>>>> ppc merge related fixes are allowed. >>>>>> >>>>>> Understood, no pressure. >>>>>> >>>>>>> You check is_initializer() for all types of fields in do_exits(). >>>>>>> But >>>>>>> is_final() is also set for @Stable field which could any methods >>>>>>> based >>>>>>> on the comment in do_put_xxx(). >>>>>> >>>>>> Well, that's disturbing. >>>>>> >>>>>> In pure spec-induced sense, the block emitting the barrier in >>>>>> do_exits() >>>>>> is only valid for initializers. That means, @Stable can indeed mimic >>>>>> its >>>>>> constructor store as the final field store. However, piggybacking on >>>>>> the >>>>>> same code to produce the barrier for an arbitrary method seems very >>>>>> error-prone (and even contradicting the comment in do_exits() which >>>>>> assumes [wrote_final == true] => [method.is_initializer() == true]). >>>>>> >>>>>> If @Stable writes out the value in an arbitrary method, then it >>>>>> requires >>>>>> release barrier on it's own. It is a pure luck finals _also_ have >>>>>> MemBar_Release, while they could have more relaxed form... especially >>>>>> when/if JMM 9 effort would allow this relaxation. Conflating memory >>>>>> semantics for finals and @Stable seems wrong. >>>>>> >>>>>> Hence, I think the change is sound. It keeps @Stable semantics for >>>>>> constructor stores. @Stable needs more work to emit release barriers >>>>>> for >>>>>> the arbitrary methods if required (why?), and I think given the >>>>>> failure >>>>>> scenario affects only non-TSO platforms, it can be done separately. >>>>>> >>>>>> Thoughts? (Vladimir Ivanov, please report in!) >>>>>> >>>>>> -Aleksey. >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 1/30/14 12:15 PM, Aleksey Shipilev wrote: >>>>>>>> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >>>>>>>>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>>>>>>>>> Question first: can you wait about 2 weeks when we merge ppc64 >>>>>>>>>> changes? >>>>>>>>> >>>>>>>>> I think we can wait. I don't want to collide with PPC merge >>>>>>>>> either. In >>>>>>>>> fact, it would be even more convenient for us to grab PPC C2 in >>>>>>>>> the >>>>>>>>> experiments from the mainline. >>>>>>>> >>>>>>>> Are we open already? I see PPC changes had collided with my patch. >>>>>>>> Even >>>>>>>> if it's too early to push the patch, I merged the upstream changes >>>>>>>> into >>>>>>>> the updated webrev: >>>>>>>> http://cr.openjdk.java.net/~shade/8031818/webrev.01/ >>>>>>>> >>>>>>>> Instead of introducing a new method, I rewired the predicate and >>>>>>>> rearranged the comments to make its structure clear. I think >>>>>>>> extracting >>>>>>>> method is not required now. Also, a few typos corrected. >>>>>>>> >>>>>>>> Testing: >>>>>>>> - full cycle JPRT >>>>>>>> >>>>>>>> -Aleksey. >>>>>>>> >>>>>> >>>> >> From vladimir.kozlov at oracle.com Fri Jan 31 09:51:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 31 Jan 2014 09:51:53 -0800 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EBD768.80802@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> <52EACEDB.4070903@oracle.com> <52EAD696.9090406@oracle.com> <52EAD843.1030500@oracle.com> <52EADDEC.7060609@oracle.com> <52EBA6A3.2010400@oracle.com> <52EBD047.9020202@oracle.com> <52EBD768.80802@oracle.com> Message-ID: <52EBE2B9.4040201@oracle.com> What about C1 in Tiered? Thanks, Vladimir On 1/31/14 9:03 AM, Vladimir Ivanov wrote: > Vladimir K, > > At that moment, we targeted @Stable for C2 only. That's why there's no > @Stable support in C1 & interpreter. Regarding interpreter, the only > thing we discussed was verification mode for @Stable values. I filed a > RFE for that [1]. > > Aleksey, > > Can you also test with -XX:+FoldStableValues > -XX:+UseImplicitStableValues since you changed relevant code and run HS > regression tests (and CTW preferably). > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8024042 > > On 1/31/14 8:33 PM, Vladimir Kozlov wrote: >> Thanks, Aleksey >> >> Looks good to me. >> >> One thing I don't see is Stable fields processing in C1. I also looked >> on original @Stable changes and don't see change in Interpreter too. I >> don't know why I did not asked about it when reviewed those changes. >> Please, talk to Vladimir Ivanov and file a bug if it is needed and >> missed. Your current fix is fine, no need additional changes for Stable. >> >> Thanks, >> Vladimir >> >> On 1/31/14 5:35 AM, Aleksey Shipilev wrote: >>> Ok, here you go: >>> http://cr.openjdk.java.net/~shade/8031818/webrev.02/ >>> >>> Testing: >>> - full JPRT cycle >>> - microbenchmarks with -XX:(+|-)AlwaysSafeConstructors >>> >>> Thanks, >>> -Aleksey >>> >>> On 01/31/2014 03:19 AM, Vladimir Kozlov wrote: >>>> On 1/30/14 2:54 PM, Aleksey Shipilev wrote: >>>>> Yes we can. >>>>> Do you want me to do this in this CR? >>>> >>>> Yes, please. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> -Aleksey. >>>>> >>>>> On 01/31/2014 02:47 AM, Vladimir Kozlov wrote: >>>>>> Can we simple separate stable stores to wrote_stable() with own >>>>>> code in >>>>>> do_exit() and comments? >>>>>> >>>>>> Thanks, >>>>>> Vladimir K >>>>>> >>>>>> On 1/30/14 2:14 PM, Aleksey Shipilev wrote: >>>>>>> On 01/31/2014 01:53 AM, Vladimir Kozlov wrote: >>>>>>>> hs-comp is closed for almost 2 weeks until SQE done all testing. >>>>>>>> Only >>>>>>>> ppc merge related fixes are allowed. >>>>>>> >>>>>>> Understood, no pressure. >>>>>>> >>>>>>>> You check is_initializer() for all types of fields in do_exits(). >>>>>>>> But >>>>>>>> is_final() is also set for @Stable field which could any methods >>>>>>>> based >>>>>>>> on the comment in do_put_xxx(). >>>>>>> >>>>>>> Well, that's disturbing. >>>>>>> >>>>>>> In pure spec-induced sense, the block emitting the barrier in >>>>>>> do_exits() >>>>>>> is only valid for initializers. That means, @Stable can indeed mimic >>>>>>> its >>>>>>> constructor store as the final field store. However, piggybacking on >>>>>>> the >>>>>>> same code to produce the barrier for an arbitrary method seems very >>>>>>> error-prone (and even contradicting the comment in do_exits() which >>>>>>> assumes [wrote_final == true] => [method.is_initializer() == true]). >>>>>>> >>>>>>> If @Stable writes out the value in an arbitrary method, then it >>>>>>> requires >>>>>>> release barrier on it's own. It is a pure luck finals _also_ have >>>>>>> MemBar_Release, while they could have more relaxed form... >>>>>>> especially >>>>>>> when/if JMM 9 effort would allow this relaxation. Conflating memory >>>>>>> semantics for finals and @Stable seems wrong. >>>>>>> >>>>>>> Hence, I think the change is sound. It keeps @Stable semantics for >>>>>>> constructor stores. @Stable needs more work to emit release barriers >>>>>>> for >>>>>>> the arbitrary methods if required (why?), and I think given the >>>>>>> failure >>>>>>> scenario affects only non-TSO platforms, it can be done separately. >>>>>>> >>>>>>> Thoughts? (Vladimir Ivanov, please report in!) >>>>>>> >>>>>>> -Aleksey. >>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 1/30/14 12:15 PM, Aleksey Shipilev wrote: >>>>>>>>> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >>>>>>>>>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>>>>>>>>>> Question first: can you wait about 2 weeks when we merge ppc64 >>>>>>>>>>> changes? >>>>>>>>>> >>>>>>>>>> I think we can wait. I don't want to collide with PPC merge >>>>>>>>>> either. In >>>>>>>>>> fact, it would be even more convenient for us to grab PPC C2 in >>>>>>>>>> the >>>>>>>>>> experiments from the mainline. >>>>>>>>> >>>>>>>>> Are we open already? I see PPC changes had collided with my patch. >>>>>>>>> Even >>>>>>>>> if it's too early to push the patch, I merged the upstream changes >>>>>>>>> into >>>>>>>>> the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~shade/8031818/webrev.01/ >>>>>>>>> >>>>>>>>> Instead of introducing a new method, I rewired the predicate and >>>>>>>>> rearranged the comments to make its structure clear. I think >>>>>>>>> extracting >>>>>>>>> method is not required now. Also, a few typos corrected. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> - full cycle JPRT >>>>>>>>> >>>>>>>>> -Aleksey. >>>>>>>>> >>>>>>> >>>>> >>> From vladimir.x.ivanov at oracle.com Fri Jan 31 09:59:50 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 31 Jan 2014 21:59:50 +0400 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EBE2B9.4040201@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> <52EACEDB.4070903@oracle.com> <52EAD696.9090406@oracle.com> <52EAD843.1030500@oracle.com> <52EADDEC.7060609@oracle.com> <52EBA6A3.2010400@oracle.com> <52EBD047.9020202@oracle.com> <52EBD768.80802@oracle.com> <52EBE2B9.4040201@oracle.com> Message-ID: <52EBE496.5090703@oracle.com> There's no problem if @Stable doesn't work in C1. It means C1 doesn't use this bit of information and produces less optimal code - always loads the value. Best regards, Vladimir Ivanov On 1/31/14 9:51 PM, Vladimir Kozlov wrote: > What about C1 in Tiered? > > Thanks, > Vladimir > > On 1/31/14 9:03 AM, Vladimir Ivanov wrote: >> Vladimir K, >> >> At that moment, we targeted @Stable for C2 only. That's why there's no >> @Stable support in C1 & interpreter. Regarding interpreter, the only >> thing we discussed was verification mode for @Stable values. I filed a >> RFE for that [1]. >> >> Aleksey, >> >> Can you also test with -XX:+FoldStableValues >> -XX:+UseImplicitStableValues since you changed relevant code and run HS >> regression tests (and CTW preferably). >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8024042 >> >> On 1/31/14 8:33 PM, Vladimir Kozlov wrote: >>> Thanks, Aleksey >>> >>> Looks good to me. >>> >>> One thing I don't see is Stable fields processing in C1. I also looked >>> on original @Stable changes and don't see change in Interpreter too. I >>> don't know why I did not asked about it when reviewed those changes. >>> Please, talk to Vladimir Ivanov and file a bug if it is needed and >>> missed. Your current fix is fine, no need additional changes for Stable. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/31/14 5:35 AM, Aleksey Shipilev wrote: >>>> Ok, here you go: >>>> http://cr.openjdk.java.net/~shade/8031818/webrev.02/ >>>> >>>> Testing: >>>> - full JPRT cycle >>>> - microbenchmarks with -XX:(+|-)AlwaysSafeConstructors >>>> >>>> Thanks, >>>> -Aleksey >>>> >>>> On 01/31/2014 03:19 AM, Vladimir Kozlov wrote: >>>>> On 1/30/14 2:54 PM, Aleksey Shipilev wrote: >>>>>> Yes we can. >>>>>> Do you want me to do this in this CR? >>>>> >>>>> Yes, please. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> -Aleksey. >>>>>> >>>>>> On 01/31/2014 02:47 AM, Vladimir Kozlov wrote: >>>>>>> Can we simple separate stable stores to wrote_stable() with own >>>>>>> code in >>>>>>> do_exit() and comments? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir K >>>>>>> >>>>>>> On 1/30/14 2:14 PM, Aleksey Shipilev wrote: >>>>>>>> On 01/31/2014 01:53 AM, Vladimir Kozlov wrote: >>>>>>>>> hs-comp is closed for almost 2 weeks until SQE done all testing. >>>>>>>>> Only >>>>>>>>> ppc merge related fixes are allowed. >>>>>>>> >>>>>>>> Understood, no pressure. >>>>>>>> >>>>>>>>> You check is_initializer() for all types of fields in do_exits(). >>>>>>>>> But >>>>>>>>> is_final() is also set for @Stable field which could any methods >>>>>>>>> based >>>>>>>>> on the comment in do_put_xxx(). >>>>>>>> >>>>>>>> Well, that's disturbing. >>>>>>>> >>>>>>>> In pure spec-induced sense, the block emitting the barrier in >>>>>>>> do_exits() >>>>>>>> is only valid for initializers. That means, @Stable can indeed >>>>>>>> mimic >>>>>>>> its >>>>>>>> constructor store as the final field store. However, >>>>>>>> piggybacking on >>>>>>>> the >>>>>>>> same code to produce the barrier for an arbitrary method seems very >>>>>>>> error-prone (and even contradicting the comment in do_exits() which >>>>>>>> assumes [wrote_final == true] => [method.is_initializer() == >>>>>>>> true]). >>>>>>>> >>>>>>>> If @Stable writes out the value in an arbitrary method, then it >>>>>>>> requires >>>>>>>> release barrier on it's own. It is a pure luck finals _also_ have >>>>>>>> MemBar_Release, while they could have more relaxed form... >>>>>>>> especially >>>>>>>> when/if JMM 9 effort would allow this relaxation. Conflating memory >>>>>>>> semantics for finals and @Stable seems wrong. >>>>>>>> >>>>>>>> Hence, I think the change is sound. It keeps @Stable semantics for >>>>>>>> constructor stores. @Stable needs more work to emit release >>>>>>>> barriers >>>>>>>> for >>>>>>>> the arbitrary methods if required (why?), and I think given the >>>>>>>> failure >>>>>>>> scenario affects only non-TSO platforms, it can be done separately. >>>>>>>> >>>>>>>> Thoughts? (Vladimir Ivanov, please report in!) >>>>>>>> >>>>>>>> -Aleksey. >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 1/30/14 12:15 PM, Aleksey Shipilev wrote: >>>>>>>>>> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >>>>>>>>>>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> Question first: can you wait about 2 weeks when we merge ppc64 >>>>>>>>>>>> changes? >>>>>>>>>>> >>>>>>>>>>> I think we can wait. I don't want to collide with PPC merge >>>>>>>>>>> either. In >>>>>>>>>>> fact, it would be even more convenient for us to grab PPC C2 in >>>>>>>>>>> the >>>>>>>>>>> experiments from the mainline. >>>>>>>>>> >>>>>>>>>> Are we open already? I see PPC changes had collided with my >>>>>>>>>> patch. >>>>>>>>>> Even >>>>>>>>>> if it's too early to push the patch, I merged the upstream >>>>>>>>>> changes >>>>>>>>>> into >>>>>>>>>> the updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~shade/8031818/webrev.01/ >>>>>>>>>> >>>>>>>>>> Instead of introducing a new method, I rewired the predicate and >>>>>>>>>> rearranged the comments to make its structure clear. I think >>>>>>>>>> extracting >>>>>>>>>> method is not required now. Also, a few typos corrected. >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> - full cycle JPRT >>>>>>>>>> >>>>>>>>>> -Aleksey. >>>>>>>>>> >>>>>>>> >>>>>> >>>> From vladimir.kozlov at oracle.com Fri Jan 31 10:01:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 31 Jan 2014 10:01:20 -0800 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EBE496.5090703@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> <52EACEDB.4070903@oracle.com> <52EAD696.9090406@oracle.com> <52EAD843.1030500@oracle.com> <52EADDEC.7060609@oracle.com> <52EBA6A3.2010400@oracle.com> <52EBD047.9020202@oracle.com> <52EBD768.80802@oracle.com> <52EBE2B9.4040201@oracle.com> <52EBE496.5090703@oracle.com> Message-ID: <52EBE4F0.7030804@oracle.com> Thanks! Vladimir On 1/31/14 9:59 AM, Vladimir Ivanov wrote: > There's no problem if @Stable doesn't work in C1. It means C1 doesn't > use this bit of information and produces less optimal code - always > loads the value. > > Best regards, > Vladimir Ivanov > > On 1/31/14 9:51 PM, Vladimir Kozlov wrote: >> What about C1 in Tiered? >> >> Thanks, >> Vladimir >> >> On 1/31/14 9:03 AM, Vladimir Ivanov wrote: >>> Vladimir K, >>> >>> At that moment, we targeted @Stable for C2 only. That's why there's no >>> @Stable support in C1 & interpreter. Regarding interpreter, the only >>> thing we discussed was verification mode for @Stable values. I filed a >>> RFE for that [1]. >>> >>> Aleksey, >>> >>> Can you also test with -XX:+FoldStableValues >>> -XX:+UseImplicitStableValues since you changed relevant code and run HS >>> regression tests (and CTW preferably). >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8024042 >>> >>> On 1/31/14 8:33 PM, Vladimir Kozlov wrote: >>>> Thanks, Aleksey >>>> >>>> Looks good to me. >>>> >>>> One thing I don't see is Stable fields processing in C1. I also looked >>>> on original @Stable changes and don't see change in Interpreter too. I >>>> don't know why I did not asked about it when reviewed those changes. >>>> Please, talk to Vladimir Ivanov and file a bug if it is needed and >>>> missed. Your current fix is fine, no need additional changes for >>>> Stable. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/31/14 5:35 AM, Aleksey Shipilev wrote: >>>>> Ok, here you go: >>>>> http://cr.openjdk.java.net/~shade/8031818/webrev.02/ >>>>> >>>>> Testing: >>>>> - full JPRT cycle >>>>> - microbenchmarks with -XX:(+|-)AlwaysSafeConstructors >>>>> >>>>> Thanks, >>>>> -Aleksey >>>>> >>>>> On 01/31/2014 03:19 AM, Vladimir Kozlov wrote: >>>>>> On 1/30/14 2:54 PM, Aleksey Shipilev wrote: >>>>>>> Yes we can. >>>>>>> Do you want me to do this in this CR? >>>>>> >>>>>> Yes, please. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> -Aleksey. >>>>>>> >>>>>>> On 01/31/2014 02:47 AM, Vladimir Kozlov wrote: >>>>>>>> Can we simple separate stable stores to wrote_stable() with own >>>>>>>> code in >>>>>>>> do_exit() and comments? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir K >>>>>>>> >>>>>>>> On 1/30/14 2:14 PM, Aleksey Shipilev wrote: >>>>>>>>> On 01/31/2014 01:53 AM, Vladimir Kozlov wrote: >>>>>>>>>> hs-comp is closed for almost 2 weeks until SQE done all testing. >>>>>>>>>> Only >>>>>>>>>> ppc merge related fixes are allowed. >>>>>>>>> >>>>>>>>> Understood, no pressure. >>>>>>>>> >>>>>>>>>> You check is_initializer() for all types of fields in do_exits(). >>>>>>>>>> But >>>>>>>>>> is_final() is also set for @Stable field which could any methods >>>>>>>>>> based >>>>>>>>>> on the comment in do_put_xxx(). >>>>>>>>> >>>>>>>>> Well, that's disturbing. >>>>>>>>> >>>>>>>>> In pure spec-induced sense, the block emitting the barrier in >>>>>>>>> do_exits() >>>>>>>>> is only valid for initializers. That means, @Stable can indeed >>>>>>>>> mimic >>>>>>>>> its >>>>>>>>> constructor store as the final field store. However, >>>>>>>>> piggybacking on >>>>>>>>> the >>>>>>>>> same code to produce the barrier for an arbitrary method seems >>>>>>>>> very >>>>>>>>> error-prone (and even contradicting the comment in do_exits() >>>>>>>>> which >>>>>>>>> assumes [wrote_final == true] => [method.is_initializer() == >>>>>>>>> true]). >>>>>>>>> >>>>>>>>> If @Stable writes out the value in an arbitrary method, then it >>>>>>>>> requires >>>>>>>>> release barrier on it's own. It is a pure luck finals _also_ have >>>>>>>>> MemBar_Release, while they could have more relaxed form... >>>>>>>>> especially >>>>>>>>> when/if JMM 9 effort would allow this relaxation. Conflating >>>>>>>>> memory >>>>>>>>> semantics for finals and @Stable seems wrong. >>>>>>>>> >>>>>>>>> Hence, I think the change is sound. It keeps @Stable semantics for >>>>>>>>> constructor stores. @Stable needs more work to emit release >>>>>>>>> barriers >>>>>>>>> for >>>>>>>>> the arbitrary methods if required (why?), and I think given the >>>>>>>>> failure >>>>>>>>> scenario affects only non-TSO platforms, it can be done >>>>>>>>> separately. >>>>>>>>> >>>>>>>>> Thoughts? (Vladimir Ivanov, please report in!) >>>>>>>>> >>>>>>>>> -Aleksey. >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 1/30/14 12:15 PM, Aleksey Shipilev wrote: >>>>>>>>>>> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote: >>>>>>>>>>>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>> Question first: can you wait about 2 weeks when we merge ppc64 >>>>>>>>>>>>> changes? >>>>>>>>>>>> >>>>>>>>>>>> I think we can wait. I don't want to collide with PPC merge >>>>>>>>>>>> either. In >>>>>>>>>>>> fact, it would be even more convenient for us to grab PPC C2 in >>>>>>>>>>>> the >>>>>>>>>>>> experiments from the mainline. >>>>>>>>>>> >>>>>>>>>>> Are we open already? I see PPC changes had collided with my >>>>>>>>>>> patch. >>>>>>>>>>> Even >>>>>>>>>>> if it's too early to push the patch, I merged the upstream >>>>>>>>>>> changes >>>>>>>>>>> into >>>>>>>>>>> the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~shade/8031818/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> Instead of introducing a new method, I rewired the predicate and >>>>>>>>>>> rearranged the comments to make its structure clear. I think >>>>>>>>>>> extracting >>>>>>>>>>> method is not required now. Also, a few typos corrected. >>>>>>>>>>> >>>>>>>>>>> Testing: >>>>>>>>>>> - full cycle JPRT >>>>>>>>>>> >>>>>>>>>>> -Aleksey. >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> From christian.thalinger at oracle.com Fri Jan 31 10:10:00 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 31 Jan 2014 10:10:00 -0800 Subject: RFR(M): 8027754: Enable loop optimizations for loops with MathExact inside In-Reply-To: <20140131114443.GP9323@rbackman> References: <20140123112723.GG9323@rbackman> <8BB2E6B3-81C3-48A1-B7C0-846338498C18@oracle.com> <20140130131027.GN9323@rbackman> <20140131114443.GP9323@rbackman> Message-ID: On Jan 31, 2014, at 3:44 AM, Rickard B?ckman wrote: > Igor, > > I changed the calls in library_call.cpp according to your suggestions. > The same with mathexactnode.cpp. Also did some additional cleanup there. > > Made will_overflow and can_overflow pure virtual in the base classes. > > The sub method is required as OverflowNode inherits from CmpNode. > > Updated webrev: http://cr.openjdk.java.net/~rbackman/8028997.2/ That webrev seems to not have all changes. > > Thanks > /R > > On 01/30, Igor Veresov wrote: >> Hi Rickard, >> >> In library_call.cpp: >> >> May be it?s just me but I?d get rid of bool LibraryCallKit::inline_math_overflow(bool is_unary) and reference the arguments explicitly. Otherwise it feels like too much depth to follow through when reading the code(since we keep specialized functions like inline_math_addExactI() anyway). >> >> Something like: >> bool LibraryCallKit::inline_math_addExactI(bool is_increment) { >> return inline_math_overflow(argument(0), is_increment ? intcon(1) : argument(1)); >> } >> Which will also allow you to avoid adding the IsLong enum. >> >> In mathexactnode.cpp: >> >> I?d move the AddHelper, SubHelper, MulHelper to the cpp file and reference them directly in a more verbose way. >> Something like: >> bool OverflowAddINode::will_overflow(jint v1, jint v2) const { >> return AddHelper::will_overflow(v1, v2); >> } >> Otherwise the reader has to go and find out what OverflowHelper means in a particular context. This will also reduce the amount of implementation specifics in the hpp. >> >> >> Is there a particular reason why you define will_overflow() and can_overflow() to do ShoundNotReachHere() is the base classes instead of making them pure virtual and let the compiler make sure that you define them? I guess there is an expectation that there are going to be overflow nodes that don?t redefine these methods but are there really going to be any? >> >> You also define const Type* sub(const Type* t1, const Type* t2) const as ShouldNotReachHere() and never redefine it. What are your plans for it? >> >> igor >> >> >> >> >> >> On Jan 30, 2014, at 5:10 AM, Rickard B?ckman wrote: >> >>> Igor, >>> >>> thanks for looking at this and the suggestions. I added some templates >>> to reduce the amount of code. >>> >>> Webrev: http://cr.openjdk.java.net/~rbackman/8027754.1/ >>> >>> Thanks >>> /R >>> >>> On 01/23, Igor Veresov wrote: >>>> Nice! >>>> >>>> In library_call.cpp: >>>> >>>> Could the LibaryCallKit::inline_math*() family of functions be factored with templates to shave a few lines? There is quite a lot of common code. >>>> I think the overflow idiom insertion can be something like: >>>> >>>> template >>>> void LibraryCallKit::inline_overflow(Node* arg1, Node* arg2) { >>>> Node* op = _gvn.transform(new(C) OperationNodeType(arg1, arg2)); >>>> Node* of = _gvn.transform(new(C) OverflowNodeType(arg1, arg2)); >>>> inline_math_mathExact(op, of); >>>> } >>>> >>>> In mathexactnode.cpp: >>>> You?ve already commoned many things up by introducing OverflowINode and OverflowLNode in hierarchy. >>>> But it feels like some of the code there could factored up as well using template helpers. In many cases the code looks exactly the same for ints and longs, differing only in some types. >>>> >>>> >>>> igor >>>> >>>> >>>> On Jan 23, 2014, at 3:27 AM, Rickard B?ckman wrote: >>>> >>>>> Hi all, >>>>> >>>>> this change is going to 9 (and backporting to 8u20). Can I please have >>>>> this change reviewed? >>>>> >>>>> The implementation of different j.l.Math.mathExact() didn't work very >>>>> well with different optimizations because there was one node that >>>>> generated both control and data. This change has a new implementation >>>>> where each call to j.l.Math.mathExact() generates a Overflow node and a >>>>> normal math operation node (in the integer add example: OverflowAddINode >>>>> and a AddINode). The Overflow node is responsible for generating >>>>> control. >>>>> >>>>> In the end we generate assembly like: >>>>> >>>>> mov rdx, rdi >>>>> add rdx, rsi >>>>> ... >>>>> mov rax, rdi >>>>> add rax, rsi >>>>> jo >>>>> >>>>> With one add instruction for the data and one for flags. Future >>>>> improvements could be to try to match the Overflow and the math >>>>> operation and remove one of them. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027754 >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8027754/ >>>>> >>>>> Thanks >>>>> /R >> From rickard.backman at oracle.com Fri Jan 31 10:22:10 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 31 Jan 2014 19:22:10 +0100 Subject: RFR(M): 8027754: Enable loop optimizations for loops with MathExact inside In-Reply-To: References: <20140123112723.GG9323@rbackman> <8BB2E6B3-81C3-48A1-B7C0-846338498C18@oracle.com> <20140130131027.GN9323@rbackman> <20140131114443.GP9323@rbackman> Message-ID: <20140131182210.GR9323@rbackman> Seem to have pasted the wrong link, try this one: http://cr.openjdk.java.net/~rbackman/8027754.2/ /R On 01/31, Christian Thalinger wrote: > > On Jan 31, 2014, at 3:44 AM, Rickard B?ckman wrote: > > > Igor, > > > > I changed the calls in library_call.cpp according to your suggestions. > > The same with mathexactnode.cpp. Also did some additional cleanup there. > > > > Made will_overflow and can_overflow pure virtual in the base classes. > > > > The sub method is required as OverflowNode inherits from CmpNode. > > > > Updated webrev: http://cr.openjdk.java.net/~rbackman/8028997.2/ > > That webrev seems to not have all changes. > > > > > Thanks > > /R > > > > On 01/30, Igor Veresov wrote: > >> Hi Rickard, > >> > >> In library_call.cpp: > >> > >> May be it?s just me but I?d get rid of bool LibraryCallKit::inline_math_overflow(bool is_unary) and reference the arguments explicitly. Otherwise it feels like too much depth to follow through when reading the code(since we keep specialized functions like inline_math_addExactI() anyway). > >> > >> Something like: > >> bool LibraryCallKit::inline_math_addExactI(bool is_increment) { > >> return inline_math_overflow(argument(0), is_increment ? intcon(1) : argument(1)); > >> } > >> Which will also allow you to avoid adding the IsLong enum. > >> > >> In mathexactnode.cpp: > >> > >> I?d move the AddHelper, SubHelper, MulHelper to the cpp file and reference them directly in a more verbose way. > >> Something like: > >> bool OverflowAddINode::will_overflow(jint v1, jint v2) const { > >> return AddHelper::will_overflow(v1, v2); > >> } > >> Otherwise the reader has to go and find out what OverflowHelper means in a particular context. This will also reduce the amount of implementation specifics in the hpp. > >> > >> > >> Is there a particular reason why you define will_overflow() and can_overflow() to do ShoundNotReachHere() is the base classes instead of making them pure virtual and let the compiler make sure that you define them? I guess there is an expectation that there are going to be overflow nodes that don?t redefine these methods but are there really going to be any? > >> > >> You also define const Type* sub(const Type* t1, const Type* t2) const as ShouldNotReachHere() and never redefine it. What are your plans for it? > >> > >> igor > >> > >> > >> > >> > >> > >> On Jan 30, 2014, at 5:10 AM, Rickard B?ckman wrote: > >> > >>> Igor, > >>> > >>> thanks for looking at this and the suggestions. I added some templates > >>> to reduce the amount of code. > >>> > >>> Webrev: http://cr.openjdk.java.net/~rbackman/8027754.1/ > >>> > >>> Thanks > >>> /R > >>> > >>> On 01/23, Igor Veresov wrote: > >>>> Nice! > >>>> > >>>> In library_call.cpp: > >>>> > >>>> Could the LibaryCallKit::inline_math*() family of functions be factored with templates to shave a few lines? There is quite a lot of common code. > >>>> I think the overflow idiom insertion can be something like: > >>>> > >>>> template > >>>> void LibraryCallKit::inline_overflow(Node* arg1, Node* arg2) { > >>>> Node* op = _gvn.transform(new(C) OperationNodeType(arg1, arg2)); > >>>> Node* of = _gvn.transform(new(C) OverflowNodeType(arg1, arg2)); > >>>> inline_math_mathExact(op, of); > >>>> } > >>>> > >>>> In mathexactnode.cpp: > >>>> You?ve already commoned many things up by introducing OverflowINode and OverflowLNode in hierarchy. > >>>> But it feels like some of the code there could factored up as well using template helpers. In many cases the code looks exactly the same for ints and longs, differing only in some types. > >>>> > >>>> > >>>> igor > >>>> > >>>> > >>>> On Jan 23, 2014, at 3:27 AM, Rickard B?ckman wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> this change is going to 9 (and backporting to 8u20). Can I please have > >>>>> this change reviewed? > >>>>> > >>>>> The implementation of different j.l.Math.mathExact() didn't work very > >>>>> well with different optimizations because there was one node that > >>>>> generated both control and data. This change has a new implementation > >>>>> where each call to j.l.Math.mathExact() generates a Overflow node and a > >>>>> normal math operation node (in the integer add example: OverflowAddINode > >>>>> and a AddINode). The Overflow node is responsible for generating > >>>>> control. > >>>>> > >>>>> In the end we generate assembly like: > >>>>> > >>>>> mov rdx, rdi > >>>>> add rdx, rsi > >>>>> ... > >>>>> mov rax, rdi > >>>>> add rax, rsi > >>>>> jo > >>>>> > >>>>> With one add instruction for the data and one for flags. Future > >>>>> improvements could be to try to match the Overflow and the math > >>>>> operation and remove one of them. > >>>>> > >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027754 > >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8027754/ > >>>>> > >>>>> Thanks > >>>>> /R > >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140131/8cd4e9ae/attachment.bin From vladimir.kozlov at oracle.com Fri Jan 31 11:26:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 31 Jan 2014 11:26:11 -0800 Subject: RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method In-Reply-To: References: <4337F3CC-905E-45CB-9665-C8085D42ECBF@oracle.com> <52E091D0.3010508@oracle.com> <52E09526.7030907@oracle.com> <865C3299-3E60-40D4-84AA-8EEA27ADAF99@oracle.com> <52E3191A.60604@oracle.com> <3FE1C7FB-C7E3-4032-9A40-946061F7A97D@oracle.com> <52E6D79E.2010505@oracle.com> Message-ID: <52EBF8D3.4020206@oracle.com> On 1/31/14 7:10 AM, Roland Westrelin wrote: > Hi Vladimir, > >> Yes, intuitively it looks correct but I am still not sure that we should do that. >> >> How big affect this has on score? I don't see any data. >> Can you write microbenchmark to show such behavior and benefits from these changes? > > This is a test that triggers the problem: > > http://cr.openjdk.java.net/~roland/8031754/TestInlineDepth.java > > m3() is the method that is compiled early. It doesn?t use the profile so there?s no uncommon trap and it doesn?t get a chance to run interpreted again and so update the profile. > m5() is inlined in m1() and ideally inlines C.m(). Without this patch, the profile from m3() is the one that is used for inlining in m5() and A.m() is inlined. That causes an uncommon trap when the compile code for m1() runs and so m1() is recompiled. It inlines A.m() again but this time with a slow case of doing the call. > With the change that I?m proposing, C.m() is inlined in m1(). There?s no uncommon trap. Very nice test, thanks! > Still no numbers. But with this test case it would be a simple matter of finding code that optimizes very well once C.m() is inlined to make it look very good, right? I don't think it would be "simple matter" but agree that we can get such case in some applications. > > With nashorn, one run of the richards.js benchmark was be good and the next one would be 40% slower because of a missed optimization. I believe this is one of the causes (the big one being the trap change that was reviewed recently). But for some reason, I can?t reproduce it anymore as I said in a previous mail. Can you put the code in graphKit.cpp under flag and try to run the benchmark with it on and off? In general I am comfortable to have inline_depth as additional type's attribute. But only for speculative types when it make sense. So why you keep _inline_depth in remove_speculative()? Also inline_depth is not type so you need to be careful with meet and dual code. Can you explain why you decided to use negation and min? For example, instance_id is done differently. Thanks, Vladimir > > Roland. > >> >> Thanks, >> Vladimir >> >> On 1/27/14 9:58 AM, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>>>> Thanks for looking at this, Vladimir. >>>>> >>>>>>> My wild guess is that the outermost method generally gives you the best >>>>>>> (cleanest) context information. The inner callees may have been called >>>>>>> from various callers, and so their type profiles may have been polluted >>>>>>> by other callers. >>>>>> >>>>>> They can't be polluted. We record only one speculative type. If Interpreter see a different type it will set flags and that type information will not be used. At least that is how I understand it works. That is why I am asking Roland to clarify this. >>>>> >>>>> That?s the way they work. What can happen for this (and what happens sometimes I believe): >>>>> >>>>> m1() { >>>>> m3(); >>>>> } >>>>> >>>>> m() { >>>>> m1(); >>>>> m2(); >>>>> } >>>>> >>>>> is that m3() is a heavily used method called from some other place early during the application run. Some profile is recorded. The method becomes so hot that it gets compiled with c2. So we stop profiling. Then m3() is called from m1() but because it?s already compiled we don?t record the conflicting profile. When m() is compiled we are stuck with an incorrect profile and we may miss some optimization opportunities. >>>> >>>> Okay, it makes sense. So m3() has totally unrelated to current compilation type information. But you should have some uncommon traps which will force deoptimization of m3() if type is wrong when you run m1(). On other hand deoptimization may not happen fast enough before we compile m(). I agree we can have such case. >>>> >>>> What about case when m3() calls m4() only when m3() is called from m()->m1()? In such situation m4() will collect correct type for m() compilation(). But it will be overwritten by bad type from m3(). >>> >>> But in this case, for m4() to have profile, the branch that calls m4() must have been run and the profile there should be consistent with the profile in m3()? >>> >>>>> >>>>> As Krys said, intuitively "the outermost method generally gives you the best (cleanest) context information?. It?s only a heuristic and as such, it?s certainly easy to build a test case for which this heuristic doesn?t do a good job. It does help for experiments I made with nashorn so I?d like to see it used to confirm it does help. >>>> >>>> Is it possible to detect type discrepancy in m3() and ignore (by special marking) all non-matching speculative types in m3()? >>>> >>>> You already do prefer speculative type from call's parameters over type collected for input arguments. Right? May be use that as indication that types in inlined method could be wrong. >>> >>> That doesn?t sound very robust to me. If profile is inaccurate in the callee, most likely we haven?t run the caller long enough to have profiling, right? >>> >>> Another thing that could be done is record the type that causes the deoptimization in the speculative trap. Then, presumably if we hit a trap everything runs interpreted again, profile is updated and when we recompile and we see that a trap was hit, we can compare the new type with the type that caused the deoptimization and if they differ, try optimizing again. That?s more space required in the method data. >>> >>> I found this problem when running nashorn but I don?t seem to able to hit it again for some reason. So I could withdraw this change for now. I?m concerned it will show up again sooner or later anyway and time will be needed to figure out what is happening. >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Roland. >>>>> >>>>> >>>>>> >>>>>> If you have merging case: >>>>>> >>>>>> if (x) >>>>>> m1() >>>>>> else >>>>>> m2() >>>>>> >>>>>> I don't understand why at merge point information from m2 will be more precise then from m3() called from m1(). >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> - Kris >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 22, 2014 at 7:51 PM, Vladimir Kozlov >>>>>>> > wrote: >>>>>>> >>>>>>> Roland, >>>>>>> >>>>>>> I don't see how inlining depth can define type's accuracy in general >>>>>>> case. why it can't be reverse: more accurate type from most deeply >>>>>>> inlined method? >>>>>>> >>>>>>> I thought you only have speculative type if it is the only one type >>>>>>> record in MDO. How in your case you can have different types? >>>>>>> >>>>>>> Can you be more specific? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> >>>>>>> On 1/22/14 1:42 AM, Roland Westrelin wrote: >>>>>>> >>>>>>> When a node already has a speculative type, and parsing >>>>>>> encounters extra profiling data, the new profiling data is >>>>>>> ignored. So profiling data coming from profile points closer to >>>>>>> the root of the compilation is favored which I think makes >>>>>>> sense: it's the data that is most specific to the context of >>>>>>> this compilation. >>>>>>> >>>>>>> During runs, profile data is not always entirely coherent so we >>>>>>> may hit something like this: >>>>>>> m1() { >>>>>>> m3(); >>>>>>> } >>>>>>> >>>>>>> m() { >>>>>>> m1(); >>>>>>> m2(); >>>>>>> } >>>>>>> >>>>>>> With: m3() and m2() have profile data for the same node. The >>>>>>> first profile data to be encountered during parsing is from m3() >>>>>>> and profile data from m2() is ignored but profile data from m2() >>>>>>> is the one that is actually the most specific and is the one >>>>>>> that should be favored. >>>>>>> >>>>>>> When a speculative type is created, this change records the >>>>>>> inline depth at which the profile point is. The inline depth is >>>>>>> then propagated together with the rest of the type information. >>>>>>> When new profile data is available for a node that already has a >>>>>>> speculative type, the current inline depth and the inline depth >>>>>>> of the current speculative type are used to decide whether the >>>>>>> new data should be used to replace the existing speculative type. >>>>>>> >>>>>>> This change helps stabilize performance with nashorn. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~__roland/8031754/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Roland. >>> > From igor.veresov at oracle.com Fri Jan 31 13:17:06 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 31 Jan 2014 13:17:06 -0800 Subject: RFR(M): 8027754: Enable loop optimizations for loops with MathExact inside In-Reply-To: <20140131182210.GR9323@rbackman> References: <20140123112723.GG9323@rbackman> <8BB2E6B3-81C3-48A1-B7C0-846338498C18@oracle.com> <20140130131027.GN9323@rbackman> <20140131114443.GP9323@rbackman> <20140131182210.GR9323@rbackman> Message-ID: <89E33D65-D78D-43C0-8FDC-6AB2401BF6C1@oracle.com> library_call.cpp: You forgot to remove this: 208 template 209 bool inline_math_overflow(bool is_unary); type.hpp: Come to think of it again bottom() is not really a bottom. I can?t come up with good name for it. Perhaps SIGNED ? And define it as static constant: static const TypeInt *SIGNED = INT; and static const TypeLong *SIGNED = LONG; to follow the existing convention? Otherwise looks excellent. igor On Jan 31, 2014, at 10:22 AM, Rickard B?ckman wrote: > > Seem to have pasted the wrong link, try this one: > > http://cr.openjdk.java.net/~rbackman/8027754.2/ > > /R > > On 01/31, Christian Thalinger wrote: >> >> On Jan 31, 2014, at 3:44 AM, Rickard B?ckman wrote: >> >>> Igor, >>> >>> I changed the calls in library_call.cpp according to your suggestions. >>> The same with mathexactnode.cpp. Also did some additional cleanup there. >>> >>> Made will_overflow and can_overflow pure virtual in the base classes. >>> >>> The sub method is required as OverflowNode inherits from CmpNode. >>> >>> Updated webrev: http://cr.openjdk.java.net/~rbackman/8028997.2/ >> >> That webrev seems to not have all changes. >> >>> >>> Thanks >>> /R >>> >>> On 01/30, Igor Veresov wrote: >>>> Hi Rickard, >>>> >>>> In library_call.cpp: >>>> >>>> May be it?s just me but I?d get rid of bool LibraryCallKit::inline_math_overflow(bool is_unary) and reference the arguments explicitly. Otherwise it feels like too much depth to follow through when reading the code(since we keep specialized functions like inline_math_addExactI() anyway). >>>> >>>> Something like: >>>> bool LibraryCallKit::inline_math_addExactI(bool is_increment) { >>>> return inline_math_overflow(argument(0), is_increment ? intcon(1) : argument(1)); >>>> } >>>> Which will also allow you to avoid adding the IsLong enum. >>>> >>>> In mathexactnode.cpp: >>>> >>>> I?d move the AddHelper, SubHelper, MulHelper to the cpp file and reference them directly in a more verbose way. >>>> Something like: >>>> bool OverflowAddINode::will_overflow(jint v1, jint v2) const { >>>> return AddHelper::will_overflow(v1, v2); >>>> } >>>> Otherwise the reader has to go and find out what OverflowHelper means in a particular context. This will also reduce the amount of implementation specifics in the hpp. >>>> >>>> >>>> Is there a particular reason why you define will_overflow() and can_overflow() to do ShoundNotReachHere() is the base classes instead of making them pure virtual and let the compiler make sure that you define them? I guess there is an expectation that there are going to be overflow nodes that don?t redefine these methods but are there really going to be any? >>>> >>>> You also define const Type* sub(const Type* t1, const Type* t2) const as ShouldNotReachHere() and never redefine it. What are your plans for it? >>>> >>>> igor >>>> >>>> >>>> >>>> >>>> >>>> On Jan 30, 2014, at 5:10 AM, Rickard B?ckman wrote: >>>> >>>>> Igor, >>>>> >>>>> thanks for looking at this and the suggestions. I added some templates >>>>> to reduce the amount of code. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8027754.1/ >>>>> >>>>> Thanks >>>>> /R >>>>> >>>>> On 01/23, Igor Veresov wrote: >>>>>> Nice! >>>>>> >>>>>> In library_call.cpp: >>>>>> >>>>>> Could the LibaryCallKit::inline_math*() family of functions be factored with templates to shave a few lines? There is quite a lot of common code. >>>>>> I think the overflow idiom insertion can be something like: >>>>>> >>>>>> template >>>>>> void LibraryCallKit::inline_overflow(Node* arg1, Node* arg2) { >>>>>> Node* op = _gvn.transform(new(C) OperationNodeType(arg1, arg2)); >>>>>> Node* of = _gvn.transform(new(C) OverflowNodeType(arg1, arg2)); >>>>>> inline_math_mathExact(op, of); >>>>>> } >>>>>> >>>>>> In mathexactnode.cpp: >>>>>> You?ve already commoned many things up by introducing OverflowINode and OverflowLNode in hierarchy. >>>>>> But it feels like some of the code there could factored up as well using template helpers. In many cases the code looks exactly the same for ints and longs, differing only in some types. >>>>>> >>>>>> >>>>>> igor >>>>>> >>>>>> >>>>>> On Jan 23, 2014, at 3:27 AM, Rickard B?ckman wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> this change is going to 9 (and backporting to 8u20). Can I please have >>>>>>> this change reviewed? >>>>>>> >>>>>>> The implementation of different j.l.Math.mathExact() didn't work very >>>>>>> well with different optimizations because there was one node that >>>>>>> generated both control and data. This change has a new implementation >>>>>>> where each call to j.l.Math.mathExact() generates a Overflow node and a >>>>>>> normal math operation node (in the integer add example: OverflowAddINode >>>>>>> and a AddINode). The Overflow node is responsible for generating >>>>>>> control. >>>>>>> >>>>>>> In the end we generate assembly like: >>>>>>> >>>>>>> mov rdx, rdi >>>>>>> add rdx, rsi >>>>>>> ... >>>>>>> mov rax, rdi >>>>>>> add rax, rsi >>>>>>> jo >>>>>>> >>>>>>> With one add instruction for the data and one for flags. Future >>>>>>> improvements could be to try to match the Overflow and the math >>>>>>> operation and remove one of them. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027754 >>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8027754/ >>>>>>> >>>>>>> Thanks >>>>>>> /R >>>> >> From john.r.rose at oracle.com Fri Jan 31 16:10:27 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 31 Jan 2014 16:10:27 -0800 Subject: RFR (S) 8031818: Experimental VM flag for enforcing safe object construction In-Reply-To: <52EACEDB.4070903@oracle.com> References: <52DEF8FB.3020707@oracle.com> <52DF52D3.2000906@oracle.com> <52DF7C2B.70200@oracle.com> <52DF8D2F.1030507@oracle.com> <52E016F1.80901@oracle.com> <52E0184E.2090004@oracle.com> <52EAB2FC.1080203@oracle.com> <52EAC9C9.2090105@oracle.com> <52EACEDB.4070903@oracle.com> Message-ID: On Jan 30, 2014, at 2:14 PM, Aleksey Shipilev wrote: > In pure spec-induced sense, the block emitting the barrier in do_exits() > is only valid for initializers. That means, @Stable can indeed mimic its > constructor store as the final field store. However, piggybacking on the > same code to produce the barrier for an arbitrary method seems very > error-prone (and even contradicting the comment in do_exits() which > assumes [wrote_final == true] => [method.is_initializer() == true]). Yes, that is right. I think of @Stable as a postponed (post-constructor) final, but making that real will require a write barrier. Currently, @Stable is only about "sticky" reads. I.e., if you read a non-null value, you can stick with it, as long as you like. > If @Stable writes out the value in an arbitrary method, then it requires > release barrier on it's own. It is a pure luck finals _also_ have > MemBar_Release, while they could have more relaxed form... especially > when/if JMM 9 effort would allow this relaxation. Conflating memory > semantics for finals and @Stable seems wrong. Yes. > Hence, I think the change is sound. It keeps @Stable semantics for > constructor stores. @Stable needs more work to emit release barriers for > the arbitrary methods if required (why?), and I think given the failure > scenario affects only non-TSO platforms, it can be done separately. Our uses of @Stable (inside java.lang.invoke) are limited to immutable objects or objects with acceptable races. So existing barriers should be enough. The barrier insertion done by C2 probably has no effect other than forcing the data to settle a little sooner. If we want to make it available for wider use we may have to make it more bullet-proof. Making it more like "postponed final" would require a write barrier. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140131/b821fac4/attachment.html