From kevin.walls at oracle.com Sat Apr 1 09:39:59 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Sat, 1 Apr 2017 10:39:59 +0100 Subject: Fwd: Re: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with cpu-arch=generic has problems In-Reply-To: <20170331175009.GC3631@vimes> References: <20170331175009.GC3631@vimes> Message-ID: Hi, I'd like to get a hotspot-compiler-dev code review on the change below... Many thanks, Kevin -------- Forwarded Message -------- Subject: Re: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with cpu-arch=generic has problems Date: Fri, 31 Mar 2017 18:50:09 +0100 From: Rob McKenna To: Kevin Walls CC: jdk8u-dev at openjdk.java.net Hi Kevin, These changes will need codereview. -Rob On 31/03/17 03:32, Kevin Walls wrote: > Hi, > > This is an approval request to backport into 8u: > > 8165482: java in ldoms, with cpu-arch=generic has problems > 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dfff5edc66df > > With a few routine changes this backports OK: > > src/cpu/sparc/vm/vm_version_sparc.cpp: has a different initial number of %s > in a call to jio_snprintf(), so it's not automatic, but the backport adds > one %s. > > src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: in 8u we have an > #ifndef PRODUCT which isn't in 9, not part of the change, but means the diff > won't apply automatically. > > 9 uses log(), logging in 8u uses tty->print_cr, and needs err_msg() to form > a message rather than having printf-style formatting built-in. 8u also uses > #ifndef PRODUCT also, and in some places if (PrintMiscellaneous && Verbose) > > Webrev in 8u of these changes: > http://cr.openjdk.java.net/~kevinw/8165482.8u/webrev.00/ > > Thanks > Kevin > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Mon Apr 3 06:22:57 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 3 Apr 2017 08:22:57 +0200 Subject: [10] RFR: 8171813: possible null pointer dereference defects In-Reply-To: References: Message-ID: Hi Rahul, On 31.03.2017 17:48, Rahul Raghavan wrote: > Please review following patch proposal to avoid > possible null pointer dereference warnings / errors for internal tests. > > - http://cr.openjdk.java.net/~rraghavan/8171813/webrev.00/ Please compare against NULL instead of casting to bool, i.e. use "if (compiler != NULL)" instead of "if (compiler)". In simpleThresholdPolicy.inline.hpp:80, please move the * to the type: use "AbstractCompiler* comp" instead of "AbstractCompiler *comp". Thanks, Tobias From poonam.bajaj at oracle.com Mon Apr 3 13:41:20 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Mon, 3 Apr 2017 06:41:20 -0700 (PDT) Subject: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with cpu-arch=generic has problems In-Reply-To: References: <20170331175009.GC3631@vimes> Message-ID: <9ead3ff6-00d6-4d0d-a55e-7557f73b4ec8@default> Hello Kevin, The changes backported to 8u look fine to me. Thanks, Poonam From: Kevin Walls Sent: Saturday, April 01, 2017 2:40 AM To: hotspot-compiler-dev at openjdk.java.net Subject: Fwd: Re: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with cpu-arch=generic has problems Hi, I'd like to get a hotspot-compiler-dev code review on the change below... Many thanks, Kevin -------- Forwarded Message -------- Subject: Re: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with cpu-arch=generic has problems Date: Fri, 31 Mar 2017 18:50:09 +0100 From: Rob McKenna HYPERLINK "mailto:rob.mckenna at oracle.com" To: Kevin Walls HYPERLINK "mailto:kevin.walls at oracle.com" CC: HYPERLINK "mailto:jdk8u-dev at openjdk.java.net"jdk8u-dev at openjdk.java.net Hi Kevin, These changes will need codereview. -Rob On 31/03/17 03:32, Kevin Walls wrote: > Hi, > > This is an approval request to backport into 8u: > > 8165482: java in ldoms, with cpu-arch=generic has problems > 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dfff5edc66df > > With a few routine changes this backports OK: > > src/cpu/sparc/vm/vm_version_sparc.cpp: has a different initial number of %s > in a call to jio_snprintf(), so it's not automatic, but the backport adds > one %s. > > src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: in 8u we have an > #ifndef PRODUCT which isn't in 9, not part of the change, but means the diff > won't apply automatically. > > 9 uses log(), logging in 8u uses tty->print_cr, and needs err_msg() to form > a message rather than having printf-style formatting built-in. 8u also uses > #ifndef PRODUCT also, and in some places if (PrintMiscellaneous && Verbose) > > Webrev in 8u of these changes: > http://cr.openjdk.java.net/~kevinw/8165482.8u/webrev.00/ > > Thanks > Kevin > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.walls at oracle.com Mon Apr 3 13:47:58 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 3 Apr 2017 14:47:58 +0100 Subject: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with cpu-arch=generic has problems In-Reply-To: <9ead3ff6-00d6-4d0d-a55e-7557f73b4ec8@default> References: <20170331175009.GC3631@vimes> <9ead3ff6-00d6-4d0d-a55e-7557f73b4ec8@default> Message-ID: Hi Poonam, thanks! On 03/04/2017 14:41, Poonam Parhar wrote: > > Hello Kevin, > > The changes backported to 8u look fine to me. > > Thanks, > > Poonam > > *From:*Kevin Walls > *Sent:* Saturday, April 01, 2017 2:40 AM > *To:* hotspot-compiler-dev at openjdk.java.net > *Subject:* Fwd: Re: [8u-dev] Request for approval for CR: 8165482: > java in ldoms, with cpu-arch=generic has problems > > Hi, > > I'd like to get a hotspot-compiler-dev code review on the change below... > > Many thanks, > Kevin > > -------- Forwarded Message -------- > > *Subject: * > > > > Re: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with > cpu-arch=generic has problems > > *Date: * > > > > Fri, 31 Mar 2017 18:50:09 +0100 > > *From: * > > > > Rob McKenna > > *To: * > > > > Kevin Walls > > *CC: * > > > > jdk8u-dev at openjdk.java.net > > Hi Kevin, > These changes will need codereview. > -Rob > On 31/03/17 03:32, Kevin Walls wrote: > > Hi, > > > > This is an approval request to backport into 8u: > > > > 8165482: java in ldoms, with cpu-arch=generic has problems > > 9 changeset:http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dfff5edc66df > > > > With a few routine changes this backports OK: > > > > src/cpu/sparc/vm/vm_version_sparc.cpp: has a different initial number of %s > > in a call to jio_snprintf(), so it's not automatic, but the backport adds > > one %s. > > > > src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: in 8u we have an > > #ifndef PRODUCT which isn't in 9, not part of the change, but means the diff > > won't apply automatically. > > > > 9 uses log(), logging in 8u uses tty->print_cr, and needs err_msg() to form > > a message rather than having printf-style formatting built-in. 8u also uses > > #ifndef PRODUCT also, and in some places if (PrintMiscellaneous && Verbose) > > > > Webrev in 8u of these changes: > >http://cr.openjdk.java.net/~kevinw/8165482.8u/webrev.00/ > > > > > Thanks > > Kevin > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Tue Apr 4 10:38:31 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 4 Apr 2017 12:38:31 +0200 Subject: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" Message-ID: Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8178033 http://cr.openjdk.java.net/~thartmann/8178033/webrev.00/ JDK-8076276 [1] added support for AVX512 but NativeMovRegMem::instruction_start() was not updated to recognize/skip the 4-bytes prefix for EVEX instructions. As a result, C1 crashes in NativeMovRegMem::verify() because the instruction_address() points to the EVEX prefix (0x62) which is not a valid MovRegMem instruction. Similar to the VEX prefixes, we should skip the corresponding number of bytes such that the instruction address points to the prefixed opcode (see also 'case 0x62' in Assembler::locate_operand()). Tested with replay compilation and RBT (running). Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8076276 From vladimir.kozlov at oracle.com Tue Apr 4 16:19:06 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 4 Apr 2017 09:19:06 -0700 Subject: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" In-Reply-To: References: Message-ID: <468af986-d1dd-e7b6-7d08-97ca77b3b4b9@oracle.com> I think it is better to use VM_Version::supports_evex() in assert. May be change similar assert in Assembler::locate_operand() too. Note, assembler instructions VM_Version::supports_evex() check too. CCing to Michael to review this change. Thanks, Vladimir On 4/4/17 3:38 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8178033 > http://cr.openjdk.java.net/~thartmann/8178033/webrev.00/ > > JDK-8076276 [1] added support for AVX512 but NativeMovRegMem::instruction_start() was not updated to recognize/skip the 4-bytes prefix for EVEX instructions. As a result, C1 crashes in NativeMovRegMem::verify() because the instruction_address() points to the EVEX prefix (0x62) which is not a valid MovRegMem instruction. > > Similar to the VEX prefixes, we should skip the corresponding number of bytes such that the instruction address points to the prefixed opcode (see also 'case 0x62' in Assembler::locate_operand()). > > Tested with replay compilation and RBT (running). > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8076276 > From michael.c.berg at intel.com Tue Apr 4 16:31:18 2017 From: michael.c.berg at intel.com (Berg, Michael C) Date: Tue, 4 Apr 2017 16:31:18 +0000 Subject: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" In-Reply-To: <468af986-d1dd-e7b6-7d08-97ca77b3b4b9@oracle.com> References: <468af986-d1dd-e7b6-7d08-97ca77b3b4b9@oracle.com> Message-ID: I agree to both, for the use of supports_evex() under 0x62 in locate_operand() and in instruction_start() with the new code or at least alternatively UseAVX > 2. Regards, Michael -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, April 04, 2017 9:19 AM To: hotspot-compiler-dev at openjdk.java.net Cc: Berg, Michael C Subject: Re: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" I think it is better to use VM_Version::supports_evex() in assert. May be change similar assert in Assembler::locate_operand() too. Note, assembler instructions VM_Version::supports_evex() check too. CCing to Michael to review this change. Thanks, Vladimir On 4/4/17 3:38 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8178033 > http://cr.openjdk.java.net/~thartmann/8178033/webrev.00/ > > JDK-8076276 [1] added support for AVX512 but NativeMovRegMem::instruction_start() was not updated to recognize/skip the 4-bytes prefix for EVEX instructions. As a result, C1 crashes in NativeMovRegMem::verify() because the instruction_address() points to the EVEX prefix (0x62) which is not a valid MovRegMem instruction. > > Similar to the VEX prefixes, we should skip the corresponding number of bytes such that the instruction address points to the prefixed opcode (see also 'case 0x62' in Assembler::locate_operand()). > > Tested with replay compilation and RBT (running). > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8076276 > From dean.long at oracle.com Wed Apr 5 02:58:25 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 4 Apr 2017 19:58:25 -0700 Subject: RFR(S) 8173795: AOT support in raw_exception_handler_for_return_address is broken Message-ID: <178d3848-2283-3f3a-9f7e-9c549d102533@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8173795 http://cr.openjdk.java.net/~dlong/8173795/hs.0 In raw_exception_handler_for_return_address(), AOT does not take advantage of the optimized unpack_with_exception deoptimization path. This fix removes special-purpose AOT code and instead enables both AOT and nmethod code to take the same path. dl From tobias.hartmann at oracle.com Wed Apr 5 05:25:40 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 5 Apr 2017 07:25:40 +0200 Subject: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" In-Reply-To: References: <468af986-d1dd-e7b6-7d08-97ca77b3b4b9@oracle.com> Message-ID: <6ace8cba-7732-b613-4d78-3feb96b7c495@oracle.com> Thanks Vladimir and Michael! Here's the new webrev: http://cr.openjdk.java.net/~thartmann/8178033/webrev.01/ Best regards, Tobias On 04.04.2017 18:31, Berg, Michael C wrote: > I agree to both, for the use of supports_evex() under 0x62 in locate_operand() and in instruction_start() with the new code or at least alternatively UseAVX > 2. > > Regards, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Tuesday, April 04, 2017 9:19 AM > To: hotspot-compiler-dev at openjdk.java.net > Cc: Berg, Michael C > Subject: Re: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" > > I think it is better to use VM_Version::supports_evex() in assert. May be change similar assert in Assembler::locate_operand() too. > Note, assembler instructions VM_Version::supports_evex() check too. > > CCing to Michael to review this change. > > Thanks, > Vladimir > > On 4/4/17 3:38 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8178033 >> http://cr.openjdk.java.net/~thartmann/8178033/webrev.00/ >> >> JDK-8076276 [1] added support for AVX512 but NativeMovRegMem::instruction_start() was not updated to recognize/skip the 4-bytes prefix for EVEX instructions. As a result, C1 crashes in NativeMovRegMem::verify() because the instruction_address() points to the EVEX prefix (0x62) which is not a valid MovRegMem instruction. >> >> Similar to the VEX prefixes, we should skip the corresponding number of bytes such that the instruction address points to the prefixed opcode (see also 'case 0x62' in Assembler::locate_operand()). >> >> Tested with replay compilation and RBT (running). >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8076276 >> From david.buck at oracle.com Wed Apr 5 13:37:30 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 5 Apr 2017 22:37:30 +0900 Subject: RFR(XS) [8u] 8153267: nmethod's exception cache not multi-thread safe Message-ID: <502df5b4-0313-1fc9-da3d-bef32db9a4ff@oracle.com> Hi! (explicitly CCing everyone involved with the original JDK 9 review) Please have a look at this very straightforward backport to 8u-dev of Martin's fix for 8153267. 8153267 bug report: https://bugs.openjdk.java.net/browse/JDK-8153267 8153267 JDK 9 push: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/95b8ce0f1228 8u backport webrev: http://cr.openjdk.java.net/~dbuck/8153267.0_jdk8u/ The only non-trivial difference between Martin's JDK 9 push and my backport is that I also included what remained of the change for 8143897. 8143897 was pushed before 8153267 but then completely superseded by 8153267. Specifically, I included the addition of the "index" local (as opposed to the multiple calls to count()) from 8143897 as it will keep both code lines (8 and 9) better in-sync and also makes the code more readable in my opinion. So you can think of the above webrev as a combined delta of both 8153267 and 8153267. 8143897 bug report: https://bugs.openjdk.java.net/browse/JDK-8143897 8143897 jdk 9 push: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f918c20107d9 All standard JPRT tests (default and "hotspot" testsets) run and passed. Cheers, -Buck From rwestrel at redhat.com Wed Apr 5 15:36:02 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 05 Apr 2017 17:36:02 +0200 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> Message-ID: >> http://cr.openjdk.java.net/~roland/8176506/webrev.02/ > > Looks good. Thanks, Vladimir. Anyone else for this change? Roland. From martin.doerr at sap.com Wed Apr 5 16:01:53 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 5 Apr 2017 16:01:53 +0000 Subject: RFR(XS) [8u] 8153267: nmethod's exception cache not multi-thread safe In-Reply-To: <502df5b4-0313-1fc9-da3d-bef32db9a4ff@oracle.com> References: <502df5b4-0313-1fc9-da3d-bef32db9a4ff@oracle.com> Message-ID: Hi David, thanks for backporting it. Looks good. Best regards, Martin -----Original Message----- From: David Buck [mailto:david.buck at oracle.com] Sent: Mittwoch, 5. April 2017 15:38 To: hotspot-compiler-dev at openjdk.java.net Cc: Vladimir Kozlov ; dean.long at oracle.com; aph at redhat.com; Doerr, Martin ; Jamsheed C M Subject: RFR(XS) [8u] 8153267: nmethod's exception cache not multi-thread safe Hi! (explicitly CCing everyone involved with the original JDK 9 review) Please have a look at this very straightforward backport to 8u-dev of Martin's fix for 8153267. 8153267 bug report: https://bugs.openjdk.java.net/browse/JDK-8153267 8153267 JDK 9 push: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/95b8ce0f1228 8u backport webrev: http://cr.openjdk.java.net/~dbuck/8153267.0_jdk8u/ The only non-trivial difference between Martin's JDK 9 push and my backport is that I also included what remained of the change for 8143897. 8143897 was pushed before 8153267 but then completely superseded by 8153267. Specifically, I included the addition of the "index" local (as opposed to the multiple calls to count()) from 8143897 as it will keep both code lines (8 and 9) better in-sync and also makes the code more readable in my opinion. So you can think of the above webrev as a combined delta of both 8153267 and 8153267. 8143897 bug report: https://bugs.openjdk.java.net/browse/JDK-8143897 8143897 jdk 9 push: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f918c20107d9 All standard JPRT tests (default and "hotspot" testsets) run and passed. Cheers, -Buck From vladimir.kozlov at oracle.com Wed Apr 5 16:07:21 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 5 Apr 2017 09:07:21 -0700 Subject: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" In-Reply-To: <6ace8cba-7732-b613-4d78-3feb96b7c495@oracle.com> References: <468af986-d1dd-e7b6-7d08-97ca77b3b4b9@oracle.com> <6ace8cba-7732-b613-4d78-3feb96b7c495@oracle.com> Message-ID: <30d84521-ad06-c2ae-d997-f81c32ceb123@oracle.com> Good. Thanks, Vladimir On 4/4/17 10:25 PM, Tobias Hartmann wrote: > Thanks Vladimir and Michael! > > Here's the new webrev: > http://cr.openjdk.java.net/~thartmann/8178033/webrev.01/ > > Best regards, > Tobias > > On 04.04.2017 18:31, Berg, Michael C wrote: >> I agree to both, for the use of supports_evex() under 0x62 in locate_operand() and in instruction_start() with the new code or at least alternatively UseAVX > 2. >> >> Regards, >> Michael >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Tuesday, April 04, 2017 9:19 AM >> To: hotspot-compiler-dev at openjdk.java.net >> Cc: Berg, Michael C >> Subject: Re: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" >> >> I think it is better to use VM_Version::supports_evex() in assert. May be change similar assert in Assembler::locate_operand() too. >> Note, assembler instructions VM_Version::supports_evex() check too. >> >> CCing to Michael to review this change. >> >> Thanks, >> Vladimir >> >> On 4/4/17 3:38 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8178033 >>> http://cr.openjdk.java.net/~thartmann/8178033/webrev.00/ >>> >>> JDK-8076276 [1] added support for AVX512 but NativeMovRegMem::instruction_start() was not updated to recognize/skip the 4-bytes prefix for EVEX instructions. As a result, C1 crashes in NativeMovRegMem::verify() because the instruction_address() points to the EVEX prefix (0x62) which is not a valid MovRegMem instruction. >>> >>> Similar to the VEX prefixes, we should skip the corresponding number of bytes such that the instruction address points to the prefixed opcode (see also 'case 0x62' in Assembler::locate_operand()). >>> >>> Tested with replay compilation and RBT (running). >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8076276 >>> From vladimir.kozlov at oracle.com Wed Apr 5 16:09:49 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 5 Apr 2017 09:09:49 -0700 Subject: RFR(S) 8173795: AOT support in raw_exception_handler_for_return_address is broken In-Reply-To: <178d3848-2283-3f3a-9f7e-9c549d102533@oracle.com> References: <178d3848-2283-3f3a-9f7e-9c549d102533@oracle.com> Message-ID: Looks good. Thanks, Vladimir On 4/4/17 7:58 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8173795 > > http://cr.openjdk.java.net/~dlong/8173795/hs.0 > > In raw_exception_handler_for_return_address(), AOT does not take > advantage of the optimized unpack_with_exception deoptimization path. > This fix removes special-purpose AOT code and instead enables both AOT > and nmethod code to take the same path. > > dl > From vladimir.kozlov at oracle.com Wed Apr 5 16:20:34 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 5 Apr 2017 09:20:34 -0700 Subject: RFR(XS) [8u] 8153267: nmethod's exception cache not multi-thread safe In-Reply-To: <502df5b4-0313-1fc9-da3d-bef32db9a4ff@oracle.com> References: <502df5b4-0313-1fc9-da3d-bef32db9a4ff@oracle.com> Message-ID: Looks correct to me. I would suggest for changeset to have both bugs listed to keep track of all fixes backport: 8153267: nmethod's exception cache not multi-thread safe 8143897: Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same Thanks, Vladimir On 4/5/17 6:37 AM, David Buck wrote: > Hi! > (explicitly CCing everyone involved with the original JDK 9 review) > > Please have a look at this very straightforward backport to 8u-dev of > Martin's fix for 8153267. > > 8153267 bug report: https://bugs.openjdk.java.net/browse/JDK-8153267 > > 8153267 JDK 9 push: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/95b8ce0f1228 > > 8u backport webrev: http://cr.openjdk.java.net/~dbuck/8153267.0_jdk8u/ > > The only non-trivial difference between Martin's JDK 9 push and my > backport is that I also included what remained of the change for > 8143897. 8143897 was pushed before 8153267 but then completely > superseded by 8153267. Specifically, I included the addition of the > "index" local (as opposed to the multiple calls to count()) from 8143897 > as it will keep both code lines (8 and 9) better in-sync and also makes > the code more readable in my opinion. So you can think of the above > webrev as a combined delta of both 8153267 and 8153267. > > 8143897 bug report: https://bugs.openjdk.java.net/browse/JDK-8143897 > > 8143897 jdk 9 push: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f918c20107d9 > > All standard JPRT tests (default and "hotspot" testsets) run and passed. > > Cheers, > -Buck From igor.veresov at oracle.com Wed Apr 5 17:58:40 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 5 Apr 2017 10:58:40 -0700 Subject: RFR(XXL) 8178088: Update Graal Message-ID: <24F5BCC4-BF08-4F9F-9FEC-0AFB768A8F66@oracle.com> This is a graal update (for JDK10). Some minor modifications to jaotc were necessary. Tested it with internal AOT tests and RBT. No new AOT-related failures. Webrev: http://cr.openjdk.java.net/~iveresov/8178088/webrev.00/ The list of changes in this drop: commit 898a31ae1fe3ad3241c5e4a31504bbb9697a0352 Merge: 07bdaff ab20953 Author: Tom Rodriguez Date: Tue Apr 4 21:25:26 2017 -0700 [GR-3530] Klass::_java_mirror is a handle in JDK10. commit ab209530addff5dea0e17c80a4c8bd27b465ad94 Author: Tom Rodriguez Date: Thu Feb 2 00:26:46 2017 -0800 Klass::_java_mirror is a handle in JDK10 commit 07bdaffdd2f4f8978fa26b13ef3b1e04095f20bf Merge: 8af58f2 bcf9382 Author: Tom Rodriguez Date: Tue Apr 4 14:22:43 2017 -0700 [GR-3529] SnippetTemplate dumping should be at DETAILED_LEVEL. commit 8af58f2aa1b2378114a31854129c08f2a2e2173e Merge: 4663710 536ae38 Author: Tom Rodriguez Date: Tue Apr 4 14:15:55 2017 -0700 [GR-3478] InputFilter during CE should have an early bailout. commit bcf9382e0fceec41b32968107e596ca7fe5463e5 Author: Tom Rodriguez Date: Tue Apr 4 12:37:50 2017 -0700 SnippetTemplate dumping should be at VERBOSE_LEVEL commit 536ae387ce9092f0b9be85c7ea2a874c3f49c27b Author: Tom Rodriguez Date: Sat Apr 1 20:41:07 2017 -0700 InputFilter during CE should have an early bailout commit 46637109fbe6a668b8400a66c0ad87eed8c5dee7 Merge: d699794 eddd175 Author: Doug Simon Date: Tue Apr 4 12:47:22 2017 -0700 [GR-3526] Clean up ConstantPoolSubstitutionsTests. commit eddd175307a5ee9ae7a1bcca698481d3d72ea392 Author: Doug Simon Date: Tue Apr 4 20:33:06 2017 +0200 removed legacy, commented out code commit d6997945fdf4b7ee2950551375949cd95050281c Merge: 954e82d 6e1ea3c Author: Gilles Duboscq Date: Tue Apr 4 03:25:21 2017 -0700 [GR-3488] Canonicalize IntegerLowerNodes & NegateNode early. commit 6e1ea3c45313cffbb96b933d22c0aebcdba734de Author: Gilles Duboscq Date: Mon Apr 3 14:27:40 2017 +0200 Call NegateNode.create commit 7f14d09b718562d3ca29313815b41276779b51e7 Author: Gilles Duboscq Date: Mon Apr 3 16:06:45 2017 +0200 Rename createCanonical to create commit 32c04af80b365ba748dee1b457b63a406a0e06b5 Author: Gilles Duboscq Date: Mon Apr 3 16:01:04 2017 +0200 Canonicalize IntegerLowerNodes early commit b731f4576ec1ec6762268333c1a165e3cafd289a Author: Gilles Duboscq Date: Mon Apr 3 13:48:00 2017 +0200 Separate primitive and object condition folding Make it possible to fold compares without a ConstantReflectionProvider Add NegateNode.create commit 954e82d04b567604dc88c259022a227b7f660d27 Merge: b89f51a 96ac936 Author: Josef Eisl Date: Tue Apr 4 00:15:57 2017 -0700 [GR-3247] Update to JMH 1.18. commit 96ac936029db150395b8201d40d9546735e9f2a3 Author: Josef Eisl Date: Tue Apr 4 08:42:48 2017 +0200 [ci] remove deprecated Microbench task from gate This has been replaced by mx benchmark and is already tested in mx. commit a9dfb206502858c34351afb7963c15d4996b9171 Author: Josef Eisl Date: Mon Apr 3 16:38:20 2017 +0200 [fix] findbugs should ignore code generated by JMH 1.18 commit 8f4b7c88295594bb94a638578787f06fe8dc1bf4 Author: Josef Eisl Date: Mon Apr 3 15:30:41 2017 +0200 [def] Update JMH to 1.18 commit d4f3d5978edb5a223cc08e3d0dc98d23ce67d375 Author: Josef Eisl Date: Mon Apr 3 16:21:21 2017 +0200 [fix] TraceLSRAIntervalBuildingBench can't set inter-trace hints commit b89f51afcd0e0469c6d6e6d937f993cc66cfc710 Merge: 12d7c44 42149c4 Author: Doug Simon Date: Mon Apr 3 16:02:18 2017 -0700 [GR-3440] Refine graph dumping policy. commit 42149c4939e8b6b2f41777653303aca37b380bc3 Author: Doug Simon Date: Tue Apr 4 00:35:15 2017 +0200 ignore SourceMappings for hotspot code installation if DebugNonSafepoints is false commit d28ccd8bd9c5c7eccf36b425a11477045b10f54a Author: Doug Simon Date: Mon Apr 3 15:19:10 2017 +0200 enable NodeSourcePositions for graphs being dumped commit 6e43f69bc6d1d75257274ae132a93cd540e8aa3c Author: Doug Simon Date: Mon Apr 3 15:18:37 2017 +0200 silence Truffle stub installation unless DebugStubsAndSnippets is true commit d1e92d819f39be86c3d07224fa7b644b1949f179 Author: Doug Simon Date: Mon Apr 3 15:32:54 2017 +0200 renamed *_LOG_LEVEL to *_LEVEL commit c2e1386e2108493b3b46670eea20483ada54f973 Author: Doug Simon Date: Mon Apr 3 15:30:06 2017 +0200 modified graph dumping levels according to new policy commit 12d7c449327aaac729f683f6c8e6d763fa95d46c Merge: ccb8f2d fdae32d Author: Thomas W?rthinger Date: Mon Apr 3 15:29:27 2017 -0700 [GR-3484] MoveGuardsUpwards should move guards above loops. commit ccb8f2db62f91d536d14e6055ddb30a1db649236 Merge: edc5675 f06c373 Author: Tom Rodriguez Date: Mon Apr 3 13:28:59 2017 -0700 [GR-3499] LockElimination should be more careful when replacing the monitor id. commit f06c373bae66e63e4382a35457b19d870f91c871 Author: Tom Rodriguez Date: Mon Apr 3 11:28:46 2017 -0700 LockElimination should be more careful when replacing the monitor id commit edc56752eb01eed2fa3e98beb7b91fc213aa4061 Merge: 8d56111 6471776 Author: Doug Simon Date: Mon Apr 3 10:34:44 2017 -0700 [GR-3474] Stop unit tests printing output to the console. commit 8d56111fcedc9435e0251a80e4f07d6636c968aa Merge: 4df8608 095b868 Author: David Leopoldseder Date: Mon Apr 3 09:43:11 2017 -0700 [GR-3481] Canonicalize demorgan structures. commit 4df8608c503bec656b2ca052da11c3057159c069 Merge: f4f8f65 a788a42 Author: Christian Haeubl Date: Mon Apr 3 09:07:44 2017 -0700 [GR-3493] Reduce memory footprint and improve performance of partial escape analysis. commit f4f8f652a56a9458f757894c771bab165fceca7d Merge: 87d20d7 9a66234 Author: Stefan Anzinger Date: Mon Apr 3 08:01:36 2017 -0700 [GR-3311] Preserve graal diagnostic output in CI jobs. commit 87d20d75c955b6002c00796c072b36b1fbdeac9a Merge: 1236bbd 71ca109 Author: Aleksandar Prokopec Date: Mon Apr 3 07:53:22 2017 -0700 [GR-3485] Add early canonicalizations for KlassLayoutHelperNode. commit a788a4285b26b28936b8aa7ea21cb804cca9a9e9 Author: Christian Haeubl Date: Mon Apr 3 15:56:22 2017 +0200 Remove an unnecessary method call. commit 545bb1b6de6fe8cfcdb28475b49b0ac77dd60603 Author: Christian Haeubl Date: Mon Apr 3 11:59:05 2017 +0200 Reduce escape analysis memory usage. commit 71ca1096049cc1b924312af239f4f8df83ce65a3 Author: Aleksandar Prokopec Date: Mon Apr 3 14:09:29 2017 +0200 Add missing early canonicalizations for KlassLayoutHelperNode and PiNode. commit fdae32d357bff02836bcef700bad9fa53325a66d Author: Gilles Duboscq Date: Mon Apr 3 13:50:09 2017 +0200 [GR-3484] MoveGuardsUpwards should move guards above loops. commit 095b868c9442bac28e021449c2849821c689bb9b Author: David Leopoldseder Date: Mon Apr 3 12:51:51 2017 +0200 [feature] canonicalize demorgan structures commit 1236bbd1691733995623f3f42f9ac3984300e437 Merge: 0ae1d82 16088c0 Author: Thomas W?rthinger Date: Sun Apr 2 13:04:49 2017 -0700 [GR-1883] Explicitly mark eliminated locks instead of nulling them out. commit 16088c0f4988a72a75b15f6e082ac3f27eea30b0 Author: Tom Rodriguez Date: Thu Mar 30 22:51:29 2017 -0700 Explicitly mark eliminated locks instead of nulling them out commit 0ae1d820069262ed9e79c3788c68129a8fb316b1 Merge: 23c8907 c6e0308 Author: Doug Simon Date: Sat Apr 1 08:56:08 2017 -0700 [GR-3475] EliminateRedundantInitializationPhase is not working in AOT. commit c6e0308e975ceb0c925d740b73f4dec3f28c0566 Author: Igor Veresov Date: Sat Apr 1 16:21:44 2017 +0200 Process correct constants in redundant initialization elimination phase (JDK-8177856) commit 6471776b3a224732495bcb6b441e60d3d55b324a Author: Doug Simon Date: Sat Apr 1 16:13:47 2017 +0200 disable console printing from unit tests commit 23c8907cfd1ee8bd64f7eb1843264666909acc4d Merge: 790c8a5 bf59ae1 Author: Thomas W?rthinger Date: Sat Apr 1 04:46:57 2017 -0700 [GR-3242] Fix a bug in the if fixed node deduplication that could lead to deoptimization loops. commit bf59ae1ca6f4cc28bccfa64c810024f9a39c468a Author: Thomas W?rthinger Date: Sat Apr 1 04:27:32 2017 +0200 Fix a bug in the if fixed node deduplication that could lead to deoptimization loops. commit 790c8a5187af5c966a355340398b2e75a4a9e3a7 Merge: b297777 a534a1f Author: Christian Wimmer Date: Fri Mar 31 15:57:46 2017 -0700 [GR-3470] Support GuardProxyNode in GraphDecoder. commit a534a1f888960168f391f149512f8b9fc4f54b01 Author: Christian Wimmer Date: Fri Mar 31 15:14:52 2017 -0700 Support GuardProxyNode in GraphDecoder commit b29777785b119726baf9afc2fe4f6ba2b4a38705 Merge: dc3f6af 8256166 Author: Aleksandar Prokopec Date: Fri Mar 31 07:39:17 2017 -0700 [GR-3459] Use static creation methods for PiNodes. commit 8256166f78355283f119866fb48054a7f36a4ec2 Author: Aleksandar Prokopec Date: Fri Mar 31 15:56:00 2017 +0200 Disable early PiNode canonicalization in MethodCallTargetNode. commit dc3f6af4e2e7c25b86899543451802e07103e2a3 Merge: 2de905e 650263d Author: Christian Haeubl Date: Fri Mar 31 06:00:19 2017 -0700 [GR-3458] Incorrect ObjectState array reference count during escape analysis. commit 5eae3d5f42b2a30f4ff30bd74fd0960783709b5b Author: Aleksandar Prokopec Date: Fri Mar 31 13:21:15 2017 +0200 Add static canonicalizing creation methods to PiNode, and ensure they are used. commit 650263d46311c6ea8a864c9ceb6e315afb456fdc Author: Christian Haeubl Date: Fri Mar 31 13:02:48 2017 +0200 Fixed incorrect reference count during escape analysis. commit 9a66234d2196f9faedbdfc5e2a37d7ff396d6092 Author: Stefan Anzinger Date: Fri Mar 31 09:43:21 2017 +0000 [GR-3311] Preserve graal diagnostic output in CI jobs. commit 2de905e50884b74c5decf35c13e21e7afa613287 Merge: dda8cfa dd68a0b Author: Tom Rodriguez Date: Thu Mar 30 21:29:23 2017 -0700 [GR-3405] Allow access to static fields in uninitialized classes. commit dda8cfa183c9f0c7ab1bc27b4c7c163b4e26b208 Merge: ac3581b b4787c2 Author: Christian Wimmer Date: Thu Mar 30 16:57:46 2017 -0700 [GR-3453] Make Truffle compilation more customizable. commit b4787c2b0a6fcc1a505ed50028706e3484930465 Author: Christian Wimmer Date: Thu Mar 30 16:32:02 2017 -0700 Truffle: expose profiled argument types and return type commit e16dc14e94dccf6aebaa6f8d850372ab3fad0d6a Author: Christian Wimmer Date: Wed Mar 29 19:40:34 2017 -0700 Truffle: allow customization of root method where partial evaluation starts commit 1a8dbe4728809178a3c54738b576b52842023366 Author: Christian Wimmer Date: Wed Mar 29 19:38:31 2017 -0700 Truffle: print address of compiled code in TraceTruffleCompilation commit dd68a0b9ecc4e34fa404bc6d4229fd1dce6d0891 Author: Tom Rodriguez Date: Mon Mar 27 20:01:22 2017 -0700 Allow access to static fields in uninitialized classes commit ac3581bf92394a588426879efdf9113b9b99fbd5 Merge: d34057d 385984d Author: Aleksandar Prokopec Date: Thu Mar 30 07:31:11 2017 -0700 [GR-3412] Add missing static creation methods for arithmetic nodes. commit d34057d250f2740ed820a053d77a172c4981ed00 Merge: 14702f0 7e4f019 Author: Gilles Duboscq Date: Thu Mar 30 07:15:38 2017 -0700 [GR-3314] Canonicalize `a - 1 < a` to `a != MIN`. commit 385984d7163a371e4cb43a8774a71823386ce582 Author: Aleksandar Prokopec Date: Thu Mar 30 14:17:54 2017 +0200 Suppress warning. commit 32a9b222c3c02b7f72484ae709b3c40f649ddea7 Merge: 8a7f54f 14702f0 Author: Aleksandar Prokopec Date: Thu Mar 30 14:16:52 2017 +0200 Merge branch 'master' into topic/static-node-creation commit 8a7f54f6d297455b82e4609515bcfcdd16bfe52c Author: Aleksandar Prokopec Date: Thu Mar 30 11:35:34 2017 +0200 Add early PiNode canonicalizations. commit 7e4f019ab26f5c6051e8ee5348b9d6e50bd1d1b2 Author: Gilles Duboscq Date: Wed Mar 29 16:17:43 2017 +0200 Remove some assertions commit f6c6563f0b9d1ad27bc6f079a30480018927824e Author: Gilles Duboscq Date: Wed Mar 29 16:11:35 2017 +0200 Handle `x - y < 1` similarily to `x - y < 0` commit f0e02546061ddf562b81b82a8418807941a7f0da Author: Gilles Duboscq Date: Thu Mar 23 16:59:37 2017 +0100 [GR-3314] Canonicalize `a - 1 < a` to `a != MIN` - Canonicalize `a < a + c` and related shapes to a comparison between `a` and a constant. - Move constants on the rights for < comparisons - Canonicalize `a < MAX` to `a != MAX` - Canonicalize `a < MIN + 1` to `a == MIN` commit 64fc4b180bee6adbb459186975b2c5821c7eb6f4 Author: Gilles Duboscq Date: Thu Mar 23 16:51:47 2017 +0100 Add isUnrestricted to Stamp commit da4ef6b58bc26e390458ecc346608fb78bff81aa Author: Gilles Duboscq Date: Thu Mar 23 17:36:31 2017 +0100 Fix ProbabilityDirectiveTest The test should check which branch has the expected probablity rather than assume it's the true successor. Turn some condition into an assertion in BranchProbabilityNode commit 7872a7820ae4a3df47a9a17c81af0b16e1f7cc83 Author: Gilles Duboscq Date: Thu Mar 23 16:50:19 2017 +0100 Fix BoxingEliminationTest#testLoop2 In the reference snippet, the loop is peeled and should start at 1 commit 718159296f63b687e88ef174931fa5447f582dbb Author: Gilles Duboscq Date: Thu Mar 23 16:48:46 2017 +0100 Canonicalize x + v1 == x + v2 and similar shapes commit cd0375565cf2dbcc01863499029f041c74a68623 Author: Gilles Duboscq Date: Thu Mar 23 16:44:04 2017 +0100 ConditionalEliminationTest: remove disableSimplification - Make sure tests are control-flow using writes - Improve getCanonicalGraphString: - include field access names - use sorted constants commit 14702f09468bd90e1d4f0aa3eecf4793dbdc060e Merge: 008879b a9ae3b4 Author: Christian Haeubl Date: Thu Mar 30 01:17:25 2017 -0700 [GR-3406] Faster constant folding during graph decoding. commit 008879b3a564a2ae40d5a12e753fd2adf067b00f Merge: 6e667ab cb657cb Author: Christian Haeubl Date: Thu Mar 30 01:12:09 2017 -0700 [GR-3408] Avoid Long Lived Objects during Graph Decoding. commit d21dea584c5776d1b5ad9693a765f3fd4b62b447 Author: Aleksandar Prokopec Date: Wed Mar 29 18:50:48 2017 +0200 Add early canonicalization for the LoadFieldNode. commit a9ae3b405621255ad822852970457ed061e05cb2 Author: Christian Haeubl Date: Thu Mar 23 11:24:03 2017 +0100 Faster constant folding during graph decoding. commit cb657cb0df8610e4a650d275f75e1f466c76224b Author: Christian Haeubl Date: Thu Mar 23 16:24:40 2017 +0100 Avoid default size for small collections. commit a30c17fc8891cd204b92fc5aae609aae42ee3429 Author: Christian Haeubl Date: Thu Mar 23 14:19:21 2017 +0100 Avoid unnecessary Node array allocations. commit dde8edd9b615a6cd54677ea900f912bfe1b2e875 Author: Christian Haeubl Date: Fri Mar 17 16:20:31 2017 +0100 Remove some data that would get propagated into the old gen. commit 4d2f00bf4130e2fb77509d3197723a984ba0c8ad Author: Aleksandar Prokopec Date: Wed Mar 29 15:56:54 2017 +0200 Do early canonicalization when creating the ZeroExtendNode. commit 00f32559d9a0cd5f3bdd1e502dcda06486a45da0 Author: Aleksandar Prokopec Date: Wed Mar 29 15:41:02 2017 +0200 Add early canonicalization for the ConditionalNode. commit 951ee767a7fe2ef14944ebfeba9b71cfc32d04e0 Author: Aleksandar Prokopec Date: Wed Mar 29 15:21:30 2017 +0200 Apply node plugins when parsing snippets before deoptimizing. commit 6e667ab7561d9b870ebdf2eda0e729b3ac7c1f18 Merge: acbd663 76fef80 Author: Christian Humer Date: Wed Mar 29 05:43:44 2017 -0700 [GR-164] Migrate code sharing. commit 76fef80e257dba4ce755d2b6a7d35c24138807ad Author: Christian Humer Date: Wed Mar 29 14:21:29 2017 +0200 Update overlay version. commit 0a950d451c6728ef628c586fc7fa5e02a4e13904 Author: Christian Humer Date: Wed Mar 22 18:27:39 2017 +0100 Update Truffle. commit e323ebe3be5d986b4bc6dae128700b515ed6811a Author: Christian Humer Date: Wed Mar 22 14:36:32 2017 +0100 Migration for code sharing changes. commit e2cc122b394ddca8f0ace8d91cd739784696534c Author: Aleksandar Prokopec Date: Wed Mar 29 11:59:29 2017 +0200 Add static creation method and early canonicalization for ClassGetHubNode. commit 57491b2b3db97d19c72708923646508e7f44742c Author: Aleksandar Prokopec Date: Wed Mar 29 10:41:02 2017 +0200 Factor out common shift operation canonicalization functionality. commit 31a127ba63dda060b9d7bd91ed122f250bd4180d Author: Aleksandar Prokopec Date: Tue Mar 28 15:12:59 2017 +0200 Add static creation methods for LeftShiftNode and RightShiftNode, and enable canonicalization during creation. commit acbd6634910f2ee1043460230b71b67551d6c0ee Merge: 6392034 8701ad6 Author: Aleksandar Prokopec Date: Tue Mar 28 08:38:40 2017 -0700 [GR-3384] Apply additional canonicalizations during node creation. commit 8701ad6a5e1c73c1bd9142c47a24b53c1f4e7ba9 Author: Aleksandar Prokopec Date: Tue Mar 28 16:27:50 2017 +0200 Add addWithInputs method to the GraphBuilderContext. commit d8534c53f2bcb2ffdcdd6396dc5f057fc9e01f0e Author: Aleksandar Prokopec Date: Tue Mar 28 15:05:41 2017 +0200 Add inputs of IsNullNode when building the graph. commit f56fab56d72365f63ad13e95d11f58d3bcb83051 Author: Aleksandar Prokopec Date: Mon Mar 27 17:06:33 2017 +0200 Disable some cases in AddNode and SubNode canonicalizations during creation. commit 63920343264aee98f589226670eda4821907d381 Merge: c004c38 4d15171 Author: Gilles Duboscq Date: Mon Mar 27 08:32:59 2017 -0700 [GR-2881] Add deploy-binary on post-merge. commit b14175d8781256f482d411a637fd6af9ff56e20b Author: Aleksandar Prokopec Date: Mon Mar 27 17:04:04 2017 +0200 Canonicalize additional cases in IsNullNode earlier. commit 86957922fd738906ae3b7e579e3cd9f0803b1277 Author: Aleksandar Prokopec Date: Mon Mar 27 16:21:19 2017 +0200 Improve early canonicalization for AddNode and SubNode, fix canonicalization test. commit 4d151712fd0880ba2cacd22c3a87eb7dbb615c85 Author: Gilles Duboscq Date: Mon Mar 27 16:16:17 2017 +0200 [GR-2881] Add deploy-binary on post-merge. commit 49cae45cc354b01798adeff1184dbc67c8ad3353 Author: Aleksandar Prokopec Date: Mon Mar 27 16:03:55 2017 +0200 Add canonicalization during creation for the SignExtendNode. commit 815768bf27cd6e1df96ef42b457fd0d8e21e5617 Author: Aleksandar Prokopec Date: Mon Mar 27 15:52:26 2017 +0200 Add early canonicalizations for logic nodes. commit c202ee1a6f700105fe074e59c42928308aeff2bb Author: Aleksandar Prokopec Date: Mon Mar 27 15:13:20 2017 +0200 Enable early canonicalization for DivNode, fix conditional elimination test to pass. commit c40e59f5be5ef753bf2321a70930acfd8f647ffa Author: Aleksandar Prokopec Date: Mon Mar 27 14:04:45 2017 +0200 Add canonicalization during creation to MulNode. commit 737a348b7a4ddc76c51060fb036ae6fe4d600ba1 Author: Aleksandar Prokopec Date: Mon Mar 27 10:15:56 2017 +0200 Apply additional canonicalizations during node creation. commit c004c3821e27df7f3cfd0d419e2e5dd93e39304f Merge: b7c67eb 5ad36d3 Author: Doug Simon Date: Sat Mar 25 10:57:51 2017 -0700 [GR-2951] OOM error in micro.benchmarks.ArrayListBenchmark.addNull. commit 5ad36d30608ca8ebee06cf11b2b4fe14d5b9c8b7 Author: Doug Simon Date: Sat Mar 25 16:08:36 2017 +0100 use self-clearing state for ArrayListBenchmark.addNull benchmark commit b7c67ebe071bebb2fa1a553a039a25264d8d925e Merge: b0c2c6b 65e2a40 Author: Doug Simon Date: Fri Mar 24 17:16:18 2017 -0700 [GR-3287] Remove StampFactory.forNodeIntrinsic. commit 65e2a4003d1870c2d87151f4f3bb4052af044363 Author: Doug Simon Date: Mon Mar 20 23:17:29 2017 +0100 removed StampFactory.forNodeIntrinsic commit b0c2c6be80e6a9dd3cc615b3189c1183943421f0 Merge: 2176764 1e41064 Author: Tom Rodriguez Date: Fri Mar 24 10:10:41 2017 -0700 [GR-3378] Fix bug with virtualization of arraycopy for primitive types. commit 1e41064941ae883f9d287f64862481fe3c436302 Author: Tom Rodriguez Date: Wed Mar 22 10:11:48 2017 -0700 Fix bug with virtualization of arraycopy for primitive types commit 217676413cc319a8c5f9d13423ef0eea1d500fed Merge: b2112f1 8eee9f3 Author: Doug Simon Date: Fri Mar 24 09:09:51 2017 -0700 [GR-3374] Make OptionValues immutable. commit 8eee9f3fa5a4a898b7d458aa68dbdcb9594f50d2 Author: Doug Simon Date: Fri Mar 24 15:27:10 2017 +0100 expose API for searching OptionDescriptors for a fuzzy match against an option name commit 3df741532a24ab9b61a53eca991c227fea2ec44f Author: Doug Simon Date: Fri Mar 24 14:06:22 2017 +0100 added ModifiableOptionValues commit b2112f1ee03759bcbc0a576d27dda571b7a838ac Merge: 76ca9b9 f5cbb13 Author: Doug Simon Date: Thu Mar 23 15:22:25 2017 -0700 [GR-3003] Make OptionValues updates more thread safe. commit 76ca9b9224329f1a6b047b765d8d0e1ea5d58f06 Merge: e9c533e 4ac9ae6 Author: Doug Simon Date: Thu Mar 23 14:54:32 2017 -0700 [GR-3309] Refine compilation retry. commit e9c533e542bcda4c65298dab1d72627d2529c533 Merge: b5daaff 5e4dcfd Author: Vojin Jovanovic Date: Thu Mar 23 10:38:33 2017 -0700 [GR-3356] Write files when roundEnv.processingOver in ServiceProviderProcessor. commit 5e4dcfd11f9a3494486d4381080c2247db3594a5 Author: Vojin Jovanovic Date: Thu Mar 23 17:43:08 2017 +0100 [fix] write files when roundEnv.processingOver in ServiceProviderProcessor commit b5daafff28b74e34ee92e9a8c69278ae8f33b131 Merge: f304652 a1745ed Author: Doug Simon Date: Thu Mar 23 06:24:59 2017 -0700 [GR-3361] Minor dumping fixes. commit f5cbb13838ca8c86e60ac8c52c798b4d3f0c0688 Author: Doug Simon Date: Tue Mar 21 22:02:33 2017 +0100 allow mutability of OptionValues commit aaf856f989a9040fd837800186502d964170c198 Author: Doug Simon Date: Tue Mar 21 09:58:42 2017 +0100 made OptionValues extensible for a subclass that implements a mutable option set commit fd80a1a29eb7e061736593de206f9e1a0531c07c Author: Doug Simon Date: Tue Mar 21 09:57:23 2017 +0100 fixed instances of "the the" in comments commit a1745edd8f717d3a477bcf28d4816e0462d1dc9e Author: Tom Rodriguez Date: Wed Mar 22 23:04:04 2017 -0700 Minor dumping fixes commit f30465268bc2133ee55d70418ad5af3b0ee1af5d Merge: c1920c3 5d729c9 Author: Doug Simon Date: Wed Mar 22 14:34:18 2017 -0700 [GR-3357] Remove UseTrivialPrefixes flag. commit 5d729c9cb1ba0230788fce921cce1b9209b8bc6e Author: Doug Simon Date: Wed Mar 22 20:58:16 2017 +0100 remove UseTrivialPrefixes option and guard CompileGraalWithC1Only code properly commit c1920c310c5d97c2d82a50ed68c4560a02f80df3 Merge: 7821a08 4cc99e7 Author: Vojin Jovanovic Date: Wed Mar 22 06:27:40 2017 -0700 [GR-3292] Update Truffle version. commit 7821a08d45468500dd663f745ab1771de5371694 Merge: b555abe b30ecfd Author: Christian Haeubl Date: Wed Mar 22 01:15:23 2017 -0700 [GR-3295] Performance and Footprint Optimizations in the GraphDecoder. commit b555abe16fd92be3c0eaf4ca475ba335ba2253f1 Merge: 4b0879e 54ac726 Author: Gilles Duboscq Date: Tue Mar 21 10:47:48 2017 -0700 [GR-3262] Yet another killCFG implementation. commit 4ac9ae620a722a9d77ff3fa0fe3f1bdab2e51f9f Author: Doug Simon Date: Tue Mar 21 13:55:59 2017 +0100 don't retry compilation is Dump option is explicitly set; improve documentation and name of CrashAt related code commit 4b0879edface6c3c5fb220cfee7a52d95700f0ab Merge: 09b8add 9b21118 Author: Doug Simon Date: Tue Mar 21 07:55:28 2017 -0700 [GR-3315] Fix prefix for GraalCompileOnly option. commit 9b21118361917a189933959a2c5005c9d3375e10 Author: Doug Simon Date: Tue Mar 21 13:57:25 2017 +0100 shorten prefix for GraalCompileOnly matching to "org.graalvm" commit 54ac72679384ff8698eabcbd077dd2d5c335f123 Author: Gilles Duboscq Date: Tue Mar 21 12:27:43 2017 +0100 Split up killCFGInner commit 4cc99e72c9db82e34918f90593a17222e9f3ad11 Author: Vojin Jovanovic Date: Tue Mar 21 12:26:47 2017 +0100 Update Truffle version commit 79c46aa0131cacf73058c7884b3d05cff19efa6b Author: Gilles Duboscq Date: Tue Mar 21 12:20:01 2017 +0100 Remove unnecessary changes commit b30ecfde331cca71422c6aa8cac91cee275fd1fb Author: Christian Haeubl Date: Mon Mar 20 16:57:10 2017 +0100 Moved PEMethodScope fields into the PEGraphDecoder. commit fa0c61ad8cecc7e5ef80236085a5996f197494cb Author: Christian Haeubl Date: Mon Mar 20 15:25:49 2017 +0100 Moved graph from MethodScope to GraphDecoder. commit 49f44e762ecaadfd127d9656c54bc522e81bb4d0 Author: Christian Haeubl Date: Mon Mar 13 09:58:58 2017 +0100 Add the number of fixed nodes to the encoded graph. commit 9ca829439e396f2d95466937eff7d330b15ed57b Author: Christian Haeubl Date: Fri Mar 10 11:57:55 2017 +0100 Use EconomicMap when encoding graphs. commit 1154130c6e3f1c2b8b0dc2831fbad6a6bd624ade Author: Christian Haeubl Date: Wed Mar 8 17:33:33 2017 +0100 Faster canonicalization of fixed nodes. commit 09b8adde268a99409a2efe419a2af347a7121b70 Merge: 50cdd01 fa3b423 Author: Christian Haeubl Date: Tue Mar 21 03:30:51 2017 -0700 [GR-3296] Better Performance for some Infrastructure Methods. commit fa3b423675c6a7af130defaf37293f3571d60383 Author: Christian Haeubl Date: Thu Mar 16 15:15:47 2017 +0100 NodeBitMap optimizations and fixes. commit b3e8c77ab728bcad9227abf42302b20055ca0589 Author: Christian Haeubl Date: Tue Mar 14 14:42:30 2017 +0100 Improved Node.equals performance. commit 32c2cd5b28b4cce96fd66ba6f76db30aa5a93c08 Author: Christian Haeubl Date: Tue Mar 7 12:09:27 2017 +0100 Small optimizations when constant folding annotated fields/arrays. commit 4e83b1d28ccfef5b18f486b183967928158a14ec Author: Christian Haeubl Date: Wed Mar 8 17:30:20 2017 +0100 Faster way of handling usages when replacing a node. commit 50cdd01472af68b78953fa48fc81f166e84dc3bf Merge: 553f905 0f6b5ea Author: Stefan Anzinger Date: Tue Mar 21 02:25:11 2017 -0700 [GR-3244] Load all non simm13 constants for further OP3 ops. commit 553f905dad4c9ca732d03fab20eee3827f8c152b Merge: bf3f6b1 1b921a3 Author: Christian Wimmer Date: Mon Mar 20 18:00:08 2017 -0700 [GR-3305] Add missing bounds check for block boundaries in BytecodeParser. commit 1b921a358d096404888448d0cb83fdbe906117d9 Author: Christian Wimmer Date: Mon Mar 20 15:17:16 2017 -0700 Add missing bounds check for block boundaries in BytecodeParser commit bf3f6b19dd457255f69eb2b30d3939bd6157d1c7 Merge: 0bc6561 10c4ee2 Author: Doug Simon Date: Mon Mar 20 12:40:20 2017 -0700 [GR-3276] Retry failed compilation with extra graph dumping enabled. commit 7616c4cf19b4fc1c5ef53b60aac07fff7ea6ee5e Author: Gilles Duboscq Date: Mon Mar 20 18:06:31 2017 +0100 Remove hard limit mode for `IterativeNodeWorkList` commit bd721090b57a0adc877debcedd118e7e66e71d8e Author: Gilles Duboscq Date: Mon Mar 20 18:02:42 2017 +0100 Remove old killCFG commit ff831acbf339c662b6a79f65b138d27b33a7fa67 Author: Gilles Duboscq Date: Fri Mar 17 20:09:54 2017 +0100 [GR-3262] Yet another killCFG implementation. commit 10c4ee254bf99e53540404021676187d50b65e38 Author: Doug Simon Date: Fri Mar 17 18:11:25 2017 +0100 added support for retrying a failed compilation with extra logging enabled commit b949e08e4cdf4cee6838233f24885641608e2059 Author: Christian Haeubl Date: Thu Mar 2 15:40:23 2017 +0100 Avoid allocating unnecessary CanonicalizerTool objects during graph decoding. commit 43ab0979c79114c0d0d7d9186c852bf7c3721ddc Author: Christian Haeubl Date: Wed Mar 1 17:18:05 2017 +0100 Allocate fewer floating nodes. commit 5e33185a8c68ff361689b8811ef4b6a3c36bfcdf Author: Christian Haeubl Date: Wed Mar 1 17:16:05 2017 +0100 Avoid unnecessary instanceof checks during graph decoding. commit 0bc65616191a47ae25035f3cddbb7a20458fe743 Merge: 532c573 8ccf234 Author: Doug Simon Date: Mon Mar 20 03:22:25 2017 -0700 [GR-3293] Do not rely on caching in jdk.vm.ci.services.Services. commit 8ccf23425ae09918c16470c13658fa617450de0c Author: Doug Simon Date: Sun Mar 19 18:04:06 2017 +0100 do not rely on caching in jdk.vm.ci.services.Services commit 0f6b5eaedd82f2ac30744ea85165f7eca4d0b631 Author: Stefan Anzinger Date: Wed Mar 15 17:35:26 2017 +0000 [GR-3244] Load all non simm13 constants for further OP3 ops. From michael.c.berg at intel.com Wed Apr 5 19:43:12 2017 From: michael.c.berg at intel.com (Berg, Michael C) Date: Wed, 5 Apr 2017 19:43:12 +0000 Subject: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" In-Reply-To: <6ace8cba-7732-b613-4d78-3feb96b7c495@oracle.com> References: <468af986-d1dd-e7b6-7d08-97ca77b3b4b9@oracle.com> <6ace8cba-7732-b613-4d78-3feb96b7c495@oracle.com> Message-ID: Looks good. Thanks Tobias. Regards, Michael -----Original Message----- From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] Sent: Tuesday, April 04, 2017 10:26 PM To: Berg, Michael C ; Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net Subject: Re: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" Thanks Vladimir and Michael! Here's the new webrev: http://cr.openjdk.java.net/~thartmann/8178033/webrev.01/ Best regards, Tobias On 04.04.2017 18:31, Berg, Michael C wrote: > I agree to both, for the use of supports_evex() under 0x62 in locate_operand() and in instruction_start() with the new code or at least alternatively UseAVX > 2. > > Regards, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Tuesday, April 04, 2017 9:19 AM > To: hotspot-compiler-dev at openjdk.java.net > Cc: Berg, Michael C > Subject: Re: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" > > I think it is better to use VM_Version::supports_evex() in assert. May be change similar assert in Assembler::locate_operand() too. > Note, assembler instructions VM_Version::supports_evex() check too. > > CCing to Michael to review this change. > > Thanks, > Vladimir > > On 4/4/17 3:38 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8178033 >> http://cr.openjdk.java.net/~thartmann/8178033/webrev.00/ >> >> JDK-8076276 [1] added support for AVX512 but NativeMovRegMem::instruction_start() was not updated to recognize/skip the 4-bytes prefix for EVEX instructions. As a result, C1 crashes in NativeMovRegMem::verify() because the instruction_address() points to the EVEX prefix (0x62) which is not a valid MovRegMem instruction. >> >> Similar to the VEX prefixes, we should skip the corresponding number of bytes such that the instruction address points to the prefixed opcode (see also 'case 0x62' in Assembler::locate_operand()). >> >> Tested with replay compilation and RBT (running). >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8076276 >> From michael.c.berg at intel.com Wed Apr 5 19:43:49 2017 From: michael.c.berg at intel.com (Berg, Michael C) Date: Wed, 5 Apr 2017 19:43:49 +0000 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> Message-ID: Looks ok to me too Roland. Regards, Michael -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin Sent: Wednesday, April 05, 2017 8:36 AM To: hotspot-compiler-dev at openjdk.java.net Subject: Re: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash >> http://cr.openjdk.java.net/~roland/8176506/webrev.02/ > > Looks good. Thanks, Vladimir. Anyone else for this change? Roland. From dean.long at oracle.com Wed Apr 5 20:05:52 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 5 Apr 2017 13:05:52 -0700 Subject: RFR(S) 8173795: AOT support in raw_exception_handler_for_return_address is broken In-Reply-To: References: <178d3848-2283-3f3a-9f7e-9c549d102533@oracle.com> Message-ID: <65626745-c2c4-8acb-6f24-b60b29473f99@oracle.com> Thanks Vladimir. dl On 4/5/17 9:09 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 4/4/17 7:58 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8173795 >> >> http://cr.openjdk.java.net/~dlong/8173795/hs.0 >> >> In raw_exception_handler_for_return_address(), AOT does not take >> advantage of the optimized unpack_with_exception deoptimization path. >> This fix removes special-purpose AOT code and instead enables both AOT >> and nmethod code to take the same path. >> >> dl >> From tobias.hartmann at oracle.com Thu Apr 6 06:08:46 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 6 Apr 2017 08:08:46 +0200 Subject: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" In-Reply-To: <30d84521-ad06-c2ae-d997-f81c32ceb123@oracle.com> References: <468af986-d1dd-e7b6-7d08-97ca77b3b4b9@oracle.com> <6ace8cba-7732-b613-4d78-3feb96b7c495@oracle.com> <30d84521-ad06-c2ae-d997-f81c32ceb123@oracle.com> Message-ID: <118da2a6-aaef-b3e0-39ba-3f6e67dd2ca7@oracle.com> Thanks, Vladimir! Best regards, Tobias On 05.04.2017 18:07, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 4/4/17 10:25 PM, Tobias Hartmann wrote: >> Thanks Vladimir and Michael! >> >> Here's the new webrev: >> http://cr.openjdk.java.net/~thartmann/8178033/webrev.01/ >> >> Best regards, >> Tobias >> >> On 04.04.2017 18:31, Berg, Michael C wrote: >>> I agree to both, for the use of supports_evex() under 0x62 in locate_operand() and in instruction_start() with the new code or at least alternatively UseAVX > 2. >>> >>> Regards, >>> Michael >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Tuesday, April 04, 2017 9:19 AM >>> To: hotspot-compiler-dev at openjdk.java.net >>> Cc: Berg, Michael C >>> Subject: Re: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" >>> >>> I think it is better to use VM_Version::supports_evex() in assert. May be change similar assert in Assembler::locate_operand() too. >>> Note, assembler instructions VM_Version::supports_evex() check too. >>> >>> CCing to Michael to review this change. >>> >>> Thanks, >>> Vladimir >>> >>> On 4/4/17 3:38 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> https://bugs.openjdk.java.net/browse/JDK-8178033 >>>> http://cr.openjdk.java.net/~thartmann/8178033/webrev.00/ >>>> >>>> JDK-8076276 [1] added support for AVX512 but NativeMovRegMem::instruction_start() was not updated to recognize/skip the 4-bytes prefix for EVEX instructions. As a result, C1 crashes in NativeMovRegMem::verify() because the instruction_address() points to the EVEX prefix (0x62) which is not a valid MovRegMem instruction. >>>> >>>> Similar to the VEX prefixes, we should skip the corresponding number of bytes such that the instruction address points to the prefixed opcode (see also 'case 0x62' in Assembler::locate_operand()). >>>> >>>> Tested with replay compilation and RBT (running). >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8076276 >>>> From tobias.hartmann at oracle.com Thu Apr 6 06:09:01 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 6 Apr 2017 08:09:01 +0200 Subject: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" In-Reply-To: References: <468af986-d1dd-e7b6-7d08-97ca77b3b4b9@oracle.com> <6ace8cba-7732-b613-4d78-3feb96b7c495@oracle.com> Message-ID: <6310107e-07d8-91cf-53ae-aeb7578c230f@oracle.com> Thanks, Michael! Best regards, Tobias On 05.04.2017 21:43, Berg, Michael C wrote: > Looks good. > Thanks Tobias. > > Regards, > Michael > > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Tuesday, April 04, 2017 10:26 PM > To: Berg, Michael C ; Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" > > Thanks Vladimir and Michael! > > Here's the new webrev: > http://cr.openjdk.java.net/~thartmann/8178033/webrev.01/ > > Best regards, > Tobias > > On 04.04.2017 18:31, Berg, Michael C wrote: >> I agree to both, for the use of supports_evex() under 0x62 in locate_operand() and in instruction_start() with the new code or at least alternatively UseAVX > 2. >> >> Regards, >> Michael >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Tuesday, April 04, 2017 9:19 AM >> To: hotspot-compiler-dev at openjdk.java.net >> Cc: Berg, Michael C >> Subject: Re: [9] RFR(S): 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" >> >> I think it is better to use VM_Version::supports_evex() in assert. May be change similar assert in Assembler::locate_operand() too. >> Note, assembler instructions VM_Version::supports_evex() check too. >> >> CCing to Michael to review this change. >> >> Thanks, >> Vladimir >> >> On 4/4/17 3:38 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8178033 >>> http://cr.openjdk.java.net/~thartmann/8178033/webrev.00/ >>> >>> JDK-8076276 [1] added support for AVX512 but NativeMovRegMem::instruction_start() was not updated to recognize/skip the 4-bytes prefix for EVEX instructions. As a result, C1 crashes in NativeMovRegMem::verify() because the instruction_address() points to the EVEX prefix (0x62) which is not a valid MovRegMem instruction. >>> >>> Similar to the VEX prefixes, we should skip the corresponding number of bytes such that the instruction address points to the prefixed opcode (see also 'case 0x62' in Assembler::locate_operand()). >>> >>> Tested with replay compilation and RBT (running). >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8076276 >>> From rahul.v.raghavan at oracle.com Thu Apr 6 06:27:21 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 5 Apr 2017 23:27:21 -0700 (PDT) Subject: [10] RFR: 8171813: possible null pointer dereference defects In-Reply-To: References: Message-ID: <0f0ef598-49a6-443b-a1ab-502335167a98@default> Hi, Thank you Tobias for the review comments. Sorry for my oversight and yes now included the required changes. - http://cr.openjdk.java.net/~rraghavan/8171813/webrev.01/ Believe the changes are now okay to be committed. Thanks, Rahul > -----Original Message----- > From: Tobias Hartmann > Sent: Monday, April 03, 2017 11:53 AM > To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net; Vladimir Kozlov; Zoltan Majo > Subject: Re: [10] RFR: 8171813: possible null pointer dereference defects > > Hi Rahul, > > On 31.03.2017 17:48, Rahul Raghavan wrote: > > Please review following patch proposal to avoid > > possible null pointer dereference warnings / errors for internal tests. > > > > - http://cr.openjdk.java.net/~rraghavan/8171813/webrev.00/ > > Please compare against NULL instead of casting to bool, i.e. use "if (compiler != NULL)" instead of "if (compiler)". > > In simpleThresholdPolicy.inline.hpp:80, please move the * to the type: use "AbstractCompiler* comp" instead of "AbstractCompiler > *comp". > > Thanks, > Tobias From tobias.hartmann at oracle.com Thu Apr 6 06:31:53 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 6 Apr 2017 08:31:53 +0200 Subject: [10] RFR: 8171813: possible null pointer dereference defects In-Reply-To: <0f0ef598-49a6-443b-a1ab-502335167a98@default> References: <0f0ef598-49a6-443b-a1ab-502335167a98@default> Message-ID: <299d57f7-093b-23ac-ff5c-1539950c2f2c@oracle.com> Hi Rahul, On 06.04.2017 08:27, Rahul Raghavan wrote: > - http://cr.openjdk.java.net/~rraghavan/8171813/webrev.01/ Looks good to me! Thanks, Tobias From rahul.v.raghavan at oracle.com Thu Apr 6 06:39:30 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 5 Apr 2017 23:39:30 -0700 (PDT) Subject: [10] RFR: 8171813: possible null pointer dereference defects In-Reply-To: <299d57f7-093b-23ac-ff5c-1539950c2f2c@oracle.com> References: <0f0ef598-49a6-443b-a1ab-502335167a98@default> <299d57f7-093b-23ac-ff5c-1539950c2f2c@oracle.com> Message-ID: <02fd4062-87ab-4adb-8206-cd4d98673281@default> Thank you Tobias. > -----Original Message----- > From: Tobias Hartmann > Sent: Thursday, April 06, 2017 12:02 PM > To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net > Subject: Re: [10] RFR: 8171813: possible null pointer dereference defects > > Hi Rahul, > > On 06.04.2017 08:27, Rahul Raghavan wrote: > > - http://cr.openjdk.java.net/~rraghavan/8171813/webrev.01/ > > Looks good to me! > > Thanks, > Tobias From vladimir.kozlov at oracle.com Thu Apr 6 18:20:55 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Apr 2017 11:20:55 -0700 Subject: RFR(XXL) 8178088: Update Graal In-Reply-To: <24F5BCC4-BF08-4F9F-9FEC-0AFB768A8F66@oracle.com> References: <24F5BCC4-BF08-4F9F-9FEC-0AFB768A8F66@oracle.com> Message-ID: <48383555-a5a2-2478-b1ae-46d1ec7708d7@oracle.com> Looks good. Thank you for doing merge. Vladimir On 4/5/17 10:58 AM, Igor Veresov wrote: > This is a graal update (for JDK10). Some minor modifications to jaotc were necessary. Tested it with internal AOT tests and RBT. No new AOT-related failures. > > Webrev: http://cr.openjdk.java.net/~iveresov/8178088/webrev.00/ > > The list of changes in this drop: > > commit 898a31ae1fe3ad3241c5e4a31504bbb9697a0352 > Merge: 07bdaff ab20953 > Author: Tom Rodriguez > Date: Tue Apr 4 21:25:26 2017 -0700 > > [GR-3530] Klass::_java_mirror is a handle in JDK10. > > commit ab209530addff5dea0e17c80a4c8bd27b465ad94 > Author: Tom Rodriguez > Date: Thu Feb 2 00:26:46 2017 -0800 > > Klass::_java_mirror is a handle in JDK10 > > commit 07bdaffdd2f4f8978fa26b13ef3b1e04095f20bf > Merge: 8af58f2 bcf9382 > Author: Tom Rodriguez > Date: Tue Apr 4 14:22:43 2017 -0700 > > [GR-3529] SnippetTemplate dumping should be at DETAILED_LEVEL. > > commit 8af58f2aa1b2378114a31854129c08f2a2e2173e > Merge: 4663710 536ae38 > Author: Tom Rodriguez > Date: Tue Apr 4 14:15:55 2017 -0700 > > [GR-3478] InputFilter during CE should have an early bailout. > > commit bcf9382e0fceec41b32968107e596ca7fe5463e5 > Author: Tom Rodriguez > Date: Tue Apr 4 12:37:50 2017 -0700 > > SnippetTemplate dumping should be at VERBOSE_LEVEL > > commit 536ae387ce9092f0b9be85c7ea2a874c3f49c27b > Author: Tom Rodriguez > Date: Sat Apr 1 20:41:07 2017 -0700 > > InputFilter during CE should have an early bailout > > commit 46637109fbe6a668b8400a66c0ad87eed8c5dee7 > Merge: d699794 eddd175 > Author: Doug Simon > Date: Tue Apr 4 12:47:22 2017 -0700 > > [GR-3526] Clean up ConstantPoolSubstitutionsTests. > > commit eddd175307a5ee9ae7a1bcca698481d3d72ea392 > Author: Doug Simon > Date: Tue Apr 4 20:33:06 2017 +0200 > > removed legacy, commented out code > > commit d6997945fdf4b7ee2950551375949cd95050281c > Merge: 954e82d 6e1ea3c > Author: Gilles Duboscq > Date: Tue Apr 4 03:25:21 2017 -0700 > > [GR-3488] Canonicalize IntegerLowerNodes & NegateNode early. > > commit 6e1ea3c45313cffbb96b933d22c0aebcdba734de > Author: Gilles Duboscq > Date: Mon Apr 3 14:27:40 2017 +0200 > > Call NegateNode.create > > commit 7f14d09b718562d3ca29313815b41276779b51e7 > Author: Gilles Duboscq > Date: Mon Apr 3 16:06:45 2017 +0200 > > Rename createCanonical to create > > commit 32c04af80b365ba748dee1b457b63a406a0e06b5 > Author: Gilles Duboscq > Date: Mon Apr 3 16:01:04 2017 +0200 > > Canonicalize IntegerLowerNodes early > > commit b731f4576ec1ec6762268333c1a165e3cafd289a > Author: Gilles Duboscq > Date: Mon Apr 3 13:48:00 2017 +0200 > > Separate primitive and object condition folding > > Make it possible to fold compares without a ConstantReflectionProvider > Add NegateNode.create > > commit 954e82d04b567604dc88c259022a227b7f660d27 > Merge: b89f51a 96ac936 > Author: Josef Eisl > Date: Tue Apr 4 00:15:57 2017 -0700 > > [GR-3247] Update to JMH 1.18. > > commit 96ac936029db150395b8201d40d9546735e9f2a3 > Author: Josef Eisl > Date: Tue Apr 4 08:42:48 2017 +0200 > > [ci] remove deprecated Microbench task from gate > > This has been replaced by mx benchmark and is already tested in mx. > > commit a9dfb206502858c34351afb7963c15d4996b9171 > Author: Josef Eisl > Date: Mon Apr 3 16:38:20 2017 +0200 > > [fix] findbugs should ignore code generated by JMH 1.18 > > commit 8f4b7c88295594bb94a638578787f06fe8dc1bf4 > Author: Josef Eisl > Date: Mon Apr 3 15:30:41 2017 +0200 > > [def] Update JMH to 1.18 > > commit d4f3d5978edb5a223cc08e3d0dc98d23ce67d375 > Author: Josef Eisl > Date: Mon Apr 3 16:21:21 2017 +0200 > > [fix] TraceLSRAIntervalBuildingBench can't set inter-trace hints > > commit b89f51afcd0e0469c6d6e6d937f993cc66cfc710 > Merge: 12d7c44 42149c4 > Author: Doug Simon > Date: Mon Apr 3 16:02:18 2017 -0700 > > [GR-3440] Refine graph dumping policy. > > commit 42149c4939e8b6b2f41777653303aca37b380bc3 > Author: Doug Simon > Date: Tue Apr 4 00:35:15 2017 +0200 > > ignore SourceMappings for hotspot code installation if DebugNonSafepoints is false > > commit d28ccd8bd9c5c7eccf36b425a11477045b10f54a > Author: Doug Simon > Date: Mon Apr 3 15:19:10 2017 +0200 > > enable NodeSourcePositions for graphs being dumped > > commit 6e43f69bc6d1d75257274ae132a93cd540e8aa3c > Author: Doug Simon > Date: Mon Apr 3 15:18:37 2017 +0200 > > silence Truffle stub installation unless DebugStubsAndSnippets is true > > commit d1e92d819f39be86c3d07224fa7b644b1949f179 > Author: Doug Simon > Date: Mon Apr 3 15:32:54 2017 +0200 > > renamed *_LOG_LEVEL to *_LEVEL > > commit c2e1386e2108493b3b46670eea20483ada54f973 > Author: Doug Simon > Date: Mon Apr 3 15:30:06 2017 +0200 > > modified graph dumping levels according to new policy > > commit 12d7c449327aaac729f683f6c8e6d763fa95d46c > Merge: ccb8f2d fdae32d > Author: Thomas W?rthinger > Date: Mon Apr 3 15:29:27 2017 -0700 > > [GR-3484] MoveGuardsUpwards should move guards above loops. > > commit ccb8f2db62f91d536d14e6055ddb30a1db649236 > Merge: edc5675 f06c373 > Author: Tom Rodriguez > Date: Mon Apr 3 13:28:59 2017 -0700 > > [GR-3499] LockElimination should be more careful when replacing the monitor id. > > commit f06c373bae66e63e4382a35457b19d870f91c871 > Author: Tom Rodriguez > Date: Mon Apr 3 11:28:46 2017 -0700 > > LockElimination should be more careful when replacing the monitor id > > commit edc56752eb01eed2fa3e98beb7b91fc213aa4061 > Merge: 8d56111 6471776 > Author: Doug Simon > Date: Mon Apr 3 10:34:44 2017 -0700 > > [GR-3474] Stop unit tests printing output to the console. > > commit 8d56111fcedc9435e0251a80e4f07d6636c968aa > Merge: 4df8608 095b868 > Author: David Leopoldseder > Date: Mon Apr 3 09:43:11 2017 -0700 > > [GR-3481] Canonicalize demorgan structures. > > commit 4df8608c503bec656b2ca052da11c3057159c069 > Merge: f4f8f65 a788a42 > Author: Christian Haeubl > Date: Mon Apr 3 09:07:44 2017 -0700 > > [GR-3493] Reduce memory footprint and improve performance of partial escape analysis. > > commit f4f8f652a56a9458f757894c771bab165fceca7d > Merge: 87d20d7 9a66234 > Author: Stefan Anzinger > Date: Mon Apr 3 08:01:36 2017 -0700 > > [GR-3311] Preserve graal diagnostic output in CI jobs. > > commit 87d20d75c955b6002c00796c072b36b1fbdeac9a > Merge: 1236bbd 71ca109 > Author: Aleksandar Prokopec > Date: Mon Apr 3 07:53:22 2017 -0700 > > [GR-3485] Add early canonicalizations for KlassLayoutHelperNode. > > commit a788a4285b26b28936b8aa7ea21cb804cca9a9e9 > Author: Christian Haeubl > Date: Mon Apr 3 15:56:22 2017 +0200 > > Remove an unnecessary method call. > > commit 545bb1b6de6fe8cfcdb28475b49b0ac77dd60603 > Author: Christian Haeubl > Date: Mon Apr 3 11:59:05 2017 +0200 > > Reduce escape analysis memory usage. > > commit 71ca1096049cc1b924312af239f4f8df83ce65a3 > Author: Aleksandar Prokopec > Date: Mon Apr 3 14:09:29 2017 +0200 > > Add missing early canonicalizations for KlassLayoutHelperNode and PiNode. > > commit fdae32d357bff02836bcef700bad9fa53325a66d > Author: Gilles Duboscq > Date: Mon Apr 3 13:50:09 2017 +0200 > > [GR-3484] MoveGuardsUpwards should move guards above loops. > > commit 095b868c9442bac28e021449c2849821c689bb9b > Author: David Leopoldseder > Date: Mon Apr 3 12:51:51 2017 +0200 > > [feature] canonicalize demorgan structures > > commit 1236bbd1691733995623f3f42f9ac3984300e437 > Merge: 0ae1d82 16088c0 > Author: Thomas W?rthinger > Date: Sun Apr 2 13:04:49 2017 -0700 > > [GR-1883] Explicitly mark eliminated locks instead of nulling them out. > > commit 16088c0f4988a72a75b15f6e082ac3f27eea30b0 > Author: Tom Rodriguez > Date: Thu Mar 30 22:51:29 2017 -0700 > > Explicitly mark eliminated locks instead of nulling them out > > commit 0ae1d820069262ed9e79c3788c68129a8fb316b1 > Merge: 23c8907 c6e0308 > Author: Doug Simon > Date: Sat Apr 1 08:56:08 2017 -0700 > > [GR-3475] EliminateRedundantInitializationPhase is not working in AOT. > > commit c6e0308e975ceb0c925d740b73f4dec3f28c0566 > Author: Igor Veresov > Date: Sat Apr 1 16:21:44 2017 +0200 > > Process correct constants in redundant initialization elimination phase (JDK-8177856) > > commit 6471776b3a224732495bcb6b441e60d3d55b324a > Author: Doug Simon > Date: Sat Apr 1 16:13:47 2017 +0200 > > disable console printing from unit tests > > commit 23c8907cfd1ee8bd64f7eb1843264666909acc4d > Merge: 790c8a5 bf59ae1 > Author: Thomas W?rthinger > Date: Sat Apr 1 04:46:57 2017 -0700 > > [GR-3242] Fix a bug in the if fixed node deduplication that could lead to deoptimization loops. > > commit bf59ae1ca6f4cc28bccfa64c810024f9a39c468a > Author: Thomas W?rthinger > Date: Sat Apr 1 04:27:32 2017 +0200 > > Fix a bug in the if fixed node deduplication that could lead to deoptimization loops. > > commit 790c8a5187af5c966a355340398b2e75a4a9e3a7 > Merge: b297777 a534a1f > Author: Christian Wimmer > Date: Fri Mar 31 15:57:46 2017 -0700 > > [GR-3470] Support GuardProxyNode in GraphDecoder. > > commit a534a1f888960168f391f149512f8b9fc4f54b01 > Author: Christian Wimmer > Date: Fri Mar 31 15:14:52 2017 -0700 > > Support GuardProxyNode in GraphDecoder > > commit b29777785b119726baf9afc2fe4f6ba2b4a38705 > Merge: dc3f6af 8256166 > Author: Aleksandar Prokopec > Date: Fri Mar 31 07:39:17 2017 -0700 > > [GR-3459] Use static creation methods for PiNodes. > > commit 8256166f78355283f119866fb48054a7f36a4ec2 > Author: Aleksandar Prokopec > Date: Fri Mar 31 15:56:00 2017 +0200 > > Disable early PiNode canonicalization in MethodCallTargetNode. > > commit dc3f6af4e2e7c25b86899543451802e07103e2a3 > Merge: 2de905e 650263d > Author: Christian Haeubl > Date: Fri Mar 31 06:00:19 2017 -0700 > > [GR-3458] Incorrect ObjectState array reference count during escape analysis. > > commit 5eae3d5f42b2a30f4ff30bd74fd0960783709b5b > Author: Aleksandar Prokopec > Date: Fri Mar 31 13:21:15 2017 +0200 > > Add static canonicalizing creation methods to PiNode, and ensure they are used. > > commit 650263d46311c6ea8a864c9ceb6e315afb456fdc > Author: Christian Haeubl > Date: Fri Mar 31 13:02:48 2017 +0200 > > Fixed incorrect reference count during escape analysis. > > commit 9a66234d2196f9faedbdfc5e2a37d7ff396d6092 > Author: Stefan Anzinger > Date: Fri Mar 31 09:43:21 2017 +0000 > > [GR-3311] Preserve graal diagnostic output in CI jobs. > > commit 2de905e50884b74c5decf35c13e21e7afa613287 > Merge: dda8cfa dd68a0b > Author: Tom Rodriguez > Date: Thu Mar 30 21:29:23 2017 -0700 > > [GR-3405] Allow access to static fields in uninitialized classes. > > commit dda8cfa183c9f0c7ab1bc27b4c7c163b4e26b208 > Merge: ac3581b b4787c2 > Author: Christian Wimmer > Date: Thu Mar 30 16:57:46 2017 -0700 > > [GR-3453] Make Truffle compilation more customizable. > > commit b4787c2b0a6fcc1a505ed50028706e3484930465 > Author: Christian Wimmer > Date: Thu Mar 30 16:32:02 2017 -0700 > > Truffle: expose profiled argument types and return type > > commit e16dc14e94dccf6aebaa6f8d850372ab3fad0d6a > Author: Christian Wimmer > Date: Wed Mar 29 19:40:34 2017 -0700 > > Truffle: allow customization of root method where partial evaluation starts > > commit 1a8dbe4728809178a3c54738b576b52842023366 > Author: Christian Wimmer > Date: Wed Mar 29 19:38:31 2017 -0700 > > Truffle: print address of compiled code in TraceTruffleCompilation > > commit dd68a0b9ecc4e34fa404bc6d4229fd1dce6d0891 > Author: Tom Rodriguez > Date: Mon Mar 27 20:01:22 2017 -0700 > > Allow access to static fields in uninitialized classes > > commit ac3581bf92394a588426879efdf9113b9b99fbd5 > Merge: d34057d 385984d > Author: Aleksandar Prokopec > Date: Thu Mar 30 07:31:11 2017 -0700 > > [GR-3412] Add missing static creation methods for arithmetic nodes. > > commit d34057d250f2740ed820a053d77a172c4981ed00 > Merge: 14702f0 7e4f019 > Author: Gilles Duboscq > Date: Thu Mar 30 07:15:38 2017 -0700 > > [GR-3314] Canonicalize `a - 1 < a` to `a != MIN`. > > commit 385984d7163a371e4cb43a8774a71823386ce582 > Author: Aleksandar Prokopec > Date: Thu Mar 30 14:17:54 2017 +0200 > > Suppress warning. > > commit 32a9b222c3c02b7f72484ae709b3c40f649ddea7 > Merge: 8a7f54f 14702f0 > Author: Aleksandar Prokopec > Date: Thu Mar 30 14:16:52 2017 +0200 > > Merge branch 'master' into topic/static-node-creation > > commit 8a7f54f6d297455b82e4609515bcfcdd16bfe52c > Author: Aleksandar Prokopec > Date: Thu Mar 30 11:35:34 2017 +0200 > > Add early PiNode canonicalizations. > > commit 7e4f019ab26f5c6051e8ee5348b9d6e50bd1d1b2 > Author: Gilles Duboscq > Date: Wed Mar 29 16:17:43 2017 +0200 > > Remove some assertions > > commit f6c6563f0b9d1ad27bc6f079a30480018927824e > Author: Gilles Duboscq > Date: Wed Mar 29 16:11:35 2017 +0200 > > Handle `x - y < 1` similarily to `x - y < 0` > > commit f0e02546061ddf562b81b82a8418807941a7f0da > Author: Gilles Duboscq > Date: Thu Mar 23 16:59:37 2017 +0100 > > [GR-3314] Canonicalize `a - 1 < a` to `a != MIN` > > - Canonicalize `a < a + c` and related shapes to a comparison between `a` and > a constant. > - Move constants on the rights for < comparisons > - Canonicalize `a < MAX` to `a != MAX` > - Canonicalize `a < MIN + 1` to `a == MIN` > > commit 64fc4b180bee6adbb459186975b2c5821c7eb6f4 > Author: Gilles Duboscq > Date: Thu Mar 23 16:51:47 2017 +0100 > > Add isUnrestricted to Stamp > > commit da4ef6b58bc26e390458ecc346608fb78bff81aa > Author: Gilles Duboscq > Date: Thu Mar 23 17:36:31 2017 +0100 > > Fix ProbabilityDirectiveTest > > The test should check which branch has the expected probablity rather > than assume it's the true successor. > Turn some condition into an assertion in BranchProbabilityNode > > commit 7872a7820ae4a3df47a9a17c81af0b16e1f7cc83 > Author: Gilles Duboscq > Date: Thu Mar 23 16:50:19 2017 +0100 > > Fix BoxingEliminationTest#testLoop2 > > In the reference snippet, the loop is peeled and should start at 1 > > commit 718159296f63b687e88ef174931fa5447f582dbb > Author: Gilles Duboscq > Date: Thu Mar 23 16:48:46 2017 +0100 > > Canonicalize x + v1 == x + v2 and similar shapes > > commit cd0375565cf2dbcc01863499029f041c74a68623 > Author: Gilles Duboscq > Date: Thu Mar 23 16:44:04 2017 +0100 > > ConditionalEliminationTest: remove disableSimplification > > - Make sure tests are control-flow using writes > - Improve getCanonicalGraphString: > - include field access names > - use sorted constants > > commit 14702f09468bd90e1d4f0aa3eecf4793dbdc060e > Merge: 008879b a9ae3b4 > Author: Christian Haeubl > Date: Thu Mar 30 01:17:25 2017 -0700 > > [GR-3406] Faster constant folding during graph decoding. > > commit 008879b3a564a2ae40d5a12e753fd2adf067b00f > Merge: 6e667ab cb657cb > Author: Christian Haeubl > Date: Thu Mar 30 01:12:09 2017 -0700 > > [GR-3408] Avoid Long Lived Objects during Graph Decoding. > > commit d21dea584c5776d1b5ad9693a765f3fd4b62b447 > Author: Aleksandar Prokopec > Date: Wed Mar 29 18:50:48 2017 +0200 > > Add early canonicalization for the LoadFieldNode. > > commit a9ae3b405621255ad822852970457ed061e05cb2 > Author: Christian Haeubl > Date: Thu Mar 23 11:24:03 2017 +0100 > > Faster constant folding during graph decoding. > > commit cb657cb0df8610e4a650d275f75e1f466c76224b > Author: Christian Haeubl > Date: Thu Mar 23 16:24:40 2017 +0100 > > Avoid default size for small collections. > > commit a30c17fc8891cd204b92fc5aae609aae42ee3429 > Author: Christian Haeubl > Date: Thu Mar 23 14:19:21 2017 +0100 > > Avoid unnecessary Node array allocations. > > commit dde8edd9b615a6cd54677ea900f912bfe1b2e875 > Author: Christian Haeubl > Date: Fri Mar 17 16:20:31 2017 +0100 > > Remove some data that would get propagated into the old gen. > > commit 4d2f00bf4130e2fb77509d3197723a984ba0c8ad > Author: Aleksandar Prokopec > Date: Wed Mar 29 15:56:54 2017 +0200 > > Do early canonicalization when creating the ZeroExtendNode. > > commit 00f32559d9a0cd5f3bdd1e502dcda06486a45da0 > Author: Aleksandar Prokopec > Date: Wed Mar 29 15:41:02 2017 +0200 > > Add early canonicalization for the ConditionalNode. > > commit 951ee767a7fe2ef14944ebfeba9b71cfc32d04e0 > Author: Aleksandar Prokopec > Date: Wed Mar 29 15:21:30 2017 +0200 > > Apply node plugins when parsing snippets before deoptimizing. > > commit 6e667ab7561d9b870ebdf2eda0e729b3ac7c1f18 > Merge: acbd663 76fef80 > Author: Christian Humer > Date: Wed Mar 29 05:43:44 2017 -0700 > > [GR-164] Migrate code sharing. > > commit 76fef80e257dba4ce755d2b6a7d35c24138807ad > Author: Christian Humer > Date: Wed Mar 29 14:21:29 2017 +0200 > > Update overlay version. > > commit 0a950d451c6728ef628c586fc7fa5e02a4e13904 > Author: Christian Humer > Date: Wed Mar 22 18:27:39 2017 +0100 > > Update Truffle. > > commit e323ebe3be5d986b4bc6dae128700b515ed6811a > Author: Christian Humer > Date: Wed Mar 22 14:36:32 2017 +0100 > > Migration for code sharing changes. > > commit e2cc122b394ddca8f0ace8d91cd739784696534c > Author: Aleksandar Prokopec > Date: Wed Mar 29 11:59:29 2017 +0200 > > Add static creation method and early canonicalization for ClassGetHubNode. > > commit 57491b2b3db97d19c72708923646508e7f44742c > Author: Aleksandar Prokopec > Date: Wed Mar 29 10:41:02 2017 +0200 > > Factor out common shift operation canonicalization functionality. > > commit 31a127ba63dda060b9d7bd91ed122f250bd4180d > Author: Aleksandar Prokopec > Date: Tue Mar 28 15:12:59 2017 +0200 > > Add static creation methods for LeftShiftNode and RightShiftNode, and enable canonicalization during creation. > > commit acbd6634910f2ee1043460230b71b67551d6c0ee > Merge: 6392034 8701ad6 > Author: Aleksandar Prokopec > Date: Tue Mar 28 08:38:40 2017 -0700 > > [GR-3384] Apply additional canonicalizations during node creation. > > commit 8701ad6a5e1c73c1bd9142c47a24b53c1f4e7ba9 > Author: Aleksandar Prokopec > Date: Tue Mar 28 16:27:50 2017 +0200 > > Add addWithInputs method to the GraphBuilderContext. > > commit d8534c53f2bcb2ffdcdd6396dc5f057fc9e01f0e > Author: Aleksandar Prokopec > Date: Tue Mar 28 15:05:41 2017 +0200 > > Add inputs of IsNullNode when building the graph. > > commit f56fab56d72365f63ad13e95d11f58d3bcb83051 > Author: Aleksandar Prokopec > Date: Mon Mar 27 17:06:33 2017 +0200 > > Disable some cases in AddNode and SubNode canonicalizations during creation. > > commit 63920343264aee98f589226670eda4821907d381 > Merge: c004c38 4d15171 > Author: Gilles Duboscq > Date: Mon Mar 27 08:32:59 2017 -0700 > > [GR-2881] Add deploy-binary on post-merge. > > commit b14175d8781256f482d411a637fd6af9ff56e20b > Author: Aleksandar Prokopec > Date: Mon Mar 27 17:04:04 2017 +0200 > > Canonicalize additional cases in IsNullNode earlier. > > commit 86957922fd738906ae3b7e579e3cd9f0803b1277 > Author: Aleksandar Prokopec > Date: Mon Mar 27 16:21:19 2017 +0200 > > Improve early canonicalization for AddNode and SubNode, fix canonicalization test. > > commit 4d151712fd0880ba2cacd22c3a87eb7dbb615c85 > Author: Gilles Duboscq > Date: Mon Mar 27 16:16:17 2017 +0200 > > [GR-2881] Add deploy-binary on post-merge. > > commit 49cae45cc354b01798adeff1184dbc67c8ad3353 > Author: Aleksandar Prokopec > Date: Mon Mar 27 16:03:55 2017 +0200 > > Add canonicalization during creation for the SignExtendNode. > > commit 815768bf27cd6e1df96ef42b457fd0d8e21e5617 > Author: Aleksandar Prokopec > Date: Mon Mar 27 15:52:26 2017 +0200 > > Add early canonicalizations for logic nodes. > > commit c202ee1a6f700105fe074e59c42928308aeff2bb > Author: Aleksandar Prokopec > Date: Mon Mar 27 15:13:20 2017 +0200 > > Enable early canonicalization for DivNode, fix conditional elimination test to pass. > > commit c40e59f5be5ef753bf2321a70930acfd8f647ffa > Author: Aleksandar Prokopec > Date: Mon Mar 27 14:04:45 2017 +0200 > > Add canonicalization during creation to MulNode. > > commit 737a348b7a4ddc76c51060fb036ae6fe4d600ba1 > Author: Aleksandar Prokopec > Date: Mon Mar 27 10:15:56 2017 +0200 > > Apply additional canonicalizations during node creation. > > commit c004c3821e27df7f3cfd0d419e2e5dd93e39304f > Merge: b7c67eb 5ad36d3 > Author: Doug Simon > Date: Sat Mar 25 10:57:51 2017 -0700 > > [GR-2951] OOM error in micro.benchmarks.ArrayListBenchmark.addNull. > > commit 5ad36d30608ca8ebee06cf11b2b4fe14d5b9c8b7 > Author: Doug Simon > Date: Sat Mar 25 16:08:36 2017 +0100 > > use self-clearing state for ArrayListBenchmark.addNull benchmark > > commit b7c67ebe071bebb2fa1a553a039a25264d8d925e > Merge: b0c2c6b 65e2a40 > Author: Doug Simon > Date: Fri Mar 24 17:16:18 2017 -0700 > > [GR-3287] Remove StampFactory.forNodeIntrinsic. > > commit 65e2a4003d1870c2d87151f4f3bb4052af044363 > Author: Doug Simon > Date: Mon Mar 20 23:17:29 2017 +0100 > > removed StampFactory.forNodeIntrinsic > > commit b0c2c6be80e6a9dd3cc615b3189c1183943421f0 > Merge: 2176764 1e41064 > Author: Tom Rodriguez > Date: Fri Mar 24 10:10:41 2017 -0700 > > [GR-3378] Fix bug with virtualization of arraycopy for primitive types. > > commit 1e41064941ae883f9d287f64862481fe3c436302 > Author: Tom Rodriguez > Date: Wed Mar 22 10:11:48 2017 -0700 > > Fix bug with virtualization of arraycopy for primitive types > > commit 217676413cc319a8c5f9d13423ef0eea1d500fed > Merge: b2112f1 8eee9f3 > Author: Doug Simon > Date: Fri Mar 24 09:09:51 2017 -0700 > > [GR-3374] Make OptionValues immutable. > > commit 8eee9f3fa5a4a898b7d458aa68dbdcb9594f50d2 > Author: Doug Simon > Date: Fri Mar 24 15:27:10 2017 +0100 > > expose API for searching OptionDescriptors for a fuzzy match against an option name > > commit 3df741532a24ab9b61a53eca991c227fea2ec44f > Author: Doug Simon > Date: Fri Mar 24 14:06:22 2017 +0100 > > added ModifiableOptionValues > > commit b2112f1ee03759bcbc0a576d27dda571b7a838ac > Merge: 76ca9b9 f5cbb13 > Author: Doug Simon > Date: Thu Mar 23 15:22:25 2017 -0700 > > [GR-3003] Make OptionValues updates more thread safe. > > commit 76ca9b9224329f1a6b047b765d8d0e1ea5d58f06 > Merge: e9c533e 4ac9ae6 > Author: Doug Simon > Date: Thu Mar 23 14:54:32 2017 -0700 > > [GR-3309] Refine compilation retry. > > commit e9c533e542bcda4c65298dab1d72627d2529c533 > Merge: b5daaff 5e4dcfd > Author: Vojin Jovanovic > Date: Thu Mar 23 10:38:33 2017 -0700 > > [GR-3356] Write files when roundEnv.processingOver in ServiceProviderProcessor. > > commit 5e4dcfd11f9a3494486d4381080c2247db3594a5 > Author: Vojin Jovanovic > Date: Thu Mar 23 17:43:08 2017 +0100 > > [fix] write files when roundEnv.processingOver in ServiceProviderProcessor > > commit b5daafff28b74e34ee92e9a8c69278ae8f33b131 > Merge: f304652 a1745ed > Author: Doug Simon > Date: Thu Mar 23 06:24:59 2017 -0700 > > [GR-3361] Minor dumping fixes. > > commit f5cbb13838ca8c86e60ac8c52c798b4d3f0c0688 > Author: Doug Simon > Date: Tue Mar 21 22:02:33 2017 +0100 > > allow mutability of OptionValues > > commit aaf856f989a9040fd837800186502d964170c198 > Author: Doug Simon > Date: Tue Mar 21 09:58:42 2017 +0100 > > made OptionValues extensible for a subclass that implements a mutable option set > > commit fd80a1a29eb7e061736593de206f9e1a0531c07c > Author: Doug Simon > Date: Tue Mar 21 09:57:23 2017 +0100 > > fixed instances of "the the" in comments > > commit a1745edd8f717d3a477bcf28d4816e0462d1dc9e > Author: Tom Rodriguez > Date: Wed Mar 22 23:04:04 2017 -0700 > > Minor dumping fixes > > commit f30465268bc2133ee55d70418ad5af3b0ee1af5d > Merge: c1920c3 5d729c9 > Author: Doug Simon > Date: Wed Mar 22 14:34:18 2017 -0700 > > [GR-3357] Remove UseTrivialPrefixes flag. > > commit 5d729c9cb1ba0230788fce921cce1b9209b8bc6e > Author: Doug Simon > Date: Wed Mar 22 20:58:16 2017 +0100 > > remove UseTrivialPrefixes option and guard CompileGraalWithC1Only code properly > > commit c1920c310c5d97c2d82a50ed68c4560a02f80df3 > Merge: 7821a08 4cc99e7 > Author: Vojin Jovanovic > Date: Wed Mar 22 06:27:40 2017 -0700 > > [GR-3292] Update Truffle version. > > commit 7821a08d45468500dd663f745ab1771de5371694 > Merge: b555abe b30ecfd > Author: Christian Haeubl > Date: Wed Mar 22 01:15:23 2017 -0700 > > [GR-3295] Performance and Footprint Optimizations in the GraphDecoder. > > commit b555abe16fd92be3c0eaf4ca475ba335ba2253f1 > Merge: 4b0879e 54ac726 > Author: Gilles Duboscq > Date: Tue Mar 21 10:47:48 2017 -0700 > > [GR-3262] Yet another killCFG implementation. > > commit 4ac9ae620a722a9d77ff3fa0fe3f1bdab2e51f9f > Author: Doug Simon > Date: Tue Mar 21 13:55:59 2017 +0100 > > don't retry compilation is Dump option is explicitly set; improve documentation and name of CrashAt related code > > commit 4b0879edface6c3c5fb220cfee7a52d95700f0ab > Merge: 09b8add 9b21118 > Author: Doug Simon > Date: Tue Mar 21 07:55:28 2017 -0700 > > [GR-3315] Fix prefix for GraalCompileOnly option. > > commit 9b21118361917a189933959a2c5005c9d3375e10 > Author: Doug Simon > Date: Tue Mar 21 13:57:25 2017 +0100 > > shorten prefix for GraalCompileOnly matching to "org.graalvm" > > commit 54ac72679384ff8698eabcbd077dd2d5c335f123 > Author: Gilles Duboscq > Date: Tue Mar 21 12:27:43 2017 +0100 > > Split up killCFGInner > > commit 4cc99e72c9db82e34918f90593a17222e9f3ad11 > Author: Vojin Jovanovic > Date: Tue Mar 21 12:26:47 2017 +0100 > > Update Truffle version > > commit 79c46aa0131cacf73058c7884b3d05cff19efa6b > Author: Gilles Duboscq > Date: Tue Mar 21 12:20:01 2017 +0100 > > Remove unnecessary changes > > commit b30ecfde331cca71422c6aa8cac91cee275fd1fb > Author: Christian Haeubl > Date: Mon Mar 20 16:57:10 2017 +0100 > > Moved PEMethodScope fields into the PEGraphDecoder. > > commit fa0c61ad8cecc7e5ef80236085a5996f197494cb > Author: Christian Haeubl > Date: Mon Mar 20 15:25:49 2017 +0100 > > Moved graph from MethodScope to GraphDecoder. > > commit 49f44e762ecaadfd127d9656c54bc522e81bb4d0 > Author: Christian Haeubl > Date: Mon Mar 13 09:58:58 2017 +0100 > > Add the number of fixed nodes to the encoded graph. > > commit 9ca829439e396f2d95466937eff7d330b15ed57b > Author: Christian Haeubl > Date: Fri Mar 10 11:57:55 2017 +0100 > > Use EconomicMap when encoding graphs. > > commit 1154130c6e3f1c2b8b0dc2831fbad6a6bd624ade > Author: Christian Haeubl > Date: Wed Mar 8 17:33:33 2017 +0100 > > Faster canonicalization of fixed nodes. > > commit 09b8adde268a99409a2efe419a2af347a7121b70 > Merge: 50cdd01 fa3b423 > Author: Christian Haeubl > Date: Tue Mar 21 03:30:51 2017 -0700 > > [GR-3296] Better Performance for some Infrastructure Methods. > > commit fa3b423675c6a7af130defaf37293f3571d60383 > Author: Christian Haeubl > Date: Thu Mar 16 15:15:47 2017 +0100 > > NodeBitMap optimizations and fixes. > > commit b3e8c77ab728bcad9227abf42302b20055ca0589 > Author: Christian Haeubl > Date: Tue Mar 14 14:42:30 2017 +0100 > > Improved Node.equals performance. > > commit 32c2cd5b28b4cce96fd66ba6f76db30aa5a93c08 > Author: Christian Haeubl > Date: Tue Mar 7 12:09:27 2017 +0100 > > Small optimizations when constant folding annotated fields/arrays. > > commit 4e83b1d28ccfef5b18f486b183967928158a14ec > Author: Christian Haeubl > Date: Wed Mar 8 17:30:20 2017 +0100 > > Faster way of handling usages when replacing a node. > > commit 50cdd01472af68b78953fa48fc81f166e84dc3bf > Merge: 553f905 0f6b5ea > Author: Stefan Anzinger > Date: Tue Mar 21 02:25:11 2017 -0700 > > [GR-3244] Load all non simm13 constants for further OP3 ops. > > commit 553f905dad4c9ca732d03fab20eee3827f8c152b > Merge: bf3f6b1 1b921a3 > Author: Christian Wimmer > Date: Mon Mar 20 18:00:08 2017 -0700 > > [GR-3305] Add missing bounds check for block boundaries in BytecodeParser. > > commit 1b921a358d096404888448d0cb83fdbe906117d9 > Author: Christian Wimmer > Date: Mon Mar 20 15:17:16 2017 -0700 > > Add missing bounds check for block boundaries in BytecodeParser > > commit bf3f6b19dd457255f69eb2b30d3939bd6157d1c7 > Merge: 0bc6561 10c4ee2 > Author: Doug Simon > Date: Mon Mar 20 12:40:20 2017 -0700 > > [GR-3276] Retry failed compilation with extra graph dumping enabled. > > commit 7616c4cf19b4fc1c5ef53b60aac07fff7ea6ee5e > Author: Gilles Duboscq > Date: Mon Mar 20 18:06:31 2017 +0100 > > Remove hard limit mode for `IterativeNodeWorkList` > > commit bd721090b57a0adc877debcedd118e7e66e71d8e > Author: Gilles Duboscq > Date: Mon Mar 20 18:02:42 2017 +0100 > > Remove old killCFG > > commit ff831acbf339c662b6a79f65b138d27b33a7fa67 > Author: Gilles Duboscq > Date: Fri Mar 17 20:09:54 2017 +0100 > > [GR-3262] Yet another killCFG implementation. > > commit 10c4ee254bf99e53540404021676187d50b65e38 > Author: Doug Simon > Date: Fri Mar 17 18:11:25 2017 +0100 > > added support for retrying a failed compilation with extra logging enabled > > commit b949e08e4cdf4cee6838233f24885641608e2059 > Author: Christian Haeubl > Date: Thu Mar 2 15:40:23 2017 +0100 > > Avoid allocating unnecessary CanonicalizerTool objects during graph decoding. > > commit 43ab0979c79114c0d0d7d9186c852bf7c3721ddc > Author: Christian Haeubl > Date: Wed Mar 1 17:18:05 2017 +0100 > > Allocate fewer floating nodes. > > commit 5e33185a8c68ff361689b8811ef4b6a3c36bfcdf > Author: Christian Haeubl > Date: Wed Mar 1 17:16:05 2017 +0100 > > Avoid unnecessary instanceof checks during graph decoding. > > commit 0bc65616191a47ae25035f3cddbb7a20458fe743 > Merge: 532c573 8ccf234 > Author: Doug Simon > Date: Mon Mar 20 03:22:25 2017 -0700 > > [GR-3293] Do not rely on caching in jdk.vm.ci.services.Services. > > commit 8ccf23425ae09918c16470c13658fa617450de0c > Author: Doug Simon > Date: Sun Mar 19 18:04:06 2017 +0100 > > do not rely on caching in jdk.vm.ci.services.Services > > commit 0f6b5eaedd82f2ac30744ea85165f7eca4d0b631 > Author: Stefan Anzinger > Date: Wed Mar 15 17:35:26 2017 +0000 > > [GR-3244] Load all non simm13 constants for further OP3 ops. > From igor.veresov at oracle.com Thu Apr 6 21:29:25 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 6 Apr 2017 14:29:25 -0700 Subject: RFR(XXL) 8178088: Update Graal In-Reply-To: <48383555-a5a2-2478-b1ae-46d1ec7708d7@oracle.com> References: <24F5BCC4-BF08-4F9F-9FEC-0AFB768A8F66@oracle.com> <48383555-a5a2-2478-b1ae-46d1ec7708d7@oracle.com> Message-ID: <968ACCE1-F100-4EC0-BC18-648653C7FB7D@oracle.com> Thanks, Vladimir! igor > On Apr 6, 2017, at 11:20 AM, Vladimir Kozlov wrote: > > Looks good. Thank you for doing merge. > > Vladimir > > On 4/5/17 10:58 AM, Igor Veresov wrote: >> This is a graal update (for JDK10). Some minor modifications to jaotc were necessary. Tested it with internal AOT tests and RBT. No new AOT-related failures. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8178088/webrev.00/ >> >> The list of changes in this drop: >> >> commit 898a31ae1fe3ad3241c5e4a31504bbb9697a0352 >> Merge: 07bdaff ab20953 >> Author: Tom Rodriguez >> Date: Tue Apr 4 21:25:26 2017 -0700 >> >> [GR-3530] Klass::_java_mirror is a handle in JDK10. >> >> commit ab209530addff5dea0e17c80a4c8bd27b465ad94 >> Author: Tom Rodriguez >> Date: Thu Feb 2 00:26:46 2017 -0800 >> >> Klass::_java_mirror is a handle in JDK10 >> >> commit 07bdaffdd2f4f8978fa26b13ef3b1e04095f20bf >> Merge: 8af58f2 bcf9382 >> Author: Tom Rodriguez >> Date: Tue Apr 4 14:22:43 2017 -0700 >> >> [GR-3529] SnippetTemplate dumping should be at DETAILED_LEVEL. >> >> commit 8af58f2aa1b2378114a31854129c08f2a2e2173e >> Merge: 4663710 536ae38 >> Author: Tom Rodriguez >> Date: Tue Apr 4 14:15:55 2017 -0700 >> >> [GR-3478] InputFilter during CE should have an early bailout. >> >> commit bcf9382e0fceec41b32968107e596ca7fe5463e5 >> Author: Tom Rodriguez >> Date: Tue Apr 4 12:37:50 2017 -0700 >> >> SnippetTemplate dumping should be at VERBOSE_LEVEL >> >> commit 536ae387ce9092f0b9be85c7ea2a874c3f49c27b >> Author: Tom Rodriguez >> Date: Sat Apr 1 20:41:07 2017 -0700 >> >> InputFilter during CE should have an early bailout >> >> commit 46637109fbe6a668b8400a66c0ad87eed8c5dee7 >> Merge: d699794 eddd175 >> Author: Doug Simon >> Date: Tue Apr 4 12:47:22 2017 -0700 >> >> [GR-3526] Clean up ConstantPoolSubstitutionsTests. >> >> commit eddd175307a5ee9ae7a1bcca698481d3d72ea392 >> Author: Doug Simon >> Date: Tue Apr 4 20:33:06 2017 +0200 >> >> removed legacy, commented out code >> >> commit d6997945fdf4b7ee2950551375949cd95050281c >> Merge: 954e82d 6e1ea3c >> Author: Gilles Duboscq >> Date: Tue Apr 4 03:25:21 2017 -0700 >> >> [GR-3488] Canonicalize IntegerLowerNodes & NegateNode early. >> >> commit 6e1ea3c45313cffbb96b933d22c0aebcdba734de >> Author: Gilles Duboscq >> Date: Mon Apr 3 14:27:40 2017 +0200 >> >> Call NegateNode.create >> >> commit 7f14d09b718562d3ca29313815b41276779b51e7 >> Author: Gilles Duboscq >> Date: Mon Apr 3 16:06:45 2017 +0200 >> >> Rename createCanonical to create >> >> commit 32c04af80b365ba748dee1b457b63a406a0e06b5 >> Author: Gilles Duboscq >> Date: Mon Apr 3 16:01:04 2017 +0200 >> >> Canonicalize IntegerLowerNodes early >> >> commit b731f4576ec1ec6762268333c1a165e3cafd289a >> Author: Gilles Duboscq >> Date: Mon Apr 3 13:48:00 2017 +0200 >> >> Separate primitive and object condition folding >> >> Make it possible to fold compares without a ConstantReflectionProvider >> Add NegateNode.create >> >> commit 954e82d04b567604dc88c259022a227b7f660d27 >> Merge: b89f51a 96ac936 >> Author: Josef Eisl >> Date: Tue Apr 4 00:15:57 2017 -0700 >> >> [GR-3247] Update to JMH 1.18. >> >> commit 96ac936029db150395b8201d40d9546735e9f2a3 >> Author: Josef Eisl >> Date: Tue Apr 4 08:42:48 2017 +0200 >> >> [ci] remove deprecated Microbench task from gate >> >> This has been replaced by mx benchmark and is already tested in mx. >> >> commit a9dfb206502858c34351afb7963c15d4996b9171 >> Author: Josef Eisl >> Date: Mon Apr 3 16:38:20 2017 +0200 >> >> [fix] findbugs should ignore code generated by JMH 1.18 >> >> commit 8f4b7c88295594bb94a638578787f06fe8dc1bf4 >> Author: Josef Eisl >> Date: Mon Apr 3 15:30:41 2017 +0200 >> >> [def] Update JMH to 1.18 >> >> commit d4f3d5978edb5a223cc08e3d0dc98d23ce67d375 >> Author: Josef Eisl >> Date: Mon Apr 3 16:21:21 2017 +0200 >> >> [fix] TraceLSRAIntervalBuildingBench can't set inter-trace hints >> >> commit b89f51afcd0e0469c6d6e6d937f993cc66cfc710 >> Merge: 12d7c44 42149c4 >> Author: Doug Simon >> Date: Mon Apr 3 16:02:18 2017 -0700 >> >> [GR-3440] Refine graph dumping policy. >> >> commit 42149c4939e8b6b2f41777653303aca37b380bc3 >> Author: Doug Simon >> Date: Tue Apr 4 00:35:15 2017 +0200 >> >> ignore SourceMappings for hotspot code installation if DebugNonSafepoints is false >> >> commit d28ccd8bd9c5c7eccf36b425a11477045b10f54a >> Author: Doug Simon >> Date: Mon Apr 3 15:19:10 2017 +0200 >> >> enable NodeSourcePositions for graphs being dumped >> >> commit 6e43f69bc6d1d75257274ae132a93cd540e8aa3c >> Author: Doug Simon >> Date: Mon Apr 3 15:18:37 2017 +0200 >> >> silence Truffle stub installation unless DebugStubsAndSnippets is true >> >> commit d1e92d819f39be86c3d07224fa7b644b1949f179 >> Author: Doug Simon >> Date: Mon Apr 3 15:32:54 2017 +0200 >> >> renamed *_LOG_LEVEL to *_LEVEL >> >> commit c2e1386e2108493b3b46670eea20483ada54f973 >> Author: Doug Simon >> Date: Mon Apr 3 15:30:06 2017 +0200 >> >> modified graph dumping levels according to new policy >> >> commit 12d7c449327aaac729f683f6c8e6d763fa95d46c >> Merge: ccb8f2d fdae32d >> Author: Thomas W?rthinger >> Date: Mon Apr 3 15:29:27 2017 -0700 >> >> [GR-3484] MoveGuardsUpwards should move guards above loops. >> >> commit ccb8f2db62f91d536d14e6055ddb30a1db649236 >> Merge: edc5675 f06c373 >> Author: Tom Rodriguez >> Date: Mon Apr 3 13:28:59 2017 -0700 >> >> [GR-3499] LockElimination should be more careful when replacing the monitor id. >> >> commit f06c373bae66e63e4382a35457b19d870f91c871 >> Author: Tom Rodriguez >> Date: Mon Apr 3 11:28:46 2017 -0700 >> >> LockElimination should be more careful when replacing the monitor id >> >> commit edc56752eb01eed2fa3e98beb7b91fc213aa4061 >> Merge: 8d56111 6471776 >> Author: Doug Simon >> Date: Mon Apr 3 10:34:44 2017 -0700 >> >> [GR-3474] Stop unit tests printing output to the console. >> >> commit 8d56111fcedc9435e0251a80e4f07d6636c968aa >> Merge: 4df8608 095b868 >> Author: David Leopoldseder >> Date: Mon Apr 3 09:43:11 2017 -0700 >> >> [GR-3481] Canonicalize demorgan structures. >> >> commit 4df8608c503bec656b2ca052da11c3057159c069 >> Merge: f4f8f65 a788a42 >> Author: Christian Haeubl >> Date: Mon Apr 3 09:07:44 2017 -0700 >> >> [GR-3493] Reduce memory footprint and improve performance of partial escape analysis. >> >> commit f4f8f652a56a9458f757894c771bab165fceca7d >> Merge: 87d20d7 9a66234 >> Author: Stefan Anzinger >> Date: Mon Apr 3 08:01:36 2017 -0700 >> >> [GR-3311] Preserve graal diagnostic output in CI jobs. >> >> commit 87d20d75c955b6002c00796c072b36b1fbdeac9a >> Merge: 1236bbd 71ca109 >> Author: Aleksandar Prokopec >> Date: Mon Apr 3 07:53:22 2017 -0700 >> >> [GR-3485] Add early canonicalizations for KlassLayoutHelperNode. >> >> commit a788a4285b26b28936b8aa7ea21cb804cca9a9e9 >> Author: Christian Haeubl >> Date: Mon Apr 3 15:56:22 2017 +0200 >> >> Remove an unnecessary method call. >> >> commit 545bb1b6de6fe8cfcdb28475b49b0ac77dd60603 >> Author: Christian Haeubl >> Date: Mon Apr 3 11:59:05 2017 +0200 >> >> Reduce escape analysis memory usage. >> >> commit 71ca1096049cc1b924312af239f4f8df83ce65a3 >> Author: Aleksandar Prokopec >> Date: Mon Apr 3 14:09:29 2017 +0200 >> >> Add missing early canonicalizations for KlassLayoutHelperNode and PiNode. >> >> commit fdae32d357bff02836bcef700bad9fa53325a66d >> Author: Gilles Duboscq >> Date: Mon Apr 3 13:50:09 2017 +0200 >> >> [GR-3484] MoveGuardsUpwards should move guards above loops. >> >> commit 095b868c9442bac28e021449c2849821c689bb9b >> Author: David Leopoldseder >> Date: Mon Apr 3 12:51:51 2017 +0200 >> >> [feature] canonicalize demorgan structures >> >> commit 1236bbd1691733995623f3f42f9ac3984300e437 >> Merge: 0ae1d82 16088c0 >> Author: Thomas W?rthinger >> Date: Sun Apr 2 13:04:49 2017 -0700 >> >> [GR-1883] Explicitly mark eliminated locks instead of nulling them out. >> >> commit 16088c0f4988a72a75b15f6e082ac3f27eea30b0 >> Author: Tom Rodriguez >> Date: Thu Mar 30 22:51:29 2017 -0700 >> >> Explicitly mark eliminated locks instead of nulling them out >> >> commit 0ae1d820069262ed9e79c3788c68129a8fb316b1 >> Merge: 23c8907 c6e0308 >> Author: Doug Simon >> Date: Sat Apr 1 08:56:08 2017 -0700 >> >> [GR-3475] EliminateRedundantInitializationPhase is not working in AOT. >> >> commit c6e0308e975ceb0c925d740b73f4dec3f28c0566 >> Author: Igor Veresov >> Date: Sat Apr 1 16:21:44 2017 +0200 >> >> Process correct constants in redundant initialization elimination phase (JDK-8177856) >> >> commit 6471776b3a224732495bcb6b441e60d3d55b324a >> Author: Doug Simon >> Date: Sat Apr 1 16:13:47 2017 +0200 >> >> disable console printing from unit tests >> >> commit 23c8907cfd1ee8bd64f7eb1843264666909acc4d >> Merge: 790c8a5 bf59ae1 >> Author: Thomas W?rthinger >> Date: Sat Apr 1 04:46:57 2017 -0700 >> >> [GR-3242] Fix a bug in the if fixed node deduplication that could lead to deoptimization loops. >> >> commit bf59ae1ca6f4cc28bccfa64c810024f9a39c468a >> Author: Thomas W?rthinger >> Date: Sat Apr 1 04:27:32 2017 +0200 >> >> Fix a bug in the if fixed node deduplication that could lead to deoptimization loops. >> >> commit 790c8a5187af5c966a355340398b2e75a4a9e3a7 >> Merge: b297777 a534a1f >> Author: Christian Wimmer >> Date: Fri Mar 31 15:57:46 2017 -0700 >> >> [GR-3470] Support GuardProxyNode in GraphDecoder. >> >> commit a534a1f888960168f391f149512f8b9fc4f54b01 >> Author: Christian Wimmer >> Date: Fri Mar 31 15:14:52 2017 -0700 >> >> Support GuardProxyNode in GraphDecoder >> >> commit b29777785b119726baf9afc2fe4f6ba2b4a38705 >> Merge: dc3f6af 8256166 >> Author: Aleksandar Prokopec >> Date: Fri Mar 31 07:39:17 2017 -0700 >> >> [GR-3459] Use static creation methods for PiNodes. >> >> commit 8256166f78355283f119866fb48054a7f36a4ec2 >> Author: Aleksandar Prokopec >> Date: Fri Mar 31 15:56:00 2017 +0200 >> >> Disable early PiNode canonicalization in MethodCallTargetNode. >> >> commit dc3f6af4e2e7c25b86899543451802e07103e2a3 >> Merge: 2de905e 650263d >> Author: Christian Haeubl >> Date: Fri Mar 31 06:00:19 2017 -0700 >> >> [GR-3458] Incorrect ObjectState array reference count during escape analysis. >> >> commit 5eae3d5f42b2a30f4ff30bd74fd0960783709b5b >> Author: Aleksandar Prokopec >> Date: Fri Mar 31 13:21:15 2017 +0200 >> >> Add static canonicalizing creation methods to PiNode, and ensure they are used. >> >> commit 650263d46311c6ea8a864c9ceb6e315afb456fdc >> Author: Christian Haeubl >> Date: Fri Mar 31 13:02:48 2017 +0200 >> >> Fixed incorrect reference count during escape analysis. >> >> commit 9a66234d2196f9faedbdfc5e2a37d7ff396d6092 >> Author: Stefan Anzinger >> Date: Fri Mar 31 09:43:21 2017 +0000 >> >> [GR-3311] Preserve graal diagnostic output in CI jobs. >> >> commit 2de905e50884b74c5decf35c13e21e7afa613287 >> Merge: dda8cfa dd68a0b >> Author: Tom Rodriguez >> Date: Thu Mar 30 21:29:23 2017 -0700 >> >> [GR-3405] Allow access to static fields in uninitialized classes. >> >> commit dda8cfa183c9f0c7ab1bc27b4c7c163b4e26b208 >> Merge: ac3581b b4787c2 >> Author: Christian Wimmer >> Date: Thu Mar 30 16:57:46 2017 -0700 >> >> [GR-3453] Make Truffle compilation more customizable. >> >> commit b4787c2b0a6fcc1a505ed50028706e3484930465 >> Author: Christian Wimmer >> Date: Thu Mar 30 16:32:02 2017 -0700 >> >> Truffle: expose profiled argument types and return type >> >> commit e16dc14e94dccf6aebaa6f8d850372ab3fad0d6a >> Author: Christian Wimmer >> Date: Wed Mar 29 19:40:34 2017 -0700 >> >> Truffle: allow customization of root method where partial evaluation starts >> >> commit 1a8dbe4728809178a3c54738b576b52842023366 >> Author: Christian Wimmer >> Date: Wed Mar 29 19:38:31 2017 -0700 >> >> Truffle: print address of compiled code in TraceTruffleCompilation >> >> commit dd68a0b9ecc4e34fa404bc6d4229fd1dce6d0891 >> Author: Tom Rodriguez >> Date: Mon Mar 27 20:01:22 2017 -0700 >> >> Allow access to static fields in uninitialized classes >> >> commit ac3581bf92394a588426879efdf9113b9b99fbd5 >> Merge: d34057d 385984d >> Author: Aleksandar Prokopec >> Date: Thu Mar 30 07:31:11 2017 -0700 >> >> [GR-3412] Add missing static creation methods for arithmetic nodes. >> >> commit d34057d250f2740ed820a053d77a172c4981ed00 >> Merge: 14702f0 7e4f019 >> Author: Gilles Duboscq >> Date: Thu Mar 30 07:15:38 2017 -0700 >> >> [GR-3314] Canonicalize `a - 1 < a` to `a != MIN`. >> >> commit 385984d7163a371e4cb43a8774a71823386ce582 >> Author: Aleksandar Prokopec >> Date: Thu Mar 30 14:17:54 2017 +0200 >> >> Suppress warning. >> >> commit 32a9b222c3c02b7f72484ae709b3c40f649ddea7 >> Merge: 8a7f54f 14702f0 >> Author: Aleksandar Prokopec >> Date: Thu Mar 30 14:16:52 2017 +0200 >> >> Merge branch 'master' into topic/static-node-creation >> >> commit 8a7f54f6d297455b82e4609515bcfcdd16bfe52c >> Author: Aleksandar Prokopec >> Date: Thu Mar 30 11:35:34 2017 +0200 >> >> Add early PiNode canonicalizations. >> >> commit 7e4f019ab26f5c6051e8ee5348b9d6e50bd1d1b2 >> Author: Gilles Duboscq >> Date: Wed Mar 29 16:17:43 2017 +0200 >> >> Remove some assertions >> >> commit f6c6563f0b9d1ad27bc6f079a30480018927824e >> Author: Gilles Duboscq >> Date: Wed Mar 29 16:11:35 2017 +0200 >> >> Handle `x - y < 1` similarily to `x - y < 0` >> >> commit f0e02546061ddf562b81b82a8418807941a7f0da >> Author: Gilles Duboscq >> Date: Thu Mar 23 16:59:37 2017 +0100 >> >> [GR-3314] Canonicalize `a - 1 < a` to `a != MIN` >> >> - Canonicalize `a < a + c` and related shapes to a comparison between `a` and >> a constant. >> - Move constants on the rights for < comparisons >> - Canonicalize `a < MAX` to `a != MAX` >> - Canonicalize `a < MIN + 1` to `a == MIN` >> >> commit 64fc4b180bee6adbb459186975b2c5821c7eb6f4 >> Author: Gilles Duboscq >> Date: Thu Mar 23 16:51:47 2017 +0100 >> >> Add isUnrestricted to Stamp >> >> commit da4ef6b58bc26e390458ecc346608fb78bff81aa >> Author: Gilles Duboscq >> Date: Thu Mar 23 17:36:31 2017 +0100 >> >> Fix ProbabilityDirectiveTest >> >> The test should check which branch has the expected probablity rather >> than assume it's the true successor. >> Turn some condition into an assertion in BranchProbabilityNode >> >> commit 7872a7820ae4a3df47a9a17c81af0b16e1f7cc83 >> Author: Gilles Duboscq >> Date: Thu Mar 23 16:50:19 2017 +0100 >> >> Fix BoxingEliminationTest#testLoop2 >> >> In the reference snippet, the loop is peeled and should start at 1 >> >> commit 718159296f63b687e88ef174931fa5447f582dbb >> Author: Gilles Duboscq >> Date: Thu Mar 23 16:48:46 2017 +0100 >> >> Canonicalize x + v1 == x + v2 and similar shapes >> >> commit cd0375565cf2dbcc01863499029f041c74a68623 >> Author: Gilles Duboscq >> Date: Thu Mar 23 16:44:04 2017 +0100 >> >> ConditionalEliminationTest: remove disableSimplification >> >> - Make sure tests are control-flow using writes >> - Improve getCanonicalGraphString: >> - include field access names >> - use sorted constants >> >> commit 14702f09468bd90e1d4f0aa3eecf4793dbdc060e >> Merge: 008879b a9ae3b4 >> Author: Christian Haeubl >> Date: Thu Mar 30 01:17:25 2017 -0700 >> >> [GR-3406] Faster constant folding during graph decoding. >> >> commit 008879b3a564a2ae40d5a12e753fd2adf067b00f >> Merge: 6e667ab cb657cb >> Author: Christian Haeubl >> Date: Thu Mar 30 01:12:09 2017 -0700 >> >> [GR-3408] Avoid Long Lived Objects during Graph Decoding. >> >> commit d21dea584c5776d1b5ad9693a765f3fd4b62b447 >> Author: Aleksandar Prokopec >> Date: Wed Mar 29 18:50:48 2017 +0200 >> >> Add early canonicalization for the LoadFieldNode. >> >> commit a9ae3b405621255ad822852970457ed061e05cb2 >> Author: Christian Haeubl >> Date: Thu Mar 23 11:24:03 2017 +0100 >> >> Faster constant folding during graph decoding. >> >> commit cb657cb0df8610e4a650d275f75e1f466c76224b >> Author: Christian Haeubl >> Date: Thu Mar 23 16:24:40 2017 +0100 >> >> Avoid default size for small collections. >> >> commit a30c17fc8891cd204b92fc5aae609aae42ee3429 >> Author: Christian Haeubl >> Date: Thu Mar 23 14:19:21 2017 +0100 >> >> Avoid unnecessary Node array allocations. >> >> commit dde8edd9b615a6cd54677ea900f912bfe1b2e875 >> Author: Christian Haeubl >> Date: Fri Mar 17 16:20:31 2017 +0100 >> >> Remove some data that would get propagated into the old gen. >> >> commit 4d2f00bf4130e2fb77509d3197723a984ba0c8ad >> Author: Aleksandar Prokopec >> Date: Wed Mar 29 15:56:54 2017 +0200 >> >> Do early canonicalization when creating the ZeroExtendNode. >> >> commit 00f32559d9a0cd5f3bdd1e502dcda06486a45da0 >> Author: Aleksandar Prokopec >> Date: Wed Mar 29 15:41:02 2017 +0200 >> >> Add early canonicalization for the ConditionalNode. >> >> commit 951ee767a7fe2ef14944ebfeba9b71cfc32d04e0 >> Author: Aleksandar Prokopec >> Date: Wed Mar 29 15:21:30 2017 +0200 >> >> Apply node plugins when parsing snippets before deoptimizing. >> >> commit 6e667ab7561d9b870ebdf2eda0e729b3ac7c1f18 >> Merge: acbd663 76fef80 >> Author: Christian Humer >> Date: Wed Mar 29 05:43:44 2017 -0700 >> >> [GR-164] Migrate code sharing. >> >> commit 76fef80e257dba4ce755d2b6a7d35c24138807ad >> Author: Christian Humer >> Date: Wed Mar 29 14:21:29 2017 +0200 >> >> Update overlay version. >> >> commit 0a950d451c6728ef628c586fc7fa5e02a4e13904 >> Author: Christian Humer >> Date: Wed Mar 22 18:27:39 2017 +0100 >> >> Update Truffle. >> >> commit e323ebe3be5d986b4bc6dae128700b515ed6811a >> Author: Christian Humer >> Date: Wed Mar 22 14:36:32 2017 +0100 >> >> Migration for code sharing changes. >> >> commit e2cc122b394ddca8f0ace8d91cd739784696534c >> Author: Aleksandar Prokopec >> Date: Wed Mar 29 11:59:29 2017 +0200 >> >> Add static creation method and early canonicalization for ClassGetHubNode. >> >> commit 57491b2b3db97d19c72708923646508e7f44742c >> Author: Aleksandar Prokopec >> Date: Wed Mar 29 10:41:02 2017 +0200 >> >> Factor out common shift operation canonicalization functionality. >> >> commit 31a127ba63dda060b9d7bd91ed122f250bd4180d >> Author: Aleksandar Prokopec >> Date: Tue Mar 28 15:12:59 2017 +0200 >> >> Add static creation methods for LeftShiftNode and RightShiftNode, and enable canonicalization during creation. >> >> commit acbd6634910f2ee1043460230b71b67551d6c0ee >> Merge: 6392034 8701ad6 >> Author: Aleksandar Prokopec >> Date: Tue Mar 28 08:38:40 2017 -0700 >> >> [GR-3384] Apply additional canonicalizations during node creation. >> >> commit 8701ad6a5e1c73c1bd9142c47a24b53c1f4e7ba9 >> Author: Aleksandar Prokopec >> Date: Tue Mar 28 16:27:50 2017 +0200 >> >> Add addWithInputs method to the GraphBuilderContext. >> >> commit d8534c53f2bcb2ffdcdd6396dc5f057fc9e01f0e >> Author: Aleksandar Prokopec >> Date: Tue Mar 28 15:05:41 2017 +0200 >> >> Add inputs of IsNullNode when building the graph. >> >> commit f56fab56d72365f63ad13e95d11f58d3bcb83051 >> Author: Aleksandar Prokopec >> Date: Mon Mar 27 17:06:33 2017 +0200 >> >> Disable some cases in AddNode and SubNode canonicalizations during creation. >> >> commit 63920343264aee98f589226670eda4821907d381 >> Merge: c004c38 4d15171 >> Author: Gilles Duboscq >> Date: Mon Mar 27 08:32:59 2017 -0700 >> >> [GR-2881] Add deploy-binary on post-merge. >> >> commit b14175d8781256f482d411a637fd6af9ff56e20b >> Author: Aleksandar Prokopec >> Date: Mon Mar 27 17:04:04 2017 +0200 >> >> Canonicalize additional cases in IsNullNode earlier. >> >> commit 86957922fd738906ae3b7e579e3cd9f0803b1277 >> Author: Aleksandar Prokopec >> Date: Mon Mar 27 16:21:19 2017 +0200 >> >> Improve early canonicalization for AddNode and SubNode, fix canonicalization test. >> >> commit 4d151712fd0880ba2cacd22c3a87eb7dbb615c85 >> Author: Gilles Duboscq >> Date: Mon Mar 27 16:16:17 2017 +0200 >> >> [GR-2881] Add deploy-binary on post-merge. >> >> commit 49cae45cc354b01798adeff1184dbc67c8ad3353 >> Author: Aleksandar Prokopec >> Date: Mon Mar 27 16:03:55 2017 +0200 >> >> Add canonicalization during creation for the SignExtendNode. >> >> commit 815768bf27cd6e1df96ef42b457fd0d8e21e5617 >> Author: Aleksandar Prokopec >> Date: Mon Mar 27 15:52:26 2017 +0200 >> >> Add early canonicalizations for logic nodes. >> >> commit c202ee1a6f700105fe074e59c42928308aeff2bb >> Author: Aleksandar Prokopec >> Date: Mon Mar 27 15:13:20 2017 +0200 >> >> Enable early canonicalization for DivNode, fix conditional elimination test to pass. >> >> commit c40e59f5be5ef753bf2321a70930acfd8f647ffa >> Author: Aleksandar Prokopec >> Date: Mon Mar 27 14:04:45 2017 +0200 >> >> Add canonicalization during creation to MulNode. >> >> commit 737a348b7a4ddc76c51060fb036ae6fe4d600ba1 >> Author: Aleksandar Prokopec >> Date: Mon Mar 27 10:15:56 2017 +0200 >> >> Apply additional canonicalizations during node creation. >> >> commit c004c3821e27df7f3cfd0d419e2e5dd93e39304f >> Merge: b7c67eb 5ad36d3 >> Author: Doug Simon >> Date: Sat Mar 25 10:57:51 2017 -0700 >> >> [GR-2951] OOM error in micro.benchmarks.ArrayListBenchmark.addNull. >> >> commit 5ad36d30608ca8ebee06cf11b2b4fe14d5b9c8b7 >> Author: Doug Simon >> Date: Sat Mar 25 16:08:36 2017 +0100 >> >> use self-clearing state for ArrayListBenchmark.addNull benchmark >> >> commit b7c67ebe071bebb2fa1a553a039a25264d8d925e >> Merge: b0c2c6b 65e2a40 >> Author: Doug Simon >> Date: Fri Mar 24 17:16:18 2017 -0700 >> >> [GR-3287] Remove StampFactory.forNodeIntrinsic. >> >> commit 65e2a4003d1870c2d87151f4f3bb4052af044363 >> Author: Doug Simon >> Date: Mon Mar 20 23:17:29 2017 +0100 >> >> removed StampFactory.forNodeIntrinsic >> >> commit b0c2c6be80e6a9dd3cc615b3189c1183943421f0 >> Merge: 2176764 1e41064 >> Author: Tom Rodriguez >> Date: Fri Mar 24 10:10:41 2017 -0700 >> >> [GR-3378] Fix bug with virtualization of arraycopy for primitive types. >> >> commit 1e41064941ae883f9d287f64862481fe3c436302 >> Author: Tom Rodriguez >> Date: Wed Mar 22 10:11:48 2017 -0700 >> >> Fix bug with virtualization of arraycopy for primitive types >> >> commit 217676413cc319a8c5f9d13423ef0eea1d500fed >> Merge: b2112f1 8eee9f3 >> Author: Doug Simon >> Date: Fri Mar 24 09:09:51 2017 -0700 >> >> [GR-3374] Make OptionValues immutable. >> >> commit 8eee9f3fa5a4a898b7d458aa68dbdcb9594f50d2 >> Author: Doug Simon >> Date: Fri Mar 24 15:27:10 2017 +0100 >> >> expose API for searching OptionDescriptors for a fuzzy match against an option name >> >> commit 3df741532a24ab9b61a53eca991c227fea2ec44f >> Author: Doug Simon >> Date: Fri Mar 24 14:06:22 2017 +0100 >> >> added ModifiableOptionValues >> >> commit b2112f1ee03759bcbc0a576d27dda571b7a838ac >> Merge: 76ca9b9 f5cbb13 >> Author: Doug Simon >> Date: Thu Mar 23 15:22:25 2017 -0700 >> >> [GR-3003] Make OptionValues updates more thread safe. >> >> commit 76ca9b9224329f1a6b047b765d8d0e1ea5d58f06 >> Merge: e9c533e 4ac9ae6 >> Author: Doug Simon >> Date: Thu Mar 23 14:54:32 2017 -0700 >> >> [GR-3309] Refine compilation retry. >> >> commit e9c533e542bcda4c65298dab1d72627d2529c533 >> Merge: b5daaff 5e4dcfd >> Author: Vojin Jovanovic >> Date: Thu Mar 23 10:38:33 2017 -0700 >> >> [GR-3356] Write files when roundEnv.processingOver in ServiceProviderProcessor. >> >> commit 5e4dcfd11f9a3494486d4381080c2247db3594a5 >> Author: Vojin Jovanovic >> Date: Thu Mar 23 17:43:08 2017 +0100 >> >> [fix] write files when roundEnv.processingOver in ServiceProviderProcessor >> >> commit b5daafff28b74e34ee92e9a8c69278ae8f33b131 >> Merge: f304652 a1745ed >> Author: Doug Simon >> Date: Thu Mar 23 06:24:59 2017 -0700 >> >> [GR-3361] Minor dumping fixes. >> >> commit f5cbb13838ca8c86e60ac8c52c798b4d3f0c0688 >> Author: Doug Simon >> Date: Tue Mar 21 22:02:33 2017 +0100 >> >> allow mutability of OptionValues >> >> commit aaf856f989a9040fd837800186502d964170c198 >> Author: Doug Simon >> Date: Tue Mar 21 09:58:42 2017 +0100 >> >> made OptionValues extensible for a subclass that implements a mutable option set >> >> commit fd80a1a29eb7e061736593de206f9e1a0531c07c >> Author: Doug Simon >> Date: Tue Mar 21 09:57:23 2017 +0100 >> >> fixed instances of "the the" in comments >> >> commit a1745edd8f717d3a477bcf28d4816e0462d1dc9e >> Author: Tom Rodriguez >> Date: Wed Mar 22 23:04:04 2017 -0700 >> >> Minor dumping fixes >> >> commit f30465268bc2133ee55d70418ad5af3b0ee1af5d >> Merge: c1920c3 5d729c9 >> Author: Doug Simon >> Date: Wed Mar 22 14:34:18 2017 -0700 >> >> [GR-3357] Remove UseTrivialPrefixes flag. >> >> commit 5d729c9cb1ba0230788fce921cce1b9209b8bc6e >> Author: Doug Simon >> Date: Wed Mar 22 20:58:16 2017 +0100 >> >> remove UseTrivialPrefixes option and guard CompileGraalWithC1Only code properly >> >> commit c1920c310c5d97c2d82a50ed68c4560a02f80df3 >> Merge: 7821a08 4cc99e7 >> Author: Vojin Jovanovic >> Date: Wed Mar 22 06:27:40 2017 -0700 >> >> [GR-3292] Update Truffle version. >> >> commit 7821a08d45468500dd663f745ab1771de5371694 >> Merge: b555abe b30ecfd >> Author: Christian Haeubl >> Date: Wed Mar 22 01:15:23 2017 -0700 >> >> [GR-3295] Performance and Footprint Optimizations in the GraphDecoder. >> >> commit b555abe16fd92be3c0eaf4ca475ba335ba2253f1 >> Merge: 4b0879e 54ac726 >> Author: Gilles Duboscq >> Date: Tue Mar 21 10:47:48 2017 -0700 >> >> [GR-3262] Yet another killCFG implementation. >> >> commit 4ac9ae620a722a9d77ff3fa0fe3f1bdab2e51f9f >> Author: Doug Simon >> Date: Tue Mar 21 13:55:59 2017 +0100 >> >> don't retry compilation is Dump option is explicitly set; improve documentation and name of CrashAt related code >> >> commit 4b0879edface6c3c5fb220cfee7a52d95700f0ab >> Merge: 09b8add 9b21118 >> Author: Doug Simon >> Date: Tue Mar 21 07:55:28 2017 -0700 >> >> [GR-3315] Fix prefix for GraalCompileOnly option. >> >> commit 9b21118361917a189933959a2c5005c9d3375e10 >> Author: Doug Simon >> Date: Tue Mar 21 13:57:25 2017 +0100 >> >> shorten prefix for GraalCompileOnly matching to "org.graalvm" >> >> commit 54ac72679384ff8698eabcbd077dd2d5c335f123 >> Author: Gilles Duboscq >> Date: Tue Mar 21 12:27:43 2017 +0100 >> >> Split up killCFGInner >> >> commit 4cc99e72c9db82e34918f90593a17222e9f3ad11 >> Author: Vojin Jovanovic >> Date: Tue Mar 21 12:26:47 2017 +0100 >> >> Update Truffle version >> >> commit 79c46aa0131cacf73058c7884b3d05cff19efa6b >> Author: Gilles Duboscq >> Date: Tue Mar 21 12:20:01 2017 +0100 >> >> Remove unnecessary changes >> >> commit b30ecfde331cca71422c6aa8cac91cee275fd1fb >> Author: Christian Haeubl >> Date: Mon Mar 20 16:57:10 2017 +0100 >> >> Moved PEMethodScope fields into the PEGraphDecoder. >> >> commit fa0c61ad8cecc7e5ef80236085a5996f197494cb >> Author: Christian Haeubl >> Date: Mon Mar 20 15:25:49 2017 +0100 >> >> Moved graph from MethodScope to GraphDecoder. >> >> commit 49f44e762ecaadfd127d9656c54bc522e81bb4d0 >> Author: Christian Haeubl >> Date: Mon Mar 13 09:58:58 2017 +0100 >> >> Add the number of fixed nodes to the encoded graph. >> >> commit 9ca829439e396f2d95466937eff7d330b15ed57b >> Author: Christian Haeubl >> Date: Fri Mar 10 11:57:55 2017 +0100 >> >> Use EconomicMap when encoding graphs. >> >> commit 1154130c6e3f1c2b8b0dc2831fbad6a6bd624ade >> Author: Christian Haeubl >> Date: Wed Mar 8 17:33:33 2017 +0100 >> >> Faster canonicalization of fixed nodes. >> >> commit 09b8adde268a99409a2efe419a2af347a7121b70 >> Merge: 50cdd01 fa3b423 >> Author: Christian Haeubl >> Date: Tue Mar 21 03:30:51 2017 -0700 >> >> [GR-3296] Better Performance for some Infrastructure Methods. >> >> commit fa3b423675c6a7af130defaf37293f3571d60383 >> Author: Christian Haeubl >> Date: Thu Mar 16 15:15:47 2017 +0100 >> >> NodeBitMap optimizations and fixes. >> >> commit b3e8c77ab728bcad9227abf42302b20055ca0589 >> Author: Christian Haeubl >> Date: Tue Mar 14 14:42:30 2017 +0100 >> >> Improved Node.equals performance. >> >> commit 32c2cd5b28b4cce96fd66ba6f76db30aa5a93c08 >> Author: Christian Haeubl >> Date: Tue Mar 7 12:09:27 2017 +0100 >> >> Small optimizations when constant folding annotated fields/arrays. >> >> commit 4e83b1d28ccfef5b18f486b183967928158a14ec >> Author: Christian Haeubl >> Date: Wed Mar 8 17:30:20 2017 +0100 >> >> Faster way of handling usages when replacing a node. >> >> commit 50cdd01472af68b78953fa48fc81f166e84dc3bf >> Merge: 553f905 0f6b5ea >> Author: Stefan Anzinger >> Date: Tue Mar 21 02:25:11 2017 -0700 >> >> [GR-3244] Load all non simm13 constants for further OP3 ops. >> >> commit 553f905dad4c9ca732d03fab20eee3827f8c152b >> Merge: bf3f6b1 1b921a3 >> Author: Christian Wimmer >> Date: Mon Mar 20 18:00:08 2017 -0700 >> >> [GR-3305] Add missing bounds check for block boundaries in BytecodeParser. >> >> commit 1b921a358d096404888448d0cb83fdbe906117d9 >> Author: Christian Wimmer >> Date: Mon Mar 20 15:17:16 2017 -0700 >> >> Add missing bounds check for block boundaries in BytecodeParser >> >> commit bf3f6b19dd457255f69eb2b30d3939bd6157d1c7 >> Merge: 0bc6561 10c4ee2 >> Author: Doug Simon >> Date: Mon Mar 20 12:40:20 2017 -0700 >> >> [GR-3276] Retry failed compilation with extra graph dumping enabled. >> >> commit 7616c4cf19b4fc1c5ef53b60aac07fff7ea6ee5e >> Author: Gilles Duboscq >> Date: Mon Mar 20 18:06:31 2017 +0100 >> >> Remove hard limit mode for `IterativeNodeWorkList` >> >> commit bd721090b57a0adc877debcedd118e7e66e71d8e >> Author: Gilles Duboscq >> Date: Mon Mar 20 18:02:42 2017 +0100 >> >> Remove old killCFG >> >> commit ff831acbf339c662b6a79f65b138d27b33a7fa67 >> Author: Gilles Duboscq >> Date: Fri Mar 17 20:09:54 2017 +0100 >> >> [GR-3262] Yet another killCFG implementation. >> >> commit 10c4ee254bf99e53540404021676187d50b65e38 >> Author: Doug Simon >> Date: Fri Mar 17 18:11:25 2017 +0100 >> >> added support for retrying a failed compilation with extra logging enabled >> >> commit b949e08e4cdf4cee6838233f24885641608e2059 >> Author: Christian Haeubl >> Date: Thu Mar 2 15:40:23 2017 +0100 >> >> Avoid allocating unnecessary CanonicalizerTool objects during graph decoding. >> >> commit 43ab0979c79114c0d0d7d9186c852bf7c3721ddc >> Author: Christian Haeubl >> Date: Wed Mar 1 17:18:05 2017 +0100 >> >> Allocate fewer floating nodes. >> >> commit 5e33185a8c68ff361689b8811ef4b6a3c36bfcdf >> Author: Christian Haeubl >> Date: Wed Mar 1 17:16:05 2017 +0100 >> >> Avoid unnecessary instanceof checks during graph decoding. >> >> commit 0bc65616191a47ae25035f3cddbb7a20458fe743 >> Merge: 532c573 8ccf234 >> Author: Doug Simon >> Date: Mon Mar 20 03:22:25 2017 -0700 >> >> [GR-3293] Do not rely on caching in jdk.vm.ci.services.Services. >> >> commit 8ccf23425ae09918c16470c13658fa617450de0c >> Author: Doug Simon >> Date: Sun Mar 19 18:04:06 2017 +0100 >> >> do not rely on caching in jdk.vm.ci.services.Services >> >> commit 0f6b5eaedd82f2ac30744ea85165f7eca4d0b631 >> Author: Stefan Anzinger >> Date: Wed Mar 15 17:35:26 2017 +0000 >> >> [GR-3244] Load all non simm13 constants for further OP3 ops. >> From kim.barrett at oracle.com Fri Apr 7 04:48:46 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 7 Apr 2017 00:48:46 -0400 Subject: RFR: 8160748: Inconsistent types for ideal_reg Message-ID: Please review this change to Type's ideal_reg to make its return type consistent with the closely related Node::ideal_reg(). Where Type used to be an int, it is now a uint. This eliminates the implicit narrowing conversion in the initialization of _type_info that caused build failure for C++11 (gcc with -std=gnu++11 or (not tested, but presumed fixed) Visual Studio 2015 or later). Also fixed a number of places where the result of Node::ideal_reg() was being treated as int rather than uint. And since I was in the neighborhood (changing the type of Type::TypeInfo::ideal_reg), also fixed Type::_type_info[] to be const as apparently intended but not successfully accomplished. (The msg member was writable, forcing allocation of the array to be in writable memory, rather than read-only.) CR: https://bugs.openjdk.java.net/browse/JDK-8160748 Webrev: http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.00/ Testing: JPRT, rbt hs-tier2,hs-tier3,hs-tier4-comp,hs-tier5-comp From zoltan.majo at oracle.com Fri Apr 7 14:38:02 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 7 Apr 2017 16:38:02 +0200 Subject: [10] RFR: 8171813: possible null pointer dereference defects In-Reply-To: <0f0ef598-49a6-443b-a1ab-502335167a98@default> References: <0f0ef598-49a6-443b-a1ab-502335167a98@default> Message-ID: <95cf497c-1a35-554f-8a95-13ef287393a1@oracle.com> Hi Rahul, On 04/06/2017 08:27 AM, Rahul Raghavan wrote: > Hi, > > Thank you Tobias for the review comments. > Sorry for my oversight and yes now included the required changes. > > - http://cr.openjdk.java.net/~rraghavan/8171813/webrev.01/ > Believe the changes are now okay to be committed. your change looks good to me. Thank you! Best regards, Zoltan > > Thanks, > Rahul > >> -----Original Message----- >> From: Tobias Hartmann >> Sent: Monday, April 03, 2017 11:53 AM >> To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net; Vladimir Kozlov; Zoltan Majo >> Subject: Re: [10] RFR: 8171813: possible null pointer dereference defects >> >> Hi Rahul, >> >> On 31.03.2017 17:48, Rahul Raghavan wrote: >>> Please review following patch proposal to avoid >>> possible null pointer dereference warnings / errors for internal tests. >>> >>> - http://cr.openjdk.java.net/~rraghavan/8171813/webrev.00/ >> Please compare against NULL instead of casting to bool, i.e. use "if (compiler != NULL)" instead of "if (compiler)". >> >> In simpleThresholdPolicy.inline.hpp:80, please move the * to the type: use "AbstractCompiler* comp" instead of "AbstractCompiler >> *comp". >> >> Thanks, >> Tobias From george.triantafillou at oracle.com Fri Apr 7 14:47:03 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 7 Apr 2017 10:47:03 -0400 Subject: RFR 8150388: Remove SPARC 32-bit support Message-ID: (Adding compiler). Please review this fix to remove SPARC 32-bit support. Support for solaris-sparc has been dropped from the list of supported platforms. JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 webrev: http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. Thanks. -George -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.triantafillou at oracle.com Fri Apr 7 15:04:22 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 7 Apr 2017 11:04:22 -0400 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: References: <2f1f97e9-8b33-c7ba-4eb7-3605ba82922a@oracle.com> Message-ID: Thanks Harold, I've made the suggested changes. -George On 4/7/2017 10:34 AM, harold seigel wrote: > Hi George, > > Most of the changes look good. A few comments: > > 1. In stubGenerator_sparc.cpp, lines 831-835 should not be deleted, > just the "&& defined(_LP64)" > > 831 #if defined(ASSERT) && defined(_LP64) > 832 __ signx(Rint, Rtmp); > 833 __ cmp(Rint, Rtmp); > 834 __ breakpoint_trap(Assembler::notEqual, Assembler::xcc); > 835 #endif > > 2. In atomic_solaris_sparc.hpp: remove lines 245 and 372 > > 3. In prefetch_solaris_sparc.inline, remove lines 30 and 63 > > 4. In thread_solaris_sparc.hpp, remove line 67. > > Thanks, Harold > > On 4/7/2017 9:43 AM, George Triantafillou wrote: >> Please review this fix to remove SPARC 32-bit support. Support for >> solaris-sparc has been dropped from the list of supported platforms. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 >> webrev: >> http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ >> >> >> Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the >> nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. >> >> Thanks. >> >> -George >> > From vladimir.kozlov at oracle.com Fri Apr 7 17:26:27 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 7 Apr 2017 10:26:27 -0700 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: References: <2f1f97e9-8b33-c7ba-4eb7-3605ba82922a@oracle.com> Message-ID: On 4/7/17 8:04 AM, George Triantafillou wrote: > Thanks Harold, I've made the suggested changes. > > -George > > On 4/7/2017 10:34 AM, harold seigel wrote: >> Hi George, >> >> Most of the changes look good. A few comments: >> >> 1. In stubGenerator_sparc.cpp, lines 831-835 should not be deleted, >> just the "&& defined(_LP64)" >> >> 831 #if defined(ASSERT) && defined(_LP64) >> 832 __ signx(Rint, Rtmp); >> 833 __ cmp(Rint, Rtmp); >> 834 __ breakpoint_trap(Assembler::notEqual, Assembler::xcc); >> 835 #endif I still see this code is removed. Did you updated webrev? >> >> 2. In atomic_solaris_sparc.hpp: remove lines 245 and 372 >> >> 3. In prefetch_solaris_sparc.inline.hpp, remove lines 30 and 63 Yes. We don't build JVM with C1 only for 64 bit. >> >> 4. In thread_solaris_sparc.hpp, remove line 67. Yes. Other compiler code changes seems fine. Thanks, Vladimir >> >> Thanks, Harold >> >> On 4/7/2017 9:43 AM, George Triantafillou wrote: >>> Please review this fix to remove SPARC 32-bit support. Support for >>> solaris-sparc has been dropped from the list of supported platforms. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 >>> webrev: >>> http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ >>> >>> >>> Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the >>> nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. >>> >>> Thanks. >>> >>> -George >>> >> > From vladimir.kozlov at oracle.com Fri Apr 7 17:34:48 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 7 Apr 2017 10:34:48 -0700 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: References: <2f1f97e9-8b33-c7ba-4eb7-3605ba82922a@oracle.com> Message-ID: <33e0aee4-0c6d-bef0-e871-6d1ef3b44434@oracle.com> Hi George, I noticed that you did not changed code guarded by NOT_LP64() and LP64_ONLY() macros. Also the code in src/os_cpu/linux_sparc/vm is not changed. Vladimir On 4/7/17 10:26 AM, Vladimir Kozlov wrote: > On 4/7/17 8:04 AM, George Triantafillou wrote: >> Thanks Harold, I've made the suggested changes. >> >> -George >> >> On 4/7/2017 10:34 AM, harold seigel wrote: >>> Hi George, >>> >>> Most of the changes look good. A few comments: >>> >>> 1. In stubGenerator_sparc.cpp, lines 831-835 should not be deleted, >>> just the "&& defined(_LP64)" >>> >>> 831 #if defined(ASSERT) && defined(_LP64) >>> 832 __ signx(Rint, Rtmp); >>> 833 __ cmp(Rint, Rtmp); >>> 834 __ breakpoint_trap(Assembler::notEqual, Assembler::xcc); >>> 835 #endif > > I still see this code is removed. Did you updated webrev? > >>> >>> 2. In atomic_solaris_sparc.hpp: remove lines 245 and 372 >>> >>> 3. In prefetch_solaris_sparc.inline.hpp, remove lines 30 and 63 > > Yes. We don't build JVM with C1 only for 64 bit. > >>> >>> 4. In thread_solaris_sparc.hpp, remove line 67. > > Yes. > > Other compiler code changes seems fine. > > Thanks, > Vladimir > >>> >>> Thanks, Harold >>> >>> On 4/7/2017 9:43 AM, George Triantafillou wrote: >>>> Please review this fix to remove SPARC 32-bit support. Support for >>>> solaris-sparc has been dropped from the list of supported platforms. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 >>>> webrev: >>>> http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ >>>> >>>> >>>> Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the >>>> nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. >>>> >>>> Thanks. >>>> >>>> -George >>>> >>> >> From igor.veresov at oracle.com Fri Apr 7 18:55:18 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 7 Apr 2017 11:55:18 -0700 Subject: RFR(S) 8176887: SIGSEGV in AOTCodeHeap::next when using specific configuration Message-ID: <58D5918F-37B3-49B3-B6A5-944076F68546@oracle.com> The problem here is that AOTCodeHeap::got_metadata_do() iterates over the _metaspace_got array assuming that the array contains Metadata*, indeed the array is declared as such. However it also happens to contain MethodCounters*, and MethodCounters is not Metadata, but MetaspaceObj. The simplest and minimal risk solution is to make MethodCounters a subclass of Metadata (we?d like to have this fix in jdk9). Webrev: http://cr.openjdk.java.net/~iveresov/8176887/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8176887 Thanks! igor From george.triantafillou at oracle.com Fri Apr 7 19:19:14 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 7 Apr 2017 15:19:14 -0400 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: References: <2f1f97e9-8b33-c7ba-4eb7-3605ba82922a@oracle.com> Message-ID: Hi Vladimir, Thanks for your comments. Updated webrev: http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev.01/ -George On 4/7/2017 1:26 PM, Vladimir Kozlov wrote: > On 4/7/17 8:04 AM, George Triantafillou wrote: >> Thanks Harold, I've made the suggested changes. >> >> -George >> >> On 4/7/2017 10:34 AM, harold seigel wrote: >>> Hi George, >>> >>> Most of the changes look good. A few comments: >>> >>> 1. In stubGenerator_sparc.cpp, lines 831-835 should not be deleted, >>> just the "&& defined(_LP64)" >>> >>> 831 #if defined(ASSERT) && defined(_LP64) >>> 832 __ signx(Rint, Rtmp); >>> 833 __ cmp(Rint, Rtmp); >>> 834 __ breakpoint_trap(Assembler::notEqual, Assembler::xcc); >>> 835 #endif > > I still see this code is removed. Did you updated webrev? > >>> >>> 2. In atomic_solaris_sparc.hpp: remove lines 245 and 372 >>> >>> 3. In prefetch_solaris_sparc.inline.hpp, remove lines 30 and 63 > > Yes. We don't build JVM with C1 only for 64 bit. > >>> >>> 4. In thread_solaris_sparc.hpp, remove line 67. > > Yes. > > Other compiler code changes seems fine. > > Thanks, > Vladimir > >>> >>> Thanks, Harold >>> >>> On 4/7/2017 9:43 AM, George Triantafillou wrote: >>>> Please review this fix to remove SPARC 32-bit support. Support for >>>> solaris-sparc has been dropped from the list of supported platforms. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 >>>> webrev: >>>> http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ >>>> >>>> >>>> Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the >>>> nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. >>>> >>>> Thanks. >>>> >>>> -George >>>> >>> >> From george.triantafillou at oracle.com Fri Apr 7 19:21:24 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 7 Apr 2017 15:21:24 -0400 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: <33e0aee4-0c6d-bef0-e871-6d1ef3b44434@oracle.com> References: <2f1f97e9-8b33-c7ba-4eb7-3605ba82922a@oracle.com> <33e0aee4-0c6d-bef0-e871-6d1ef3b44434@oracle.com> Message-ID: Hi Vladimir, On 4/7/2017 1:34 PM, Vladimir Kozlov wrote: > Hi George, > > I noticed that you did not changed code guarded by NOT_LP64() and > LP64_ONLY() macros. > > Also the code in src/os_cpu/linux_sparc/vm is not changed. My understanding is that this issue only covers solaris_sparc. -George > > Vladimir > > On 4/7/17 10:26 AM, Vladimir Kozlov wrote: >> On 4/7/17 8:04 AM, George Triantafillou wrote: >>> Thanks Harold, I've made the suggested changes. >>> >>> -George >>> >>> On 4/7/2017 10:34 AM, harold seigel wrote: >>>> Hi George, >>>> >>>> Most of the changes look good. A few comments: >>>> >>>> 1. In stubGenerator_sparc.cpp, lines 831-835 should not be deleted, >>>> just the "&& defined(_LP64)" >>>> >>>> 831 #if defined(ASSERT) && defined(_LP64) >>>> 832 __ signx(Rint, Rtmp); >>>> 833 __ cmp(Rint, Rtmp); >>>> 834 __ breakpoint_trap(Assembler::notEqual, Assembler::xcc); >>>> 835 #endif >> >> I still see this code is removed. Did you updated webrev? >> >>>> >>>> 2. In atomic_solaris_sparc.hpp: remove lines 245 and 372 >>>> >>>> 3. In prefetch_solaris_sparc.inline.hpp, remove lines 30 and 63 >> >> Yes. We don't build JVM with C1 only for 64 bit. >> >>>> >>>> 4. In thread_solaris_sparc.hpp, remove line 67. >> >> Yes. >> >> Other compiler code changes seems fine. >> >> Thanks, >> Vladimir >> >>>> >>>> Thanks, Harold >>>> >>>> On 4/7/2017 9:43 AM, George Triantafillou wrote: >>>>> Please review this fix to remove SPARC 32-bit support. Support for >>>>> solaris-sparc has been dropped from the list of supported platforms. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ >>>>> >>>>> >>>>> Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the >>>>> nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. >>>>> >>>>> Thanks. >>>>> >>>>> -George >>>>> >>>> >>> From igor.veresov at oracle.com Fri Apr 7 19:21:30 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 7 Apr 2017 12:21:30 -0700 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: References: Message-ID: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> Looks good to me. igor > On Apr 6, 2017, at 9:48 PM, Kim Barrett wrote: > > Please review this change to Type's ideal_reg to make its return type > consistent with the closely related Node::ideal_reg(). Where Type > used to be an int, it is now a uint. This eliminates the implicit > narrowing conversion in the initialization of _type_info that caused > build failure for C++11 (gcc with -std=gnu++11 or (not tested, but > presumed fixed) Visual Studio 2015 or later). > > Also fixed a number of places where the result of Node::ideal_reg() > was being treated as int rather than uint. > > And since I was in the neighborhood (changing the type of > Type::TypeInfo::ideal_reg), also fixed Type::_type_info[] to be const > as apparently intended but not successfully accomplished. (The msg > member was writable, forcing allocation of the array to be in writable > memory, rather than read-only.) > > CR: > https://bugs.openjdk.java.net/browse/JDK-8160748 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.00/ > > Testing: > JPRT, rbt hs-tier2,hs-tier3,hs-tier4-comp,hs-tier5-comp > From igor.ignatyev at oracle.com Fri Apr 7 19:38:18 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 7 Apr 2017 12:38:18 -0700 Subject: RFR(XS) : 8178333: CTW/PathHandler uses == instead of String::equals for string comparison Message-ID: http://cr.openjdk.java.net/~iignatyev/8178333/webrev.00/index.html > 4 lines changed: 1 ins; 0 del; 3 mod; Hi all, could you please review this tiny fix? == was mistakenly used instead of String::equals in PathHandler. webrev: http://cr.openjdk.java.net/~iignatyev/8178333/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8178333 testing: hotspot/test/testlibrary_tests/ctw Thanks, -- Igor From vladimir.kozlov at oracle.com Fri Apr 7 20:29:24 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 7 Apr 2017 13:29:24 -0700 Subject: RFR(S) 8176887: SIGSEGV in AOTCodeHeap::next when using specific configuration In-Reply-To: <58D5918F-37B3-49B3-B6A5-944076F68546@oracle.com> References: <58D5918F-37B3-49B3-B6A5-944076F68546@oracle.com> Message-ID: This could be good fix for JDK 9. Are you sure that functions called for Metadata scan will not barf on MethodCounters? You need also ask Runtime group to look on this change. When fixing 8173794 I missed this case (MethodCounters*). We should not put them into metaspace_got array since GC don't need to process them. And they increase metaspace_got array significantly. For 10 we should fix JAPTC code - metaspace_got array should contain only Klass* pointers. May be to add a separate array since extLinkageGOTContainer may not right for MethodCounters*. Thanks, Vladimir On 4/7/17 11:55 AM, Igor Veresov wrote: > The problem here is that AOTCodeHeap::got_metadata_do() iterates over the _metaspace_got array assuming that the array contains Metadata*, indeed the array is declared as such. However it also happens to contain MethodCounters*, and MethodCounters is not Metadata, but MetaspaceObj. The simplest and minimal risk solution is to make MethodCounters a subclass of Metadata (we?d like to have this fix in jdk9). > > > Webrev: http://cr.openjdk.java.net/~iveresov/8176887/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8176887 > > Thanks! > igor > From vladimir.kozlov at oracle.com Fri Apr 7 20:32:57 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 7 Apr 2017 13:32:57 -0700 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: References: <2f1f97e9-8b33-c7ba-4eb7-3605ba82922a@oracle.com> <33e0aee4-0c6d-bef0-e871-6d1ef3b44434@oracle.com> Message-ID: <304ec69a-c397-70de-0cb1-baac10b764c2@oracle.com> We will never support 32-bit VM in future JDK releases on all SPARC platforms which includes Linux (we only build 64 bit JDK on it)! So you need to clean it too. Vladimir On 4/7/17 12:21 PM, George Triantafillou wrote: > Hi Vladimir, > > On 4/7/2017 1:34 PM, Vladimir Kozlov wrote: >> Hi George, >> >> I noticed that you did not changed code guarded by NOT_LP64() and >> LP64_ONLY() macros. >> >> Also the code in src/os_cpu/linux_sparc/vm is not changed. > My understanding is that this issue only covers solaris_sparc. > > -George >> >> Vladimir >> >> On 4/7/17 10:26 AM, Vladimir Kozlov wrote: >>> On 4/7/17 8:04 AM, George Triantafillou wrote: >>>> Thanks Harold, I've made the suggested changes. >>>> >>>> -George >>>> >>>> On 4/7/2017 10:34 AM, harold seigel wrote: >>>>> Hi George, >>>>> >>>>> Most of the changes look good. A few comments: >>>>> >>>>> 1. In stubGenerator_sparc.cpp, lines 831-835 should not be deleted, >>>>> just the "&& defined(_LP64)" >>>>> >>>>> 831 #if defined(ASSERT) && defined(_LP64) >>>>> 832 __ signx(Rint, Rtmp); >>>>> 833 __ cmp(Rint, Rtmp); >>>>> 834 __ breakpoint_trap(Assembler::notEqual, Assembler::xcc); >>>>> 835 #endif >>> >>> I still see this code is removed. Did you updated webrev? >>> >>>>> >>>>> 2. In atomic_solaris_sparc.hpp: remove lines 245 and 372 >>>>> >>>>> 3. In prefetch_solaris_sparc.inline.hpp, remove lines 30 and 63 >>> >>> Yes. We don't build JVM with C1 only for 64 bit. >>> >>>>> >>>>> 4. In thread_solaris_sparc.hpp, remove line 67. >>> >>> Yes. >>> >>> Other compiler code changes seems fine. >>> >>> Thanks, >>> Vladimir >>> >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 4/7/2017 9:43 AM, George Triantafillou wrote: >>>>>> Please review this fix to remove SPARC 32-bit support. Support for >>>>>> solaris-sparc has been dropped from the list of supported platforms. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ >>>>>> >>>>>> >>>>>> Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the >>>>>> nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -George >>>>>> >>>>> >>>> > From vladimir.kozlov at oracle.com Fri Apr 7 20:34:48 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 7 Apr 2017 13:34:48 -0700 Subject: RFR(XS) : 8178333: CTW/PathHandler uses == instead of String::equals for string comparison In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 4/7/17 12:38 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8178333/webrev.00/index.html >> 4 lines changed: 1 ins; 0 del; 3 mod; > > Hi all, > > could you please review this tiny fix? == was mistakenly used instead of String::equals in PathHandler. > > webrev: http://cr.openjdk.java.net/~iignatyev/8178333/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8178333 > testing: hotspot/test/testlibrary_tests/ctw > > Thanks, > -- Igor > From kim.barrett at oracle.com Fri Apr 7 20:41:14 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 7 Apr 2017 16:41:14 -0400 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> References: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> Message-ID: <9D07D3A3-01E6-4432-8261-F20487C91428@oracle.com> > On Apr 7, 2017, at 3:21 PM, Igor Veresov wrote: > > Looks good to me. > > igor Thanks Igor. > >> On Apr 6, 2017, at 9:48 PM, Kim Barrett wrote: >> >> Please review this change to Type's ideal_reg to make its return type >> consistent with the closely related Node::ideal_reg(). Where Type >> used to be an int, it is now a uint. This eliminates the implicit >> narrowing conversion in the initialization of _type_info that caused >> build failure for C++11 (gcc with -std=gnu++11 or (not tested, but >> presumed fixed) Visual Studio 2015 or later). >> >> Also fixed a number of places where the result of Node::ideal_reg() >> was being treated as int rather than uint. >> >> And since I was in the neighborhood (changing the type of >> Type::TypeInfo::ideal_reg), also fixed Type::_type_info[] to be const >> as apparently intended but not successfully accomplished. (The msg >> member was writable, forcing allocation of the array to be in writable >> memory, rather than read-only.) >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8160748 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.00/ >> >> Testing: >> JPRT, rbt hs-tier2,hs-tier3,hs-tier4-comp,hs-tier5-comp From igor.veresov at oracle.com Fri Apr 7 21:33:08 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 7 Apr 2017 14:33:08 -0700 Subject: RFR(S) 8176887: SIGSEGV in AOTCodeHeap::next when using specific configuration In-Reply-To: References: <58D5918F-37B3-49B3-B6A5-944076F68546@oracle.com> Message-ID: <55E1501F-E358-492A-BD04-94B0F2AC2AD7@oracle.com> > On Apr 7, 2017, at 1:29 PM, Vladimir Kozlov wrote: > > This could be good fix for JDK 9. > > Are you sure that functions called for Metadata scan will not barf on MethodCounters? Yes, there shouldn?t be any problems. In the context of class redefinition it calls mark_on_stack(), which is empty by default except for Method and ConstantPool. > > You need also ask Runtime group to look on this change. CCing the runtime mail list. Guys, any objections to making MethodCounters a Metadata ? > > When fixing 8173794 I missed this case (MethodCounters*). We should not put them into metaspace_got array since GC don't need to process them. And they increase metaspace_got array significantly. > > For 10 we should fix JAPTC code - metaspace_got array should contain only Klass* pointers. May be to add a separate array since extLinkageGOTContainer may not right for MethodCounters*. In the context of class redefinition the scan is actually interested only in methods, rather than classes. Going forward, yes, it would probably be better if we had separate GOT arrays for each MetaspaceObj subtype, so that we can separate Methods out and scan only them. igor > > Thanks, > Vladimir > > On 4/7/17 11:55 AM, Igor Veresov wrote: >> The problem here is that AOTCodeHeap::got_metadata_do() iterates over the _metaspace_got array assuming that the array contains Metadata*, indeed the array is declared as such. However it also happens to contain MethodCounters*, and MethodCounters is not Metadata, but MetaspaceObj. The simplest and minimal risk solution is to make MethodCounters a subclass of Metadata (we?d like to have this fix in jdk9). >> >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8176887/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8176887 >> >> Thanks! >> igor >> From rahul.v.raghavan at oracle.com Mon Apr 10 03:31:48 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Sun, 9 Apr 2017 20:31:48 -0700 (PDT) Subject: [10] RFR: 8171813: possible null pointer dereference defects In-Reply-To: <95cf497c-1a35-554f-8a95-13ef287393a1@oracle.com> References: <0f0ef598-49a6-443b-a1ab-502335167a98@default> <95cf497c-1a35-554f-8a95-13ef287393a1@oracle.com> Message-ID: <53377e8d-6803-4d55-85d5-90a9b7c528c3@default> Thank you Zoltan. > -----Original Message----- > From: Zolt?n Maj? > Sent: Friday, April 07, 2017 8:08 PM > To: Rahul Raghavan; Tobias Hartmann; hotspot-compiler-dev at openjdk.java.net > Subject: Re: [10] RFR: 8171813: possible null pointer dereference defects > > Hi Rahul, > > > On 04/06/2017 08:27 AM, Rahul Raghavan wrote: > > Hi, > > > > Thank you Tobias for the review comments. > > Sorry for my oversight and yes now included the required changes. > > > > - http://cr.openjdk.java.net/~rraghavan/8171813/webrev.01/ > > Believe the changes are now okay to be committed. > > your change looks good to me. Thank you! > > Best regards, > > > Zoltan > > > > > Thanks, > > Rahul > > From rwestrel at redhat.com Mon Apr 10 07:13:14 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 10 Apr 2017 09:13:14 +0200 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> Message-ID: > Looks ok to me too Roland. Thanks for reviewing this, Michael. Roland. From per.liden at oracle.com Mon Apr 10 07:54:39 2017 From: per.liden at oracle.com (Per Liden) Date: Mon, 10 Apr 2017 09:54:39 +0200 Subject: RFR(s): 8178363: Incorrect check for nmethod re-registration in C1 In-Reply-To: <83e5e130-9c55-0cab-238b-fd8efea103f7@oracle.com> References: <9f8a9ea6-b067-37e4-57ea-bcc22a26426e@oracle.com> <83e5e130-9c55-0cab-238b-fd8efea103f7@oracle.com> Message-ID: Hi Stefan, On 2017-04-10 09:31, Stefan Karlsson wrote: > On 2017-04-10 09:05, Per Liden wrote: >> Hi, >> >> When an nmethod is compiled, it's registered with the heap if >> ScavengeRootsInCode is non-zero (which it always is). However, during >> code patching in C1 we re-register the nmethod with the heap only if it >> also has scavengable oops. This additional requirement is only valid for >> calls to CodeCache::add_scavenge_root_nmethod(), and not for >> CollectedHeap::register_nmethod(). This happens to work today since G1's >> is_scavengable() basically always returns true. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178363 >> Webrev: http://cr.openjdk.java.net/~pliden/8178363/webrev.0/ >> Testing: jprt > > Looks good, from a GC perspective. Thanks for reviewing! > > For non-G1 GCs, we now, unnecessarily, take the CodCache lock and call > find_nmethod even when mirror and appendix are non-scavengable. Maybe > this should be reviewed on hotspot-comp-dev as well? Sure, adding comp-dev. thanks, Per > > Thanks, > StefanK > >> >> cheers, >> Per From vladimir.x.ivanov at oracle.com Mon Apr 10 16:23:18 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 10 Apr 2017 19:23:18 +0300 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> Message-ID: I'll sponsor the fix. Best regards, Vladimir Ivanov On 4/10/17 10:13 AM, Roland Westrelin wrote: > >> Looks ok to me too Roland. > > Thanks for reviewing this, Michael. > > Roland. > From vladimir.kempik at oracle.com Mon Apr 10 17:18:40 2017 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Mon, 10 Apr 2017 20:18:40 +0300 Subject: [8u] RFR 8173373: C1: NPE is thrown instead of LinkageError when accessing inaccessible field on NULL receiver Message-ID: <3234f84b-ed79-1ec2-df81-cde77e850c07@oracle.com> Hello Please review this backport of 8173373 for jdk8u. The fix applied cleanly to jdk8, except one place: in src/share/vm/c1/c1_LIR.cpp I had to change + CodeStub* deopt = new DeoptimizeStub(info, Deoptimization::Reason_null_check, Deoptimization::Action_none); to + CodeStub* deopt = new DeoptimizeStub(info); The fix passes jprt and testcase. Bug: https://bugs.openjdk.java.net/browse/JDK-8173373 Webrev: http://cr.openjdk.java.net/~vkempik/8173373/webrev.00/ Thanks -Vladimir From vladimir.x.ivanov at oracle.com Mon Apr 10 17:27:46 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 10 Apr 2017 20:27:46 +0300 Subject: [8u] RFR 8173373: C1: NPE is thrown instead of LinkageError when accessing inaccessible field on NULL receiver In-Reply-To: <3234f84b-ed79-1ec2-df81-cde77e850c07@oracle.com> References: <3234f84b-ed79-1ec2-df81-cde77e850c07@oracle.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 4/10/17 8:18 PM, Vladimir Kempik wrote: > Hello > > Please review this backport of 8173373 for jdk8u. > > The fix applied cleanly to jdk8, except one place: > > in src/share/vm/c1/c1_LIR.cpp > > I had to change > > + CodeStub* deopt = new DeoptimizeStub(info, > Deoptimization::Reason_null_check, Deoptimization::Action_none); > > to > > + CodeStub* deopt = new DeoptimizeStub(info); > > The fix passes jprt and testcase. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173373 > Webrev: http://cr.openjdk.java.net/~vkempik/8173373/webrev.00/ > > Thanks > -Vladimir > From vladimir.kozlov at oracle.com Mon Apr 10 19:43:03 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Apr 2017 12:43:03 -0700 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> References: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> Message-ID: <138b60b8-51d9-e8fc-62c0-457c7b4cb40f@oracle.com> Hi, Kim Please, also correct vector registers (need to fix *.ad files too): // Vector ideal reg static const int vector_ideal_reg(int len); static const int vector_shift_count_ideal_reg(int len); Can you do the same for OptoReg::reg2stack()? Or file separate RFE for it. Thanks, Vladimir On 4/7/17 12:21 PM, Igor Veresov wrote: > Looks good to me. > > igor > >> On Apr 6, 2017, at 9:48 PM, Kim Barrett wrote: >> >> Please review this change to Type's ideal_reg to make its return type >> consistent with the closely related Node::ideal_reg(). Where Type >> used to be an int, it is now a uint. This eliminates the implicit >> narrowing conversion in the initialization of _type_info that caused >> build failure for C++11 (gcc with -std=gnu++11 or (not tested, but >> presumed fixed) Visual Studio 2015 or later). >> >> Also fixed a number of places where the result of Node::ideal_reg() >> was being treated as int rather than uint. >> >> And since I was in the neighborhood (changing the type of >> Type::TypeInfo::ideal_reg), also fixed Type::_type_info[] to be const >> as apparently intended but not successfully accomplished. (The msg >> member was writable, forcing allocation of the array to be in writable >> memory, rather than read-only.) >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8160748 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.00/ >> >> Testing: >> JPRT, rbt hs-tier2,hs-tier3,hs-tier4-comp,hs-tier5-comp >> > From igor.veresov at oracle.com Mon Apr 10 19:48:10 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 10 Apr 2017 12:48:10 -0700 Subject: RFR(S) 8176887: SIGSEGV in AOTCodeHeap::next when using specific configuration In-Reply-To: <6A4AB813-BCAB-44C0-BC79-44ACAC9DED6C@oracle.com> References: <58D5918F-37B3-49B3-B6A5-944076F68546@oracle.com> <55E1501F-E358-492A-BD04-94B0F2AC2AD7@oracle.com> <75975c80-65e9-d8ed-f183-21af950f5032@oracle.com> <6A4AB813-BCAB-44C0-BC79-44ACAC9DED6C@oracle.com> Message-ID: So? I?m ok to assume that you?re ok with this fix for the time being? igor > On Apr 7, 2017, at 3:43 PM, Igor Veresov wrote: > >> >> On Apr 7, 2017, at 2:36 PM, coleen.phillimore at oracle.com wrote: >> >> >> >> On 4/7/17 5:33 PM, Igor Veresov wrote: >>>> On Apr 7, 2017, at 1:29 PM, Vladimir Kozlov wrote: >>>> >>>> This could be good fix for JDK 9. >>>> >>>> Are you sure that functions called for Metadata scan will not barf on MethodCounters? >>> Yes, there shouldn?t be any problems. In the context of class redefinition it calls mark_on_stack(), which is empty by default except for Method and ConstantPool. >>> >>>> You need also ask Runtime group to look on this change. >>> CCing the runtime mail list. Guys, any objections to making MethodCounters a Metadata ? >> >> If you make MethodCounters inherited by Metadata it will have a vptr. It doesn't otherwise. > > Yes, but I?d have to have some type id to filter them out anyway (if they are in an array with other metaspace objects), having a vtbl seems like an equivalent solution. > >>> >>>> When fixing 8173794 I missed this case (MethodCounters*). We should not put them into metaspace_got array since GC don't need to process them. And they increase metaspace_got array significantly. >>>> >>>> For 10 we should fix JAPTC code - metaspace_got array should contain only Klass* pointers. May be to add a separate array since extLinkageGOTContainer may not right for MethodCounters*. >>> >>> In the context of class redefinition the scan is actually interested only in methods, rather than classes. Going forward, yes, it would probably be better if we had separate GOT arrays for each MetaspaceObj subtype, so that we can separate Methods out and scan only them. >> >> Can you have a special array for Method*s? > > Yes, that?s what would be best to do in the future. But it is a substantially bigger change, I?m not sure it would be appropriate for 9 at this point. > > igor > >> Coleen >> >>> igor >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/7/17 11:55 AM, Igor Veresov wrote: >>>>> The problem here is that AOTCodeHeap::got_metadata_do() iterates over the _metaspace_got array assuming that the array contains Metadata*, indeed the array is declared as such. However it also happens to contain MethodCounters*, and MethodCounters is not Metadata, but MetaspaceObj. The simplest and minimal risk solution is to make MethodCounters a subclass of Metadata (we?d like to have this fix in jdk9). >>>>> >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8176887/webrev.00/ >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176887 >>>>> >>>>> Thanks! >>>>> igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Mon Apr 10 20:22:51 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 10 Apr 2017 16:22:51 -0400 Subject: RFR(S) 8176887: SIGSEGV in AOTCodeHeap::next when using specific configuration In-Reply-To: References: <58D5918F-37B3-49B3-B6A5-944076F68546@oracle.com> <55E1501F-E358-492A-BD04-94B0F2AC2AD7@oracle.com> <75975c80-65e9-d8ed-f183-21af950f5032@oracle.com> <6A4AB813-BCAB-44C0-BC79-44ACAC9DED6C@oracle.com> Message-ID: <3d22d236-97f9-95af-8f43-4454679c5b54@oracle.com> On 4/10/17 3:48 PM, Igor Veresov wrote: > So? I?m ok to assume that you?re ok with this fix for the time being? If these MethodCounters aren't added to the CDS archive, then the vptr only adds space and I think it's ok for now. Coleen > > igor > >> On Apr 7, 2017, at 3:43 PM, Igor Veresov > > wrote: >> >>> >>> On Apr 7, 2017, at 2:36 PM, coleen.phillimore at oracle.com >>> wrote: >>> >>> >>> >>> On 4/7/17 5:33 PM, Igor Veresov wrote: >>>>> On Apr 7, 2017, at 1:29 PM, Vladimir Kozlov >>>>> > >>>>> wrote: >>>>> >>>>> This could be good fix for JDK 9. >>>>> >>>>> Are you sure that functions called for Metadata scan will not barf >>>>> on MethodCounters? >>>> Yes, there shouldn?t be any problems. In the context of class >>>> redefinition it calls mark_on_stack(), which is empty by default >>>> except for Method and ConstantPool. >>>> >>>>> You need also ask Runtime group to look on this change. >>>> CCing the runtime mail list. Guys, any objections to making >>>> MethodCounters a Metadata ? >>> >>> If you make MethodCounters inherited by Metadata it will have a >>> vptr. It doesn't otherwise. >> >> Yes, but I?d have to have some type id to filter them out anyway (if >> they are in an array with other metaspace objects), having a vtbl >> seems like an equivalent solution. >> >>>> >>>>> When fixing 8173794 I missed this case (MethodCounters*). We >>>>> should not put them into metaspace_got array since GC don't need >>>>> to process them. And they increase metaspace_got array significantly. >>>>> >>>>> For 10 we should fix JAPTC code - metaspace_got array should >>>>> contain only Klass* pointers. May be to add a separate array since >>>>> extLinkageGOTContainer may not right for MethodCounters*. >>>> >>>> In the context of class redefinition the scan is actually >>>> interested only in methods, rather than classes. Going forward, >>>> yes, it would probably be better if we had separate GOT arrays for >>>> each MetaspaceObj subtype, so that we can separate Methods out and >>>> scan only them. >>> >>> Can you have a special array for Method*s? >> >> Yes, that?s what would be best to do in the future. But it is a >> substantially bigger change, I?m not sure it would be appropriate for >> 9 at this point. >> >> igor >> >>> Coleen >>> >>>> igor >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 4/7/17 11:55 AM, Igor Veresov wrote: >>>>>> The problem here is that AOTCodeHeap::got_metadata_do() iterates >>>>>> over the _metaspace_got array assuming that the array contains >>>>>> Metadata*, indeed the array is declared as such. However it also >>>>>> happens to contain MethodCounters*, and MethodCounters is not >>>>>> Metadata, but MetaspaceObj. The simplest and minimal risk >>>>>> solution is to make MethodCounters a subclass of Metadata (we?d >>>>>> like to have this fix in jdk9). >>>>>> >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8176887/webrev.00/ >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176887 >>>>>> >>>>>> Thanks! >>>>>> igor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Mon Apr 10 21:12:25 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 10 Apr 2017 17:12:25 -0400 Subject: RFR 8026985: Rewrite SystemDictionary::classes_do and Dictionary::classes_do to use KlassClosure In-Reply-To: <7B03B1D3-57B2-44D7-8B89-8C729B20B31A@oracle.com> References: <2ae47703-2c17-548c-f278-2c25647f1cc7@oracle.com> <913ac7b4-affe-0e69-b5dd-95e6727514c0@oracle.com> <7B03B1D3-57B2-44D7-8B89-8C729B20B31A@oracle.com> Message-ID: <22759e6d-0b05-1e34-1e73-5bf3b974ad95@oracle.com> Hi, I've reopened this cleanup. To be clear, I didn't change which of classes_do are called except for two places in this change. One is print_method_profiling_data because it doesn't make sense for this not to print methods for anonymous classes and method handle intrinsics. See SystemDictionary::methods_do() implementation. I added hotspot-compiler-dev to this review so hopefully someone from the compiler group can verify this. The second is heapDumper.cpp because it seemed an obvious bug that if !ClassUnloading that all the classes shouldn't be dumped as STICKY classes. Tested with jvmti and heapdump tests. I've put this data you requested in the bug report as a comment. We could probably file about 4 more bugs to cleanup the calls sites for classes_do, so that the design is clearer, but I didn't want to do it all in this one change and mix it up with the functions that I found were unused and this change got large enough. New webrev: open webrev at http://cr.openjdk.java.net/~coleenp/8026985.03/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8026985 Thanks! Coleen On 3/14/17 10:43 AM, Karen Kinnear wrote: > Coleen, > > I am concerned about exposure of: > 1) not yet loaded classes > 2) scratch-classes > 3) classes that are not live due to JFR, parallel class loading or load errors > > Could you please make us a table of those who walk the classes: > which classes they saw before > which classes they see now - and why the change is ok > what tests you have for each of the boxes in the table - both that you see what you want, and that you do not see > what should not be exposed. > > My understanding is that this is intended to speed up GC but not to change behaviors. > I am concerned about the exposure to non-GC walkers. > > thanks, > Karen > >> On Mar 13, 2017, at 8:30 PM, David Holmes wrote: >> >> Hi Coleen, >> >> On 11/03/2017 12:39 AM, coleen.phillimore at oracle.com wrote: >>> David, Thank you for reviewing. >>> >>> On 3/10/17 12:18 AM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 9/03/2017 2:24 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Clean up and examine uses of classes_do for the >>>>> SystemDictionary >>>>> >>>>> See bug comments for more details. I wanted to clean this up while >>>>> examining the idea of having system dictionary information added per >>>>> ClassLoaderData, rather than a global table. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026985.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026985 >>>> The bulk of the deletion looks good! :) >>>> >>>> I guess my main query is how ClassLoaderDataGraph::classes_do / >>>> loaded_classes_do relate to SystemDictionary::classes_do? I would >>>> presume SD::classes_do can only act on loaded classes - by definition. >>>> So then it is unclear how you can replace it with either of the CLDG >>>> methods? >>> True, loaded_classes_do only walks loaded classes, which is probably >>> what we want most of the time. I was trying to figure this out and the >>> differences which led to this change. I am trying to make it less >>> confusing. At least for me! >>> >>> The ClassLoaderData::classes_do includes anonymous, array and allocated >>> classes. Most of the time we want the first two. For GC we want the >>> last (because it has a mirror to walk). The SystemDictionary only has >>> loaded InstanceKlasses, both with defined loader and initiating >>> loader. Except for one place in the code, we ignore the entries with >>> initiating loader. >> I'm still very unclear as to why it is now okay to expand the set of klasses being walked at a given point. For example: >> >> src/share/vm/oops/klassVtable.cpp >> >> static void compute() { >> - SystemDictionary::classes_do(do_class); >> + ClassLoaderDataGraph::classes_do(do_class); >> >> IIUC SD::classes_do does not see anonymous classes, but CLDG::classes_do does. Why is this okay? >> >> You mentioned bugs like JDK-8024423 "missing anonymous classes" but my limited understanding of that bug suggests to me that the fix was to completely hide anonymous classes not to expose them! They should not be visible to JVM TI as I understand the intent of VM anonymous classes! >> >> Thanks, >> David >> ----- >> >>> The only place where methods_do() is called for all the methods is for >>> print_method_data_histogram and print_method_profiling_data. These >>> should only use loaded classes, so I've made the change below: >>> >>> void ClassLoaderData::methods_do(void f(Method*)) { >>> // Lock-free access requires load_ptr_acquire >>> for (Klass* k = load_ptr_acquire(&_klasses); k != NULL; k = >>> k->next_link()) { >>> if (k->is_instance_klass() && InstanceKlass::cast(k)->is_loaded()) { >>> InstanceKlass::cast(k)->methods_do(f); >>> } >>> } >>> } >>>> It also seems a little odd to switch from SD to CLDG for classes_do, >>>> but go the other way, from CLDG to SD for methods_do ? I would >>>> expect/hope to have a single "entry point" for this kind of iteration. >>> I know. Unfortunately SD::methods_do includes the methods added for >>> MethodHandle intrinsics, which is owned by SystemDictionary. >>> >>> void SystemDictionary::methods_do(void f(Method*)) { >>> ClassLoaderDataGraph::methods_do(f); >>> invoke_method_table()->methods_do(f); >>> } >>> >>> I don't like this either. This invoke_method_table() really has >>> nothing to do with the Dictionary, it's just where it ended up. I could >>> expand the change to find a better place for it. I don't know where >>> would be good though. >>> >>> Aside, I'd forgotten about invoke_method_table - it seems to be a >>> mechanism for isolated methods. >>> >>> Coleen >>> >>>> Thanks, >>>> David >>>> >>>>> Tested with java.lang.instrument, sun.com.jdi, tonga colocated (closed) >>>>> tests, and JPRT, because of difference in which classes_do is called for >>>>> heap dumping. >>>>> >>>>> Note, will update copyrights on commit. >>>>> >>>>> Thanks, >>>>> Coleen From igor.veresov at oracle.com Mon Apr 10 21:13:11 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 10 Apr 2017 14:13:11 -0700 Subject: RFR(S) 8176887: SIGSEGV in AOTCodeHeap::next when using specific configuration In-Reply-To: <3d22d236-97f9-95af-8f43-4454679c5b54@oracle.com> References: <58D5918F-37B3-49B3-B6A5-944076F68546@oracle.com> <55E1501F-E358-492A-BD04-94B0F2AC2AD7@oracle.com> <75975c80-65e9-d8ed-f183-21af950f5032@oracle.com> <6A4AB813-BCAB-44C0-BC79-44ACAC9DED6C@oracle.com> <3d22d236-97f9-95af-8f43-4454679c5b54@oracle.com> Message-ID: <1A4DC886-8121-4D43-B756-C45AEDA7BACC@oracle.com> Thanks, Coleen! igor > On Apr 10, 2017, at 1:22 PM, coleen.phillimore at oracle.com wrote: > > > > On 4/10/17 3:48 PM, Igor Veresov wrote: >> So? I?m ok to assume that you?re ok with this fix for the time being? > > If these MethodCounters aren't added to the CDS archive, then the vptr only adds space and I think it's ok for now. > Coleen > >> >> igor >> >>> On Apr 7, 2017, at 3:43 PM, Igor Veresov > wrote: >>> >>>> >>>> On Apr 7, 2017, at 2:36 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> >>>> On 4/7/17 5:33 PM, Igor Veresov wrote: >>>>>> On Apr 7, 2017, at 1:29 PM, Vladimir Kozlov > wrote: >>>>>> >>>>>> This could be good fix for JDK 9. >>>>>> >>>>>> Are you sure that functions called for Metadata scan will not barf on MethodCounters? >>>>> Yes, there shouldn?t be any problems. In the context of class redefinition it calls mark_on_stack(), which is empty by default except for Method and ConstantPool. >>>>> >>>>>> You need also ask Runtime group to look on this change. >>>>> CCing the runtime mail list. Guys, any objections to making MethodCounters a Metadata ? >>>> >>>> If you make MethodCounters inherited by Metadata it will have a vptr. It doesn't otherwise. >>> >>> Yes, but I?d have to have some type id to filter them out anyway (if they are in an array with other metaspace objects), having a vtbl seems like an equivalent solution. >>> >>>>> >>>>>> When fixing 8173794 I missed this case (MethodCounters*). We should not put them into metaspace_got array since GC don't need to process them. And they increase metaspace_got array significantly. >>>>>> >>>>>> For 10 we should fix JAPTC code - metaspace_got array should contain only Klass* pointers. May be to add a separate array since extLinkageGOTContainer may not right for MethodCounters*. >>>>> >>>>> In the context of class redefinition the scan is actually interested only in methods, rather than classes. Going forward, yes, it would probably be better if we had separate GOT arrays for each MetaspaceObj subtype, so that we can separate Methods out and scan only them. >>>> >>>> Can you have a special array for Method*s? >>> >>> Yes, that?s what would be best to do in the future. But it is a substantially bigger change, I?m not sure it would be appropriate for 9 at this point. >>> >>> igor >>> >>>> Coleen >>>> >>>>> igor >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 4/7/17 11:55 AM, Igor Veresov wrote: >>>>>>> The problem here is that AOTCodeHeap::got_metadata_do() iterates over the _metaspace_got array assuming that the array contains Metadata*, indeed the array is declared as such. However it also happens to contain MethodCounters*, and MethodCounters is not Metadata, but MetaspaceObj. The simplest and minimal risk solution is to make MethodCounters a subclass of Metadata (we?d like to have this fix in jdk9). >>>>>>> >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8176887/webrev.00/ >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176887 >>>>>>> >>>>>>> Thanks! >>>>>>> igor >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Tue Apr 11 00:27:40 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 10 Apr 2017 17:27:40 -0700 Subject: RFR 8026985: Rewrite SystemDictionary::classes_do and Dictionary::classes_do to use KlassClosure In-Reply-To: <22759e6d-0b05-1e34-1e73-5bf3b974ad95@oracle.com> References: <2ae47703-2c17-548c-f278-2c25647f1cc7@oracle.com> <913ac7b4-affe-0e69-b5dd-95e6727514c0@oracle.com> <7B03B1D3-57B2-44D7-8B89-8C729B20B31A@oracle.com> <22759e6d-0b05-1e34-1e73-5bf3b974ad95@oracle.com> Message-ID: <7C357C0C-536A-4A28-87F5-88F31559B29B@oracle.com> Looks good. Amazing how much dead code is there. igor > On Apr 10, 2017, at 2:12 PM, coleen.phillimore at oracle.com wrote: > > > Hi, I've reopened this cleanup. To be clear, I didn't change which of classes_do are called except for two places in this change. > > One is print_method_profiling_data because it doesn't make sense for this not to print methods for anonymous classes and method handle intrinsics. See SystemDictionary::methods_do() implementation. I added hotspot-compiler-dev to this review so hopefully someone from the compiler group can verify this. > > The second is heapDumper.cpp because it seemed an obvious bug that if !ClassUnloading that all the classes shouldn't be dumped as STICKY classes. Tested with jvmti and heapdump tests. > > I've put this data you requested in the bug report as a comment. We could probably file about 4 more bugs to cleanup the calls sites for classes_do, so that the design is clearer, but I didn't want to do it all in this one change and mix it up with the functions that I found were unused and this change got large enough. > > New webrev: > > open webrev at http://cr.openjdk.java.net/~coleenp/8026985.03/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8026985 > > Thanks! > Coleen > > On 3/14/17 10:43 AM, Karen Kinnear wrote: >> Coleen, >> >> I am concerned about exposure of: >> 1) not yet loaded classes >> 2) scratch-classes >> 3) classes that are not live due to JFR, parallel class loading or load errors >> >> Could you please make us a table of those who walk the classes: >> which classes they saw before >> which classes they see now - and why the change is ok >> what tests you have for each of the boxes in the table - both that you see what you want, and that you do not see >> what should not be exposed. >> >> My understanding is that this is intended to speed up GC but not to change behaviors. >> I am concerned about the exposure to non-GC walkers. >> >> thanks, >> Karen >> >>> On Mar 13, 2017, at 8:30 PM, David Holmes wrote: >>> >>> Hi Coleen, >>> >>> On 11/03/2017 12:39 AM, coleen.phillimore at oracle.com wrote: >>>> David, Thank you for reviewing. >>>> >>>> On 3/10/17 12:18 AM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 9/03/2017 2:24 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Clean up and examine uses of classes_do for the >>>>>> SystemDictionary >>>>>> >>>>>> See bug comments for more details. I wanted to clean this up while >>>>>> examining the idea of having system dictionary information added per >>>>>> ClassLoaderData, rather than a global table. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026985.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026985 >>>>> The bulk of the deletion looks good! :) >>>>> >>>>> I guess my main query is how ClassLoaderDataGraph::classes_do / >>>>> loaded_classes_do relate to SystemDictionary::classes_do? I would >>>>> presume SD::classes_do can only act on loaded classes - by definition. >>>>> So then it is unclear how you can replace it with either of the CLDG >>>>> methods? >>>> True, loaded_classes_do only walks loaded classes, which is probably >>>> what we want most of the time. I was trying to figure this out and the >>>> differences which led to this change. I am trying to make it less >>>> confusing. At least for me! >>>> >>>> The ClassLoaderData::classes_do includes anonymous, array and allocated >>>> classes. Most of the time we want the first two. For GC we want the >>>> last (because it has a mirror to walk). The SystemDictionary only has >>>> loaded InstanceKlasses, both with defined loader and initiating >>>> loader. Except for one place in the code, we ignore the entries with >>>> initiating loader. >>> I'm still very unclear as to why it is now okay to expand the set of klasses being walked at a given point. For example: >>> >>> src/share/vm/oops/klassVtable.cpp >>> >>> static void compute() { >>> - SystemDictionary::classes_do(do_class); >>> + ClassLoaderDataGraph::classes_do(do_class); >>> >>> IIUC SD::classes_do does not see anonymous classes, but CLDG::classes_do does. Why is this okay? >>> >>> You mentioned bugs like JDK-8024423 "missing anonymous classes" but my limited understanding of that bug suggests to me that the fix was to completely hide anonymous classes not to expose them! They should not be visible to JVM TI as I understand the intent of VM anonymous classes! >>> >>> Thanks, >>> David >>> ----- >>> >>>> The only place where methods_do() is called for all the methods is for >>>> print_method_data_histogram and print_method_profiling_data. These >>>> should only use loaded classes, so I've made the change below: >>>> >>>> void ClassLoaderData::methods_do(void f(Method*)) { >>>> // Lock-free access requires load_ptr_acquire >>>> for (Klass* k = load_ptr_acquire(&_klasses); k != NULL; k = >>>> k->next_link()) { >>>> if (k->is_instance_klass() && InstanceKlass::cast(k)->is_loaded()) { >>>> InstanceKlass::cast(k)->methods_do(f); >>>> } >>>> } >>>> } >>>>> It also seems a little odd to switch from SD to CLDG for classes_do, >>>>> but go the other way, from CLDG to SD for methods_do ? I would >>>>> expect/hope to have a single "entry point" for this kind of iteration. >>>> I know. Unfortunately SD::methods_do includes the methods added for >>>> MethodHandle intrinsics, which is owned by SystemDictionary. >>>> >>>> void SystemDictionary::methods_do(void f(Method*)) { >>>> ClassLoaderDataGraph::methods_do(f); >>>> invoke_method_table()->methods_do(f); >>>> } >>>> >>>> I don't like this either. This invoke_method_table() really has >>>> nothing to do with the Dictionary, it's just where it ended up. I could >>>> expand the change to find a better place for it. I don't know where >>>> would be good though. >>>> >>>> Aside, I'd forgotten about invoke_method_table - it seems to be a >>>> mechanism for isolated methods. >>>> >>>> Coleen >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Tested with java.lang.instrument, sun.com.jdi, tonga colocated (closed) >>>>>> tests, and JPRT, because of difference in which classes_do is called for >>>>>> heap dumping. >>>>>> >>>>>> Note, will update copyrights on commit. >>>>>> >>>>>> Thanks, >>>>>> Coleen > From igor.veresov at oracle.com Tue Apr 11 00:59:51 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 10 Apr 2017 17:59:51 -0700 Subject: RFR(S) 8176887: SIGSEGV in AOTCodeHeap::next when using specific configuration In-Reply-To: <1A4DC886-8121-4D43-B756-C45AEDA7BACC@oracle.com> References: <58D5918F-37B3-49B3-B6A5-944076F68546@oracle.com> <55E1501F-E358-492A-BD04-94B0F2AC2AD7@oracle.com> <75975c80-65e9-d8ed-f183-21af950f5032@oracle.com> <6A4AB813-BCAB-44C0-BC79-44ACAC9DED6C@oracle.com> <3d22d236-97f9-95af-8f43-4454679c5b54@oracle.com> <1A4DC886-8121-4D43-B756-C45AEDA7BACC@oracle.com> Message-ID: Vladimir, so are you ok with us pushing this? igor > On Apr 10, 2017, at 2:13 PM, Igor Veresov wrote: > > Thanks, Coleen! > > igor > >> On Apr 10, 2017, at 1:22 PM, coleen.phillimore at oracle.com wrote: >> >> >> >> On 4/10/17 3:48 PM, Igor Veresov wrote: >>> So? I?m ok to assume that you?re ok with this fix for the time being? >> >> If these MethodCounters aren't added to the CDS archive, then the vptr only adds space and I think it's ok for now. >> Coleen >> >>> >>> igor >>> >>>> On Apr 7, 2017, at 3:43 PM, Igor Veresov > wrote: >>>> >>>>> >>>>> On Apr 7, 2017, at 2:36 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> >>>>> On 4/7/17 5:33 PM, Igor Veresov wrote: >>>>>>> On Apr 7, 2017, at 1:29 PM, Vladimir Kozlov > wrote: >>>>>>> >>>>>>> This could be good fix for JDK 9. >>>>>>> >>>>>>> Are you sure that functions called for Metadata scan will not barf on MethodCounters? >>>>>> Yes, there shouldn?t be any problems. In the context of class redefinition it calls mark_on_stack(), which is empty by default except for Method and ConstantPool. >>>>>> >>>>>>> You need also ask Runtime group to look on this change. >>>>>> CCing the runtime mail list. Guys, any objections to making MethodCounters a Metadata ? >>>>> >>>>> If you make MethodCounters inherited by Metadata it will have a vptr. It doesn't otherwise. >>>> >>>> Yes, but I?d have to have some type id to filter them out anyway (if they are in an array with other metaspace objects), having a vtbl seems like an equivalent solution. >>>> >>>>>> >>>>>>> When fixing 8173794 I missed this case (MethodCounters*). We should not put them into metaspace_got array since GC don't need to process them. And they increase metaspace_got array significantly. >>>>>>> >>>>>>> For 10 we should fix JAPTC code - metaspace_got array should contain only Klass* pointers. May be to add a separate array since extLinkageGOTContainer may not right for MethodCounters*. >>>>>> >>>>>> In the context of class redefinition the scan is actually interested only in methods, rather than classes. Going forward, yes, it would probably be better if we had separate GOT arrays for each MetaspaceObj subtype, so that we can separate Methods out and scan only them. >>>>> >>>>> Can you have a special array for Method*s? >>>> >>>> Yes, that?s what would be best to do in the future. But it is a substantially bigger change, I?m not sure it would be appropriate for 9 at this point. >>>> >>>> igor >>>> >>>>> Coleen >>>>> >>>>>> igor >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 4/7/17 11:55 AM, Igor Veresov wrote: >>>>>>>> The problem here is that AOTCodeHeap::got_metadata_do() iterates over the _metaspace_got array assuming that the array contains Metadata*, indeed the array is declared as such. However it also happens to contain MethodCounters*, and MethodCounters is not Metadata, but MetaspaceObj. The simplest and minimal risk solution is to make MethodCounters a subclass of Metadata (we?d like to have this fix in jdk9). >>>>>>>> >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8176887/webrev.00/ >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176887 >>>>>>>> >>>>>>>> Thanks! >>>>>>>> igor >>> >> > From kim.barrett at oracle.com Tue Apr 11 01:00:47 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 10 Apr 2017 21:00:47 -0400 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: <138b60b8-51d9-e8fc-62c0-457c7b4cb40f@oracle.com> References: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> <138b60b8-51d9-e8fc-62c0-457c7b4cb40f@oracle.com> Message-ID: <698EFCB4-7019-442C-A611-D2D36DA474CB@oracle.com> > On Apr 10, 2017, at 3:43 PM, Vladimir Kozlov wrote: > > Hi, Kim > > Please, also correct vector registers (need to fix *.ad files too): > > // Vector ideal reg > static const int vector_ideal_reg(int len); > static const int vector_shift_count_ideal_reg(int len); Oops, I missed those. Testing that change. I?ll put out a new webrev when that?s done. > Can you do the same for OptoReg::reg2stack()? Or file separate RFE for it. I?m not sure what it is you are asking for here. > Thanks, > Vladimir > > On 4/7/17 12:21 PM, Igor Veresov wrote: >> Looks good to me. >> >> igor >> >>> On Apr 6, 2017, at 9:48 PM, Kim Barrett wrote: >>> >>> Please review this change to Type's ideal_reg to make its return type >>> consistent with the closely related Node::ideal_reg(). Where Type >>> used to be an int, it is now a uint. This eliminates the implicit >>> narrowing conversion in the initialization of _type_info that caused >>> build failure for C++11 (gcc with -std=gnu++11 or (not tested, but >>> presumed fixed) Visual Studio 2015 or later). >>> >>> Also fixed a number of places where the result of Node::ideal_reg() >>> was being treated as int rather than uint. >>> >>> And since I was in the neighborhood (changing the type of >>> Type::TypeInfo::ideal_reg), also fixed Type::_type_info[] to be const >>> as apparently intended but not successfully accomplished. (The msg >>> member was writable, forcing allocation of the array to be in writable >>> memory, rather than read-only.) >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8160748 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.00/ >>> >>> Testing: >>> JPRT, rbt hs-tier2,hs-tier3,hs-tier4-comp,hs-tier5-comp From vladimir.kozlov at oracle.com Tue Apr 11 01:47:07 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Apr 2017 18:47:07 -0700 Subject: RFR(S) 8176887: SIGSEGV in AOTCodeHeap::next when using specific configuration In-Reply-To: References: <58D5918F-37B3-49B3-B6A5-944076F68546@oracle.com> <55E1501F-E358-492A-BD04-94B0F2AC2AD7@oracle.com> <75975c80-65e9-d8ed-f183-21af950f5032@oracle.com> <6A4AB813-BCAB-44C0-BC79-44ACAC9DED6C@oracle.com> <3d22d236-97f9-95af-8f43-4454679c5b54@oracle.com> <1A4DC886-8121-4D43-B756-C45AEDA7BACC@oracle.com> Message-ID: <806f735d-1d3d-f5ef-638d-bd223f8dfbfc@oracle.com> Yes, I am fine with it. We will reverse this vtbl in MethodCounters when we do proper fix in JDK 10. I would like to do splitting and renaming of these arrays in JDK 10. And it is a lot of changes which we don't want to see now in JDK 9. Vladimir On 4/10/17 5:59 PM, Igor Veresov wrote: > Vladimir, so are you ok with us pushing this? > > igor > >> On Apr 10, 2017, at 2:13 PM, Igor Veresov wrote: >> >> Thanks, Coleen! >> >> igor >> >>> On Apr 10, 2017, at 1:22 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> >>> On 4/10/17 3:48 PM, Igor Veresov wrote: >>>> So? I?m ok to assume that you?re ok with this fix for the time being? >>> >>> If these MethodCounters aren't added to the CDS archive, then the vptr only adds space and I think it's ok for now. >>> Coleen >>> >>>> >>>> igor >>>> >>>>> On Apr 7, 2017, at 3:43 PM, Igor Veresov > wrote: >>>>> >>>>>> >>>>>> On Apr 7, 2017, at 2:36 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 4/7/17 5:33 PM, Igor Veresov wrote: >>>>>>>> On Apr 7, 2017, at 1:29 PM, Vladimir Kozlov > wrote: >>>>>>>> >>>>>>>> This could be good fix for JDK 9. >>>>>>>> >>>>>>>> Are you sure that functions called for Metadata scan will not barf on MethodCounters? >>>>>>> Yes, there shouldn?t be any problems. In the context of class redefinition it calls mark_on_stack(), which is empty by default except for Method and ConstantPool. >>>>>>> >>>>>>>> You need also ask Runtime group to look on this change. >>>>>>> CCing the runtime mail list. Guys, any objections to making MethodCounters a Metadata ? >>>>>> >>>>>> If you make MethodCounters inherited by Metadata it will have a vptr. It doesn't otherwise. >>>>> >>>>> Yes, but I?d have to have some type id to filter them out anyway (if they are in an array with other metaspace objects), having a vtbl seems like an equivalent solution. >>>>> >>>>>>> >>>>>>>> When fixing 8173794 I missed this case (MethodCounters*). We should not put them into metaspace_got array since GC don't need to process them. And they increase metaspace_got array significantly. >>>>>>>> >>>>>>>> For 10 we should fix JAPTC code - metaspace_got array should contain only Klass* pointers. May be to add a separate array since extLinkageGOTContainer may not right for MethodCounters*. >>>>>>> >>>>>>> In the context of class redefinition the scan is actually interested only in methods, rather than classes. Going forward, yes, it would probably be better if we had separate GOT arrays for each MetaspaceObj subtype, so that we can separate Methods out and scan only them. >>>>>> >>>>>> Can you have a special array for Method*s? >>>>> >>>>> Yes, that?s what would be best to do in the future. But it is a substantially bigger change, I?m not sure it would be appropriate for 9 at this point. >>>>> >>>>> igor >>>>> >>>>>> Coleen >>>>>> >>>>>>> igor >>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 4/7/17 11:55 AM, Igor Veresov wrote: >>>>>>>>> The problem here is that AOTCodeHeap::got_metadata_do() iterates over the _metaspace_got array assuming that the array contains Metadata*, indeed the array is declared as such. However it also happens to contain MethodCounters*, and MethodCounters is not Metadata, but MetaspaceObj. The simplest and minimal risk solution is to make MethodCounters a subclass of Metadata (we?d like to have this fix in jdk9). >>>>>>>>> >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8176887/webrev.00/ >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176887 >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> igor >>>> >>> >> > From vladimir.kozlov at oracle.com Tue Apr 11 01:53:04 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Apr 2017 18:53:04 -0700 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: <698EFCB4-7019-442C-A611-D2D36DA474CB@oracle.com> References: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> <138b60b8-51d9-e8fc-62c0-457c7b4cb40f@oracle.com> <698EFCB4-7019-442C-A611-D2D36DA474CB@oracle.com> Message-ID: <55a6a298-f97d-3207-1f75-73a20d04ea61@oracle.com> On 4/10/17 6:00 PM, Kim Barrett wrote: >> On Apr 10, 2017, at 3:43 PM, Vladimir Kozlov wrote: >> >> Hi, Kim >> >> Please, also correct vector registers (need to fix *.ad files too): >> >> // Vector ideal reg >> static const int vector_ideal_reg(int len); >> static const int vector_shift_count_ideal_reg(int len); > > Oops, I missed those. Testing that change. I?ll put out a new webrev when that?s done. > >> Can you do the same for OptoReg::reg2stack()? Or file separate RFE for it. > > I?m not sure what it is you are asking for here. There are useless conversions there too. For example: static unsigned int reg2stack( OptoReg::Name r) { int stack_slot = reg2stack(n); But it is a lot more changes since stack2reg(int idx) and others have singed argument. And I don't remember if negative values are used in such case. That is why I said may be to do it in separate RFE. Vladimir > >> Thanks, >> Vladimir >> >> On 4/7/17 12:21 PM, Igor Veresov wrote: >>> Looks good to me. >>> >>> igor >>> >>>> On Apr 6, 2017, at 9:48 PM, Kim Barrett wrote: >>>> >>>> Please review this change to Type's ideal_reg to make its return type >>>> consistent with the closely related Node::ideal_reg(). Where Type >>>> used to be an int, it is now a uint. This eliminates the implicit >>>> narrowing conversion in the initialization of _type_info that caused >>>> build failure for C++11 (gcc with -std=gnu++11 or (not tested, but >>>> presumed fixed) Visual Studio 2015 or later). >>>> >>>> Also fixed a number of places where the result of Node::ideal_reg() >>>> was being treated as int rather than uint. >>>> >>>> And since I was in the neighborhood (changing the type of >>>> Type::TypeInfo::ideal_reg), also fixed Type::_type_info[] to be const >>>> as apparently intended but not successfully accomplished. (The msg >>>> member was writable, forcing allocation of the array to be in writable >>>> memory, rather than read-only.) >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8160748 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.00/ >>>> >>>> Testing: >>>> JPRT, rbt hs-tier2,hs-tier3,hs-tier4-comp,hs-tier5-comp > > From david.holmes at oracle.com Tue Apr 11 06:47:57 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Apr 2017 16:47:57 +1000 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: References: <2f1f97e9-8b33-c7ba-4eb7-3605ba82922a@oracle.com> Message-ID: <25f0a70d-44ec-1f98-94f9-1126514ab86e@oracle.com> Hi George, On 8/04/2017 5:19 AM, George Triantafillou wrote: > Hi Vladimir, > > Thanks for your comments. > > Updated webrev: > http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev.01/ > There are also changes needed in shared code: ./vm/utilities/globalDefinitions_sparcWorks.hpp** ./vm/utilities/globalDefinitions_gcc.hpp ** which could also do with some Solaris 8 clean out! Thanks, David > -George > > On 4/7/2017 1:26 PM, Vladimir Kozlov wrote: >> On 4/7/17 8:04 AM, George Triantafillou wrote: >>> Thanks Harold, I've made the suggested changes. >>> >>> -George >>> >>> On 4/7/2017 10:34 AM, harold seigel wrote: >>>> Hi George, >>>> >>>> Most of the changes look good. A few comments: >>>> >>>> 1. In stubGenerator_sparc.cpp, lines 831-835 should not be deleted, >>>> just the "&& defined(_LP64)" >>>> >>>> 831 #if defined(ASSERT) && defined(_LP64) >>>> 832 __ signx(Rint, Rtmp); >>>> 833 __ cmp(Rint, Rtmp); >>>> 834 __ breakpoint_trap(Assembler::notEqual, Assembler::xcc); >>>> 835 #endif >> >> I still see this code is removed. Did you updated webrev? >> >>>> >>>> 2. In atomic_solaris_sparc.hpp: remove lines 245 and 372 >>>> >>>> 3. In prefetch_solaris_sparc.inline.hpp, remove lines 30 and 63 >> >> Yes. We don't build JVM with C1 only for 64 bit. >> >>>> >>>> 4. In thread_solaris_sparc.hpp, remove line 67. >> >> Yes. >> >> Other compiler code changes seems fine. >> >> Thanks, >> Vladimir >> >>>> >>>> Thanks, Harold >>>> >>>> On 4/7/2017 9:43 AM, George Triantafillou wrote: >>>>> Please review this fix to remove SPARC 32-bit support. Support for >>>>> solaris-sparc has been dropped from the list of supported platforms. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ >>>>> >>>>> >>>>> Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the >>>>> nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. >>>>> >>>>> Thanks. >>>>> >>>>> -George >>>>> >>>> >>> > From serguei.spitsyn at oracle.com Tue Apr 11 07:05:57 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Apr 2017 00:05:57 -0700 Subject: RFR 8026985: Rewrite SystemDictionary::classes_do and Dictionary::classes_do to use KlassClosure In-Reply-To: <22759e6d-0b05-1e34-1e73-5bf3b974ad95@oracle.com> References: <2ae47703-2c17-548c-f278-2c25647f1cc7@oracle.com> <913ac7b4-affe-0e69-b5dd-95e6727514c0@oracle.com> <7B03B1D3-57B2-44D7-8B89-8C729B20B31A@oracle.com> <22759e6d-0b05-1e34-1e73-5bf3b974ad95@oracle.com> Message-ID: <91d0148a-272c-ae28-aced-fe55c5c522c4@oracle.com> Hi Coleen, http://cr.openjdk.java.net/~coleenp/8026985.03/webrev/src/share/vm/classfile/dictionary.cpp.udiff.html // The loader in this entry is alive. If the klass is dead, // (determined by checking the defining class loader) // the loader must be an initiating loader (rather than the // defining loader). Remove this entry. if (k_def_class_loader_data->is_unloading()) { + ResourceMark rm; + tty->print_cr("loader data %s loads class %s in loader data %s", + loader_data->loader_name(), + ik->name()->as_C_string(), k_def_class_loader_data->loader_name()); + ShouldNotReachHere(); // isn't there a dependency created? or k_loader_data is parent of loader_data?? // If we get here, the class_loader_data must not be the defining // loader, it must be an initiating one. assert(k_def_class_loader_data != loader_data, "cannot have live defining loader and unreachable klass"); // Loader is live, but class and its defining loader are dead. Not sure, I understand why is some code present after theShouldNotReachHere. Also, one extra (unneeded?) question mark is present in the comment. Otherwise, the fix looks good to me. Thanks, Serguei On 4/10/17 14:12, coleen.phillimore at oracle.com wrote: > Hi, I've reopened this cleanup. To be clear, I didn't change which of > classes_do are called except for two places in this change. One is > print_method_profiling_data because it doesn't make sense for this not > to print methods for anonymous classes and method handle intrinsics. > See SystemDictionary::methods_do() implementation. I added > hotspot-compiler-dev to this review so hopefully someone from the > compiler group can verify this. The second is heapDumper.cpp because > it seemed an obvious bug that if !ClassUnloading that all the classes > shouldn't be dumped as STICKY classes. Tested with jvmti and > heapdump tests. I've put this data you requested in the bug report as > a comment. We could probably file about 4 more bugs to cleanup the > calls sites for classes_do, so that the design is clearer, but I > didn't want to do it all in this one change and mix it up with the > functions that I found were unused and this change got large enough. > New webrev: open webrev at > http://cr.openjdk.java.net/~coleenp/8026985.03/webrev bug link > https://bugs.openjdk.java.net/browse/JDK-8026985 Thanks! Coleen On > 3/14/17 10:43 AM, Karen Kinnear wrote: >> Coleen, I am concerned about exposure of: 1) not yet loaded classes >> 2) scratch-classes 3) classes that are not live due to JFR, parallel >> class loading or load errors Could you please make us a table of >> those who walk the classes: which classes they saw before >> which classes they see now - and why the change is ok what tests >> you have for each of the boxes in the table - both that you see what >> you want, and that you do not see what should not be exposed. My >> understanding is that this is intended to speed up GC but not to >> change behaviors. I am concerned about the exposure to non-GC >> walkers. thanks, Karen >>> On Mar 13, 2017, at 8:30 PM, David Holmes >>> wrote: Hi Coleen, On 11/03/2017 12:39 AM, >>> coleen.phillimore at oracle.com >>> wrote: >>>> David, Thank you for reviewing. On 3/10/17 12:18 AM, David Holmes >>>> wrote: >>>>> Hi Coleen, On 9/03/2017 2:24 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Clean up and examine uses of classes_do for the >>>>>> SystemDictionary See bug comments for more details. I wanted to >>>>>> clean this up while examining the idea of having system >>>>>> dictionary information added per ClassLoaderData, rather than a >>>>>> global table. open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/8026985.01/webrev bug link >>>>>> https://bugs.openjdk.java.net/browse/JDK-8026985 >>>>> The bulk of the deletion looks good! :) I guess my main query is >>>>> how ClassLoaderDataGraph::classes_do / loaded_classes_do relate to >>>>> SystemDictionary::classes_do? I would presume SD::classes_do can >>>>> only act on loaded classes - by definition. So then it is unclear >>>>> how you can replace it with either of the CLDG methods? >>>> True, loaded_classes_do only walks loaded classes, which is >>>> probably what we want most of the time. I was trying to figure >>>> this out and the differences which led to this change. I am trying >>>> to make it less confusing. At least for me! The >>>> ClassLoaderData::classes_do includes anonymous, array and allocated >>>> classes. Most of the time we want the first two. For GC we want >>>> the last (because it has a mirror to walk). The SystemDictionary >>>> only has loaded InstanceKlasses, both with defined loader and >>>> initiating loader. Except for one place in the code, we ignore >>>> the entries with initiating loader. >>> I'm still very unclear as to why it is now okay to expand the set of >>> klasses being walked at a given point. For example: >>> src/share/vm/oops/klassVtable.cpp static void compute() { - >>> SystemDictionary::classes_do(do_class); + >>> ClassLoaderDataGraph::classes_do(do_class); IIUC SD::classes_do does >>> not see anonymous classes, but CLDG::classes_do does. Why is this >>> okay? You mentioned bugs like JDK-8024423 "missing anonymous >>> classes" but my limited understanding of that bug suggests to me >>> that the fix was to completely hide anonymous classes not to expose >>> them! They should not be visible to JVM TI as I understand the >>> intent of VM anonymous classes! Thanks, David ----- >>>> The only place where methods_do() is called for all the methods is >>>> for print_method_data_histogram and print_method_profiling_data. >>>> These should only use loaded classes, so I've made the change >>>> below: void ClassLoaderData::methods_do(void f(Method*)) { // >>>> Lock-free access requires load_ptr_acquire for (Klass* k = >>>> load_ptr_acquire(&_klasses); k != NULL; k = k->next_link()) { >>>> if (k->is_instance_klass() && InstanceKlass::cast(k)->is_loaded()) >>>> { InstanceKlass::cast(k)->methods_do(f); } } } >>>>> It also seems a little odd to switch from SD to CLDG for >>>>> classes_do, but go the other way, from CLDG to SD for methods_do ? >>>>> I would expect/hope to have a single "entry point" for this kind >>>>> of iteration. >>>> I know. Unfortunately SD::methods_do includes the methods added >>>> for MethodHandle intrinsics, which is owned by SystemDictionary. >>>> void SystemDictionary::methods_do(void f(Method*)) { >>>> ClassLoaderDataGraph::methods_do(f); >>>> invoke_method_table()->methods_do(f); } I don't like this either. >>>> This invoke_method_table() really has nothing to do with the >>>> Dictionary, it's just where it ended up. I could expand the change >>>> to find a better place for it. I don't know where would be good >>>> though. Aside, I'd forgotten about invoke_method_table - it seems >>>> to be a mechanism for isolated methods. Coleen >>>>> Thanks, David >>>>>> Tested with java.lang.instrument, sun.com.jdi, tonga colocated >>>>>> (closed) tests, and JPRT, because of difference in which >>>>>> classes_do is called for heap dumping. Note, will update >>>>>> copyrights on commit. Thanks, Coleen From tobias.hartmann at oracle.com Tue Apr 11 07:07:14 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 11 Apr 2017 09:07:14 +0200 Subject: [8u] RFR 8173373: C1: NPE is thrown instead of LinkageError when accessing inaccessible field on NULL receiver In-Reply-To: <3234f84b-ed79-1ec2-df81-cde77e850c07@oracle.com> References: <3234f84b-ed79-1ec2-df81-cde77e850c07@oracle.com> Message-ID: Hi Vladimir, looks good to me, thanks for taking care of the backport! Best regards, Tobias On 10.04.2017 19:18, Vladimir Kempik wrote: > Hello > > Please review this backport of 8173373 for jdk8u. > > The fix applied cleanly to jdk8, except one place: > > in src/share/vm/c1/c1_LIR.cpp > > I had to change > > + CodeStub* deopt = new DeoptimizeStub(info, Deoptimization::Reason_null_check, Deoptimization::Action_none); > > to > > + CodeStub* deopt = new DeoptimizeStub(info); > > The fix passes jprt and testcase. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173373 > Webrev: http://cr.openjdk.java.net/~vkempik/8173373/webrev.00/ > > Thanks > -Vladimir > From coleen.phillimore at oracle.com Tue Apr 11 11:41:52 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 11 Apr 2017 07:41:52 -0400 Subject: RFR 8026985: Rewrite SystemDictionary::classes_do and Dictionary::classes_do to use KlassClosure In-Reply-To: <7C357C0C-536A-4A28-87F5-88F31559B29B@oracle.com> References: <2ae47703-2c17-548c-f278-2c25647f1cc7@oracle.com> <913ac7b4-affe-0e69-b5dd-95e6727514c0@oracle.com> <7B03B1D3-57B2-44D7-8B89-8C729B20B31A@oracle.com> <22759e6d-0b05-1e34-1e73-5bf3b974ad95@oracle.com> <7C357C0C-536A-4A28-87F5-88F31559B29B@oracle.com> Message-ID: Thanks, Igor! Coleen On 4/10/17 8:27 PM, Igor Veresov wrote: > Looks good. Amazing how much dead code is there. > > igor > > >> On Apr 10, 2017, at 2:12 PM, coleen.phillimore at oracle.com wrote: >> >> >> Hi, I've reopened this cleanup. To be clear, I didn't change which of classes_do are called except for two places in this change. >> >> One is print_method_profiling_data because it doesn't make sense for this not to print methods for anonymous classes and method handle intrinsics. See SystemDictionary::methods_do() implementation. I added hotspot-compiler-dev to this review so hopefully someone from the compiler group can verify this. >> >> The second is heapDumper.cpp because it seemed an obvious bug that if !ClassUnloading that all the classes shouldn't be dumped as STICKY classes. Tested with jvmti and heapdump tests. >> >> I've put this data you requested in the bug report as a comment. We could probably file about 4 more bugs to cleanup the calls sites for classes_do, so that the design is clearer, but I didn't want to do it all in this one change and mix it up with the functions that I found were unused and this change got large enough. >> >> New webrev: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8026985.03/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8026985 >> >> Thanks! >> Coleen >> >> On 3/14/17 10:43 AM, Karen Kinnear wrote: >>> Coleen, >>> >>> I am concerned about exposure of: >>> 1) not yet loaded classes >>> 2) scratch-classes >>> 3) classes that are not live due to JFR, parallel class loading or load errors >>> >>> Could you please make us a table of those who walk the classes: >>> which classes they saw before >>> which classes they see now - and why the change is ok >>> what tests you have for each of the boxes in the table - both that you see what you want, and that you do not see >>> what should not be exposed. >>> >>> My understanding is that this is intended to speed up GC but not to change behaviors. >>> I am concerned about the exposure to non-GC walkers. >>> >>> thanks, >>> Karen >>> >>>> On Mar 13, 2017, at 8:30 PM, David Holmes wrote: >>>> >>>> Hi Coleen, >>>> >>>> On 11/03/2017 12:39 AM, coleen.phillimore at oracle.com wrote: >>>>> David, Thank you for reviewing. >>>>> >>>>> On 3/10/17 12:18 AM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 9/03/2017 2:24 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Clean up and examine uses of classes_do for the >>>>>>> SystemDictionary >>>>>>> >>>>>>> See bug comments for more details. I wanted to clean this up while >>>>>>> examining the idea of having system dictionary information added per >>>>>>> ClassLoaderData, rather than a global table. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026985.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026985 >>>>>> The bulk of the deletion looks good! :) >>>>>> >>>>>> I guess my main query is how ClassLoaderDataGraph::classes_do / >>>>>> loaded_classes_do relate to SystemDictionary::classes_do? I would >>>>>> presume SD::classes_do can only act on loaded classes - by definition. >>>>>> So then it is unclear how you can replace it with either of the CLDG >>>>>> methods? >>>>> True, loaded_classes_do only walks loaded classes, which is probably >>>>> what we want most of the time. I was trying to figure this out and the >>>>> differences which led to this change. I am trying to make it less >>>>> confusing. At least for me! >>>>> >>>>> The ClassLoaderData::classes_do includes anonymous, array and allocated >>>>> classes. Most of the time we want the first two. For GC we want the >>>>> last (because it has a mirror to walk). The SystemDictionary only has >>>>> loaded InstanceKlasses, both with defined loader and initiating >>>>> loader. Except for one place in the code, we ignore the entries with >>>>> initiating loader. >>>> I'm still very unclear as to why it is now okay to expand the set of klasses being walked at a given point. For example: >>>> >>>> src/share/vm/oops/klassVtable.cpp >>>> >>>> static void compute() { >>>> - SystemDictionary::classes_do(do_class); >>>> + ClassLoaderDataGraph::classes_do(do_class); >>>> >>>> IIUC SD::classes_do does not see anonymous classes, but CLDG::classes_do does. Why is this okay? >>>> >>>> You mentioned bugs like JDK-8024423 "missing anonymous classes" but my limited understanding of that bug suggests to me that the fix was to completely hide anonymous classes not to expose them! They should not be visible to JVM TI as I understand the intent of VM anonymous classes! >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> The only place where methods_do() is called for all the methods is for >>>>> print_method_data_histogram and print_method_profiling_data. These >>>>> should only use loaded classes, so I've made the change below: >>>>> >>>>> void ClassLoaderData::methods_do(void f(Method*)) { >>>>> // Lock-free access requires load_ptr_acquire >>>>> for (Klass* k = load_ptr_acquire(&_klasses); k != NULL; k = >>>>> k->next_link()) { >>>>> if (k->is_instance_klass() && InstanceKlass::cast(k)->is_loaded()) { >>>>> InstanceKlass::cast(k)->methods_do(f); >>>>> } >>>>> } >>>>> } >>>>>> It also seems a little odd to switch from SD to CLDG for classes_do, >>>>>> but go the other way, from CLDG to SD for methods_do ? I would >>>>>> expect/hope to have a single "entry point" for this kind of iteration. >>>>> I know. Unfortunately SD::methods_do includes the methods added for >>>>> MethodHandle intrinsics, which is owned by SystemDictionary. >>>>> >>>>> void SystemDictionary::methods_do(void f(Method*)) { >>>>> ClassLoaderDataGraph::methods_do(f); >>>>> invoke_method_table()->methods_do(f); >>>>> } >>>>> >>>>> I don't like this either. This invoke_method_table() really has >>>>> nothing to do with the Dictionary, it's just where it ended up. I could >>>>> expand the change to find a better place for it. I don't know where >>>>> would be good though. >>>>> >>>>> Aside, I'd forgotten about invoke_method_table - it seems to be a >>>>> mechanism for isolated methods. >>>>> >>>>> Coleen >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Tested with java.lang.instrument, sun.com.jdi, tonga colocated (closed) >>>>>>> tests, and JPRT, because of difference in which classes_do is called for >>>>>>> heap dumping. >>>>>>> >>>>>>> Note, will update copyrights on commit. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen From volker.simonis at gmail.com Tue Apr 11 13:34:17 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 11 Apr 2017 15:34:17 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <1C84273B-2FA8-4B91-B412-0D2F815C13F2@sap.com> <9bc87d3e-a657-1e10-f688-e51e4e26645d@redhat.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> Message-ID: Hi Zoltan, could you please be so kind to sponsor this reviewed change for jdk10? Initially we wanted to push it ourselves because it was s390x only but now that we've also touched the tests we need a sponsor. Thank you and best regards, Volker ---------- Forwarded message ---------- From: Volker Simonis Date: Fri, Mar 31, 2017 at 10:53 AM Subject: Re: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases To: "Schmidt, Lutz" Cc: Andrew Haley , "hotspot-compiler-dev at openjdk.java.net" < hotspot-compiler-dev at openjdk.java.net> Ping... Can somebody please push this change? It's ppc64/s390x only but as a courtesy to the community it also fixes the CRC JTreg tests so unfortunately I still can't push it myself :) Thank you and best regards, Volker On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis wrote: > Hi Lutz, > > thanks a lot for fixing the test! > Your change looks good now. > > Because this touches shared (i.e. test) files, we still need a sponsor > so can somebody please sponsor this change? > > Thank you and best regards, > Volker > > > > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz wrote: >> Hi Volker, >> >> Sorry for letting you wait. Here is the final(?) webrev, containing all your requests for cleanup and improvements: >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ >> >> As before, the *.cpp files have not been modified. >> >> Best Regards, >> Lutz >> >> >> >> On 21/03/2017, 17:55, "Volker Simonis" wrote: >> >> Hi Lutz, >> >> thanks a lot for updating the tests. I think they look much better now. >> >> There's just one more cleanup I'd like to propose. Can you please move >> the throw right into the check() function. Just make check() return >> void and throw from it if there's a mismatch between the computed and >> the expected result. I leave it up to you if you want to pass an extra >> error string to check() which will be printed in the case of an error. >> I personally don't think that's necessary as it will be evident from >> the stack trace which computation failed. >> >> Also the try/catch and rethrow in test_multi() isn't necessary. The >> test can be simply terminated by the initial exception. >> >> Thank you and best regards, >> Volker >> >> >> On Fri, Mar 17, 2017 at 10:03 PM, Schmidt, Lutz wrote: >> > Hi Volker, >> > >> > Thanks a lot for your valuable hints. >> > >> > I have worked some time on the Java test files: >> > TestCRC32.java and TestCRC32C.java are now identical as far as possible. >> > They now throw an exception, should any error be detected. >> > The ?reference CRC value? is now used in test_multi() as well. >> > The extra test runs have been removed again. >> > The test methodology is fixed: each result is tested against its reference. >> > The tests now detect the bug introduced with 8175368 and 8175369. >> > No issue is indicated when testing with 8176580. >> > I ran jcheck, and to the best of my ability and knowledge, there is no trailing whitespace. >> > All *.cpp files were left untouched! >> > >> > The next iteration of the webrev: http://cr.openjdk.java.net/~ lucy/webrevs/8176580.02/ >> > >> > Best regards, >> > Lutz >> > >> > >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 (6227) 7-42834 >> > >> > >> > >> > On 16.03.17, 11:28, "Volker Simonis" wrote: >> > >> > On Wed, Mar 15, 2017 at 5:55 PM, Schmidt, Lutz < lutz.schmidt at sap.com> wrote: >> > > >> > > Hi Andrew, Volker, >> > > >> > > What do you think about these test enhancements? >> > > Webrev: http://cr.openjdk.java.net/~ lucy/webrevs/8176580.01/ >> > > >> > > Please note: the cpp files in the webrev remained unchanged. >> > > >> > > I added some improvements (as I believe) to the TestCRC32(C).java files. >> > > >> > > In some more detail: >> > > The test now calculates a ?reference CRC value?, based on a java implementation of the CRC32 algorithm. This reference value is used to verify all other crc values, in particular during initialization and warmup. Three additional test runs check a non-zero offset with ?Xint, -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp -XX:+TieredCompilation (C1 + C2). >> > > >> > >> > Hi Lutz, >> > >> > thanks for updating the tests. I've had a closer look at the tests and >> > realized that they actually can never fail! The check() routine just >> > prints an error message but that will not let the test fail. So I >> > would suggest to throw a runtime exception in the check() routine >> > after the error message was printed. >> > >> > I also suggest to do the check during the normal test execution (i.e. >> > in test_multi()) so there's no need for extra test runs. >> > >> > Finally, the current test methodology in test_multi() is broken: >> > - it sets the reference by calling CRC from the interpreter which >> > won't work if the intrinsic is also used in the interpreter. >> > - it only compares the reference against the last computation of CRC >> > in the loop which will be the result of the C2 generated code. This >> > misses errors in C1. >> > >> > I suggest to use your new, pure Java implementation for the >> > computation of the reference result and compare the reference with the >> > result of calling CRC in every iteration of the loop so we really >> > check all possibilities from interpreter trough C1 to C2. >> > >> > Finally, can you please pay attention to not insert trailing >> > whitespace (there was some at line 88 in TestCRC32C.java). You can >> > easily verify this by running jcheck before creating the webrevs. >> > >> > Thanks, >> > Volker >> > >> > > >> > > Best regards, >> > > Lutz >> > > >> > > >> > > On 15.03.17, 11:50, "Volker Simonis" < volker.simonis at gmail.com> wrote: >> > > >> > > On Tue, Mar 14, 2017 at 7:05 PM, Andrew Haley < aph at redhat.com> wrote: >> > > > On 14/03/17 13:12, Schmidt, Lutz wrote: >> > > > >> > > >> Yes, one might think of running a test suite subset multiple times >> > > >> with different parameters. In this case, -Xint and/or ?Xcomp were >> > > >> helpful. Forcing tests to run fully interpreted or fully compiled >> > > >> helps in cases where a certain function, e.g. an intrinsic, is >> > > >> invoked via distinct code paths. >> > > > >> > > > Right, so your patch should include that change to the test suite. >> > > > >> > > >> > > Hi Lutz, >> > > >> > > I agree with Andrew. We should really fix the tests such that they >> > > check the correctness of the intrinsics. >> > > >> > > This may be tricky if all three, the interpreter, the client and the >> > > server compiler use the same intrinsic implementation. You could >> > > either copy the pure Java implementation into the test so that you can >> > > compare the results of the intrinsic operation against it or you can >> > > switch them off in the compilers with >> > > "-XX:DisableIntrinsic=_updateBytesCRC32C >> > > -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and compare the >> > > results. Not sure which solution is more practical, but I would be >> > > really scared if we wouldn't have these test. >> > > >> > > Regards, >> > > Volker >> > > >> > > > Andrew. >> > > > >> > > >> > > >> > >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Apr 11 14:00:00 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 11 Apr 2017 10:00:00 -0400 Subject: RFR 8026985: Rewrite SystemDictionary::classes_do and Dictionary::classes_do to use KlassClosure In-Reply-To: <91d0148a-272c-ae28-aced-fe55c5c522c4@oracle.com> References: <2ae47703-2c17-548c-f278-2c25647f1cc7@oracle.com> <913ac7b4-affe-0e69-b5dd-95e6727514c0@oracle.com> <7B03B1D3-57B2-44D7-8B89-8C729B20B31A@oracle.com> <22759e6d-0b05-1e34-1e73-5bf3b974ad95@oracle.com> <91d0148a-272c-ae28-aced-fe55c5c522c4@oracle.com> Message-ID: On 4/11/17 3:05 AM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > http://cr.openjdk.java.net/~coleenp/8026985.03/webrev/src/share/vm/classfile/dictionary.cpp.udiff.html > > > // The loader in this entry is alive. If the klass is dead, > // (determined by checking the defining class loader) > // the loader must be an initiating loader (rather than the > // defining loader). Remove this entry. > if (k_def_class_loader_data->is_unloading()) { > + ResourceMark rm; > + tty->print_cr("loader data %s loads class %s in loader data %s", > + loader_data->loader_name(), > + ik->name()->as_C_string(), k_def_class_loader_data->loader_name()); > + ShouldNotReachHere(); // isn't there a dependency created? or > k_loader_data is parent of loader_data?? > // If we get here, the class_loader_data must not be the > defining > // loader, it must be an initiating one. > assert(k_def_class_loader_data != loader_data, > "cannot have live defining loader and unreachable > klass"); > // Loader is live, but class and its defining loader are > dead. > > > Not sure, I understand why is some code present after > theShouldNotReachHere. Also, one extra (unneeded?) question mark > is present in the comment. Hi Serguei, That change is part of a different investigation, I'll remove it. Thanks for looking at this change. Coleen > > Otherwise, the fix looks good to me. > > Thanks, Serguei On 4/10/17 14:12, coleen.phillimore at oracle.com wrote: >> Hi, I've reopened this cleanup. To be clear, I didn't change which >> of classes_do are called except for two places in this change. One is >> print_method_profiling_data because it doesn't make sense for this >> not to print methods for anonymous classes and method handle >> intrinsics. See SystemDictionary::methods_do() implementation. I >> added hotspot-compiler-dev to this review so hopefully someone from >> the compiler group can verify this. The second is heapDumper.cpp >> because it seemed an obvious bug that if !ClassUnloading that all the >> classes shouldn't be dumped as STICKY classes. Tested with jvmti >> and heapdump tests. I've put this data you requested in the bug >> report as a comment. We could probably file about 4 more bugs to >> cleanup the calls sites for classes_do, so that the design is >> clearer, but I didn't want to do it all in this one change and mix it >> up with the functions that I found were unused and this change got >> large enough. New webrev: open webrev at >> http://cr.openjdk.java.net/~coleenp/8026985.03/webrev bug link >> https://bugs.openjdk.java.net/browse/JDK-8026985 Thanks! Coleen On >> 3/14/17 10:43 AM, Karen Kinnear wrote: >>> Coleen, I am concerned about exposure of: 1) not yet loaded classes >>> 2) scratch-classes 3) classes that are not live due to JFR, parallel >>> class loading or load errors Could you please make us a table of >>> those who walk the classes: which classes they saw before >>> which classes they see now - and why the change is ok what tests >>> you have for each of the boxes in the table - both that you see what >>> you want, and that you do not see what should not be exposed. My >>> understanding is that this is intended to speed up GC but not to >>> change behaviors. I am concerned about the exposure to non-GC >>> walkers. thanks, Karen >>>> On Mar 13, 2017, at 8:30 PM, David Holmes >>>> wrote: Hi Coleen, On 11/03/2017 12:39 AM, >>>> coleen.phillimore at oracle.com >>>> wrote: >>>>> David, Thank you for reviewing. On 3/10/17 12:18 AM, David Holmes >>>>> wrote: >>>>>> Hi Coleen, On 9/03/2017 2:24 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Clean up and examine uses of classes_do for the >>>>>>> SystemDictionary See bug comments for more details. I wanted to >>>>>>> clean this up while examining the idea of having system >>>>>>> dictionary information added per ClassLoaderData, rather than a >>>>>>> global table. open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/8026985.01/webrev bug link >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8026985 >>>>>> The bulk of the deletion looks good! :) I guess my main query is >>>>>> how ClassLoaderDataGraph::classes_do / loaded_classes_do relate >>>>>> to SystemDictionary::classes_do? I would presume SD::classes_do >>>>>> can only act on loaded classes - by definition. So then it is >>>>>> unclear how you can replace it with either of the CLDG methods? >>>>> True, loaded_classes_do only walks loaded classes, which is >>>>> probably what we want most of the time. I was trying to figure >>>>> this out and the differences which led to this change. I am >>>>> trying to make it less confusing. At least for me! The >>>>> ClassLoaderData::classes_do includes anonymous, array and >>>>> allocated classes. Most of the time we want the first two. For >>>>> GC we want the last (because it has a mirror to walk). The >>>>> SystemDictionary only has loaded InstanceKlasses, both with >>>>> defined loader and initiating loader. Except for one place in >>>>> the code, we ignore the entries with initiating loader. >>>> I'm still very unclear as to why it is now okay to expand the set >>>> of klasses being walked at a given point. For example: >>>> src/share/vm/oops/klassVtable.cpp static void compute() { - >>>> SystemDictionary::classes_do(do_class); + >>>> ClassLoaderDataGraph::classes_do(do_class); IIUC SD::classes_do >>>> does not see anonymous classes, but CLDG::classes_do does. Why is >>>> this okay? You mentioned bugs like JDK-8024423 "missing anonymous >>>> classes" but my limited understanding of that bug suggests to me >>>> that the fix was to completely hide anonymous classes not to expose >>>> them! They should not be visible to JVM TI as I understand the >>>> intent of VM anonymous classes! Thanks, David ----- >>>>> The only place where methods_do() is called for all the methods is >>>>> for print_method_data_histogram and print_method_profiling_data. >>>>> These should only use loaded classes, so I've made the change >>>>> below: void ClassLoaderData::methods_do(void f(Method*)) { // >>>>> Lock-free access requires load_ptr_acquire for (Klass* k = >>>>> load_ptr_acquire(&_klasses); k != NULL; k = k->next_link()) { >>>>> if (k->is_instance_klass() && InstanceKlass::cast(k)->is_loaded()) >>>>> { InstanceKlass::cast(k)->methods_do(f); } } } >>>>>> It also seems a little odd to switch from SD to CLDG for >>>>>> classes_do, but go the other way, from CLDG to SD for methods_do >>>>>> ? I would expect/hope to have a single "entry point" for this >>>>>> kind of iteration. >>>>> I know. Unfortunately SD::methods_do includes the methods added >>>>> for MethodHandle intrinsics, which is owned by SystemDictionary. >>>>> void SystemDictionary::methods_do(void f(Method*)) { >>>>> ClassLoaderDataGraph::methods_do(f); >>>>> invoke_method_table()->methods_do(f); } I don't like this >>>>> either. This invoke_method_table() really has nothing to do with >>>>> the Dictionary, it's just where it ended up. I could expand the >>>>> change to find a better place for it. I don't know where would be >>>>> good though. Aside, I'd forgotten about invoke_method_table - it >>>>> seems to be a mechanism for isolated methods. Coleen >>>>>> Thanks, David >>>>>>> Tested with java.lang.instrument, sun.com.jdi, tonga colocated >>>>>>> (closed) tests, and JPRT, because of difference in which >>>>>>> classes_do is called for heap dumping. Note, will update >>>>>>> copyrights on commit. Thanks, Coleen From zoltan.majo at oracle.com Tue Apr 11 14:35:52 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 11 Apr 2017 16:35:52 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <1C84273B-2FA8-4B91-B412-0D2F815C13F2@sap.com> <9bc87d3e-a657-1e10-f688-e51e4e26645d@redhat.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> Message-ID: <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> Hi Volker, On 04/11/2017 03:34 PM, Volker Simonis wrote: > > Hi Zoltan, > > could you please be so kind to sponsor this reviewed change for jdk10? yes, of course. I'll push it today. Best regards, Zoltan > Initially we wanted to push it ourselves because it was s390x only but > now that we've also touched the tests we need a sponsor. > > Thank you and best regards, > Volker > > ---------- Forwarded message ---------- > From: *Volker Simonis* > > Date: Fri, Mar 31, 2017 at 10:53 AM > Subject: Re: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum > result in some cases > To: "Schmidt, Lutz" > > Cc: Andrew Haley >, > "hotspot-compiler-dev at openjdk.java.net > " > > > > > Ping... > > Can somebody please push this change? > > It's ppc64/s390x only but as a courtesy to the community it also fixes > the CRC JTreg tests so unfortunately I still can't push it myself :) > > Thank you and best regards, > Volker > > > On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis > > wrote: > > Hi Lutz, > > > > thanks a lot for fixing the test! > > Your change looks good now. > > > > Because this touches shared (i.e. test) files, we still need a sponsor > > so can somebody please sponsor this change? > > > > Thank you and best regards, > > Volker > > > > > > > > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz > wrote: > >> Hi Volker, > >> > >> Sorry for letting you wait. Here is the final(?) webrev, containing > all your requests for cleanup and improvements: > >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ > > >> > >> As before, the *.cpp files have not been modified. > >> > >> Best Regards, > >> Lutz > >> > >> > >> > >> On 21/03/2017, 17:55, "Volker Simonis" > wrote: > >> > >> Hi Lutz, > >> > >> thanks a lot for updating the tests. I think they look much > better now. > >> > >> There's just one more cleanup I'd like to propose. Can you > please move > >> the throw right into the check() function. Just make check() return > >> void and throw from it if there's a mismatch between the > computed and > >> the expected result. I leave it up to you if you want to pass > an extra > >> error string to check() which will be printed in the case of an > error. > >> I personally don't think that's necessary as it will be evident > from > >> the stack trace which computation failed. > >> > >> Also the try/catch and rethrow in test_multi() isn't necessary. The > >> test can be simply terminated by the initial exception. > >> > >> Thank you and best regards, > >> Volker > >> > >> > >> On Fri, Mar 17, 2017 at 10:03 PM, Schmidt, Lutz > > wrote: > >> > Hi Volker, > >> > > >> > Thanks a lot for your valuable hints. > >> > > >> > I have worked some time on the Java test files: > >> > TestCRC32.java and TestCRC32C.java are now identical as far > as possible. > >> > They now throw an exception, should any error be detected. > >> > The ?reference CRC value? is now used in test_multi() as well. > >> > The extra test runs have been removed again. > >> > The test methodology is fixed: each result is tested > against its reference. > >> > The tests now detect the bug introduced with 8175368 and > 8175369. > >> > No issue is indicated when testing with 8176580. > >> > I ran jcheck, and to the best of my ability and knowledge, > there is no trailing whitespace. > >> > All *.cpp files were left untouched! > >> > > >> > The next iteration of the webrev: > http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ > > >> > > >> > Best regards, > >> > Lutz > >> > > >> > > >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 (6227) > 7-42834 > >> > > >> > > >> > > >> > On 16.03.17, 11:28, "Volker Simonis" > > wrote: > >> > > >> > On Wed, Mar 15, 2017 at 5:55 PM, Schmidt, Lutz > > wrote: > >> > > > >> > > Hi Andrew, Volker, > >> > > > >> > > What do you think about these test enhancements? > >> > > Webrev: > http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ > > >> > > > >> > > Please note: the cpp files in the webrev remained > unchanged. > >> > > > >> > > I added some improvements (as I believe) to the > TestCRC32(C).java files. > >> > > > >> > > In some more detail: > >> > > The test now calculates a ?reference CRC value?, based > on a java implementation of the CRC32 algorithm. This reference value > is used to verify all other crc values, in particular during > initialization and warmup. Three additional test runs check a non-zero > offset with ?Xint, -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp > -XX:+TieredCompilation (C1 + C2). > >> > > > >> > > >> > Hi Lutz, > >> > > >> > thanks for updating the tests. I've had a closer look at > the tests and > >> > realized that they actually can never fail! The check() > routine just > >> > prints an error message but that will not let the test > fail. So I > >> > would suggest to throw a runtime exception in the check() > routine > >> > after the error message was printed. > >> > > >> > I also suggest to do the check during the normal test > execution (i.e. > >> > in test_multi()) so there's no need for extra test runs. > >> > > >> > Finally, the current test methodology in test_multi() is > broken: > >> > - it sets the reference by calling CRC from the > interpreter which > >> > won't work if the intrinsic is also used in the interpreter. > >> > - it only compares the reference against the last > computation of CRC > >> > in the loop which will be the result of the C2 generated > code. This > >> > misses errors in C1. > >> > > >> > I suggest to use your new, pure Java implementation for the > >> > computation of the reference result and compare the > reference with the > >> > result of calling CRC in every iteration of the loop so > we really > >> > check all possibilities from interpreter trough C1 to C2. > >> > > >> > Finally, can you please pay attention to not insert trailing > >> > whitespace (there was some at line 88 in > TestCRC32C.java). You can > >> > easily verify this by running jcheck before creating the > webrevs. > >> > > >> > Thanks, > >> > Volker > >> > > >> > > > >> > > Best regards, > >> > > Lutz > >> > > > >> > > > >> > > On 15.03.17, 11:50, "Volker Simonis" > > wrote: > >> > > > >> > > On Tue, Mar 14, 2017 at 7:05 PM, Andrew Haley > > wrote: > >> > > > On 14/03/17 13:12, Schmidt, Lutz wrote: > >> > > > > >> > > >> Yes, one might think of running a test suite > subset multiple times > >> > > >> with different parameters. In this case, -Xint > and/or ?Xcomp were > >> > > >> helpful. Forcing tests to run fully interpreted > or fully compiled > >> > > >> helps in cases where a certain function, e.g. an > intrinsic, is > >> > > >> invoked via distinct code paths. > >> > > > > >> > > > Right, so your patch should include that change > to the test suite. > >> > > > > >> > > > >> > > Hi Lutz, > >> > > > >> > > I agree with Andrew. We should really fix the tests > such that they > >> > > check the correctness of the intrinsics. > >> > > > >> > > This may be tricky if all three, the interpreter, > the client and the > >> > > server compiler use the same intrinsic > implementation. You could > >> > > either copy the pure Java implementation into the > test so that you can > >> > > compare the results of the intrinsic operation > against it or you can > >> > > switch them off in the compilers with > >> > > "-XX:DisableIntrinsic=_updateBytesCRC32C > >> > > -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" > and compare the > >> > > results. Not sure which solution is more practical, > but I would be > >> > > really scared if we wouldn't have these test. > >> > > > >> > > Regards, > >> > > Volker > >> > > > >> > > > Andrew. > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > From volker.simonis at gmail.com Tue Apr 11 16:03:02 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 11 Apr 2017 18:03:02 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <1C84273B-2FA8-4B91-B412-0D2F815C13F2@sap.com> <9bc87d3e-a657-1e10-f688-e51e4e26645d@redhat.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> Message-ID: Thanks a lot Zoltan! On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? wrote: > Hi Volker, > > > On 04/11/2017 03:34 PM, Volker Simonis wrote: > >> >> Hi Zoltan, >> >> could you please be so kind to sponsor this reviewed change for jdk10? >> > > yes, of course. I'll push it today. > > Best regards, > > > Zoltan > > Initially we wanted to push it ourselves because it was s390x only but now >> that we've also touched the tests we need a sponsor. >> >> Thank you and best regards, >> Volker >> >> ---------- Forwarded message ---------- >> From: *Volker Simonis* > volker.simonis at gmail.com>> >> Date: Fri, Mar 31, 2017 at 10:53 AM >> Subject: Re: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result >> in some cases >> To: "Schmidt, Lutz" > >> Cc: Andrew Haley >, " >> hotspot-compiler-dev at openjdk.java.net > penjdk.java.net>" > hotspot-compiler-dev at openjdk.java.net>> >> >> >> Ping... >> >> Can somebody please push this change? >> >> It's ppc64/s390x only but as a courtesy to the community it also fixes >> the CRC JTreg tests so unfortunately I still can't push it myself :) >> >> Thank you and best regards, >> Volker >> >> >> On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis >> > wrote: >> > Hi Lutz, >> > >> > thanks a lot for fixing the test! >> > Your change looks good now. >> > >> > Because this touches shared (i.e. test) files, we still need a sponsor >> > so can somebody please sponsor this change? >> > >> > Thank you and best regards, >> > Volker >> > >> > >> > >> > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz > > wrote: >> >> Hi Volker, >> >> >> >> Sorry for letting you wait. Here is the final(?) webrev, containing >> all your requests for cleanup and improvements: >> >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ < >> http://cr.openjdk.java.net/%7Elucy/webrevs/8176580.03/> >> >> >> >> As before, the *.cpp files have not been modified. >> >> >> >> Best Regards, >> >> Lutz >> >> >> >> >> >> >> >> On 21/03/2017, 17:55, "Volker Simonis" > > wrote: >> >> >> >> Hi Lutz, >> >> >> >> thanks a lot for updating the tests. I think they look much better >> now. >> >> >> >> There's just one more cleanup I'd like to propose. Can you please >> move >> >> the throw right into the check() function. Just make check() return >> >> void and throw from it if there's a mismatch between the computed >> and >> >> the expected result. I leave it up to you if you want to pass an >> extra >> >> error string to check() which will be printed in the case of an >> error. >> >> I personally don't think that's necessary as it will be evident >> from >> >> the stack trace which computation failed. >> >> >> >> Also the try/catch and rethrow in test_multi() isn't necessary. The >> >> test can be simply terminated by the initial exception. >> >> >> >> Thank you and best regards, >> >> Volker >> >> >> >> >> >> On Fri, Mar 17, 2017 at 10:03 PM, Schmidt, Lutz < >> lutz.schmidt at sap.com > wrote: >> >> > Hi Volker, >> >> > >> >> > Thanks a lot for your valuable hints. >> >> > >> >> > I have worked some time on the Java test files: >> >> > TestCRC32.java and TestCRC32C.java are now identical as far as >> possible. >> >> > They now throw an exception, should any error be detected. >> >> > The ?reference CRC value? is now used in test_multi() as well. >> >> > The extra test runs have been removed again. >> >> > The test methodology is fixed: each result is tested against >> its reference. >> >> > The tests now detect the bug introduced with 8175368 and >> 8175369. >> >> > No issue is indicated when testing with 8176580. >> >> > I ran jcheck, and to the best of my ability and knowledge, >> there is no trailing whitespace. >> >> > All *.cpp files were left untouched! >> >> > >> >> > The next iteration of the webrev: http://cr.openjdk.java.net/~lu >> cy/webrevs/8176580.02/ > Elucy/webrevs/8176580.02/> >> >> > >> >> > Best regards, >> >> > Lutz >> >> > >> >> > >> >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 (6227) >> 7-42834 >> >> > >> >> > >> >> > >> >> > On 16.03.17, 11:28, "Volker Simonis" > > wrote: >> >> > >> >> > On Wed, Mar 15, 2017 at 5:55 PM, Schmidt, Lutz < >> lutz.schmidt at sap.com > wrote: >> >> > > >> >> > > Hi Andrew, Volker, >> >> > > >> >> > > What do you think about these test enhancements? >> >> > > Webrev: http://cr.openjdk.java.net/~lu >> cy/webrevs/8176580.01/ > Elucy/webrevs/8176580.01/> >> >> >> > > >> >> > > Please note: the cpp files in the webrev remained >> unchanged. >> >> > > >> >> > > I added some improvements (as I believe) to the >> TestCRC32(C).java files. >> >> > > >> >> > > In some more detail: >> >> > > The test now calculates a ?reference CRC value?, based on >> a java implementation of the CRC32 algorithm. This reference value is used >> to verify all other crc values, in particular during initialization and >> warmup. Three additional test runs check a non-zero offset with ?Xint, >> -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp -XX:+TieredCompilation (C1 >> + C2). >> >> > > >> >> > >> >> > Hi Lutz, >> >> > >> >> > thanks for updating the tests. I've had a closer look at the >> tests and >> >> > realized that they actually can never fail! The check() >> routine just >> >> > prints an error message but that will not let the test fail. >> So I >> >> > would suggest to throw a runtime exception in the check() >> routine >> >> > after the error message was printed. >> >> > >> >> > I also suggest to do the check during the normal test >> execution (i.e. >> >> > in test_multi()) so there's no need for extra test runs. >> >> > >> >> > Finally, the current test methodology in test_multi() is >> broken: >> >> > - it sets the reference by calling CRC from the interpreter >> which >> >> > won't work if the intrinsic is also used in the interpreter. >> >> > - it only compares the reference against the last >> computation of CRC >> >> > in the loop which will be the result of the C2 generated >> code. This >> >> > misses errors in C1. >> >> > >> >> > I suggest to use your new, pure Java implementation for the >> >> > computation of the reference result and compare the >> reference with the >> >> > result of calling CRC in every iteration of the loop so we >> really >> >> > check all possibilities from interpreter trough C1 to C2. >> >> > >> >> > Finally, can you please pay attention to not insert trailing >> >> > whitespace (there was some at line 88 in TestCRC32C.java). >> You can >> >> > easily verify this by running jcheck before creating the >> webrevs. >> >> > >> >> > Thanks, >> >> > Volker >> >> > >> >> > > >> >> > > Best regards, >> >> > > Lutz >> >> > > >> >> > > >> >> > > On 15.03.17, 11:50, "Volker Simonis" < >> volker.simonis at gmail.com > wrote: >> >> > > >> >> > > On Tue, Mar 14, 2017 at 7:05 PM, Andrew Haley < >> aph at redhat.com > wrote: >> >> > > > On 14/03/17 13:12, Schmidt, Lutz wrote: >> >> > > > >> >> > > >> Yes, one might think of running a test suite subset >> multiple times >> >> > > >> with different parameters. In this case, -Xint >> and/or ?Xcomp were >> >> > > >> helpful. Forcing tests to run fully interpreted or >> fully compiled >> >> > > >> helps in cases where a certain function, e.g. an >> intrinsic, is >> >> > > >> invoked via distinct code paths. >> >> > > > >> >> > > > Right, so your patch should include that change to >> the test suite. >> >> > > > >> >> > > >> >> > > Hi Lutz, >> >> > > >> >> > > I agree with Andrew. We should really fix the tests >> such that they >> >> > > check the correctness of the intrinsics. >> >> > > >> >> > > This may be tricky if all three, the interpreter, the >> client and the >> >> > > server compiler use the same intrinsic implementation. >> You could >> >> > > either copy the pure Java implementation into the test >> so that you can >> >> > > compare the results of the intrinsic operation against >> it or you can >> >> > > switch them off in the compilers with >> >> > > "-XX:DisableIntrinsic=_updateBytesCRC32C >> >> > > -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and >> compare the >> >> > > results. Not sure which solution is more practical, >> but I would be >> >> > > really scared if we wouldn't have these test. >> >> > > >> >> > > Regards, >> >> > > Volker >> >> > > >> >> > > > Andrew. >> >> > > > >> >> > > >> >> > > >> >> > >> >> > >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Wed Apr 12 00:42:23 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 11 Apr 2017 20:42:23 -0400 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: <698EFCB4-7019-442C-A611-D2D36DA474CB@oracle.com> References: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> <138b60b8-51d9-e8fc-62c0-457c7b4cb40f@oracle.com> <698EFCB4-7019-442C-A611-D2D36DA474CB@oracle.com> Message-ID: <08FD6DB1-C826-419B-8716-CFD7AAAD3327@oracle.com> > On Apr 10, 2017, at 9:00 PM, Kim Barrett wrote: > >> On Apr 10, 2017, at 3:43 PM, Vladimir Kozlov wrote: >> >> Hi, Kim >> >> Please, also correct vector registers (need to fix *.ad files too): >> >> // Vector ideal reg >> static const int vector_ideal_reg(int len); >> static const int vector_shift_count_ideal_reg(int len); > > Oops, I missed those. Testing that change. I?ll put out a new webrev when that?s done. Here are the requested additional fixes for vector_ideal_reg and vector_shift_count_ideal_reg. full: http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.01/ incr: http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.01.inc/ Note that I've not tested the aarch64, ppc, or s390 changes at all. They are pretty simple though, so hopefully no problems. From kim.barrett at oracle.com Wed Apr 12 01:03:37 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 11 Apr 2017 21:03:37 -0400 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: <55a6a298-f97d-3207-1f75-73a20d04ea61@oracle.com> References: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> <138b60b8-51d9-e8fc-62c0-457c7b4cb40f@oracle.com> <698EFCB4-7019-442C-A611-D2D36DA474CB@oracle.com> <55a6a298-f97d-3207-1f75-73a20d04ea61@oracle.com> Message-ID: <8E0593E3-7DA3-42B8-86C5-110BB952EAD1@oracle.com> > On Apr 10, 2017, at 9:53 PM, Vladimir Kozlov wrote: > > On 4/10/17 6:00 PM, Kim Barrett wrote: >>> On Apr 10, 2017, at 3:43 PM, Vladimir Kozlov wrote: >>> >>> Hi, Kim >>> >>> Please, also correct vector registers (need to fix *.ad files too): >>> >>> // Vector ideal reg >>> static const int vector_ideal_reg(int len); >>> static const int vector_shift_count_ideal_reg(int len); >> >> Oops, I missed those. Testing that change. I?ll put out a new webrev when that?s done. >> >>> Can you do the same for OptoReg::reg2stack()? Or file separate RFE for it. >> >> I?m not sure what it is you are asking for here. > > There are useless conversions there too. For example: > > static unsigned int reg2stack( OptoReg::Name r) { > > int stack_slot = reg2stack(n); > > But it is a lot more changes since stack2reg(int idx) and others have singed argument. And I don't remember if negative values are used in such case. That is why I said may be to do it in separate RFE. At a high level, I think this is covered by JDK-8135181, and would be part of the JDK-8177482 subtask. If you want something more specific than that right now, it might be better for you or some other person with better understanding of the compiler than I have to put a sensible RFE together. About all I could say is that reg2stack returns uint but many callers treat the result as an int. But maybe that?s all you are asking for? From vladimir.kozlov at oracle.com Wed Apr 12 02:38:41 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Apr 2017 19:38:41 -0700 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: <08FD6DB1-C826-419B-8716-CFD7AAAD3327@oracle.com> References: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> <138b60b8-51d9-e8fc-62c0-457c7b4cb40f@oracle.com> <698EFCB4-7019-442C-A611-D2D36DA474CB@oracle.com> <08FD6DB1-C826-419B-8716-CFD7AAAD3327@oracle.com> Message-ID: Good. Thanks, Vladimir On 4/11/17 5:42 PM, Kim Barrett wrote: >> On Apr 10, 2017, at 9:00 PM, Kim Barrett wrote: >> >>> On Apr 10, 2017, at 3:43 PM, Vladimir Kozlov wrote: >>> >>> Hi, Kim >>> >>> Please, also correct vector registers (need to fix *.ad files too): >>> >>> // Vector ideal reg >>> static const int vector_ideal_reg(int len); >>> static const int vector_shift_count_ideal_reg(int len); >> >> Oops, I missed those. Testing that change. I?ll put out a new webrev when that?s done. > > Here are the requested additional fixes for vector_ideal_reg and > vector_shift_count_ideal_reg. > > full: http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.01.inc/ > > Note that I've not tested the aarch64, ppc, or s390 changes at all. > They are pretty simple though, so hopefully no problems. > > From vladimir.kozlov at oracle.com Wed Apr 12 02:41:27 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Apr 2017 19:41:27 -0700 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: <8E0593E3-7DA3-42B8-86C5-110BB952EAD1@oracle.com> References: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> <138b60b8-51d9-e8fc-62c0-457c7b4cb40f@oracle.com> <698EFCB4-7019-442C-A611-D2D36DA474CB@oracle.com> <55a6a298-f97d-3207-1f75-73a20d04ea61@oracle.com> <8E0593E3-7DA3-42B8-86C5-110BB952EAD1@oracle.com> Message-ID: On 4/11/17 6:03 PM, Kim Barrett wrote: >> On Apr 10, 2017, at 9:53 PM, Vladimir Kozlov wrote: >> >> On 4/10/17 6:00 PM, Kim Barrett wrote: >>>> On Apr 10, 2017, at 3:43 PM, Vladimir Kozlov wrote: >>>> >>>> Hi, Kim >>>> >>>> Please, also correct vector registers (need to fix *.ad files too): >>>> >>>> // Vector ideal reg >>>> static const int vector_ideal_reg(int len); >>>> static const int vector_shift_count_ideal_reg(int len); >>> >>> Oops, I missed those. Testing that change. I?ll put out a new webrev when that?s done. >>> >>>> Can you do the same for OptoReg::reg2stack()? Or file separate RFE for it. >>> >>> I?m not sure what it is you are asking for here. >> >> There are useless conversions there too. For example: >> >> static unsigned int reg2stack( OptoReg::Name r) { >> >> int stack_slot = reg2stack(n); >> >> But it is a lot more changes since stack2reg(int idx) and others have singed argument. And I don't remember if negative values are used in such case. That is why I said may be to do it in separate RFE. > > At a high level, I think this is covered by JDK-8135181, and would be part of the JDK-8177482 subtask. Good. We will take care about this when work on 8177482. > If you want something more specific than that right now, it might be better for you or some other person > with better understanding of the compiler than I have to put a sensible RFE together. About all I could > say is that reg2stack returns uint but many callers treat the result as an int. But maybe that?s all you are > asking for? I did not know about 8177482 before. It should cover the issue I mentioned. Thanks, Vladimir > > From kim.barrett at oracle.com Wed Apr 12 05:12:18 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 12 Apr 2017 01:12:18 -0400 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: References: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> <138b60b8-51d9-e8fc-62c0-457c7b4cb40f@oracle.com> <698EFCB4-7019-442C-A611-D2D36DA474CB@oracle.com> <08FD6DB1-C826-419B-8716-CFD7AAAD3327@oracle.com> Message-ID: <43881C2E-5958-4EA6-9027-703EF04A4BCE@oracle.com> > On Apr 11, 2017, at 10:38 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir Thanks. > On 4/11/17 5:42 PM, Kim Barrett wrote: >>> On Apr 10, 2017, at 9:00 PM, Kim Barrett wrote: >>> >>>> On Apr 10, 2017, at 3:43 PM, Vladimir Kozlov wrote: >>>> >>>> Hi, Kim >>>> >>>> Please, also correct vector registers (need to fix *.ad files too): >>>> >>>> // Vector ideal reg >>>> static const int vector_ideal_reg(int len); >>>> static const int vector_shift_count_ideal_reg(int len); >>> >>> Oops, I missed those. Testing that change. I?ll put out a new webrev when that?s done. >> >> Here are the requested additional fixes for vector_ideal_reg and >> vector_shift_count_ideal_reg. >> >> full: http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.01.inc/ >> >> Note that I've not tested the aarch64, ppc, or s390 changes at all. >> They are pretty simple though, so hopefully no problems. From kim.barrett at oracle.com Wed Apr 12 05:12:58 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 12 Apr 2017 01:12:58 -0400 Subject: RFR: 8160748: Inconsistent types for ideal_reg In-Reply-To: References: <877C3DB2-E0EB-4365-8DB7-5B056B1831D3@oracle.com> <138b60b8-51d9-e8fc-62c0-457c7b4cb40f@oracle.com> <698EFCB4-7019-442C-A611-D2D36DA474CB@oracle.com> <55a6a298-f97d-3207-1f75-73a20d04ea61@oracle.com> <8E0593E3-7DA3-42B8-86C5-110BB952EAD1@oracle.com> Message-ID: > On Apr 11, 2017, at 10:41 PM, Vladimir Kozlov wrote: > > > > On 4/11/17 6:03 PM, Kim Barrett wrote: >>> On Apr 10, 2017, at 9:53 PM, Vladimir Kozlov wrote: >>> >>> On 4/10/17 6:00 PM, Kim Barrett wrote: >>>>> On Apr 10, 2017, at 3:43 PM, Vladimir Kozlov wrote: >>>>> >>>>> Hi, Kim >>>>> >>>>> Please, also correct vector registers (need to fix *.ad files too): >>>>> >>>>> // Vector ideal reg >>>>> static const int vector_ideal_reg(int len); >>>>> static const int vector_shift_count_ideal_reg(int len); >>>> >>>> Oops, I missed those. Testing that change. I?ll put out a new webrev when that?s done. >>>> >>>>> Can you do the same for OptoReg::reg2stack()? Or file separate RFE for it. >>>> >>>> I?m not sure what it is you are asking for here. >>> >>> There are useless conversions there too. For example: >>> >>> static unsigned int reg2stack( OptoReg::Name r) { >>> >>> int stack_slot = reg2stack(n); >>> >>> But it is a lot more changes since stack2reg(int idx) and others have singed argument. And I don't remember if negative values are used in such case. That is why I said may be to do it in separate RFE. >> >> At a high level, I think this is covered by JDK-8135181, and would be part of the JDK-8177482 subtask. > > Good. We will take care about this when work on 8177482. > >> If you want something more specific than that right now, it might be better for you or some other person >> with better understanding of the compiler than I have to put a sensible RFE together. About all I could >> say is that reg2stack returns uint but many callers treat the result as an int. But maybe that?s all you are >> asking for? > > I did not know about 8177482 before. It should cover the issue I mentioned. > > Thanks, > Vladimir OK, I?ll leave it at that. From rickard.backman at oracle.com Wed Apr 12 06:40:31 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 12 Apr 2017 08:40:31 +0200 Subject: RFR(s): 8178363: Incorrect check for nmethod re-registration in C1 In-Reply-To: References: <9f8a9ea6-b067-37e4-57ea-bcc22a26426e@oracle.com> <83e5e130-9c55-0cab-238b-fd8efea103f7@oracle.com> Message-ID: <20170412064030.GI31838@rbackman> Looks good. On 04/10, Per Liden wrote: > Hi Stefan, > > On 2017-04-10 09:31, Stefan Karlsson wrote: > >On 2017-04-10 09:05, Per Liden wrote: > >>Hi, > >> > >>When an nmethod is compiled, it's registered with the heap if > >>ScavengeRootsInCode is non-zero (which it always is). However, during > >>code patching in C1 we re-register the nmethod with the heap only if it > >>also has scavengable oops. This additional requirement is only valid for > >>calls to CodeCache::add_scavenge_root_nmethod(), and not for > >>CollectedHeap::register_nmethod(). This happens to work today since G1's > >>is_scavengable() basically always returns true. > >> > >>Bug: https://bugs.openjdk.java.net/browse/JDK-8178363 > >>Webrev: http://cr.openjdk.java.net/~pliden/8178363/webrev.0/ > >>Testing: jprt > > > >Looks good, from a GC perspective. > > Thanks for reviewing! > > > > >For non-G1 GCs, we now, unnecessarily, take the CodCache lock and call > >find_nmethod even when mirror and appendix are non-scavengable. Maybe > >this should be reviewed on hotspot-comp-dev as well? > > Sure, adding comp-dev. > > thanks, > Per > > > > >Thanks, > >StefanK > > > >> > >>cheers, > >>Per /R From per.liden at oracle.com Wed Apr 12 06:41:32 2017 From: per.liden at oracle.com (Per Liden) Date: Wed, 12 Apr 2017 08:41:32 +0200 Subject: RFR(s): 8178363: Incorrect check for nmethod re-registration in C1 In-Reply-To: <20170412064030.GI31838@rbackman> References: <9f8a9ea6-b067-37e4-57ea-bcc22a26426e@oracle.com> <83e5e130-9c55-0cab-238b-fd8efea103f7@oracle.com> <20170412064030.GI31838@rbackman> Message-ID: <0c277326-0ece-0194-fe3c-584e3950f54e@oracle.com> On 2017-04-12 08:40, Rickard B?ckman wrote: > Looks good. Thanks Rickard! cheers, Per > > On 04/10, Per Liden wrote: >> Hi Stefan, >> >> On 2017-04-10 09:31, Stefan Karlsson wrote: >>> On 2017-04-10 09:05, Per Liden wrote: >>>> Hi, >>>> >>>> When an nmethod is compiled, it's registered with the heap if >>>> ScavengeRootsInCode is non-zero (which it always is). However, during >>>> code patching in C1 we re-register the nmethod with the heap only if it >>>> also has scavengable oops. This additional requirement is only valid for >>>> calls to CodeCache::add_scavenge_root_nmethod(), and not for >>>> CollectedHeap::register_nmethod(). This happens to work today since G1's >>>> is_scavengable() basically always returns true. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178363 >>>> Webrev: http://cr.openjdk.java.net/~pliden/8178363/webrev.0/ >>>> Testing: jprt >>> >>> Looks good, from a GC perspective. >> >> Thanks for reviewing! >> >>> >>> For non-G1 GCs, we now, unnecessarily, take the CodCache lock and call >>> find_nmethod even when mirror and appendix are non-scavengable. Maybe >>> this should be reviewed on hotspot-comp-dev as well? >> >> Sure, adding comp-dev. >> >> thanks, >> Per >> >>> >>> Thanks, >>> StefanK >>> >>>> >>>> cheers, >>>> Per > > /R > From david.holmes at oracle.com Wed Apr 12 07:26:00 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 17:26:00 +1000 Subject: RFR 8026985: Rewrite SystemDictionary::classes_do and Dictionary::classes_do to use KlassClosure In-Reply-To: <22759e6d-0b05-1e34-1e73-5bf3b974ad95@oracle.com> References: <2ae47703-2c17-548c-f278-2c25647f1cc7@oracle.com> <913ac7b4-affe-0e69-b5dd-95e6727514c0@oracle.com> <7B03B1D3-57B2-44D7-8B89-8C729B20B31A@oracle.com> <22759e6d-0b05-1e34-1e73-5bf3b974ad95@oracle.com> Message-ID: <3a530d13-00f4-049e-7613-3aa0f8b7234f@oracle.com> Hi Coleen, This all seems quite reasonable. It is good to see so much code deleted! Thanks, David On 11/04/2017 7:12 AM, coleen.phillimore at oracle.com wrote: > > Hi, I've reopened this cleanup. To be clear, I didn't change which of > classes_do are called except for two places in this change. > > One is print_method_profiling_data because it doesn't make sense for > this not to print methods for anonymous classes and method handle > intrinsics. See SystemDictionary::methods_do() implementation. I > added hotspot-compiler-dev to this review so hopefully someone from the > compiler group can verify this. > > The second is heapDumper.cpp because it seemed an obvious bug that if > !ClassUnloading that all the classes shouldn't be dumped as STICKY > classes. Tested with jvmti and heapdump tests. > > I've put this data you requested in the bug report as a comment. We > could probably file about 4 more bugs to cleanup the calls sites for > classes_do, so that the design is clearer, but I didn't want to do it > all in this one change and mix it up with the functions that I found > were unused and this change got large enough. > > New webrev: > > open webrev at http://cr.openjdk.java.net/~coleenp/8026985.03/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8026985 > > Thanks! > Coleen > > On 3/14/17 10:43 AM, Karen Kinnear wrote: >> Coleen, >> >> I am concerned about exposure of: >> 1) not yet loaded classes >> 2) scratch-classes >> 3) classes that are not live due to JFR, parallel class loading or >> load errors >> >> Could you please make us a table of those who walk the classes: >> which classes they saw before >> which classes they see now - and why the change is ok >> what tests you have for each of the boxes in the table - both that >> you see what you want, and that you do not see >> what should not be exposed. >> >> My understanding is that this is intended to speed up GC but not to >> change behaviors. >> I am concerned about the exposure to non-GC walkers. >> >> thanks, >> Karen >> >>> On Mar 13, 2017, at 8:30 PM, David Holmes >>> wrote: >>> >>> Hi Coleen, >>> >>> On 11/03/2017 12:39 AM, coleen.phillimore at oracle.com >>> wrote: >>>> David, Thank you for reviewing. >>>> >>>> On 3/10/17 12:18 AM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 9/03/2017 2:24 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Clean up and examine uses of classes_do for the >>>>>> SystemDictionary >>>>>> >>>>>> See bug comments for more details. I wanted to clean this up while >>>>>> examining the idea of having system dictionary information added per >>>>>> ClassLoaderData, rather than a global table. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026985.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026985 >>>>> The bulk of the deletion looks good! :) >>>>> >>>>> I guess my main query is how ClassLoaderDataGraph::classes_do / >>>>> loaded_classes_do relate to SystemDictionary::classes_do? I would >>>>> presume SD::classes_do can only act on loaded classes - by definition. >>>>> So then it is unclear how you can replace it with either of the CLDG >>>>> methods? >>>> True, loaded_classes_do only walks loaded classes, which is probably >>>> what we want most of the time. I was trying to figure this out and the >>>> differences which led to this change. I am trying to make it less >>>> confusing. At least for me! >>>> >>>> The ClassLoaderData::classes_do includes anonymous, array and allocated >>>> classes. Most of the time we want the first two. For GC we want the >>>> last (because it has a mirror to walk). The SystemDictionary only has >>>> loaded InstanceKlasses, both with defined loader and initiating >>>> loader. Except for one place in the code, we ignore the entries with >>>> initiating loader. >>> I'm still very unclear as to why it is now okay to expand the set of >>> klasses being walked at a given point. For example: >>> >>> src/share/vm/oops/klassVtable.cpp >>> >>> static void compute() { >>> - SystemDictionary::classes_do(do_class); >>> + ClassLoaderDataGraph::classes_do(do_class); >>> >>> IIUC SD::classes_do does not see anonymous classes, but >>> CLDG::classes_do does. Why is this okay? >>> >>> You mentioned bugs like JDK-8024423 "missing anonymous classes" but >>> my limited understanding of that bug suggests to me that the fix was >>> to completely hide anonymous classes not to expose them! They should >>> not be visible to JVM TI as I understand the intent of VM anonymous >>> classes! >>> >>> Thanks, >>> David >>> ----- >>> >>>> The only place where methods_do() is called for all the methods is for >>>> print_method_data_histogram and print_method_profiling_data. These >>>> should only use loaded classes, so I've made the change below: >>>> >>>> void ClassLoaderData::methods_do(void f(Method*)) { >>>> // Lock-free access requires load_ptr_acquire >>>> for (Klass* k = load_ptr_acquire(&_klasses); k != NULL; k = >>>> k->next_link()) { >>>> if (k->is_instance_klass() && >>>> InstanceKlass::cast(k)->is_loaded()) { >>>> InstanceKlass::cast(k)->methods_do(f); >>>> } >>>> } >>>> } >>>>> It also seems a little odd to switch from SD to CLDG for classes_do, >>>>> but go the other way, from CLDG to SD for methods_do ? I would >>>>> expect/hope to have a single "entry point" for this kind of iteration. >>>> I know. Unfortunately SD::methods_do includes the methods added for >>>> MethodHandle intrinsics, which is owned by SystemDictionary. >>>> >>>> void SystemDictionary::methods_do(void f(Method*)) { >>>> ClassLoaderDataGraph::methods_do(f); >>>> invoke_method_table()->methods_do(f); >>>> } >>>> >>>> I don't like this either. This invoke_method_table() really has >>>> nothing to do with the Dictionary, it's just where it ended up. I >>>> could >>>> expand the change to find a better place for it. I don't know where >>>> would be good though. >>>> >>>> Aside, I'd forgotten about invoke_method_table - it seems to be a >>>> mechanism for isolated methods. >>>> >>>> Coleen >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Tested with java.lang.instrument, sun.com.jdi, tonga colocated >>>>>> (closed) >>>>>> tests, and JPRT, because of difference in which classes_do is >>>>>> called for >>>>>> heap dumping. >>>>>> >>>>>> Note, will update copyrights on commit. >>>>>> >>>>>> Thanks, >>>>>> Coleen > From zoltan.majo at oracle.com Wed Apr 12 11:07:42 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 12 Apr 2017 13:07:42 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <1C84273B-2FA8-4B91-B412-0D2F815C13F2@sap.com> <9bc87d3e-a657-1e10-f688-e51e4e26645d@redhat.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> Message-ID: <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> Hi Volker, Hi Lutz, yesterday I tried to push webrev.03 using JPRT. Unfortunately, the TestCRC32C.java test you've modified fails on Mac OS X on x86_64. Do you have an idea why that could be? Thank you! Best regards, Zoltan On 04/11/2017 06:03 PM, Volker Simonis wrote: > Thanks a lot Zoltan! > > > On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? > wrote: > > Hi Volker, > > > On 04/11/2017 03:34 PM, Volker Simonis wrote: > > > Hi Zoltan, > > could you please be so kind to sponsor this reviewed change > for jdk10? > > > yes, of course. I'll push it today. > > Best regards, > > > Zoltan > > Initially we wanted to push it ourselves because it was s390x > only but now that we've also touched the tests we need a sponsor. > > Thank you and best regards, > Volker > > ---------- Forwarded message ---------- > From: *Volker Simonis* > >> > Date: Fri, Mar 31, 2017 at 10:53 AM > Subject: Re: RFR (S) 8176580: [ppc, s390] CRC32C: wrong > checksum result in some cases > To: "Schmidt, Lutz" >> > Cc: Andrew Haley > >>, > "hotspot-compiler-dev at openjdk.java.net > > >" > > >> > > > Ping... > > Can somebody please push this change? > > It's ppc64/s390x only but as a courtesy to the community it > also fixes > the CRC JTreg tests so unfortunately I still can't push it > myself :) > > Thank you and best regards, > Volker > > > On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis > > >> wrote: > > Hi Lutz, > > > > thanks a lot for fixing the test! > > Your change looks good now. > > > > Because this touches shared (i.e. test) files, we still need > a sponsor > > so can somebody please sponsor this change? > > > > Thank you and best regards, > > Volker > > > > > > > > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz > > >> > wrote: > >> Hi Volker, > >> > >> Sorry for letting you wait. Here is the final(?) webrev, > containing all your requests for cleanup and improvements: > >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ > > > > >> > >> As before, the *.cpp files have not been modified. > >> > >> Best Regards, > >> Lutz > >> > >> > >> > >> On 21/03/2017, 17:55, "Volker Simonis" > > >> wrote: > >> > >> Hi Lutz, > >> > >> thanks a lot for updating the tests. I think they look > much better now. > >> > >> There's just one more cleanup I'd like to propose. Can > you please move > >> the throw right into the check() function. Just make > check() return > >> void and throw from it if there's a mismatch between > the computed and > >> the expected result. I leave it up to you if you want > to pass an extra > >> error string to check() which will be printed in the > case of an error. > >> I personally don't think that's necessary as it will be > evident from > >> the stack trace which computation failed. > >> > >> Also the try/catch and rethrow in test_multi() isn't > necessary. The > >> test can be simply terminated by the initial exception. > >> > >> Thank you and best regards, > >> Volker > >> > >> > >> On Fri, Mar 17, 2017 at 10:03 PM, Schmidt, Lutz > > >> > wrote: > >> > Hi Volker, > >> > > >> > Thanks a lot for your valuable hints. > >> > > >> > I have worked some time on the Java test files: > >> > TestCRC32.java and TestCRC32C.java are now > identical as far as possible. > >> > They now throw an exception, should any error be > detected. > >> > The ?reference CRC value? is now used in > test_multi() as well. > >> > The extra test runs have been removed again. > >> > The test methodology is fixed: each result is > tested against its reference. > >> > The tests now detect the bug introduced with > 8175368 and 8175369. > >> > No issue is indicated when testing with 8176580. > >> > I ran jcheck, and to the best of my ability and > knowledge, there is no trailing whitespace. > >> > All *.cpp files were left untouched! > >> > > >> > The next iteration of the webrev: > http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ > > > > >> > > >> > Best regards, > >> > Lutz > >> > > >> > > >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 > (6227) 7-42834 > > >> > > >> > > >> > > >> > On 16.03.17, 11:28, "Volker Simonis" > > >> wrote: > >> > > >> > On Wed, Mar 15, 2017 at 5:55 PM, Schmidt, Lutz > > >> > wrote: > >> > > > >> > > Hi Andrew, Volker, > >> > > > >> > > What do you think about these test enhancements? > >> > > Webrev: > http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ > > > > > >> > > > >> > > Please note: the cpp files in the webrev > remained unchanged. > >> > > > >> > > I added some improvements (as I believe) to the > TestCRC32(C).java files. > >> > > > >> > > In some more detail: > >> > > The test now calculates a ?reference CRC > value?, based on a java implementation of the CRC32 algorithm. > This reference value is used to verify all other crc values, > in particular during initialization and warmup. Three > additional test runs check a non-zero offset with ?Xint, > -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp > -XX:+TieredCompilation (C1 + C2). > >> > > > >> > > >> > Hi Lutz, > >> > > >> > thanks for updating the tests. I've had a closer > look at the tests and > >> > realized that they actually can never fail! The > check() routine just > >> > prints an error message but that will not let the > test fail. So I > >> > would suggest to throw a runtime exception in the > check() routine > >> > after the error message was printed. > >> > > >> > I also suggest to do the check during the normal > test execution (i.e. > >> > in test_multi()) so there's no need for extra > test runs. > >> > > >> > Finally, the current test methodology in > test_multi() is broken: > >> > - it sets the reference by calling CRC from the > interpreter which > >> > won't work if the intrinsic is also used in the > interpreter. > >> > - it only compares the reference against the > last computation of CRC > >> > in the loop which will be the result of the C2 > generated code. This > >> > misses errors in C1. > >> > > >> > I suggest to use your new, pure Java > implementation for the > >> > computation of the reference result and compare > the reference with the > >> > result of calling CRC in every iteration of the > loop so we really > >> > check all possibilities from interpreter trough > C1 to C2. > >> > > >> > Finally, can you please pay attention to not > insert trailing > >> > whitespace (there was some at line 88 in > TestCRC32C.java). You can > >> > easily verify this by running jcheck before > creating the webrevs. > >> > > >> > Thanks, > >> > Volker > >> > > >> > > > >> > > Best regards, > >> > > Lutz > >> > > > >> > > > >> > > On 15.03.17, 11:50, "Volker Simonis" > > >> wrote: > >> > > > >> > > On Tue, Mar 14, 2017 at 7:05 PM, Andrew > Haley > >> wrote: > >> > > > On 14/03/17 13:12, Schmidt, Lutz wrote: > >> > > > > >> > > >> Yes, one might think of running a test > suite subset multiple times > >> > > >> with different parameters. In this case, > -Xint and/or ?Xcomp were > >> > > >> helpful. Forcing tests to run fully > interpreted or fully compiled > >> > > >> helps in cases where a certain function, > e.g. an intrinsic, is > >> > > >> invoked via distinct code paths. > >> > > > > >> > > > Right, so your patch should include that > change to the test suite. > >> > > > > >> > > > >> > > Hi Lutz, > >> > > > >> > > I agree with Andrew. We should really fix > the tests such that they > >> > > check the correctness of the intrinsics. > >> > > > >> > > This may be tricky if all three, the > interpreter, the client and the > >> > > server compiler use the same intrinsic > implementation. You could > >> > > either copy the pure Java implementation > into the test so that you can > >> > > compare the results of the intrinsic > operation against it or you can > >> > > switch them off in the compilers with > >> > > "-XX:DisableIntrinsic=_updateBytesCRC32C > >> > > > -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and > compare the > >> > > results. Not sure which solution is more > practical, but I would be > >> > > really scared if we wouldn't have these test. > >> > > > >> > > Regards, > >> > > Volker > >> > > > >> > > > Andrew. > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > > > From zoltan.majo at oracle.com Wed Apr 12 11:10:04 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 12 Apr 2017 13:10:04 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <1C84273B-2FA8-4B91-B412-0D2F815C13F2@sap.com> <9bc87d3e-a657-1e10-f688-e51e4e26645d@redhat.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> Message-ID: P.S.: Forgot to mention: The problem does not appear on any other x86_64 platform. On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > Hi Volker, > Hi Lutz, > > > yesterday I tried to push webrev.03 using JPRT. Unfortunately, the > TestCRC32C.java test you've modified fails on Mac OS X on x86_64. Do > you have an idea why that could be? > > Thank you! Best regards, > > > Zoltan > > On 04/11/2017 06:03 PM, Volker Simonis wrote: >> Thanks a lot Zoltan! >> >> >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? > > wrote: >> >> Hi Volker, >> >> >> On 04/11/2017 03:34 PM, Volker Simonis wrote: >> >> >> Hi Zoltan, >> >> could you please be so kind to sponsor this reviewed change >> for jdk10? >> >> >> yes, of course. I'll push it today. >> >> Best regards, >> >> >> Zoltan >> >> Initially we wanted to push it ourselves because it was s390x >> only but now that we've also touched the tests we need a >> sponsor. >> >> Thank you and best regards, >> Volker >> >> ---------- Forwarded message ---------- >> From: *Volker Simonis* > >> > >> >> Date: Fri, Mar 31, 2017 at 10:53 AM >> Subject: Re: RFR (S) 8176580: [ppc, s390] CRC32C: wrong >> checksum result in some cases >> To: "Schmidt, Lutz" > > >> >> Cc: Andrew Haley >> >>, >> "hotspot-compiler-dev at openjdk.java.net >> >> > >" >> > >> > >> >> >> >> Ping... >> >> Can somebody please push this change? >> >> It's ppc64/s390x only but as a courtesy to the community it >> also fixes >> the CRC JTreg tests so unfortunately I still can't push it >> myself :) >> >> Thank you and best regards, >> Volker >> >> >> On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis >> >> > >> wrote: >> > Hi Lutz, >> > >> > thanks a lot for fixing the test! >> > Your change looks good now. >> > >> > Because this touches shared (i.e. test) files, we still need >> a sponsor >> > so can somebody please sponsor this change? >> > >> > Thank you and best regards, >> > Volker >> > >> > >> > >> > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz >> >> >> >> wrote: >> >> Hi Volker, >> >> >> >> Sorry for letting you wait. Here is the final(?) webrev, >> containing all your requests for cleanup and improvements: >> >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ >> >> > > >> >> >> >> As before, the *.cpp files have not been modified. >> >> >> >> Best Regards, >> >> Lutz >> >> >> >> >> >> >> >> On 21/03/2017, 17:55, "Volker Simonis" >> >> > >> wrote: >> >> >> >> Hi Lutz, >> >> >> >> thanks a lot for updating the tests. I think they look >> much better now. >> >> >> >> There's just one more cleanup I'd like to propose. Can >> you please move >> >> the throw right into the check() function. Just make >> check() return >> >> void and throw from it if there's a mismatch between >> the computed and >> >> the expected result. I leave it up to you if you want >> to pass an extra >> >> error string to check() which will be printed in the >> case of an error. >> >> I personally don't think that's necessary as it will be >> evident from >> >> the stack trace which computation failed. >> >> >> >> Also the try/catch and rethrow in test_multi() isn't >> necessary. The >> >> test can be simply terminated by the initial exception. >> >> >> >> Thank you and best regards, >> >> Volker >> >> >> >> >> >> On Fri, Mar 17, 2017 at 10:03 PM, Schmidt, Lutz >> >> >> >> wrote: >> >> > Hi Volker, >> >> > >> >> > Thanks a lot for your valuable hints. >> >> > >> >> > I have worked some time on the Java test files: >> >> > TestCRC32.java and TestCRC32C.java are now >> identical as far as possible. >> >> > They now throw an exception, should any error be >> detected. >> >> > The ?reference CRC value? is now used in >> test_multi() as well. >> >> > The extra test runs have been removed again. >> >> > The test methodology is fixed: each result is >> tested against its reference. >> >> > The tests now detect the bug introduced with >> 8175368 and 8175369. >> >> > No issue is indicated when testing with 8176580. >> >> > I ran jcheck, and to the best of my ability and >> knowledge, there is no trailing whitespace. >> >> > All *.cpp files were left untouched! >> >> > >> >> > The next iteration of the webrev: >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ >> >> > > >> >> > >> >> > Best regards, >> >> > Lutz >> >> > >> >> > >> >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 >> (6227) 7-42834 >> >> >> > >> >> > >> >> > >> >> > On 16.03.17, 11:28, "Volker Simonis" >> >> > >> wrote: >> >> > >> >> > On Wed, Mar 15, 2017 at 5:55 PM, Schmidt, Lutz >> >> >> >> wrote: >> >> > > >> >> > > Hi Andrew, Volker, >> >> > > >> >> > > What do you think about these test enhancements? >> >> > > Webrev: >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ >> >> > > >> >> >> > > >> >> > > Please note: the cpp files in the webrev >> remained unchanged. >> >> > > >> >> > > I added some improvements (as I believe) to the >> TestCRC32(C).java files. >> >> > > >> >> > > In some more detail: >> >> > > The test now calculates a ?reference CRC >> value?, based on a java implementation of the CRC32 algorithm. >> This reference value is used to verify all other crc values, >> in particular during initialization and warmup. Three >> additional test runs check a non-zero offset with ?Xint, >> -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp >> -XX:+TieredCompilation (C1 + C2). >> >> > > >> >> > >> >> > Hi Lutz, >> >> > >> >> > thanks for updating the tests. I've had a closer >> look at the tests and >> >> > realized that they actually can never fail! The >> check() routine just >> >> > prints an error message but that will not let the >> test fail. So I >> >> > would suggest to throw a runtime exception in the >> check() routine >> >> > after the error message was printed. >> >> > >> >> > I also suggest to do the check during the normal >> test execution (i.e. >> >> > in test_multi()) so there's no need for extra >> test runs. >> >> > >> >> > Finally, the current test methodology in >> test_multi() is broken: >> >> > - it sets the reference by calling CRC from the >> interpreter which >> >> > won't work if the intrinsic is also used in the >> interpreter. >> >> > - it only compares the reference against the >> last computation of CRC >> >> > in the loop which will be the result of the C2 >> generated code. This >> >> > misses errors in C1. >> >> > >> >> > I suggest to use your new, pure Java >> implementation for the >> >> > computation of the reference result and compare >> the reference with the >> >> > result of calling CRC in every iteration of the >> loop so we really >> >> > check all possibilities from interpreter trough >> C1 to C2. >> >> > >> >> > Finally, can you please pay attention to not >> insert trailing >> >> > whitespace (there was some at line 88 in >> TestCRC32C.java). You can >> >> > easily verify this by running jcheck before >> creating the webrevs. >> >> > >> >> > Thanks, >> >> > Volker >> >> > >> >> > > >> >> > > Best regards, >> >> > > Lutz >> >> > > >> >> > > >> >> > > On 15.03.17, 11:50, "Volker Simonis" >> >> > >> wrote: >> >> > > >> >> > > On Tue, Mar 14, 2017 at 7:05 PM, Andrew >> Haley >> >> wrote: >> >> > > > On 14/03/17 13:12, Schmidt, Lutz wrote: >> >> > > > >> >> > > >> Yes, one might think of running a test >> suite subset multiple times >> >> > > >> with different parameters. In this case, >> -Xint and/or ?Xcomp were >> >> > > >> helpful. Forcing tests to run fully >> interpreted or fully compiled >> >> > > >> helps in cases where a certain function, >> e.g. an intrinsic, is >> >> > > >> invoked via distinct code paths. >> >> > > > >> >> > > > Right, so your patch should include that >> change to the test suite. >> >> > > > >> >> > > >> >> > > Hi Lutz, >> >> > > >> >> > > I agree with Andrew. We should really fix >> the tests such that they >> >> > > check the correctness of the intrinsics. >> >> > > >> >> > > This may be tricky if all three, the >> interpreter, the client and the >> >> > > server compiler use the same intrinsic >> implementation. You could >> >> > > either copy the pure Java implementation >> into the test so that you can >> >> > > compare the results of the intrinsic >> operation against it or you can >> >> > > switch them off in the compilers with >> >> > > "-XX:DisableIntrinsic=_updateBytesCRC32C >> >> > > >> -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and >> compare the >> >> > > results. Not sure which solution is more >> practical, but I would be >> >> > > really scared if we wouldn't have these test. >> >> > > >> >> > > Regards, >> >> > > Volker >> >> > > >> >> > > > Andrew. >> >> > > > >> >> > > >> >> > > >> >> > >> >> > >> >> >> >> >> >> >> > From coleen.phillimore at oracle.com Wed Apr 12 11:59:03 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 12 Apr 2017 07:59:03 -0400 Subject: RFR 8026985: Rewrite SystemDictionary::classes_do and Dictionary::classes_do to use KlassClosure In-Reply-To: <3a530d13-00f4-049e-7613-3aa0f8b7234f@oracle.com> References: <2ae47703-2c17-548c-f278-2c25647f1cc7@oracle.com> <913ac7b4-affe-0e69-b5dd-95e6727514c0@oracle.com> <7B03B1D3-57B2-44D7-8B89-8C729B20B31A@oracle.com> <22759e6d-0b05-1e34-1e73-5bf3b974ad95@oracle.com> <3a530d13-00f4-049e-7613-3aa0f8b7234f@oracle.com> Message-ID: <46666df9-b107-ccd7-05d9-cdf1d1b0d2db@oracle.com> Thank you, David! Coleen On 4/12/17 3:26 AM, David Holmes wrote: > Hi Coleen, > > This all seems quite reasonable. It is good to see so much code deleted! > > Thanks, > David > > On 11/04/2017 7:12 AM, coleen.phillimore at oracle.com wrote: >> >> Hi, I've reopened this cleanup. To be clear, I didn't change which of >> classes_do are called except for two places in this change. >> >> One is print_method_profiling_data because it doesn't make sense for >> this not to print methods for anonymous classes and method handle >> intrinsics. See SystemDictionary::methods_do() implementation. I >> added hotspot-compiler-dev to this review so hopefully someone from the >> compiler group can verify this. >> >> The second is heapDumper.cpp because it seemed an obvious bug that if >> !ClassUnloading that all the classes shouldn't be dumped as STICKY >> classes. Tested with jvmti and heapdump tests. >> >> I've put this data you requested in the bug report as a comment. We >> could probably file about 4 more bugs to cleanup the calls sites for >> classes_do, so that the design is clearer, but I didn't want to do it >> all in this one change and mix it up with the functions that I found >> were unused and this change got large enough. >> >> New webrev: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8026985.03/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8026985 >> >> Thanks! >> Coleen >> >> On 3/14/17 10:43 AM, Karen Kinnear wrote: >>> Coleen, >>> >>> I am concerned about exposure of: >>> 1) not yet loaded classes >>> 2) scratch-classes >>> 3) classes that are not live due to JFR, parallel class loading or >>> load errors >>> >>> Could you please make us a table of those who walk the classes: >>> which classes they saw before >>> which classes they see now - and why the change is ok >>> what tests you have for each of the boxes in the table - both that >>> you see what you want, and that you do not see >>> what should not be exposed. >>> >>> My understanding is that this is intended to speed up GC but not to >>> change behaviors. >>> I am concerned about the exposure to non-GC walkers. >>> >>> thanks, >>> Karen >>> >>>> On Mar 13, 2017, at 8:30 PM, David Holmes >>>> wrote: >>>> >>>> Hi Coleen, >>>> >>>> On 11/03/2017 12:39 AM, coleen.phillimore at oracle.com >>>> wrote: >>>>> David, Thank you for reviewing. >>>>> >>>>> On 3/10/17 12:18 AM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 9/03/2017 2:24 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Clean up and examine uses of classes_do for the >>>>>>> SystemDictionary >>>>>>> >>>>>>> See bug comments for more details. I wanted to clean this up while >>>>>>> examining the idea of having system dictionary information added >>>>>>> per >>>>>>> ClassLoaderData, rather than a global table. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/8026985.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026985 >>>>>> The bulk of the deletion looks good! :) >>>>>> >>>>>> I guess my main query is how ClassLoaderDataGraph::classes_do / >>>>>> loaded_classes_do relate to SystemDictionary::classes_do? I would >>>>>> presume SD::classes_do can only act on loaded classes - by >>>>>> definition. >>>>>> So then it is unclear how you can replace it with either of the CLDG >>>>>> methods? >>>>> True, loaded_classes_do only walks loaded classes, which is probably >>>>> what we want most of the time. I was trying to figure this out >>>>> and the >>>>> differences which led to this change. I am trying to make it less >>>>> confusing. At least for me! >>>>> >>>>> The ClassLoaderData::classes_do includes anonymous, array and >>>>> allocated >>>>> classes. Most of the time we want the first two. For GC we want >>>>> the >>>>> last (because it has a mirror to walk). The SystemDictionary only >>>>> has >>>>> loaded InstanceKlasses, both with defined loader and initiating >>>>> loader. Except for one place in the code, we ignore the entries >>>>> with >>>>> initiating loader. >>>> I'm still very unclear as to why it is now okay to expand the set of >>>> klasses being walked at a given point. For example: >>>> >>>> src/share/vm/oops/klassVtable.cpp >>>> >>>> static void compute() { >>>> - SystemDictionary::classes_do(do_class); >>>> + ClassLoaderDataGraph::classes_do(do_class); >>>> >>>> IIUC SD::classes_do does not see anonymous classes, but >>>> CLDG::classes_do does. Why is this okay? >>>> >>>> You mentioned bugs like JDK-8024423 "missing anonymous classes" but >>>> my limited understanding of that bug suggests to me that the fix was >>>> to completely hide anonymous classes not to expose them! They should >>>> not be visible to JVM TI as I understand the intent of VM anonymous >>>> classes! >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> The only place where methods_do() is called for all the methods is >>>>> for >>>>> print_method_data_histogram and print_method_profiling_data. These >>>>> should only use loaded classes, so I've made the change below: >>>>> >>>>> void ClassLoaderData::methods_do(void f(Method*)) { >>>>> // Lock-free access requires load_ptr_acquire >>>>> for (Klass* k = load_ptr_acquire(&_klasses); k != NULL; k = >>>>> k->next_link()) { >>>>> if (k->is_instance_klass() && >>>>> InstanceKlass::cast(k)->is_loaded()) { >>>>> InstanceKlass::cast(k)->methods_do(f); >>>>> } >>>>> } >>>>> } >>>>>> It also seems a little odd to switch from SD to CLDG for classes_do, >>>>>> but go the other way, from CLDG to SD for methods_do ? I would >>>>>> expect/hope to have a single "entry point" for this kind of >>>>>> iteration. >>>>> I know. Unfortunately SD::methods_do includes the methods added for >>>>> MethodHandle intrinsics, which is owned by SystemDictionary. >>>>> >>>>> void SystemDictionary::methods_do(void f(Method*)) { >>>>> ClassLoaderDataGraph::methods_do(f); >>>>> invoke_method_table()->methods_do(f); >>>>> } >>>>> >>>>> I don't like this either. This invoke_method_table() really has >>>>> nothing to do with the Dictionary, it's just where it ended up. I >>>>> could >>>>> expand the change to find a better place for it. I don't know where >>>>> would be good though. >>>>> >>>>> Aside, I'd forgotten about invoke_method_table - it seems to be a >>>>> mechanism for isolated methods. >>>>> >>>>> Coleen >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Tested with java.lang.instrument, sun.com.jdi, tonga colocated >>>>>>> (closed) >>>>>>> tests, and JPRT, because of difference in which classes_do is >>>>>>> called for >>>>>>> heap dumping. >>>>>>> >>>>>>> Note, will update copyrights on commit. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >> From lutz.schmidt at sap.com Wed Apr 12 12:14:15 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 12 Apr 2017 12:14:15 +0000 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <1C84273B-2FA8-4B91-B412-0D2F815C13F2@sap.com> <9bc87d3e-a657-1e10-f688-e51e4e26645d@redhat.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> Message-ID: Hi Zoltan, First of all: thanks for trying to push! Second: sorry for the problems you ran into. I do not have an immediate explanation for the failure ? my dev machine is MacOS/x86_64. I will try to reproduce immediately. For the time being: is there any log output that could shed some light on the issue? Thanks, Lutz On 12.04.2017, 13:10, "hotspot-compiler-dev on behalf of Zolt?n Maj?" wrote: P.S.: Forgot to mention: The problem does not appear on any other x86_64 platform. On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > Hi Volker, > Hi Lutz, > > > yesterday I tried to push webrev.03 using JPRT. Unfortunately, the > TestCRC32C.java test you've modified fails on Mac OS X on x86_64. Do > you have an idea why that could be? > > Thank you! Best regards, > > > Zoltan > > On 04/11/2017 06:03 PM, Volker Simonis wrote: >> Thanks a lot Zoltan! >> >> >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? > > wrote: >> >> Hi Volker, >> >> >> On 04/11/2017 03:34 PM, Volker Simonis wrote: >> >> >> Hi Zoltan, >> >> could you please be so kind to sponsor this reviewed change >> for jdk10? >> >> >> yes, of course. I'll push it today. >> >> Best regards, >> >> >> Zoltan >> >> Initially we wanted to push it ourselves because it was s390x >> only but now that we've also touched the tests we need a >> sponsor. >> >> Thank you and best regards, >> Volker >> >> ---------- Forwarded message ---------- >> From: *Volker Simonis* > >> > >> >> Date: Fri, Mar 31, 2017 at 10:53 AM >> Subject: Re: RFR (S) 8176580: [ppc, s390] CRC32C: wrong >> checksum result in some cases >> To: "Schmidt, Lutz" > > >> >> Cc: Andrew Haley >> >>, >> "hotspot-compiler-dev at openjdk.java.net >> >> > >" >> > >> > >> >> >> >> Ping... >> >> Can somebody please push this change? >> >> It's ppc64/s390x only but as a courtesy to the community it >> also fixes >> the CRC JTreg tests so unfortunately I still can't push it >> myself :) >> >> Thank you and best regards, >> Volker >> >> >> On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis >> >> > >> wrote: >> > Hi Lutz, >> > >> > thanks a lot for fixing the test! >> > Your change looks good now. >> > >> > Because this touches shared (i.e. test) files, we still need >> a sponsor >> > so can somebody please sponsor this change? >> > >> > Thank you and best regards, >> > Volker >> > >> > >> > >> > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz >> >> >> >> wrote: >> >> Hi Volker, >> >> >> >> Sorry for letting you wait. Here is the final(?) webrev, >> containing all your requests for cleanup and improvements: >> >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ >> >> > > >> >> >> >> As before, the *.cpp files have not been modified. >> >> >> >> Best Regards, >> >> Lutz >> >> >> >> >> >> >> >> On 21/03/2017, 17:55, "Volker Simonis" >> >> > >> wrote: >> >> >> >> Hi Lutz, >> >> >> >> thanks a lot for updating the tests. I think they look >> much better now. >> >> >> >> There's just one more cleanup I'd like to propose. Can >> you please move >> >> the throw right into the check() function. Just make >> check() return >> >> void and throw from it if there's a mismatch between >> the computed and >> >> the expected result. I leave it up to you if you want >> to pass an extra >> >> error string to check() which will be printed in the >> case of an error. >> >> I personally don't think that's necessary as it will be >> evident from >> >> the stack trace which computation failed. >> >> >> >> Also the try/catch and rethrow in test_multi() isn't >> necessary. The >> >> test can be simply terminated by the initial exception. >> >> >> >> Thank you and best regards, >> >> Volker >> >> >> >> >> >> On Fri, Mar 17, 2017 at 10:03 PM, Schmidt, Lutz >> >> >> >> wrote: >> >> > Hi Volker, >> >> > >> >> > Thanks a lot for your valuable hints. >> >> > >> >> > I have worked some time on the Java test files: >> >> > TestCRC32.java and TestCRC32C.java are now >> identical as far as possible. >> >> > They now throw an exception, should any error be >> detected. >> >> > The ?reference CRC value? is now used in >> test_multi() as well. >> >> > The extra test runs have been removed again. >> >> > The test methodology is fixed: each result is >> tested against its reference. >> >> > The tests now detect the bug introduced with >> 8175368 and 8175369. >> >> > No issue is indicated when testing with 8176580. >> >> > I ran jcheck, and to the best of my ability and >> knowledge, there is no trailing whitespace. >> >> > All *.cpp files were left untouched! >> >> > >> >> > The next iteration of the webrev: >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ >> >> > > >> >> > >> >> > Best regards, >> >> > Lutz >> >> > >> >> > >> >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 >> (6227) 7-42834 >> >> >> > >> >> > >> >> > >> >> > On 16.03.17, 11:28, "Volker Simonis" >> >> > >> wrote: >> >> > >> >> > On Wed, Mar 15, 2017 at 5:55 PM, Schmidt, Lutz >> >> >> >> wrote: >> >> > > >> >> > > Hi Andrew, Volker, >> >> > > >> >> > > What do you think about these test enhancements? >> >> > > Webrev: >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ >> >> > > >> >> >> > > >> >> > > Please note: the cpp files in the webrev >> remained unchanged. >> >> > > >> >> > > I added some improvements (as I believe) to the >> TestCRC32(C).java files. >> >> > > >> >> > > In some more detail: >> >> > > The test now calculates a ?reference CRC >> value?, based on a java implementation of the CRC32 algorithm. >> This reference value is used to verify all other crc values, >> in particular during initialization and warmup. Three >> additional test runs check a non-zero offset with ?Xint, >> -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp >> -XX:+TieredCompilation (C1 + C2). >> >> > > >> >> > >> >> > Hi Lutz, >> >> > >> >> > thanks for updating the tests. I've had a closer >> look at the tests and >> >> > realized that they actually can never fail! The >> check() routine just >> >> > prints an error message but that will not let the >> test fail. So I >> >> > would suggest to throw a runtime exception in the >> check() routine >> >> > after the error message was printed. >> >> > >> >> > I also suggest to do the check during the normal >> test execution (i.e. >> >> > in test_multi()) so there's no need for extra >> test runs. >> >> > >> >> > Finally, the current test methodology in >> test_multi() is broken: >> >> > - it sets the reference by calling CRC from the >> interpreter which >> >> > won't work if the intrinsic is also used in the >> interpreter. >> >> > - it only compares the reference against the >> last computation of CRC >> >> > in the loop which will be the result of the C2 >> generated code. This >> >> > misses errors in C1. >> >> > >> >> > I suggest to use your new, pure Java >> implementation for the >> >> > computation of the reference result and compare >> the reference with the >> >> > result of calling CRC in every iteration of the >> loop so we really >> >> > check all possibilities from interpreter trough >> C1 to C2. >> >> > >> >> > Finally, can you please pay attention to not >> insert trailing >> >> > whitespace (there was some at line 88 in >> TestCRC32C.java). You can >> >> > easily verify this by running jcheck before >> creating the webrevs. >> >> > >> >> > Thanks, >> >> > Volker >> >> > >> >> > > >> >> > > Best regards, >> >> > > Lutz >> >> > > >> >> > > >> >> > > On 15.03.17, 11:50, "Volker Simonis" >> >> > >> wrote: >> >> > > >> >> > > On Tue, Mar 14, 2017 at 7:05 PM, Andrew >> Haley >> >> wrote: >> >> > > > On 14/03/17 13:12, Schmidt, Lutz wrote: >> >> > > > >> >> > > >> Yes, one might think of running a test >> suite subset multiple times >> >> > > >> with different parameters. In this case, >> -Xint and/or ?Xcomp were >> >> > > >> helpful. Forcing tests to run fully >> interpreted or fully compiled >> >> > > >> helps in cases where a certain function, >> e.g. an intrinsic, is >> >> > > >> invoked via distinct code paths. >> >> > > > >> >> > > > Right, so your patch should include that >> change to the test suite. >> >> > > > >> >> > > >> >> > > Hi Lutz, >> >> > > >> >> > > I agree with Andrew. We should really fix >> the tests such that they >> >> > > check the correctness of the intrinsics. >> >> > > >> >> > > This may be tricky if all three, the >> interpreter, the client and the >> >> > > server compiler use the same intrinsic >> implementation. You could >> >> > > either copy the pure Java implementation >> into the test so that you can >> >> > > compare the results of the intrinsic >> operation against it or you can >> >> > > switch them off in the compilers with >> >> > > "-XX:DisableIntrinsic=_updateBytesCRC32C >> >> > > >> -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and >> compare the >> >> > > results. Not sure which solution is more >> practical, but I would be >> >> > > really scared if we wouldn't have these test. >> >> > > >> >> > > Regards, >> >> > > Volker >> >> > > >> >> > > > Andrew. >> >> > > > >> >> > > >> >> > > >> >> > >> >> > >> >> >> >> >> >> >> > From zoltan.majo at oracle.com Wed Apr 12 12:38:17 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 12 Apr 2017 14:38:17 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <1C84273B-2FA8-4B91-B412-0D2F815C13F2@sap.com> <9bc87d3e-a657-1e10-f688-e51e4e26645d@redhat.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> Message-ID: <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> Hi Lutz, On 04/12/2017 02:14 PM, Schmidt, Lutz wrote: > Hi Zoltan, > > First of all: thanks for trying to push! Second: sorry for the problems you ran into. you are welcome and no problem, of course. > I do not have an immediate explanation for the failure ? my dev machine is MacOS/x86_64. I will try to reproduce immediately. For the time being: is there any log output that could shed some light on the issue? Please find the output below (and sorry for not including it before). Please let me know if you were able to reproduce the problem (or not). Best regards, Zoltan command: main -Xbatch compiler.intrinsics.zip.TestCRC32C -m reason: User specified action: run main/othervm/timeout=600 -Xbatch compiler.intrinsics.zip.TestCRC32C -m Mode: othervm [/othervm specified] elapsed time (seconds): 1.915 configuration: STDOUT: testing 1050 cases ... STDERR: ERROR: crc = 6f894393, crcReference = 2cdf6e8f java.lang.Exception: TestCRC32C Error at compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218) at compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280) at compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:563) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) JavaTest Message: Test threw exception: java.lang.Exception: TestCRC32C Error JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.Exception: TestCRC32C Error > > Thanks, > Lutz > > > On 12.04.2017, 13:10, "hotspot-compiler-dev on behalf of Zolt?n Maj?" wrote: > > P.S.: Forgot to mention: The problem does not appear on any other x86_64 > platform. > > On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > > Hi Volker, > > Hi Lutz, > > > > > > yesterday I tried to push webrev.03 using JPRT. Unfortunately, the > > TestCRC32C.java test you've modified fails on Mac OS X on x86_64. Do > > you have an idea why that could be? > > > > Thank you! Best regards, > > > > > > Zoltan > > > > On 04/11/2017 06:03 PM, Volker Simonis wrote: > >> Thanks a lot Zoltan! > >> > >> > >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? >> > wrote: > >> > >> Hi Volker, > >> > >> > >> On 04/11/2017 03:34 PM, Volker Simonis wrote: > >> > >> > >> Hi Zoltan, > >> > >> could you please be so kind to sponsor this reviewed change > >> for jdk10? > >> > >> > >> yes, of course. I'll push it today. > >> > >> Best regards, > >> > >> > >> Zoltan > >> > >> Initially we wanted to push it ourselves because it was s390x > >> only but now that we've also touched the tests we need a > >> sponsor. > >> > >> Thank you and best regards, > >> Volker > >> > >> ---------- Forwarded message ---------- > >> From: *Volker Simonis* >> > >> >> >> > >> Date: Fri, Mar 31, 2017 at 10:53 AM > >> Subject: Re: RFR (S) 8176580: [ppc, s390] CRC32C: wrong > >> checksum result in some cases > >> To: "Schmidt, Lutz" >> >> >> > >> Cc: Andrew Haley > >> >>, > >> "hotspot-compiler-dev at openjdk.java.net > >> > >> >> >" > >> >> > >> >> >> > >> > >> > >> Ping... > >> > >> Can somebody please push this change? > >> > >> It's ppc64/s390x only but as a courtesy to the community it > >> also fixes > >> the CRC JTreg tests so unfortunately I still can't push it > >> myself :) > >> > >> Thank you and best regards, > >> Volker > >> > >> > >> On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis > >> > >> >> >> wrote: > >> > Hi Lutz, > >> > > >> > thanks a lot for fixing the test! > >> > Your change looks good now. > >> > > >> > Because this touches shared (i.e. test) files, we still need > >> a sponsor > >> > so can somebody please sponsor this change? > >> > > >> > Thank you and best regards, > >> > Volker > >> > > >> > > >> > > >> > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz > >> > >> >> > >> wrote: > >> >> Hi Volker, > >> >> > >> >> Sorry for letting you wait. Here is the final(?) webrev, > >> containing all your requests for cleanup and improvements: > >> >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ > >> > >> >> > > >> >> > >> >> As before, the *.cpp files have not been modified. > >> >> > >> >> Best Regards, > >> >> Lutz > >> >> > >> >> > >> >> > >> >> On 21/03/2017, 17:55, "Volker Simonis" > >> > >> >> >> wrote: > >> >> > >> >> Hi Lutz, > >> >> > >> >> thanks a lot for updating the tests. I think they look > >> much better now. > >> >> > >> >> There's just one more cleanup I'd like to propose. Can > >> you please move > >> >> the throw right into the check() function. Just make > >> check() return > >> >> void and throw from it if there's a mismatch between > >> the computed and > >> >> the expected result. I leave it up to you if you want > >> to pass an extra > >> >> error string to check() which will be printed in the > >> case of an error. > >> >> I personally don't think that's necessary as it will be > >> evident from > >> >> the stack trace which computation failed. > >> >> > >> >> Also the try/catch and rethrow in test_multi() isn't > >> necessary. The > >> >> test can be simply terminated by the initial exception. > >> >> > >> >> Thank you and best regards, > >> >> Volker > >> >> > >> >> > >> >> On Fri, Mar 17, 2017 at 10:03 PM, Schmidt, Lutz > >> > >> >> > >> wrote: > >> >> > Hi Volker, > >> >> > > >> >> > Thanks a lot for your valuable hints. > >> >> > > >> >> > I have worked some time on the Java test files: > >> >> > TestCRC32.java and TestCRC32C.java are now > >> identical as far as possible. > >> >> > They now throw an exception, should any error be > >> detected. > >> >> > The ?reference CRC value? is now used in > >> test_multi() as well. > >> >> > The extra test runs have been removed again. > >> >> > The test methodology is fixed: each result is > >> tested against its reference. > >> >> > The tests now detect the bug introduced with > >> 8175368 and 8175369. > >> >> > No issue is indicated when testing with 8176580. > >> >> > I ran jcheck, and to the best of my ability and > >> knowledge, there is no trailing whitespace. > >> >> > All *.cpp files were left untouched! > >> >> > > >> >> > The next iteration of the webrev: > >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ > >> > >> >> > > >> >> > > >> >> > Best regards, > >> >> > Lutz > >> >> > > >> >> > > >> >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 > >> (6227) 7-42834 > >> > >> >> > > >> >> > > >> >> > > >> >> > On 16.03.17, 11:28, "Volker Simonis" > >> > >> >> >> wrote: > >> >> > > >> >> > On Wed, Mar 15, 2017 at 5:55 PM, Schmidt, Lutz > >> > >> >> > >> wrote: > >> >> > > > >> >> > > Hi Andrew, Volker, > >> >> > > > >> >> > > What do you think about these test enhancements? > >> >> > > Webrev: > >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ > >> > >> >> > > >> > >> >> > > > >> >> > > Please note: the cpp files in the webrev > >> remained unchanged. > >> >> > > > >> >> > > I added some improvements (as I believe) to the > >> TestCRC32(C).java files. > >> >> > > > >> >> > > In some more detail: > >> >> > > The test now calculates a ?reference CRC > >> value?, based on a java implementation of the CRC32 algorithm. > >> This reference value is used to verify all other crc values, > >> in particular during initialization and warmup. Three > >> additional test runs check a non-zero offset with ?Xint, > >> -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp > >> -XX:+TieredCompilation (C1 + C2). > >> >> > > > >> >> > > >> >> > Hi Lutz, > >> >> > > >> >> > thanks for updating the tests. I've had a closer > >> look at the tests and > >> >> > realized that they actually can never fail! The > >> check() routine just > >> >> > prints an error message but that will not let the > >> test fail. So I > >> >> > would suggest to throw a runtime exception in the > >> check() routine > >> >> > after the error message was printed. > >> >> > > >> >> > I also suggest to do the check during the normal > >> test execution (i.e. > >> >> > in test_multi()) so there's no need for extra > >> test runs. > >> >> > > >> >> > Finally, the current test methodology in > >> test_multi() is broken: > >> >> > - it sets the reference by calling CRC from the > >> interpreter which > >> >> > won't work if the intrinsic is also used in the > >> interpreter. > >> >> > - it only compares the reference against the > >> last computation of CRC > >> >> > in the loop which will be the result of the C2 > >> generated code. This > >> >> > misses errors in C1. > >> >> > > >> >> > I suggest to use your new, pure Java > >> implementation for the > >> >> > computation of the reference result and compare > >> the reference with the > >> >> > result of calling CRC in every iteration of the > >> loop so we really > >> >> > check all possibilities from interpreter trough > >> C1 to C2. > >> >> > > >> >> > Finally, can you please pay attention to not > >> insert trailing > >> >> > whitespace (there was some at line 88 in > >> TestCRC32C.java). You can > >> >> > easily verify this by running jcheck before > >> creating the webrevs. > >> >> > > >> >> > Thanks, > >> >> > Volker > >> >> > > >> >> > > > >> >> > > Best regards, > >> >> > > Lutz > >> >> > > > >> >> > > > >> >> > > On 15.03.17, 11:50, "Volker Simonis" > >> > >> >> >> wrote: > >> >> > > > >> >> > > On Tue, Mar 14, 2017 at 7:05 PM, Andrew > >> Haley > >> >> wrote: > >> >> > > > On 14/03/17 13:12, Schmidt, Lutz wrote: > >> >> > > > > >> >> > > >> Yes, one might think of running a test > >> suite subset multiple times > >> >> > > >> with different parameters. In this case, > >> -Xint and/or ?Xcomp were > >> >> > > >> helpful. Forcing tests to run fully > >> interpreted or fully compiled > >> >> > > >> helps in cases where a certain function, > >> e.g. an intrinsic, is > >> >> > > >> invoked via distinct code paths. > >> >> > > > > >> >> > > > Right, so your patch should include that > >> change to the test suite. > >> >> > > > > >> >> > > > >> >> > > Hi Lutz, > >> >> > > > >> >> > > I agree with Andrew. We should really fix > >> the tests such that they > >> >> > > check the correctness of the intrinsics. > >> >> > > > >> >> > > This may be tricky if all three, the > >> interpreter, the client and the > >> >> > > server compiler use the same intrinsic > >> implementation. You could > >> >> > > either copy the pure Java implementation > >> into the test so that you can > >> >> > > compare the results of the intrinsic > >> operation against it or you can > >> >> > > switch them off in the compilers with > >> >> > > "-XX:DisableIntrinsic=_updateBytesCRC32C > >> >> > > > >> -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and > >> compare the > >> >> > > results. Not sure which solution is more > >> practical, but I would be > >> >> > > really scared if we wouldn't have these test. > >> >> > > > >> >> > > Regards, > >> >> > > Volker > >> >> > > > >> >> > > > Andrew. > >> >> > > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > >> >> > >> > >> > >> > > > > > From lutz.schmidt at sap.com Wed Apr 12 16:36:53 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 12 Apr 2017 16:36:53 +0000 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <1C84273B-2FA8-4B91-B412-0D2F815C13F2@sap.com> <9bc87d3e-a657-1e10-f688-e51e4e26645d@redhat.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> Message-ID: Hi Zoltan, I?m not able to reproduce the problem as of now. I will try out other (older) x86 machines tomorrow. Could be a problem in fallback code when required vector instructions are not available. Can you please find out on what H/W (CPU in particular) the tests are failing? Thanks, Lutz On 12.04.2017, 14:38, "Zolt?n Maj?" wrote: Hi Lutz, On 04/12/2017 02:14 PM, Schmidt, Lutz wrote: > Hi Zoltan, > > First of all: thanks for trying to push! Second: sorry for the problems you ran into. you are welcome and no problem, of course. > I do not have an immediate explanation for the failure ? my dev machine is MacOS/x86_64. I will try to reproduce immediately. For the time being: is there any log output that could shed some light on the issue? Please find the output below (and sorry for not including it before). Please let me know if you were able to reproduce the problem (or not). Best regards, Zoltan command: main -Xbatch compiler.intrinsics.zip.TestCRC32C -m reason: User specified action: run main/othervm/timeout=600 -Xbatch compiler.intrinsics.zip.TestCRC32C -m Mode: othervm [/othervm specified] elapsed time (seconds): 1.915 configuration: STDOUT: testing 1050 cases ... STDERR: ERROR: crc = 6f894393, crcReference = 2cdf6e8f java.lang.Exception: TestCRC32C Error at compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218) at compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280) at compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:563) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) JavaTest Message: Test threw exception: java.lang.Exception: TestCRC32C Error JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.Exception: TestCRC32C Error > > Thanks, > Lutz > > > On 12.04.2017, 13:10, "hotspot-compiler-dev on behalf of Zolt?n Maj?" wrote: > > P.S.: Forgot to mention: The problem does not appear on any other x86_64 > platform. > > On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > > Hi Volker, > > Hi Lutz, > > > > > > yesterday I tried to push webrev.03 using JPRT. Unfortunately, the > > TestCRC32C.java test you've modified fails on Mac OS X on x86_64. Do > > you have an idea why that could be? > > > > Thank you! Best regards, > > > > > > Zoltan > > > > On 04/11/2017 06:03 PM, Volker Simonis wrote: > >> Thanks a lot Zoltan! > >> > >> > >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? >> > wrote: > >> > >> Hi Volker, > >> > >> > >> On 04/11/2017 03:34 PM, Volker Simonis wrote: > >> > >> > >> Hi Zoltan, > >> > >> could you please be so kind to sponsor this reviewed change > >> for jdk10? > >> > >> > >> yes, of course. I'll push it today. > >> > >> Best regards, > >> > >> > >> Zoltan > >> > >> Initially we wanted to push it ourselves because it was s390x > >> only but now that we've also touched the tests we need a > >> sponsor. > >> > >> Thank you and best regards, > >> Volker > >> > >> ---------- Forwarded message ---------- > >> From: *Volker Simonis* >> > >> >> >> > >> Date: Fri, Mar 31, 2017 at 10:53 AM > >> Subject: Re: RFR (S) 8176580: [ppc, s390] CRC32C: wrong > >> checksum result in some cases > >> To: "Schmidt, Lutz" >> >> >> > >> Cc: Andrew Haley > >> >>, > >> "hotspot-compiler-dev at openjdk.java.net > >> > >> >> >" > >> >> > >> >> >> > >> > >> > >> Ping... > >> > >> Can somebody please push this change? > >> > >> It's ppc64/s390x only but as a courtesy to the community it > >> also fixes > >> the CRC JTreg tests so unfortunately I still can't push it > >> myself :) > >> > >> Thank you and best regards, > >> Volker > >> > >> > >> On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis > >> > >> >> >> wrote: > >> > Hi Lutz, > >> > > >> > thanks a lot for fixing the test! > >> > Your change looks good now. > >> > > >> > Because this touches shared (i.e. test) files, we still need > >> a sponsor > >> > so can somebody please sponsor this change? > >> > > >> > Thank you and best regards, > >> > Volker > >> > > >> > > >> > > >> > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz > >> > >> >> > >> wrote: > >> >> Hi Volker, > >> >> > >> >> Sorry for letting you wait. Here is the final(?) webrev, > >> containing all your requests for cleanup and improvements: > >> >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ > >> > >> >> > > >> >> > >> >> As before, the *.cpp files have not been modified. > >> >> > >> >> Best Regards, > >> >> Lutz > >> >> > >> >> > >> >> > >> >> On 21/03/2017, 17:55, "Volker Simonis" > >> > >> >> >> wrote: > >> >> > >> >> Hi Lutz, > >> >> > >> >> thanks a lot for updating the tests. I think they look > >> much better now. > >> >> > >> >> There's just one more cleanup I'd like to propose. Can > >> you please move > >> >> the throw right into the check() function. Just make > >> check() return > >> >> void and throw from it if there's a mismatch between > >> the computed and > >> >> the expected result. I leave it up to you if you want > >> to pass an extra > >> >> error string to check() which will be printed in the > >> case of an error. > >> >> I personally don't think that's necessary as it will be > >> evident from > >> >> the stack trace which computation failed. > >> >> > >> >> Also the try/catch and rethrow in test_multi() isn't > >> necessary. The > >> >> test can be simply terminated by the initial exception. > >> >> > >> >> Thank you and best regards, > >> >> Volker > >> >> > >> >> > >> >> On Fri, Mar 17, 2017 at 10:03 PM, Schmidt, Lutz > >> > >> >> > >> wrote: > >> >> > Hi Volker, > >> >> > > >> >> > Thanks a lot for your valuable hints. > >> >> > > >> >> > I have worked some time on the Java test files: > >> >> > TestCRC32.java and TestCRC32C.java are now > >> identical as far as possible. > >> >> > They now throw an exception, should any error be > >> detected. > >> >> > The ?reference CRC value? is now used in > >> test_multi() as well. > >> >> > The extra test runs have been removed again. > >> >> > The test methodology is fixed: each result is > >> tested against its reference. > >> >> > The tests now detect the bug introduced with > >> 8175368 and 8175369. > >> >> > No issue is indicated when testing with 8176580. > >> >> > I ran jcheck, and to the best of my ability and > >> knowledge, there is no trailing whitespace. > >> >> > All *.cpp files were left untouched! > >> >> > > >> >> > The next iteration of the webrev: > >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ > >> > >> >> > > >> >> > > >> >> > Best regards, > >> >> > Lutz > >> >> > > >> >> > > >> >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 > >> (6227) 7-42834 > >> > >> >> > > >> >> > > >> >> > > >> >> > On 16.03.17, 11:28, "Volker Simonis" > >> > >> >> >> wrote: > >> >> > > >> >> > On Wed, Mar 15, 2017 at 5:55 PM, Schmidt, Lutz > >> > >> >> > >> wrote: > >> >> > > > >> >> > > Hi Andrew, Volker, > >> >> > > > >> >> > > What do you think about these test enhancements? > >> >> > > Webrev: > >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ > >> > >> >> > > >> > >> >> > > > >> >> > > Please note: the cpp files in the webrev > >> remained unchanged. > >> >> > > > >> >> > > I added some improvements (as I believe) to the > >> TestCRC32(C).java files. > >> >> > > > >> >> > > In some more detail: > >> >> > > The test now calculates a ?reference CRC > >> value?, based on a java implementation of the CRC32 algorithm. > >> This reference value is used to verify all other crc values, > >> in particular during initialization and warmup. Three > >> additional test runs check a non-zero offset with ?Xint, > >> -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp > >> -XX:+TieredCompilation (C1 + C2). > >> >> > > > >> >> > > >> >> > Hi Lutz, > >> >> > > >> >> > thanks for updating the tests. I've had a closer > >> look at the tests and > >> >> > realized that they actually can never fail! The > >> check() routine just > >> >> > prints an error message but that will not let the > >> test fail. So I > >> >> > would suggest to throw a runtime exception in the > >> check() routine > >> >> > after the error message was printed. > >> >> > > >> >> > I also suggest to do the check during the normal > >> test execution (i.e. > >> >> > in test_multi()) so there's no need for extra > >> test runs. > >> >> > > >> >> > Finally, the current test methodology in > >> test_multi() is broken: > >> >> > - it sets the reference by calling CRC from the > >> interpreter which > >> >> > won't work if the intrinsic is also used in the > >> interpreter. > >> >> > - it only compares the reference against the > >> last computation of CRC > >> >> > in the loop which will be the result of the C2 > >> generated code. This > >> >> > misses errors in C1. > >> >> > > >> >> > I suggest to use your new, pure Java > >> implementation for the > >> >> > computation of the reference result and compare > >> the reference with the > >> >> > result of calling CRC in every iteration of the > >> loop so we really > >> >> > check all possibilities from interpreter trough > >> C1 to C2. > >> >> > > >> >> > Finally, can you please pay attention to not > >> insert trailing > >> >> > whitespace (there was some at line 88 in > >> TestCRC32C.java). You can > >> >> > easily verify this by running jcheck before > >> creating the webrevs. > >> >> > > >> >> > Thanks, > >> >> > Volker > >> >> > > >> >> > > > >> >> > > Best regards, > >> >> > > Lutz > >> >> > > > >> >> > > > >> >> > > On 15.03.17, 11:50, "Volker Simonis" > >> > >> >> >> wrote: > >> >> > > > >> >> > > On Tue, Mar 14, 2017 at 7:05 PM, Andrew > >> Haley > >> >> wrote: > >> >> > > > On 14/03/17 13:12, Schmidt, Lutz wrote: > >> >> > > > > >> >> > > >> Yes, one might think of running a test > >> suite subset multiple times > >> >> > > >> with different parameters. In this case, > >> -Xint and/or ?Xcomp were > >> >> > > >> helpful. Forcing tests to run fully > >> interpreted or fully compiled > >> >> > > >> helps in cases where a certain function, > >> e.g. an intrinsic, is > >> >> > > >> invoked via distinct code paths. > >> >> > > > > >> >> > > > Right, so your patch should include that > >> change to the test suite. > >> >> > > > > >> >> > > > >> >> > > Hi Lutz, > >> >> > > > >> >> > > I agree with Andrew. We should really fix > >> the tests such that they > >> >> > > check the correctness of the intrinsics. > >> >> > > > >> >> > > This may be tricky if all three, the > >> interpreter, the client and the > >> >> > > server compiler use the same intrinsic > >> implementation. You could > >> >> > > either copy the pure Java implementation > >> into the test so that you can > >> >> > > compare the results of the intrinsic > >> operation against it or you can > >> >> > > switch them off in the compilers with > >> >> > > "-XX:DisableIntrinsic=_updateBytesCRC32C > >> >> > > > >> -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and > >> compare the > >> >> > > results. Not sure which solution is more > >> practical, but I would be > >> >> > > really scared if we wouldn't have these test. > >> >> > > > >> >> > > Regards, > >> >> > > Volker > >> >> > > > >> >> > > > Andrew. > >> >> > > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > >> >> > >> > >> > >> > > > > > From igor.ignatyev at oracle.com Wed Apr 12 19:03:15 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Apr 2017 12:03:15 -0700 Subject: RFR(S): 8164944: Refactor ProcessTools to get rid of dependency on java.management Message-ID: <9054D440-C6C9-4D97-AEB9-25CD3057564F@oracle.com> http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html > 92 lines changed: 36 ins; 36 del; 20 mod; Hi all, could you please review this small fix which removes dependency on java.management module from the testlibrary? jdk.test.lib.process.ProcessTools class has getVmInputArgs method which depend on java.management, this method is used only by j.d.t.process.ProcessTools::executeTestJvmAll and j.t.l.cli.CommandLineOptionTest class. - ProcessTools::executeTestJvmAll is a variation of executeTestJvm which prepends vm flags from jtreg @run. - CommandLineOptionTest is a library class for cli testing, it uses flags from ProcessTools::getVmInputArgs to create a new jvm with all flags the fix removes ProcessTools::executeTestJvmAll method, moves getVmInputArgs to a separate class jdk.test.lib.management.InputArguments. c.c.s.scenario.Executor and j.t.l.cli.CommandLineOptionTest are updated to use getVmInputArgs from that class. c.j.compilerToVM.DebugOutputTest is refactored to pass add-exports and patch module directly. all the affected classes and obviously updated to use executeTestJvm instead of executeTestJvmAll. after this fix many hotspot tests won't depend on java.management, hence that module might be removed from their @modules, this will be done separately by 8178416. jbs: https://bugs.openjdk.java.net/browse/JDK-8164944 webrev: http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html testing: :hotspot_all 8178416: https://bugs.openjdk.java.net/browse/JDK-8178416 Thanks, -- Igor From igor.ignatyev at oracle.com Wed Apr 12 19:14:20 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Apr 2017 12:14:20 -0700 Subject: RFR(S): 8164944: Refactor ProcessTools to get rid of dependency on java.management In-Reply-To: <9054D440-C6C9-4D97-AEB9-25CD3057564F@oracle.com> References: <9054D440-C6C9-4D97-AEB9-25CD3057564F@oracle.com> Message-ID: <5548AED8-2BEB-4341-88F9-B34C0F827BAD@oracle.com> forgot to update copyrights, http://cr.openjdk.java.net/~iignatyev//8164944/webrev.01/index.html > On Apr 12, 2017, at 12:03 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html >> 92 lines changed: 36 ins; 36 del; 20 mod; > > Hi all, > > could you please review this small fix which removes dependency on java.management module from the testlibrary? > > jdk.test.lib.process.ProcessTools class has getVmInputArgs method which depend on java.management, this method is used only by j.d.t.process.ProcessTools::executeTestJvmAll and j.t.l.cli.CommandLineOptionTest class. > - ProcessTools::executeTestJvmAll is a variation of executeTestJvm which prepends vm flags from jtreg @run. > - CommandLineOptionTest is a library class for cli testing, it uses flags from ProcessTools::getVmInputArgs to create a new jvm with all flags > > the fix removes ProcessTools::executeTestJvmAll method, moves getVmInputArgs to a separate class jdk.test.lib.management.InputArguments. c.c.s.scenario.Executor and j.t.l.cli.CommandLineOptionTest are updated to use getVmInputArgs from that class. c.j.compilerToVM.DebugOutputTest is refactored to pass add-exports and patch module directly. all the affected classes and obviously updated to use executeTestJvm instead of executeTestJvmAll. > > after this fix many hotspot tests won't depend on java.management, hence that module might be removed from their @modules, this will be done separately by 8178416. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8164944 > webrev: http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html > testing: :hotspot_all > 8178416: https://bugs.openjdk.java.net/browse/JDK-8178416 > > Thanks, > -- Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Apr 12 19:42:22 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Apr 2017 12:42:22 -0700 Subject: RFR(S): 8164944: Refactor ProcessTools to get rid of dependency on java.management In-Reply-To: <9054D440-C6C9-4D97-AEB9-25CD3057564F@oracle.com> References: <9054D440-C6C9-4D97-AEB9-25CD3057564F@oracle.com> Message-ID: <0c11c59a-3c05-fb5f-36e3-579cd39c0f6d@oracle.com> Looks fine to me. Vladimir On 4/12/17 12:03 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html >> 92 lines changed: 36 ins; 36 del; 20 mod; > > Hi all, > > could you please review this small fix which removes dependency on java.management module from the testlibrary? > > jdk.test.lib.process.ProcessTools class has getVmInputArgs method which depend on java.management, this method is used only by j.d.t.process.ProcessTools::executeTestJvmAll and j.t.l.cli.CommandLineOptionTest class. > - ProcessTools::executeTestJvmAll is a variation of executeTestJvm which prepends vm flags from jtreg @run. > - CommandLineOptionTest is a library class for cli testing, it uses flags from ProcessTools::getVmInputArgs to create a new jvm with all flags > > the fix removes ProcessTools::executeTestJvmAll method, moves getVmInputArgs to a separate class jdk.test.lib.management.InputArguments. c.c.s.scenario.Executor and j.t.l.cli.CommandLineOptionTest are updated to use getVmInputArgs from that class. c.j.compilerToVM.DebugOutputTest is refactored to pass add-exports and patch module directly. all the affected classes and obviously updated to use executeTestJvm instead of executeTestJvmAll. > > after this fix many hotspot tests won't depend on java.management, hence that module might be removed from their @modules, this will be done separately by 8178416. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8164944 > webrev: http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html > testing: :hotspot_all > 8178416: https://bugs.openjdk.java.net/browse/JDK-8178416 > > Thanks, > -- Igor > From dmitry.fazunenko at oracle.com Wed Apr 12 20:36:17 2017 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 12 Apr 2017 23:36:17 +0300 Subject: RFR(S): 8164944: Refactor ProcessTools to get rid of dependency on java.management In-Reply-To: <5548AED8-2BEB-4341-88F9-B34C0F827BAD@oracle.com> References: <9054D440-C6C9-4D97-AEB9-25CD3057564F@oracle.com> <5548AED8-2BEB-4341-88F9-B34C0F827BAD@oracle.com> Message-ID: <296e94e5-1ee4-3d9b-d7ff-d1103c43a916@oracle.com> Hi Igor, On 12.04.2017 22:14, Igor Ignatyev wrote: > forgot to update copyrights, http://cr.openjdk.java.net/~iignatyev//8164944/webrev.01/index.html It's become much better :) Now the fix looks perfect to me. Thanks for making this change! Thanks, Dima > >> On Apr 12, 2017, at 12:03 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html >>> 92 lines changed: 36 ins; 36 del; 20 mod; >> Hi all, >> >> could you please review this small fix which removes dependency on java.management module from the testlibrary? >> >> jdk.test.lib.process.ProcessTools class has getVmInputArgs method which depend on java.management, this method is used only by j.d.t.process.ProcessTools::executeTestJvmAll and j.t.l.cli.CommandLineOptionTest class. >> - ProcessTools::executeTestJvmAll is a variation of executeTestJvm which prepends vm flags from jtreg @run. >> - CommandLineOptionTest is a library class for cli testing, it uses flags from ProcessTools::getVmInputArgs to create a new jvm with all flags >> >> the fix removes ProcessTools::executeTestJvmAll method, moves getVmInputArgs to a separate class jdk.test.lib.management.InputArguments. c.c.s.scenario.Executor and j.t.l.cli.CommandLineOptionTest are updated to use getVmInputArgs from that class. c.j.compilerToVM.DebugOutputTest is refactored to pass add-exports and patch module directly. all the affected classes and obviously updated to use executeTestJvm instead of executeTestJvmAll. >> >> after this fix many hotspot tests won't depend on java.management, hence that module might be removed from their @modules, this will be done separately by 8178416. >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8164944 >> webrev: http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html >> testing: :hotspot_all >> 8178416: https://bugs.openjdk.java.net/browse/JDK-8178416 >> >> Thanks, >> -- Igor From david.holmes at oracle.com Thu Apr 13 01:47:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Apr 2017 11:47:11 +1000 Subject: RFR(S): 8164944: Refactor ProcessTools to get rid of dependency on java.management In-Reply-To: <9054D440-C6C9-4D97-AEB9-25CD3057564F@oracle.com> References: <9054D440-C6C9-4D97-AEB9-25CD3057564F@oracle.com> Message-ID: Hi Igor, Overall this looks good. To be clear the old executeTestJvmAllArgs() presumably provides the VM options from @run _and_ @module - right? So if they don't exist in a test we can simply replace the usage of executeTestJvmAllArgs with executeTestJvm - as done in: test/compiler/c2/cr7200264/TestDriver.java And for other tests we either grab the VM input arguments as a separate step, or else reconstruct them as needed (eg for the module flags in DebugOutputTest). Thanks, David On 13/04/2017 5:03 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html >> 92 lines changed: 36 ins; 36 del; 20 mod; > > Hi all, > > could you please review this small fix which removes dependency on java.management module from the testlibrary? > > jdk.test.lib.process.ProcessTools class has getVmInputArgs method which depend on java.management, this method is used only by j.d.t.process.ProcessTools::executeTestJvmAll and j.t.l.cli.CommandLineOptionTest class. > - ProcessTools::executeTestJvmAll is a variation of executeTestJvm which prepends vm flags from jtreg @run. > - CommandLineOptionTest is a library class for cli testing, it uses flags from ProcessTools::getVmInputArgs to create a new jvm with all flags > > the fix removes ProcessTools::executeTestJvmAll method, moves getVmInputArgs to a separate class jdk.test.lib.management.InputArguments. c.c.s.scenario.Executor and j.t.l.cli.CommandLineOptionTest are updated to use getVmInputArgs from that class. c.j.compilerToVM.DebugOutputTest is refactored to pass add-exports and patch module directly. all the affected classes and obviously updated to use executeTestJvm instead of executeTestJvmAll. > > after this fix many hotspot tests won't depend on java.management, hence that module might be removed from their @modules, this will be done separately by 8178416. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8164944 > webrev: http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html > testing: :hotspot_all > 8178416: https://bugs.openjdk.java.net/browse/JDK-8178416 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Thu Apr 13 01:56:06 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Apr 2017 18:56:06 -0700 Subject: RFR(S): 8164944: Refactor ProcessTools to get rid of dependency on java.management In-Reply-To: References: <9054D440-C6C9-4D97-AEB9-25CD3057564F@oracle.com> Message-ID: Hi David, right. executeTestJvmAllArgs prepends the VM options which the current JVM was started with, which is all options from jtreg harness: @run, @module, and the options specified in the command line by -javaoptions and -vmoptions to the passed arguments. executeTestJvm prepends only the options specified in the command line. so if there is no options from @run or @module, there is no difference b/w executeTestJvmAllArgs and executeTestJvm. in other cases, we need to do some extra steps. -- Igor > On Apr 12, 2017, at 6:47 PM, David Holmes wrote: > > Hi Igor, > > Overall this looks good. > > To be clear the old executeTestJvmAllArgs() presumably provides the VM options from @run _and_ @module - right? So if they don't exist in a test we can simply replace the usage of executeTestJvmAllArgs with executeTestJvm - as done in: > > test/compiler/c2/cr7200264/TestDriver.java > > And for other tests we either grab the VM input arguments as a separate step, or else reconstruct them as needed (eg for the module flags in DebugOutputTest). > > Thanks, > David > > On 13/04/2017 5:03 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html >>> 92 lines changed: 36 ins; 36 del; 20 mod; >> >> Hi all, >> >> could you please review this small fix which removes dependency on java.management module from the testlibrary? >> >> jdk.test.lib.process.ProcessTools class has getVmInputArgs method which depend on java.management, this method is used only by j.d.t.process.ProcessTools::executeTestJvmAll and j.t.l.cli.CommandLineOptionTest class. >> - ProcessTools::executeTestJvmAll is a variation of executeTestJvm which prepends vm flags from jtreg @run. >> - CommandLineOptionTest is a library class for cli testing, it uses flags from ProcessTools::getVmInputArgs to create a new jvm with all flags >> >> the fix removes ProcessTools::executeTestJvmAll method, moves getVmInputArgs to a separate class jdk.test.lib.management.InputArguments. c.c.s.scenario.Executor and j.t.l.cli.CommandLineOptionTest are updated to use getVmInputArgs from that class. c.j.compilerToVM.DebugOutputTest is refactored to pass add-exports and patch module directly. all the affected classes and obviously updated to use executeTestJvm instead of executeTestJvmAll. >> >> after this fix many hotspot tests won't depend on java.management, hence that module might be removed from their @modules, this will be done separately by 8178416. >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8164944 >> webrev: http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html >> testing: :hotspot_all >> 8178416: https://bugs.openjdk.java.net/browse/JDK-8178416 >> >> Thanks, >> -- Igor >> From igor.ignatyev at oracle.com Thu Apr 13 02:23:24 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Apr 2017 19:23:24 -0700 Subject: RFR(M) : Add CTW test for boot module Message-ID: <5CE18247-A373-4D5C-9B10-A68230DBA362@oracle.com> http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html > 237 lines changed: 236 ins; 0 del; 1 mod; Hi all, could you please review the patch which adds a test which runs CTW for lib/modules? Besides a file w/ jtreg test description, the patch contains CtwRunner class, which is a driver class for CTW tests. it compiles all classes from a target and, in case of an error, saves information about the error and restart CTW starting from the next class. The test takes approx. 2 hours to complete. currently there are 20 known errors related to class initialization. corresponding bugs will be filed and fixed shortly. webrev: http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8178291 testing: test/applications/ctw/Modules.java Thanks, -- Igor From vladimir.kozlov at oracle.com Thu Apr 13 02:55:36 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Apr 2017 19:55:36 -0700 Subject: RFR(M) : Add CTW test for boot module In-Reply-To: <5CE18247-A373-4D5C-9B10-A68230DBA362@oracle.com> References: <5CE18247-A373-4D5C-9B10-A68230DBA362@oracle.com> Message-ID: <6d392f2e-38d7-89b4-9d75-ed858b055923@oracle.com> Igor, When we ran CTW in Nightly before we sliced rt.jar to few parts using CompileTheWorldStartAt/CompileTheWorldStopAt to get better parallelism. Can we do the same here? You already have mechanism to restart with N+1 after error. 2 hours for serial test execution is too long - would be nice to parallelize it. Thanks, Vladimir On 4/12/17 7:23 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html >> 237 lines changed: 236 ins; 0 del; 1 mod; > > Hi all, > > could you please review the patch which adds a test which runs CTW for lib/modules? > > Besides a file w/ jtreg test description, the patch contains CtwRunner class, which is a driver class for CTW tests. it compiles all classes from a target and, in case of an error, saves information about the error and restart CTW starting from the next class. The test takes approx. 2 hours to complete. > > currently there are 20 known errors related to class initialization. corresponding bugs will be filed and fixed shortly. > > webrev: http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8178291 > testing: test/applications/ctw/Modules.java > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Thu Apr 13 03:15:51 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Apr 2017 20:15:51 -0700 Subject: RFR(M) : Add CTW test for boot module In-Reply-To: <6d392f2e-38d7-89b4-9d75-ed858b055923@oracle.com> References: <5CE18247-A373-4D5C-9B10-A68230DBA362@oracle.com> <6d392f2e-38d7-89b4-9d75-ed858b055923@oracle.com> Message-ID: Vladimir, In current implementation, CTW is parallelized itself, we compile classes independently by CICompilerCount threads, so I don't think having N separate processes will give us any improvements here. -- Igor > On Apr 12, 2017, at 7:55 PM, Vladimir Kozlov wrote: > > Igor, > > When we ran CTW in Nightly before we sliced rt.jar to few parts using CompileTheWorldStartAt/CompileTheWorldStopAt to get better parallelism. > Can we do the same here? You already have mechanism to restart with N+1 after error. > 2 hours for serial test execution is too long - would be nice to parallelize it. > > Thanks, > Vladimir > > On 4/12/17 7:23 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html >>> 237 lines changed: 236 ins; 0 del; 1 mod; >> >> Hi all, >> >> could you please review the patch which adds a test which runs CTW for lib/modules? >> >> Besides a file w/ jtreg test description, the patch contains CtwRunner class, which is a driver class for CTW tests. it compiles all classes from a target and, in case of an error, saves information about the error and restart CTW starting from the next class. The test takes approx. 2 hours to complete. >> >> currently there are 20 known errors related to class initialization. corresponding bugs will be filed and fixed shortly. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html >> jbs: https://bugs.openjdk.java.net/browse/JDK-8178291 >> testing: test/applications/ctw/Modules.java >> >> Thanks, >> -- Igor >> From vladimir.kozlov at oracle.com Thu Apr 13 03:34:36 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Apr 2017 20:34:36 -0700 Subject: RFR(M) : Add CTW test for boot module In-Reply-To: References: <5CE18247-A373-4D5C-9B10-A68230DBA362@oracle.com> <6d392f2e-38d7-89b4-9d75-ed858b055923@oracle.com> Message-ID: <35f3ed65-9125-b0a9-0feb-9252de7526ee@oracle.com> On 4/12/17 8:15 PM, Igor Ignatyev wrote: > Vladimir, > > In current implementation, CTW is parallelized itself, we compile classes independently by CICompilerCount threads, so I don't think having N separate processes will give us any improvements here. Where is that code? Code in ClassLoader::compile_the_world_in() iterates methods only. I also don't see CompileTheWorld flag in new test files. Only CompileTheWorldStartAt. Vladimir > > -- Igor > >> On Apr 12, 2017, at 7:55 PM, Vladimir Kozlov wrote: >> >> Igor, >> >> When we ran CTW in Nightly before we sliced rt.jar to few parts using CompileTheWorldStartAt/CompileTheWorldStopAt to get better parallelism. >> Can we do the same here? You already have mechanism to restart with N+1 after error. >> 2 hours for serial test execution is too long - would be nice to parallelize it. >> >> Thanks, >> Vladimir >> >> On 4/12/17 7:23 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html >>>> 237 lines changed: 236 ins; 0 del; 1 mod; >>> >>> Hi all, >>> >>> could you please review the patch which adds a test which runs CTW for lib/modules? >>> >>> Besides a file w/ jtreg test description, the patch contains CtwRunner class, which is a driver class for CTW tests. it compiles all classes from a target and, in case of an error, saves information about the error and restart CTW starting from the next class. The test takes approx. 2 hours to complete. >>> >>> currently there are 20 known errors related to class initialization. corresponding bugs will be filed and fixed shortly. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8178291 >>> testing: test/applications/ctw/Modules.java >>> >>> Thanks, >>> -- Igor >>> > From igor.ignatyev at oracle.com Thu Apr 13 03:48:16 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Apr 2017 20:48:16 -0700 Subject: RFR(M) : Add CTW test for boot module In-Reply-To: <35f3ed65-9125-b0a9-0feb-9252de7526ee@oracle.com> References: <5CE18247-A373-4D5C-9B10-A68230DBA362@oracle.com> <6d392f2e-38d7-89b4-9d75-ed858b055923@oracle.com> <35f3ed65-9125-b0a9-0feb-9252de7526ee@oracle.com> Message-ID: this code is in CTW library hotspot/test/testlibrary/ctw, more precisely in sun.hotspot.tools.ctw.CompileTheWorld::createExecutor method. we stoped to use ClassLoader::compile_the_world and switched to java library shortly after 1st jigsaw integration, see JDK-8153675. Actually, I ain't sure if ClassLoader::compile_the_world still can be used, it has dependency on Xbootclasspath/p which was removed. I was planning to remove CompileTheWorld flag and all the related code from hotspot in JDK 9 TF, but didn't have time. -- Igor > On Apr 12, 2017, at 8:34 PM, Vladimir Kozlov wrote: > > On 4/12/17 8:15 PM, Igor Ignatyev wrote: >> Vladimir, >> >> In current implementation, CTW is parallelized itself, we compile classes independently by CICompilerCount threads, so I don't think having N separate processes will give us any improvements here. > > Where is that code? Code in ClassLoader::compile_the_world_in() iterates methods only. > > I also don't see CompileTheWorld flag in new test files. Only CompileTheWorldStartAt. > > Vladimir > >> >> -- Igor >> >>> On Apr 12, 2017, at 7:55 PM, Vladimir Kozlov wrote: >>> >>> Igor, >>> >>> When we ran CTW in Nightly before we sliced rt.jar to few parts using CompileTheWorldStartAt/CompileTheWorldStopAt to get better parallelism. >>> Can we do the same here? You already have mechanism to restart with N+1 after error. >>> 2 hours for serial test execution is too long - would be nice to parallelize it. >>> >>> Thanks, >>> Vladimir >>> >>> On 4/12/17 7:23 PM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html >>>>> 237 lines changed: 236 ins; 0 del; 1 mod; >>>> >>>> Hi all, >>>> >>>> could you please review the patch which adds a test which runs CTW for lib/modules? >>>> >>>> Besides a file w/ jtreg test description, the patch contains CtwRunner class, which is a driver class for CTW tests. it compiles all classes from a target and, in case of an error, saves information about the error and restart CTW starting from the next class. The test takes approx. 2 hours to complete. >>>> >>>> currently there are 20 known errors related to class initialization. corresponding bugs will be filed and fixed shortly. >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8178291 >>>> testing: test/applications/ctw/Modules.java >>>> >>>> Thanks, >>>> -- Igor >>>> >> From vladimir.kozlov at oracle.com Thu Apr 13 05:01:35 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Apr 2017 22:01:35 -0700 Subject: RFR(M) : Add CTW test for boot module In-Reply-To: References: <5CE18247-A373-4D5C-9B10-A68230DBA362@oracle.com> <6d392f2e-38d7-89b4-9d75-ed858b055923@oracle.com> <35f3ed65-9125-b0a9-0feb-9252de7526ee@oracle.com> Message-ID: <4855ecad-79f1-eff4-4748-77752c56ee57@oracle.com> Okay. I see now. Changes looks good then. Thanks, Vladimir On 4/12/17 8:48 PM, Igor Ignatyev wrote: > this code is in CTW library hotspot/test/testlibrary/ctw, more precisely in sun.hotspot.tools.ctw.CompileTheWorld::createExecutor method. we stoped to use ClassLoader::compile_the_world and switched to java library shortly after 1st jigsaw integration, see JDK-8153675. Actually, I ain't sure if ClassLoader::compile_the_world still can be used, it has dependency on Xbootclasspath/p which was removed. I was planning to remove CompileTheWorld flag and all the related code from hotspot in JDK 9 TF, but didn't have time. > > -- Igor > >> On Apr 12, 2017, at 8:34 PM, Vladimir Kozlov wrote: >> >> On 4/12/17 8:15 PM, Igor Ignatyev wrote: >>> Vladimir, >>> >>> In current implementation, CTW is parallelized itself, we compile classes independently by CICompilerCount threads, so I don't think having N separate processes will give us any improvements here. >> >> Where is that code? Code in ClassLoader::compile_the_world_in() iterates methods only. >> >> I also don't see CompileTheWorld flag in new test files. Only CompileTheWorldStartAt. >> >> Vladimir >> >>> >>> -- Igor >>> >>>> On Apr 12, 2017, at 7:55 PM, Vladimir Kozlov wrote: >>>> >>>> Igor, >>>> >>>> When we ran CTW in Nightly before we sliced rt.jar to few parts using CompileTheWorldStartAt/CompileTheWorldStopAt to get better parallelism. >>>> Can we do the same here? You already have mechanism to restart with N+1 after error. >>>> 2 hours for serial test execution is too long - would be nice to parallelize it. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/12/17 7:23 PM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html >>>>>> 237 lines changed: 236 ins; 0 del; 1 mod; >>>>> >>>>> Hi all, >>>>> >>>>> could you please review the patch which adds a test which runs CTW for lib/modules? >>>>> >>>>> Besides a file w/ jtreg test description, the patch contains CtwRunner class, which is a driver class for CTW tests. it compiles all classes from a target and, in case of an error, saves information about the error and restart CTW starting from the next class. The test takes approx. 2 hours to complete. >>>>> >>>>> currently there are 20 known errors related to class initialization. corresponding bugs will be filed and fixed shortly. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8178291/webrev.00/index.html >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8178291 >>>>> testing: test/applications/ctw/Modules.java >>>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>> > From lutz.schmidt at sap.com Thu Apr 13 10:10:31 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 13 Apr 2017 10:10:31 +0000 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <1C84273B-2FA8-4B91-B412-0D2F815C13F2@sap.com> <9bc87d3e-a657-1e10-f688-e51e4e26645d@redhat.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> Message-ID: Hi Zoltan, I am now able to reproduce the problem. Calculated crc and reference crc are exactly the same as in the log output you pasted below. And the problem shows up on linux-x86_64 as well. Here is what?s happening: The CRC32C implementation generates code depending on the CLMUL cpu feature being available. On most machines @Oracle and @SAP, this feature seems to be available ? except for one of your MacOS test machines. To gain control over that feature, I have modified just one line in src/cpu/x86/vm/vm_version_x86_64.hpp like this: static bool supports_clmul() { return ((_features & CPU_CLMUL) != 0) && UseNewCode; } The boolean UseNewCode is a command line parameter we use @SAP to make experimental code switchable during development. With that modification, I can force off the CLMUL feature at will. And voila, here is what I get (linux-x86_64): lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java -XX:+UseNewCode TestCRC32C_OpenJDK -m updateBytesCRC32C: pclmulqdq = true. testing 1050 cases ... lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java -XX:-UseNewCode TestCRC32C_OpenJDK -m updateBytesCRC32C: pclmulqdq = false. testing 1050 cases ... ERROR: crc = 6f894393, crcReference = 2cdf6e8f iteration 0: offsets[0] = 0 sizes[30] = 1024 Exception: java.lang.Exception: TestCRC32C Error Exception in thread "main" java.lang.Exception: java.lang.Exception: TestCRC32C Error at TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:306) at TestCRC32C_OpenJDK.main(TestCRC32C_OpenJDK.java:74) Caused by: java.lang.Exception: TestCRC32C Error at TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:298) ... 1 more lu0084 PrivSrc/TestCRC> Output on MacOS is the same. I did not try solaris-x86_64. The bug is in MacroAssembler::crc32c_ipl_alg2_alt2() or one of its callees. I have not yet performed an in-depth analysis on what?s going wrong, mainly because I am not a proven expert on x86 machine code. So how do we proceed from here? Shouldn?t we file a separate bug for this x86 issue? Should this webrev (8176580) be split up into the (ppc, s390) chunk and a separate test bug webrev? Can you push this webrev despite there is an (unrelated) JPRT failure? Thanks and best regards, Lutz On 12.04.2017, 18:36, "hotspot-compiler-dev on behalf of Schmidt, Lutz" wrote: Hi Zoltan, I?m not able to reproduce the problem as of now. I will try out other (older) x86 machines tomorrow. Could be a problem in fallback code when required vector instructions are not available. Can you please find out on what H/W (CPU in particular) the tests are failing? Thanks, Lutz On 12.04.2017, 14:38, "Zolt?n Maj?" wrote: Hi Lutz, On 04/12/2017 02:14 PM, Schmidt, Lutz wrote: > Hi Zoltan, > > First of all: thanks for trying to push! Second: sorry for the problems you ran into. you are welcome and no problem, of course. > I do not have an immediate explanation for the failure ? my dev machine is MacOS/x86_64. I will try to reproduce immediately. For the time being: is there any log output that could shed some light on the issue? Please find the output below (and sorry for not including it before). Please let me know if you were able to reproduce the problem (or not). Best regards, Zoltan command: main -Xbatch compiler.intrinsics.zip.TestCRC32C -m reason: User specified action: run main/othervm/timeout=600 -Xbatch compiler.intrinsics.zip.TestCRC32C -m Mode: othervm [/othervm specified] elapsed time (seconds): 1.915 configuration: STDOUT: testing 1050 cases ... STDERR: ERROR: crc = 6f894393, crcReference = 2cdf6e8f java.lang.Exception: TestCRC32C Error at compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218) at compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280) at compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:563) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) JavaTest Message: Test threw exception: java.lang.Exception: TestCRC32C Error JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.Exception: TestCRC32C Error > > Thanks, > Lutz > > > On 12.04.2017, 13:10, "hotspot-compiler-dev on behalf of Zolt?n Maj?" wrote: > > P.S.: Forgot to mention: The problem does not appear on any other x86_64 > platform. > > On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > > Hi Volker, > > Hi Lutz, > > > > > > yesterday I tried to push webrev.03 using JPRT. Unfortunately, the > > TestCRC32C.java test you've modified fails on Mac OS X on x86_64. Do > > you have an idea why that could be? > > > > Thank you! Best regards, > > > > > > Zoltan > > > > On 04/11/2017 06:03 PM, Volker Simonis wrote: > >> Thanks a lot Zoltan! > >> > >> > >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? >> > wrote: > >> > >> Hi Volker, > >> > >> > >> On 04/11/2017 03:34 PM, Volker Simonis wrote: > >> > >> > >> Hi Zoltan, > >> > >> could you please be so kind to sponsor this reviewed change > >> for jdk10? > >> > >> > >> yes, of course. I'll push it today. > >> > >> Best regards, > >> > >> > >> Zoltan > >> > >> Initially we wanted to push it ourselves because it was s390x > >> only but now that we've also touched the tests we need a > >> sponsor. > >> > >> Thank you and best regards, > >> Volker > >> > >> ---------- Forwarded message ---------- > >> From: *Volker Simonis* >> > >> >> >> > >> Date: Fri, Mar 31, 2017 at 10:53 AM > >> Subject: Re: RFR (S) 8176580: [ppc, s390] CRC32C: wrong > >> checksum result in some cases > >> To: "Schmidt, Lutz" >> >> >> > >> Cc: Andrew Haley > >> >>, > >> "hotspot-compiler-dev at openjdk.java.net > >> > >> >> >" > >> >> > >> >> >> > >> > >> > >> Ping... > >> > >> Can somebody please push this change? > >> > >> It's ppc64/s390x only but as a courtesy to the community it > >> also fixes > >> the CRC JTreg tests so unfortunately I still can't push it > >> myself :) > >> > >> Thank you and best regards, > >> Volker > >> > >> > >> On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis > >> > >> >> >> wrote: > >> > Hi Lutz, > >> > > >> > thanks a lot for fixing the test! > >> > Your change looks good now. > >> > > >> > Because this touches shared (i.e. test) files, we still need > >> a sponsor > >> > so can somebody please sponsor this change? > >> > > >> > Thank you and best regards, > >> > Volker > >> > > >> > > >> > > >> > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz > >> > >> >> > >> wrote: > >> >> Hi Volker, > >> >> > >> >> Sorry for letting you wait. Here is the final(?) webrev, > >> containing all your requests for cleanup and improvements: > >> >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ > >> > >> >> > > >> >> > >> >> As before, the *.cpp files have not been modified. > >> >> > >> >> Best Regards, > >> >> Lutz > >> >> > >> >> > >> >> > >> >> On 21/03/2017, 17:55, "Volker Simonis" > >> > >> >> >> wrote: > >> >> > >> >> Hi Lutz, > >> >> > >> >> thanks a lot for updating the tests. I think they look > >> much better now. > >> >> > >> >> There's just one more cleanup I'd like to propose. Can > >> you please move > >> >> the throw right into the check() function. Just make > >> check() return > >> >> void and throw from it if there's a mismatch between > >> the computed and > >> >> the expected result. I leave it up to you if you want > >> to pass an extra > >> >> error string to check() which will be printed in the > >> case of an error. > >> >> I personally don't think that's necessary as it will be > >> evident from > >> >> the stack trace which computation failed. > >> >> > >> >> Also the try/catch and rethrow in test_multi() isn't > >> necessary. The > >> >> test can be simply terminated by the initial exception. > >> >> > >> >> Thank you and best regards, > >> >> Volker > >> >> > >> >> > >> >> On Fri, Mar 17, 2017 at 10:03 PM, Schmidt, Lutz > >> > >> >> > >> wrote: > >> >> > Hi Volker, > >> >> > > >> >> > Thanks a lot for your valuable hints. > >> >> > > >> >> > I have worked some time on the Java test files: > >> >> > TestCRC32.java and TestCRC32C.java are now > >> identical as far as possible. > >> >> > They now throw an exception, should any error be > >> detected. > >> >> > The ?reference CRC value? is now used in > >> test_multi() as well. > >> >> > The extra test runs have been removed again. > >> >> > The test methodology is fixed: each result is > >> tested against its reference. > >> >> > The tests now detect the bug introduced with > >> 8175368 and 8175369. > >> >> > No issue is indicated when testing with 8176580. > >> >> > I ran jcheck, and to the best of my ability and > >> knowledge, there is no trailing whitespace. > >> >> > All *.cpp files were left untouched! > >> >> > > >> >> > The next iteration of the webrev: > >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ > >> > >> >> > > >> >> > > >> >> > Best regards, > >> >> > Lutz > >> >> > > >> >> > > >> >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 > >> (6227) 7-42834 > >> > >> >> > > >> >> > > >> >> > > >> >> > On 16.03.17, 11:28, "Volker Simonis" > >> > >> >> >> wrote: > >> >> > > >> >> > On Wed, Mar 15, 2017 at 5:55 PM, Schmidt, Lutz > >> > >> >> > >> wrote: > >> >> > > > >> >> > > Hi Andrew, Volker, > >> >> > > > >> >> > > What do you think about these test enhancements? > >> >> > > Webrev: > >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ > >> > >> >> > > >> > >> >> > > > >> >> > > Please note: the cpp files in the webrev > >> remained unchanged. > >> >> > > > >> >> > > I added some improvements (as I believe) to the > >> TestCRC32(C).java files. > >> >> > > > >> >> > > In some more detail: > >> >> > > The test now calculates a ?reference CRC > >> value?, based on a java implementation of the CRC32 algorithm. > >> This reference value is used to verify all other crc values, > >> in particular during initialization and warmup. Three > >> additional test runs check a non-zero offset with ?Xint, > >> -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp > >> -XX:+TieredCompilation (C1 + C2). > >> >> > > > >> >> > > >> >> > Hi Lutz, > >> >> > > >> >> > thanks for updating the tests. I've had a closer > >> look at the tests and > >> >> > realized that they actually can never fail! The > >> check() routine just > >> >> > prints an error message but that will not let the > >> test fail. So I > >> >> > would suggest to throw a runtime exception in the > >> check() routine > >> >> > after the error message was printed. > >> >> > > >> >> > I also suggest to do the check during the normal > >> test execution (i.e. > >> >> > in test_multi()) so there's no need for extra > >> test runs. > >> >> > > >> >> > Finally, the current test methodology in > >> test_multi() is broken: > >> >> > - it sets the reference by calling CRC from the > >> interpreter which > >> >> > won't work if the intrinsic is also used in the > >> interpreter. > >> >> > - it only compares the reference against the > >> last computation of CRC > >> >> > in the loop which will be the result of the C2 > >> generated code. This > >> >> > misses errors in C1. > >> >> > > >> >> > I suggest to use your new, pure Java > >> implementation for the > >> >> > computation of the reference result and compare > >> the reference with the > >> >> > result of calling CRC in every iteration of the > >> loop so we really > >> >> > check all possibilities from interpreter trough > >> C1 to C2. > >> >> > > >> >> > Finally, can you please pay attention to not > >> insert trailing > >> >> > whitespace (there was some at line 88 in > >> TestCRC32C.java). You can > >> >> > easily verify this by running jcheck before > >> creating the webrevs. > >> >> > > >> >> > Thanks, > >> >> > Volker > >> >> > > >> >> > > > >> >> > > Best regards, > >> >> > > Lutz > >> >> > > > >> >> > > > >> >> > > On 15.03.17, 11:50, "Volker Simonis" > >> > >> >> >> wrote: > >> >> > > > >> >> > > On Tue, Mar 14, 2017 at 7:05 PM, Andrew > >> Haley > >> >> wrote: > >> >> > > > On 14/03/17 13:12, Schmidt, Lutz wrote: > >> >> > > > > >> >> > > >> Yes, one might think of running a test > >> suite subset multiple times > >> >> > > >> with different parameters. In this case, > >> -Xint and/or ?Xcomp were > >> >> > > >> helpful. Forcing tests to run fully > >> interpreted or fully compiled > >> >> > > >> helps in cases where a certain function, > >> e.g. an intrinsic, is > >> >> > > >> invoked via distinct code paths. > >> >> > > > > >> >> > > > Right, so your patch should include that > >> change to the test suite. > >> >> > > > > >> >> > > > >> >> > > Hi Lutz, > >> >> > > > >> >> > > I agree with Andrew. We should really fix > >> the tests such that they > >> >> > > check the correctness of the intrinsics. > >> >> > > > >> >> > > This may be tricky if all three, the > >> interpreter, the client and the > >> >> > > server compiler use the same intrinsic > >> implementation. You could > >> >> > > either copy the pure Java implementation > >> into the test so that you can > >> >> > > compare the results of the intrinsic > >> operation against it or you can > >> >> > > switch them off in the compilers with > >> >> > > "-XX:DisableIntrinsic=_updateBytesCRC32C > >> >> > > > >> -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and > >> compare the > >> >> > > results. Not sure which solution is more > >> practical, but I would be > >> >> > > really scared if we wouldn't have these test. > >> >> > > > >> >> > > Regards, > >> >> > > Volker > >> >> > > > >> >> > > > Andrew. > >> >> > > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > >> >> > >> > >> > >> > > > > > From volker.simonis at gmail.com Thu Apr 13 13:25:40 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 13 Apr 2017 15:25:40 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <1C84273B-2FA8-4B91-B412-0D2F815C13F2@sap.com> <9bc87d3e-a657-1e10-f688-e51e4e26645d@redhat.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> Message-ID: Hi Lutz, Zoltan, @Lutz, thanks for analyzing the problem! I actually didn't expected that the efforts we put into fixing the tests will pay up that fast :) @Zoltan: I propose we split the test from the actual fix. I can push the ppc64/s390x parts myself. I opened the new prio 2 bug "8178720: CRC32C fails on old x86 hardware without CLMUL support" for jdk9 and linked the reworked tests from Lutz' last webrev to it. I think this is definitely something we should fix before jdk9 will be released and the nfix should contain the new, fixed version of the tests. Zoltan, can you please take care of this? Thank you and best regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8178720 On Thu, Apr 13, 2017 at 12:10 PM, Schmidt, Lutz wrote: > Hi Zoltan, > > I am now able to reproduce the problem. Calculated crc and reference crc > are exactly the same as in the log output you pasted below. And the problem > shows up on linux-x86_64 as well. > > Here is what?s happening: > The CRC32C implementation generates code depending on the CLMUL cpu > feature being available. On most machines @Oracle and @SAP, this feature > seems to be available ? except for one of your MacOS test machines. > > To gain control over that feature, I have modified just one line in > src/cpu/x86/vm/vm_version_x86_64.hpp like this: > static bool supports_clmul() { return ((_features & CPU_CLMUL) != > 0) && UseNewCode; } > > The boolean UseNewCode is a command line parameter we use @SAP to make > experimental code switchable during development. With that modification, I > can force off the CLMUL feature at will. And voila, here is what I get > (linux-x86_64): > > lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java -XX:+UseNewCode > TestCRC32C_OpenJDK -m > updateBytesCRC32C: pclmulqdq = true. > testing 1050 cases ... > lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java -XX:-UseNewCode > TestCRC32C_OpenJDK -m > updateBytesCRC32C: pclmulqdq = false. > testing 1050 cases ... > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > iteration 0: offsets[0] = 0 sizes[30] = 1024 > Exception: java.lang.Exception: TestCRC32C Error > Exception in thread "main" java.lang.Exception: java.lang.Exception: > TestCRC32C Error > at TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:306) > at TestCRC32C_OpenJDK.main(TestCRC32C_OpenJDK.java:74) > Caused by: java.lang.Exception: TestCRC32C Error > at TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:298) > ... 1 more > lu0084 PrivSrc/TestCRC> > > Output on MacOS is the same. I did not try solaris-x86_64. > > The bug is in MacroAssembler::crc32c_ipl_alg2_alt2() or one of its > callees. I have not yet performed an in-depth analysis on what?s going > wrong, mainly because I am not a proven expert on x86 machine code. > > So how do we proceed from here? Shouldn?t we file a separate bug for this > x86 issue? Should this webrev (8176580) be split up into the (ppc, s390) > chunk and a separate test bug webrev? Can you push this webrev despite > there is an (unrelated) JPRT failure? > > Thanks and best regards, > Lutz > > > > On 12.04.2017, 18:36, "hotspot-compiler-dev on behalf of Schmidt, Lutz" < > hotspot-compiler-dev-bounces at openjdk.java.net on behalf of > lutz.schmidt at sap.com> wrote: > > Hi Zoltan, > > I?m not able to reproduce the problem as of now. I will try out other > (older) x86 machines tomorrow. Could be a problem in fallback code when > required vector instructions are not available. > > Can you please find out on what H/W (CPU in particular) the tests are > failing? > > Thanks, > Lutz > > > On 12.04.2017, 14:38, "Zolt?n Maj?" wrote: > > Hi Lutz, > > > On 04/12/2017 02:14 PM, Schmidt, Lutz wrote: > > Hi Zoltan, > > > > First of all: thanks for trying to push! Second: sorry for the > problems you ran into. > > you are welcome and no problem, of course. > > > I do not have an immediate explanation for the failure ? my dev > machine is MacOS/x86_64. I will try to reproduce immediately. For the time > being: is there any log output that could shed some light on the issue? > > Please find the output below (and sorry for not including it > before). > > Please let me know if you were able to reproduce the problem (or > not). > > Best regards, > > > Zoltan > > command: main -Xbatch compiler.intrinsics.zip.TestCRC32C -m > reason: User specified action: run main/othervm/timeout=600 > -Xbatch compiler.intrinsics.zip.TestCRC32C -m > Mode: othervm [/othervm specified] > elapsed time (seconds): 1.915 > configuration: > STDOUT: > testing 1050 cases ... > STDERR: > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > java.lang.Exception: TestCRC32C Error > at compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C. > java:218) > at compiler.intrinsics.zip.TestCRC32C.test_multi( > TestCRC32C.java:280) > at compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C. > java:74) > at java.base/jdk.internal.reflect. > NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect. > NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect. > DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect. > Method.invoke(Method.java:563) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread. > run(MainWrapper.java:110) > at java.base/java.lang.Thread.run(Thread.java:844) > > JavaTest Message: Test threw exception: java.lang.Exception: > TestCRC32C Error > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.Exception: > TestCRC32C Error > > > > > > > Thanks, > > Lutz > > > > > > On 12.04.2017, 13:10, "hotspot-compiler-dev on behalf of Zolt?n > Maj?" zoltan.majo at oracle.com> wrote: > > > > P.S.: Forgot to mention: The problem does not appear on any > other x86_64 > > platform. > > > > On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > > > Hi Volker, > > > Hi Lutz, > > > > > > > > > yesterday I tried to push webrev.03 using JPRT. > Unfortunately, the > > > TestCRC32C.java test you've modified fails on Mac OS X on > x86_64. Do > > > you have an idea why that could be? > > > > > > Thank you! Best regards, > > > > > > > > > Zoltan > > > > > > On 04/11/2017 06:03 PM, Volker Simonis wrote: > > >> Thanks a lot Zoltan! > > >> > > >> > > >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? < > zoltan.majo at oracle.com > > >> > wrote: > > >> > > >> Hi Volker, > > >> > > >> > > >> On 04/11/2017 03:34 PM, Volker Simonis wrote: > > >> > > >> > > >> Hi Zoltan, > > >> > > >> could you please be so kind to sponsor this > reviewed change > > >> for jdk10? > > >> > > >> > > >> yes, of course. I'll push it today. > > >> > > >> Best regards, > > >> > > >> > > >> Zoltan > > >> > > >> Initially we wanted to push it ourselves because > it was s390x > > >> only but now that we've also touched the tests > we need a > > >> sponsor. > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> ---------- Forwarded message ---------- > > >> From: *Volker Simonis* > >> > > >> > >> >> > > >> Date: Fri, Mar 31, 2017 at 10:53 AM > > >> Subject: Re: RFR (S) 8176580: [ppc, s390] > CRC32C: wrong > > >> checksum result in some cases > > >> To: "Schmidt, Lutz" > >> lutz.schmidt at sap.com > > >> >> > > >> Cc: Andrew Haley aph at redhat.com> > > >> >>>, > > >> "hotspot-compiler-dev at openjdk.java.net > > >> > > >> > >> >" > > >> > >> > > >> > >> >> > > >> > > >> > > >> Ping... > > >> > > >> Can somebody please push this change? > > >> > > >> It's ppc64/s390x only but as a courtesy to the > community it > > >> also fixes > > >> the CRC JTreg tests so unfortunately I still > can't push it > > >> myself :) > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> > > >> On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis > > >> volker.simonis at gmail.com> > > >> > >> >> wrote: > > >> > Hi Lutz, > > >> > > > >> > thanks a lot for fixing the test! > > >> > Your change looks good now. > > >> > > > >> > Because this touches shared (i.e. test) files, > we still need > > >> a sponsor > > >> > so can somebody please sponsor this change? > > >> > > > >> > Thank you and best regards, > > >> > Volker > > >> > > > >> > > > >> > > > >> > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz > > >> lutz.schmidt at sap.com> > > >> lutz.schmidt at sap.com>>> > > >> wrote: > > >> >> Hi Volker, > > >> >> > > >> >> Sorry for letting you wait. Here is the > final(?) webrev, > > >> containing all your requests for cleanup and > improvements: > > >> >> http://cr.openjdk.java.net/~ > lucy/webrevs/8176580.03/ > > >> > > >> > >> >> > > >> >> > > >> >> As before, the *.cpp files have not been > modified. > > >> >> > > >> >> Best Regards, > > >> >> Lutz > > >> >> > > >> >> > > >> >> > > >> >> On 21/03/2017, 17:55, "Volker Simonis" > > >> volker.simonis at gmail.com> > > >> > >> >> wrote: > > >> >> > > >> >> Hi Lutz, > > >> >> > > >> >> thanks a lot for updating the tests. I > think they look > > >> much better now. > > >> >> > > >> >> There's just one more cleanup I'd like to > propose. Can > > >> you please move > > >> >> the throw right into the check() > function. Just make > > >> check() return > > >> >> void and throw from it if there's a > mismatch between > > >> the computed and > > >> >> the expected result. I leave it up to you > if you want > > >> to pass an extra > > >> >> error string to check() which will be > printed in the > > >> case of an error. > > >> >> I personally don't think that's necessary > as it will be > > >> evident from > > >> >> the stack trace which computation failed. > > >> >> > > >> >> Also the try/catch and rethrow in > test_multi() isn't > > >> necessary. The > > >> >> test can be simply terminated by the > initial exception. > > >> >> > > >> >> Thank you and best regards, > > >> >> Volker > > >> >> > > >> >> > > >> >> On Fri, Mar 17, 2017 at 10:03 PM, > Schmidt, Lutz > > >> lutz.schmidt at sap.com> > > >> lutz.schmidt at sap.com>>> > > >> wrote: > > >> >> > Hi Volker, > > >> >> > > > >> >> > Thanks a lot for your valuable hints. > > >> >> > > > >> >> > I have worked some time on the Java > test files: > > >> >> > TestCRC32.java and TestCRC32C.java > are now > > >> identical as far as possible. > > >> >> > They now throw an exception, should > any error be > > >> detected. > > >> >> > The ?reference CRC value? is now used > in > > >> test_multi() as well. > > >> >> > The extra test runs have been removed > again. > > >> >> > The test methodology is fixed: each > result is > > >> tested against its reference. > > >> >> > The tests now detect the bug > introduced with > > >> 8175368 and 8175369. > > >> >> > No issue is indicated when testing > with 8176580. > > >> >> > I ran jcheck, and to the best of my > ability and > > >> knowledge, there is no trailing whitespace. > > >> >> > All *.cpp files were left untouched! > > >> >> > > > >> >> > The next iteration of the webrev: > > >> http://cr.openjdk.java.net/~ > lucy/webrevs/8176580.02/ > > >> > > >> > >> >> > > >> >> > > > >> >> > Best regards, > > >> >> > Lutz > > >> >> > > > >> >> > > > >> >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP > Core | T: +49 > > >> (6227) 7-42834 42834> > > >> > > >> >> > > > >> >> > > > >> >> > > > >> >> > On 16.03.17, 11:28, "Volker Simonis" > > >> volker.simonis at gmail.com> > > >> > >> >> wrote: > > >> >> > > > >> >> > On Wed, Mar 15, 2017 at 5:55 PM, > Schmidt, Lutz > > >> lutz.schmidt at sap.com> > > >> lutz.schmidt at sap.com>>> > > >> wrote: > > >> >> > > > > >> >> > > Hi Andrew, Volker, > > >> >> > > > > >> >> > > What do you think about these > test enhancements? > > >> >> > > Webrev: > > >> http://cr.openjdk.java.net/~ > lucy/webrevs/8176580.01/ > > >> > > >> > >> >> > > >> > > >> >> > > > > >> >> > > Please note: the cpp files in the > webrev > > >> remained unchanged. > > >> >> > > > > >> >> > > I added some improvements (as I > believe) to the > > >> TestCRC32(C).java files. > > >> >> > > > > >> >> > > In some more detail: > > >> >> > > The test now calculates a > ?reference CRC > > >> value?, based on a java implementation of the > CRC32 algorithm. > > >> This reference value is used to verify all other > crc values, > > >> in particular during initialization and warmup. > Three > > >> additional test runs check a non-zero offset > with ?Xint, > > >> -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp > > >> -XX:+TieredCompilation (C1 + C2). > > >> >> > > > > >> >> > > > >> >> > Hi Lutz, > > >> >> > > > >> >> > thanks for updating the tests. I've > had a closer > > >> look at the tests and > > >> >> > realized that they actually can > never fail! The > > >> check() routine just > > >> >> > prints an error message but that > will not let the > > >> test fail. So I > > >> >> > would suggest to throw a runtime > exception in the > > >> check() routine > > >> >> > after the error message was printed. > > >> >> > > > >> >> > I also suggest to do the check > during the normal > > >> test execution (i.e. > > >> >> > in test_multi()) so there's no need > for extra > > >> test runs. > > >> >> > > > >> >> > Finally, the current test > methodology in > > >> test_multi() is broken: > > >> >> > - it sets the reference by calling > CRC from the > > >> interpreter which > > >> >> > won't work if the intrinsic is also > used in the > > >> interpreter. > > >> >> > - it only compares the reference > against the > > >> last computation of CRC > > >> >> > in the loop which will be the > result of the C2 > > >> generated code. This > > >> >> > misses errors in C1. > > >> >> > > > >> >> > I suggest to use your new, pure Java > > >> implementation for the > > >> >> > computation of the reference result > and compare > > >> the reference with the > > >> >> > result of calling CRC in every > iteration of the > > >> loop so we really > > >> >> > check all possibilities from > interpreter trough > > >> C1 to C2. > > >> >> > > > >> >> > Finally, can you please pay > attention to not > > >> insert trailing > > >> >> > whitespace (there was some at line > 88 in > > >> TestCRC32C.java). You can > > >> >> > easily verify this by running > jcheck before > > >> creating the webrevs. > > >> >> > > > >> >> > Thanks, > > >> >> > Volker > > >> >> > > > >> >> > > > > >> >> > > Best regards, > > >> >> > > Lutz > > >> >> > > > > >> >> > > > > >> >> > > On 15.03.17, 11:50, "Volker > Simonis" > > >> volker.simonis at gmail.com> > > >> > >> >> wrote: > > >> >> > > > > >> >> > > On Tue, Mar 14, 2017 at 7:05 > PM, Andrew > > >> Haley > > >> >> > wrote: > > >> >> > > > On 14/03/17 13:12, Schmidt, > Lutz wrote: > > >> >> > > > > > >> >> > > >> Yes, one might think of > running a test > > >> suite subset multiple times > > >> >> > > >> with different parameters. > In this case, > > >> -Xint and/or ?Xcomp were > > >> >> > > >> helpful. Forcing tests to > run fully > > >> interpreted or fully compiled > > >> >> > > >> helps in cases where a > certain function, > > >> e.g. an intrinsic, is > > >> >> > > >> invoked via distinct code > paths. > > >> >> > > > > > >> >> > > > Right, so your patch should > include that > > >> change to the test suite. > > >> >> > > > > > >> >> > > > > >> >> > > Hi Lutz, > > >> >> > > > > >> >> > > I agree with Andrew. We > should really fix > > >> the tests such that they > > >> >> > > check the correctness of the > intrinsics. > > >> >> > > > > >> >> > > This may be tricky if all > three, the > > >> interpreter, the client and the > > >> >> > > server compiler use the same > intrinsic > > >> implementation. You could > > >> >> > > either copy the pure Java > implementation > > >> into the test so that you can > > >> >> > > compare the results of the > intrinsic > > >> operation against it or you can > > >> >> > > switch them off in the > compilers with > > >> >> > > "-XX:DisableIntrinsic=_ > updateBytesCRC32C > > >> >> > > > > >> -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" > and > > >> compare the > > >> >> > > results. Not sure which > solution is more > > >> practical, but I would be > > >> >> > > really scared if we wouldn't > have these test. > > >> >> > > > > >> >> > > Regards, > > >> >> > > Volker > > >> >> > > > > >> >> > > > Andrew. > > >> >> > > > > > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> > > >> > > >> > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Thu Apr 13 13:29:03 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 13 Apr 2017 15:29:03 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <69B4433F-72B8-4855-9C42-A89F4AB34F6F@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> Message-ID: Hi Lutz, thank you for the investigation and the detailed description of the problem! On 04/13/2017 12:10 PM, Schmidt, Lutz wrote: > [...] > > The bug is in MacroAssembler::crc32c_ipl_alg2_alt2() or one of its callees. I have not yet performed an in-depth analysis on what?s going wrong, mainly because I am not a proven expert on x86 machine code. > > So how do we proceed from here? Shouldn?t we file a separate bug for this x86 issue? Should this webrev (8176580) be split up into the (ppc, s390) chunk and a separate test bug webrev? Can you push this webrev despite there is an (unrelated) JPRT failure? I agree, it's a good idea file a separate bug for the issue your test just uncovered -- I can do that. [Volker actually just did that -- let me continue in my reply to his email.] Best regards, Zoltan > > Thanks and best regards, > Lutz > > > > On 12.04.2017, 18:36, "hotspot-compiler-dev on behalf of Schmidt, Lutz" wrote: > > Hi Zoltan, > > I?m not able to reproduce the problem as of now. I will try out other (older) x86 machines tomorrow. Could be a problem in fallback code when required vector instructions are not available. > > Can you please find out on what H/W (CPU in particular) the tests are failing? > > Thanks, > Lutz > > > On 12.04.2017, 14:38, "Zolt?n Maj?" wrote: > > Hi Lutz, > > > On 04/12/2017 02:14 PM, Schmidt, Lutz wrote: > > Hi Zoltan, > > > > First of all: thanks for trying to push! Second: sorry for the problems you ran into. > > you are welcome and no problem, of course. > > > I do not have an immediate explanation for the failure ? my dev machine is MacOS/x86_64. I will try to reproduce immediately. For the time being: is there any log output that could shed some light on the issue? > > Please find the output below (and sorry for not including it before). > > Please let me know if you were able to reproduce the problem (or not). > > Best regards, > > > Zoltan > > command: main -Xbatch compiler.intrinsics.zip.TestCRC32C -m > reason: User specified action: run main/othervm/timeout=600 -Xbatch compiler.intrinsics.zip.TestCRC32C -m > Mode: othervm [/othervm specified] > elapsed time (seconds): 1.915 > configuration: > STDOUT: > testing 1050 cases ... > STDERR: > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > java.lang.Exception: TestCRC32C Error > at compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218) > at compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280) > at compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:563) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at java.base/java.lang.Thread.run(Thread.java:844) > > JavaTest Message: Test threw exception: java.lang.Exception: TestCRC32C Error > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.Exception: TestCRC32C Error > > > > > > > Thanks, > > Lutz > > > > > > On 12.04.2017, 13:10, "hotspot-compiler-dev on behalf of Zolt?n Maj?" wrote: > > > > P.S.: Forgot to mention: The problem does not appear on any other x86_64 > > platform. > > > > On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > > > Hi Volker, > > > Hi Lutz, > > > > > > > > > yesterday I tried to push webrev.03 using JPRT. Unfortunately, the > > > TestCRC32C.java test you've modified fails on Mac OS X on x86_64. Do > > > you have an idea why that could be? > > > > > > Thank you! Best regards, > > > > > > > > > Zoltan > > > > > > On 04/11/2017 06:03 PM, Volker Simonis wrote: > > >> Thanks a lot Zoltan! > > >> > > >> > > >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? > >> > wrote: > > >> > > >> Hi Volker, > > >> > > >> > > >> On 04/11/2017 03:34 PM, Volker Simonis wrote: > > >> > > >> > > >> Hi Zoltan, > > >> > > >> could you please be so kind to sponsor this reviewed change > > >> for jdk10? > > >> > > >> > > >> yes, of course. I'll push it today. > > >> > > >> Best regards, > > >> > > >> > > >> Zoltan > > >> > > >> Initially we wanted to push it ourselves because it was s390x > > >> only but now that we've also touched the tests we need a > > >> sponsor. > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> ---------- Forwarded message ---------- > > >> From: *Volker Simonis* > >> > > >> > >> >> > > >> Date: Fri, Mar 31, 2017 at 10:53 AM > > >> Subject: Re: RFR (S) 8176580: [ppc, s390] CRC32C: wrong > > >> checksum result in some cases > > >> To: "Schmidt, Lutz" > >> > >> >> > > >> Cc: Andrew Haley > > >> >>, > > >> "hotspot-compiler-dev at openjdk.java.net > > >> > > >> > >> >" > > >> > >> > > >> > >> >> > > >> > > >> > > >> Ping... > > >> > > >> Can somebody please push this change? > > >> > > >> It's ppc64/s390x only but as a courtesy to the community it > > >> also fixes > > >> the CRC JTreg tests so unfortunately I still can't push it > > >> myself :) > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> > > >> On Tue, Mar 28, 2017 at 5:01 PM, Volker Simonis > > >> > > >> > >> >> wrote: > > >> > Hi Lutz, > > >> > > > >> > thanks a lot for fixing the test! > > >> > Your change looks good now. > > >> > > > >> > Because this touches shared (i.e. test) files, we still need > > >> a sponsor > > >> > so can somebody please sponsor this change? > > >> > > > >> > Thank you and best regards, > > >> > Volker > > >> > > > >> > > > >> > > > >> > On Fri, Mar 24, 2017 at 4:54 PM, Schmidt, Lutz > > >> > > >> >> > > >> wrote: > > >> >> Hi Volker, > > >> >> > > >> >> Sorry for letting you wait. Here is the final(?) webrev, > > >> containing all your requests for cleanup and improvements: > > >> >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ > > >> > > >> > >> > > > >> >> > > >> >> As before, the *.cpp files have not been modified. > > >> >> > > >> >> Best Regards, > > >> >> Lutz > > >> >> > > >> >> > > >> >> > > >> >> On 21/03/2017, 17:55, "Volker Simonis" > > >> > > >> > >> >> wrote: > > >> >> > > >> >> Hi Lutz, > > >> >> > > >> >> thanks a lot for updating the tests. I think they look > > >> much better now. > > >> >> > > >> >> There's just one more cleanup I'd like to propose. Can > > >> you please move > > >> >> the throw right into the check() function. Just make > > >> check() return > > >> >> void and throw from it if there's a mismatch between > > >> the computed and > > >> >> the expected result. I leave it up to you if you want > > >> to pass an extra > > >> >> error string to check() which will be printed in the > > >> case of an error. > > >> >> I personally don't think that's necessary as it will be > > >> evident from > > >> >> the stack trace which computation failed. > > >> >> > > >> >> Also the try/catch and rethrow in test_multi() isn't > > >> necessary. The > > >> >> test can be simply terminated by the initial exception. > > >> >> > > >> >> Thank you and best regards, > > >> >> Volker > > >> >> > > >> >> > > >> >> On Fri, Mar 17, 2017 at 10:03 PM, Schmidt, Lutz > > >> > > >> >> > > >> wrote: > > >> >> > Hi Volker, > > >> >> > > > >> >> > Thanks a lot for your valuable hints. > > >> >> > > > >> >> > I have worked some time on the Java test files: > > >> >> > TestCRC32.java and TestCRC32C.java are now > > >> identical as far as possible. > > >> >> > They now throw an exception, should any error be > > >> detected. > > >> >> > The ?reference CRC value? is now used in > > >> test_multi() as well. > > >> >> > The extra test runs have been removed again. > > >> >> > The test methodology is fixed: each result is > > >> tested against its reference. > > >> >> > The tests now detect the bug introduced with > > >> 8175368 and 8175369. > > >> >> > No issue is indicated when testing with 8176580. > > >> >> > I ran jcheck, and to the best of my ability and > > >> knowledge, there is no trailing whitespace. > > >> >> > All *.cpp files were left untouched! > > >> >> > > > >> >> > The next iteration of the webrev: > > >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ > > >> > > >> > >> > > > >> >> > > > >> >> > Best regards, > > >> >> > Lutz > > >> >> > > > >> >> > > > >> >> > Dr. Lutz Schmidt | SAP JVM | PI SAP CP Core | T: +49 > > >> (6227) 7-42834 > > >> > > >> >> > > > >> >> > > > >> >> > > > >> >> > On 16.03.17, 11:28, "Volker Simonis" > > >> > > >> > >> >> wrote: > > >> >> > > > >> >> > On Wed, Mar 15, 2017 at 5:55 PM, Schmidt, Lutz > > >> > > >> >> > > >> wrote: > > >> >> > > > > >> >> > > Hi Andrew, Volker, > > >> >> > > > > >> >> > > What do you think about these test enhancements? > > >> >> > > Webrev: > > >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ > > >> > > >> > >> > > > >> > > >> >> > > > > >> >> > > Please note: the cpp files in the webrev > > >> remained unchanged. > > >> >> > > > > >> >> > > I added some improvements (as I believe) to the > > >> TestCRC32(C).java files. > > >> >> > > > > >> >> > > In some more detail: > > >> >> > > The test now calculates a ?reference CRC > > >> value?, based on a java implementation of the CRC32 algorithm. > > >> This reference value is used to verify all other crc values, > > >> in particular during initialization and warmup. Three > > >> additional test runs check a non-zero offset with ?Xint, > > >> -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp > > >> -XX:+TieredCompilation (C1 + C2). > > >> >> > > > > >> >> > > > >> >> > Hi Lutz, > > >> >> > > > >> >> > thanks for updating the tests. I've had a closer > > >> look at the tests and > > >> >> > realized that they actually can never fail! The > > >> check() routine just > > >> >> > prints an error message but that will not let the > > >> test fail. So I > > >> >> > would suggest to throw a runtime exception in the > > >> check() routine > > >> >> > after the error message was printed. > > >> >> > > > >> >> > I also suggest to do the check during the normal > > >> test execution (i.e. > > >> >> > in test_multi()) so there's no need for extra > > >> test runs. > > >> >> > > > >> >> > Finally, the current test methodology in > > >> test_multi() is broken: > > >> >> > - it sets the reference by calling CRC from the > > >> interpreter which > > >> >> > won't work if the intrinsic is also used in the > > >> interpreter. > > >> >> > - it only compares the reference against the > > >> last computation of CRC > > >> >> > in the loop which will be the result of the C2 > > >> generated code. This > > >> >> > misses errors in C1. > > >> >> > > > >> >> > I suggest to use your new, pure Java > > >> implementation for the > > >> >> > computation of the reference result and compare > > >> the reference with the > > >> >> > result of calling CRC in every iteration of the > > >> loop so we really > > >> >> > check all possibilities from interpreter trough > > >> C1 to C2. > > >> >> > > > >> >> > Finally, can you please pay attention to not > > >> insert trailing > > >> >> > whitespace (there was some at line 88 in > > >> TestCRC32C.java). You can > > >> >> > easily verify this by running jcheck before > > >> creating the webrevs. > > >> >> > > > >> >> > Thanks, > > >> >> > Volker > > >> >> > > > >> >> > > > > >> >> > > Best regards, > > >> >> > > Lutz > > >> >> > > > > >> >> > > > > >> >> > > On 15.03.17, 11:50, "Volker Simonis" > > >> > > >> > >> >> wrote: > > >> >> > > > > >> >> > > On Tue, Mar 14, 2017 at 7:05 PM, Andrew > > >> Haley > > >> >> wrote: > > >> >> > > > On 14/03/17 13:12, Schmidt, Lutz wrote: > > >> >> > > > > > >> >> > > >> Yes, one might think of running a test > > >> suite subset multiple times > > >> >> > > >> with different parameters. In this case, > > >> -Xint and/or ?Xcomp were > > >> >> > > >> helpful. Forcing tests to run fully > > >> interpreted or fully compiled > > >> >> > > >> helps in cases where a certain function, > > >> e.g. an intrinsic, is > > >> >> > > >> invoked via distinct code paths. > > >> >> > > > > > >> >> > > > Right, so your patch should include that > > >> change to the test suite. > > >> >> > > > > > >> >> > > > > >> >> > > Hi Lutz, > > >> >> > > > > >> >> > > I agree with Andrew. We should really fix > > >> the tests such that they > > >> >> > > check the correctness of the intrinsics. > > >> >> > > > > >> >> > > This may be tricky if all three, the > > >> interpreter, the client and the > > >> >> > > server compiler use the same intrinsic > > >> implementation. You could > > >> >> > > either copy the pure Java implementation > > >> into the test so that you can > > >> >> > > compare the results of the intrinsic > > >> operation against it or you can > > >> >> > > switch them off in the compilers with > > >> >> > > "-XX:DisableIntrinsic=_updateBytesCRC32C > > >> >> > > > > >> -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and > > >> compare the > > >> >> > > results. Not sure which solution is more > > >> practical, but I would be > > >> >> > > really scared if we wouldn't have these test. > > >> >> > > > > >> >> > > Regards, > > >> >> > > Volker > > >> >> > > > > >> >> > > > Andrew. > > >> >> > > > > > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> > > >> > > >> > > > > > > > > > > > > > > From zoltan.majo at oracle.com Thu Apr 13 13:39:19 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 13 Apr 2017 15:39:19 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> Message-ID: Hi Volker, Hi Lutz, On 04/13/2017 03:25 PM, Volker Simonis wrote: > Hi Lutz, Zoltan, > > @Lutz, thanks for analyzing the problem! I actually didn't expected > that the efforts we put into fixing the tests will pay up that fast :) > > @Zoltan: I propose we split the test from the actual fix. I can push > the ppc64/s390x parts myself. That is fine with me. Just to clarify: Will you include the other test Lutz has modified (test/compiler/intrinsics/zip/TestCRC32.java) into your JDK 10 changeset? I can live with both options (i.e., (1) both tests pushed into JDK 9 with 8178720 and (2) *CRC32C -> JDK 9, CRC32 -> JDK 10). > > I opened the new prio 2 bug "8178720: CRC32C fails on old x86 hardware > without CLMUL support" for jdk9 Thank you. > and linked the reworked tests from Lutz' last webrev to it. I think > this is definitely something we should fix before jdk9 will be > released and the nfix should contain the new, fixed version of the > tests. Zoltan, can you please take care of this? Yes, I can. Just let me know which option from above you prefer. For the record: I'll add Lutz as a contributor when pushing the tests (if that's fine with you, Lutz). Best regards, Zoltan > > Thank you and best regards, > Volker > > [1] https://bugs.openjdk.java.net/browse/JDK-8178720 > > > On Thu, Apr 13, 2017 at 12:10 PM, Schmidt, Lutz > wrote: > > Hi Zoltan, > > I am now able to reproduce the problem. Calculated crc and > reference crc are exactly the same as in the log output you pasted > below. And the problem shows up on linux-x86_64 as well. > > Here is what?s happening: > The CRC32C implementation generates code depending on the CLMUL > cpu feature being available. On most machines @Oracle and @SAP, > this feature seems to be available ? except for one of your MacOS > test machines. > > To gain control over that feature, I have modified just one line > in src/cpu/x86/vm/vm_version_x86_64.hpp like this: > static bool supports_clmul() { return ((_features & > CPU_CLMUL) != 0) && UseNewCode; } > > The boolean UseNewCode is a command line parameter we use @SAP to > make experimental code switchable during development. With that > modification, I can force off the CLMUL feature at will. And > voila, here is what I get (linux-x86_64): > > lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java > -XX:+UseNewCode TestCRC32C_OpenJDK -m > updateBytesCRC32C: pclmulqdq = true. > testing 1050 cases ... > lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java > -XX:-UseNewCode TestCRC32C_OpenJDK -m > updateBytesCRC32C: pclmulqdq = false. > testing 1050 cases ... > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > iteration 0: offsets[0] = 0 sizes[30] = 1024 > Exception: java.lang.Exception: TestCRC32C Error > Exception in thread "main" java.lang.Exception: > java.lang.Exception: TestCRC32C Error > at > TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:306) > at TestCRC32C_OpenJDK.main(TestCRC32C_OpenJDK.java:74) > Caused by: java.lang.Exception: TestCRC32C Error > at > TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:298) > ... 1 more > lu0084 PrivSrc/TestCRC> > > Output on MacOS is the same. I did not try solaris-x86_64. > > The bug is in MacroAssembler::crc32c_ipl_alg2_alt2() or one of its > callees. I have not yet performed an in-depth analysis on what?s > going wrong, mainly because I am not a proven expert on x86 > machine code. > > So how do we proceed from here? Shouldn?t we file a separate bug > for this x86 issue? Should this webrev (8176580) be split up into > the (ppc, s390) chunk and a separate test bug webrev? Can you push > this webrev despite there is an (unrelated) JPRT failure? > > Thanks and best regards, > Lutz > > > > On 12.04.2017, 18:36, "hotspot-compiler-dev on behalf of Schmidt, > Lutz" on behalf > of lutz.schmidt at sap.com > wrote: > > Hi Zoltan, > > I?m not able to reproduce the problem as of now. I will try > out other (older) x86 machines tomorrow. Could be a problem in > fallback code when required vector instructions are not available. > > Can you please find out on what H/W (CPU in particular) the > tests are failing? > > Thanks, > Lutz > > > On 12.04.2017, 14:38, "Zolt?n Maj?" > wrote: > > Hi Lutz, > > > On 04/12/2017 02:14 PM, Schmidt, Lutz wrote: > > Hi Zoltan, > > > > First of all: thanks for trying to push! Second: sorry > for the problems you ran into. > > you are welcome and no problem, of course. > > > I do not have an immediate explanation for the failure ? > my dev machine is MacOS/x86_64. I will try to reproduce > immediately. For the time being: is there any log output that > could shed some light on the issue? > > Please find the output below (and sorry for not including > it before). > > Please let me know if you were able to reproduce the > problem (or not). > > Best regards, > > > Zoltan > > command: main -Xbatch compiler.intrinsics.zip.TestCRC32C -m > reason: User specified action: run > main/othervm/timeout=600 -Xbatch compiler.intrinsics.zip.TestCRC32C -m > Mode: othervm [/othervm specified] > elapsed time (seconds): 1.915 > configuration: > STDOUT: > testing 1050 cases ... > STDERR: > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > java.lang.Exception: TestCRC32C Error > at > compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218) > at > compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280) > at > compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at > java.base/java.lang.reflect.Method.invoke(Method.java:563) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at java.base/java.lang.Thread.run(Thread.java:844) > > JavaTest Message: Test threw exception: > java.lang.Exception: TestCRC32C Error > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.Exception: > TestCRC32C Error > > > > > > > Thanks, > > Lutz > > > > > > On 12.04.2017, 13:10, "hotspot-compiler-dev on behalf of > Zolt?n Maj?" on behalf > of zoltan.majo at oracle.com > wrote: > > > > P.S.: Forgot to mention: The problem does not > appear on any other x86_64 > > platform. > > > > On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > > > Hi Volker, > > > Hi Lutz, > > > > > > > > > yesterday I tried to push webrev.03 using JPRT. > Unfortunately, the > > > TestCRC32C.java test you've modified fails on Mac > OS X on x86_64. Do > > > you have an idea why that could be? > > > > > > Thank you! Best regards, > > > > > > > > > Zoltan > > > > > > On 04/11/2017 06:03 PM, Volker Simonis wrote: > > >> Thanks a lot Zoltan! > > >> > > >> > > >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? > > > >> >> wrote: > > >> > > >> Hi Volker, > > >> > > >> > > >> On 04/11/2017 03:34 PM, Volker Simonis wrote: > > >> > > >> > > >> Hi Zoltan, > > >> > > >> could you please be so kind to sponsor > this reviewed change > > >> for jdk10? > > >> > > >> > > >> yes, of course. I'll push it today. > > >> > > >> Best regards, > > >> > > >> > > >> Zoltan > > >> > > >> Initially we wanted to push it ourselves > because it was s390x > > >> only but now that we've also touched the > tests we need a > > >> sponsor. > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> ---------- Forwarded message ---------- > > >> From: *Volker Simonis* > > > >> > > > >> > > >> >>> > > >> Date: Fri, Mar 31, 2017 at 10:53 AM > > >> Subject: Re: RFR (S) 8176580: [ppc, > s390] CRC32C: wrong > > >> checksum result in some cases > > >> To: "Schmidt, Lutz" > > > >> > > > >> >>> > > >> Cc: Andrew Haley > > > >> >>>, > > >> "hotspot-compiler-dev at openjdk.java.net > > > >> > > > > >> > > > >> >>" > > >> > > >> > > > > >> > > > >> >>> > > >> > > >> > > >> Ping... > > >> > > >> Can somebody please push this change? > > >> > > >> It's ppc64/s390x only but as a courtesy > to the community it > > >> also fixes > > >> the CRC JTreg tests so unfortunately I > still can't push it > > >> myself :) > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> > > >> On Tue, Mar 28, 2017 at 5:01 PM, Volker > Simonis > > >> > > > >> > > >> >>> wrote: > > >> > Hi Lutz, > > >> > > > >> > thanks a lot for fixing the test! > > >> > Your change looks good now. > > >> > > > >> > Because this touches shared (i.e. > test) files, we still need > > >> a sponsor > > >> > so can somebody please sponsor this > change? > > >> > > > >> > Thank you and best regards, > > >> > Volker > > >> > > > >> > > > >> > > > >> > On Fri, Mar 24, 2017 at 4:54 PM, > Schmidt, Lutz > > >> > > > >> >>> > > >> wrote: > > >> >> Hi Volker, > > >> >> > > >> >> Sorry for letting you wait. Here is > the final(?) webrev, > > >> containing all your requests for cleanup > and improvements: > > >> >> > http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ > > > >> > > > > >> > > > >> > >> > > >> >> > > >> >> As before, the *.cpp files have not > been modified. > > >> >> > > >> >> Best Regards, > > >> >> Lutz > > >> >> > > >> >> > > >> >> > > >> >> On 21/03/2017, 17:55, "Volker Simonis" > > >> > > > >> > > >> >>> wrote: > > >> >> > > >> >> Hi Lutz, > > >> >> > > >> >> thanks a lot for updating the > tests. I think they look > > >> much better now. > > >> >> > > >> >> There's just one more cleanup I'd > like to propose. Can > > >> you please move > > >> >> the throw right into the check() > function. Just make > > >> check() return > > >> >> void and throw from it if there's > a mismatch between > > >> the computed and > > >> >> the expected result. I leave it > up to you if you want > > >> to pass an extra > > >> >> error string to check() which > will be printed in the > > >> case of an error. > > >> >> I personally don't think that's > necessary as it will be > > >> evident from > > >> >> the stack trace which computation > failed. > > >> >> > > >> >> Also the try/catch and rethrow in > test_multi() isn't > > >> necessary. The > > >> >> test can be simply terminated by > the initial exception. > > >> >> > > >> >> Thank you and best regards, > > >> >> Volker > > >> >> > > >> >> > > >> >> On Fri, Mar 17, 2017 at 10:03 PM, > Schmidt, Lutz > > >> > > > >> >>> > > >> wrote: > > >> >> > Hi Volker, > > >> >> > > > >> >> > Thanks a lot for your valuable > hints. > > >> >> > > > >> >> > I have worked some time on the > Java test files: > > >> >> > TestCRC32.java and > TestCRC32C.java are now > > >> identical as far as possible. > > >> >> > They now throw an exception, > should any error be > > >> detected. > > >> >> > The ?reference CRC value? is > now used in > > >> test_multi() as well. > > >> >> > The extra test runs have been > removed again. > > >> >> > The test methodology is fixed: > each result is > > >> tested against its reference. > > >> >> > The tests now detect the bug > introduced with > > >> 8175368 and 8175369. > > >> >> > No issue is indicated when > testing with 8176580. > > >> >> > I ran jcheck, and to the best > of my ability and > > >> knowledge, there is no trailing whitespace. > > >> >> > All *.cpp files were left > untouched! > > >> >> > > > >> >> > The next iteration of the webrev: > > >> > http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ > > > >> > > > > >> > > > >> > >> > > >> >> > > > >> >> > Best regards, > > >> >> > Lutz > > >> >> > > > >> >> > > > >> >> > Dr. Lutz Schmidt | SAP JVM | > PI SAP CP Core | T: +49 > > >> (6227) 7-42834 > > > >> > > >> >> > > > >> >> > > > >> >> > > > >> >> > On 16.03.17, 11:28, "Volker > Simonis" > > >> > > > >> > > >> >>> wrote: > > >> >> > > > >> >> > On Wed, Mar 15, 2017 at 5:55 > PM, Schmidt, Lutz > > >> > > > >> >>> > > >> wrote: > > >> >> > > > > >> >> > > Hi Andrew, Volker, > > >> >> > > > > >> >> > > What do you think about > these test enhancements? > > >> >> > > Webrev: > > >> > http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ > > > >> > > > > >> > > > >> > >> > > >> > > >> >> > > > > >> >> > > Please note: the cpp files > in the webrev > > >> remained unchanged. > > >> >> > > > > >> >> > > I added some improvements > (as I believe) to the > > >> TestCRC32(C).java files. > > >> >> > > > > >> >> > > In some more detail: > > >> >> > > The test now calculates a > ?reference CRC > > >> value?, based on a java implementation > of the CRC32 algorithm. > > >> This reference value is used to verify > all other crc values, > > >> in particular during initialization and > warmup. Three > > >> additional test runs check a non-zero > offset with ?Xint, > > >> -Xcomp -XX:-TieredCompilation (C2 only), > -Xcomp > > >> -XX:+TieredCompilation (C1 + C2). > > >> >> > > > > >> >> > > > >> >> > Hi Lutz, > > >> >> > > > >> >> > thanks for updating the tests. > I've had a closer > > >> look at the tests and > > >> >> > realized that they actually > can never fail! The > > >> check() routine just > > >> >> > prints an error message but > that will not let the > > >> test fail. So I > > >> >> > would suggest to throw a > runtime exception in the > > >> check() routine > > >> >> > after the error message was > printed. > > >> >> > > > >> >> > I also suggest to do the check > during the normal > > >> test execution (i.e. > > >> >> > in test_multi()) so there's no > need for extra > > >> test runs. > > >> >> > > > >> >> > Finally, the current test > methodology in > > >> test_multi() is broken: > > >> >> > - it sets the reference by > calling CRC from the > > >> interpreter which > > >> >> > won't work if the intrinsic is > also used in the > > >> interpreter. > > >> >> > - it only compares the > reference against the > > >> last computation of CRC > > >> >> > in the loop which will be the > result of the C2 > > >> generated code. This > > >> >> > misses errors in C1. > > >> >> > > > >> >> > I suggest to use your new, > pure Java > > >> implementation for the > > >> >> > computation of the reference > result and compare > > >> the reference with the > > >> >> > result of calling CRC in every > iteration of the > > >> loop so we really > > >> >> > check all possibilities from > interpreter trough > > >> C1 to C2. > > >> >> > > > >> >> > Finally, can you please pay > attention to not > > >> insert trailing > > >> >> > whitespace (there was some at > line 88 in > > >> TestCRC32C.java). You can > > >> >> > easily verify this by running > jcheck before > > >> creating the webrevs. > > >> >> > > > >> >> > Thanks, > > >> >> > Volker > > >> >> > > > >> >> > > > > >> >> > > Best regards, > > >> >> > > Lutz > > >> >> > > > > >> >> > > > > >> >> > > On 15.03.17, 11:50, "Volker > Simonis" > > >> > > > >> > > >> >>> wrote: > > >> >> > > > > >> >> > > On Tue, Mar 14, 2017 at > 7:05 PM, Andrew > > >> Haley > > > >> >>> wrote: > > >> >> > > > On 14/03/17 13:12, > Schmidt, Lutz wrote: > > >> >> > > > > > >> >> > > >> Yes, one might think > of running a test > > >> suite subset multiple times > > >> >> > > >> with different > parameters. In this case, > > >> -Xint and/or ?Xcomp were > > >> >> > > >> helpful. Forcing > tests to run fully > > >> interpreted or fully compiled > > >> >> > > >> helps in cases where > a certain function, > > >> e.g. an intrinsic, is > > >> >> > > >> invoked via distinct > code paths. > > >> >> > > > > > >> >> > > > Right, so your patch > should include that > > >> change to the test suite. > > >> >> > > > > > >> >> > > > > >> >> > > Hi Lutz, > > >> >> > > > > >> >> > > I agree with Andrew. We > should really fix > > >> the tests such that they > > >> >> > > check the correctness of > the intrinsics. > > >> >> > > > > >> >> > > This may be tricky if > all three, the > > >> interpreter, the client and the > > >> >> > > server compiler use the > same intrinsic > > >> implementation. You could > > >> >> > > either copy the pure > Java implementation > > >> into the test so that you can > > >> >> > > compare the results of > the intrinsic > > >> operation against it or you can > > >> >> > > switch them off in the > compilers with > > >> >> > > > "-XX:DisableIntrinsic=_updateBytesCRC32C > > >> >> > > > > >> > -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and > > >> compare the > > >> >> > > results. Not sure which > solution is more > > >> practical, but I would be > > >> >> > > really scared if we > wouldn't have these test. > > >> >> > > > > >> >> > > Regards, > > >> >> > > Volker > > >> >> > > > > >> >> > > > Andrew. > > >> >> > > > > > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> > > >> > > >> > > > > > > > > > > > > > > > From volker.simonis at gmail.com Thu Apr 13 14:22:43 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 13 Apr 2017 16:22:43 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> Message-ID: On Thu, Apr 13, 2017 at 3:39 PM, Zolt?n Maj? wrote: > Hi Volker, > Hi Lutz, > > > On 04/13/2017 03:25 PM, Volker Simonis wrote: > >> Hi Lutz, Zoltan, >> >> @Lutz, thanks for analyzing the problem! I actually didn't expected that >> the efforts we put into fixing the tests will pay up that fast :) >> >> @Zoltan: I propose we split the test from the actual fix. I can push the >> ppc64/s390x parts myself. >> > > That is fine with me. > > Just to clarify: Will you include the other test Lutz has modified > (test/compiler/intrinsics/zip/TestCRC32.java) into your JDK 10 changeset? > I can live with both options (i.e., (1) both tests pushed into JDK 9 with > 8178720 and (2) *CRC32C -> JDK 9, CRC32 -> JDK 10). > > I will only push the ppc64/s390x related fixes WITHOUT any tests (actually I'm still not allowed to push shared code as it must go through JPRT and there's still no access to JPRT for external committers :( > >> I opened the new prio 2 bug "8178720: CRC32C fails on old x86 hardware >> without CLMUL support" for jdk9 >> > > Thank you. > > and linked the reworked tests from Lutz' last webrev to it. I think this >> is definitely something we should fix before jdk9 will be released and the >> nfix should contain the new, fixed version of the tests. Zoltan, can you >> please take care of this? >> > > Yes, I can. Just let me know which option from above you prefer. > > For the record: I'll add Lutz as a contributor when pushing the tests (if > that's fine with you, Lutz). > > That's fine. Thanks! > Best regards, > > > Zoltan > > >> Thank you and best regards, >> Volker >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8178720 >> >> >> On Thu, Apr 13, 2017 at 12:10 PM, Schmidt, Lutz > > wrote: >> >> Hi Zoltan, >> >> I am now able to reproduce the problem. Calculated crc and >> reference crc are exactly the same as in the log output you pasted >> below. And the problem shows up on linux-x86_64 as well. >> >> Here is what?s happening: >> The CRC32C implementation generates code depending on the CLMUL >> cpu feature being available. On most machines @Oracle and @SAP, >> this feature seems to be available ? except for one of your MacOS >> test machines. >> >> To gain control over that feature, I have modified just one line >> in src/cpu/x86/vm/vm_version_x86_64.hpp like this: >> static bool supports_clmul() { return ((_features & >> CPU_CLMUL) != 0) && UseNewCode; } >> >> The boolean UseNewCode is a command line parameter we use @SAP to >> make experimental code switchable during development. With that >> modification, I can force off the CLMUL feature at will. And >> voila, here is what I get (linux-x86_64): >> >> lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java >> -XX:+UseNewCode TestCRC32C_OpenJDK -m >> updateBytesCRC32C: pclmulqdq = true. >> testing 1050 cases ... >> lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java >> -XX:-UseNewCode TestCRC32C_OpenJDK -m >> updateBytesCRC32C: pclmulqdq = false. >> testing 1050 cases ... >> ERROR: crc = 6f894393, crcReference = 2cdf6e8f >> iteration 0: offsets[0] = 0 sizes[30] = 1024 >> Exception: java.lang.Exception: TestCRC32C Error >> Exception in thread "main" java.lang.Exception: >> java.lang.Exception: TestCRC32C Error >> at >> TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:306) >> at TestCRC32C_OpenJDK.main(TestCRC32C_OpenJDK.java:74) >> Caused by: java.lang.Exception: TestCRC32C Error >> at >> TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:298) >> ... 1 more >> lu0084 PrivSrc/TestCRC> >> >> Output on MacOS is the same. I did not try solaris-x86_64. >> >> The bug is in MacroAssembler::crc32c_ipl_alg2_alt2() or one of its >> callees. I have not yet performed an in-depth analysis on what?s >> going wrong, mainly because I am not a proven expert on x86 >> machine code. >> >> So how do we proceed from here? Shouldn?t we file a separate bug >> for this x86 issue? Should this webrev (8176580) be split up into >> the (ppc, s390) chunk and a separate test bug webrev? Can you push >> this webrev despite there is an (unrelated) JPRT failure? >> >> Thanks and best regards, >> Lutz >> >> >> >> On 12.04.2017, 18:36, "hotspot-compiler-dev on behalf of Schmidt, >> Lutz" > on behalf >> of lutz.schmidt at sap.com > wrote: >> >> Hi Zoltan, >> >> I?m not able to reproduce the problem as of now. I will try >> out other (older) x86 machines tomorrow. Could be a problem in >> fallback code when required vector instructions are not available. >> >> Can you please find out on what H/W (CPU in particular) the >> tests are failing? >> >> Thanks, >> Lutz >> >> >> On 12.04.2017, 14:38, "Zolt?n Maj?" > > wrote: >> >> Hi Lutz, >> >> >> On 04/12/2017 02:14 PM, Schmidt, Lutz wrote: >> > Hi Zoltan, >> > >> > First of all: thanks for trying to push! Second: sorry >> for the problems you ran into. >> >> you are welcome and no problem, of course. >> >> > I do not have an immediate explanation for the failure ? >> my dev machine is MacOS/x86_64. I will try to reproduce >> immediately. For the time being: is there any log output that >> could shed some light on the issue? >> >> Please find the output below (and sorry for not including >> it before). >> >> Please let me know if you were able to reproduce the >> problem (or not). >> >> Best regards, >> >> >> Zoltan >> >> command: main -Xbatch compiler.intrinsics.zip.TestCRC32C -m >> reason: User specified action: run >> main/othervm/timeout=600 -Xbatch compiler.intrinsics.zip.TestCRC32C >> -m >> Mode: othervm [/othervm specified] >> elapsed time (seconds): 1.915 >> configuration: >> STDOUT: >> testing 1050 cases ... >> STDERR: >> ERROR: crc = 6f894393, crcReference = 2cdf6e8f >> java.lang.Exception: TestCRC32C Error >> at >> compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218) >> at >> compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280) >> at >> compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >> ke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >> ke(NativeMethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >> invoke(DelegatingMethodAccessorImpl.java:43) >> at >> java.base/java.lang.reflect.Method.invoke(Method.java:563) >> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run( >> MainWrapper.java:110) >> at java.base/java.lang.Thread.run(Thread.java:844) >> >> JavaTest Message: Test threw exception: >> java.lang.Exception: TestCRC32C Error >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.Exception: >> TestCRC32C Error >> >> >> >> > >> > Thanks, >> > Lutz >> > >> > >> > On 12.04.2017, 13:10, "hotspot-compiler-dev on behalf of >> Zolt?n Maj?" > on behalf >> of zoltan.majo at oracle.com > wrote: >> > >> > P.S.: Forgot to mention: The problem does not >> appear on any other x86_64 >> > platform. >> > >> > On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: >> > > Hi Volker, >> > > Hi Lutz, >> > > >> > > >> > > yesterday I tried to push webrev.03 using JPRT. >> Unfortunately, the >> > > TestCRC32C.java test you've modified fails on Mac >> OS X on x86_64. Do >> > > you have an idea why that could be? >> > > >> > > Thank you! Best regards, >> > > >> > > >> > > Zoltan >> > > >> > > On 04/11/2017 06:03 PM, Volker Simonis wrote: >> > >> Thanks a lot Zoltan! >> > >> >> > >> >> > >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? >> >> > >> > >> >> wrote: >> > >> >> > >> Hi Volker, >> > >> >> > >> >> > >> On 04/11/2017 03:34 PM, Volker Simonis wrote: >> > >> >> > >> >> > >> Hi Zoltan, >> > >> >> > >> could you please be so kind to sponsor >> this reviewed change >> > >> for jdk10? >> > >> >> > >> >> > >> yes, of course. I'll push it today. >> > >> >> > >> Best regards, >> > >> >> > >> >> > >> Zoltan >> > >> >> > >> Initially we wanted to push it ourselves >> because it was s390x >> > >> only but now that we've also touched the >> tests we need a >> > >> sponsor. >> > >> >> > >> Thank you and best regards, >> > >> Volker >> > >> >> > >> ---------- Forwarded message ---------- >> > >> From: *Volker Simonis* >> >> > >> > > >> > >> > >> > >> > >>> >> > >> Date: Fri, Mar 31, 2017 at 10:53 AM >> > >> Subject: Re: RFR (S) 8176580: [ppc, >> s390] CRC32C: wrong >> > >> checksum result in some cases >> > >> To: "Schmidt, Lutz" >> >> > >> > > > >> >> > >> > >>> >> > >> Cc: Andrew Haley > > > >> > >> > > >>>, >> > >> "hotspot-compiler-dev at openjdk.java.net >> >> > >> > penjdk.java.net >> > >> > >> > penjdk.java.net >> >> > >> > >>" >> > >> > >> > >> > penjdk.java.net >> > >> > >> > penjdk.java.net >> >> > >> > >>> >> > >> >> > >> >> > >> Ping... >> > >> >> > >> Can somebody please push this change? >> > >> >> > >> It's ppc64/s390x only but as a courtesy >> to the community it >> > >> also fixes >> > >> the CRC JTreg tests so unfortunately I >> still can't push it >> > >> myself :) >> > >> >> > >> Thank you and best regards, >> > >> Volker >> > >> >> > >> >> > >> On Tue, Mar 28, 2017 at 5:01 PM, Volker >> Simonis >> > >> > > > >> > >> > >> > >> > >>> wrote: >> > >> > Hi Lutz, >> > >> > >> > >> > thanks a lot for fixing the test! >> > >> > Your change looks good now. >> > >> > >> > >> > Because this touches shared (i.e. >> test) files, we still need >> > >> a sponsor >> > >> > so can somebody please sponsor this >> change? >> > >> > >> > >> > Thank you and best regards, >> > >> > Volker >> > >> > >> > >> > >> > >> > >> > >> > On Fri, Mar 24, 2017 at 4:54 PM, >> Schmidt, Lutz >> > >> > > > >> > >> > > >>> >> > >> wrote: >> > >> >> Hi Volker, >> > >> >> >> > >> >> Sorry for letting you wait. Here is >> the final(?) webrev, >> > >> containing all your requests for cleanup >> and improvements: >> > >> >> >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ >> >> > >> >> > > >> > >> >> > >> > >> >> > >> >> > >> >> >> > >> >> As before, the *.cpp files have not >> been modified. >> > >> >> >> > >> >> Best Regards, >> > >> >> Lutz >> > >> >> >> > >> >> >> > >> >> >> > >> >> On 21/03/2017, 17:55, "Volker Simonis" >> > >> > > > >> > >> > >> > >> > >>> wrote: >> > >> >> >> > >> >> Hi Lutz, >> > >> >> >> > >> >> thanks a lot for updating the >> tests. I think they look >> > >> much better now. >> > >> >> >> > >> >> There's just one more cleanup I'd >> like to propose. Can >> > >> you please move >> > >> >> the throw right into the check() >> function. Just make >> > >> check() return >> > >> >> void and throw from it if there's >> a mismatch between >> > >> the computed and >> > >> >> the expected result. I leave it >> up to you if you want >> > >> to pass an extra >> > >> >> error string to check() which >> will be printed in the >> > >> case of an error. >> > >> >> I personally don't think that's >> necessary as it will be >> > >> evident from >> > >> >> the stack trace which computation >> failed. >> > >> >> >> > >> >> Also the try/catch and rethrow in >> test_multi() isn't >> > >> necessary. The >> > >> >> test can be simply terminated by >> the initial exception. >> > >> >> >> > >> >> Thank you and best regards, >> > >> >> Volker >> > >> >> >> > >> >> >> > >> >> On Fri, Mar 17, 2017 at 10:03 PM, >> Schmidt, Lutz >> > >> > > > >> > >> > > >>> >> > >> wrote: >> > >> >> > Hi Volker, >> > >> >> > >> > >> >> > Thanks a lot for your valuable >> hints. >> > >> >> > >> > >> >> > I have worked some time on the >> Java test files: >> > >> >> > TestCRC32.java and >> TestCRC32C.java are now >> > >> identical as far as possible. >> > >> >> > They now throw an exception, >> should any error be >> > >> detected. >> > >> >> > The ?reference CRC value? is >> now used in >> > >> test_multi() as well. >> > >> >> > The extra test runs have been >> removed again. >> > >> >> > The test methodology is fixed: >> each result is >> > >> tested against its reference. >> > >> >> > The tests now detect the bug >> introduced with >> > >> 8175368 and 8175369. >> > >> >> > No issue is indicated when >> testing with 8176580. >> > >> >> > I ran jcheck, and to the best >> of my ability and >> > >> knowledge, there is no trailing whitespace. >> > >> >> > All *.cpp files were left >> untouched! >> > >> >> > >> > >> >> > The next iteration of the webrev: >> > >> >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ >> >> > >> >> > > >> > >> >> > >> > >> >> > >> >> > >> >> > >> > >> >> > Best regards, >> > >> >> > Lutz >> > >> >> > >> > >> >> > >> > >> >> > Dr. Lutz Schmidt | SAP JVM | >> PI SAP CP Core | T: +49 >> > >> (6227) 7-42834 >> >> > >> >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > On 16.03.17, 11:28, "Volker >> Simonis" >> > >> > > > >> > >> > >> > >> > >>> wrote: >> > >> >> > >> > >> >> > On Wed, Mar 15, 2017 at 5:55 >> PM, Schmidt, Lutz >> > >> > > > >> > >> > > >>> >> > >> wrote: >> > >> >> > > >> > >> >> > > Hi Andrew, Volker, >> > >> >> > > >> > >> >> > > What do you think about >> these test enhancements? >> > >> >> > > Webrev: >> > >> >> http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ >> >> > >> >> > > >> > >> >> > >> > >> >> > >> >> > >> >> > >> >> > > >> > >> >> > > Please note: the cpp files >> in the webrev >> > >> remained unchanged. >> > >> >> > > >> > >> >> > > I added some improvements >> (as I believe) to the >> > >> TestCRC32(C).java files. >> > >> >> > > >> > >> >> > > In some more detail: >> > >> >> > > The test now calculates a >> ?reference CRC >> > >> value?, based on a java implementation >> of the CRC32 algorithm. >> > >> This reference value is used to verify >> all other crc values, >> > >> in particular during initialization and >> warmup. Three >> > >> additional test runs check a non-zero >> offset with ?Xint, >> > >> -Xcomp -XX:-TieredCompilation (C2 only), >> -Xcomp >> > >> -XX:+TieredCompilation (C1 + C2). >> > >> >> > > >> > >> >> > >> > >> >> > Hi Lutz, >> > >> >> > >> > >> >> > thanks for updating the tests. >> I've had a closer >> > >> look at the tests and >> > >> >> > realized that they actually >> can never fail! The >> > >> check() routine just >> > >> >> > prints an error message but >> that will not let the >> > >> test fail. So I >> > >> >> > would suggest to throw a >> runtime exception in the >> > >> check() routine >> > >> >> > after the error message was >> printed. >> > >> >> > >> > >> >> > I also suggest to do the check >> during the normal >> > >> test execution (i.e. >> > >> >> > in test_multi()) so there's no >> need for extra >> > >> test runs. >> > >> >> > >> > >> >> > Finally, the current test >> methodology in >> > >> test_multi() is broken: >> > >> >> > - it sets the reference by >> calling CRC from the >> > >> interpreter which >> > >> >> > won't work if the intrinsic is >> also used in the >> > >> interpreter. >> > >> >> > - it only compares the >> reference against the >> > >> last computation of CRC >> > >> >> > in the loop which will be the >> result of the C2 >> > >> generated code. This >> > >> >> > misses errors in C1. >> > >> >> > >> > >> >> > I suggest to use your new, >> pure Java >> > >> implementation for the >> > >> >> > computation of the reference >> result and compare >> > >> the reference with the >> > >> >> > result of calling CRC in every >> iteration of the >> > >> loop so we really >> > >> >> > check all possibilities from >> interpreter trough >> > >> C1 to C2. >> > >> >> > >> > >> >> > Finally, can you please pay >> attention to not >> > >> insert trailing >> > >> >> > whitespace (there was some at >> line 88 in >> > >> TestCRC32C.java). You can >> > >> >> > easily verify this by running >> jcheck before >> > >> creating the webrevs. >> > >> >> > >> > >> >> > Thanks, >> > >> >> > Volker >> > >> >> > >> > >> >> > > >> > >> >> > > Best regards, >> > >> >> > > Lutz >> > >> >> > > >> > >> >> > > >> > >> >> > > On 15.03.17, 11:50, "Volker >> Simonis" >> > >> > > > >> > >> > >> > >> > >>> wrote: >> > >> >> > > >> > >> >> > > On Tue, Mar 14, 2017 at >> 7:05 PM, Andrew >> > >> Haley > > > >> > >> > > >>> wrote: >> > >> >> > > > On 14/03/17 13:12, >> Schmidt, Lutz wrote: >> > >> >> > > > >> > >> >> > > >> Yes, one might think >> of running a test >> > >> suite subset multiple times >> > >> >> > > >> with different >> parameters. In this case, >> > >> -Xint and/or ?Xcomp were >> > >> >> > > >> helpful. Forcing >> tests to run fully >> > >> interpreted or fully compiled >> > >> >> > > >> helps in cases where >> a certain function, >> > >> e.g. an intrinsic, is >> > >> >> > > >> invoked via distinct >> code paths. >> > >> >> > > > >> > >> >> > > > Right, so your patch >> should include that >> > >> change to the test suite. >> > >> >> > > > >> > >> >> > > >> > >> >> > > Hi Lutz, >> > >> >> > > >> > >> >> > > I agree with Andrew. We >> should really fix >> > >> the tests such that they >> > >> >> > > check the correctness of >> the intrinsics. >> > >> >> > > >> > >> >> > > This may be tricky if >> all three, the >> > >> interpreter, the client and the >> > >> >> > > server compiler use the >> same intrinsic >> > >> implementation. You could >> > >> >> > > either copy the pure >> Java implementation >> > >> into the test so that you can >> > >> >> > > compare the results of >> the intrinsic >> > >> operation against it or you can >> > >> >> > > switch them off in the >> compilers with >> > >> >> > > >> "-XX:DisableIntrinsic=_updateBytesCRC32C >> > >> >> > > >> > >> >> -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and >> > >> compare the >> > >> >> > > results. Not sure which >> solution is more >> > >> practical, but I would be >> > >> >> > > really scared if we >> wouldn't have these test. >> > >> >> > > >> > >> >> > > Regards, >> > >> >> > > Volker >> > >> >> > > >> > >> >> > > > Andrew. >> > >> >> > > > >> > >> >> > > >> > >> >> > > >> > >> >> > >> > >> >> > >> > >> >> >> > >> >> >> > >> >> > >> >> > >> >> > > >> > >> > >> > >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Thu Apr 13 14:28:31 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 13 Apr 2017 16:28:31 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> Message-ID: Hi Volker, On 04/13/2017 04:22 PM, Volker Simonis wrote: > On Thu, Apr 13, 2017 at 3:39 PM, Zolt?n Maj? > wrote: > > Hi Volker, > Hi Lutz, > > > On 04/13/2017 03:25 PM, Volker Simonis wrote: > > Hi Lutz, Zoltan, > > @Lutz, thanks for analyzing the problem! I actually didn't > expected that the efforts we put into fixing the tests will > pay up that fast :) > > @Zoltan: I propose we split the test from the actual fix. I > can push the ppc64/s390x parts myself. > > > That is fine with me. > > Just to clarify: Will you include the other test Lutz has modified > (test/compiler/intrinsics/zip/TestCRC32.java) into your JDK 10 > changeset? I can live with both options (i.e., (1) both tests > pushed into JDK 9 with 8178720 and (2) *CRC32C -> JDK 9, CRC32 -> > JDK 10). > > > I will only push the ppc64/s390x related fixes WITHOUT any tests > (actually I'm still not allowed to push shared code as it must go > through JPRT and there's still no access to JPRT for external > committers :( Thanks for clarifying. I was confused because at one place you used singular ("test") and at two other places you used plural ("tests"). If you were to go with (2) I would have offered my help with sponsoring (that's the only way I can help you at the moment, unfortunately). I'll take care of both tests then. Best regards, Zoltan > > I opened the new prio 2 bug "8178720: CRC32C fails on old x86 > hardware without CLMUL support" for jdk9 > > > Thank you. > > and linked the reworked tests from Lutz' last webrev to it. I > think this is definitely something we should fix before jdk9 > will be released and the nfix should contain the new, fixed > version of the tests. Zoltan, can you please take care of this? > > > Yes, I can. Just let me know which option from above you prefer. > > For the record: I'll add Lutz as a contributor when pushing the > tests (if that's fine with you, Lutz). > > > That's fine. Thanks! > > Best regards, > > > Zoltan > > > Thank you and best regards, > Volker > > [1] https://bugs.openjdk.java.net/browse/JDK-8178720 > > > > On Thu, Apr 13, 2017 at 12:10 PM, Schmidt, Lutz > > >> > wrote: > > Hi Zoltan, > > I am now able to reproduce the problem. Calculated crc and > reference crc are exactly the same as in the log output > you pasted > below. And the problem shows up on linux-x86_64 as well. > > Here is what?s happening: > The CRC32C implementation generates code depending on the > CLMUL > cpu feature being available. On most machines @Oracle and > @SAP, > this feature seems to be available ? except for one of > your MacOS > test machines. > > To gain control over that feature, I have modified just > one line > in src/cpu/x86/vm/vm_version_x86_64.hpp like this: > static bool supports_clmul() { return ((_features & > CPU_CLMUL) != 0) && UseNewCode; } > > The boolean UseNewCode is a command line parameter we use > @SAP to > make experimental code switchable during development. With > that > modification, I can force off the CLMUL feature at will. And > voila, here is what I get (linux-x86_64): > > lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java > -XX:+UseNewCode TestCRC32C_OpenJDK -m > updateBytesCRC32C: pclmulqdq = true. > testing 1050 cases ... > lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java > -XX:-UseNewCode TestCRC32C_OpenJDK -m > updateBytesCRC32C: pclmulqdq = false. > testing 1050 cases ... > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > iteration 0: offsets[0] = 0 sizes[30] = 1024 > Exception: java.lang.Exception: TestCRC32C Error > Exception in thread "main" java.lang.Exception: > java.lang.Exception: TestCRC32C Error > at > TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:306) > at > TestCRC32C_OpenJDK.main(TestCRC32C_OpenJDK.java:74) > Caused by: java.lang.Exception: TestCRC32C Error > at > TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:298) > ... 1 more > lu0084 PrivSrc/TestCRC> > > Output on MacOS is the same. I did not try solaris-x86_64. > > The bug is in MacroAssembler::crc32c_ipl_alg2_alt2() or > one of its > callees. I have not yet performed an in-depth analysis on > what?s > going wrong, mainly because I am not a proven expert on x86 > machine code. > > So how do we proceed from here? Shouldn?t we file a > separate bug > for this x86 issue? Should this webrev (8176580) be split > up into > the (ppc, s390) chunk and a separate test bug webrev? Can > you push > this webrev despite there is an (unrelated) JPRT failure? > > Thanks and best regards, > Lutz > > > > On 12.04.2017, 18:36, "hotspot-compiler-dev on behalf of > Schmidt, > Lutz" > > on behalf > of lutz.schmidt at sap.com > >> > wrote: > > Hi Zoltan, > > I?m not able to reproduce the problem as of now. I > will try > out other (older) x86 machines tomorrow. Could be a problem in > fallback code when required vector instructions are not > available. > > Can you please find out on what H/W (CPU in > particular) the > tests are failing? > > Thanks, > Lutz > > > On 12.04.2017, 14:38, "Zolt?n Maj?" > > >> wrote: > > Hi Lutz, > > > On 04/12/2017 02:14 PM, Schmidt, Lutz wrote: > > Hi Zoltan, > > > > First of all: thanks for trying to push! Second: > sorry > for the problems you ran into. > > you are welcome and no problem, of course. > > > I do not have an immediate explanation for the > failure ? > my dev machine is MacOS/x86_64. I will try to reproduce > immediately. For the time being: is there any log output that > could shed some light on the issue? > > Please find the output below (and sorry for not > including > it before). > > Please let me know if you were able to reproduce the > problem (or not). > > Best regards, > > > Zoltan > > command: main -Xbatch > compiler.intrinsics.zip.TestCRC32C -m > reason: User specified action: run > main/othervm/timeout=600 -Xbatch > compiler.intrinsics.zip.TestCRC32C -m > Mode: othervm [/othervm specified] > elapsed time (seconds): 1.915 > configuration: > STDOUT: > testing 1050 cases ... > STDERR: > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > java.lang.Exception: TestCRC32C Error > at > compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218) > at > > compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280) > at > compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74) > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at > java.base/java.lang.reflect.Me > thod.invoke(Method.java:563) > at > > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at > java.base/java.lang.Thread.run(Thread.java:844) > > JavaTest Message: Test threw exception: > java.lang.Exception: TestCRC32C Error > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: > java.lang.Exception: > TestCRC32C Error > > > > > > > Thanks, > > Lutz > > > > > > On 12.04.2017, 13:10, "hotspot-compiler-dev on > behalf of > Zolt?n Maj?" > > > on behalf > of zoltan.majo at oracle.com > >> wrote: > > > > P.S.: Forgot to mention: The problem does not > appear on any other x86_64 > > platform. > > > > On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > > > Hi Volker, > > > Hi Lutz, > > > > > > > > > yesterday I tried to push webrev.03 using > JPRT. > Unfortunately, the > > > TestCRC32C.java test you've modified > fails on Mac > OS X on x86_64. Do > > > you have an idea why that could be? > > > > > > Thank you! Best regards, > > > > > > > > > Zoltan > > > > > > On 04/11/2017 06:03 PM, Volker Simonis wrote: > > >> Thanks a lot Zoltan! > > >> > > >> > > >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? > > > > > >> > > >>> wrote: > > >> > > >> Hi Volker, > > >> > > >> > > >> On 04/11/2017 03:34 PM, Volker > Simonis wrote: > > >> > > >> > > >> Hi Zoltan, > > >> > > >> could you please be so kind to > sponsor > this reviewed change > > >> for jdk10? > > >> > > >> > > >> yes, of course. I'll push it today. > > >> > > >> Best regards, > > >> > > >> > > >> Zoltan > > >> > > >> Initially we wanted to push it > ourselves > because it was s390x > > >> only but now that we've also > touched the > tests we need a > > >> sponsor. > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> ---------- Forwarded message > ---------- > > >> From: *Volker Simonis* > > > > > >> > >> > > >> > > > > >> > >>>> > > >> Date: Fri, Mar 31, 2017 at 10:53 AM > > >> Subject: Re: RFR (S) 8176580: [ppc, > s390] CRC32C: wrong > > >> checksum result in some cases > > >> To: "Schmidt, Lutz" > > > > > >> > >> > > > > > >> > >>>> > > >> Cc: Andrew Haley > > > > >> > > >> > > > > >>>>, > > >> > "hotspot-compiler-dev at openjdk.java.net > > > > > >> > > >> > > >> > > > > > >> > > >>>" > > >> > > > > > >> > > >> > > >> > > > > > >> > > >>>> > > >> > > >> > > >> Ping... > > >> > > >> Can somebody please push this > change? > > >> > > >> It's ppc64/s390x only but as a > courtesy > to the community it > > >> also fixes > > >> the CRC JTreg tests so > unfortunately I > still can't push it > > >> myself :) > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> > > >> On Tue, Mar 28, 2017 at 5:01 PM, > Volker > Simonis > > >> > > > > >> > > >> > > > > >> > >>>> wrote: > > >> > Hi Lutz, > > >> > > > >> > thanks a lot for fixing the test! > > >> > Your change looks good now. > > >> > > > >> > Because this touches shared (i.e. > test) files, we still need > > >> a sponsor > > >> > so can somebody please sponsor > this > change? > > >> > > > >> > Thank you and best regards, > > >> > Volker > > >> > > > >> > > > >> > > > >> > On Fri, Mar 24, 2017 at 4:54 PM, > Schmidt, Lutz > > >> > > > >> > > >> > > > >>>> > > >> wrote: > > >> >> Hi Volker, > > >> >> > > >> >> Sorry for letting you wait. > Here is > the final(?) webrev, > > >> containing all your requests for > cleanup > and improvements: > > >> >> > http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ > > > > > >> > > >> > > >> > > > > > >> > > >>> > > >> >> > > >> >> As before, the *.cpp files > have not > been modified. > > >> >> > > >> >> Best Regards, > > >> >> Lutz > > >> >> > > >> >> > > >> >> > > >> >> On 21/03/2017, 17:55, "Volker > Simonis" > > >> > > > > >> > > >> > > > > >> > >>>> wrote: > > >> >> > > >> >> Hi Lutz, > > >> >> > > >> >> thanks a lot for updating the > tests. I think they look > > >> much better now. > > >> >> > > >> >> There's just one more > cleanup I'd > like to propose. Can > > >> you please move > > >> >> the throw right into the check() > function. Just make > > >> check() return > > >> >> void and throw from it if > there's > a mismatch between > > >> the computed and > > >> >> the expected result. I leave it > up to you if you want > > >> to pass an extra > > >> >> error string to check() which > will be printed in the > > >> case of an error. > > >> >> I personally don't think that's > necessary as it will be > > >> evident from > > >> >> the stack trace which > computation > failed. > > >> >> > > >> >> Also the try/catch and > rethrow in > test_multi() isn't > > >> necessary. The > > >> >> test can be simply terminated by > the initial exception. > > >> >> > > >> >> Thank you and best regards, > > >> >> Volker > > >> >> > > >> >> > > >> >> On Fri, Mar 17, 2017 at > 10:03 PM, > Schmidt, Lutz > > >> > > > >> > > >> > > > >>>> > > >> wrote: > > >> >> > Hi Volker, > > >> >> > > > >> >> > Thanks a lot for your valuable > hints. > > >> >> > > > >> >> > I have worked some time on the > Java test files: > > >> >> > TestCRC32.java and > TestCRC32C.java are now > > >> identical as far as possible. > > >> >> > They now throw an exception, > should any error be > > >> detected. > > >> >> > The ?reference CRC value? is > now used in > > >> test_multi() as well. > > >> >> > The extra test runs have been > removed again. > > >> >> > The test methodology is > fixed: > each result is > > >> tested against its reference. > > >> >> > The tests now detect the bug > introduced with > > >> 8175368 and 8175369. > > >> >> > No issue is indicated when > testing with 8176580. > > >> >> > I ran jcheck, and to the > best > of my ability and > > >> knowledge, there is no trailing > whitespace. > > >> >> > All *.cpp files were left > untouched! > > >> >> > > > >> >> > The next iteration of the > webrev: > > >> > http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ > > > > > >> > > >> > > >> > > > > > >> > > >>> > > >> >> > > > >> >> > Best regards, > > >> >> > Lutz > > >> >> > > > >> >> > > > >> >> > Dr. Lutz Schmidt | SAP JVM | > PI SAP CP Core | T: +49 > > >> (6227) 7-42834 > > > > >> > > >> >> > > > >> >> > > > >> >> > > > >> >> > On 16.03.17, 11:28, "Volker > Simonis" > > >> > > > > >> > > >> > > > > >> > >>>> wrote: > > >> >> > > > >> >> > On Wed, Mar 15, 2017 at 5:55 > PM, Schmidt, Lutz > > >> > > > >> > > >> > > > >>>> > > >> wrote: > > >> >> > > > > >> >> > > Hi Andrew, Volker, > > >> >> > > > > >> >> > > What do you think about > these test enhancements? > > >> >> > > Webrev: > > >> > http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ > > > > > >> > > >> > > >> > > > > > >> > > >>> > > >> > > >> >> > > > > >> >> > > Please note: the cpp files > in the webrev > > >> remained unchanged. > > >> >> > > > > >> >> > > I added some improvements > (as I believe) to the > > >> TestCRC32(C).java files. > > >> >> > > > > >> >> > > In some more detail: > > >> >> > > The test now calculates a > ?reference CRC > > >> value?, based on a java > implementation > of the CRC32 algorithm. > > >> This reference value is used to > verify > all other crc values, > > >> in particular during > initialization and > warmup. Three > > >> additional test runs check a > non-zero > offset with ?Xint, > > >> -Xcomp -XX:-TieredCompilation > (C2 only), > -Xcomp > > >> -XX:+TieredCompilation (C1 + C2). > > >> >> > > > > >> >> > > > >> >> > Hi Lutz, > > >> >> > > > >> >> > thanks for updating the > tests. > I've had a closer > > >> look at the tests and > > >> >> > realized that they actually > can never fail! The > > >> check() routine just > > >> >> > prints an error message but > that will not let the > > >> test fail. So I > > >> >> > would suggest to throw a > runtime exception in the > > >> check() routine > > >> >> > after the error message was > printed. > > >> >> > > > >> >> > I also suggest to do the > check > during the normal > > >> test execution (i.e. > > >> >> > in test_multi()) so > there's no > need for extra > > >> test runs. > > >> >> > > > >> >> > Finally, the current test > methodology in > > >> test_multi() is broken: > > >> >> > - it sets the reference by > calling CRC from the > > >> interpreter which > > >> >> > won't work if the > intrinsic is > also used in the > > >> interpreter. > > >> >> > - it only compares the > reference against the > > >> last computation of CRC > > >> >> > in the loop which will be the > result of the C2 > > >> generated code. This > > >> >> > misses errors in C1. > > >> >> > > > >> >> > I suggest to use your new, > pure Java > > >> implementation for the > > >> >> > computation of the reference > result and compare > > >> the reference with the > > >> >> > result of calling CRC in > every > iteration of the > > >> loop so we really > > >> >> > check all possibilities from > interpreter trough > > >> C1 to C2. > > >> >> > > > >> >> > Finally, can you please pay > attention to not > > >> insert trailing > > >> >> > whitespace (there was some at > line 88 in > > >> TestCRC32C.java). You can > > >> >> > easily verify this by running > jcheck before > > >> creating the webrevs. > > >> >> > > > >> >> > Thanks, > > >> >> > Volker > > >> >> > > > >> >> > > > > >> >> > > Best regards, > > >> >> > > Lutz > > >> >> > > > > >> >> > > > > >> >> > > On 15.03.17, 11:50, "Volker > Simonis" > > >> > > > > >> > > >> > > > > >> > >>>> wrote: > > >> >> > > > > >> >> > > On Tue, Mar 14, 2017 at > 7:05 PM, Andrew > > >> Haley > > > > >> > > >> > > > > >>>> wrote: > > >> >> > > > On 14/03/17 13:12, > Schmidt, Lutz wrote: > > >> >> > > > > > >> >> > > >> Yes, one might think > of running a test > > >> suite subset multiple times > > >> >> > > >> with different > parameters. In this case, > > >> -Xint and/or ?Xcomp were > > >> >> > > >> helpful. Forcing > tests to run fully > > >> interpreted or fully compiled > > >> >> > > >> helps in cases where > a certain function, > > >> e.g. an intrinsic, is > > >> >> > > >> invoked via distinct > code paths. > > >> >> > > > > > >> >> > > > Right, so your patch > should include that > > >> change to the test suite. > > >> >> > > > > > >> >> > > > > >> >> > > Hi Lutz, > > >> >> > > > > >> >> > > I agree with Andrew. We > should really fix > > >> the tests such that they > > >> >> > > check the > correctness of > the intrinsics. > > >> >> > > > > >> >> > > This may be tricky if > all three, the > > >> interpreter, the client and the > > >> >> > > server compiler use the > same intrinsic > > >> implementation. You could > > >> >> > > either copy the pure > Java implementation > > >> into the test so that you can > > >> >> > > compare the results of > the intrinsic > > >> operation against it or you can > > >> >> > > switch them off in the > compilers with > > >> >> > > > "-XX:DisableIntrinsic=_updateBytesCRC32C > > >> >> > > > > >> > -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and > > >> compare the > > >> >> > > results. Not sure which > solution is more > > >> practical, but I would be > > >> >> > > really scared if we > wouldn't have these test. > > >> >> > > > > >> >> > > Regards, > > >> >> > > Volker > > >> >> > > > > >> >> > > > Andrew. > > >> >> > > > > > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > From zoltan.majo at oracle.com Thu Apr 13 14:54:21 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 13 Apr 2017 16:54:21 +0200 Subject: [9] RFR (S) 8178723: Workaround for failure of CRC32C intrinsic on x86 machines without CLMUL support (JDK-8178720) Message-ID: <1e62816d-f893-2883-e86a-0b4e68557b28@oracle.com> Hi, please review the following fix for 8178723. (8178723 is a workaround for 8178720.) https://bugs.openjdk.java.net/browse/JDK-8178723 http://cr.openjdk.java.net/~zmajo/8178723/webrev.00/ The problem is that the CRC32C intrinsic is apparently incorrect on x86 machines without CLMUL support. The tests provided by Lutz Schmidt (also part of this change set) have uncovered that problem. Given the state of JDK 9, I think it's best to split the problem into two parts: - (1) this workaround (8178723), which disables the CRC32C intrinsics on x86 machines without CLMUL support; the workaround also the tests provided by Lutz (with proper credit in the final change set); - (2) the "proper" fix for the problem is handled in 8178720; I asked Michael Berg to look into that problem. If (and once) the workaround is fine with you, I'll take care of the fix-request process. JPRT testing is running at the moment. Thank you! Best regards, Zoltan From zoltan.majo at oracle.com Thu Apr 13 15:15:27 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 13 Apr 2017 17:15:27 +0200 Subject: [9] RFR (S) 8178723: Workaround for failure of CRC32C intrinsic on x86 machines without CLMUL support (JDK-8178720) In-Reply-To: <1e62816d-f893-2883-e86a-0b4e68557b28@oracle.com> References: <1e62816d-f893-2883-e86a-0b4e68557b28@oracle.com> Message-ID: <3bdf8249-460f-65e6-4e5d-c952712606c0@oracle.com> On 04/13/2017 04:54 PM, Zolt?n Maj? wrote: > [...] > JPRT testing is running at the moment. P.S.: All JPRT tests pass. Best regards, Zoltan > > Thank you! > > Best regards, > > > Zoltan > From lutz.schmidt at sap.com Thu Apr 13 15:17:28 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 13 Apr 2017 15:17:28 +0000 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <8CDCC332-FADE-4BFC-A915-7A68B865D513@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> Message-ID: <1FF57C0C-497B-4A87-B9A5-E042FA8BEFB1@sap.com> Hi Zoltan, I really appreciate that the enhanced tests will make their way into JDK 9! Re. the contributor credentials, I?m confident you will do the right thing. Getting the bug out of the way is by far more important. Regards, Lutz On 13.04.2017, 16:28, "Zolt?n Maj?" wrote: Hi Volker, On 04/13/2017 04:22 PM, Volker Simonis wrote: > On Thu, Apr 13, 2017 at 3:39 PM, Zolt?n Maj? > wrote: > > Hi Volker, > Hi Lutz, > > > On 04/13/2017 03:25 PM, Volker Simonis wrote: > > Hi Lutz, Zoltan, > > @Lutz, thanks for analyzing the problem! I actually didn't > expected that the efforts we put into fixing the tests will > pay up that fast :) > > @Zoltan: I propose we split the test from the actual fix. I > can push the ppc64/s390x parts myself. > > > That is fine with me. > > Just to clarify: Will you include the other test Lutz has modified > (test/compiler/intrinsics/zip/TestCRC32.java) into your JDK 10 > changeset? I can live with both options (i.e., (1) both tests > pushed into JDK 9 with 8178720 and (2) *CRC32C -> JDK 9, CRC32 -> > JDK 10). > > > I will only push the ppc64/s390x related fixes WITHOUT any tests > (actually I'm still not allowed to push shared code as it must go > through JPRT and there's still no access to JPRT for external > committers :( Thanks for clarifying. I was confused because at one place you used singular ("test") and at two other places you used plural ("tests"). If you were to go with (2) I would have offered my help with sponsoring (that's the only way I can help you at the moment, unfortunately). I'll take care of both tests then. Best regards, Zoltan > > I opened the new prio 2 bug "8178720: CRC32C fails on old x86 > hardware without CLMUL support" for jdk9 > > > Thank you. > > and linked the reworked tests from Lutz' last webrev to it. I > think this is definitely something we should fix before jdk9 > will be released and the nfix should contain the new, fixed > version of the tests. Zoltan, can you please take care of this? > > > Yes, I can. Just let me know which option from above you prefer. > > For the record: I'll add Lutz as a contributor when pushing the > tests (if that's fine with you, Lutz). > > > That's fine. Thanks! > > Best regards, > > > Zoltan > > > Thank you and best regards, > Volker > > [1] https://bugs.openjdk.java.net/browse/JDK-8178720 > > > > On Thu, Apr 13, 2017 at 12:10 PM, Schmidt, Lutz > > >> > wrote: > > Hi Zoltan, > > I am now able to reproduce the problem. Calculated crc and > reference crc are exactly the same as in the log output > you pasted > below. And the problem shows up on linux-x86_64 as well. > > Here is what?s happening: > The CRC32C implementation generates code depending on the > CLMUL > cpu feature being available. On most machines @Oracle and > @SAP, > this feature seems to be available ? except for one of > your MacOS > test machines. > > To gain control over that feature, I have modified just > one line > in src/cpu/x86/vm/vm_version_x86_64.hpp like this: > static bool supports_clmul() { return ((_features & > CPU_CLMUL) != 0) && UseNewCode; } > > The boolean UseNewCode is a command line parameter we use > @SAP to > make experimental code switchable during development. With > that > modification, I can force off the CLMUL feature at will. And > voila, here is what I get (linux-x86_64): > > lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java > -XX:+UseNewCode TestCRC32C_OpenJDK -m > updateBytesCRC32C: pclmulqdq = true. > testing 1050 cases ... > lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java > -XX:-UseNewCode TestCRC32C_OpenJDK -m > updateBytesCRC32C: pclmulqdq = false. > testing 1050 cases ... > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > iteration 0: offsets[0] = 0 sizes[30] = 1024 > Exception: java.lang.Exception: TestCRC32C Error > Exception in thread "main" java.lang.Exception: > java.lang.Exception: TestCRC32C Error > at > TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:306) > at > TestCRC32C_OpenJDK.main(TestCRC32C_OpenJDK.java:74) > Caused by: java.lang.Exception: TestCRC32C Error > at > TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:298) > ... 1 more > lu0084 PrivSrc/TestCRC> > > Output on MacOS is the same. I did not try solaris-x86_64. > > The bug is in MacroAssembler::crc32c_ipl_alg2_alt2() or > one of its > callees. I have not yet performed an in-depth analysis on > what?s > going wrong, mainly because I am not a proven expert on x86 > machine code. > > So how do we proceed from here? Shouldn?t we file a > separate bug > for this x86 issue? Should this webrev (8176580) be split > up into > the (ppc, s390) chunk and a separate test bug webrev? Can > you push > this webrev despite there is an (unrelated) JPRT failure? > > Thanks and best regards, > Lutz > > > > On 12.04.2017, 18:36, "hotspot-compiler-dev on behalf of > Schmidt, > Lutz" > > on behalf > of lutz.schmidt at sap.com > >> > wrote: > > Hi Zoltan, > > I?m not able to reproduce the problem as of now. I > will try > out other (older) x86 machines tomorrow. Could be a problem in > fallback code when required vector instructions are not > available. > > Can you please find out on what H/W (CPU in > particular) the > tests are failing? > > Thanks, > Lutz > > > On 12.04.2017, 14:38, "Zolt?n Maj?" > > >> wrote: > > Hi Lutz, > > > On 04/12/2017 02:14 PM, Schmidt, Lutz wrote: > > Hi Zoltan, > > > > First of all: thanks for trying to push! Second: > sorry > for the problems you ran into. > > you are welcome and no problem, of course. > > > I do not have an immediate explanation for the > failure ? > my dev machine is MacOS/x86_64. I will try to reproduce > immediately. For the time being: is there any log output that > could shed some light on the issue? > > Please find the output below (and sorry for not > including > it before). > > Please let me know if you were able to reproduce the > problem (or not). > > Best regards, > > > Zoltan > > command: main -Xbatch > compiler.intrinsics.zip.TestCRC32C -m > reason: User specified action: run > main/othervm/timeout=600 -Xbatch > compiler.intrinsics.zip.TestCRC32C -m > Mode: othervm [/othervm specified] > elapsed time (seconds): 1.915 > configuration: > STDOUT: > testing 1050 cases ... > STDERR: > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > java.lang.Exception: TestCRC32C Error > at > compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218) > at > > compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280) > at > compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74) > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at > java.base/java.lang.reflect.Me > thod.invoke(Method.java:563) > at > > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at > java.base/java.lang.Thread.run(Thread.java:844) > > JavaTest Message: Test threw exception: > java.lang.Exception: TestCRC32C Error > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: > java.lang.Exception: > TestCRC32C Error > > > > > > > Thanks, > > Lutz > > > > > > On 12.04.2017, 13:10, "hotspot-compiler-dev on > behalf of > Zolt?n Maj?" > > > on behalf > of zoltan.majo at oracle.com > >> wrote: > > > > P.S.: Forgot to mention: The problem does not > appear on any other x86_64 > > platform. > > > > On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > > > Hi Volker, > > > Hi Lutz, > > > > > > > > > yesterday I tried to push webrev.03 using > JPRT. > Unfortunately, the > > > TestCRC32C.java test you've modified > fails on Mac > OS X on x86_64. Do > > > you have an idea why that could be? > > > > > > Thank you! Best regards, > > > > > > > > > Zoltan > > > > > > On 04/11/2017 06:03 PM, Volker Simonis wrote: > > >> Thanks a lot Zoltan! > > >> > > >> > > >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? > > > > > >> > > >>> wrote: > > >> > > >> Hi Volker, > > >> > > >> > > >> On 04/11/2017 03:34 PM, Volker > Simonis wrote: > > >> > > >> > > >> Hi Zoltan, > > >> > > >> could you please be so kind to > sponsor > this reviewed change > > >> for jdk10? > > >> > > >> > > >> yes, of course. I'll push it today. > > >> > > >> Best regards, > > >> > > >> > > >> Zoltan > > >> > > >> Initially we wanted to push it > ourselves > because it was s390x > > >> only but now that we've also > touched the > tests we need a > > >> sponsor. > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> ---------- Forwarded message > ---------- > > >> From: *Volker Simonis* > > > > > >> > >> > > >> > > > > >> > >>>> > > >> Date: Fri, Mar 31, 2017 at 10:53 AM > > >> Subject: Re: RFR (S) 8176580: [ppc, > s390] CRC32C: wrong > > >> checksum result in some cases > > >> To: "Schmidt, Lutz" > > > > > >> > >> > > > > > >> > >>>> > > >> Cc: Andrew Haley > > > > >> > > >> > > > > >>>>, > > >> > "hotspot-compiler-dev at openjdk.java.net > > > > > >> > > >> > > >> > > > > > >> > > >>>" > > >> > > > > > >> > > >> > > >> > > > > > >> > > >>>> > > >> > > >> > > >> Ping... > > >> > > >> Can somebody please push this > change? > > >> > > >> It's ppc64/s390x only but as a > courtesy > to the community it > > >> also fixes > > >> the CRC JTreg tests so > unfortunately I > still can't push it > > >> myself :) > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> > > >> On Tue, Mar 28, 2017 at 5:01 PM, > Volker > Simonis > > >> > > > > >> > > >> > > > > >> > >>>> wrote: > > >> > Hi Lutz, > > >> > > > >> > thanks a lot for fixing the test! > > >> > Your change looks good now. > > >> > > > >> > Because this touches shared (i.e. > test) files, we still need > > >> a sponsor > > >> > so can somebody please sponsor > this > change? > > >> > > > >> > Thank you and best regards, > > >> > Volker > > >> > > > >> > > > >> > > > >> > On Fri, Mar 24, 2017 at 4:54 PM, > Schmidt, Lutz > > >> > > > >> > > >> > > > >>>> > > >> wrote: > > >> >> Hi Volker, > > >> >> > > >> >> Sorry for letting you wait. > Here is > the final(?) webrev, > > >> containing all your requests for > cleanup > and improvements: > > >> >> > http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ > > > > > >> > > >> > > >> > > > > > >> > > >>> > > >> >> > > >> >> As before, the *.cpp files > have not > been modified. > > >> >> > > >> >> Best Regards, > > >> >> Lutz > > >> >> > > >> >> > > >> >> > > >> >> On 21/03/2017, 17:55, "Volker > Simonis" > > >> > > > > >> > > >> > > > > >> > >>>> wrote: > > >> >> > > >> >> Hi Lutz, > > >> >> > > >> >> thanks a lot for updating the > tests. I think they look > > >> much better now. > > >> >> > > >> >> There's just one more > cleanup I'd > like to propose. Can > > >> you please move > > >> >> the throw right into the check() > function. Just make > > >> check() return > > >> >> void and throw from it if > there's > a mismatch between > > >> the computed and > > >> >> the expected result. I leave it > up to you if you want > > >> to pass an extra > > >> >> error string to check() which > will be printed in the > > >> case of an error. > > >> >> I personally don't think that's > necessary as it will be > > >> evident from > > >> >> the stack trace which > computation > failed. > > >> >> > > >> >> Also the try/catch and > rethrow in > test_multi() isn't > > >> necessary. The > > >> >> test can be simply terminated by > the initial exception. > > >> >> > > >> >> Thank you and best regards, > > >> >> Volker > > >> >> > > >> >> > > >> >> On Fri, Mar 17, 2017 at > 10:03 PM, > Schmidt, Lutz > > >> > > > >> > > >> > > > >>>> > > >> wrote: > > >> >> > Hi Volker, > > >> >> > > > >> >> > Thanks a lot for your valuable > hints. > > >> >> > > > >> >> > I have worked some time on the > Java test files: > > >> >> > TestCRC32.java and > TestCRC32C.java are now > > >> identical as far as possible. > > >> >> > They now throw an exception, > should any error be > > >> detected. > > >> >> > The ?reference CRC value? is > now used in > > >> test_multi() as well. > > >> >> > The extra test runs have been > removed again. > > >> >> > The test methodology is > fixed: > each result is > > >> tested against its reference. > > >> >> > The tests now detect the bug > introduced with > > >> 8175368 and 8175369. > > >> >> > No issue is indicated when > testing with 8176580. > > >> >> > I ran jcheck, and to the > best > of my ability and > > >> knowledge, there is no trailing > whitespace. > > >> >> > All *.cpp files were left > untouched! > > >> >> > > > >> >> > The next iteration of the > webrev: > > >> > http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ > > > > > >> > > >> > > >> > > > > > >> > > >>> > > >> >> > > > >> >> > Best regards, > > >> >> > Lutz > > >> >> > > > >> >> > > > >> >> > Dr. Lutz Schmidt | SAP JVM | > PI SAP CP Core | T: +49 > > >> (6227) 7-42834 > > > > >> > > >> >> > > > >> >> > > > >> >> > > > >> >> > On 16.03.17, 11:28, "Volker > Simonis" > > >> > > > > >> > > >> > > > > >> > >>>> wrote: > > >> >> > > > >> >> > On Wed, Mar 15, 2017 at 5:55 > PM, Schmidt, Lutz > > >> > > > >> > > >> > > > >>>> > > >> wrote: > > >> >> > > > > >> >> > > Hi Andrew, Volker, > > >> >> > > > > >> >> > > What do you think about > these test enhancements? > > >> >> > > Webrev: > > >> > http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ > > > > > >> > > >> > > >> > > > > > >> > > >>> > > >> > > >> >> > > > > >> >> > > Please note: the cpp files > in the webrev > > >> remained unchanged. > > >> >> > > > > >> >> > > I added some improvements > (as I believe) to the > > >> TestCRC32(C).java files. > > >> >> > > > > >> >> > > In some more detail: > > >> >> > > The test now calculates a > ?reference CRC > > >> value?, based on a java > implementation > of the CRC32 algorithm. > > >> This reference value is used to > verify > all other crc values, > > >> in particular during > initialization and > warmup. Three > > >> additional test runs check a > non-zero > offset with ?Xint, > > >> -Xcomp -XX:-TieredCompilation > (C2 only), > -Xcomp > > >> -XX:+TieredCompilation (C1 + C2). > > >> >> > > > > >> >> > > > >> >> > Hi Lutz, > > >> >> > > > >> >> > thanks for updating the > tests. > I've had a closer > > >> look at the tests and > > >> >> > realized that they actually > can never fail! The > > >> check() routine just > > >> >> > prints an error message but > that will not let the > > >> test fail. So I > > >> >> > would suggest to throw a > runtime exception in the > > >> check() routine > > >> >> > after the error message was > printed. > > >> >> > > > >> >> > I also suggest to do the > check > during the normal > > >> test execution (i.e. > > >> >> > in test_multi()) so > there's no > need for extra > > >> test runs. > > >> >> > > > >> >> > Finally, the current test > methodology in > > >> test_multi() is broken: > > >> >> > - it sets the reference by > calling CRC from the > > >> interpreter which > > >> >> > won't work if the > intrinsic is > also used in the > > >> interpreter. > > >> >> > - it only compares the > reference against the > > >> last computation of CRC > > >> >> > in the loop which will be the > result of the C2 > > >> generated code. This > > >> >> > misses errors in C1. > > >> >> > > > >> >> > I suggest to use your new, > pure Java > > >> implementation for the > > >> >> > computation of the reference > result and compare > > >> the reference with the > > >> >> > result of calling CRC in > every > iteration of the > > >> loop so we really > > >> >> > check all possibilities from > interpreter trough > > >> C1 to C2. > > >> >> > > > >> >> > Finally, can you please pay > attention to not > > >> insert trailing > > >> >> > whitespace (there was some at > line 88 in > > >> TestCRC32C.java). You can > > >> >> > easily verify this by running > jcheck before > > >> creating the webrevs. > > >> >> > > > >> >> > Thanks, > > >> >> > Volker > > >> >> > > > >> >> > > > > >> >> > > Best regards, > > >> >> > > Lutz > > >> >> > > > > >> >> > > > > >> >> > > On 15.03.17, 11:50, "Volker > Simonis" > > >> > > > > >> > > >> > > > > >> > >>>> wrote: > > >> >> > > > > >> >> > > On Tue, Mar 14, 2017 at > 7:05 PM, Andrew > > >> Haley > > > > >> > > >> > > > > >>>> wrote: > > >> >> > > > On 14/03/17 13:12, > Schmidt, Lutz wrote: > > >> >> > > > > > >> >> > > >> Yes, one might think > of running a test > > >> suite subset multiple times > > >> >> > > >> with different > parameters. In this case, > > >> -Xint and/or ?Xcomp were > > >> >> > > >> helpful. Forcing > tests to run fully > > >> interpreted or fully compiled > > >> >> > > >> helps in cases where > a certain function, > > >> e.g. an intrinsic, is > > >> >> > > >> invoked via distinct > code paths. > > >> >> > > > > > >> >> > > > Right, so your patch > should include that > > >> change to the test suite. > > >> >> > > > > > >> >> > > > > >> >> > > Hi Lutz, > > >> >> > > > > >> >> > > I agree with Andrew. We > should really fix > > >> the tests such that they > > >> >> > > check the > correctness of > the intrinsics. > > >> >> > > > > >> >> > > This may be tricky if > all three, the > > >> interpreter, the client and the > > >> >> > > server compiler use the > same intrinsic > > >> implementation. You could > > >> >> > > either copy the pure > Java implementation > > >> into the test so that you can > > >> >> > > compare the results of > the intrinsic > > >> operation against it or you can > > >> >> > > switch them off in the > compilers with > > >> >> > > > "-XX:DisableIntrinsic=_updateBytesCRC32C > > >> >> > > > > >> > -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and > > >> compare the > > >> >> > > results. Not sure which > solution is more > > >> practical, but I would be > > >> >> > > really scared if we > wouldn't have these test. > > >> >> > > > > >> >> > > Regards, > > >> >> > > Volker > > >> >> > > > > >> >> > > > Andrew. > > >> >> > > > > > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > From vladimir.kozlov at oracle.com Thu Apr 13 17:28:41 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Apr 2017 10:28:41 -0700 Subject: [9] RFR (S) 8178723: Workaround for failure of CRC32C intrinsic on x86 machines without CLMUL support (JDK-8178720) In-Reply-To: <1e62816d-f893-2883-e86a-0b4e68557b28@oracle.com> References: <1e62816d-f893-2883-e86a-0b4e68557b28@oracle.com> Message-ID: <33e57da7-7271-7173-f1a9-525340d37a62@oracle.com> Hi Zoltan, The fix looks good. Please, add label and fix request comment according to RDP2 rules for JDK 9. Thanks, Vladimir On 4/13/17 7:54 AM, Zolt?n Maj? wrote: > Hi, > > > please review the following fix for 8178723. (8178723 is a workaround for 8178720.) > https://bugs.openjdk.java.net/browse/JDK-8178723 > http://cr.openjdk.java.net/~zmajo/8178723/webrev.00/ > > The problem is that the CRC32C intrinsic is apparently incorrect on x86 machines without CLMUL support. The tests > provided by Lutz Schmidt (also part of this change set) have uncovered that problem. > > Given the state of JDK 9, I think it's best to split the problem into two parts: > - (1) this workaround (8178723), which disables the CRC32C intrinsics on x86 machines without CLMUL support; the > workaround also the tests provided by Lutz (with proper credit in the final change set); > - (2) the "proper" fix for the problem is handled in 8178720; I asked Michael Berg to look into that problem. > > If (and once) the workaround is fine with you, I'll take care of the fix-request process. > > JPRT testing is running at the moment. > > Thank you! > > Best regards, > > > Zoltan > From volker.simonis at gmail.com Thu Apr 13 18:43:23 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 13 Apr 2017 20:43:23 +0200 Subject: [9] RFR (S) 8178723: Workaround for failure of CRC32C intrinsic on x86 machines without CLMUL support (JDK-8178720) In-Reply-To: <3bdf8249-460f-65e6-4e5d-c952712606c0@oracle.com> References: <1e62816d-f893-2883-e86a-0b4e68557b28@oracle.com> <3bdf8249-460f-65e6-4e5d-c952712606c0@oracle.com> Message-ID: Looks good although all the files need an updated copyright line :) Thanks, Volker On Thu, Apr 13, 2017 at 5:15 PM, Zolt?n Maj? wrote: > > On 04/13/2017 04:54 PM, Zolt?n Maj? wrote: > >> [...] >> JPRT testing is running at the moment. >> > > P.S.: All JPRT tests pass. > > Best regards, > > > Zoltan > > > >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Fri Apr 14 03:30:52 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 13 Apr 2017 20:30:52 -0700 Subject: RFR(XS) 8178047: Aliasing problem with raw memory accesses Message-ID: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> This seems like a long-standing bug. Analysis in MemNode::find_previous_store() tries to relax memory dependencies by proving that memory accesses don?t alias. The code is fine for oops: if [offset, offset+length) intervals don?t overlap it proves the accesses don?t alias because bases always point to the start of an object. For raw accesses that?s not true. Offset analysis doesn?t mean much without proving that bases are not the same. Webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.00 Thanks, igor From igor.ignatyev at oracle.com Fri Apr 14 03:58:02 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 13 Apr 2017 20:58:02 -0700 Subject: RFR(XS) : 8178727: CTW should provide class names in error messages Message-ID: <2B0EB6B4-96F7-4A54-A14C-A3C919D02EC4@oracle.com> http://cr.openjdk.java.net/~iignatyev//8178727/webrev.00/index.html > 14 lines changed: 5 ins; 1 del; 8 mod; Hi all, could you please review this small enchantment for CTW test runner? Currently, error messages contain only index of class which caused an error, which is not informative enough. this fix adds a class name to an error message. Without the fix, errors look like: > java.lang.Error: modules_0: failed during compilation of class #4795 > at sun.hotspot.tools.ctw.CtwRunner.startCtwforAllClasses(CtwRunner.java:133) > at sun.hotspot.tools.ctw.CtwRunner.run(CtwRunner.java:78) > at sun.hotspot.tools.ctw.CtwRunner.main(CtwRunner.java:56) > ... With the fix: > java.lang.Error: modules_0: failed during compilation of class #4795:sun/reflect/misc/ReflectUtil > at sun.hotspot.tools.ctw.CtwRunner.startCtwforAllClasses(CtwRunner.java:134) > at sun.hotspot.tools.ctw.CtwRunner.run(CtwRunner.java:79) > at sun.hotspot.tools.ctw.CtwRunner.main(CtwRunner.java:57) > ... webrev: http://cr.openjdk.java.net/~iignatyev//8178727/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8178727 testing: hotspot/test/applications/ctw/Modules.java Thanks, -- Igor From aph at redhat.com Fri Apr 14 16:44:26 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 14 Apr 2017 17:44:26 +0100 Subject: RFR(XS) 8178047: Aliasing problem with raw memory accesses In-Reply-To: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> References: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> Message-ID: On 14/04/17 04:30, Igor Veresov wrote: > This seems like a long-standing bug. Analysis in MemNode::find_previous_store() tries to relax memory dependencies by proving that memory accesses don?t alias. The code is fine for oops: if [offset, offset+length) intervals don?t overlap it proves the accesses don?t alias because bases always point to the start of an object. For raw accesses that?s not true. Offset analysis doesn?t mean much without proving that bases are not the same. > > Webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.00 Please make sure that the test in https://bugs.openjdk.java.net/browse/JDK-8176513 doesn't regress again. Thanks, Andrew. From vladimir.kozlov at oracle.com Fri Apr 14 16:53:05 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Apr 2017 09:53:05 -0700 Subject: RFR(XS) 8178047: Aliasing problem with raw memory accesses In-Reply-To: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> References: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> Message-ID: <8ee16b46-0ecb-a23f-fc96-31771f4d9552@oracle.com> Klass pointers should be also fine I think. The problem is only Raw pointers which could point to the same memory but different offset. May be use bool is_raw = adr->bottom_type()->isa_rawptr() != NULL; ... if (is_raw && st_base != base) { Also what if pointer type is mixed: original is oop and mem node is raw? May we should check that if when one of them is raw we should compare bases. Thanks, Vladimir On 4/13/17 8:30 PM, Igor Veresov wrote: > This seems like a long-standing bug. Analysis in MemNode::find_previous_store() tries to relax memory dependencies by proving that memory accesses don?t alias. The code is fine for oops: if [offset, offset+length) intervals don?t overlap it proves the accesses don?t alias because bases always point to the start of an object. For raw accesses that?s not true. Offset analysis doesn?t mean much without proving that bases are not the same. > > Webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.00 > > Thanks, > igor > From vladimir.kozlov at oracle.com Fri Apr 14 16:56:35 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Apr 2017 09:56:35 -0700 Subject: RFR(XS) : 8178727: CTW should provide class names in error messages In-Reply-To: <2B0EB6B4-96F7-4A54-A14C-A3C919D02EC4@oracle.com> References: <2B0EB6B4-96F7-4A54-A14C-A3C919D02EC4@oracle.com> Message-ID: <38c22710-379a-6f12-b53a-f57ead478b69@oracle.com> Put spaces around : #4795 : sun/r Is modules_0 is module name or also index? In such case may be print module name too. Otherwise good. Thanks, Vladimir On 4/13/17 8:58 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8178727/webrev.00/index.html >> 14 lines changed: 5 ins; 1 del; 8 mod; > > Hi all, > > could you please review this small enchantment for CTW test runner? > Currently, error messages contain only index of class which caused an error, which is not informative enough. this fix adds a class name to an error message. > Without the fix, errors look like: >> java.lang.Error: modules_0: failed during compilation of class #4795 >> at sun.hotspot.tools.ctw.CtwRunner.startCtwforAllClasses(CtwRunner.java:133) >> at sun.hotspot.tools.ctw.CtwRunner.run(CtwRunner.java:78) >> at sun.hotspot.tools.ctw.CtwRunner.main(CtwRunner.java:56) >> ... > With the fix: >> java.lang.Error: modules_0: failed during compilation of class #4795:sun/reflect/misc/ReflectUtil >> at sun.hotspot.tools.ctw.CtwRunner.startCtwforAllClasses(CtwRunner.java:134) >> at sun.hotspot.tools.ctw.CtwRunner.run(CtwRunner.java:79) >> at sun.hotspot.tools.ctw.CtwRunner.main(CtwRunner.java:57) >> ... > > > > webrev: http://cr.openjdk.java.net/~iignatyev//8178727/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8178727 > testing: hotspot/test/applications/ctw/Modules.java > > Thanks, > -- Igor > From igor.veresov at oracle.com Fri Apr 14 17:31:59 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 14 Apr 2017 10:31:59 -0700 Subject: RFR(XS) 8178047: Aliasing problem with raw memory accesses In-Reply-To: <8ee16b46-0ecb-a23f-fc96-31771f4d9552@oracle.com> References: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> <8ee16b46-0ecb-a23f-fc96-31771f4d9552@oracle.com> Message-ID: > On Apr 14, 2017, at 9:53 AM, Vladimir Kozlov wrote: > > Klass pointers should be also fine I think. > The problem is only Raw pointers which could point to the same memory but different offset. > May be use > > bool is_raw = adr->bottom_type()->isa_rawptr() != NULL; > ... > if (is_raw && st_base != base) { I guess in that case AnyPtr should be be also checked for, because it includes RawPtr, right? > > Also what if pointer type is mixed: original is oop and mem node is raw? > May we should check that if when one of them is raw we should compare bases. Is it possible for that to happen? igor > > Thanks, > Vladimir > > On 4/13/17 8:30 PM, Igor Veresov wrote: >> This seems like a long-standing bug. Analysis in MemNode::find_previous_store() tries to relax memory dependencies by proving that memory accesses don?t alias. The code is fine for oops: if [offset, offset+length) intervals don?t overlap it proves the accesses don?t alias because bases always point to the start of an object. For raw accesses that?s not true. Offset analysis doesn?t mean much without proving that bases are not the same. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.00 >> >> Thanks, >> igor >> From igor.veresov at oracle.com Fri Apr 14 18:04:48 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 14 Apr 2017 11:04:48 -0700 Subject: RFR(XS) 8178047: Aliasing problem with raw memory accesses In-Reply-To: References: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> Message-ID: > On Apr 14, 2017, at 9:44 AM, Andrew Haley wrote: > > On 14/04/17 04:30, Igor Veresov wrote: >> This seems like a long-standing bug. Analysis in MemNode::find_previous_store() tries to relax memory dependencies by proving that memory accesses don?t alias. The code is fine for oops: if [offset, offset+length) intervals don?t overlap it proves the accesses don?t alias because bases always point to the start of an object. For raw accesses that?s not true. Offset analysis doesn?t mean much without proving that bases are not the same. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.00 > > Please make sure that the test in https://bugs.openjdk.java.net/browse/JDK-8176513 > doesn't regress again. It might be a problem with a test attached to the bug (it also needs b.capacity() / 4 in floss(), otherwise it would throw), but I don?t see vectorization happening at all. With or without my fix. igor > > Thanks, > > Andrew. > From vivek.r.deshpande at intel.com Fri Apr 14 18:17:47 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Fri, 14 Apr 2017 18:17:47 +0000 Subject: RFR(S): 8178811: Minimize the AVX <-> SSE transition penalty on x86 Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A63CD479B@ORSMSX106.amr.corp.intel.com> Hi All This fix minimizes the AVX to SSE and SSE to AVX transition penalty through generation of vzeroupper instruction. With this patch we see zero transitions with penalty per SPECjbb2015 jOPS on BDW and a significant reduction on SKX CPU event vector width mismatch from 65 to 0.01 per SPECjbb2015 jOPS. We have also implemented an enhancement to disable vzeroupper generation for Knights family where the instruction has high penalty and is not recommended. The option UseVzeroupper is used to control generation of vzeroupper instruction and gets set to false on the Knights family. We observed ~3% gain on SPECJvm2008 composite result on Skylake. Webrev: http://cr.openjdk.java.net/~vdeshpande/8178811/webrev.00/ I have also updated the JBS entry. https://bugs.openjdk.java.net/browse/JDK-8178811 Would you please review and sponsor it. Regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Apr 14 18:21:42 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Apr 2017 11:21:42 -0700 Subject: RFR(XS) 8178047: Aliasing problem with raw memory accesses In-Reply-To: References: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> <8ee16b46-0ecb-a23f-fc96-31771f4d9552@oracle.com> Message-ID: <698356e6-5505-053f-b6db-8583e9c02ae9@oracle.com> On 4/14/17 10:31 AM, Igor Veresov wrote: > >> On Apr 14, 2017, at 9:53 AM, Vladimir Kozlov wrote: >> >> Klass pointers should be also fine I think. >> The problem is only Raw pointers which could point to the same memory but different offset. >> May be use >> >> bool is_raw = adr->bottom_type()->isa_rawptr() != NULL; >> ... >> if (is_raw && st_base != base) { > > I guess in that case AnyPtr should be be also checked for, because it includes RawPtr, right? Yes. > >> >> Also what if pointer type is mixed: original is oop and mem node is raw? >> May we should check that if when one of them is raw we should compare bases. > > Is it possible for that to happen? May be not. Usually we will have membars around unsafe memory access. But if we have AnyPtr, as you said, it could be mixed I think. I think it is better to check for such case even if it may not happen. Vladimir > > igor > >> >> Thanks, >> Vladimir >> >> On 4/13/17 8:30 PM, Igor Veresov wrote: >>> This seems like a long-standing bug. Analysis in MemNode::find_previous_store() tries to relax memory dependencies by proving that memory accesses don?t alias. The code is fine for oops: if [offset, offset+length) intervals don?t overlap it proves the accesses don?t alias because bases always point to the start of an object. For raw accesses that?s not true. Offset analysis doesn?t mean much without proving that bases are not the same. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.00 >>> >>> Thanks, >>> igor >>> > From vladimir.kozlov at oracle.com Fri Apr 14 19:47:36 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Apr 2017 12:47:36 -0700 Subject: RFR(S): 8178811: Minimize the AVX <-> SSE transition penalty on x86 In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A63CD479B@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A63CD479B@ORSMSX106.amr.corp.intel.com> Message-ID: Hi Vivek, Did you pinpoint particular change which helps SPECjbb2015? From what I remember it is mostly during call to runtime or JNI calls. // AVX instruction which is used to clear upper 128 bits of YMM registers and // to avoid transaction penalty between AVX and SSE states. There is no // penalty if legacy SSE instructions are encoded using VEX prefix because // they always clear upper 128 bits. It should be used before calling // runtime code and native libraries. void vzeroupper(); So why you added vzeroupper() into arraycopy and other stubs? If AVX is supported all instructions should be encoded with VEX prefix. Or the statement in the comment is incorrect? About UseVzeroupper flag. We should avoid adding new product flags if possible. IT only make sense if you want to do experiments to check performance with and without it. But we already know that it is needed on most CPUs. I would suggest to add VM_Version::supports_vzeroupper() { return (_features & CPU_VZEROUPPER) != 0; } Set CPU_VZEROUPPE if AVX is supported and clear it for Knights CPU. The add check inside assembler instruction: void Assembler::vzeroupper() { - assert(VM_Version::supports_avx(), ""); + if (VM_Version::supports_vzeroupper()) { It will allow to avoid supports_avx() checks on each vzeroupper() call. You missed check in MachEpilogNode::emit() in x86_64.ad Note, I used (C->max_vector_size() > 16) checks in .ad files because of the same reasons as above: // There is no penalty if legacy SSE instructions are encoded using VEX prefix because // they always clear upper 128 bits. I thought if vectors are small and we use VEX prefix then upper bits will be 0 anyway so you don't need vzeroupper(). Thanks, Vladimir On 4/14/17 11:17 AM, Deshpande, Vivek R wrote: > Hi All > > > > This fix minimizes the AVX to SSE and SSE to AVX transition penalty through generation of vzeroupper instruction. With this patch we see zero transitions with penalty per SPECjbb2015 jOPS on BDW and a > significant reduction on SKX CPU event vector width mismatch from 65 to 0.01 per SPECjbb2015 jOPS. We have also implemented an enhancement to disable vzeroupper generation for Knights family where the > instruction has high penalty and is not recommended. The option UseVzeroupper is used to control generation of vzeroupper instruction and gets set to false on the Knights family. > We observed ~3% gain on SPECJvm2008 composite result on Skylake. > > Webrev: > > http://cr.openjdk.java.net/~vdeshpande/8178811/webrev.00/ > > I have also updated the JBS entry. > > https://bugs.openjdk.java.net/browse/JDK-8178811 > > Would you please review and sponsor it. > > > > Regards, > > Vivek > > > From serguei.spitsyn at oracle.com Fri Apr 14 20:45:22 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Apr 2017 13:45:22 -0700 Subject: RFR(S): 8164944: Refactor ProcessTools to get rid of dependency on java.management In-Reply-To: <5548AED8-2BEB-4341-88F9-B34C0F827BAD@oracle.com> References: <9054D440-C6C9-4D97-AEB9-25CD3057564F@oracle.com> <5548AED8-2BEB-4341-88F9-B34C0F827BAD@oracle.com> Message-ID: Igor, Looks good. Thanks, Serguei On 4/12/17 12:14, Igor Ignatyev wrote: > forgot to update copyrights, http://cr.openjdk.java.net/~iignatyev//8164944/webrev.01/index.html > >> On Apr 12, 2017, at 12:03 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html >>> 92 lines changed: 36 ins; 36 del; 20 mod; >> Hi all, >> >> could you please review this small fix which removes dependency on java.management module from the testlibrary? >> >> jdk.test.lib.process.ProcessTools class has getVmInputArgs method which depend on java.management, this method is used only by j.d.t.process.ProcessTools::executeTestJvmAll and j.t.l.cli.CommandLineOptionTest class. >> - ProcessTools::executeTestJvmAll is a variation of executeTestJvm which prepends vm flags from jtreg @run. >> - CommandLineOptionTest is a library class for cli testing, it uses flags from ProcessTools::getVmInputArgs to create a new jvm with all flags >> >> the fix removes ProcessTools::executeTestJvmAll method, moves getVmInputArgs to a separate class jdk.test.lib.management.InputArguments. c.c.s.scenario.Executor and j.t.l.cli.CommandLineOptionTest are updated to use getVmInputArgs from that class. c.j.compilerToVM.DebugOutputTest is refactored to pass add-exports and patch module directly. all the affected classes and obviously updated to use executeTestJvm instead of executeTestJvmAll. >> >> after this fix many hotspot tests won't depend on java.management, hence that module might be removed from their @modules, this will be done separately by 8178416. >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8164944 >> webrev: http://cr.openjdk.java.net/~iignatyev//8164944/webrev.00/index.html >> testing: :hotspot_all >> 8178416: https://bugs.openjdk.java.net/browse/JDK-8178416 >> >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Fri Apr 14 21:59:00 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 14 Apr 2017 14:59:00 -0700 Subject: RFR(XS) : 8178727: CTW should provide class names in error messages In-Reply-To: <38c22710-379a-6f12-b53a-f57ead478b69@oracle.com> References: <2B0EB6B4-96F7-4A54-A14C-A3C919D02EC4@oracle.com> <38c22710-379a-6f12-b53a-f57ead478b69@oracle.com> Message-ID: Vladimir, thank you for your review. please see my answers inline. -- Igor > On Apr 14, 2017, at 9:56 AM, Vladimir Kozlov wrote: > > Put spaces around : > > #4795 : sun/r added > Is modules_0 is module name or also index? In such case may be print module name too. it's not a module name, it's name of a file we run CTW on, which is modules in this case, and class start index. the same string is used for dumped output/error streams, hs_err, hs_log and cireplay files. so when you see "java.lang.Error: modules_0:" , you know that you need to look at modules_0* files in test result directory. > > Otherwise good. > > Thanks, > Vladimir > > On 4/13/17 8:58 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8178727/webrev.00/index.html >>> 14 lines changed: 5 ins; 1 del; 8 mod; >> >> Hi all, >> >> could you please review this small enchantment for CTW test runner? >> Currently, error messages contain only index of class which caused an error, which is not informative enough. this fix adds a class name to an error message. >> Without the fix, errors look like: >>> java.lang.Error: modules_0: failed during compilation of class #4795 >>> at sun.hotspot.tools.ctw.CtwRunner.startCtwforAllClasses(CtwRunner.java:133) >>> at sun.hotspot.tools.ctw.CtwRunner.run(CtwRunner.java:78) >>> at sun.hotspot.tools.ctw.CtwRunner.main(CtwRunner.java:56) >>> ... >> With the fix: >>> java.lang.Error: modules_0: failed during compilation of class #4795:sun/reflect/misc/ReflectUtil >>> at sun.hotspot.tools.ctw.CtwRunner.startCtwforAllClasses(CtwRunner.java:134) >>> at sun.hotspot.tools.ctw.CtwRunner.run(CtwRunner.java:79) >>> at sun.hotspot.tools.ctw.CtwRunner.main(CtwRunner.java:57) >>> ... >> >> >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8178727/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8178727 >> testing: hotspot/test/applications/ctw/Modules.java >> >> Thanks, >> -- Igor >> From vladimir.kozlov at oracle.com Fri Apr 14 22:09:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Apr 2017 15:09:50 -0700 Subject: RFR(XS) : 8178727: CTW should provide class names in error messages In-Reply-To: References: <2B0EB6B4-96F7-4A54-A14C-A3C919D02EC4@oracle.com> <38c22710-379a-6f12-b53a-f57ead478b69@oracle.com> Message-ID: <4618bc6e-b276-c569-d972-ec74e4807ee7@oracle.com> Good. thanks, Vladimir On 4/14/17 2:59 PM, Igor Ignatyev wrote: > Vladimir, > > thank you for your review. please see my answers inline. > > -- Igor > >> On Apr 14, 2017, at 9:56 AM, Vladimir Kozlov wrote: >> >> Put spaces around : >> >> #4795 : sun/r > added > >> Is modules_0 is module name or also index? In such case may be print module name too. > it's not a module name, it's name of a file we run CTW on, which is modules in this case, and class start index. the same string is used for dumped output/error streams, hs_err, hs_log and cireplay files. so when you see "java.lang.Error: modules_0:" , you know that you need to look at modules_0* files in test result directory. > >> >> Otherwise good. >> >> Thanks, >> Vladimir >> >> On 4/13/17 8:58 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8178727/webrev.00/index.html >>>> 14 lines changed: 5 ins; 1 del; 8 mod; >>> >>> Hi all, >>> >>> could you please review this small enchantment for CTW test runner? >>> Currently, error messages contain only index of class which caused an error, which is not informative enough. this fix adds a class name to an error message. >>> Without the fix, errors look like: >>>> java.lang.Error: modules_0: failed during compilation of class #4795 >>>> at sun.hotspot.tools.ctw.CtwRunner.startCtwforAllClasses(CtwRunner.java:133) >>>> at sun.hotspot.tools.ctw.CtwRunner.run(CtwRunner.java:78) >>>> at sun.hotspot.tools.ctw.CtwRunner.main(CtwRunner.java:56) >>>> ... >>> With the fix: >>>> java.lang.Error: modules_0: failed during compilation of class #4795:sun/reflect/misc/ReflectUtil >>>> at sun.hotspot.tools.ctw.CtwRunner.startCtwforAllClasses(CtwRunner.java:134) >>>> at sun.hotspot.tools.ctw.CtwRunner.run(CtwRunner.java:79) >>>> at sun.hotspot.tools.ctw.CtwRunner.main(CtwRunner.java:57) >>>> ... >>> >>> >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8178727/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8178727 >>> testing: hotspot/test/applications/ctw/Modules.java >>> >>> Thanks, >>> -- Igor >>> > From ekaterina.pavlova at oracle.com Fri Apr 14 22:52:37 2017 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Fri, 14 Apr 2017 15:52:37 -0700 Subject: RFR(S) 8178731: compiler/ciReplay/SABase.java does not compile Message-ID: <4c83e586-1c10-1bae-eb18-6d6b1b7bd286@oracle.com> Hi everyone, Please review this small change that fixes hotspot/test/compiler/ciReplay/SABase.java This file used ProcessHandle.getPid() which was recently renamed in ProcessHandle.pid() as part of JDK-8178347. Also fixed test/serviceability/sa/sadebugd/SADebugDTest.java which had the same issue. bug: https://bugs.openjdk.java.net/browse/JDK-8178731 webrev: http://cr.openjdk.java.net/~iignatyev/epavlova/8178731/webrev.00/ Tested by running jprt. thanks, -katya p.s. Igor Ignatyev volunteered to sponsor this change. From igor.ignatyev at oracle.com Fri Apr 14 22:54:26 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 14 Apr 2017 15:54:26 -0700 Subject: RFR(S) 8178731: compiler/ciReplay/SABase.java does not compile In-Reply-To: <4c83e586-1c10-1bae-eb18-6d6b1b7bd286@oracle.com> References: <4c83e586-1c10-1bae-eb18-6d6b1b7bd286@oracle.com> Message-ID: Hi Katya, looks good to me. since it also changes svc tests, I cc'ed svc-dev alias. Thanks, -- Igor > On Apr 14, 2017, at 3:52 PM, Ekaterina Pavlova wrote: > > Hi everyone, > > Please review this small change that fixes hotspot/test/compiler/ciReplay/SABase.java > This file used ProcessHandle.getPid() which was recently renamed in ProcessHandle.pid() > as part of JDK-8178347. > Also fixed test/serviceability/sa/sadebugd/SADebugDTest.java which had the same issue. > > bug: https://bugs.openjdk.java.net/browse/JDK-8178731 > webrev: http://cr.openjdk.java.net/~iignatyev/epavlova/8178731/webrev.00/ > > Tested by running jprt. > > thanks, > -katya > > p.s. > Igor Ignatyev volunteered to sponsor this change. From gerald.thornbrugh at oracle.com Fri Apr 7 16:18:15 2017 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Fri, 7 Apr 2017 10:18:15 -0600 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: References: Message-ID: <9489720A-1E66-4587-AD8B-C9838BBA0635@oracle.com> Hi George, Wow, this is bigger than I thought it would be. A couple of questions: I assume you will update the copyright years before you putback? src /os_cpu /solaris_sparc /vm /atomic_solaris_sparc.hpp Line 245, you can probably remove the " || defined(_LP64)? Line 372, you can probably remove the "_LP64 ||? Is there a reason you did not include prefetch_solaris_sparc.inline.hpp in your changes? src /os_cpu /solaris_sparc /vm /prefetch_solaris_sparc.inline.hpp Line 30, 58 and 63, you can probably remove the references to _LP64 Is there a plan to remove the SPARC 32 bit support from the makefiles and build configuration files? Thanks! Jerry > On Apr 7, 2017, at 8:47 AM, George Triantafillou wrote: > > (Adding compiler). > > Please review this fix to remove SPARC 32-bit support. Support for solaris-sparc has been dropped from the list of supported platforms. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 > webrev: http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ > > Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. > > Thanks. > > -George > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekaterina.pavlova at oracle.com Fri Apr 14 22:48:27 2017 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Fri, 14 Apr 2017 15:48:27 -0700 Subject: RFR(S) 8178731: compiler/ciReplay/SABase.java does not compile Message-ID: Hi everyone, Please review this small change that fixes hotspot/test/compiler/ciReplay/SABase.java This file used ProcessHandle.getPid() which was recently renamed in ProcessHandle.pid() as part of JDK-8178347. Also fixed test/serviceability/sa/sadebugd/SADebugDTest.java which had the same issue. bug: https://bugs.openjdk.java.net/browse/JDK-8178731 webrev: http://cr.openjdk.java.net/~iignatyev/epavlova/8178731/webrev.00/ Tested by running jprt. thanks, -katya p.s. Igor Ignatyev volunteered to sponsor this change. From serguei.spitsyn at oracle.com Fri Apr 14 23:42:45 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Apr 2017 16:42:45 -0700 Subject: RFR(S) 8178731: compiler/ciReplay/SABase.java does not compile In-Reply-To: References: <4c83e586-1c10-1bae-eb18-6d6b1b7bd286@oracle.com> Message-ID: Hi Katya, It looks good. Thanks, Serguei On 4/14/17 15:54, Igor Ignatyev wrote: > Hi Katya, > > looks good to me. since it also changes svc tests, I cc'ed svc-dev alias. > > Thanks, > -- Igor > >> On Apr 14, 2017, at 3:52 PM, Ekaterina Pavlova wrote: >> >> Hi everyone, >> >> Please review this small change that fixes hotspot/test/compiler/ciReplay/SABase.java >> This file used ProcessHandle.getPid() which was recently renamed in ProcessHandle.pid() >> as part of JDK-8178347. >> Also fixed test/serviceability/sa/sadebugd/SADebugDTest.java which had the same issue. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8178731 >> webrev: http://cr.openjdk.java.net/~iignatyev/epavlova/8178731/webrev.00/ >> >> Tested by running jprt. >> >> thanks, >> -katya >> >> p.s. >> Igor Ignatyev volunteered to sponsor this change. From kim.barrett at oracle.com Sat Apr 15 08:27:56 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 15 Apr 2017 04:27:56 -0400 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: References: Message-ID: <8C096D6B-AFEB-44BD-ACDF-0709E04300A9@oracle.com> > On Apr 7, 2017, at 10:47 AM, George Triantafillou wrote: > > (Adding compiler). > Please review this fix to remove SPARC 32-bit support. Support for solaris-sparc has been dropped from the list of supported platforms. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 > webrev: http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ > > Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. > > Thanks. > > -George That's a lot of files and changes! I hope you'll be providing incremental webrevs for updates. ------------------------------------------------------------------------------ src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp 1393 // the poll may need a register so just pick one that isn't the return register This comment appears to refer to the 32bit code that followed it and was removed. I think the comment should be removed too. ------------------------------------------------------------------------------ src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp 1490 Register yhi = opr2->as_register_hi(); After the removal of the 32bit code, I don't see any remaining references to yhi. Not sure what that implies, other than there's likely further work to do here. ------------------------------------------------------------------------------ src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp 1559 } else 1560 __ brx(acond, false, Assembler::pt, skip); // checks icc on 32bit and xcc on 64bit Please add braces to that else-clause. They were missing before because the if/else was 64bit-only, and the close brace would have also needed 64bit conditionalization. ------------------------------------------------------------------------------ src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp 2574 Register cmp_value_hi = op->cmp_value()->as_register_hi(); ... 2576 Register new_value_hi = op->new_value()->as_register_hi(); After the removal of the 32bit code, I don't see any remaining references to the xxx_hi variables. Not sure what that implies, other than there's likely further work to do here. ------------------------------------------------------------------------------ src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp 3047 void LIR_Assembler::volatile_move_op(LIR_Opr src, LIR_Opr dest, BasicType type, CodeEmitInfo* info) { 3048 ShouldNotReachHere(); 3049 3050 NEEDS_CLEANUP; It appears that in 64bit mode this function has no implementation, and the following 50+ lines of code are presently 32bit-only. Likely further work to do here. ------------------------------------------------------------------------------ rc/cpu/sparc/vm/copy_sparc.hpp 116 static void pd_conjoint_jlongs_atomic(jlong* from, jlong* to, size_t count) { --- TBD Removed call to _Copy_conjoint_jlongs_atomic. Check if it's still needed elsewhere or definition is removed. ------------------------------------------------------------------------------ src/cpu/sparc/vm/globalDefinitions_sparc.hpp 43 #elif defined(COMPILER1) 44 // pure C1, 32-bit, small machine 45 #define DEFAULT_CACHE_LINE_SIZE 16 Comment suggests this is a configuration we don't use with 64bit. ------------------------------------------------------------------------------ src/cpu/sparc/vm/globals_sparc.hpp 59 // Stack slots are 2X larger in LP64 than in the 32 bit VM. Comment seems dead now. ------------------------------------------------------------------------------ src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp There are a lot of operations here that are for dispatching on 32/64. Some of them may be worth keeping for documentation purposes, but some might be better off being removed. That kind of cleanup should probably wait for a later RFE though. ------------------------------------------------------------------------------ src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp 323 inline intptr_t MacroAssembler::load_pc_address( Register reg, int bytes_to_skip ) { 324 intptr_t thepc = (intptr_t)pc() + 2*BytesPerInstWord + bytes_to_skip; 325 Unimplemented(); Presumably never called in 64bit mode. ------------------------------------------------------------------------------ src/cpu/sparc/vm/sparc.ad 314 // 64-bit build means 64-bit pointers means hi/lo pairs "64-bit build means" seems superfluous now. ------------------------------------------------------------------------------ src/cpu/sparc/vm/sparc.ad 355 // 32-bit, longs in 1 register: cannot use I's and L's. Restrict to O's and G's. Comment seems superfluous now. ------------------------------------------------------------------------------ src/cpu/sparc/vm/sparc.ad 1856 // Note that we if-def off of _LP64. 1857 // The relevant question is how the int is callee-saved. In _LP64 1858 // the whole long is written but de-opt'ing will have to extract 1859 // the relevant 32 bits, in not-_LP64 only the low 32 bits is written. The commentary here needs some updating; there is no not-_LP64 anymore. ------------------------------------------------------------------------------ src/cpu/sparc/vm/sparc.ad 1947 // The intptr_t operand types, defined by textual substitution. 1948 // (Cf. opto/type.hpp. This lets us avoid many, many other ifdefs.) These comments suggest there are further cleanup opportunities, probably for a later RFE. ------------------------------------------------------------------------------ src/cpu/sparc/vm/stubGenerator_sparc.cpp Removed block starting with: 831 #if defined(ASSERT) && defined(_LP64) That looks like an incorrect removal. ------------------------------------------------------------------------------ src/cpu/sparc/vm/stubGenerator_sparc.cpp 1232 if (!aligned) 1233 { Please move the { to line 1232. ------------------------------------------------------------------------------ src/cpu/sparc/vm/stubGenerator_sparc.cpp 1334 } else 1335 { Please move the { to line 1334. ------------------------------------------------------------------------------ src/cpu/sparc/vm/stubGenerator_sparc.cpp 1445 if (!aligned) 1446 { Please move the { to line 1445. ------------------------------------------------------------------------------ src/cpu/sparc/vm/stubGenerator_sparc.cpp 1562 if (!aligned) { 1563 // align to 8 bytes, we know we are 4 byte aligned to start 1564 __ andcc(to, 7, G0); 1565 __ br(Assembler::zero, false, Assembler::pt, L_fill_32_bytes); 1566 __ delayed()->nop(); 1567 __ stw(value, to, 0); 1568 __ inc(to, 4); 1569 __ dec(count, 1 << shift); 1570 __ BIND(L_fill_32_bytes); 1571 } Please fix the indentation. ------------------------------------------------------------------------------ src/cpu/sparc/vm/stubGenerator_sparc.cpp 1777 } else 1778 { Please move the { to line 1777. ------------------------------------------------------------------------------ src/cpu/sparc/vm/stubGenerator_sparc.cpp 1887 if (!aligned) 1888 { Please move the { to line 1887. ------------------------------------------------------------------------------ src/cpu/sparc/vm/stubGenerator_sparc.cpp 3085 } else 3086 { Please move the { to line 3085. ------------------------------------------------------------------------------ src/cpu/sparc/vm/stubGenerator_sparc.cpp 5103 // Write the high part of the address 5104 // [RGV] Check if there is a dependency on the size of this prolog Pre-existing: These comments seem mis-indented. I wonder who RGV is, and how old this comment is. ------------------------------------------------------------------------------ src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp 60 // The sethi() instruction generates lots more instructions when shell 61 // stack limit is unlimited, so that's why this is much bigger. "why this is much bigger" ? than what? Oh, the 32bit value. Some revision of comment is called for here. ------------------------------------------------------------------------------ src/cpu/sparc/vm/vm_version_sparc.cpp 73 // 32-bit oops don't make sense for the 64-bit VM on sparc 74 // since the 32-bit VM has the same registers and smaller objects. This comment probably needs updating. ------------------------------------------------------------------------------ src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.hpp 166 #if defined(COMPILER2) || defined(_LP64) and 228 #endif // _LP64 || COMPILER2 I think the _LP64 parts of these can be removed. ------------------------------------------------------------------------------ src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.hpp 57 #ifdef _GNU_SOURCE For a future clenaup, Solaris Studio now supports the gcc-style inline assembler being protected by this #ifdef. We could probably eliminate the alternative definitions, though if we're not already using the inline versions they will need to be carefully examined first. ------------------------------------------------------------------------------ src/os_cpu/solaris_sparc/vm/prefetch_solaris_sparc.inline.hpp 30 #if defined(COMPILER2) || defined(_LP64) and 58 #endif // defined(COMPILER2) || defined(_LP64) I think the _LP64 parts of these can be removed. ------------------------------------------------------------------------------ From aph at redhat.com Sat Apr 15 09:15:03 2017 From: aph at redhat.com (Andrew Haley) Date: Sat, 15 Apr 2017 10:15:03 +0100 Subject: RFR(XS) 8178047: Aliasing problem with raw memory accesses In-Reply-To: References: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> Message-ID: On 14/04/17 19:04, Igor Veresov wrote: > It might be a problem with a test attached to the bug (it also needs b.capacity() / 4 in floss(), otherwise it would throw), but I don?t see vectorization happening at all. With or without my fix. Lack of vectorization is OK for now: the thing I'm trying to ensure is that it doesn't get worse. Thanks, Andrew. From kim.barrett at oracle.com Sat Apr 15 18:21:04 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 15 Apr 2017 14:21:04 -0400 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: <8C096D6B-AFEB-44BD-ACDF-0709E04300A9@oracle.com> References: <8C096D6B-AFEB-44BD-ACDF-0709E04300A9@oracle.com> Message-ID: <13DE06DC-3370-4B94-B063-C1EE3E9E2B7A@oracle.com> > On Apr 15, 2017, at 4:27 AM, Kim Barrett wrote: > src/cpu/sparc/vm/globalDefinitions_sparc.hpp > 43 #elif defined(COMPILER1) > 44 // pure C1, 32-bit, small machine > 45 #define DEFAULT_CACHE_LINE_SIZE 16 > > Comment suggests this is a configuration we don't use with 64bit. And if we did, the resulting value seems suspect. But someone with more knowledge than I have should figure out what should really be done here. It's not the kind of mostly mechanical change that this RFE is about. > src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.hpp > 166 #if defined(COMPILER2) || defined(_LP64) > and > 228 #endif // _LP64 || COMPILER2 > > I think the _LP64 parts of these can be removed. That was wrong of me. As written, the #if/#endif can be just removed. It would be a change to remove just the _LP64 part. OTOH, the comment at the head of the protected section suggests this is mostly for sparc-v8 support, and I believe we don't support that anymore, so further cleanup perhaps to be had here, in some different RFE. (Assuming I'm remembering correctly that we no longer support v8, is there an existing RFE for that cleanup?) > src/os_cpu/solaris_sparc/vm/prefetch_solaris_sparc.inline.hpp > 30 #if defined(COMPILER2) || defined(_LP64) > and > 58 #endif // defined(COMPILER2) || defined(_LP64) > > I think the _LP64 parts of these can be removed. As with the one above, this comment is similarly wrong. From aph at redhat.com Sun Apr 16 10:03:18 2017 From: aph at redhat.com (Andrew Haley) Date: Sun, 16 Apr 2017 11:03:18 +0100 Subject: RFR(S): 8178811: Minimize the AVX <-> SSE transition penalty on x86 In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A63CD479B@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A63CD479B@ORSMSX106.amr.corp.intel.com> Message-ID: Hi, On 14/04/17 19:17, Deshpande, Vivek R wrote: > This fix minimizes the AVX to SSE and SSE to AVX transition penalty > through generation of vzeroupper instruction. This looks like a performance enhancement, rather than a bug. Is JDK 9 still open for performance enhancement? I thought we were in rampdown, but the report is targeted to 9. Andrew. From dmitry.samersoff at oracle.com Sun Apr 16 10:36:33 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 16 Apr 2017 13:36:33 +0300 Subject: RFR(S) 8178731: compiler/ciReplay/SABase.java does not compile In-Reply-To: References: <4c83e586-1c10-1bae-eb18-6d6b1b7bd286@oracle.com> Message-ID: <6c2abd5f-6df5-e4ee-74a9-aafc0575eea0@oracle.com> Katya, Looks good to me. -Dmitry On 2017-04-15 01:54, Igor Ignatyev wrote: > Hi Katya, > > looks good to me. since it also changes svc tests, I cc'ed svc-dev alias. > > Thanks, > -- Igor > >> On Apr 14, 2017, at 3:52 PM, Ekaterina Pavlova wrote: >> >> Hi everyone, >> >> Please review this small change that fixes hotspot/test/compiler/ciReplay/SABase.java >> This file used ProcessHandle.getPid() which was recently renamed in ProcessHandle.pid() >> as part of JDK-8178347. >> Also fixed test/serviceability/sa/sadebugd/SADebugDTest.java which had the same issue. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8178731 >> webrev: http://cr.openjdk.java.net/~iignatyev/epavlova/8178731/webrev.00/ >> >> Tested by running jprt. >> >> thanks, >> -katya >> >> p.s. >> Igor Ignatyev volunteered to sponsor this change. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From aph at redhat.com Sun Apr 16 13:16:45 2017 From: aph at redhat.com (Andrew Haley) Date: Sun, 16 Apr 2017 14:16:45 +0100 Subject: RFR(S): 8178811: Minimize the AVX <-> SSE transition penalty on x86 In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A63CD479B@ORSMSX106.amr.corp.intel.com> Message-ID: <93630e55-28ec-91aa-17f1-67354661903c@redhat.com> I'm sorry: my reply sounded terribly mean spirited but I didn't intend it to be. 3% on an important benchmark is certainly worth having, and I'd support the patch for that reason. I'm just confused about what is allowed: for example, there are a couple of missing vector patterns in AArch64.ad, but I haven't posted the fix because we're in rampdown. Andrew. From igor.veresov at oracle.com Sun Apr 16 18:23:30 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 16 Apr 2017 11:23:30 -0700 Subject: RFR(S) 8178731: compiler/ciReplay/SABase.java does not compile In-Reply-To: References: Message-ID: <0980B347-D6E1-42AC-B64A-59BB667760E2@oracle.com> Looks good. igor > On Apr 14, 2017, at 3:48 PM, Ekaterina Pavlova wrote: > > Hi everyone, > > Please review this small change that fixes hotspot/test/compiler/ciReplay/SABase.java > This file used ProcessHandle.getPid() which was recently renamed in ProcessHandle.pid() > as part of JDK-8178347. > Also fixed test/serviceability/sa/sadebugd/SADebugDTest.java which had the same issue. > > bug: https://bugs.openjdk.java.net/browse/JDK-8178731 > webrev: http://cr.openjdk.java.net/~iignatyev/epavlova/8178731/webrev.00/ > > Tested by running jprt. > > thanks, > -katya > > p.s. > Igor Ignatyev volunteered to sponsor this change. From vladimir.kozlov at oracle.com Mon Apr 17 04:30:21 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 16 Apr 2017 21:30:21 -0700 Subject: RFR(S): 8178811: Minimize the AVX <-> SSE transition penalty on x86 In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A63CD479B@ORSMSX106.amr.corp.intel.com> Message-ID: <16b9ac5c-25cb-193d-4b6f-e6d3c9a95651@oracle.com> What is important is 'Fix version'. 'Affected version' could be all current and previous releases. From the beginning I thought it is targeting JDK 10. To avoid confusion I set 'Fix version' to 10. It may go into 9 Update as other small enchantments. Regards, Vladimir On 4/16/17 3:03 AM, Andrew Haley wrote: > Hi, > > On 14/04/17 19:17, Deshpande, Vivek R wrote: > >> This fix minimizes the AVX to SSE and SSE to AVX transition penalty >> through generation of vzeroupper instruction. > > This looks like a performance enhancement, rather than a bug. Is JDK > 9 still open for performance enhancement? I thought we were in > rampdown, but the report is targeted to 9. > > Andrew. > From igor.veresov at oracle.com Mon Apr 17 21:08:38 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 17 Apr 2017 14:08:38 -0700 Subject: RFR(XXL) 8178864: Update Graal Message-ID: <008050D5-DEC7-4117-8EEF-B77BF3E22B24@oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8178864 Webrev: http://cr.openjdk.java.net/~iveresov/8178864/webrev.00/ Thanks, igor p.s. Changes: commit 415a4ef635029f49ab2c4fef0e6f2012be916db7 Merge: 768caab 294900b Author: Tom Rodriguez Date: Mon Apr 17 10:36:23 2017 -0700 [GR-3667] Fix probability for intrinsic guard. commit 294900b270c2f866a9a33a3a027a63ba85562792 Author: Tom Rodriguez Date: Fri Apr 14 10:00:47 2017 -0700 Fix probability for intrinsic guard commit 768caabc4aad572e7fa8a08e708b81eaf9c8e119 Merge: c3ab66a 78f5562 Author: Doug Simon Date: Mon Apr 17 09:06:14 2017 -0700 [GR-3673] Remove forced dumps. commit c3ab66a7fb72311ed479d0f47b87cf867453915d Merge: 4d1095d 9a66f88 Author: Tom Rodriguez Date: Mon Apr 17 09:01:21 2017 -0700 [GR-3657] Fix possible infinite loop in nodesInLoopBranch. commit 9a66f887d1f6c8308f15c8c8df7c40578923369c Author: Tom Rodriguez Date: Thu Apr 13 21:20:49 2017 -0700 Fix possible infinite loop in nodesInLoopBranch commit 78f55621c9301ae9c6e6e5b8d0d3fab7c2e4de6c Author: Doug Simon Date: Mon Apr 17 10:41:29 2017 +0200 removed uses of Debug.forceDump that pollute test logs commit 4d1095d1ea9fc4c317c7f584a02344e64df7a5f3 Merge: 02a2a3d cf9a623 Author: Christian Wimmer Date: Fri Apr 14 10:25:21 2017 -0700 [GR-3666] Remove redundant final modifier as reported by newest Checkstyle version. commit cf9a6238a826e77c94ab0602c2214b0f0afd1aa6 Author: Christian Wimmer Date: Fri Apr 14 09:02:55 2017 -0700 Remove redundant final modifier as reported by newest Checkstyle version commit 02a2a3d9ba60c5db87c83c701a500e41d79583b2 Merge: e8acaea 92a1821 Author: Josef Eisl Date: Fri Apr 14 02:24:54 2017 -0700 [GR-3206] The parallel scala actors fix should not overwrite the other results. commit e8acaea4d026244a187e50f9f39206730473da30 Merge: 52a9ed9 fa1e93f Author: Doug Simon Date: Thu Apr 13 07:57:55 2017 -0700 [GR-3627] Correct various errors in code generation (#267). commit 52a9ed925be5511d7984174136d07a2568cd83e5 Merge: 0c30850 fc12456 Author: Matthias Grimmer Date: Thu Apr 13 07:04:06 2017 -0700 [GR-3642] Explicit hosted (e.g. hosted-graal-core) jvm-config. commit 92a18214d2279ab421c15300d46bab93cac90619 Author: Josef Eisl Date: Thu Apr 13 15:51:51 2017 +0200 [ci,fix] the parallel scala actors fix should not overwrite the other results commit fa1e93f806c16dfe79b79cc0932b5d2bbea342c4 Merge: 425a9c4 f1f981e Author: Doug Simon Date: Thu Apr 13 15:27:39 2017 +0200 Merge. commit fc12456b4e654a51009b07d1ff437622bcc5e2b7 Author: Matthias Grimmer Date: Thu Apr 13 11:27:16 2017 +0200 Add hosted configurations to mx benchmark. commit 0c30850da9fcf74d0b08e3e53f4a99e036294d30 Merge: f1f981e fdf7341 Author: Roland Schatz Date: Thu Apr 13 04:11:34 2017 -0700 [GR-3629] Fix wrong callRootMethod in GraalTestTVMCI. commit 425a9c4e4d346b1018786d02ba3d9d0a6433cae4 Author: Andrew Dinn Date: Wed Apr 12 15:43:56 2017 +0100 fix problem in emit for CompressRegister and Uncompressregister commit fdf7341635824a7c6eb3b7be908dd74372aa4736 Author: Roland Schatz Date: Wed Apr 12 15:50:26 2017 +0200 Fix wrong callRootMethod in GraalTestTVMCI. commit 1c0da37a2cff42a9b46cdfad40d9ccc932e948cb Author: Andrew Dinn Date: Wed Apr 12 14:53:56 2017 +0100 correct cut-and-pasteo in original patch commit cb8ee4804de9bec5eea213470bd237a83c981cac Author: Andrew Dinn Date: Wed Apr 12 13:50:36 2017 +0100 correct two small errors in code generation commit f1f981e8002fa6de2989fc223d67d7589d11c0c0 Merge: 1e9c29d 3685425 Author: Doug Simon Date: Wed Apr 12 04:46:39 2017 -0700 [GR-3598] Remove use of JDK internal API in CompileTheWorld. commit 1e9c29d7bd62ddb5b0180d081db7b9230ea9383d Merge: 8b0ff79 e01a696 Author: Doug Simon Date: Wed Apr 12 01:46:57 2017 -0700 [GR-3610] Unstrip VM output when running with stripped jars. commit 8b0ff796db6d6d5eae4711f3740b9ec18b68a284 Merge: dde444f 78aecaa Author: Paul W?gerer Date: Wed Apr 12 01:19:57 2017 -0700 [GR-3556] Handle inlining during parsing more like inlining after parsing. commit e01a696368522b6965e2a73155881ce873858b1d Author: Doug Simon Date: Tue Apr 11 14:25:13 2017 +0200 apply retrace tool to VM output if running with stripped jars commit 368542591c5d5d0547774cf556217f38b4fd162d Author: Doug Simon Date: Mon Apr 10 17:17:00 2017 +0200 moved CompileTheWorld out of GRAAL dist and removed its use of JDK internal API added CTW 9 tests to gate commit 78aecaa0a0ac7bbecbdc820f3393eaf09fddb16e Author: Christian Wimmer Date: Tue Apr 11 13:49:23 2017 -0700 Handle inlining during parsing more like inlining after parsing When a method has multiple returns, inlinig during parsing created a merge frame state with a bci of one of the return bytecodes. Now the handling is the same as in the inlining phase: the merge frame state that does not include the callee (just the caller frame state after the call). commit dde444fdb4608a48b90dacd32719c12efb59f84c Merge: 8c016d0 1d1a3b0 Author: Tom Rodriguez Date: Tue Apr 11 13:49:12 2017 -0700 [GR-3153] Revert Handle placeholder states specially in PEA. commit 1d1a3b0e18c8c0e5499c719d658013967111e875 Author: Tom Rodriguez Date: Tue Apr 11 13:12:10 2017 -0700 Revert Handle placeholder states specially in PEA commit 8c016d06d3c18ce9a62d958bf3bed6b30b997687 Merge: 4c4144b 9735c8c Author: David Leopoldseder Date: Tue Apr 11 10:17:45 2017 -0700 [GR-3476] Remove TruffleCompilationCancellationTest. commit 4c4144b71d527d984637ade1c0ba8f361c326143 Merge: 978c49a a1d0705 Author: Aleksandar Prokopec Date: Tue Apr 11 05:53:09 2017 -0700 [GR-3601] Ensure that a more specific create method is used when creating comparison nodes. commit a1d0705cd0b7f74075208365bd42b78cdaf1eff2 Author: Aleksandar Prokopec Date: Mon Apr 10 17:25:10 2017 +0200 Use more specific create method for comparison nodes. commit 978c49ae5c2b4d9cfb000a4c0917b18ef255857d Merge: d07c8b2 af5dd81 Author: Christian Haeubl Date: Tue Apr 11 05:11:50 2017 -0700 [GR-3595] Cache if a method is covered by an InvocationPlugin. commit af5dd81295c8d7f8070fd051c9848599459afffe Author: Christian Haeubl Date: Mon Apr 10 12:10:23 2017 +0200 Cache if a method is covered by an InvocationPlugin. commit d07c8b25d76f5956d6d7b62849eafc8ba944abe0 Merge: c72a5d5 d53ce49 Author: Vojin Jovanovic Date: Tue Apr 11 03:39:18 2017 -0700 [GR-3393] Revert. commit d53ce499e9ce85de2303e642d17ca069b1a47af2 Author: Vojin Jovanovic Date: Tue Apr 11 11:38:42 2017 +0200 Revert "[GR-3393] Separate compressed oops from HotSpot as much as possible." This reverts commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43, reversing changes made to a872965c61c942ce33fd295a2280dcb54a3b38f4. commit 9735c8c573c1b869b38dbe8cabbf37ebcb82a4e7 Author: David Leopoldseder Date: Tue Apr 11 10:59:33 2017 +0200 [fix] Remove TruffleCompilationCancellationTest. commit c72a5d5e78538cea5d42967b238fe91198c95ae3 Merge: 0b9c9ee 2d18d0a Author: Tom Rodriguez Date: Mon Apr 10 09:38:09 2017 -0700 [GR-3153] Handle placeholder states specially in PEA. commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43 Merge: a872965 eb2ef20 Author: Vojin Jovanovic Date: Mon Apr 10 07:25:07 2017 -0700 [GR-3393] Separate compressed oops from HotSpot as much as possible. commit eb2ef20805d6c24ff4b0dcc9af644a0365cdb926 Author: Vojin Jovanovic Date: Mon Mar 27 17:24:40 2017 +0200 [cleanup] separate compressed oops from HotSpot as much as possible commit a872965c61c942ce33fd295a2280dcb54a3b38f4 Merge: 448e5d8 2722294 Author: Josef Eisl Date: Mon Apr 10 03:14:51 2017 -0700 [GR-3581] Set machine node for parallel benchmarks. commit 27222942948eb21a3be34a3bec1c7aa03d11aed3 Author: Josef Eisl Date: Mon Apr 10 10:45:16 2017 +0200 [ci] add MACHINE_NODE to parallel benchmarks commit 448e5d899e46c37e3800c92ffa9fdb69f5c5307c Merge: 7cc4f5d 24dba6b Author: Josef Eisl Date: Mon Apr 10 01:24:11 2017 -0700 [GR-3525] Refine LIR dumping. commit 24dba6b3d9fe7472cb8cd50d00e3b95c0e9118f3 Author: Josef Eisl Date: Fri Apr 7 17:48:49 2017 +0200 [fix] consolidate stack slot allocation dumping commit d2eacbdc80797f3032ee7a8de383e957b68aef9c Author: Josef Eisl Date: Fri Apr 7 17:41:33 2017 +0200 [fix] consolidate linear scan dumping commit cbe02790cad450e1fb2af010fc3e56bb87ddd99e Author: Josef Eisl Date: Fri Apr 7 16:38:57 2017 +0200 [fix] consolidate TraceRA dumping commit 55490c13f6274258b4ca339e30775097e8a97c1c Author: Josef Eisl Date: Fri Apr 7 16:13:18 2017 +0200 [fix] Remove useless scopes and dumps from emitLIR commit 3f8355da125f50efb0180fdf9c019ae70234db14 Author: Josef Eisl Date: Fri Apr 7 15:25:24 2017 +0200 [feature] Dump LIR stages in GraalCompiler commit 9c56f54ed009c9d93e0cb3f967f00c03c82028f2 Author: Josef Eisl Date: Fri Apr 7 15:24:49 2017 +0200 [doc] document LIR dumping levels commit 7cc4f5dcea60bf0dabca37ef28eb97c378e494db Merge: 9edeefc c6fe486 Author: Aleksandar Prokopec Date: Fri Apr 7 12:35:10 2017 -0700 [GR-3551] Add early canonicalization to IntegerEqualsNode and ObjectEqualsNode. commit c6fe4861464787def1c5eb66842b3ad843285a55 Merge: 8948675 9edeefc Author: Aleksandar Prokopec Date: Fri Apr 7 19:24:18 2017 +0200 Merge branch 'master' into topic/GR-3551 commit 9edeefc2b6635d97c571c41a3708a2d90ae1ab3a Merge: 8a0a87e c152e63 Author: Josef Eisl Date: Fri Apr 7 09:27:55 2017 -0700 [GR-3206] Do not execute scala-dacapo actors in parallel. commit 8a0a87eb63cbbc94c8cead115921f96a69d6869b Merge: 633e409 5282a7c Author: Roland Schatz Date: Fri Apr 7 06:00:40 2017 -0700 [GR-3583] Update truffle import. commit 5282a7c3ffa0cbd0505a3825c718fee32ac1a202 Author: Roland Schatz Date: Fri Apr 7 13:32:00 2017 +0200 Update truffle import. commit 633e40969f800a2231e5f7e7747f8eb812ebeb6e Merge: d8d8c22 2bac7bc Author: Christian Haeubl Date: Fri Apr 7 02:08:18 2017 -0700 [GR-3435] Cache JVMCI call results during graph decoding. commit 2bac7bcfcac159d4e7c5b63ab64a83b48b91300b Author: Christian Haeubl Date: Thu Mar 30 17:10:55 2017 +0200 Cache methods while doing graph decoding. commit 10968ad0ed8432049ee937170df8fbf075807427 Author: Christian Haeubl Date: Thu Mar 30 14:32:15 2017 +0200 Cache annotations while doing graph decoding. commit d8d8c22904a4cee00988356183e16aaac6cf4e01 Merge: 0ea748e 5a50222 Author: Josef Eisl Date: Thu Apr 6 09:39:21 2017 -0700 [GR-3515] Explicitly specify phases for compile time benchmarks. commit 89486753b1c8ba3dd85e259eef60556c84b43873 Merge: cca4aa3 65e6110 Author: Aleksandar Prokopec Date: Thu Apr 6 17:16:00 2017 +0200 Merge branch 'master' into topic/GR-3551 commit 0ea748e92d0ef075da80234cb6e8f2181c55ac88 Merge: 65e6110 c60b383 Author: Roland Schatz Date: Thu Apr 6 08:06:18 2017 -0700 [GR-3169] Graal produces wrong code for HeapByteBuffer on JDK9. commit cca4aa3eb4377d132cd314a57ff03b8cd7c21d61 Merge: b7cb98d ccd2af9 Author: Aleksandar Prokopec Date: Thu Apr 6 15:16:19 2017 +0200 Merge branch 'master' into topic/GR-3551 commit c152e63aaa3b0d00d714f33dfbf1c01a14e72acc Author: Josef Eisl Date: Thu Apr 6 16:37:51 2017 +0200 [ci] do not execute scala-dacapo actors in parallel commit 65e61109f0edc70864767b200ae33a660c6e8dcb Merge: 429d5da 57189f6 Author: Doug Simon Date: Thu Apr 6 06:58:52 2017 -0700 [GR-3557] Fix regression in reading options from a file. commit c60b3830dc4765f2fd7f4d3f2dd85380bc6861e1 Author: Roland Schatz Date: Thu Apr 6 15:36:10 2017 +0200 Fix escape analysis of byte array in HeapByteBuffer on JDK 9. commit 429d5da9377ac9f0951e472a93f68ad7d2fd40c8 Merge: ccd2af9 926fe31 Author: Gilles Duboscq Date: Thu Apr 6 06:11:27 2017 -0700 [GR-3522] Canonicalize `NormalizeCompare < 1`. commit b7cb98d8b43d92ce1a7591e05fc7e5e0c6e453ec Author: Aleksandar Prokopec Date: Thu Apr 6 15:00:37 2017 +0200 Rewire node creation for CompareNode subclasses and add static creation methods that invoke canonicalization. commit ccd2af9473a022c66eb399d34db22986a4a1b00e Merge: 01222aa 7f3278c Author: David Leopoldseder Date: Thu Apr 6 05:17:49 2017 -0700 [GR-3568] NodeCostDumpUtil: swallow errors during class loading of nodes. commit 57189f612c106a041ecc4a79c82360c43ca581eb Author: Doug Simon Date: Wed Apr 5 22:18:24 2017 +0200 fixed regression of handling options in a file commit 7f3278c8530a10d64c9d2e9d5c7c1525847655eb Author: David Leopoldseder Date: Thu Apr 6 12:48:59 2017 +0200 [fix] NodeCostDumpUtil: swallow errors during class loading of nodes. commit 926fe31632e616776659c289f9376781647b98a1 Author: Gilles Duboscq Date: Thu Apr 6 13:10:00 2017 +0200 Canonicalize `NormalizeCompare == c` commit 3a72610a51ba874a81c5b7dcd4a5b4dc13aece3b Author: Gilles Duboscq Date: Tue Apr 4 19:38:10 2017 +0200 [GR-3522] Canonicalize `NormalizeCompare < 1` commit 01222aa50cd049253da87b18d9b86aa1fa8958f6 Merge: 8145122 7c59459 Author: Roland Schatz Date: Thu Apr 6 03:17:24 2017 -0700 [GR-2925] Graal support for Truffle TestTVMCI. commit 5a502228765bcf2a8f5243708a8c6de0fdad3f15 Author: Josef Eisl Date: Wed Apr 5 16:49:57 2017 +0200 [ci] restrict TimingBenchmarkMixin timers commit bbcd46991b0b776eb69df17e2130ad9c5e095cab Author: Josef Eisl Date: Tue Apr 4 13:34:26 2017 +0200 [ci] use -Dgraaldebug.timer.XXX instead of -Dgraal.Time= for TimingBenchmarkMixin commit 4974eb04f4ee81dc48e68eacc505b8e7524c91eb Author: Josef Eisl Date: Tue Apr 4 13:23:30 2017 +0200 [ci] outsource timerArgs in TimingBenchmarkMixin commit 81451226de18cbe2ccb1f2f23c2110a5cf874169 Merge: 2fc6719 42650bb Author: David Leopoldseder Date: Thu Apr 6 01:20:45 2017 -0700 [GR-2552] NodeCost Model Improvements. commit 2fc6719fec619137e9e82d74be3c802341761790 Merge: 7f32177 b1f5952 Author: Josef Eisl Date: Thu Apr 6 00:46:25 2017 -0700 [GR-3514] Register allocation sub-phases do not need to be proper LIRPhases. commit 2d18d0a330c3123f9e62851580a2e18aed231697 Author: Tom Rodriguez Date: Wed Apr 5 23:56:50 2017 -0700 Handle placeholder states specially in PEA commit 42650bbebbb8d89c66d5517cb761f9e92c1f68cf Author: David Leopoldseder Date: Tue Feb 21 15:58:33 2017 +0100 [fix] NodeCost: Ensure all nodes specify default costs. commit caf972182c4bd958f658185520e32e88843b200d Author: David Leopoldseder Date: Mon Feb 20 09:46:56 2017 +0100 [feature] NodeCosts: Verify node cost model integrity in CheckGraalInvariants. commit 7cd39f545c0db26610dc12eb37364b3d3265ec99 Author: David Leopoldseder Date: Mon Jan 30 11:05:11 2017 +0100 [fix] NodeCosts: Remove provider, move dynamic logic into nodes and fix scale. commit fde0d24a2dddaf45e46cf6dc1dcade625261c5e3 Author: David Leopoldseder Date: Mon Jan 30 15:46:45 2017 +0100 [feature] NodeCosts: Add option to dump node cost related information to IGV. commit e72bbb87cb4ec9b08f1ee9de9546a2166a5db54d Author: David Leopoldseder Date: Mon Jan 30 15:08:01 2017 +0100 [feature] NodeCost: Add dump util to dump costs of all node classes commit 7f32177fad91fedabefea6e9919aa5f51657481b Merge: 2eacdb3 ba5773e Author: Doug Simon Date: Wed Apr 5 13:32:29 2017 -0700 [GR-3528] Convert some assertions in Node to guarantees. commit 63f10a5f38680435c750232702d183f05ad7e67f Merge: cce0b88 2eacdb3 Author: Aleksandar Prokopec Date: Wed Apr 5 21:47:11 2017 +0200 Merge branch 'master' into topic/GR-3551 commit 2eacdb37f19de982e14d1bb6ea224d2c5ad0c0cc Merge: ee4cbef ba57d4d Author: Doug Simon Date: Wed Apr 5 11:38:14 2017 -0700 [GR-3521] GraphBuilder: Change semantic of append to be recursive & remove recursiveAppend. commit ba57d4d7f716e5698e040196f9eeb03e2b4d42c5 Merge: 48d9d36 ee4cbef Author: Doug Simon Date: Wed Apr 5 19:45:58 2017 +0200 Merge branch 'master' into topic/GR-3521 commit cce0b8820624ff627b999a743ff9274e1ee5f9af Author: Aleksandar Prokopec Date: Wed Apr 5 17:31:13 2017 +0200 Make LowerOp extends CompareOp from CompareNode. commit 41f62af348083b11684927a5222f92abead5bfec Author: Aleksandar Prokopec Date: Wed Apr 5 17:13:44 2017 +0200 Introduce CompareOp to CompareNode. commit ba5773e0575c5d18974b8bc0470c0fc306161075 Author: Doug Simon Date: Tue Apr 4 21:21:32 2017 +0200 deprecated varargs version of GraalError.guarantee and replaced with fixed arg versions commit bc448373357aa8825a2cca6be86d0573a8442f17 Author: Doug Simon Date: Tue Apr 4 21:20:41 2017 +0200 converted some assertions in Node to be guarantees commit 48d9d363d0e78dad51d1b5a6c87ddbfe6df4cece Author: David Leopoldseder Date: Wed Apr 5 10:07:43 2017 +0200 [fix] GraphBuilder: Change semantic of append to be recursive & remove recursiveAppend commit ee4cbef108f34b17b55ffab2100a59b9b3529881 Merge: 898a31a ce55244 Author: Aleksandar Prokopec Date: Wed Apr 5 02:55:54 2017 -0700 [GR-3208] Apply node plugins during graph decoding. commit ce55244ca5f6304c3c0a83233976f3fa7af852f4 Merge: 3e99694 898a31a Author: Aleksandar Prokopec Date: Wed Apr 5 11:08:41 2017 +0200 Merge branch 'master' into topic/GR-3208 commit b1f595227b39ea9017a62129780fd8eddd8ffb64 Author: Josef Eisl Date: Tue Apr 4 15:44:19 2017 +0200 [fix] LSRA subphases do not need to be AllocationPhases commit 4898e53ab808bf5a0f92da49705743d6da55fd46 Author: Josef Eisl Date: Tue Apr 4 15:54:36 2017 +0200 [fix] TraceRA: TraceLinearScanAllocationPhase is no TraceAllocationPhase commit 3e99694c859bc1e1243dd0cb2ffdeb52b3364a8a Author: Aleksandar Prokopec Date: Mon Apr 3 11:10:37 2017 +0200 Move graph builder context allocation to relevant branches, and document the graph builder context subclass. commit f80747fbabf07d9b0b276e9f6db00629dcd2cd1e Merge: ac63293 2de905e Author: Aleksandar Prokopec Date: Fri Mar 31 16:01:10 2017 +0200 Merge branch 'master' into topic/GR-3208 commit 7c5945907a5e4c5737dd2dcbd52e4af9eb44cce5 Author: Roland Schatz Date: Fri Mar 31 12:09:05 2017 +0200 Graal support for Truffle TestTVMCI. commit ac63293ed26263d161b0b0ba4b9fcce767f54899 Merge: 61436b1 14702f0 Author: Aleksandar Prokopec Date: Thu Mar 30 11:50:05 2017 +0200 Merge branch 'master' into topic/GR-3208 commit 61436b1743ea8d785e186fda82ce1d9e5f51334c Merge: 9a18509 acbd663 Author: Aleksandar Prokopec Date: Thu Mar 30 11:49:10 2017 +0200 Merge branch 'master' into topic/GR-3208 commit 9a18509ff88b8cd184f0f53bb363460741fd0328 Author: Aleksandar Prokopec Date: Fri Mar 24 12:11:41 2017 +0100 Ensure that node plugins passed to the graph decoder handle all relevant node types. commit cacbd1effa1f1466c8d8b4978bd1d78b8d8b6941 Author: Aleksandar Prokopec Date: Fri Mar 24 10:46:03 2017 +0100 Add overridable hook for instantiating node plugins. commit a71e6a7326a6a97d129734e22410993951aff00f Author: Aleksandar Prokopec Date: Thu Mar 23 15:26:01 2017 +0100 Add on-demand handling of load-indexed nodes. commit d9165694fb9c486c6d05aafddcace65e55a4bf8e Merge: e36255e f304652 Author: Aleksandar Prokopec Date: Thu Mar 23 14:12:55 2017 +0100 Merge branch 'master' into topic/GR-3208-alternative commit e36255e119b994ddca01a54d5fc1c3976935eaf3 Author: Aleksandar Prokopec Date: Fri Mar 17 11:29:34 2017 +0100 [refactor] Remove CompositeNodePlugin and use NodePlugin arrays instead. commit 859d2e0fe86cae9933fbc6ae71a7ccbad196baff Author: Aleksandar Prokopec Date: Tue Mar 14 15:55:18 2017 +0100 [feature] Add support for all the node plugin cases to graph decoding. commit e45ae3f1fb381d505351e23ff1bfe5fa1faf97c6 Author: Aleksandar Prokopec Date: Tue Mar 14 12:29:13 2017 +0100 [fix] Prevent node plugin graph changes when not necessary. commit f8589ed80ce1f759ae14cd7ee314b0f4d82e4cc4 Author: Aleksandar Prokopec Date: Mon Mar 13 17:16:31 2017 +0100 [feature] Add node plugins to graph decoder, and implement the handleLoadIndexed case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Apr 17 23:17:23 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Apr 2017 16:17:23 -0700 Subject: RFR(XXL) 8178864: Update Graal In-Reply-To: <008050D5-DEC7-4117-8EEF-B77BF3E22B24@oracle.com> References: <008050D5-DEC7-4117-8EEF-B77BF3E22B24@oracle.com> Message-ID: <5b5aa9f3-ae17-0491-9852-f9ca9c4d4f2b@oracle.com> Good. Thanks, Vladimir On 4/17/17 2:08 PM, Igor Veresov wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8178864 > Webrev: http://cr.openjdk.java.net/~iveresov/8178864/webrev.00/ > > Thanks, > igor > > p.s. > > Changes: > > commit 415a4ef635029f49ab2c4fef0e6f2012be916db7 > Merge: 768caab 294900b > Author: Tom Rodriguez > > Date: Mon Apr 17 10:36:23 2017 -0700 > > [GR-3667] Fix probability for intrinsic guard. > > commit 294900b270c2f866a9a33a3a027a63ba85562792 > Author: Tom Rodriguez > > Date: Fri Apr 14 10:00:47 2017 -0700 > > Fix probability for intrinsic guard > > commit 768caabc4aad572e7fa8a08e708b81eaf9c8e119 > Merge: c3ab66a 78f5562 > Author: Doug Simon > > Date: Mon Apr 17 09:06:14 2017 -0700 > > [GR-3673] Remove forced dumps. > > commit c3ab66a7fb72311ed479d0f47b87cf867453915d > Merge: 4d1095d 9a66f88 > Author: Tom Rodriguez > > Date: Mon Apr 17 09:01:21 2017 -0700 > > [GR-3657] Fix possible infinite loop in nodesInLoopBranch. > > commit 9a66f887d1f6c8308f15c8c8df7c40578923369c > Author: Tom Rodriguez > > Date: Thu Apr 13 21:20:49 2017 -0700 > > Fix possible infinite loop in nodesInLoopBranch > > commit 78f55621c9301ae9c6e6e5b8d0d3fab7c2e4de6c > Author: Doug Simon > > Date: Mon Apr 17 10:41:29 2017 +0200 > > removed uses of Debug.forceDump that pollute test logs > > commit 4d1095d1ea9fc4c317c7f584a02344e64df7a5f3 > Merge: 02a2a3d cf9a623 > Author: Christian Wimmer > > Date: Fri Apr 14 10:25:21 2017 -0700 > > [GR-3666] Remove redundant final modifier as reported by newest > Checkstyle version. > > commit cf9a6238a826e77c94ab0602c2214b0f0afd1aa6 > Author: Christian Wimmer > > Date: Fri Apr 14 09:02:55 2017 -0700 > > Remove redundant final modifier as reported by newest Checkstyle version > > commit 02a2a3d9ba60c5db87c83c701a500e41d79583b2 > Merge: e8acaea 92a1821 > Author: Josef Eisl > > Date: Fri Apr 14 02:24:54 2017 -0700 > > [GR-3206] The parallel scala actors fix should not overwrite the > other results. > > commit e8acaea4d026244a187e50f9f39206730473da30 > Merge: 52a9ed9 fa1e93f > Author: Doug Simon > > Date: Thu Apr 13 07:57:55 2017 -0700 > > [GR-3627] Correct various errors in code generation (#267). > > commit 52a9ed925be5511d7984174136d07a2568cd83e5 > Merge: 0c30850 fc12456 > Author: Matthias Grimmer > > Date: Thu Apr 13 07:04:06 2017 -0700 > > [GR-3642] Explicit hosted (e.g. hosted-graal-core) jvm-config. > > commit 92a18214d2279ab421c15300d46bab93cac90619 > Author: Josef Eisl > > Date: Thu Apr 13 15:51:51 2017 +0200 > > [ci,fix] the parallel scala actors fix should not overwrite the > other results > > commit fa1e93f806c16dfe79b79cc0932b5d2bbea342c4 > Merge: 425a9c4 f1f981e > Author: Doug Simon > > Date: Thu Apr 13 15:27:39 2017 +0200 > > Merge. > > commit fc12456b4e654a51009b07d1ff437622bcc5e2b7 > Author: Matthias Grimmer > > Date: Thu Apr 13 11:27:16 2017 +0200 > > Add hosted configurations to mx benchmark. > > commit 0c30850da9fcf74d0b08e3e53f4a99e036294d30 > Merge: f1f981e fdf7341 > Author: Roland Schatz > > Date: Thu Apr 13 04:11:34 2017 -0700 > > [GR-3629] Fix wrong callRootMethod in GraalTestTVMCI. > > commit 425a9c4e4d346b1018786d02ba3d9d0a6433cae4 > Author: Andrew Dinn > > Date: Wed Apr 12 15:43:56 2017 +0100 > > fix problem in emit for CompressRegister and Uncompressregister > > commit fdf7341635824a7c6eb3b7be908dd74372aa4736 > Author: Roland Schatz > > Date: Wed Apr 12 15:50:26 2017 +0200 > > Fix wrong callRootMethod in GraalTestTVMCI. > > commit 1c0da37a2cff42a9b46cdfad40d9ccc932e948cb > Author: Andrew Dinn > > Date: Wed Apr 12 14:53:56 2017 +0100 > > correct cut-and-pasteo in original patch > > commit cb8ee4804de9bec5eea213470bd237a83c981cac > Author: Andrew Dinn > > Date: Wed Apr 12 13:50:36 2017 +0100 > > correct two small errors in code generation > > commit f1f981e8002fa6de2989fc223d67d7589d11c0c0 > Merge: 1e9c29d 3685425 > Author: Doug Simon > > Date: Wed Apr 12 04:46:39 2017 -0700 > > [GR-3598] Remove use of JDK internal API in CompileTheWorld. > > commit 1e9c29d7bd62ddb5b0180d081db7b9230ea9383d > Merge: 8b0ff79 e01a696 > Author: Doug Simon > > Date: Wed Apr 12 01:46:57 2017 -0700 > > [GR-3610] Unstrip VM output when running with stripped jars. > > commit 8b0ff796db6d6d5eae4711f3740b9ec18b68a284 > Merge: dde444f 78aecaa > Author: Paul W?gerer > > Date: Wed Apr 12 01:19:57 2017 -0700 > > [GR-3556] Handle inlining during parsing more like inlining after > parsing. > > commit e01a696368522b6965e2a73155881ce873858b1d > Author: Doug Simon > > Date: Tue Apr 11 14:25:13 2017 +0200 > > apply retrace tool to VM output if running with stripped jars > > commit 368542591c5d5d0547774cf556217f38b4fd162d > Author: Doug Simon > > Date: Mon Apr 10 17:17:00 2017 +0200 > > moved CompileTheWorld out of GRAAL dist and removed its use of JDK > internal API > added CTW 9 tests to gate > > commit 78aecaa0a0ac7bbecbdc820f3393eaf09fddb16e > Author: Christian Wimmer > > Date: Tue Apr 11 13:49:23 2017 -0700 > > Handle inlining during parsing more like inlining after parsing > > When a method has multiple returns, inlinig during parsing created a > merge frame state with a bci of one of the return bytecodes. Now the > handling is the same as in the inlining phase: the merge frame state > that does not include the callee (just the caller frame state after the > call). > > commit dde444fdb4608a48b90dacd32719c12efb59f84c > Merge: 8c016d0 1d1a3b0 > Author: Tom Rodriguez > > Date: Tue Apr 11 13:49:12 2017 -0700 > > [GR-3153] Revert Handle placeholder states specially in PEA. > > commit 1d1a3b0e18c8c0e5499c719d658013967111e875 > Author: Tom Rodriguez > > Date: Tue Apr 11 13:12:10 2017 -0700 > > Revert Handle placeholder states specially in PEA > > commit 8c016d06d3c18ce9a62d958bf3bed6b30b997687 > Merge: 4c4144b 9735c8c > Author: David Leopoldseder > > Date: Tue Apr 11 10:17:45 2017 -0700 > > [GR-3476] Remove TruffleCompilationCancellationTest. > > commit 4c4144b71d527d984637ade1c0ba8f361c326143 > Merge: 978c49a a1d0705 > Author: Aleksandar Prokopec > > Date: Tue Apr 11 05:53:09 2017 -0700 > > [GR-3601] Ensure that a more specific create method is used when > creating comparison nodes. > > commit a1d0705cd0b7f74075208365bd42b78cdaf1eff2 > Author: Aleksandar Prokopec > > Date: Mon Apr 10 17:25:10 2017 +0200 > > Use more specific create method for comparison nodes. > > commit 978c49ae5c2b4d9cfb000a4c0917b18ef255857d > Merge: d07c8b2 af5dd81 > Author: Christian Haeubl > > Date: Tue Apr 11 05:11:50 2017 -0700 > > [GR-3595] Cache if a method is covered by an InvocationPlugin. > > commit af5dd81295c8d7f8070fd051c9848599459afffe > Author: Christian Haeubl > > Date: Mon Apr 10 12:10:23 2017 +0200 > > Cache if a method is covered by an InvocationPlugin. > > commit d07c8b25d76f5956d6d7b62849eafc8ba944abe0 > Merge: c72a5d5 d53ce49 > Author: Vojin Jovanovic > > Date: Tue Apr 11 03:39:18 2017 -0700 > > [GR-3393] Revert. > > commit d53ce499e9ce85de2303e642d17ca069b1a47af2 > Author: Vojin Jovanovic > > Date: Tue Apr 11 11:38:42 2017 +0200 > > Revert "[GR-3393] Separate compressed oops from HotSpot as much as > possible." > > This reverts commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43, reversing > changes made to a872965c61c942ce33fd295a2280dcb54a3b38f4. > > commit 9735c8c573c1b869b38dbe8cabbf37ebcb82a4e7 > Author: David Leopoldseder > > Date: Tue Apr 11 10:59:33 2017 +0200 > > [fix] Remove TruffleCompilationCancellationTest. > > commit c72a5d5e78538cea5d42967b238fe91198c95ae3 > Merge: 0b9c9ee 2d18d0a > Author: Tom Rodriguez > > Date: Mon Apr 10 09:38:09 2017 -0700 > > [GR-3153] Handle placeholder states specially in PEA. > > commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43 > Merge: a872965 eb2ef20 > Author: Vojin Jovanovic > > Date: Mon Apr 10 07:25:07 2017 -0700 > > [GR-3393] Separate compressed oops from HotSpot as much as possible. > > commit eb2ef20805d6c24ff4b0dcc9af644a0365cdb926 > Author: Vojin Jovanovic > > Date: Mon Mar 27 17:24:40 2017 +0200 > > [cleanup] separate compressed oops from HotSpot as much as possible > > commit a872965c61c942ce33fd295a2280dcb54a3b38f4 > Merge: 448e5d8 2722294 > Author: Josef Eisl > > Date: Mon Apr 10 03:14:51 2017 -0700 > > [GR-3581] Set machine node for parallel benchmarks. > > commit 27222942948eb21a3be34a3bec1c7aa03d11aed3 > Author: Josef Eisl > > Date: Mon Apr 10 10:45:16 2017 +0200 > > [ci] add MACHINE_NODE to parallel benchmarks > > commit 448e5d899e46c37e3800c92ffa9fdb69f5c5307c > Merge: 7cc4f5d 24dba6b > Author: Josef Eisl > > Date: Mon Apr 10 01:24:11 2017 -0700 > > [GR-3525] Refine LIR dumping. > > commit 24dba6b3d9fe7472cb8cd50d00e3b95c0e9118f3 > Author: Josef Eisl > > Date: Fri Apr 7 17:48:49 2017 +0200 > > [fix] consolidate stack slot allocation dumping > > commit d2eacbdc80797f3032ee7a8de383e957b68aef9c > Author: Josef Eisl > > Date: Fri Apr 7 17:41:33 2017 +0200 > > [fix] consolidate linear scan dumping > > commit cbe02790cad450e1fb2af010fc3e56bb87ddd99e > Author: Josef Eisl > > Date: Fri Apr 7 16:38:57 2017 +0200 > > [fix] consolidate TraceRA dumping > > commit 55490c13f6274258b4ca339e30775097e8a97c1c > Author: Josef Eisl > > Date: Fri Apr 7 16:13:18 2017 +0200 > > [fix] Remove useless scopes and dumps from emitLIR > > commit 3f8355da125f50efb0180fdf9c019ae70234db14 > Author: Josef Eisl > > Date: Fri Apr 7 15:25:24 2017 +0200 > > [feature] Dump LIR stages in GraalCompiler > > commit 9c56f54ed009c9d93e0cb3f967f00c03c82028f2 > Author: Josef Eisl > > Date: Fri Apr 7 15:24:49 2017 +0200 > > [doc] document LIR dumping levels > > commit 7cc4f5dcea60bf0dabca37ef28eb97c378e494db > Merge: 9edeefc c6fe486 > Author: Aleksandar Prokopec > > Date: Fri Apr 7 12:35:10 2017 -0700 > > [GR-3551] Add early canonicalization to IntegerEqualsNode and > ObjectEqualsNode. > > commit c6fe4861464787def1c5eb66842b3ad843285a55 > Merge: 8948675 9edeefc > Author: Aleksandar Prokopec > > Date: Fri Apr 7 19:24:18 2017 +0200 > > Merge branch 'master' into topic/GR-3551 > > commit 9edeefc2b6635d97c571c41a3708a2d90ae1ab3a > Merge: 8a0a87e c152e63 > Author: Josef Eisl > > Date: Fri Apr 7 09:27:55 2017 -0700 > > [GR-3206] Do not execute scala-dacapo actors in parallel. > > commit 8a0a87eb63cbbc94c8cead115921f96a69d6869b > Merge: 633e409 5282a7c > Author: Roland Schatz > > Date: Fri Apr 7 06:00:40 2017 -0700 > > [GR-3583] Update truffle import. > > commit 5282a7c3ffa0cbd0505a3825c718fee32ac1a202 > Author: Roland Schatz > > Date: Fri Apr 7 13:32:00 2017 +0200 > > Update truffle import. > > commit 633e40969f800a2231e5f7e7747f8eb812ebeb6e > Merge: d8d8c22 2bac7bc > Author: Christian Haeubl > > Date: Fri Apr 7 02:08:18 2017 -0700 > > [GR-3435] Cache JVMCI call results during graph decoding. > > commit 2bac7bcfcac159d4e7c5b63ab64a83b48b91300b > Author: Christian Haeubl > > Date: Thu Mar 30 17:10:55 2017 +0200 > > Cache methods while doing graph decoding. > > commit 10968ad0ed8432049ee937170df8fbf075807427 > Author: Christian Haeubl > > Date: Thu Mar 30 14:32:15 2017 +0200 > > Cache annotations while doing graph decoding. > > commit d8d8c22904a4cee00988356183e16aaac6cf4e01 > Merge: 0ea748e 5a50222 > Author: Josef Eisl > > Date: Thu Apr 6 09:39:21 2017 -0700 > > [GR-3515] Explicitly specify phases for compile time benchmarks. > > commit 89486753b1c8ba3dd85e259eef60556c84b43873 > Merge: cca4aa3 65e6110 > Author: Aleksandar Prokopec > > Date: Thu Apr 6 17:16:00 2017 +0200 > > Merge branch 'master' into topic/GR-3551 > > commit 0ea748e92d0ef075da80234cb6e8f2181c55ac88 > Merge: 65e6110 c60b383 > Author: Roland Schatz > > Date: Thu Apr 6 08:06:18 2017 -0700 > > [GR-3169] Graal produces wrong code for HeapByteBuffer on JDK9. > > commit cca4aa3eb4377d132cd314a57ff03b8cd7c21d61 > Merge: b7cb98d ccd2af9 > Author: Aleksandar Prokopec > > Date: Thu Apr 6 15:16:19 2017 +0200 > > Merge branch 'master' into topic/GR-3551 > > commit c152e63aaa3b0d00d714f33dfbf1c01a14e72acc > Author: Josef Eisl > > Date: Thu Apr 6 16:37:51 2017 +0200 > > [ci] do not execute scala-dacapo actors in parallel > > commit 65e61109f0edc70864767b200ae33a660c6e8dcb > Merge: 429d5da 57189f6 > Author: Doug Simon > > Date: Thu Apr 6 06:58:52 2017 -0700 > > [GR-3557] Fix regression in reading options from a file. > > commit c60b3830dc4765f2fd7f4d3f2dd85380bc6861e1 > Author: Roland Schatz > > Date: Thu Apr 6 15:36:10 2017 +0200 > > Fix escape analysis of byte array in HeapByteBuffer on JDK 9. > > commit 429d5da9377ac9f0951e472a93f68ad7d2fd40c8 > Merge: ccd2af9 926fe31 > Author: Gilles Duboscq > > Date: Thu Apr 6 06:11:27 2017 -0700 > > [GR-3522] Canonicalize `NormalizeCompare < 1`. > > commit b7cb98d8b43d92ce1a7591e05fc7e5e0c6e453ec > Author: Aleksandar Prokopec > > Date: Thu Apr 6 15:00:37 2017 +0200 > > Rewire node creation for CompareNode subclasses and add static > creation methods that invoke canonicalization. > > commit ccd2af9473a022c66eb399d34db22986a4a1b00e > Merge: 01222aa 7f3278c > Author: David Leopoldseder > > Date: Thu Apr 6 05:17:49 2017 -0700 > > [GR-3568] NodeCostDumpUtil: swallow errors during class loading of > nodes. > > commit 57189f612c106a041ecc4a79c82360c43ca581eb > Author: Doug Simon > > Date: Wed Apr 5 22:18:24 2017 +0200 > > fixed regression of handling options in a file > > commit 7f3278c8530a10d64c9d2e9d5c7c1525847655eb > Author: David Leopoldseder > > Date: Thu Apr 6 12:48:59 2017 +0200 > > [fix] NodeCostDumpUtil: swallow errors during class loading of nodes. > > commit 926fe31632e616776659c289f9376781647b98a1 > Author: Gilles Duboscq > > Date: Thu Apr 6 13:10:00 2017 +0200 > > Canonicalize `NormalizeCompare == c` > > commit 3a72610a51ba874a81c5b7dcd4a5b4dc13aece3b > Author: Gilles Duboscq > > Date: Tue Apr 4 19:38:10 2017 +0200 > > [GR-3522] Canonicalize `NormalizeCompare < 1` > > commit 01222aa50cd049253da87b18d9b86aa1fa8958f6 > Merge: 8145122 7c59459 > Author: Roland Schatz > > Date: Thu Apr 6 03:17:24 2017 -0700 > > [GR-2925] Graal support for Truffle TestTVMCI. > > commit 5a502228765bcf2a8f5243708a8c6de0fdad3f15 > Author: Josef Eisl > > Date: Wed Apr 5 16:49:57 2017 +0200 > > [ci] restrict TimingBenchmarkMixin timers > > commit bbcd46991b0b776eb69df17e2130ad9c5e095cab > Author: Josef Eisl > > Date: Tue Apr 4 13:34:26 2017 +0200 > > [ci] use -Dgraaldebug.timer.XXX instead of -Dgraal.Time= for > TimingBenchmarkMixin > > commit 4974eb04f4ee81dc48e68eacc505b8e7524c91eb > Author: Josef Eisl > > Date: Tue Apr 4 13:23:30 2017 +0200 > > [ci] outsource timerArgs in TimingBenchmarkMixin > > commit 81451226de18cbe2ccb1f2f23c2110a5cf874169 > Merge: 2fc6719 42650bb > Author: David Leopoldseder > > Date: Thu Apr 6 01:20:45 2017 -0700 > > [GR-2552] NodeCost Model Improvements. > > commit 2fc6719fec619137e9e82d74be3c802341761790 > Merge: 7f32177 b1f5952 > Author: Josef Eisl > > Date: Thu Apr 6 00:46:25 2017 -0700 > > [GR-3514] Register allocation sub-phases do not need to be proper > LIRPhases. > > commit 2d18d0a330c3123f9e62851580a2e18aed231697 > Author: Tom Rodriguez > > Date: Wed Apr 5 23:56:50 2017 -0700 > > Handle placeholder states specially in PEA > > commit 42650bbebbb8d89c66d5517cb761f9e92c1f68cf > Author: David Leopoldseder > > Date: Tue Feb 21 15:58:33 2017 +0100 > > [fix] NodeCost: Ensure all nodes specify default costs. > > commit caf972182c4bd958f658185520e32e88843b200d > Author: David Leopoldseder > > Date: Mon Feb 20 09:46:56 2017 +0100 > > [feature] NodeCosts: Verify node cost model integrity in > CheckGraalInvariants. > > commit 7cd39f545c0db26610dc12eb37364b3d3265ec99 > Author: David Leopoldseder > > Date: Mon Jan 30 11:05:11 2017 +0100 > > [fix] NodeCosts: Remove provider, move dynamic logic into nodes and > fix scale. > > commit fde0d24a2dddaf45e46cf6dc1dcade625261c5e3 > Author: David Leopoldseder > > Date: Mon Jan 30 15:46:45 2017 +0100 > > [feature] NodeCosts: Add option to dump node cost related > information to IGV. > > commit e72bbb87cb4ec9b08f1ee9de9546a2166a5db54d > Author: David Leopoldseder > > Date: Mon Jan 30 15:08:01 2017 +0100 > > [feature] NodeCost: Add dump util to dump costs of all node classes > > commit 7f32177fad91fedabefea6e9919aa5f51657481b > Merge: 2eacdb3 ba5773e > Author: Doug Simon > > Date: Wed Apr 5 13:32:29 2017 -0700 > > [GR-3528] Convert some assertions in Node to guarantees. > > commit 63f10a5f38680435c750232702d183f05ad7e67f > Merge: cce0b88 2eacdb3 > Author: Aleksandar Prokopec > > Date: Wed Apr 5 21:47:11 2017 +0200 > > Merge branch 'master' into topic/GR-3551 > > commit 2eacdb37f19de982e14d1bb6ea224d2c5ad0c0cc > Merge: ee4cbef ba57d4d > Author: Doug Simon > > Date: Wed Apr 5 11:38:14 2017 -0700 > > [GR-3521] GraphBuilder: Change semantic of append to be recursive & > remove recursiveAppend. > > commit ba57d4d7f716e5698e040196f9eeb03e2b4d42c5 > Merge: 48d9d36 ee4cbef > Author: Doug Simon > > Date: Wed Apr 5 19:45:58 2017 +0200 > > Merge branch 'master' into topic/GR-3521 > > commit cce0b8820624ff627b999a743ff9274e1ee5f9af > Author: Aleksandar Prokopec > > Date: Wed Apr 5 17:31:13 2017 +0200 > > Make LowerOp extends CompareOp from CompareNode. > > commit 41f62af348083b11684927a5222f92abead5bfec > Author: Aleksandar Prokopec > > Date: Wed Apr 5 17:13:44 2017 +0200 > > Introduce CompareOp to CompareNode. > > commit ba5773e0575c5d18974b8bc0470c0fc306161075 > Author: Doug Simon > > Date: Tue Apr 4 21:21:32 2017 +0200 > > deprecated varargs version of GraalError.guarantee and replaced with > fixed arg versions > > commit bc448373357aa8825a2cca6be86d0573a8442f17 > Author: Doug Simon > > Date: Tue Apr 4 21:20:41 2017 +0200 > > converted some assertions in Node to be guarantees > > commit 48d9d363d0e78dad51d1b5a6c87ddbfe6df4cece > Author: David Leopoldseder > > Date: Wed Apr 5 10:07:43 2017 +0200 > > [fix] GraphBuilder: Change semantic of append to be recursive & > remove recursiveAppend > > commit ee4cbef108f34b17b55ffab2100a59b9b3529881 > Merge: 898a31a ce55244 > Author: Aleksandar Prokopec > > Date: Wed Apr 5 02:55:54 2017 -0700 > > [GR-3208] Apply node plugins during graph decoding. > > commit ce55244ca5f6304c3c0a83233976f3fa7af852f4 > Merge: 3e99694 898a31a > Author: Aleksandar Prokopec > > Date: Wed Apr 5 11:08:41 2017 +0200 > > Merge branch 'master' into topic/GR-3208 > > commit b1f595227b39ea9017a62129780fd8eddd8ffb64 > Author: Josef Eisl > > Date: Tue Apr 4 15:44:19 2017 +0200 > > [fix] LSRA subphases do not need to be AllocationPhases > > commit 4898e53ab808bf5a0f92da49705743d6da55fd46 > Author: Josef Eisl > > Date: Tue Apr 4 15:54:36 2017 +0200 > > [fix] TraceRA: TraceLinearScanAllocationPhase is no TraceAllocationPhase > > commit 3e99694c859bc1e1243dd0cb2ffdeb52b3364a8a > Author: Aleksandar Prokopec > > Date: Mon Apr 3 11:10:37 2017 +0200 > > Move graph builder context allocation to relevant branches, and > document the graph builder context subclass. > > commit f80747fbabf07d9b0b276e9f6db00629dcd2cd1e > Merge: ac63293 2de905e > Author: Aleksandar Prokopec > > Date: Fri Mar 31 16:01:10 2017 +0200 > > Merge branch 'master' into topic/GR-3208 > > commit 7c5945907a5e4c5737dd2dcbd52e4af9eb44cce5 > Author: Roland Schatz > > Date: Fri Mar 31 12:09:05 2017 +0200 > > Graal support for Truffle TestTVMCI. > > commit ac63293ed26263d161b0b0ba4b9fcce767f54899 > Merge: 61436b1 14702f0 > Author: Aleksandar Prokopec > > Date: Thu Mar 30 11:50:05 2017 +0200 > > Merge branch 'master' into topic/GR-3208 > > commit 61436b1743ea8d785e186fda82ce1d9e5f51334c > Merge: 9a18509 acbd663 > Author: Aleksandar Prokopec > > Date: Thu Mar 30 11:49:10 2017 +0200 > > Merge branch 'master' into topic/GR-3208 > > commit 9a18509ff88b8cd184f0f53bb363460741fd0328 > Author: Aleksandar Prokopec > > Date: Fri Mar 24 12:11:41 2017 +0100 > > Ensure that node plugins passed to the graph decoder handle all > relevant node types. > > commit cacbd1effa1f1466c8d8b4978bd1d78b8d8b6941 > Author: Aleksandar Prokopec > > Date: Fri Mar 24 10:46:03 2017 +0100 > > Add overridable hook for instantiating node plugins. > > commit a71e6a7326a6a97d129734e22410993951aff00f > Author: Aleksandar Prokopec > > Date: Thu Mar 23 15:26:01 2017 +0100 > > Add on-demand handling of load-indexed nodes. > > commit d9165694fb9c486c6d05aafddcace65e55a4bf8e > Merge: e36255e f304652 > Author: Aleksandar Prokopec > > Date: Thu Mar 23 14:12:55 2017 +0100 > > Merge branch 'master' into topic/GR-3208-alternative > > commit e36255e119b994ddca01a54d5fc1c3976935eaf3 > Author: Aleksandar Prokopec > > Date: Fri Mar 17 11:29:34 2017 +0100 > > [refactor] Remove CompositeNodePlugin and use NodePlugin arrays instead. > > commit 859d2e0fe86cae9933fbc6ae71a7ccbad196baff > Author: Aleksandar Prokopec > > Date: Tue Mar 14 15:55:18 2017 +0100 > > [feature] Add support for all the node plugin cases to graph decoding. > > commit e45ae3f1fb381d505351e23ff1bfe5fa1faf97c6 > Author: Aleksandar Prokopec > > Date: Tue Mar 14 12:29:13 2017 +0100 > > [fix] Prevent node plugin graph changes when not necessary. > > commit f8589ed80ce1f759ae14cd7ee314b0f4d82e4cc4 > Author: Aleksandar Prokopec > > Date: Mon Mar 13 17:16:31 2017 +0100 > > [feature] Add node plugins to graph decoder, and implement the > handleLoadIndexed case. > From david.holmes at oracle.com Tue Apr 18 02:16:37 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Apr 2017 12:16:37 +1000 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: References: Message-ID: <43aed67c-27f7-bbbd-25b3-194a034ff029@oracle.com> Redirecting to hotspot-compiler-dev, please do not reply to jdk9-dev. Thanks, David On 18/04/2017 11:43 AM, Yuting Chen wrote: > If I moved the infinite loop to any other method (e.g., main), the > class can then be compiled. I guess jaotc runs clinit when it compiles > clinit. > > On Mon, Apr 17, 2017 at 6:14 PM, Yuting Chen wrote: >> Hi, I recently met a problem: when I tried to compile a class whose >> clinit method contains an infinite loop, the aotc waits and fails to >> response.... >> >> It seems that the aotc performs some static analysis before the >> compilation, while the analysis may not stop (when an infinite loop is >> there). >> >> The bytecode is shown as follows: >> >> public class Vector1 >> minor version: 0 >> major version: 52 >> flags: ACC_PUBLIC, ACC_SUPER >> Constant pool: >> #1 = Utf8 Vector1 >> #2 = Class #1 // Vector1 >> #3 = Utf8 java/lang/Object >> #4 = Class #3 // java/lang/Object >> #5 = Utf8 serialVersionUID >> #6 = Utf8 J >> #7 = Long -2767605614048989439l >> #9 = Utf8 >> #10 = Utf8 ()V >> #11 = NameAndType #5:#6 // serialVersionUID:J >> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >> #13 = Utf8 main >> #14 = Utf8 ([Ljava/lang/String;)V >> #15 = Utf8 ConstantValue >> #16 = Utf8 Code >> #17 = Utf8 StackMapTable >> { >> public static {}; >> descriptor: ()V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=2, locals=0, args_size=0 >> 0: ldc2_w #7 // long -2767605614048989439l >> 3: putstatic #12 // Field serialVersionUID:J >> 6: iconst_1 >> 7: iconst_m1 >> 8: iadd >> 9: ifge 0 >> 12: return >> StackMapTable: number_of_entries = 1 >> frame_type = 0 /* same */ >> >> public static void main(java.lang.String[]); >> descriptor: ([Ljava/lang/String;)V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=0, locals=1, args_size=1 >> 0: return >> } From igor.veresov at oracle.com Tue Apr 18 03:15:27 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 17 Apr 2017 20:15:27 -0700 Subject: RFR(XXL) 8178864: Update Graal In-Reply-To: <5b5aa9f3-ae17-0491-9852-f9ca9c4d4f2b@oracle.com> References: <008050D5-DEC7-4117-8EEF-B77BF3E22B24@oracle.com> <5b5aa9f3-ae17-0491-9852-f9ca9c4d4f2b@oracle.com> Message-ID: <4560279E-F9BC-4488-8C0E-D65A20F4FB88@oracle.com> Thanks, Vladimir! igor > On Apr 17, 2017, at 4:17 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 4/17/17 2:08 PM, Igor Veresov wrote: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8178864 >> Webrev: http://cr.openjdk.java.net/~iveresov/8178864/webrev.00/ >> >> Thanks, >> igor >> >> p.s. >> >> Changes: >> >> commit 415a4ef635029f49ab2c4fef0e6f2012be916db7 >> Merge: 768caab 294900b >> Author: Tom Rodriguez > > >> Date: Mon Apr 17 10:36:23 2017 -0700 >> >> [GR-3667] Fix probability for intrinsic guard. >> >> commit 294900b270c2f866a9a33a3a027a63ba85562792 >> Author: Tom Rodriguez > > >> Date: Fri Apr 14 10:00:47 2017 -0700 >> >> Fix probability for intrinsic guard >> >> commit 768caabc4aad572e7fa8a08e708b81eaf9c8e119 >> Merge: c3ab66a 78f5562 >> Author: Doug Simon > >> Date: Mon Apr 17 09:06:14 2017 -0700 >> >> [GR-3673] Remove forced dumps. >> >> commit c3ab66a7fb72311ed479d0f47b87cf867453915d >> Merge: 4d1095d 9a66f88 >> Author: Tom Rodriguez > > >> Date: Mon Apr 17 09:01:21 2017 -0700 >> >> [GR-3657] Fix possible infinite loop in nodesInLoopBranch. >> >> commit 9a66f887d1f6c8308f15c8c8df7c40578923369c >> Author: Tom Rodriguez > > >> Date: Thu Apr 13 21:20:49 2017 -0700 >> >> Fix possible infinite loop in nodesInLoopBranch >> >> commit 78f55621c9301ae9c6e6e5b8d0d3fab7c2e4de6c >> Author: Doug Simon > >> Date: Mon Apr 17 10:41:29 2017 +0200 >> >> removed uses of Debug.forceDump that pollute test logs >> >> commit 4d1095d1ea9fc4c317c7f584a02344e64df7a5f3 >> Merge: 02a2a3d cf9a623 >> Author: Christian Wimmer > > >> Date: Fri Apr 14 10:25:21 2017 -0700 >> >> [GR-3666] Remove redundant final modifier as reported by newest >> Checkstyle version. >> >> commit cf9a6238a826e77c94ab0602c2214b0f0afd1aa6 >> Author: Christian Wimmer > > >> Date: Fri Apr 14 09:02:55 2017 -0700 >> >> Remove redundant final modifier as reported by newest Checkstyle version >> >> commit 02a2a3d9ba60c5db87c83c701a500e41d79583b2 >> Merge: e8acaea 92a1821 >> Author: Josef Eisl > > >> Date: Fri Apr 14 02:24:54 2017 -0700 >> >> [GR-3206] The parallel scala actors fix should not overwrite the >> other results. >> >> commit e8acaea4d026244a187e50f9f39206730473da30 >> Merge: 52a9ed9 fa1e93f >> Author: Doug Simon > >> Date: Thu Apr 13 07:57:55 2017 -0700 >> >> [GR-3627] Correct various errors in code generation (#267). >> >> commit 52a9ed925be5511d7984174136d07a2568cd83e5 >> Merge: 0c30850 fc12456 >> Author: Matthias Grimmer > > >> Date: Thu Apr 13 07:04:06 2017 -0700 >> >> [GR-3642] Explicit hosted (e.g. hosted-graal-core) jvm-config. >> >> commit 92a18214d2279ab421c15300d46bab93cac90619 >> Author: Josef Eisl > >> Date: Thu Apr 13 15:51:51 2017 +0200 >> >> [ci,fix] the parallel scala actors fix should not overwrite the >> other results >> >> commit fa1e93f806c16dfe79b79cc0932b5d2bbea342c4 >> Merge: 425a9c4 f1f981e >> Author: Doug Simon > >> Date: Thu Apr 13 15:27:39 2017 +0200 >> >> Merge. >> >> commit fc12456b4e654a51009b07d1ff437622bcc5e2b7 >> Author: Matthias Grimmer > > >> Date: Thu Apr 13 11:27:16 2017 +0200 >> >> Add hosted configurations to mx benchmark. >> >> commit 0c30850da9fcf74d0b08e3e53f4a99e036294d30 >> Merge: f1f981e fdf7341 >> Author: Roland Schatz > > >> Date: Thu Apr 13 04:11:34 2017 -0700 >> >> [GR-3629] Fix wrong callRootMethod in GraalTestTVMCI. >> >> commit 425a9c4e4d346b1018786d02ba3d9d0a6433cae4 >> Author: Andrew Dinn > >> Date: Wed Apr 12 15:43:56 2017 +0100 >> >> fix problem in emit for CompressRegister and Uncompressregister >> >> commit fdf7341635824a7c6eb3b7be908dd74372aa4736 >> Author: Roland Schatz > > >> Date: Wed Apr 12 15:50:26 2017 +0200 >> >> Fix wrong callRootMethod in GraalTestTVMCI. >> >> commit 1c0da37a2cff42a9b46cdfad40d9ccc932e948cb >> Author: Andrew Dinn > >> Date: Wed Apr 12 14:53:56 2017 +0100 >> >> correct cut-and-pasteo in original patch >> >> commit cb8ee4804de9bec5eea213470bd237a83c981cac >> Author: Andrew Dinn > >> Date: Wed Apr 12 13:50:36 2017 +0100 >> >> correct two small errors in code generation >> >> commit f1f981e8002fa6de2989fc223d67d7589d11c0c0 >> Merge: 1e9c29d 3685425 >> Author: Doug Simon > >> Date: Wed Apr 12 04:46:39 2017 -0700 >> >> [GR-3598] Remove use of JDK internal API in CompileTheWorld. >> >> commit 1e9c29d7bd62ddb5b0180d081db7b9230ea9383d >> Merge: 8b0ff79 e01a696 >> Author: Doug Simon > >> Date: Wed Apr 12 01:46:57 2017 -0700 >> >> [GR-3610] Unstrip VM output when running with stripped jars. >> >> commit 8b0ff796db6d6d5eae4711f3740b9ec18b68a284 >> Merge: dde444f 78aecaa >> Author: Paul W?gerer > > >> Date: Wed Apr 12 01:19:57 2017 -0700 >> >> [GR-3556] Handle inlining during parsing more like inlining after >> parsing. >> >> commit e01a696368522b6965e2a73155881ce873858b1d >> Author: Doug Simon > >> Date: Tue Apr 11 14:25:13 2017 +0200 >> >> apply retrace tool to VM output if running with stripped jars >> >> commit 368542591c5d5d0547774cf556217f38b4fd162d >> Author: Doug Simon > >> Date: Mon Apr 10 17:17:00 2017 +0200 >> >> moved CompileTheWorld out of GRAAL dist and removed its use of JDK >> internal API >> added CTW 9 tests to gate >> >> commit 78aecaa0a0ac7bbecbdc820f3393eaf09fddb16e >> Author: Christian Wimmer > > >> Date: Tue Apr 11 13:49:23 2017 -0700 >> >> Handle inlining during parsing more like inlining after parsing >> >> When a method has multiple returns, inlinig during parsing created a >> merge frame state with a bci of one of the return bytecodes. Now the >> handling is the same as in the inlining phase: the merge frame state >> that does not include the callee (just the caller frame state after the >> call). >> >> commit dde444fdb4608a48b90dacd32719c12efb59f84c >> Merge: 8c016d0 1d1a3b0 >> Author: Tom Rodriguez > > >> Date: Tue Apr 11 13:49:12 2017 -0700 >> >> [GR-3153] Revert Handle placeholder states specially in PEA. >> >> commit 1d1a3b0e18c8c0e5499c719d658013967111e875 >> Author: Tom Rodriguez > > >> Date: Tue Apr 11 13:12:10 2017 -0700 >> >> Revert Handle placeholder states specially in PEA >> >> commit 8c016d06d3c18ce9a62d958bf3bed6b30b997687 >> Merge: 4c4144b 9735c8c >> Author: David Leopoldseder > > >> Date: Tue Apr 11 10:17:45 2017 -0700 >> >> [GR-3476] Remove TruffleCompilationCancellationTest. >> >> commit 4c4144b71d527d984637ade1c0ba8f361c326143 >> Merge: 978c49a a1d0705 >> Author: Aleksandar Prokopec > > >> Date: Tue Apr 11 05:53:09 2017 -0700 >> >> [GR-3601] Ensure that a more specific create method is used when >> creating comparison nodes. >> >> commit a1d0705cd0b7f74075208365bd42b78cdaf1eff2 >> Author: Aleksandar Prokopec > > >> Date: Mon Apr 10 17:25:10 2017 +0200 >> >> Use more specific create method for comparison nodes. >> >> commit 978c49ae5c2b4d9cfb000a4c0917b18ef255857d >> Merge: d07c8b2 af5dd81 >> Author: Christian Haeubl > > >> Date: Tue Apr 11 05:11:50 2017 -0700 >> >> [GR-3595] Cache if a method is covered by an InvocationPlugin. >> >> commit af5dd81295c8d7f8070fd051c9848599459afffe >> Author: Christian Haeubl > > >> Date: Mon Apr 10 12:10:23 2017 +0200 >> >> Cache if a method is covered by an InvocationPlugin. >> >> commit d07c8b25d76f5956d6d7b62849eafc8ba944abe0 >> Merge: c72a5d5 d53ce49 >> Author: Vojin Jovanovic > > >> Date: Tue Apr 11 03:39:18 2017 -0700 >> >> [GR-3393] Revert. >> >> commit d53ce499e9ce85de2303e642d17ca069b1a47af2 >> Author: Vojin Jovanovic > > >> Date: Tue Apr 11 11:38:42 2017 +0200 >> >> Revert "[GR-3393] Separate compressed oops from HotSpot as much as >> possible." >> >> This reverts commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43, reversing >> changes made to a872965c61c942ce33fd295a2280dcb54a3b38f4. >> >> commit 9735c8c573c1b869b38dbe8cabbf37ebcb82a4e7 >> Author: David Leopoldseder > > >> Date: Tue Apr 11 10:59:33 2017 +0200 >> >> [fix] Remove TruffleCompilationCancellationTest. >> >> commit c72a5d5e78538cea5d42967b238fe91198c95ae3 >> Merge: 0b9c9ee 2d18d0a >> Author: Tom Rodriguez > > >> Date: Mon Apr 10 09:38:09 2017 -0700 >> >> [GR-3153] Handle placeholder states specially in PEA. >> >> commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43 >> Merge: a872965 eb2ef20 >> Author: Vojin Jovanovic > > >> Date: Mon Apr 10 07:25:07 2017 -0700 >> >> [GR-3393] Separate compressed oops from HotSpot as much as possible. >> >> commit eb2ef20805d6c24ff4b0dcc9af644a0365cdb926 >> Author: Vojin Jovanovic > > >> Date: Mon Mar 27 17:24:40 2017 +0200 >> >> [cleanup] separate compressed oops from HotSpot as much as possible >> >> commit a872965c61c942ce33fd295a2280dcb54a3b38f4 >> Merge: 448e5d8 2722294 >> Author: Josef Eisl > > >> Date: Mon Apr 10 03:14:51 2017 -0700 >> >> [GR-3581] Set machine node for parallel benchmarks. >> >> commit 27222942948eb21a3be34a3bec1c7aa03d11aed3 >> Author: Josef Eisl > >> Date: Mon Apr 10 10:45:16 2017 +0200 >> >> [ci] add MACHINE_NODE to parallel benchmarks >> >> commit 448e5d899e46c37e3800c92ffa9fdb69f5c5307c >> Merge: 7cc4f5d 24dba6b >> Author: Josef Eisl > > >> Date: Mon Apr 10 01:24:11 2017 -0700 >> >> [GR-3525] Refine LIR dumping. >> >> commit 24dba6b3d9fe7472cb8cd50d00e3b95c0e9118f3 >> Author: Josef Eisl > >> Date: Fri Apr 7 17:48:49 2017 +0200 >> >> [fix] consolidate stack slot allocation dumping >> >> commit d2eacbdc80797f3032ee7a8de383e957b68aef9c >> Author: Josef Eisl > >> Date: Fri Apr 7 17:41:33 2017 +0200 >> >> [fix] consolidate linear scan dumping >> >> commit cbe02790cad450e1fb2af010fc3e56bb87ddd99e >> Author: Josef Eisl > >> Date: Fri Apr 7 16:38:57 2017 +0200 >> >> [fix] consolidate TraceRA dumping >> >> commit 55490c13f6274258b4ca339e30775097e8a97c1c >> Author: Josef Eisl > >> Date: Fri Apr 7 16:13:18 2017 +0200 >> >> [fix] Remove useless scopes and dumps from emitLIR >> >> commit 3f8355da125f50efb0180fdf9c019ae70234db14 >> Author: Josef Eisl > >> Date: Fri Apr 7 15:25:24 2017 +0200 >> >> [feature] Dump LIR stages in GraalCompiler >> >> commit 9c56f54ed009c9d93e0cb3f967f00c03c82028f2 >> Author: Josef Eisl > >> Date: Fri Apr 7 15:24:49 2017 +0200 >> >> [doc] document LIR dumping levels >> >> commit 7cc4f5dcea60bf0dabca37ef28eb97c378e494db >> Merge: 9edeefc c6fe486 >> Author: Aleksandar Prokopec > > >> Date: Fri Apr 7 12:35:10 2017 -0700 >> >> [GR-3551] Add early canonicalization to IntegerEqualsNode and >> ObjectEqualsNode. >> >> commit c6fe4861464787def1c5eb66842b3ad843285a55 >> Merge: 8948675 9edeefc >> Author: Aleksandar Prokopec > > >> Date: Fri Apr 7 19:24:18 2017 +0200 >> >> Merge branch 'master' into topic/GR-3551 >> >> commit 9edeefc2b6635d97c571c41a3708a2d90ae1ab3a >> Merge: 8a0a87e c152e63 >> Author: Josef Eisl > > >> Date: Fri Apr 7 09:27:55 2017 -0700 >> >> [GR-3206] Do not execute scala-dacapo actors in parallel. >> >> commit 8a0a87eb63cbbc94c8cead115921f96a69d6869b >> Merge: 633e409 5282a7c >> Author: Roland Schatz > > >> Date: Fri Apr 7 06:00:40 2017 -0700 >> >> [GR-3583] Update truffle import. >> >> commit 5282a7c3ffa0cbd0505a3825c718fee32ac1a202 >> Author: Roland Schatz > > >> Date: Fri Apr 7 13:32:00 2017 +0200 >> >> Update truffle import. >> >> commit 633e40969f800a2231e5f7e7747f8eb812ebeb6e >> Merge: d8d8c22 2bac7bc >> Author: Christian Haeubl > > >> Date: Fri Apr 7 02:08:18 2017 -0700 >> >> [GR-3435] Cache JVMCI call results during graph decoding. >> >> commit 2bac7bcfcac159d4e7c5b63ab64a83b48b91300b >> Author: Christian Haeubl > > >> Date: Thu Mar 30 17:10:55 2017 +0200 >> >> Cache methods while doing graph decoding. >> >> commit 10968ad0ed8432049ee937170df8fbf075807427 >> Author: Christian Haeubl > > >> Date: Thu Mar 30 14:32:15 2017 +0200 >> >> Cache annotations while doing graph decoding. >> >> commit d8d8c22904a4cee00988356183e16aaac6cf4e01 >> Merge: 0ea748e 5a50222 >> Author: Josef Eisl > > >> Date: Thu Apr 6 09:39:21 2017 -0700 >> >> [GR-3515] Explicitly specify phases for compile time benchmarks. >> >> commit 89486753b1c8ba3dd85e259eef60556c84b43873 >> Merge: cca4aa3 65e6110 >> Author: Aleksandar Prokopec > > >> Date: Thu Apr 6 17:16:00 2017 +0200 >> >> Merge branch 'master' into topic/GR-3551 >> >> commit 0ea748e92d0ef075da80234cb6e8f2181c55ac88 >> Merge: 65e6110 c60b383 >> Author: Roland Schatz > > >> Date: Thu Apr 6 08:06:18 2017 -0700 >> >> [GR-3169] Graal produces wrong code for HeapByteBuffer on JDK9. >> >> commit cca4aa3eb4377d132cd314a57ff03b8cd7c21d61 >> Merge: b7cb98d ccd2af9 >> Author: Aleksandar Prokopec > > >> Date: Thu Apr 6 15:16:19 2017 +0200 >> >> Merge branch 'master' into topic/GR-3551 >> >> commit c152e63aaa3b0d00d714f33dfbf1c01a14e72acc >> Author: Josef Eisl > >> Date: Thu Apr 6 16:37:51 2017 +0200 >> >> [ci] do not execute scala-dacapo actors in parallel >> >> commit 65e61109f0edc70864767b200ae33a660c6e8dcb >> Merge: 429d5da 57189f6 >> Author: Doug Simon > >> Date: Thu Apr 6 06:58:52 2017 -0700 >> >> [GR-3557] Fix regression in reading options from a file. >> >> commit c60b3830dc4765f2fd7f4d3f2dd85380bc6861e1 >> Author: Roland Schatz > > >> Date: Thu Apr 6 15:36:10 2017 +0200 >> >> Fix escape analysis of byte array in HeapByteBuffer on JDK 9. >> >> commit 429d5da9377ac9f0951e472a93f68ad7d2fd40c8 >> Merge: ccd2af9 926fe31 >> Author: Gilles Duboscq > > >> Date: Thu Apr 6 06:11:27 2017 -0700 >> >> [GR-3522] Canonicalize `NormalizeCompare < 1`. >> >> commit b7cb98d8b43d92ce1a7591e05fc7e5e0c6e453ec >> Author: Aleksandar Prokopec > > >> Date: Thu Apr 6 15:00:37 2017 +0200 >> >> Rewire node creation for CompareNode subclasses and add static >> creation methods that invoke canonicalization. >> >> commit ccd2af9473a022c66eb399d34db22986a4a1b00e >> Merge: 01222aa 7f3278c >> Author: David Leopoldseder > > >> Date: Thu Apr 6 05:17:49 2017 -0700 >> >> [GR-3568] NodeCostDumpUtil: swallow errors during class loading of >> nodes. >> >> commit 57189f612c106a041ecc4a79c82360c43ca581eb >> Author: Doug Simon > >> Date: Wed Apr 5 22:18:24 2017 +0200 >> >> fixed regression of handling options in a file >> >> commit 7f3278c8530a10d64c9d2e9d5c7c1525847655eb >> Author: David Leopoldseder > > >> Date: Thu Apr 6 12:48:59 2017 +0200 >> >> [fix] NodeCostDumpUtil: swallow errors during class loading of nodes. >> >> commit 926fe31632e616776659c289f9376781647b98a1 >> Author: Gilles Duboscq > > >> Date: Thu Apr 6 13:10:00 2017 +0200 >> >> Canonicalize `NormalizeCompare == c` >> >> commit 3a72610a51ba874a81c5b7dcd4a5b4dc13aece3b >> Author: Gilles Duboscq > > >> Date: Tue Apr 4 19:38:10 2017 +0200 >> >> [GR-3522] Canonicalize `NormalizeCompare < 1` >> >> commit 01222aa50cd049253da87b18d9b86aa1fa8958f6 >> Merge: 8145122 7c59459 >> Author: Roland Schatz > > >> Date: Thu Apr 6 03:17:24 2017 -0700 >> >> [GR-2925] Graal support for Truffle TestTVMCI. >> >> commit 5a502228765bcf2a8f5243708a8c6de0fdad3f15 >> Author: Josef Eisl > >> Date: Wed Apr 5 16:49:57 2017 +0200 >> >> [ci] restrict TimingBenchmarkMixin timers >> >> commit bbcd46991b0b776eb69df17e2130ad9c5e095cab >> Author: Josef Eisl > >> Date: Tue Apr 4 13:34:26 2017 +0200 >> >> [ci] use -Dgraaldebug.timer.XXX instead of -Dgraal.Time= for >> TimingBenchmarkMixin >> >> commit 4974eb04f4ee81dc48e68eacc505b8e7524c91eb >> Author: Josef Eisl > >> Date: Tue Apr 4 13:23:30 2017 +0200 >> >> [ci] outsource timerArgs in TimingBenchmarkMixin >> >> commit 81451226de18cbe2ccb1f2f23c2110a5cf874169 >> Merge: 2fc6719 42650bb >> Author: David Leopoldseder > > >> Date: Thu Apr 6 01:20:45 2017 -0700 >> >> [GR-2552] NodeCost Model Improvements. >> >> commit 2fc6719fec619137e9e82d74be3c802341761790 >> Merge: 7f32177 b1f5952 >> Author: Josef Eisl > > >> Date: Thu Apr 6 00:46:25 2017 -0700 >> >> [GR-3514] Register allocation sub-phases do not need to be proper >> LIRPhases. >> >> commit 2d18d0a330c3123f9e62851580a2e18aed231697 >> Author: Tom Rodriguez > > >> Date: Wed Apr 5 23:56:50 2017 -0700 >> >> Handle placeholder states specially in PEA >> >> commit 42650bbebbb8d89c66d5517cb761f9e92c1f68cf >> Author: David Leopoldseder > > >> Date: Tue Feb 21 15:58:33 2017 +0100 >> >> [fix] NodeCost: Ensure all nodes specify default costs. >> >> commit caf972182c4bd958f658185520e32e88843b200d >> Author: David Leopoldseder > > >> Date: Mon Feb 20 09:46:56 2017 +0100 >> >> [feature] NodeCosts: Verify node cost model integrity in >> CheckGraalInvariants. >> >> commit 7cd39f545c0db26610dc12eb37364b3d3265ec99 >> Author: David Leopoldseder > > >> Date: Mon Jan 30 11:05:11 2017 +0100 >> >> [fix] NodeCosts: Remove provider, move dynamic logic into nodes and >> fix scale. >> >> commit fde0d24a2dddaf45e46cf6dc1dcade625261c5e3 >> Author: David Leopoldseder > > >> Date: Mon Jan 30 15:46:45 2017 +0100 >> >> [feature] NodeCosts: Add option to dump node cost related >> information to IGV. >> >> commit e72bbb87cb4ec9b08f1ee9de9546a2166a5db54d >> Author: David Leopoldseder > > >> Date: Mon Jan 30 15:08:01 2017 +0100 >> >> [feature] NodeCost: Add dump util to dump costs of all node classes >> >> commit 7f32177fad91fedabefea6e9919aa5f51657481b >> Merge: 2eacdb3 ba5773e >> Author: Doug Simon > >> Date: Wed Apr 5 13:32:29 2017 -0700 >> >> [GR-3528] Convert some assertions in Node to guarantees. >> >> commit 63f10a5f38680435c750232702d183f05ad7e67f >> Merge: cce0b88 2eacdb3 >> Author: Aleksandar Prokopec > > >> Date: Wed Apr 5 21:47:11 2017 +0200 >> >> Merge branch 'master' into topic/GR-3551 >> >> commit 2eacdb37f19de982e14d1bb6ea224d2c5ad0c0cc >> Merge: ee4cbef ba57d4d >> Author: Doug Simon > >> Date: Wed Apr 5 11:38:14 2017 -0700 >> >> [GR-3521] GraphBuilder: Change semantic of append to be recursive & >> remove recursiveAppend. >> >> commit ba57d4d7f716e5698e040196f9eeb03e2b4d42c5 >> Merge: 48d9d36 ee4cbef >> Author: Doug Simon > >> Date: Wed Apr 5 19:45:58 2017 +0200 >> >> Merge branch 'master' into topic/GR-3521 >> >> commit cce0b8820624ff627b999a743ff9274e1ee5f9af >> Author: Aleksandar Prokopec > > >> Date: Wed Apr 5 17:31:13 2017 +0200 >> >> Make LowerOp extends CompareOp from CompareNode. >> >> commit 41f62af348083b11684927a5222f92abead5bfec >> Author: Aleksandar Prokopec > > >> Date: Wed Apr 5 17:13:44 2017 +0200 >> >> Introduce CompareOp to CompareNode. >> >> commit ba5773e0575c5d18974b8bc0470c0fc306161075 >> Author: Doug Simon > >> Date: Tue Apr 4 21:21:32 2017 +0200 >> >> deprecated varargs version of GraalError.guarantee and replaced with >> fixed arg versions >> >> commit bc448373357aa8825a2cca6be86d0573a8442f17 >> Author: Doug Simon > >> Date: Tue Apr 4 21:20:41 2017 +0200 >> >> converted some assertions in Node to be guarantees >> >> commit 48d9d363d0e78dad51d1b5a6c87ddbfe6df4cece >> Author: David Leopoldseder > > >> Date: Wed Apr 5 10:07:43 2017 +0200 >> >> [fix] GraphBuilder: Change semantic of append to be recursive & >> remove recursiveAppend >> >> commit ee4cbef108f34b17b55ffab2100a59b9b3529881 >> Merge: 898a31a ce55244 >> Author: Aleksandar Prokopec > > >> Date: Wed Apr 5 02:55:54 2017 -0700 >> >> [GR-3208] Apply node plugins during graph decoding. >> >> commit ce55244ca5f6304c3c0a83233976f3fa7af852f4 >> Merge: 3e99694 898a31a >> Author: Aleksandar Prokopec > > >> Date: Wed Apr 5 11:08:41 2017 +0200 >> >> Merge branch 'master' into topic/GR-3208 >> >> commit b1f595227b39ea9017a62129780fd8eddd8ffb64 >> Author: Josef Eisl > >> Date: Tue Apr 4 15:44:19 2017 +0200 >> >> [fix] LSRA subphases do not need to be AllocationPhases >> >> commit 4898e53ab808bf5a0f92da49705743d6da55fd46 >> Author: Josef Eisl > >> Date: Tue Apr 4 15:54:36 2017 +0200 >> >> [fix] TraceRA: TraceLinearScanAllocationPhase is no TraceAllocationPhase >> >> commit 3e99694c859bc1e1243dd0cb2ffdeb52b3364a8a >> Author: Aleksandar Prokopec > > >> Date: Mon Apr 3 11:10:37 2017 +0200 >> >> Move graph builder context allocation to relevant branches, and >> document the graph builder context subclass. >> >> commit f80747fbabf07d9b0b276e9f6db00629dcd2cd1e >> Merge: ac63293 2de905e >> Author: Aleksandar Prokopec > > >> Date: Fri Mar 31 16:01:10 2017 +0200 >> >> Merge branch 'master' into topic/GR-3208 >> >> commit 7c5945907a5e4c5737dd2dcbd52e4af9eb44cce5 >> Author: Roland Schatz > > >> Date: Fri Mar 31 12:09:05 2017 +0200 >> >> Graal support for Truffle TestTVMCI. >> >> commit ac63293ed26263d161b0b0ba4b9fcce767f54899 >> Merge: 61436b1 14702f0 >> Author: Aleksandar Prokopec > > >> Date: Thu Mar 30 11:50:05 2017 +0200 >> >> Merge branch 'master' into topic/GR-3208 >> >> commit 61436b1743ea8d785e186fda82ce1d9e5f51334c >> Merge: 9a18509 acbd663 >> Author: Aleksandar Prokopec > > >> Date: Thu Mar 30 11:49:10 2017 +0200 >> >> Merge branch 'master' into topic/GR-3208 >> >> commit 9a18509ff88b8cd184f0f53bb363460741fd0328 >> Author: Aleksandar Prokopec > > >> Date: Fri Mar 24 12:11:41 2017 +0100 >> >> Ensure that node plugins passed to the graph decoder handle all >> relevant node types. >> >> commit cacbd1effa1f1466c8d8b4978bd1d78b8d8b6941 >> Author: Aleksandar Prokopec > > >> Date: Fri Mar 24 10:46:03 2017 +0100 >> >> Add overridable hook for instantiating node plugins. >> >> commit a71e6a7326a6a97d129734e22410993951aff00f >> Author: Aleksandar Prokopec > > >> Date: Thu Mar 23 15:26:01 2017 +0100 >> >> Add on-demand handling of load-indexed nodes. >> >> commit d9165694fb9c486c6d05aafddcace65e55a4bf8e >> Merge: e36255e f304652 >> Author: Aleksandar Prokopec > > >> Date: Thu Mar 23 14:12:55 2017 +0100 >> >> Merge branch 'master' into topic/GR-3208-alternative >> >> commit e36255e119b994ddca01a54d5fc1c3976935eaf3 >> Author: Aleksandar Prokopec > > >> Date: Fri Mar 17 11:29:34 2017 +0100 >> >> [refactor] Remove CompositeNodePlugin and use NodePlugin arrays instead. >> >> commit 859d2e0fe86cae9933fbc6ae71a7ccbad196baff >> Author: Aleksandar Prokopec > > >> Date: Tue Mar 14 15:55:18 2017 +0100 >> >> [feature] Add support for all the node plugin cases to graph decoding. >> >> commit e45ae3f1fb381d505351e23ff1bfe5fa1faf97c6 >> Author: Aleksandar Prokopec > > >> Date: Tue Mar 14 12:29:13 2017 +0100 >> >> [fix] Prevent node plugin graph changes when not necessary. >> >> commit f8589ed80ce1f759ae14cd7ee314b0f4d82e4cc4 >> Author: Aleksandar Prokopec > > >> Date: Mon Mar 13 17:16:31 2017 +0100 >> >> [feature] Add node plugins to graph decoder, and implement the >> handleLoadIndexed case. >> From zoltan.majo at oracle.com Tue Apr 18 09:30:39 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 18 Apr 2017 11:30:39 +0200 Subject: [9] RFR (S) 8178723: Workaround for failure of CRC32C intrinsic on x86 machines without CLMUL support (JDK-8178720) In-Reply-To: References: <1e62816d-f893-2883-e86a-0b4e68557b28@oracle.com> <3bdf8249-460f-65e6-4e5d-c952712606c0@oracle.com> Message-ID: <61f515e6-70d2-9aac-0223-40637b4c8036@oracle.com> Hi Volker, On 04/13/2017 08:43 PM, Volker Simonis wrote: > Looks good although all the files need an updated copyright line :) thank you for pointing that out. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8178723/webrev.01/ Best regards, Zoltan > > Thanks, > Volker > > > On Thu, Apr 13, 2017 at 5:15 PM, Zolt?n Maj? > wrote: > > > On 04/13/2017 04:54 PM, Zolt?n Maj? wrote: > > [...] > JPRT testing is running at the moment. > > > P.S.: All JPRT tests pass. > > Best regards, > > > Zoltan > > > > Thank you! > > Best regards, > > > Zoltan > > > From zoltan.majo at oracle.com Tue Apr 18 10:21:57 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 18 Apr 2017 12:21:57 +0200 Subject: RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases In-Reply-To: <1FF57C0C-497B-4A87-B9A5-E042FA8BEFB1@sap.com> References: <4D9309E1-AACE-4C22-B567-03C579034BA6@sap.com> <5eb3b253-8a50-bad1-d410-e8ff0f46890a@oracle.com> <91bd6fd4-f85d-d940-9cab-756a72d8b67b@oracle.com> <9943567b-e6d8-f108-1404-865d1038cfb0@oracle.com> <1FF57C0C-497B-4A87-B9A5-E042FA8BEFB1@sap.com> Message-ID: <382b06ea-103d-9ff3-7f38-5f627bc6d91e@oracle.com> Hi Lutz, On 04/13/2017 05:17 PM, Schmidt, Lutz wrote: > Hi Zoltan, > > I really appreciate that the enhanced tests will make their way into JDK 9! > Re. the contributor credentials, I?m confident you will do the right thing. > Getting the bug out of the way is by far more important. Thank you! Best regards, Zoltan > > Regards, Lutz > > > > On 13.04.2017, 16:28, "Zolt?n Maj?" wrote: > > Hi Volker, > > > On 04/13/2017 04:22 PM, Volker Simonis wrote: > > On Thu, Apr 13, 2017 at 3:39 PM, Zolt?n Maj? > > wrote: > > > > Hi Volker, > > Hi Lutz, > > > > > > On 04/13/2017 03:25 PM, Volker Simonis wrote: > > > > Hi Lutz, Zoltan, > > > > @Lutz, thanks for analyzing the problem! I actually didn't > > expected that the efforts we put into fixing the tests will > > pay up that fast :) > > > > @Zoltan: I propose we split the test from the actual fix. I > > can push the ppc64/s390x parts myself. > > > > > > That is fine with me. > > > > Just to clarify: Will you include the other test Lutz has modified > > (test/compiler/intrinsics/zip/TestCRC32.java) into your JDK 10 > > changeset? I can live with both options (i.e., (1) both tests > > pushed into JDK 9 with 8178720 and (2) *CRC32C -> JDK 9, CRC32 -> > > JDK 10). > > > > > > I will only push the ppc64/s390x related fixes WITHOUT any tests > > (actually I'm still not allowed to push shared code as it must go > > through JPRT and there's still no access to JPRT for external > > committers :( > > Thanks for clarifying. > > I was confused because at one place you used singular ("test") and at > two other places you used plural ("tests"). If you were to go with (2) I > would have offered my help with sponsoring (that's the only way I can > help you at the moment, unfortunately). > > I'll take care of both tests then. > > Best regards, > > > Zoltan > > > > > > I opened the new prio 2 bug "8178720: CRC32C fails on old x86 > > hardware without CLMUL support" for jdk9 > > > > > > Thank you. > > > > and linked the reworked tests from Lutz' last webrev to it. I > > think this is definitely something we should fix before jdk9 > > will be released and the nfix should contain the new, fixed > > version of the tests. Zoltan, can you please take care of this? > > > > > > Yes, I can. Just let me know which option from above you prefer. > > > > For the record: I'll add Lutz as a contributor when pushing the > > tests (if that's fine with you, Lutz). > > > > > > That's fine. Thanks! > > > > Best regards, > > > > > > Zoltan > > > > > > Thank you and best regards, > > Volker > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8178720 > > > > > > > > On Thu, Apr 13, 2017 at 12:10 PM, Schmidt, Lutz > > > > >> > > wrote: > > > > Hi Zoltan, > > > > I am now able to reproduce the problem. Calculated crc and > > reference crc are exactly the same as in the log output > > you pasted > > below. And the problem shows up on linux-x86_64 as well. > > > > Here is what?s happening: > > The CRC32C implementation generates code depending on the > > CLMUL > > cpu feature being available. On most machines @Oracle and > > @SAP, > > this feature seems to be available ? except for one of > > your MacOS > > test machines. > > > > To gain control over that feature, I have modified just > > one line > > in src/cpu/x86/vm/vm_version_x86_64.hpp like this: > > static bool supports_clmul() { return ((_features & > > CPU_CLMUL) != 0) && UseNewCode; } > > > > The boolean UseNewCode is a command line parameter we use > > @SAP to > > make experimental code switchable during development. With > > that > > modification, I can force off the CLMUL feature at will. And > > voila, here is what I get (linux-x86_64): > > > > lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java > > -XX:+UseNewCode TestCRC32C_OpenJDK -m > > updateBytesCRC32C: pclmulqdq = true. > > testing 1050 cases ... > > lu0084 PrivSrc/TestCRC> //sapjvm_9/bin/java > > -XX:-UseNewCode TestCRC32C_OpenJDK -m > > updateBytesCRC32C: pclmulqdq = false. > > testing 1050 cases ... > > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > > iteration 0: offsets[0] = 0 sizes[30] = 1024 > > Exception: java.lang.Exception: TestCRC32C Error > > Exception in thread "main" java.lang.Exception: > > java.lang.Exception: TestCRC32C Error > > at > > TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:306) > > at > > TestCRC32C_OpenJDK.main(TestCRC32C_OpenJDK.java:74) > > Caused by: java.lang.Exception: TestCRC32C Error > > at > > TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:298) > > ... 1 more > > lu0084 PrivSrc/TestCRC> > > > > Output on MacOS is the same. I did not try solaris-x86_64. > > > > The bug is in MacroAssembler::crc32c_ipl_alg2_alt2() or > > one of its > > callees. I have not yet performed an in-depth analysis on > > what?s > > going wrong, mainly because I am not a proven expert on x86 > > machine code. > > > > So how do we proceed from here? Shouldn?t we file a > > separate bug > > for this x86 issue? Should this webrev (8176580) be split > > up into > > the (ppc, s390) chunk and a separate test bug webrev? Can > > you push > > this webrev despite there is an (unrelated) JPRT failure? > > > > Thanks and best regards, > > Lutz > > > > > > > > On 12.04.2017, 18:36, "hotspot-compiler-dev on behalf of > > Schmidt, > > Lutz" > > > > > on behalf > > of lutz.schmidt at sap.com > > >> > > wrote: > > > > Hi Zoltan, > > > > I?m not able to reproduce the problem as of now. I > > will try > > out other (older) x86 machines tomorrow. Could be a problem in > > fallback code when required vector instructions are not > > available. > > > > Can you please find out on what H/W (CPU in > > particular) the > > tests are failing? > > > > Thanks, > > Lutz > > > > > > On 12.04.2017, 14:38, "Zolt?n Maj?" > > > > > >> wrote: > > > > Hi Lutz, > > > > > > On 04/12/2017 02:14 PM, Schmidt, Lutz wrote: > > > Hi Zoltan, > > > > > > First of all: thanks for trying to push! Second: > > sorry > > for the problems you ran into. > > > > you are welcome and no problem, of course. > > > > > I do not have an immediate explanation for the > > failure ? > > my dev machine is MacOS/x86_64. I will try to reproduce > > immediately. For the time being: is there any log output that > > could shed some light on the issue? > > > > Please find the output below (and sorry for not > > including > > it before). > > > > Please let me know if you were able to reproduce the > > problem (or not). > > > > Best regards, > > > > > > Zoltan > > > > command: main -Xbatch > > compiler.intrinsics.zip.TestCRC32C -m > > reason: User specified action: run > > main/othervm/timeout=600 -Xbatch > > compiler.intrinsics.zip.TestCRC32C -m > > Mode: othervm [/othervm specified] > > elapsed time (seconds): 1.915 > > configuration: > > STDOUT: > > testing 1050 cases ... > > STDERR: > > ERROR: crc = 6f894393, crcReference = 2cdf6e8f > > java.lang.Exception: TestCRC32C Error > > at > > compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218) > > at > > > > compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280) > > at > > compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74) > > at > > > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > at > > > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at > > > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at > > java.base/java.lang.reflect.Me > > thod.invoke(Method.java:563) > > at > > > > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > > at > > java.base/java.lang.Thread.run(Thread.java:844) > > > > JavaTest Message: Test threw exception: > > java.lang.Exception: TestCRC32C Error > > JavaTest Message: shutting down test > > > > STATUS:Failed.`main' threw exception: > > java.lang.Exception: > > TestCRC32C Error > > > > > > > > > > > > Thanks, > > > Lutz > > > > > > > > > On 12.04.2017, 13:10, "hotspot-compiler-dev on > > behalf of > > Zolt?n Maj?" > > > > > > > on behalf > > of zoltan.majo at oracle.com > > > >> wrote: > > > > > > P.S.: Forgot to mention: The problem does not > > appear on any other x86_64 > > > platform. > > > > > > On 04/12/2017 01:07 PM, Zolt?n Maj? wrote: > > > > Hi Volker, > > > > Hi Lutz, > > > > > > > > > > > > yesterday I tried to push webrev.03 using > > JPRT. > > Unfortunately, the > > > > TestCRC32C.java test you've modified > > fails on Mac > > OS X on x86_64. Do > > > > you have an idea why that could be? > > > > > > > > Thank you! Best regards, > > > > > > > > > > > > Zoltan > > > > > > > > On 04/11/2017 06:03 PM, Volker Simonis wrote: > > > >> Thanks a lot Zoltan! > > > >> > > > >> > > > >> On Tue, Apr 11, 2017 at 4:35 PM, Zolt?n Maj? > > > > > > > > >> > > > > > > >>> wrote: > > > >> > > > >> Hi Volker, > > > >> > > > >> > > > >> On 04/11/2017 03:34 PM, Volker > > Simonis wrote: > > > >> > > > >> > > > >> Hi Zoltan, > > > >> > > > >> could you please be so kind to > > sponsor > > this reviewed change > > > >> for jdk10? > > > >> > > > >> > > > >> yes, of course. I'll push it today. > > > >> > > > >> Best regards, > > > >> > > > >> > > > >> Zoltan > > > >> > > > >> Initially we wanted to push it > > ourselves > > because it was s390x > > > >> only but now that we've also > > touched the > > tests we need a > > > >> sponsor. > > > >> > > > >> Thank you and best regards, > > > >> Volker > > > >> > > > >> ---------- Forwarded message > > ---------- > > > >> From: *Volker Simonis* > > > > > > > > > > >> > > > > >> > > > >> > > > > > > > > >> > > > > >>>> > > > >> Date: Fri, Mar 31, 2017 at 10:53 AM > > > >> Subject: Re: RFR (S) 8176580: [ppc, > > s390] CRC32C: wrong > > > >> checksum result in some cases > > > >> To: "Schmidt, Lutz" > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > >>>> > > > >> Cc: Andrew Haley > > > > > > > > >> > > > >> > > > > > > > > >>>>, > > > >> > > "hotspot-compiler-dev at openjdk.java.net > > > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > > >> > > > > > > >>>" > > > >> > > > > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > > >> > > > > > > >>>> > > > >> > > > >> > > > >> Ping... > > > >> > > > >> Can somebody please push this > > change? > > > >> > > > >> It's ppc64/s390x only but as a > > courtesy > > to the community it > > > >> also fixes > > > >> the CRC JTreg tests so > > unfortunately I > > still can't push it > > > >> myself :) > > > >> > > > >> Thank you and best regards, > > > >> Volker > > > >> > > > >> > > > >> On Tue, Mar 28, 2017 at 5:01 PM, > > Volker > > Simonis > > > >> > > > > > > > > > > >> > > > >> > > > > > > > > >> > > > > >>>> wrote: > > > >> > Hi Lutz, > > > >> > > > > >> > thanks a lot for fixing the test! > > > >> > Your change looks good now. > > > >> > > > > >> > Because this touches shared (i.e. > > test) files, we still need > > > >> a sponsor > > > >> > so can somebody please sponsor > > this > > change? > > > >> > > > > >> > Thank you and best regards, > > > >> > Volker > > > >> > > > > >> > > > > >> > > > > >> > On Fri, Mar 24, 2017 at 4:54 PM, > > Schmidt, Lutz > > > >> > > > > > > > > >> > > > >> > > > > > > > > >>>> > > > >> wrote: > > > >> >> Hi Volker, > > > >> >> > > > >> >> Sorry for letting you wait. > > Here is > > the final(?) webrev, > > > >> containing all your requests for > > cleanup > > and improvements: > > > >> >> > > http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/ > > > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > > >> > > > > > > >>> > > > >> >> > > > >> >> As before, the *.cpp files > > have not > > been modified. > > > >> >> > > > >> >> Best Regards, > > > >> >> Lutz > > > >> >> > > > >> >> > > > >> >> > > > >> >> On 21/03/2017, 17:55, "Volker > > Simonis" > > > >> > > > > > > > > > > >> > > > >> > > > > > > > > >> > > > > >>>> wrote: > > > >> >> > > > >> >> Hi Lutz, > > > >> >> > > > >> >> thanks a lot for updating the > > tests. I think they look > > > >> much better now. > > > >> >> > > > >> >> There's just one more > > cleanup I'd > > like to propose. Can > > > >> you please move > > > >> >> the throw right into the check() > > function. Just make > > > >> check() return > > > >> >> void and throw from it if > > there's > > a mismatch between > > > >> the computed and > > > >> >> the expected result. I leave it > > up to you if you want > > > >> to pass an extra > > > >> >> error string to check() which > > will be printed in the > > > >> case of an error. > > > >> >> I personally don't think that's > > necessary as it will be > > > >> evident from > > > >> >> the stack trace which > > computation > > failed. > > > >> >> > > > >> >> Also the try/catch and > > rethrow in > > test_multi() isn't > > > >> necessary. The > > > >> >> test can be simply terminated by > > the initial exception. > > > >> >> > > > >> >> Thank you and best regards, > > > >> >> Volker > > > >> >> > > > >> >> > > > >> >> On Fri, Mar 17, 2017 at > > 10:03 PM, > > Schmidt, Lutz > > > >> > > > > > > > > >> > > > >> > > > > > > > > >>>> > > > >> wrote: > > > >> >> > Hi Volker, > > > >> >> > > > > >> >> > Thanks a lot for your valuable > > hints. > > > >> >> > > > > >> >> > I have worked some time on the > > Java test files: > > > >> >> > TestCRC32.java and > > TestCRC32C.java are now > > > >> identical as far as possible. > > > >> >> > They now throw an exception, > > should any error be > > > >> detected. > > > >> >> > The ?reference CRC value? is > > now used in > > > >> test_multi() as well. > > > >> >> > The extra test runs have been > > removed again. > > > >> >> > The test methodology is > > fixed: > > each result is > > > >> tested against its reference. > > > >> >> > The tests now detect the bug > > introduced with > > > >> 8175368 and 8175369. > > > >> >> > No issue is indicated when > > testing with 8176580. > > > >> >> > I ran jcheck, and to the > > best > > of my ability and > > > >> knowledge, there is no trailing > > whitespace. > > > >> >> > All *.cpp files were left > > untouched! > > > >> >> > > > > >> >> > The next iteration of the > > webrev: > > > >> > > http://cr.openjdk.java.net/~lucy/webrevs/8176580.02/ > > > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > > >> > > > > > > >>> > > > >> >> > > > > >> >> > Best regards, > > > >> >> > Lutz > > > >> >> > > > > >> >> > > > > >> >> > Dr. Lutz Schmidt | SAP JVM | > > PI SAP CP Core | T: +49 > > > >> (6227) 7-42834 > > > > > > > >> > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > On 16.03.17, 11:28, "Volker > > Simonis" > > > >> > > > > > > > > > > >> > > > >> > > > > > > > > >> > > > > >>>> wrote: > > > >> >> > > > > >> >> > On Wed, Mar 15, 2017 at 5:55 > > PM, Schmidt, Lutz > > > >> > > > > > > > > >> > > > >> > > > > > > > > >>>> > > > >> wrote: > > > >> >> > > > > > >> >> > > Hi Andrew, Volker, > > > >> >> > > > > > >> >> > > What do you think about > > these test enhancements? > > > >> >> > > Webrev: > > > >> > > http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/ > > > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > > >> > > > > > > >>> > > > >> > > > >> >> > > > > > >> >> > > Please note: the cpp files > > in the webrev > > > >> remained unchanged. > > > >> >> > > > > > >> >> > > I added some improvements > > (as I believe) to the > > > >> TestCRC32(C).java files. > > > >> >> > > > > > >> >> > > In some more detail: > > > >> >> > > The test now calculates a > > ?reference CRC > > > >> value?, based on a java > > implementation > > of the CRC32 algorithm. > > > >> This reference value is used to > > verify > > all other crc values, > > > >> in particular during > > initialization and > > warmup. Three > > > >> additional test runs check a > > non-zero > > offset with ?Xint, > > > >> -Xcomp -XX:-TieredCompilation > > (C2 only), > > -Xcomp > > > >> -XX:+TieredCompilation (C1 + C2). > > > >> >> > > > > > >> >> > > > > >> >> > Hi Lutz, > > > >> >> > > > > >> >> > thanks for updating the > > tests. > > I've had a closer > > > >> look at the tests and > > > >> >> > realized that they actually > > can never fail! The > > > >> check() routine just > > > >> >> > prints an error message but > > that will not let the > > > >> test fail. So I > > > >> >> > would suggest to throw a > > runtime exception in the > > > >> check() routine > > > >> >> > after the error message was > > printed. > > > >> >> > > > > >> >> > I also suggest to do the > > check > > during the normal > > > >> test execution (i.e. > > > >> >> > in test_multi()) so > > there's no > > need for extra > > > >> test runs. > > > >> >> > > > > >> >> > Finally, the current test > > methodology in > > > >> test_multi() is broken: > > > >> >> > - it sets the reference by > > calling CRC from the > > > >> interpreter which > > > >> >> > won't work if the > > intrinsic is > > also used in the > > > >> interpreter. > > > >> >> > - it only compares the > > reference against the > > > >> last computation of CRC > > > >> >> > in the loop which will be the > > result of the C2 > > > >> generated code. This > > > >> >> > misses errors in C1. > > > >> >> > > > > >> >> > I suggest to use your new, > > pure Java > > > >> implementation for the > > > >> >> > computation of the reference > > result and compare > > > >> the reference with the > > > >> >> > result of calling CRC in > > every > > iteration of the > > > >> loop so we really > > > >> >> > check all possibilities from > > interpreter trough > > > >> C1 to C2. > > > >> >> > > > > >> >> > Finally, can you please pay > > attention to not > > > >> insert trailing > > > >> >> > whitespace (there was some at > > line 88 in > > > >> TestCRC32C.java). You can > > > >> >> > easily verify this by running > > jcheck before > > > >> creating the webrevs. > > > >> >> > > > > >> >> > Thanks, > > > >> >> > Volker > > > >> >> > > > > >> >> > > > > > >> >> > > Best regards, > > > >> >> > > Lutz > > > >> >> > > > > > >> >> > > > > > >> >> > > On 15.03.17, 11:50, "Volker > > Simonis" > > > >> > > > > > > > > > > >> > > > >> > > > > > > > > >> > > > > >>>> wrote: > > > >> >> > > > > > >> >> > > On Tue, Mar 14, 2017 at > > 7:05 PM, Andrew > > > >> Haley > > > > > > > > >> > > > >> > > > > > > > > >>>> wrote: > > > >> >> > > > On 14/03/17 13:12, > > Schmidt, Lutz wrote: > > > >> >> > > > > > > >> >> > > >> Yes, one might think > > of running a test > > > >> suite subset multiple times > > > >> >> > > >> with different > > parameters. In this case, > > > >> -Xint and/or ?Xcomp were > > > >> >> > > >> helpful. Forcing > > tests to run fully > > > >> interpreted or fully compiled > > > >> >> > > >> helps in cases where > > a certain function, > > > >> e.g. an intrinsic, is > > > >> >> > > >> invoked via distinct > > code paths. > > > >> >> > > > > > > >> >> > > > Right, so your patch > > should include that > > > >> change to the test suite. > > > >> >> > > > > > > >> >> > > > > > >> >> > > Hi Lutz, > > > >> >> > > > > > >> >> > > I agree with Andrew. We > > should really fix > > > >> the tests such that they > > > >> >> > > check the > > correctness of > > the intrinsics. > > > >> >> > > > > > >> >> > > This may be tricky if > > all three, the > > > >> interpreter, the client and the > > > >> >> > > server compiler use the > > same intrinsic > > > >> implementation. You could > > > >> >> > > either copy the pure > > Java implementation > > > >> into the test so that you can > > > >> >> > > compare the results of > > the intrinsic > > > >> operation against it or you can > > > >> >> > > switch them off in the > > compilers with > > > >> >> > > > > "-XX:DisableIntrinsic=_updateBytesCRC32C > > > >> >> > > > > > >> > > -XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and > > > >> compare the > > > >> >> > > results. Not sure which > > solution is more > > > >> practical, but I would be > > > >> >> > > really scared if we > > wouldn't have these test. > > > >> >> > > > > > >> >> > > Regards, > > > >> >> > > Volker > > > >> >> > > > > > >> >> > > > Andrew. > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From zoltan.majo at oracle.com Tue Apr 18 10:22:49 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 18 Apr 2017 12:22:49 +0200 Subject: [9] RFR (S) 8178723: Workaround for failure of CRC32C intrinsic on x86 machines without CLMUL support (JDK-8178720) In-Reply-To: <33e57da7-7271-7173-f1a9-525340d37a62@oracle.com> References: <1e62816d-f893-2883-e86a-0b4e68557b28@oracle.com> <33e57da7-7271-7173-f1a9-525340d37a62@oracle.com> Message-ID: Hi Vladimir, On 04/13/2017 07:28 PM, Vladimir Kozlov wrote: > Hi Zoltan, > > The fix looks good. thank you! > Please, add label and fix request comment according to RDP2 rules for > JDK 9. I did so. Once the fix is approved, I'll push it. Best regards, Zoltan > > Thanks, > Vladimir > > On 4/13/17 7:54 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following fix for 8178723. (8178723 is a workaround >> for 8178720.) >> https://bugs.openjdk.java.net/browse/JDK-8178723 >> http://cr.openjdk.java.net/~zmajo/8178723/webrev.00/ >> >> The problem is that the CRC32C intrinsic is apparently incorrect on >> x86 machines without CLMUL support. The tests >> provided by Lutz Schmidt (also part of this change set) have >> uncovered that problem. >> >> Given the state of JDK 9, I think it's best to split the problem into >> two parts: >> - (1) this workaround (8178723), which disables the CRC32C intrinsics >> on x86 machines without CLMUL support; the >> workaround also the tests provided by Lutz (with proper credit in the >> final change set); >> - (2) the "proper" fix for the problem is handled in 8178720; I asked >> Michael Berg to look into that problem. >> >> If (and once) the workaround is fine with you, I'll take care of the >> fix-request process. >> >> JPRT testing is running at the moment. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> From tobias.hartmann at oracle.com Tue Apr 18 11:03:53 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 18 Apr 2017 13:03:53 +0200 Subject: RFR(S): 8178811: Minimize the AVX <-> SSE transition penalty on x86 In-Reply-To: <16b9ac5c-25cb-193d-4b6f-e6d3c9a95651@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A63CD479B@ORSMSX106.amr.corp.intel.com> <16b9ac5c-25cb-193d-4b6f-e6d3c9a95651@oracle.com> Message-ID: <2b5a9d2e-14ae-25e8-3d64-f06abceb6fb5@oracle.com> Hi, this issue slipped through our triaging process because the subcomponent was not set to "compiler". I converted it to an enhancement and targeted it to JDK 10. As Vladimir said, we can later backport it to a JDK 9 update release. Thanks, Tobias On 17.04.2017 06:30, Vladimir Kozlov wrote: > What is important is 'Fix version'. 'Affected version' could be all current and previous releases. > > From the beginning I thought it is targeting JDK 10. To avoid confusion I set 'Fix version' to 10. > > It may go into 9 Update as other small enchantments. > > Regards, > Vladimir > > On 4/16/17 3:03 AM, Andrew Haley wrote: >> Hi, >> >> On 14/04/17 19:17, Deshpande, Vivek R wrote: >> >>> This fix minimizes the AVX to SSE and SSE to AVX transition penalty >>> through generation of vzeroupper instruction. >> >> This looks like a performance enhancement, rather than a bug. Is JDK >> 9 still open for performance enhancement? I thought we were in >> rampdown, but the report is targeted to 9. >> >> Andrew. >> From volker.simonis at gmail.com Tue Apr 18 12:37:55 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 18 Apr 2017 14:37:55 +0200 Subject: [9] RFR (S) 8178723: Workaround for failure of CRC32C intrinsic on x86 machines without CLMUL support (JDK-8178720) In-Reply-To: <61f515e6-70d2-9aac-0223-40637b4c8036@oracle.com> References: <1e62816d-f893-2883-e86a-0b4e68557b28@oracle.com> <3bdf8249-460f-65e6-4e5d-c952712606c0@oracle.com> <61f515e6-70d2-9aac-0223-40637b4c8036@oracle.com> Message-ID: Looks good! Sorry, I forgot to mention that you don't have to do a new webrev just for the updated copyright line. I definitely trust you on that :) Regards, Volker On Tue, Apr 18, 2017 at 11:30 AM, Zolt?n Maj? wrote: > Hi Volker, > > > On 04/13/2017 08:43 PM, Volker Simonis wrote: >> >> Looks good although all the files need an updated copyright line :) > > > thank you for pointing that out. Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8178723/webrev.01/ > > Best regards, > > > Zoltan > >> >> Thanks, >> Volker >> >> >> On Thu, Apr 13, 2017 at 5:15 PM, Zolt?n Maj? > > wrote: >> >> >> On 04/13/2017 04:54 PM, Zolt?n Maj? wrote: >> >> [...] >> JPRT testing is running at the moment. >> >> >> P.S.: All JPRT tests pass. >> >> Best regards, >> >> >> Zoltan >> >> >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> >> > From zoltan.majo at oracle.com Tue Apr 18 12:40:35 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 18 Apr 2017 14:40:35 +0200 Subject: [9] RFR (S) 8178723: Workaround for failure of CRC32C intrinsic on x86 machines without CLMUL support (JDK-8178720) In-Reply-To: References: <1e62816d-f893-2883-e86a-0b4e68557b28@oracle.com> <3bdf8249-460f-65e6-4e5d-c952712606c0@oracle.com> <61f515e6-70d2-9aac-0223-40637b4c8036@oracle.com> Message-ID: <03a62754-79e4-fc1a-f51a-dc7671b18053@oracle.com> On 04/18/2017 02:37 PM, Volker Simonis wrote: > Looks good! > > Sorry, I forgot to mention that you don't have to do a new webrev just > for the updated copyright line. I definitely trust you on that :) Thank you, Volker! :-) Best regards, Zoltan > > Regards, > Volker > > > On Tue, Apr 18, 2017 at 11:30 AM, Zolt?n Maj? wrote: >> Hi Volker, >> >> >> On 04/13/2017 08:43 PM, Volker Simonis wrote: >>> Looks good although all the files need an updated copyright line :) >> >> thank you for pointing that out. Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8178723/webrev.01/ >> >> Best regards, >> >> >> Zoltan >> >>> Thanks, >>> Volker >>> >>> >>> On Thu, Apr 13, 2017 at 5:15 PM, Zolt?n Maj? >> > wrote: >>> >>> >>> On 04/13/2017 04:54 PM, Zolt?n Maj? wrote: >>> >>> [...] >>> JPRT testing is running at the moment. >>> >>> >>> P.S.: All JPRT tests pass. >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>> From igor.ignatyev at oracle.com Tue Apr 18 18:33:05 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Apr 2017 11:33:05 -0700 Subject: RFR(XS) : 8178913 : CTW library does not close all opened resources Message-ID: <869ED692-650B-431B-9EF6-AAAE516AC499@oracle.com> http://cr.openjdk.java.net/~iignatyev//8178913/webrev.00/index.html > 14 lines changed: 6 ins; 3 del; 5 mod; Hi all, could you please review this small fix for CTW library? there were several instance of resources leak in the library, this changeset fixes them by using try-w/-resource where applicable, and explicit close() call were not. webrev: http://cr.openjdk.java.net/~iignatyev//8178913/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8178913 testing: hotspot/test/testlibrary_tests/ctw Thanks, -- Igor From chenyt.cs.sjtu at gmail.com Tue Apr 18 21:20:12 2017 From: chenyt.cs.sjtu at gmail.com (Yuting Chen) Date: Tue, 18 Apr 2017 14:20:12 -0700 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: References: Message-ID: Hi, are there any comments to this case? I found that the clinit method will be compiled if it does not contain the infinite loop. Does it mean that clinit will run before it is compiled. Re-paste the bytecode: public class Vector1 minor version: 0 major version: 52 flags: ACC_PUBLIC, ACC_SUPER Constant pool: #1 = Utf8 Vector1 #2 = Class #1 // Vector1 #3 = Utf8 java/lang/Object #4 = Class #3 // java/lang/Object #5 = Utf8 serialVersionUID #6 = Utf8 J #7 = Long -2767605614048989439l #9 = Utf8 #10 = Utf8 ()V #11 = NameAndType #5:#6 // serialVersionUID:J #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J #13 = Utf8 main #14 = Utf8 ([Ljava/lang/String;)V #15 = Utf8 ConstantValue #16 = Utf8 Code #17 = Utf8 StackMapTable { public static {}; descriptor: ()V flags: ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=0, args_size=0 0: ldc2_w #7 // long -2767605614048989439l 3: putstatic #12 // Field serialVersionUID:J 6: iconst_1 7: iconst_m1 8: iadd 9: ifge 0 12: return StackMapTable: number_of_entries = 1 frame_type = 0 /* same */ public static void main(java.lang.String[]); descriptor: ([Ljava/lang/String;)V flags: ACC_PUBLIC, ACC_STATIC Code: stack=0, locals=1, args_size=1 0: return } On Tue, Apr 18, 2017 at 9:41 AM, Yuting Chen wrote: > Hi, are there any comments to this case? I found that the clinit > method will be compiled if it does not contain the infinite loop. It's > weird. > > The bytecode is shown as follows: > > public class Vector1 > minor version: 0 > major version: 52 > flags: ACC_PUBLIC, ACC_SUPER > Constant pool: > #1 = Utf8 Vector1 > #2 = Class #1 // Vector1 > #3 = Utf8 java/lang/Object > #4 = Class #3 // java/lang/Object > #5 = Utf8 serialVersionUID > #6 = Utf8 J > #7 = Long -2767605614048989439l > #9 = Utf8 > #10 = Utf8 ()V > #11 = NameAndType #5:#6 // serialVersionUID:J > #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J > #13 = Utf8 main > #14 = Utf8 ([Ljava/lang/String;)V > #15 = Utf8 ConstantValue > #16 = Utf8 Code > #17 = Utf8 StackMapTable > { > public static {}; > descriptor: ()V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=2, locals=0, args_size=0 > 0: ldc2_w #7 // long -2767605614048989439l > 3: putstatic #12 // Field serialVersionUID:J > 6: iconst_1 > 7: iconst_m1 > 8: iadd > 9: ifge 0 > 12: return > StackMapTable: number_of_entries = 1 > frame_type = 0 /* same */ > > public static void main(java.lang.String[]); > descriptor: ([Ljava/lang/String;)V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=0, locals=1, args_size=1 > 0: return > } From igor.ignatyev at oracle.com Tue Apr 18 22:12:48 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Apr 2017 15:12:48 -0700 Subject: RFR(XL/M) : 8178788: wrap JCStress test suite as jtreg tests Message-ID: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html > 69903 lines changed: 69903 ins; 0 del; 0 mod; (69524 lines are generated) Hi all, could you please review this patch which adds a jtreg test wrapper for jcstress test suite and jtreg tests which run jsctress tests thru this wrapper? webrev: http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8178788 testing: applications/jcstress Thanks, -- Igor From igor.ignatyev at oracle.com Tue Apr 18 22:49:07 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Apr 2017 15:49:07 -0700 Subject: RFR(S) : 8178835: CTW Runner should check that all classes have been compiled Message-ID: <4F275E2E-99FC-4661-B03A-9EFFD0472544@oracle.com> http://cr.openjdk.java.net/~iignatyev//8178835/webrev.00/index.html > 99 lines changed: 88 ins; 1 del; 10 mod Hi all, could you please review this small fix for CTW runner which adds verification that CTW was run for all classes? currently, CTW runner stops execution when a child process exits w/ zero code, this might lead to missed test cover and/or false negative tests results. This fix adds a check that the index of the last compiled class equals to count of classes in a target. webrev: http://cr.openjdk.java.net/~iignatyev//8178835/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8178835 testing: applications/ctw Thanks, -- Igor From cthalinger at twitter.com Tue Apr 18 23:03:42 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 18 Apr 2017 13:03:42 -1000 Subject: RFR(XXL) 8178864: Update Graal In-Reply-To: <008050D5-DEC7-4117-8EEF-B77BF3E22B24@oracle.com> References: <008050D5-DEC7-4117-8EEF-B77BF3E22B24@oracle.com> Message-ID: <2D2B20C1-65C5-4DBE-BC74-0D280D686D49@twitter.com> Igor, do you have a script you are using to update Graal in OpenJDK? If yes, could you share it? > On Apr 17, 2017, at 11:08 AM, Igor Veresov wrote: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8178864 > Webrev: http://cr.openjdk.java.net/~iveresov/8178864/webrev.00/ > > Thanks, > igor > > p.s. > > Changes: > > commit 415a4ef635029f49ab2c4fef0e6f2012be916db7 > Merge: 768caab 294900b > Author: Tom Rodriguez > > Date: Mon Apr 17 10:36:23 2017 -0700 > > [GR-3667] Fix probability for intrinsic guard. > > commit 294900b270c2f866a9a33a3a027a63ba85562792 > Author: Tom Rodriguez > > Date: Fri Apr 14 10:00:47 2017 -0700 > > Fix probability for intrinsic guard > > commit 768caabc4aad572e7fa8a08e708b81eaf9c8e119 > Merge: c3ab66a 78f5562 > Author: Doug Simon > > Date: Mon Apr 17 09:06:14 2017 -0700 > > [GR-3673] Remove forced dumps. > > commit c3ab66a7fb72311ed479d0f47b87cf867453915d > Merge: 4d1095d 9a66f88 > Author: Tom Rodriguez > > Date: Mon Apr 17 09:01:21 2017 -0700 > > [GR-3657] Fix possible infinite loop in nodesInLoopBranch. > > commit 9a66f887d1f6c8308f15c8c8df7c40578923369c > Author: Tom Rodriguez > > Date: Thu Apr 13 21:20:49 2017 -0700 > > Fix possible infinite loop in nodesInLoopBranch > > commit 78f55621c9301ae9c6e6e5b8d0d3fab7c2e4de6c > Author: Doug Simon > > Date: Mon Apr 17 10:41:29 2017 +0200 > > removed uses of Debug.forceDump that pollute test logs > > commit 4d1095d1ea9fc4c317c7f584a02344e64df7a5f3 > Merge: 02a2a3d cf9a623 > Author: Christian Wimmer > > Date: Fri Apr 14 10:25:21 2017 -0700 > > [GR-3666] Remove redundant final modifier as reported by newest Checkstyle version. > > commit cf9a6238a826e77c94ab0602c2214b0f0afd1aa6 > Author: Christian Wimmer > > Date: Fri Apr 14 09:02:55 2017 -0700 > > Remove redundant final modifier as reported by newest Checkstyle version > > commit 02a2a3d9ba60c5db87c83c701a500e41d79583b2 > Merge: e8acaea 92a1821 > Author: Josef Eisl > > Date: Fri Apr 14 02:24:54 2017 -0700 > > [GR-3206] The parallel scala actors fix should not overwrite the other results. > > commit e8acaea4d026244a187e50f9f39206730473da30 > Merge: 52a9ed9 fa1e93f > Author: Doug Simon > > Date: Thu Apr 13 07:57:55 2017 -0700 > > [GR-3627] Correct various errors in code generation (#267). > > commit 52a9ed925be5511d7984174136d07a2568cd83e5 > Merge: 0c30850 fc12456 > Author: Matthias Grimmer > > Date: Thu Apr 13 07:04:06 2017 -0700 > > [GR-3642] Explicit hosted (e.g. hosted-graal-core) jvm-config. > > commit 92a18214d2279ab421c15300d46bab93cac90619 > Author: Josef Eisl > > Date: Thu Apr 13 15:51:51 2017 +0200 > > [ci,fix] the parallel scala actors fix should not overwrite the other results > > commit fa1e93f806c16dfe79b79cc0932b5d2bbea342c4 > Merge: 425a9c4 f1f981e > Author: Doug Simon > > Date: Thu Apr 13 15:27:39 2017 +0200 > > Merge. > > commit fc12456b4e654a51009b07d1ff437622bcc5e2b7 > Author: Matthias Grimmer > > Date: Thu Apr 13 11:27:16 2017 +0200 > > Add hosted configurations to mx benchmark. > > commit 0c30850da9fcf74d0b08e3e53f4a99e036294d30 > Merge: f1f981e fdf7341 > Author: Roland Schatz > > Date: Thu Apr 13 04:11:34 2017 -0700 > > [GR-3629] Fix wrong callRootMethod in GraalTestTVMCI. > > commit 425a9c4e4d346b1018786d02ba3d9d0a6433cae4 > Author: Andrew Dinn > > Date: Wed Apr 12 15:43:56 2017 +0100 > > fix problem in emit for CompressRegister and Uncompressregister > > commit fdf7341635824a7c6eb3b7be908dd74372aa4736 > Author: Roland Schatz > > Date: Wed Apr 12 15:50:26 2017 +0200 > > Fix wrong callRootMethod in GraalTestTVMCI. > > commit 1c0da37a2cff42a9b46cdfad40d9ccc932e948cb > Author: Andrew Dinn > > Date: Wed Apr 12 14:53:56 2017 +0100 > > correct cut-and-pasteo in original patch > > commit cb8ee4804de9bec5eea213470bd237a83c981cac > Author: Andrew Dinn > > Date: Wed Apr 12 13:50:36 2017 +0100 > > correct two small errors in code generation > > commit f1f981e8002fa6de2989fc223d67d7589d11c0c0 > Merge: 1e9c29d 3685425 > Author: Doug Simon > > Date: Wed Apr 12 04:46:39 2017 -0700 > > [GR-3598] Remove use of JDK internal API in CompileTheWorld. > > commit 1e9c29d7bd62ddb5b0180d081db7b9230ea9383d > Merge: 8b0ff79 e01a696 > Author: Doug Simon > > Date: Wed Apr 12 01:46:57 2017 -0700 > > [GR-3610] Unstrip VM output when running with stripped jars. > > commit 8b0ff796db6d6d5eae4711f3740b9ec18b68a284 > Merge: dde444f 78aecaa > Author: Paul W?gerer > > Date: Wed Apr 12 01:19:57 2017 -0700 > > [GR-3556] Handle inlining during parsing more like inlining after parsing. > > commit e01a696368522b6965e2a73155881ce873858b1d > Author: Doug Simon > > Date: Tue Apr 11 14:25:13 2017 +0200 > > apply retrace tool to VM output if running with stripped jars > > commit 368542591c5d5d0547774cf556217f38b4fd162d > Author: Doug Simon > > Date: Mon Apr 10 17:17:00 2017 +0200 > > moved CompileTheWorld out of GRAAL dist and removed its use of JDK internal API > added CTW 9 tests to gate > > commit 78aecaa0a0ac7bbecbdc820f3393eaf09fddb16e > Author: Christian Wimmer > > Date: Tue Apr 11 13:49:23 2017 -0700 > > Handle inlining during parsing more like inlining after parsing > > When a method has multiple returns, inlinig during parsing created a merge frame state with a bci of one of the return bytecodes. Now the handling is the same as in the inlining phase: the merge frame state that does not include the callee (just the caller frame state after the call). > > commit dde444fdb4608a48b90dacd32719c12efb59f84c > Merge: 8c016d0 1d1a3b0 > Author: Tom Rodriguez > > Date: Tue Apr 11 13:49:12 2017 -0700 > > [GR-3153] Revert Handle placeholder states specially in PEA. > > commit 1d1a3b0e18c8c0e5499c719d658013967111e875 > Author: Tom Rodriguez > > Date: Tue Apr 11 13:12:10 2017 -0700 > > Revert Handle placeholder states specially in PEA > > commit 8c016d06d3c18ce9a62d958bf3bed6b30b997687 > Merge: 4c4144b 9735c8c > Author: David Leopoldseder > > Date: Tue Apr 11 10:17:45 2017 -0700 > > [GR-3476] Remove TruffleCompilationCancellationTest. > > commit 4c4144b71d527d984637ade1c0ba8f361c326143 > Merge: 978c49a a1d0705 > Author: Aleksandar Prokopec > > Date: Tue Apr 11 05:53:09 2017 -0700 > > [GR-3601] Ensure that a more specific create method is used when creating comparison nodes. > > commit a1d0705cd0b7f74075208365bd42b78cdaf1eff2 > Author: Aleksandar Prokopec > > Date: Mon Apr 10 17:25:10 2017 +0200 > > Use more specific create method for comparison nodes. > > commit 978c49ae5c2b4d9cfb000a4c0917b18ef255857d > Merge: d07c8b2 af5dd81 > Author: Christian Haeubl > > Date: Tue Apr 11 05:11:50 2017 -0700 > > [GR-3595] Cache if a method is covered by an InvocationPlugin. > > commit af5dd81295c8d7f8070fd051c9848599459afffe > Author: Christian Haeubl > > Date: Mon Apr 10 12:10:23 2017 +0200 > > Cache if a method is covered by an InvocationPlugin. > > commit d07c8b25d76f5956d6d7b62849eafc8ba944abe0 > Merge: c72a5d5 d53ce49 > Author: Vojin Jovanovic > > Date: Tue Apr 11 03:39:18 2017 -0700 > > [GR-3393] Revert. > > commit d53ce499e9ce85de2303e642d17ca069b1a47af2 > Author: Vojin Jovanovic > > Date: Tue Apr 11 11:38:42 2017 +0200 > > Revert "[GR-3393] Separate compressed oops from HotSpot as much as possible." > > This reverts commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43, reversing > changes made to a872965c61c942ce33fd295a2280dcb54a3b38f4. > > commit 9735c8c573c1b869b38dbe8cabbf37ebcb82a4e7 > Author: David Leopoldseder > > Date: Tue Apr 11 10:59:33 2017 +0200 > > [fix] Remove TruffleCompilationCancellationTest. > > commit c72a5d5e78538cea5d42967b238fe91198c95ae3 > Merge: 0b9c9ee 2d18d0a > Author: Tom Rodriguez > > Date: Mon Apr 10 09:38:09 2017 -0700 > > [GR-3153] Handle placeholder states specially in PEA. > > commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43 > Merge: a872965 eb2ef20 > Author: Vojin Jovanovic > > Date: Mon Apr 10 07:25:07 2017 -0700 > > [GR-3393] Separate compressed oops from HotSpot as much as possible. > > commit eb2ef20805d6c24ff4b0dcc9af644a0365cdb926 > Author: Vojin Jovanovic > > Date: Mon Mar 27 17:24:40 2017 +0200 > > [cleanup] separate compressed oops from HotSpot as much as possible > > commit a872965c61c942ce33fd295a2280dcb54a3b38f4 > Merge: 448e5d8 2722294 > Author: Josef Eisl > > Date: Mon Apr 10 03:14:51 2017 -0700 > > [GR-3581] Set machine node for parallel benchmarks. > > commit 27222942948eb21a3be34a3bec1c7aa03d11aed3 > Author: Josef Eisl > > Date: Mon Apr 10 10:45:16 2017 +0200 > > [ci] add MACHINE_NODE to parallel benchmarks > > commit 448e5d899e46c37e3800c92ffa9fdb69f5c5307c > Merge: 7cc4f5d 24dba6b > Author: Josef Eisl > > Date: Mon Apr 10 01:24:11 2017 -0700 > > [GR-3525] Refine LIR dumping. > > commit 24dba6b3d9fe7472cb8cd50d00e3b95c0e9118f3 > Author: Josef Eisl > > Date: Fri Apr 7 17:48:49 2017 +0200 > > [fix] consolidate stack slot allocation dumping > > commit d2eacbdc80797f3032ee7a8de383e957b68aef9c > Author: Josef Eisl > > Date: Fri Apr 7 17:41:33 2017 +0200 > > [fix] consolidate linear scan dumping > > commit cbe02790cad450e1fb2af010fc3e56bb87ddd99e > Author: Josef Eisl > > Date: Fri Apr 7 16:38:57 2017 +0200 > > [fix] consolidate TraceRA dumping > > commit 55490c13f6274258b4ca339e30775097e8a97c1c > Author: Josef Eisl > > Date: Fri Apr 7 16:13:18 2017 +0200 > > [fix] Remove useless scopes and dumps from emitLIR > > commit 3f8355da125f50efb0180fdf9c019ae70234db14 > Author: Josef Eisl > > Date: Fri Apr 7 15:25:24 2017 +0200 > > [feature] Dump LIR stages in GraalCompiler > > commit 9c56f54ed009c9d93e0cb3f967f00c03c82028f2 > Author: Josef Eisl > > Date: Fri Apr 7 15:24:49 2017 +0200 > > [doc] document LIR dumping levels > > commit 7cc4f5dcea60bf0dabca37ef28eb97c378e494db > Merge: 9edeefc c6fe486 > Author: Aleksandar Prokopec > > Date: Fri Apr 7 12:35:10 2017 -0700 > > [GR-3551] Add early canonicalization to IntegerEqualsNode and ObjectEqualsNode. > > commit c6fe4861464787def1c5eb66842b3ad843285a55 > Merge: 8948675 9edeefc > Author: Aleksandar Prokopec > > Date: Fri Apr 7 19:24:18 2017 +0200 > > Merge branch 'master' into topic/GR-3551 > > commit 9edeefc2b6635d97c571c41a3708a2d90ae1ab3a > Merge: 8a0a87e c152e63 > Author: Josef Eisl > > Date: Fri Apr 7 09:27:55 2017 -0700 > > [GR-3206] Do not execute scala-dacapo actors in parallel. > > commit 8a0a87eb63cbbc94c8cead115921f96a69d6869b > Merge: 633e409 5282a7c > Author: Roland Schatz > > Date: Fri Apr 7 06:00:40 2017 -0700 > > [GR-3583] Update truffle import. > > commit 5282a7c3ffa0cbd0505a3825c718fee32ac1a202 > Author: Roland Schatz > > Date: Fri Apr 7 13:32:00 2017 +0200 > > Update truffle import. > > commit 633e40969f800a2231e5f7e7747f8eb812ebeb6e > Merge: d8d8c22 2bac7bc > Author: Christian Haeubl > > Date: Fri Apr 7 02:08:18 2017 -0700 > > [GR-3435] Cache JVMCI call results during graph decoding. > > commit 2bac7bcfcac159d4e7c5b63ab64a83b48b91300b > Author: Christian Haeubl > > Date: Thu Mar 30 17:10:55 2017 +0200 > > Cache methods while doing graph decoding. > > commit 10968ad0ed8432049ee937170df8fbf075807427 > Author: Christian Haeubl > > Date: Thu Mar 30 14:32:15 2017 +0200 > > Cache annotations while doing graph decoding. > > commit d8d8c22904a4cee00988356183e16aaac6cf4e01 > Merge: 0ea748e 5a50222 > Author: Josef Eisl > > Date: Thu Apr 6 09:39:21 2017 -0700 > > [GR-3515] Explicitly specify phases for compile time benchmarks. > > commit 89486753b1c8ba3dd85e259eef60556c84b43873 > Merge: cca4aa3 65e6110 > Author: Aleksandar Prokopec > > Date: Thu Apr 6 17:16:00 2017 +0200 > > Merge branch 'master' into topic/GR-3551 > > commit 0ea748e92d0ef075da80234cb6e8f2181c55ac88 > Merge: 65e6110 c60b383 > Author: Roland Schatz > > Date: Thu Apr 6 08:06:18 2017 -0700 > > [GR-3169] Graal produces wrong code for HeapByteBuffer on JDK9. > > commit cca4aa3eb4377d132cd314a57ff03b8cd7c21d61 > Merge: b7cb98d ccd2af9 > Author: Aleksandar Prokopec > > Date: Thu Apr 6 15:16:19 2017 +0200 > > Merge branch 'master' into topic/GR-3551 > > commit c152e63aaa3b0d00d714f33dfbf1c01a14e72acc > Author: Josef Eisl > > Date: Thu Apr 6 16:37:51 2017 +0200 > > [ci] do not execute scala-dacapo actors in parallel > > commit 65e61109f0edc70864767b200ae33a660c6e8dcb > Merge: 429d5da 57189f6 > Author: Doug Simon > > Date: Thu Apr 6 06:58:52 2017 -0700 > > [GR-3557] Fix regression in reading options from a file. > > commit c60b3830dc4765f2fd7f4d3f2dd85380bc6861e1 > Author: Roland Schatz > > Date: Thu Apr 6 15:36:10 2017 +0200 > > Fix escape analysis of byte array in HeapByteBuffer on JDK 9. > > commit 429d5da9377ac9f0951e472a93f68ad7d2fd40c8 > Merge: ccd2af9 926fe31 > Author: Gilles Duboscq > > Date: Thu Apr 6 06:11:27 2017 -0700 > > [GR-3522] Canonicalize `NormalizeCompare < 1`. > > commit b7cb98d8b43d92ce1a7591e05fc7e5e0c6e453ec > Author: Aleksandar Prokopec > > Date: Thu Apr 6 15:00:37 2017 +0200 > > Rewire node creation for CompareNode subclasses and add static creation methods that invoke canonicalization. > > commit ccd2af9473a022c66eb399d34db22986a4a1b00e > Merge: 01222aa 7f3278c > Author: David Leopoldseder > > Date: Thu Apr 6 05:17:49 2017 -0700 > > [GR-3568] NodeCostDumpUtil: swallow errors during class loading of nodes. > > commit 57189f612c106a041ecc4a79c82360c43ca581eb > Author: Doug Simon > > Date: Wed Apr 5 22:18:24 2017 +0200 > > fixed regression of handling options in a file > > commit 7f3278c8530a10d64c9d2e9d5c7c1525847655eb > Author: David Leopoldseder > > Date: Thu Apr 6 12:48:59 2017 +0200 > > [fix] NodeCostDumpUtil: swallow errors during class loading of nodes. > > commit 926fe31632e616776659c289f9376781647b98a1 > Author: Gilles Duboscq > > Date: Thu Apr 6 13:10:00 2017 +0200 > > Canonicalize `NormalizeCompare == c` > > commit 3a72610a51ba874a81c5b7dcd4a5b4dc13aece3b > Author: Gilles Duboscq > > Date: Tue Apr 4 19:38:10 2017 +0200 > > [GR-3522] Canonicalize `NormalizeCompare < 1` > > commit 01222aa50cd049253da87b18d9b86aa1fa8958f6 > Merge: 8145122 7c59459 > Author: Roland Schatz > > Date: Thu Apr 6 03:17:24 2017 -0700 > > [GR-2925] Graal support for Truffle TestTVMCI. > > commit 5a502228765bcf2a8f5243708a8c6de0fdad3f15 > Author: Josef Eisl > > Date: Wed Apr 5 16:49:57 2017 +0200 > > [ci] restrict TimingBenchmarkMixin timers > > commit bbcd46991b0b776eb69df17e2130ad9c5e095cab > Author: Josef Eisl > > Date: Tue Apr 4 13:34:26 2017 +0200 > > [ci] use -Dgraaldebug.timer.XXX instead of -Dgraal.Time= for TimingBenchmarkMixin > > commit 4974eb04f4ee81dc48e68eacc505b8e7524c91eb > Author: Josef Eisl > > Date: Tue Apr 4 13:23:30 2017 +0200 > > [ci] outsource timerArgs in TimingBenchmarkMixin > > commit 81451226de18cbe2ccb1f2f23c2110a5cf874169 > Merge: 2fc6719 42650bb > Author: David Leopoldseder > > Date: Thu Apr 6 01:20:45 2017 -0700 > > [GR-2552] NodeCost Model Improvements. > > commit 2fc6719fec619137e9e82d74be3c802341761790 > Merge: 7f32177 b1f5952 > Author: Josef Eisl > > Date: Thu Apr 6 00:46:25 2017 -0700 > > [GR-3514] Register allocation sub-phases do not need to be proper LIRPhases. > > commit 2d18d0a330c3123f9e62851580a2e18aed231697 > Author: Tom Rodriguez > > Date: Wed Apr 5 23:56:50 2017 -0700 > > Handle placeholder states specially in PEA > > commit 42650bbebbb8d89c66d5517cb761f9e92c1f68cf > Author: David Leopoldseder > > Date: Tue Feb 21 15:58:33 2017 +0100 > > [fix] NodeCost: Ensure all nodes specify default costs. > > commit caf972182c4bd958f658185520e32e88843b200d > Author: David Leopoldseder > > Date: Mon Feb 20 09:46:56 2017 +0100 > > [feature] NodeCosts: Verify node cost model integrity in CheckGraalInvariants. > > commit 7cd39f545c0db26610dc12eb37364b3d3265ec99 > Author: David Leopoldseder > > Date: Mon Jan 30 11:05:11 2017 +0100 > > [fix] NodeCosts: Remove provider, move dynamic logic into nodes and fix scale. > > commit fde0d24a2dddaf45e46cf6dc1dcade625261c5e3 > Author: David Leopoldseder > > Date: Mon Jan 30 15:46:45 2017 +0100 > > [feature] NodeCosts: Add option to dump node cost related information to IGV. > > commit e72bbb87cb4ec9b08f1ee9de9546a2166a5db54d > Author: David Leopoldseder > > Date: Mon Jan 30 15:08:01 2017 +0100 > > [feature] NodeCost: Add dump util to dump costs of all node classes > > commit 7f32177fad91fedabefea6e9919aa5f51657481b > Merge: 2eacdb3 ba5773e > Author: Doug Simon > > Date: Wed Apr 5 13:32:29 2017 -0700 > > [GR-3528] Convert some assertions in Node to guarantees. > > commit 63f10a5f38680435c750232702d183f05ad7e67f > Merge: cce0b88 2eacdb3 > Author: Aleksandar Prokopec > > Date: Wed Apr 5 21:47:11 2017 +0200 > > Merge branch 'master' into topic/GR-3551 > > commit 2eacdb37f19de982e14d1bb6ea224d2c5ad0c0cc > Merge: ee4cbef ba57d4d > Author: Doug Simon > > Date: Wed Apr 5 11:38:14 2017 -0700 > > [GR-3521] GraphBuilder: Change semantic of append to be recursive & remove recursiveAppend. > > commit ba57d4d7f716e5698e040196f9eeb03e2b4d42c5 > Merge: 48d9d36 ee4cbef > Author: Doug Simon > > Date: Wed Apr 5 19:45:58 2017 +0200 > > Merge branch 'master' into topic/GR-3521 > > commit cce0b8820624ff627b999a743ff9274e1ee5f9af > Author: Aleksandar Prokopec > > Date: Wed Apr 5 17:31:13 2017 +0200 > > Make LowerOp extends CompareOp from CompareNode. > > commit 41f62af348083b11684927a5222f92abead5bfec > Author: Aleksandar Prokopec > > Date: Wed Apr 5 17:13:44 2017 +0200 > > Introduce CompareOp to CompareNode. > > commit ba5773e0575c5d18974b8bc0470c0fc306161075 > Author: Doug Simon > > Date: Tue Apr 4 21:21:32 2017 +0200 > > deprecated varargs version of GraalError.guarantee and replaced with fixed arg versions > > commit bc448373357aa8825a2cca6be86d0573a8442f17 > Author: Doug Simon > > Date: Tue Apr 4 21:20:41 2017 +0200 > > converted some assertions in Node to be guarantees > > commit 48d9d363d0e78dad51d1b5a6c87ddbfe6df4cece > Author: David Leopoldseder > > Date: Wed Apr 5 10:07:43 2017 +0200 > > [fix] GraphBuilder: Change semantic of append to be recursive & remove recursiveAppend > > commit ee4cbef108f34b17b55ffab2100a59b9b3529881 > Merge: 898a31a ce55244 > Author: Aleksandar Prokopec > > Date: Wed Apr 5 02:55:54 2017 -0700 > > [GR-3208] Apply node plugins during graph decoding. > > commit ce55244ca5f6304c3c0a83233976f3fa7af852f4 > Merge: 3e99694 898a31a > Author: Aleksandar Prokopec > > Date: Wed Apr 5 11:08:41 2017 +0200 > > Merge branch 'master' into topic/GR-3208 > > commit b1f595227b39ea9017a62129780fd8eddd8ffb64 > Author: Josef Eisl > > Date: Tue Apr 4 15:44:19 2017 +0200 > > [fix] LSRA subphases do not need to be AllocationPhases > > commit 4898e53ab808bf5a0f92da49705743d6da55fd46 > Author: Josef Eisl > > Date: Tue Apr 4 15:54:36 2017 +0200 > > [fix] TraceRA: TraceLinearScanAllocationPhase is no TraceAllocationPhase > > commit 3e99694c859bc1e1243dd0cb2ffdeb52b3364a8a > Author: Aleksandar Prokopec > > Date: Mon Apr 3 11:10:37 2017 +0200 > > Move graph builder context allocation to relevant branches, and document the graph builder context subclass. > > commit f80747fbabf07d9b0b276e9f6db00629dcd2cd1e > Merge: ac63293 2de905e > Author: Aleksandar Prokopec > > Date: Fri Mar 31 16:01:10 2017 +0200 > > Merge branch 'master' into topic/GR-3208 > > commit 7c5945907a5e4c5737dd2dcbd52e4af9eb44cce5 > Author: Roland Schatz > > Date: Fri Mar 31 12:09:05 2017 +0200 > > Graal support for Truffle TestTVMCI. > > commit ac63293ed26263d161b0b0ba4b9fcce767f54899 > Merge: 61436b1 14702f0 > Author: Aleksandar Prokopec > > Date: Thu Mar 30 11:50:05 2017 +0200 > > Merge branch 'master' into topic/GR-3208 > > commit 61436b1743ea8d785e186fda82ce1d9e5f51334c > Merge: 9a18509 acbd663 > Author: Aleksandar Prokopec > > Date: Thu Mar 30 11:49:10 2017 +0200 > > Merge branch 'master' into topic/GR-3208 > > commit 9a18509ff88b8cd184f0f53bb363460741fd0328 > Author: Aleksandar Prokopec > > Date: Fri Mar 24 12:11:41 2017 +0100 > > Ensure that node plugins passed to the graph decoder handle all relevant node types. > > commit cacbd1effa1f1466c8d8b4978bd1d78b8d8b6941 > Author: Aleksandar Prokopec > > Date: Fri Mar 24 10:46:03 2017 +0100 > > Add overridable hook for instantiating node plugins. > > commit a71e6a7326a6a97d129734e22410993951aff00f > Author: Aleksandar Prokopec > > Date: Thu Mar 23 15:26:01 2017 +0100 > > Add on-demand handling of load-indexed nodes. > > commit d9165694fb9c486c6d05aafddcace65e55a4bf8e > Merge: e36255e f304652 > Author: Aleksandar Prokopec > > Date: Thu Mar 23 14:12:55 2017 +0100 > > Merge branch 'master' into topic/GR-3208-alternative > > commit e36255e119b994ddca01a54d5fc1c3976935eaf3 > Author: Aleksandar Prokopec > > Date: Fri Mar 17 11:29:34 2017 +0100 > > [refactor] Remove CompositeNodePlugin and use NodePlugin arrays instead. > > commit 859d2e0fe86cae9933fbc6ae71a7ccbad196baff > Author: Aleksandar Prokopec > > Date: Tue Mar 14 15:55:18 2017 +0100 > > [feature] Add support for all the node plugin cases to graph decoding. > > commit e45ae3f1fb381d505351e23ff1bfe5fa1faf97c6 > Author: Aleksandar Prokopec > > Date: Tue Mar 14 12:29:13 2017 +0100 > > [fix] Prevent node plugin graph changes when not necessary. > > commit f8589ed80ce1f759ae14cd7ee314b0f4d82e4cc4 > Author: Aleksandar Prokopec > > Date: Mon Mar 13 17:16:31 2017 +0100 > > [feature] Add node plugins to graph decoder, and implement the handleLoadIndexed case. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Apr 18 23:34:19 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Apr 2017 16:34:19 -0700 Subject: RFR(XL/M) : 8178788: wrap JCStress test suite as jtreg tests In-Reply-To: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> References: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> Message-ID: <565e6b33-844a-d08e-2e79-39f69c25e36c@oracle.com> Looks fine to me. Vladimir On 4/18/17 3:12 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >> 69903 lines changed: 69903 ins; 0 del; 0 mod; > (69524 lines are generated) > > Hi all, > > could you please review this patch which adds a jtreg test wrapper for jcstress test suite and jtreg tests which run jsctress tests thru this wrapper? > > webrev: http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8178788 > testing: applications/jcstress > > Thanks, > -- Igor > From vladimir.kozlov at oracle.com Tue Apr 18 23:36:33 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Apr 2017 16:36:33 -0700 Subject: RFR(S) : 8178835: CTW Runner should check that all classes have been compiled In-Reply-To: <4F275E2E-99FC-4661-B03A-9EFFD0472544@oracle.com> References: <4F275E2E-99FC-4661-B03A-9EFFD0472544@oracle.com> Message-ID: <681f0eb0-5523-79dc-8889-c1bffb542f7f@oracle.com> Okay. Vladimir On 4/18/17 3:49 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8178835/webrev.00/index.html >> 99 lines changed: 88 ins; 1 del; 10 mod > > Hi all, > > could you please review this small fix for CTW runner which adds verification that CTW was run for all classes? > currently, CTW runner stops execution when a child process exits w/ zero code, this might lead to missed test cover and/or false negative tests results. This fix adds a check that the index of the last compiled class equals to count of classes in a target. > > webrev: http://cr.openjdk.java.net/~iignatyev//8178835/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8178835 > testing: applications/ctw > > Thanks, > -- Igor > From vladimir.kozlov at oracle.com Tue Apr 18 23:37:57 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Apr 2017 16:37:57 -0700 Subject: RFR(XS) : 8178913 : CTW library does not close all opened resources In-Reply-To: <869ED692-650B-431B-9EF6-AAAE516AC499@oracle.com> References: <869ED692-650B-431B-9EF6-AAAE516AC499@oracle.com> Message-ID: Good. Vladimir On 4/18/17 11:33 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8178913/webrev.00/index.html >> 14 lines changed: 6 ins; 3 del; 5 mod; > > Hi all, > > could you please review this small fix for CTW library? there were several instance of resources leak in the library, this changeset fixes them by using try-w/-resource where applicable, and explicit close() call were not. > > webrev: http://cr.openjdk.java.net/~iignatyev//8178913/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8178913 > testing: hotspot/test/testlibrary_tests/ctw > > Thanks, > -- Igor > From vladimir.kozlov at oracle.com Tue Apr 18 23:46:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Apr 2017 16:46:52 -0700 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: References: Message-ID: <1d2886ef-1f65-0dc3-29a0-a1366b29218c@oracle.com> On 4/18/17 2:20 PM, Yuting Chen wrote: > Hi, are there any comments to this case? I found that the clinit > method will be compiled if it does not contain the infinite loop. Does > it mean that clinit will run before it is compiled. Yes, AOT compiler will run class initializer since it needs to access static fields and other values. Vladimir > > Re-paste the bytecode: > > public class Vector1 > minor version: 0 > major version: 52 > flags: ACC_PUBLIC, ACC_SUPER > Constant pool: > #1 = Utf8 Vector1 > #2 = Class #1 // Vector1 > #3 = Utf8 java/lang/Object > #4 = Class #3 // java/lang/Object > #5 = Utf8 serialVersionUID > #6 = Utf8 J > #7 = Long -2767605614048989439l > #9 = Utf8 > #10 = Utf8 ()V > #11 = NameAndType #5:#6 // serialVersionUID:J > #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J > #13 = Utf8 main > #14 = Utf8 ([Ljava/lang/String;)V > #15 = Utf8 ConstantValue > #16 = Utf8 Code > #17 = Utf8 StackMapTable > { > public static {}; > descriptor: ()V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=2, locals=0, args_size=0 > 0: ldc2_w #7 // long -2767605614048989439l > 3: putstatic #12 // Field serialVersionUID:J > 6: iconst_1 > 7: iconst_m1 > 8: iadd > 9: ifge 0 > 12: return > StackMapTable: number_of_entries = 1 > frame_type = 0 /* same */ > > public static void main(java.lang.String[]); > descriptor: ([Ljava/lang/String;)V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=0, locals=1, args_size=1 > 0: return > } > > On Tue, Apr 18, 2017 at 9:41 AM, Yuting Chen wrote: >> Hi, are there any comments to this case? I found that the clinit >> method will be compiled if it does not contain the infinite loop. It's >> weird. >> >> The bytecode is shown as follows: >> >> public class Vector1 >> minor version: 0 >> major version: 52 >> flags: ACC_PUBLIC, ACC_SUPER >> Constant pool: >> #1 = Utf8 Vector1 >> #2 = Class #1 // Vector1 >> #3 = Utf8 java/lang/Object >> #4 = Class #3 // java/lang/Object >> #5 = Utf8 serialVersionUID >> #6 = Utf8 J >> #7 = Long -2767605614048989439l >> #9 = Utf8 >> #10 = Utf8 ()V >> #11 = NameAndType #5:#6 // serialVersionUID:J >> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >> #13 = Utf8 main >> #14 = Utf8 ([Ljava/lang/String;)V >> #15 = Utf8 ConstantValue >> #16 = Utf8 Code >> #17 = Utf8 StackMapTable >> { >> public static {}; >> descriptor: ()V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=2, locals=0, args_size=0 >> 0: ldc2_w #7 // long -2767605614048989439l >> 3: putstatic #12 // Field serialVersionUID:J >> 6: iconst_1 >> 7: iconst_m1 >> 8: iadd >> 9: ifge 0 >> 12: return >> StackMapTable: number_of_entries = 1 >> frame_type = 0 /* same */ >> >> public static void main(java.lang.String[]); >> descriptor: ([Ljava/lang/String;)V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=0, locals=1, args_size=1 >> 0: return >> } From chenyt.cs.sjtu at gmail.com Wed Apr 19 00:17:43 2017 From: chenyt.cs.sjtu at gmail.com (Yuting Chen) Date: Tue, 18 Apr 2017 17:17:43 -0700 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: <1d2886ef-1f65-0dc3-29a0-a1366b29218c@oracle.com> References: <1d2886ef-1f65-0dc3-29a0-a1366b29218c@oracle.com> Message-ID: Thank you, Vladimir. Should it be better if the compiler can report a timeout error for such a class initializer? On Tue, Apr 18, 2017 at 4:46 PM, Vladimir Kozlov wrote: > On 4/18/17 2:20 PM, Yuting Chen wrote: >> >> Hi, are there any comments to this case? I found that the clinit >> method will be compiled if it does not contain the infinite loop. Does >> it mean that clinit will run before it is compiled. > > > Yes, AOT compiler will run class initializer since it needs to access static > fields and other values. > > Vladimir > > >> >> Re-paste the bytecode: >> >> public class Vector1 >> minor version: 0 >> major version: 52 >> flags: ACC_PUBLIC, ACC_SUPER >> Constant pool: >> #1 = Utf8 Vector1 >> #2 = Class #1 // Vector1 >> #3 = Utf8 java/lang/Object >> #4 = Class #3 // java/lang/Object >> #5 = Utf8 serialVersionUID >> #6 = Utf8 J >> #7 = Long -2767605614048989439l >> #9 = Utf8 >> #10 = Utf8 ()V >> #11 = NameAndType #5:#6 // serialVersionUID:J >> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >> #13 = Utf8 main >> #14 = Utf8 ([Ljava/lang/String;)V >> #15 = Utf8 ConstantValue >> #16 = Utf8 Code >> #17 = Utf8 StackMapTable >> { >> public static {}; >> descriptor: ()V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=2, locals=0, args_size=0 >> 0: ldc2_w #7 // long >> -2767605614048989439l >> 3: putstatic #12 // Field serialVersionUID:J >> 6: iconst_1 >> 7: iconst_m1 >> 8: iadd >> 9: ifge 0 >> 12: return >> StackMapTable: number_of_entries = 1 >> frame_type = 0 /* same */ >> >> public static void main(java.lang.String[]); >> descriptor: ([Ljava/lang/String;)V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=0, locals=1, args_size=1 >> 0: return >> } >> >> On Tue, Apr 18, 2017 at 9:41 AM, Yuting Chen >> wrote: >>> >>> Hi, are there any comments to this case? I found that the clinit >>> method will be compiled if it does not contain the infinite loop. It's >>> weird. >>> >>> The bytecode is shown as follows: >>> >>> public class Vector1 >>> minor version: 0 >>> major version: 52 >>> flags: ACC_PUBLIC, ACC_SUPER >>> Constant pool: >>> #1 = Utf8 Vector1 >>> #2 = Class #1 // Vector1 >>> #3 = Utf8 java/lang/Object >>> #4 = Class #3 // java/lang/Object >>> #5 = Utf8 serialVersionUID >>> #6 = Utf8 J >>> #7 = Long -2767605614048989439l >>> #9 = Utf8 >>> #10 = Utf8 ()V >>> #11 = NameAndType #5:#6 // serialVersionUID:J >>> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >>> #13 = Utf8 main >>> #14 = Utf8 ([Ljava/lang/String;)V >>> #15 = Utf8 ConstantValue >>> #16 = Utf8 Code >>> #17 = Utf8 StackMapTable >>> { >>> public static {}; >>> descriptor: ()V >>> flags: ACC_PUBLIC, ACC_STATIC >>> Code: >>> stack=2, locals=0, args_size=0 >>> 0: ldc2_w #7 // long >>> -2767605614048989439l >>> 3: putstatic #12 // Field >>> serialVersionUID:J >>> 6: iconst_1 >>> 7: iconst_m1 >>> 8: iadd >>> 9: ifge 0 >>> 12: return >>> StackMapTable: number_of_entries = 1 >>> frame_type = 0 /* same */ >>> >>> public static void main(java.lang.String[]); >>> descriptor: ([Ljava/lang/String;)V >>> flags: ACC_PUBLIC, ACC_STATIC >>> Code: >>> stack=0, locals=1, args_size=1 >>> 0: return >>> } From david.holmes at oracle.com Wed Apr 19 01:28:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Apr 2017 11:28:11 +1000 Subject: RFR(XL/M) : 8178788: wrap JCStress test suite as jtreg tests In-Reply-To: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> References: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> Message-ID: <5a1da3e4-622b-66a4-1228-4a7e3ebbee91@oracle.com> Hi Igor, On 19/04/2017 8:12 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >> 69903 lines changed: 69903 ins; 0 del; 0 mod; > (69524 lines are generated) > > Hi all, > > could you please review this patch which adds a jtreg test wrapper for jcstress test suite and jtreg tests which run jsctress tests thru this wrapper? > > webrev: http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8178788 > testing: applications/jcstress This looks really good! Only concern is that according to the docs jtreg doesn't seem to support multiple test declarations in a single file ?? Maybe the docs are out of date? http://openjdk.java.net/jtreg/tag-spec.html A few grammatical nits in the README: 23 The tests located under this directory run tests from Java Concurrency Stress from Java -> from the Java 24 [1] aka jcstress test suite. This suite aims to verify the correctness of Suggest: test suite [1] (a.k.a. jcstress). This suite ... 25 concurrency support in JDK. in JDK -> in the JDK 27 All the tests are run thought test driver class -- JcstressRunner, which s/thought/through the/ 29 spawns a new JVM to run one jsctress test and checks that it is finished is finished -> finishes 33 changed, one should make corresponding changes in the artifact description in in the -> to the 36 */Test.java files should never be modified directly, because they are Insert "The" at start. --- General Java style nits re long ling wrapping. You seem to be using a consistent "indent by 8" style when wrapping long lines. The "usual" style guidelines suggest a more structured indentation style, for example: - when wrapping the arguments to a call align after the opening ( of the call ie: throw new Error("TESTBUG: Can not resolve artifacts for " + JcstressRunner.class.getName(), e); - when you have chained method calls, try to align at the dots ie: return artifacts.get("org.openjdk.jcstress.jcstress-tests-all-0.3") .toAbsolutePath(); and ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(getCmd(args)) .redirectErrorStream(true) .redirectOutput(out.toFile()); --- test/applications/jcstress/TestGenerator.java 44 * This is a test generator, should be run only when jsctress is changed Typo: jsctress -> jcstress 51 * Use jcstress test suite to generates generates -> generate Strictly speaking the copyright years should only be updated when there is a substantive change to the text of the file, so updating whenever the files are regenerated is not really correct. This may need to be manually adjusted when commiting updated files ... though if there is no change other than to copyright year then the changes can simply be ignored (hg revert) and no update pushed. Thanks, David ------ > Thanks, > -- Igor > From chenyt.cs.sjtu at gmail.com Wed Apr 19 02:09:24 2017 From: chenyt.cs.sjtu at gmail.com (Yuting Chen) Date: Tue, 18 Apr 2017 19:09:24 -0700 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: References: <1d2886ef-1f65-0dc3-29a0-a1366b29218c@oracle.com> Message-ID: Besides, if a class initializer writes into an external file (or make some computations), the compiler will have side effects when compiling the corresponding class, :). On Tue, Apr 18, 2017 at 5:17 PM, Yuting Chen wrote: > Thank you, Vladimir. Should it be better if the compiler can report a > timeout error for such a class initializer? > > On Tue, Apr 18, 2017 at 4:46 PM, Vladimir Kozlov > wrote: >> On 4/18/17 2:20 PM, Yuting Chen wrote: >>> >>> Hi, are there any comments to this case? I found that the clinit >>> method will be compiled if it does not contain the infinite loop. Does >>> it mean that clinit will run before it is compiled. >> >> >> Yes, AOT compiler will run class initializer since it needs to access static >> fields and other values. >> >> Vladimir >> >> >>> >>> Re-paste the bytecode: >>> >>> public class Vector1 >>> minor version: 0 >>> major version: 52 >>> flags: ACC_PUBLIC, ACC_SUPER >>> Constant pool: >>> #1 = Utf8 Vector1 >>> #2 = Class #1 // Vector1 >>> #3 = Utf8 java/lang/Object >>> #4 = Class #3 // java/lang/Object >>> #5 = Utf8 serialVersionUID >>> #6 = Utf8 J >>> #7 = Long -2767605614048989439l >>> #9 = Utf8 >>> #10 = Utf8 ()V >>> #11 = NameAndType #5:#6 // serialVersionUID:J >>> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >>> #13 = Utf8 main >>> #14 = Utf8 ([Ljava/lang/String;)V >>> #15 = Utf8 ConstantValue >>> #16 = Utf8 Code >>> #17 = Utf8 StackMapTable >>> { >>> public static {}; >>> descriptor: ()V >>> flags: ACC_PUBLIC, ACC_STATIC >>> Code: >>> stack=2, locals=0, args_size=0 >>> 0: ldc2_w #7 // long >>> -2767605614048989439l >>> 3: putstatic #12 // Field serialVersionUID:J >>> 6: iconst_1 >>> 7: iconst_m1 >>> 8: iadd >>> 9: ifge 0 >>> 12: return >>> StackMapTable: number_of_entries = 1 >>> frame_type = 0 /* same */ >>> >>> public static void main(java.lang.String[]); >>> descriptor: ([Ljava/lang/String;)V >>> flags: ACC_PUBLIC, ACC_STATIC >>> Code: >>> stack=0, locals=1, args_size=1 >>> 0: return >>> } >>> >>> On Tue, Apr 18, 2017 at 9:41 AM, Yuting Chen >>> wrote: >>>> >>>> Hi, are there any comments to this case? I found that the clinit >>>> method will be compiled if it does not contain the infinite loop. It's >>>> weird. >>>> >>>> The bytecode is shown as follows: >>>> >>>> public class Vector1 >>>> minor version: 0 >>>> major version: 52 >>>> flags: ACC_PUBLIC, ACC_SUPER >>>> Constant pool: >>>> #1 = Utf8 Vector1 >>>> #2 = Class #1 // Vector1 >>>> #3 = Utf8 java/lang/Object >>>> #4 = Class #3 // java/lang/Object >>>> #5 = Utf8 serialVersionUID >>>> #6 = Utf8 J >>>> #7 = Long -2767605614048989439l >>>> #9 = Utf8 >>>> #10 = Utf8 ()V >>>> #11 = NameAndType #5:#6 // serialVersionUID:J >>>> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >>>> #13 = Utf8 main >>>> #14 = Utf8 ([Ljava/lang/String;)V >>>> #15 = Utf8 ConstantValue >>>> #16 = Utf8 Code >>>> #17 = Utf8 StackMapTable >>>> { >>>> public static {}; >>>> descriptor: ()V >>>> flags: ACC_PUBLIC, ACC_STATIC >>>> Code: >>>> stack=2, locals=0, args_size=0 >>>> 0: ldc2_w #7 // long >>>> -2767605614048989439l >>>> 3: putstatic #12 // Field >>>> serialVersionUID:J >>>> 6: iconst_1 >>>> 7: iconst_m1 >>>> 8: iadd >>>> 9: ifge 0 >>>> 12: return >>>> StackMapTable: number_of_entries = 1 >>>> frame_type = 0 /* same */ >>>> >>>> public static void main(java.lang.String[]); >>>> descriptor: ([Ljava/lang/String;)V >>>> flags: ACC_PUBLIC, ACC_STATIC >>>> Code: >>>> stack=0, locals=1, args_size=1 >>>> 0: return >>>> } From igor.ignatyev at oracle.com Wed Apr 19 02:51:42 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Apr 2017 19:51:42 -0700 Subject: RFR(XL/M) : 8178788: wrap JCStress test suite as jtreg tests In-Reply-To: <5a1da3e4-622b-66a4-1228-4a7e3ebbee91@oracle.com> References: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> <5a1da3e4-622b-66a4-1228-4a7e3ebbee91@oracle.com> Message-ID: <33C90E84-6872-4DC4-B6F9-74055D943876@oracle.com> Hi David, thank you for your comments, I've tried to address them all, please look at the incremental webrev: http://cr.openjdk.java.net/~iignatyev/8178788/webrev.00-01/index.html regarding multiple test declarations, jtreg supports that, but in the current version it's not fully/officially supported and hence it's not documented. Jon has fixed a few jtreg bugs[1-3] related to this and AFAIK is working towards full support, so I hope it will be supported and documented in the next promoted build of jtreg. [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7900144 : Implement multiple tests in one file in jtreg [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7901914 : Failure to find multiple @test in a single file [3] https://bugs.openjdk.java.net/browse/CODETOOLS-7901940 : support multiple @test in one test file Thanks, -- Igor > On Apr 18, 2017, at 6:28 PM, David Holmes wrote: > > Hi Igor, > > On 19/04/2017 8:12 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >>> 69903 lines changed: 69903 ins; 0 del; 0 mod; >> (69524 lines are generated) >> >> Hi all, >> >> could you please review this patch which adds a jtreg test wrapper for jcstress test suite and jtreg tests which run jsctress tests thru this wrapper? >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8178788 >> testing: applications/jcstress > > This looks really good! Only concern is that according to the docs jtreg doesn't seem to support multiple test declarations in a single file ?? Maybe the docs are out of date? > > http://openjdk.java.net/jtreg/tag-spec.html > > A few grammatical nits in the README: > > 23 The tests located under this directory run tests from Java Concurrency Stress > > from Java -> from the Java > > 24 [1] aka jcstress test suite. This suite aims to verify the correctness of > > Suggest: > > test suite [1] (a.k.a. jcstress). This suite ... > > 25 concurrency support in JDK. > > in JDK -> in the JDK > > 27 All the tests are run thought test driver class -- JcstressRunner, which > > s/thought/through the/ > > 29 spawns a new JVM to run one jsctress test and checks that it is finished > > is finished -> finishes > > 33 changed, one should make corresponding changes in the artifact description in > > in the -> to the > > 36 */Test.java files should never be modified directly, because they are > > Insert "The" at start. > > --- > > General Java style nits re long ling wrapping. You seem to be using a consistent "indent by 8" style when wrapping long lines. The "usual" style guidelines suggest a more structured indentation style, for example: > > - when wrapping the arguments to a call align after the opening ( of the call ie: > > throw new Error("TESTBUG: Can not resolve artifacts for " > + JcstressRunner.class.getName(), e); > > - when you have chained method calls, try to align at the dots ie: > > return artifacts.get("org.openjdk.jcstress.jcstress-tests-all-0.3") > .toAbsolutePath(); > > and > > ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(getCmd(args)) > .redirectErrorStream(true) > .redirectOutput(out.toFile()); > > --- > > test/applications/jcstress/TestGenerator.java > > 44 * This is a test generator, should be run only when jsctress is changed > > Typo: jsctress -> jcstress > > 51 * Use jcstress test suite to generates > > generates -> generate > > Strictly speaking the copyright years should only be updated when there is a substantive change to the text of the file, so updating whenever the files are regenerated is not really correct. This may need to be manually adjusted when commiting updated files ... though if there is no change other than to copyright year then the changes can simply be ignored (hg revert) and no update pushed. > > Thanks, > David > ------ > >> Thanks, >> -- Igor >> From igor.ignatyev at oracle.com Wed Apr 19 03:11:48 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Apr 2017 20:11:48 -0700 Subject: RFR(S) : 8178835: CTW Runner should check that all classes have been compiled In-Reply-To: <681f0eb0-5523-79dc-8889-c1bffb542f7f@oracle.com> References: <4F275E2E-99FC-4661-B03A-9EFFD0472544@oracle.com> <681f0eb0-5523-79dc-8889-c1bffb542f7f@oracle.com> Message-ID: <1F32711A-A352-452D-BFA4-CA45AEDD533C@oracle.com> Vladimir, Thank you for the review! -- Igor > On Apr 18, 2017, at 4:36 PM, Vladimir Kozlov wrote: > > Okay. > > Vladimir > > On 4/18/17 3:49 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8178835/webrev.00/index.html >>> 99 lines changed: 88 ins; 1 del; 10 mod >> >> Hi all, >> >> could you please review this small fix for CTW runner which adds verification that CTW was run for all classes? >> currently, CTW runner stops execution when a child process exits w/ zero code, this might lead to missed test cover and/or false negative tests results. This fix adds a check that the index of the last compiled class equals to count of classes in a target. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8178835/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8178835 >> testing: applications/ctw >> >> Thanks, >> -- Igor >> From igor.ignatyev at oracle.com Wed Apr 19 03:12:10 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Apr 2017 20:12:10 -0700 Subject: RFR(XS) : 8178913 : CTW library does not close all opened resources In-Reply-To: References: <869ED692-650B-431B-9EF6-AAAE516AC499@oracle.com> Message-ID: Thanks for your review. -- Igor > On Apr 18, 2017, at 4:37 PM, Vladimir Kozlov wrote: > > Good. > > Vladimir > > On 4/18/17 11:33 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8178913/webrev.00/index.html >>> 14 lines changed: 6 ins; 3 del; 5 mod; >> >> Hi all, >> >> could you please review this small fix for CTW library? there were several instance of resources leak in the library, this changeset fixes them by using try-w/-resource where applicable, and explicit close() call were not. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8178913/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8178913 >> testing: hotspot/test/testlibrary_tests/ctw >> >> Thanks, >> -- Igor >> From igor.veresov at oracle.com Wed Apr 19 03:15:55 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 18 Apr 2017 20:15:55 -0700 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: References: <1d2886ef-1f65-0dc3-29a0-a1366b29218c@oracle.com> Message-ID: <39E0280D-96CB-4E6F-8038-B7DBC820E22D@oracle.com> We know :) https://bugs.openjdk.java.net/browse/JDK-8146201 igor > On Apr 18, 2017, at 7:09 PM, Yuting Chen wrote: > > Besides, if a class initializer writes into an external file (or make > some computations), the compiler will have side effects when compiling > the corresponding class, :). > > On Tue, Apr 18, 2017 at 5:17 PM, Yuting Chen wrote: >> Thank you, Vladimir. Should it be better if the compiler can report a >> timeout error for such a class initializer? >> >> On Tue, Apr 18, 2017 at 4:46 PM, Vladimir Kozlov >> wrote: >>> On 4/18/17 2:20 PM, Yuting Chen wrote: >>>> >>>> Hi, are there any comments to this case? I found that the clinit >>>> method will be compiled if it does not contain the infinite loop. Does >>>> it mean that clinit will run before it is compiled. >>> >>> >>> Yes, AOT compiler will run class initializer since it needs to access static >>> fields and other values. >>> >>> Vladimir >>> >>> >>>> >>>> Re-paste the bytecode: >>>> >>>> public class Vector1 >>>> minor version: 0 >>>> major version: 52 >>>> flags: ACC_PUBLIC, ACC_SUPER >>>> Constant pool: >>>> #1 = Utf8 Vector1 >>>> #2 = Class #1 // Vector1 >>>> #3 = Utf8 java/lang/Object >>>> #4 = Class #3 // java/lang/Object >>>> #5 = Utf8 serialVersionUID >>>> #6 = Utf8 J >>>> #7 = Long -2767605614048989439l >>>> #9 = Utf8 >>>> #10 = Utf8 ()V >>>> #11 = NameAndType #5:#6 // serialVersionUID:J >>>> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >>>> #13 = Utf8 main >>>> #14 = Utf8 ([Ljava/lang/String;)V >>>> #15 = Utf8 ConstantValue >>>> #16 = Utf8 Code >>>> #17 = Utf8 StackMapTable >>>> { >>>> public static {}; >>>> descriptor: ()V >>>> flags: ACC_PUBLIC, ACC_STATIC >>>> Code: >>>> stack=2, locals=0, args_size=0 >>>> 0: ldc2_w #7 // long >>>> -2767605614048989439l >>>> 3: putstatic #12 // Field serialVersionUID:J >>>> 6: iconst_1 >>>> 7: iconst_m1 >>>> 8: iadd >>>> 9: ifge 0 >>>> 12: return >>>> StackMapTable: number_of_entries = 1 >>>> frame_type = 0 /* same */ >>>> >>>> public static void main(java.lang.String[]); >>>> descriptor: ([Ljava/lang/String;)V >>>> flags: ACC_PUBLIC, ACC_STATIC >>>> Code: >>>> stack=0, locals=1, args_size=1 >>>> 0: return >>>> } >>>> >>>> On Tue, Apr 18, 2017 at 9:41 AM, Yuting Chen >>>> wrote: >>>>> >>>>> Hi, are there any comments to this case? I found that the clinit >>>>> method will be compiled if it does not contain the infinite loop. It's >>>>> weird. >>>>> >>>>> The bytecode is shown as follows: >>>>> >>>>> public class Vector1 >>>>> minor version: 0 >>>>> major version: 52 >>>>> flags: ACC_PUBLIC, ACC_SUPER >>>>> Constant pool: >>>>> #1 = Utf8 Vector1 >>>>> #2 = Class #1 // Vector1 >>>>> #3 = Utf8 java/lang/Object >>>>> #4 = Class #3 // java/lang/Object >>>>> #5 = Utf8 serialVersionUID >>>>> #6 = Utf8 J >>>>> #7 = Long -2767605614048989439l >>>>> #9 = Utf8 >>>>> #10 = Utf8 ()V >>>>> #11 = NameAndType #5:#6 // serialVersionUID:J >>>>> #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J >>>>> #13 = Utf8 main >>>>> #14 = Utf8 ([Ljava/lang/String;)V >>>>> #15 = Utf8 ConstantValue >>>>> #16 = Utf8 Code >>>>> #17 = Utf8 StackMapTable >>>>> { >>>>> public static {}; >>>>> descriptor: ()V >>>>> flags: ACC_PUBLIC, ACC_STATIC >>>>> Code: >>>>> stack=2, locals=0, args_size=0 >>>>> 0: ldc2_w #7 // long >>>>> -2767605614048989439l >>>>> 3: putstatic #12 // Field >>>>> serialVersionUID:J >>>>> 6: iconst_1 >>>>> 7: iconst_m1 >>>>> 8: iadd >>>>> 9: ifge 0 >>>>> 12: return >>>>> StackMapTable: number_of_entries = 1 >>>>> frame_type = 0 /* same */ >>>>> >>>>> public static void main(java.lang.String[]); >>>>> descriptor: ([Ljava/lang/String;)V >>>>> flags: ACC_PUBLIC, ACC_STATIC >>>>> Code: >>>>> stack=0, locals=1, args_size=1 >>>>> 0: return >>>>> } -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Wed Apr 19 03:26:21 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 18 Apr 2017 20:26:21 -0700 Subject: RFR(XXL) 8178864: Update Graal In-Reply-To: <2D2B20C1-65C5-4DBE-BC74-0D280D686D49@twitter.com> References: <008050D5-DEC7-4117-8EEF-B77BF3E22B24@oracle.com> <2D2B20C1-65C5-4DBE-BC74-0D280D686D49@twitter.com> Message-ID: It goes something like this: update-graal() { cd ~/work/jdk10-hs/hotspot/src/jdk.internal.vm.compiler/share/classes/ rm -rf org.graalvm.* cp -R ~/work/veresov-graal/graal-core/graal/org.graalvm.* . rm -rf org.graalvm.compiler.truffle* cd ~/work/jdk10-hs/hotspot hg add `hg status -un` hg rm `hg status -dn` } Note, that I?m not doing merges. It?s just a plain copy of Graal from GitHub. And then you?d have to update suites.py manually.. igor > On Apr 18, 2017, at 4:03 PM, Christian Thalinger wrote: > > Igor, do you have a script you are using to update Graal in OpenJDK? If yes, could you share it? > >> On Apr 17, 2017, at 11:08 AM, Igor Veresov > wrote: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8178864 >> Webrev: http://cr.openjdk.java.net/~iveresov/8178864/webrev.00/ >> >> Thanks, >> igor >> >> p.s. >> >> Changes: >> >> commit 415a4ef635029f49ab2c4fef0e6f2012be916db7 >> Merge: 768caab 294900b >> Author: Tom Rodriguez > >> Date: Mon Apr 17 10:36:23 2017 -0700 >> >> [GR-3667] Fix probability for intrinsic guard. >> >> commit 294900b270c2f866a9a33a3a027a63ba85562792 >> Author: Tom Rodriguez > >> Date: Fri Apr 14 10:00:47 2017 -0700 >> >> Fix probability for intrinsic guard >> >> commit 768caabc4aad572e7fa8a08e708b81eaf9c8e119 >> Merge: c3ab66a 78f5562 >> Author: Doug Simon > >> Date: Mon Apr 17 09:06:14 2017 -0700 >> >> [GR-3673] Remove forced dumps. >> >> commit c3ab66a7fb72311ed479d0f47b87cf867453915d >> Merge: 4d1095d 9a66f88 >> Author: Tom Rodriguez > >> Date: Mon Apr 17 09:01:21 2017 -0700 >> >> [GR-3657] Fix possible infinite loop in nodesInLoopBranch. >> >> commit 9a66f887d1f6c8308f15c8c8df7c40578923369c >> Author: Tom Rodriguez > >> Date: Thu Apr 13 21:20:49 2017 -0700 >> >> Fix possible infinite loop in nodesInLoopBranch >> >> commit 78f55621c9301ae9c6e6e5b8d0d3fab7c2e4de6c >> Author: Doug Simon > >> Date: Mon Apr 17 10:41:29 2017 +0200 >> >> removed uses of Debug.forceDump that pollute test logs >> >> commit 4d1095d1ea9fc4c317c7f584a02344e64df7a5f3 >> Merge: 02a2a3d cf9a623 >> Author: Christian Wimmer > >> Date: Fri Apr 14 10:25:21 2017 -0700 >> >> [GR-3666] Remove redundant final modifier as reported by newest Checkstyle version. >> >> commit cf9a6238a826e77c94ab0602c2214b0f0afd1aa6 >> Author: Christian Wimmer > >> Date: Fri Apr 14 09:02:55 2017 -0700 >> >> Remove redundant final modifier as reported by newest Checkstyle version >> >> commit 02a2a3d9ba60c5db87c83c701a500e41d79583b2 >> Merge: e8acaea 92a1821 >> Author: Josef Eisl > >> Date: Fri Apr 14 02:24:54 2017 -0700 >> >> [GR-3206] The parallel scala actors fix should not overwrite the other results. >> >> commit e8acaea4d026244a187e50f9f39206730473da30 >> Merge: 52a9ed9 fa1e93f >> Author: Doug Simon > >> Date: Thu Apr 13 07:57:55 2017 -0700 >> >> [GR-3627] Correct various errors in code generation (#267). >> >> commit 52a9ed925be5511d7984174136d07a2568cd83e5 >> Merge: 0c30850 fc12456 >> Author: Matthias Grimmer > >> Date: Thu Apr 13 07:04:06 2017 -0700 >> >> [GR-3642] Explicit hosted (e.g. hosted-graal-core) jvm-config. >> >> commit 92a18214d2279ab421c15300d46bab93cac90619 >> Author: Josef Eisl > >> Date: Thu Apr 13 15:51:51 2017 +0200 >> >> [ci,fix] the parallel scala actors fix should not overwrite the other results >> >> commit fa1e93f806c16dfe79b79cc0932b5d2bbea342c4 >> Merge: 425a9c4 f1f981e >> Author: Doug Simon > >> Date: Thu Apr 13 15:27:39 2017 +0200 >> >> Merge. >> >> commit fc12456b4e654a51009b07d1ff437622bcc5e2b7 >> Author: Matthias Grimmer > >> Date: Thu Apr 13 11:27:16 2017 +0200 >> >> Add hosted configurations to mx benchmark. >> >> commit 0c30850da9fcf74d0b08e3e53f4a99e036294d30 >> Merge: f1f981e fdf7341 >> Author: Roland Schatz > >> Date: Thu Apr 13 04:11:34 2017 -0700 >> >> [GR-3629] Fix wrong callRootMethod in GraalTestTVMCI. >> >> commit 425a9c4e4d346b1018786d02ba3d9d0a6433cae4 >> Author: Andrew Dinn > >> Date: Wed Apr 12 15:43:56 2017 +0100 >> >> fix problem in emit for CompressRegister and Uncompressregister >> >> commit fdf7341635824a7c6eb3b7be908dd74372aa4736 >> Author: Roland Schatz > >> Date: Wed Apr 12 15:50:26 2017 +0200 >> >> Fix wrong callRootMethod in GraalTestTVMCI. >> >> commit 1c0da37a2cff42a9b46cdfad40d9ccc932e948cb >> Author: Andrew Dinn > >> Date: Wed Apr 12 14:53:56 2017 +0100 >> >> correct cut-and-pasteo in original patch >> >> commit cb8ee4804de9bec5eea213470bd237a83c981cac >> Author: Andrew Dinn > >> Date: Wed Apr 12 13:50:36 2017 +0100 >> >> correct two small errors in code generation >> >> commit f1f981e8002fa6de2989fc223d67d7589d11c0c0 >> Merge: 1e9c29d 3685425 >> Author: Doug Simon > >> Date: Wed Apr 12 04:46:39 2017 -0700 >> >> [GR-3598] Remove use of JDK internal API in CompileTheWorld. >> >> commit 1e9c29d7bd62ddb5b0180d081db7b9230ea9383d >> Merge: 8b0ff79 e01a696 >> Author: Doug Simon > >> Date: Wed Apr 12 01:46:57 2017 -0700 >> >> [GR-3610] Unstrip VM output when running with stripped jars. >> >> commit 8b0ff796db6d6d5eae4711f3740b9ec18b68a284 >> Merge: dde444f 78aecaa >> Author: Paul W?gerer > >> Date: Wed Apr 12 01:19:57 2017 -0700 >> >> [GR-3556] Handle inlining during parsing more like inlining after parsing. >> >> commit e01a696368522b6965e2a73155881ce873858b1d >> Author: Doug Simon > >> Date: Tue Apr 11 14:25:13 2017 +0200 >> >> apply retrace tool to VM output if running with stripped jars >> >> commit 368542591c5d5d0547774cf556217f38b4fd162d >> Author: Doug Simon > >> Date: Mon Apr 10 17:17:00 2017 +0200 >> >> moved CompileTheWorld out of GRAAL dist and removed its use of JDK internal API >> added CTW 9 tests to gate >> >> commit 78aecaa0a0ac7bbecbdc820f3393eaf09fddb16e >> Author: Christian Wimmer > >> Date: Tue Apr 11 13:49:23 2017 -0700 >> >> Handle inlining during parsing more like inlining after parsing >> >> When a method has multiple returns, inlinig during parsing created a merge frame state with a bci of one of the return bytecodes. Now the handling is the same as in the inlining phase: the merge frame state that does not include the callee (just the caller frame state after the call). >> >> commit dde444fdb4608a48b90dacd32719c12efb59f84c >> Merge: 8c016d0 1d1a3b0 >> Author: Tom Rodriguez > >> Date: Tue Apr 11 13:49:12 2017 -0700 >> >> [GR-3153] Revert Handle placeholder states specially in PEA. >> >> commit 1d1a3b0e18c8c0e5499c719d658013967111e875 >> Author: Tom Rodriguez > >> Date: Tue Apr 11 13:12:10 2017 -0700 >> >> Revert Handle placeholder states specially in PEA >> >> commit 8c016d06d3c18ce9a62d958bf3bed6b30b997687 >> Merge: 4c4144b 9735c8c >> Author: David Leopoldseder > >> Date: Tue Apr 11 10:17:45 2017 -0700 >> >> [GR-3476] Remove TruffleCompilationCancellationTest. >> >> commit 4c4144b71d527d984637ade1c0ba8f361c326143 >> Merge: 978c49a a1d0705 >> Author: Aleksandar Prokopec > >> Date: Tue Apr 11 05:53:09 2017 -0700 >> >> [GR-3601] Ensure that a more specific create method is used when creating comparison nodes. >> >> commit a1d0705cd0b7f74075208365bd42b78cdaf1eff2 >> Author: Aleksandar Prokopec > >> Date: Mon Apr 10 17:25:10 2017 +0200 >> >> Use more specific create method for comparison nodes. >> >> commit 978c49ae5c2b4d9cfb000a4c0917b18ef255857d >> Merge: d07c8b2 af5dd81 >> Author: Christian Haeubl > >> Date: Tue Apr 11 05:11:50 2017 -0700 >> >> [GR-3595] Cache if a method is covered by an InvocationPlugin. >> >> commit af5dd81295c8d7f8070fd051c9848599459afffe >> Author: Christian Haeubl > >> Date: Mon Apr 10 12:10:23 2017 +0200 >> >> Cache if a method is covered by an InvocationPlugin. >> >> commit d07c8b25d76f5956d6d7b62849eafc8ba944abe0 >> Merge: c72a5d5 d53ce49 >> Author: Vojin Jovanovic > >> Date: Tue Apr 11 03:39:18 2017 -0700 >> >> [GR-3393] Revert. >> >> commit d53ce499e9ce85de2303e642d17ca069b1a47af2 >> Author: Vojin Jovanovic > >> Date: Tue Apr 11 11:38:42 2017 +0200 >> >> Revert "[GR-3393] Separate compressed oops from HotSpot as much as possible." >> >> This reverts commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43, reversing >> changes made to a872965c61c942ce33fd295a2280dcb54a3b38f4. >> >> commit 9735c8c573c1b869b38dbe8cabbf37ebcb82a4e7 >> Author: David Leopoldseder > >> Date: Tue Apr 11 10:59:33 2017 +0200 >> >> [fix] Remove TruffleCompilationCancellationTest. >> >> commit c72a5d5e78538cea5d42967b238fe91198c95ae3 >> Merge: 0b9c9ee 2d18d0a >> Author: Tom Rodriguez > >> Date: Mon Apr 10 09:38:09 2017 -0700 >> >> [GR-3153] Handle placeholder states specially in PEA. >> >> commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43 >> Merge: a872965 eb2ef20 >> Author: Vojin Jovanovic > >> Date: Mon Apr 10 07:25:07 2017 -0700 >> >> [GR-3393] Separate compressed oops from HotSpot as much as possible. >> >> commit eb2ef20805d6c24ff4b0dcc9af644a0365cdb926 >> Author: Vojin Jovanovic > >> Date: Mon Mar 27 17:24:40 2017 +0200 >> >> [cleanup] separate compressed oops from HotSpot as much as possible >> >> commit a872965c61c942ce33fd295a2280dcb54a3b38f4 >> Merge: 448e5d8 2722294 >> Author: Josef Eisl > >> Date: Mon Apr 10 03:14:51 2017 -0700 >> >> [GR-3581] Set machine node for parallel benchmarks. >> >> commit 27222942948eb21a3be34a3bec1c7aa03d11aed3 >> Author: Josef Eisl > >> Date: Mon Apr 10 10:45:16 2017 +0200 >> >> [ci] add MACHINE_NODE to parallel benchmarks >> >> commit 448e5d899e46c37e3800c92ffa9fdb69f5c5307c >> Merge: 7cc4f5d 24dba6b >> Author: Josef Eisl > >> Date: Mon Apr 10 01:24:11 2017 -0700 >> >> [GR-3525] Refine LIR dumping. >> >> commit 24dba6b3d9fe7472cb8cd50d00e3b95c0e9118f3 >> Author: Josef Eisl > >> Date: Fri Apr 7 17:48:49 2017 +0200 >> >> [fix] consolidate stack slot allocation dumping >> >> commit d2eacbdc80797f3032ee7a8de383e957b68aef9c >> Author: Josef Eisl > >> Date: Fri Apr 7 17:41:33 2017 +0200 >> >> [fix] consolidate linear scan dumping >> >> commit cbe02790cad450e1fb2af010fc3e56bb87ddd99e >> Author: Josef Eisl > >> Date: Fri Apr 7 16:38:57 2017 +0200 >> >> [fix] consolidate TraceRA dumping >> >> commit 55490c13f6274258b4ca339e30775097e8a97c1c >> Author: Josef Eisl > >> Date: Fri Apr 7 16:13:18 2017 +0200 >> >> [fix] Remove useless scopes and dumps from emitLIR >> >> commit 3f8355da125f50efb0180fdf9c019ae70234db14 >> Author: Josef Eisl > >> Date: Fri Apr 7 15:25:24 2017 +0200 >> >> [feature] Dump LIR stages in GraalCompiler >> >> commit 9c56f54ed009c9d93e0cb3f967f00c03c82028f2 >> Author: Josef Eisl > >> Date: Fri Apr 7 15:24:49 2017 +0200 >> >> [doc] document LIR dumping levels >> >> commit 7cc4f5dcea60bf0dabca37ef28eb97c378e494db >> Merge: 9edeefc c6fe486 >> Author: Aleksandar Prokopec > >> Date: Fri Apr 7 12:35:10 2017 -0700 >> >> [GR-3551] Add early canonicalization to IntegerEqualsNode and ObjectEqualsNode. >> >> commit c6fe4861464787def1c5eb66842b3ad843285a55 >> Merge: 8948675 9edeefc >> Author: Aleksandar Prokopec > >> Date: Fri Apr 7 19:24:18 2017 +0200 >> >> Merge branch 'master' into topic/GR-3551 >> >> commit 9edeefc2b6635d97c571c41a3708a2d90ae1ab3a >> Merge: 8a0a87e c152e63 >> Author: Josef Eisl > >> Date: Fri Apr 7 09:27:55 2017 -0700 >> >> [GR-3206] Do not execute scala-dacapo actors in parallel. >> >> commit 8a0a87eb63cbbc94c8cead115921f96a69d6869b >> Merge: 633e409 5282a7c >> Author: Roland Schatz > >> Date: Fri Apr 7 06:00:40 2017 -0700 >> >> [GR-3583] Update truffle import. >> >> commit 5282a7c3ffa0cbd0505a3825c718fee32ac1a202 >> Author: Roland Schatz > >> Date: Fri Apr 7 13:32:00 2017 +0200 >> >> Update truffle import. >> >> commit 633e40969f800a2231e5f7e7747f8eb812ebeb6e >> Merge: d8d8c22 2bac7bc >> Author: Christian Haeubl > >> Date: Fri Apr 7 02:08:18 2017 -0700 >> >> [GR-3435] Cache JVMCI call results during graph decoding. >> >> commit 2bac7bcfcac159d4e7c5b63ab64a83b48b91300b >> Author: Christian Haeubl > >> Date: Thu Mar 30 17:10:55 2017 +0200 >> >> Cache methods while doing graph decoding. >> >> commit 10968ad0ed8432049ee937170df8fbf075807427 >> Author: Christian Haeubl > >> Date: Thu Mar 30 14:32:15 2017 +0200 >> >> Cache annotations while doing graph decoding. >> >> commit d8d8c22904a4cee00988356183e16aaac6cf4e01 >> Merge: 0ea748e 5a50222 >> Author: Josef Eisl > >> Date: Thu Apr 6 09:39:21 2017 -0700 >> >> [GR-3515] Explicitly specify phases for compile time benchmarks. >> >> commit 89486753b1c8ba3dd85e259eef60556c84b43873 >> Merge: cca4aa3 65e6110 >> Author: Aleksandar Prokopec > >> Date: Thu Apr 6 17:16:00 2017 +0200 >> >> Merge branch 'master' into topic/GR-3551 >> >> commit 0ea748e92d0ef075da80234cb6e8f2181c55ac88 >> Merge: 65e6110 c60b383 >> Author: Roland Schatz > >> Date: Thu Apr 6 08:06:18 2017 -0700 >> >> [GR-3169] Graal produces wrong code for HeapByteBuffer on JDK9. >> >> commit cca4aa3eb4377d132cd314a57ff03b8cd7c21d61 >> Merge: b7cb98d ccd2af9 >> Author: Aleksandar Prokopec > >> Date: Thu Apr 6 15:16:19 2017 +0200 >> >> Merge branch 'master' into topic/GR-3551 >> >> commit c152e63aaa3b0d00d714f33dfbf1c01a14e72acc >> Author: Josef Eisl > >> Date: Thu Apr 6 16:37:51 2017 +0200 >> >> [ci] do not execute scala-dacapo actors in parallel >> >> commit 65e61109f0edc70864767b200ae33a660c6e8dcb >> Merge: 429d5da 57189f6 >> Author: Doug Simon > >> Date: Thu Apr 6 06:58:52 2017 -0700 >> >> [GR-3557] Fix regression in reading options from a file. >> >> commit c60b3830dc4765f2fd7f4d3f2dd85380bc6861e1 >> Author: Roland Schatz > >> Date: Thu Apr 6 15:36:10 2017 +0200 >> >> Fix escape analysis of byte array in HeapByteBuffer on JDK 9. >> >> commit 429d5da9377ac9f0951e472a93f68ad7d2fd40c8 >> Merge: ccd2af9 926fe31 >> Author: Gilles Duboscq > >> Date: Thu Apr 6 06:11:27 2017 -0700 >> >> [GR-3522] Canonicalize `NormalizeCompare < 1`. >> >> commit b7cb98d8b43d92ce1a7591e05fc7e5e0c6e453ec >> Author: Aleksandar Prokopec > >> Date: Thu Apr 6 15:00:37 2017 +0200 >> >> Rewire node creation for CompareNode subclasses and add static creation methods that invoke canonicalization. >> >> commit ccd2af9473a022c66eb399d34db22986a4a1b00e >> Merge: 01222aa 7f3278c >> Author: David Leopoldseder > >> Date: Thu Apr 6 05:17:49 2017 -0700 >> >> [GR-3568] NodeCostDumpUtil: swallow errors during class loading of nodes. >> >> commit 57189f612c106a041ecc4a79c82360c43ca581eb >> Author: Doug Simon > >> Date: Wed Apr 5 22:18:24 2017 +0200 >> >> fixed regression of handling options in a file >> >> commit 7f3278c8530a10d64c9d2e9d5c7c1525847655eb >> Author: David Leopoldseder > >> Date: Thu Apr 6 12:48:59 2017 +0200 >> >> [fix] NodeCostDumpUtil: swallow errors during class loading of nodes. >> >> commit 926fe31632e616776659c289f9376781647b98a1 >> Author: Gilles Duboscq > >> Date: Thu Apr 6 13:10:00 2017 +0200 >> >> Canonicalize `NormalizeCompare == c` >> >> commit 3a72610a51ba874a81c5b7dcd4a5b4dc13aece3b >> Author: Gilles Duboscq > >> Date: Tue Apr 4 19:38:10 2017 +0200 >> >> [GR-3522] Canonicalize `NormalizeCompare < 1` >> >> commit 01222aa50cd049253da87b18d9b86aa1fa8958f6 >> Merge: 8145122 7c59459 >> Author: Roland Schatz > >> Date: Thu Apr 6 03:17:24 2017 -0700 >> >> [GR-2925] Graal support for Truffle TestTVMCI. >> >> commit 5a502228765bcf2a8f5243708a8c6de0fdad3f15 >> Author: Josef Eisl > >> Date: Wed Apr 5 16:49:57 2017 +0200 >> >> [ci] restrict TimingBenchmarkMixin timers >> >> commit bbcd46991b0b776eb69df17e2130ad9c5e095cab >> Author: Josef Eisl > >> Date: Tue Apr 4 13:34:26 2017 +0200 >> >> [ci] use -Dgraaldebug.timer.XXX instead of -Dgraal.Time= for TimingBenchmarkMixin >> >> commit 4974eb04f4ee81dc48e68eacc505b8e7524c91eb >> Author: Josef Eisl > >> Date: Tue Apr 4 13:23:30 2017 +0200 >> >> [ci] outsource timerArgs in TimingBenchmarkMixin >> >> commit 81451226de18cbe2ccb1f2f23c2110a5cf874169 >> Merge: 2fc6719 42650bb >> Author: David Leopoldseder > >> Date: Thu Apr 6 01:20:45 2017 -0700 >> >> [GR-2552] NodeCost Model Improvements. >> >> commit 2fc6719fec619137e9e82d74be3c802341761790 >> Merge: 7f32177 b1f5952 >> Author: Josef Eisl > >> Date: Thu Apr 6 00:46:25 2017 -0700 >> >> [GR-3514] Register allocation sub-phases do not need to be proper LIRPhases. >> >> commit 2d18d0a330c3123f9e62851580a2e18aed231697 >> Author: Tom Rodriguez > >> Date: Wed Apr 5 23:56:50 2017 -0700 >> >> Handle placeholder states specially in PEA >> >> commit 42650bbebbb8d89c66d5517cb761f9e92c1f68cf >> Author: David Leopoldseder > >> Date: Tue Feb 21 15:58:33 2017 +0100 >> >> [fix] NodeCost: Ensure all nodes specify default costs. >> >> commit caf972182c4bd958f658185520e32e88843b200d >> Author: David Leopoldseder > >> Date: Mon Feb 20 09:46:56 2017 +0100 >> >> [feature] NodeCosts: Verify node cost model integrity in CheckGraalInvariants. >> >> commit 7cd39f545c0db26610dc12eb37364b3d3265ec99 >> Author: David Leopoldseder > >> Date: Mon Jan 30 11:05:11 2017 +0100 >> >> [fix] NodeCosts: Remove provider, move dynamic logic into nodes and fix scale. >> >> commit fde0d24a2dddaf45e46cf6dc1dcade625261c5e3 >> Author: David Leopoldseder > >> Date: Mon Jan 30 15:46:45 2017 +0100 >> >> [feature] NodeCosts: Add option to dump node cost related information to IGV. >> >> commit e72bbb87cb4ec9b08f1ee9de9546a2166a5db54d >> Author: David Leopoldseder > >> Date: Mon Jan 30 15:08:01 2017 +0100 >> >> [feature] NodeCost: Add dump util to dump costs of all node classes >> >> commit 7f32177fad91fedabefea6e9919aa5f51657481b >> Merge: 2eacdb3 ba5773e >> Author: Doug Simon > >> Date: Wed Apr 5 13:32:29 2017 -0700 >> >> [GR-3528] Convert some assertions in Node to guarantees. >> >> commit 63f10a5f38680435c750232702d183f05ad7e67f >> Merge: cce0b88 2eacdb3 >> Author: Aleksandar Prokopec > >> Date: Wed Apr 5 21:47:11 2017 +0200 >> >> Merge branch 'master' into topic/GR-3551 >> >> commit 2eacdb37f19de982e14d1bb6ea224d2c5ad0c0cc >> Merge: ee4cbef ba57d4d >> Author: Doug Simon > >> Date: Wed Apr 5 11:38:14 2017 -0700 >> >> [GR-3521] GraphBuilder: Change semantic of append to be recursive & remove recursiveAppend. >> >> commit ba57d4d7f716e5698e040196f9eeb03e2b4d42c5 >> Merge: 48d9d36 ee4cbef >> Author: Doug Simon > >> Date: Wed Apr 5 19:45:58 2017 +0200 >> >> Merge branch 'master' into topic/GR-3521 >> >> commit cce0b8820624ff627b999a743ff9274e1ee5f9af >> Author: Aleksandar Prokopec > >> Date: Wed Apr 5 17:31:13 2017 +0200 >> >> Make LowerOp extends CompareOp from CompareNode. >> >> commit 41f62af348083b11684927a5222f92abead5bfec >> Author: Aleksandar Prokopec > >> Date: Wed Apr 5 17:13:44 2017 +0200 >> >> Introduce CompareOp to CompareNode. >> >> commit ba5773e0575c5d18974b8bc0470c0fc306161075 >> Author: Doug Simon > >> Date: Tue Apr 4 21:21:32 2017 +0200 >> >> deprecated varargs version of GraalError.guarantee and replaced with fixed arg versions >> >> commit bc448373357aa8825a2cca6be86d0573a8442f17 >> Author: Doug Simon > >> Date: Tue Apr 4 21:20:41 2017 +0200 >> >> converted some assertions in Node to be guarantees >> >> commit 48d9d363d0e78dad51d1b5a6c87ddbfe6df4cece >> Author: David Leopoldseder > >> Date: Wed Apr 5 10:07:43 2017 +0200 >> >> [fix] GraphBuilder: Change semantic of append to be recursive & remove recursiveAppend >> >> commit ee4cbef108f34b17b55ffab2100a59b9b3529881 >> Merge: 898a31a ce55244 >> Author: Aleksandar Prokopec > >> Date: Wed Apr 5 02:55:54 2017 -0700 >> >> [GR-3208] Apply node plugins during graph decoding. >> >> commit ce55244ca5f6304c3c0a83233976f3fa7af852f4 >> Merge: 3e99694 898a31a >> Author: Aleksandar Prokopec > >> Date: Wed Apr 5 11:08:41 2017 +0200 >> >> Merge branch 'master' into topic/GR-3208 >> >> commit b1f595227b39ea9017a62129780fd8eddd8ffb64 >> Author: Josef Eisl > >> Date: Tue Apr 4 15:44:19 2017 +0200 >> >> [fix] LSRA subphases do not need to be AllocationPhases >> >> commit 4898e53ab808bf5a0f92da49705743d6da55fd46 >> Author: Josef Eisl > >> Date: Tue Apr 4 15:54:36 2017 +0200 >> >> [fix] TraceRA: TraceLinearScanAllocationPhase is no TraceAllocationPhase >> >> commit 3e99694c859bc1e1243dd0cb2ffdeb52b3364a8a >> Author: Aleksandar Prokopec > >> Date: Mon Apr 3 11:10:37 2017 +0200 >> >> Move graph builder context allocation to relevant branches, and document the graph builder context subclass. >> >> commit f80747fbabf07d9b0b276e9f6db00629dcd2cd1e >> Merge: ac63293 2de905e >> Author: Aleksandar Prokopec > >> Date: Fri Mar 31 16:01:10 2017 +0200 >> >> Merge branch 'master' into topic/GR-3208 >> >> commit 7c5945907a5e4c5737dd2dcbd52e4af9eb44cce5 >> Author: Roland Schatz > >> Date: Fri Mar 31 12:09:05 2017 +0200 >> >> Graal support for Truffle TestTVMCI. >> >> commit ac63293ed26263d161b0b0ba4b9fcce767f54899 >> Merge: 61436b1 14702f0 >> Author: Aleksandar Prokopec > >> Date: Thu Mar 30 11:50:05 2017 +0200 >> >> Merge branch 'master' into topic/GR-3208 >> >> commit 61436b1743ea8d785e186fda82ce1d9e5f51334c >> Merge: 9a18509 acbd663 >> Author: Aleksandar Prokopec > >> Date: Thu Mar 30 11:49:10 2017 +0200 >> >> Merge branch 'master' into topic/GR-3208 >> >> commit 9a18509ff88b8cd184f0f53bb363460741fd0328 >> Author: Aleksandar Prokopec > >> Date: Fri Mar 24 12:11:41 2017 +0100 >> >> Ensure that node plugins passed to the graph decoder handle all relevant node types. >> >> commit cacbd1effa1f1466c8d8b4978bd1d78b8d8b6941 >> Author: Aleksandar Prokopec > >> Date: Fri Mar 24 10:46:03 2017 +0100 >> >> Add overridable hook for instantiating node plugins. >> >> commit a71e6a7326a6a97d129734e22410993951aff00f >> Author: Aleksandar Prokopec > >> Date: Thu Mar 23 15:26:01 2017 +0100 >> >> Add on-demand handling of load-indexed nodes. >> >> commit d9165694fb9c486c6d05aafddcace65e55a4bf8e >> Merge: e36255e f304652 >> Author: Aleksandar Prokopec > >> Date: Thu Mar 23 14:12:55 2017 +0100 >> >> Merge branch 'master' into topic/GR-3208-alternative >> >> commit e36255e119b994ddca01a54d5fc1c3976935eaf3 >> Author: Aleksandar Prokopec > >> Date: Fri Mar 17 11:29:34 2017 +0100 >> >> [refactor] Remove CompositeNodePlugin and use NodePlugin arrays instead. >> >> commit 859d2e0fe86cae9933fbc6ae71a7ccbad196baff >> Author: Aleksandar Prokopec > >> Date: Tue Mar 14 15:55:18 2017 +0100 >> >> [feature] Add support for all the node plugin cases to graph decoding. >> >> commit e45ae3f1fb381d505351e23ff1bfe5fa1faf97c6 >> Author: Aleksandar Prokopec > >> Date: Tue Mar 14 12:29:13 2017 +0100 >> >> [fix] Prevent node plugin graph changes when not necessary. >> >> commit f8589ed80ce1f759ae14cd7ee314b0f4d82e4cc4 >> Author: Aleksandar Prokopec > >> Date: Mon Mar 13 17:16:31 2017 +0100 >> >> [feature] Add node plugins to graph decoder, and implement the handleLoadIndexed case. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Apr 19 06:17:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Apr 2017 16:17:28 +1000 Subject: RFR(XL/M) : 8178788: wrap JCStress test suite as jtreg tests In-Reply-To: <33C90E84-6872-4DC4-B6F9-74055D943876@oracle.com> References: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> <5a1da3e4-622b-66a4-1228-4a7e3ebbee91@oracle.com> <33C90E84-6872-4DC4-B6F9-74055D943876@oracle.com> Message-ID: <28eafe0f-c951-7a24-2fa0-7e994db7beec@oracle.com> Hi Igor, Thanks for the jtreg info! You missed a couple of things in the README: 27 All the tests are run thought test driver class -- JcstressRunner, which s/thought/through the/ And I just noticed an additional typo: 29 spawns a new JVM to run one jsctress test jsctress -> jcstress Thanks, David ----- On 19/04/2017 12:51 PM, Igor Ignatyev wrote: > Hi David, > > thank you for your comments, I've tried to address them all, please look at the incremental webrev: http://cr.openjdk.java.net/~iignatyev/8178788/webrev.00-01/index.html > > regarding multiple test declarations, jtreg supports that, but in the current version it's not fully/officially supported and hence it's not documented. Jon has fixed a few jtreg bugs[1-3] related to this and AFAIK is working towards full support, so I hope it will be supported and documented in the next promoted build of jtreg. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7900144 : Implement multiple tests in one file in jtreg > [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7901914 : Failure to find multiple @test in a single file > [3] https://bugs.openjdk.java.net/browse/CODETOOLS-7901940 : support multiple @test in one test file > > Thanks, > -- Igor > >> On Apr 18, 2017, at 6:28 PM, David Holmes wrote: >> >> Hi Igor, >> >> On 19/04/2017 8:12 AM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >>>> 69903 lines changed: 69903 ins; 0 del; 0 mod; >>> (69524 lines are generated) >>> >>> Hi all, >>> >>> could you please review this patch which adds a jtreg test wrapper for jcstress test suite and jtreg tests which run jsctress tests thru this wrapper? >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8178788 >>> testing: applications/jcstress >> >> This looks really good! Only concern is that according to the docs jtreg doesn't seem to support multiple test declarations in a single file ?? Maybe the docs are out of date? > >> >> http://openjdk.java.net/jtreg/tag-spec.html >> >> A few grammatical nits in the README: >> >> 23 The tests located under this directory run tests from Java Concurrency Stress >> >> from Java -> from the Java >> >> 24 [1] aka jcstress test suite. This suite aims to verify the correctness of >> >> Suggest: >> >> test suite [1] (a.k.a. jcstress). This suite ... >> >> 25 concurrency support in JDK. >> >> in JDK -> in the JDK >> >> 27 All the tests are run thought test driver class -- JcstressRunner, which >> >> s/thought/through the/ >> >> 29 spawns a new JVM to run one jsctress test and checks that it is finished >> >> is finished -> finishes >> >> 33 changed, one should make corresponding changes in the artifact description in >> >> in the -> to the >> >> 36 */Test.java files should never be modified directly, because they are >> >> Insert "The" at start. >> >> --- >> >> General Java style nits re long ling wrapping. You seem to be using a consistent "indent by 8" style when wrapping long lines. The "usual" style guidelines suggest a more structured indentation style, for example: >> >> - when wrapping the arguments to a call align after the opening ( of the call ie: >> >> throw new Error("TESTBUG: Can not resolve artifacts for " >> + JcstressRunner.class.getName(), e); >> >> - when you have chained method calls, try to align at the dots ie: >> >> return artifacts.get("org.openjdk.jcstress.jcstress-tests-all-0.3") >> .toAbsolutePath(); >> >> and >> >> ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(getCmd(args)) >> .redirectErrorStream(true) >> .redirectOutput(out.toFile()); >> >> --- >> >> test/applications/jcstress/TestGenerator.java >> >> 44 * This is a test generator, should be run only when jsctress is changed >> >> Typo: jsctress -> jcstress >> >> 51 * Use jcstress test suite to generates >> >> generates -> generate >> >> Strictly speaking the copyright years should only be updated when there is a substantive change to the text of the file, so updating whenever the files are regenerated is not really correct. This may need to be manually adjusted when commiting updated files ... though if there is no change other than to copyright year then the changes can simply be ignored (hg revert) and no update pushed. >> >> Thanks, >> David >> ------ >> >>> Thanks, >>> -- Igor >>> > From doug.simon at oracle.com Wed Apr 19 07:16:08 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 09:16:08 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal Message-ID: (adding hotspot-compiler-dev) Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. The primary requirement for this is to remove all usage of JDK internals from Graal. While this most involves changes in Graal, there remain a few capabilities that must be exposed via JVMCI. Namely: 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize can use system properties that are guaranteed not to have been modified by application code (Graal initialization is lazy and may occur after application code has been run). 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal optimized implementation of the Truffle runtime. These capabilities have been added to jdk.vm.ci.services.Services. A comment has also been added to this class to denote the current methods to be removed in a subsequent bug to update the JDK copy of Graal with the upstream version which no longer uses the methods. The methods destined for removal are: exportJVMCITo(Class requestor) load(Class service) loadSingle(Class service, boolean required) The first one is no longer needed as JVMCI exports itself to Graal service providers it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API is only useful for JVMCI-8 where a hidden JVMCI class loader is used. These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra minor changes were required: 1. In JDK-8177673, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException on all error paths except one which throws AssertionError. The latter was a mistake and has been fixed to also throw IllegalArgumentException. 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and remove use of JDK internal API from the jdk.aot module. The qualified exports to jdk.vm.internal.compiler and jdk.aot can then be removed. -Doug https://bugs.openjdk.java.net/browse/JDK-8177845 http://cr.openjdk.java.net/~dnsimon/8177845/ [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess From doug.simon at oracle.com Wed Apr 19 07:18:03 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 09:18:03 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> Message-ID: (adding hotspot-compiler-dev) > On 19 Apr 2017, at 02:02, Mandy Chung wrote: > > >> On Apr 18, 2017, at 3:13 PM, Doug Simon wrote: >> >> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >> : >> http://cr.openjdk.java.net/~dnsimon/8177845/ > > Thanks for making this change. This would simplify the way to replace JDK?s graal with the lab graal. A couple of comments: > > jdk/internal/misc/VM.java > > 161 * Note that the saved system properties do not include > 162 * the ones set by sun.misc.Version.init(). > > sun.misc.Version is no longer present in JDK 9. Renamed to java.lang.VersionProps Sorry, the webrev was out of date. I've updated it and also fixed the comment for VM::getSavedProperty. > jdk/vm/ci/services/Services.java > 67 Class.forName("jdk.vm.ci.runtime.JVMCI?); > > JVMCI class is local in jdk.internal.vm.ci module. An alternative may be > to provide a static initialize method rather than Class::forName. JVMCI is broken into fine grained "projects" and the jdk.vm.ci.runtime[1] project depends on the jdk.vm.ci.services project[2] so I cannot make a direct reference without introducing a circular dependency. I don't expect the reflection cost to be significant in practice. > jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java > 211 for (HotSpotJVMCIBackendFactory factory : ServiceLoader.load(HotSpotJVMCIBackendFactory.class)) { > > This uses the thread context class loader to load providers. Services::load uses > the system class loader to load providers. I suspect you want this to use the > system class loader here too. > > jdk/vm/ci/services/JVMCIServiceLocator.java > 78 for (JVMCIServiceLocator access : ServiceLoader.load(JVMCIServiceLocator.class)) { > > Same comment as above. I think you want to use system class loader to load providers. Yes, I think you're right. I've updated the webrev with that change. Thanks for the review. -Doug [1] http://hg.openjdk.java.net/jdk9/dev/hotspot/file/560d7aa083a2/.mx.jvmci/suite.py#l94 [2] http://hg.openjdk.java.net/jdk9/dev/hotspot/file/560d7aa083a2/.mx.jvmci/suite.py#l45 From doug.simon at oracle.com Wed Apr 19 14:16:44 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 16:16:44 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <56bb9632-e8d7-60be-0832-fa86c20a36ef@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <56bb9632-e8d7-60be-0832-fa86c20a36ef@oracle.com> Message-ID: <28A2A0B1-3898-43DB-BFA1-011B64D2CE69@oracle.com> > On 19 Apr 2017, at 16:04, Alan Bateman wrote: > > On 18/04/2017 23:13, Doug Simon wrote: > >> : >> >> https://bugs.openjdk.java.net/browse/JDK-8177845 >> http://cr.openjdk.java.net/~dnsimon/8177845/ >> > I'm happy to see jdk.internal.vm.compiler changing to be an upgradable module and the patching foo going away. Yes, I'm delighted to see the command line required for using upstream Graal shrinking! > If I read the changes correctly then I can extend JVMCIServiceLocator and the construction of my sub-class will open up all packages in jdk.internal.vm.ci to me. It is there any to tie this to -XX:+EnableJVMCI? We could but I'm not sure what it would buy you. The service lookup only originates from the JVMCI runtime and the initialization of JVMCI already checks EnableJVMCI[1] -Doug [1] http://hg.openjdk.java.net/jdk9/dev/hotspot/file/4368832d1991/src/share/vm/jvmci/jvmciRuntime.cpp#l634 From aph at redhat.com Wed Apr 19 15:45:02 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Apr 2017 16:45:02 +0100 Subject: RFR: 8178968: AArch64: Remove non-standard code cache size Message-ID: <4aba4e9d-38a9-b0a2-0bfd-374f39b200b0@redhat.com> The AArch64 code cache size defaults to 128M. This dates from a time when we hadn't solved the problem of generating efficient far calls, and it now should be removed so that port defaults to the same cache size as other architectures. For JDK 10. http://cr.openjdk.java.net/~aph/8178968/ Andrew. From rwestrel at redhat.com Wed Apr 19 15:47:05 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 19 Apr 2017 17:47:05 +0200 Subject: RFR: 8178968: AArch64: Remove non-standard code cache size In-Reply-To: <4aba4e9d-38a9-b0a2-0bfd-374f39b200b0@redhat.com> References: <4aba4e9d-38a9-b0a2-0bfd-374f39b200b0@redhat.com> Message-ID: > http://cr.openjdk.java.net/~aph/8178968/ Looks good to me. Roland. From adinn at redhat.com Wed Apr 19 16:13:00 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 19 Apr 2017 17:13:00 +0100 Subject: RFR: 8178968: AArch64: Remove non-standard code cache size In-Reply-To: <4aba4e9d-38a9-b0a2-0bfd-374f39b200b0@redhat.com> References: <4aba4e9d-38a9-b0a2-0bfd-374f39b200b0@redhat.com> Message-ID: <5a8b84e9-a87a-0e0d-1d13-ae484086bb18@redhat.com> On 19/04/17 16:45, Andrew Haley wrote: > The AArch64 code cache size defaults to 128M. This dates from a time > when we hadn't solved the problem of generating efficient far calls, > and it now should be removed so that port defaults to the same cache > size as other architectures. > > For JDK 10. > > http://cr.openjdk.java.net/~aph/8178968/ Sounds good to me (reviewed by a non-reviewer). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.kozlov at oracle.com Wed Apr 19 16:45:51 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Apr 2017 09:45:51 -0700 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> Message-ID: <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> Hi, Roland Did you run performance testing? It could affect loop optimizations and cause performance regression loops have unsafe access. On other hand unsafe accesses have membars so it may be not big deal. At least run Andrew's ByteBuffers ;) Changes looks fine to me. Thanks, Vladimir On 3/28/17 9:10 AM, Roland Westrelin wrote: > > New webrev: > > http://cr.openjdk.java.net/~roland/8176506/webrev.02/ > >> src/share/vm/opto/library_call.cpp: >> } else { >> + // We know it's an on heap access so base can't be null >> + base = must_be_not_null(base, true); >> return basic_plus_adr(base, offset); >> } >> >> Why do you unconditionally apply GK::must_be_not_null() even when base >> is provably non-null? > > It would be optimized out. Anyway, I followed your suggestion and added > a check. > >> Another thing I noticed is that the following check isn't strong enough: >> >> 2072 LibraryCallKit::classify_unsafe_addr(Node* &base, Node* &offset) { >> >> 2085 } else if (base_type->isa_oopptr()) { >> 2086 // Base is never null => always a heap address. >> 2087 if (base_type->ptr() == TypePtr::NotNull) { >> >> It doesn't cover TypePtr::Constant case. Fixed it with: >> - if (base_type->ptr() == TypePtr::NotNull) { >> + if (!TypePtr::NULL_PTR->higher_equal(base_type)) { > > Right. I had noticed that change in your webrev but wasn't sure why it > was necessary. Thanks for the explanation. > >> Otherwise, looks good for 10. > > Thanks! > > Roland. > From igor.veresov at oracle.com Wed Apr 19 16:48:12 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 19 Apr 2017 09:48:12 -0700 Subject: RFR(XS) 8178047: Aliasing problem with raw memory accesses In-Reply-To: <698356e6-5505-053f-b6db-8583e9c02ae9@oracle.com> References: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> <8ee16b46-0ecb-a23f-fc96-31771f4d9552@oracle.com> <698356e6-5505-053f-b6db-8583e9c02ae9@oracle.com> Message-ID: I?ve updated the webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.01 I did an RBT run and the results look good. igor > On Apr 14, 2017, at 11:21 AM, Vladimir Kozlov wrote: > > On 4/14/17 10:31 AM, Igor Veresov wrote: >> >>> On Apr 14, 2017, at 9:53 AM, Vladimir Kozlov wrote: >>> >>> Klass pointers should be also fine I think. >>> The problem is only Raw pointers which could point to the same memory but different offset. >>> May be use >>> >>> bool is_raw = adr->bottom_type()->isa_rawptr() != NULL; >>> ... >>> if (is_raw && st_base != base) { >> >> I guess in that case AnyPtr should be be also checked for, because it includes RawPtr, right? > > Yes. > >> >>> >>> Also what if pointer type is mixed: original is oop and mem node is raw? >>> May we should check that if when one of them is raw we should compare bases. >> >> Is it possible for that to happen? > > May be not. Usually we will have membars around unsafe memory access. But if we have AnyPtr, as you said, it could be mixed I think. I think it is better to check for such case even if it may not happen. > > Vladimir > >> >> igor >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/13/17 8:30 PM, Igor Veresov wrote: >>>> This seems like a long-standing bug. Analysis in MemNode::find_previous_store() tries to relax memory dependencies by proving that memory accesses don?t alias. The code is fine for oops: if [offset, offset+length) intervals don?t overlap it proves the accesses don?t alias because bases always point to the start of an object. For raw accesses that?s not true. Offset analysis doesn?t mean much without proving that bases are not the same. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.00 >>>> >>>> Thanks, >>>> igor >>>> >> From chenyt.cs.sjtu at gmail.com Wed Apr 19 16:56:30 2017 From: chenyt.cs.sjtu at gmail.com (Yuting Chen) Date: Wed, 19 Apr 2017 09:56:30 -0700 Subject: aot compiler halts when there exists an infinite loop in clinit() In-Reply-To: <39E0280D-96CB-4E6F-8038-B7DBC820E22D@oracle.com> References: <1d2886ef-1f65-0dc3-29a0-a1366b29218c@oracle.com> <39E0280D-96CB-4E6F-8038-B7DBC820E22D@oracle.com> Message-ID: Thank you, Igor. I can understand now:) I'd expect that some timeout messages will be provided if the compiler hangs (a quick patch?). I compiled some pieces of bytecode and waited for the whole night... Regards, Yuting On Tue, Apr 18, 2017 at 8:15 PM, Igor Veresov wrote: > We know :) > > https://bugs.openjdk.java.net/browse/JDK-8146201 > > > igor > > On Apr 18, 2017, at 7:09 PM, Yuting Chen wrote: > > Besides, if a class initializer writes into an external file (or make > some computations), the compiler will have side effects when compiling > the corresponding class, :). > > On Tue, Apr 18, 2017 at 5:17 PM, Yuting Chen > wrote: > > Thank you, Vladimir. Should it be better if the compiler can report a > timeout error for such a class initializer? > > On Tue, Apr 18, 2017 at 4:46 PM, Vladimir Kozlov > wrote: > > On 4/18/17 2:20 PM, Yuting Chen wrote: > > > Hi, are there any comments to this case? I found that the clinit > method will be compiled if it does not contain the infinite loop. Does > it mean that clinit will run before it is compiled. > > > > Yes, AOT compiler will run class initializer since it needs to access static > fields and other values. > > Vladimir > > > > Re-paste the bytecode: > > public class Vector1 > minor version: 0 > major version: 52 > flags: ACC_PUBLIC, ACC_SUPER > Constant pool: > #1 = Utf8 Vector1 > #2 = Class #1 // Vector1 > #3 = Utf8 java/lang/Object > #4 = Class #3 // java/lang/Object > #5 = Utf8 serialVersionUID > #6 = Utf8 J > #7 = Long -2767605614048989439l > #9 = Utf8 > #10 = Utf8 ()V > #11 = NameAndType #5:#6 // serialVersionUID:J > #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J > #13 = Utf8 main > #14 = Utf8 ([Ljava/lang/String;)V > #15 = Utf8 ConstantValue > #16 = Utf8 Code > #17 = Utf8 StackMapTable > { > public static {}; > descriptor: ()V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=2, locals=0, args_size=0 > 0: ldc2_w #7 // long > -2767605614048989439l > 3: putstatic #12 // Field serialVersionUID:J > 6: iconst_1 > 7: iconst_m1 > 8: iadd > 9: ifge 0 > 12: return > StackMapTable: number_of_entries = 1 > frame_type = 0 /* same */ > > public static void main(java.lang.String[]); > descriptor: ([Ljava/lang/String;)V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=0, locals=1, args_size=1 > 0: return > } > > On Tue, Apr 18, 2017 at 9:41 AM, Yuting Chen > wrote: > > > Hi, are there any comments to this case? I found that the clinit > method will be compiled if it does not contain the infinite loop. It's > weird. > > The bytecode is shown as follows: > > public class Vector1 > minor version: 0 > major version: 52 > flags: ACC_PUBLIC, ACC_SUPER > Constant pool: > #1 = Utf8 Vector1 > #2 = Class #1 // Vector1 > #3 = Utf8 java/lang/Object > #4 = Class #3 // java/lang/Object > #5 = Utf8 serialVersionUID > #6 = Utf8 J > #7 = Long -2767605614048989439l > #9 = Utf8 > #10 = Utf8 ()V > #11 = NameAndType #5:#6 // serialVersionUID:J > #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J > #13 = Utf8 main > #14 = Utf8 ([Ljava/lang/String;)V > #15 = Utf8 ConstantValue > #16 = Utf8 Code > #17 = Utf8 StackMapTable > { > public static {}; > descriptor: ()V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=2, locals=0, args_size=0 > 0: ldc2_w #7 // long > -2767605614048989439l > 3: putstatic #12 // Field > serialVersionUID:J > 6: iconst_1 > 7: iconst_m1 > 8: iadd > 9: ifge 0 > 12: return > StackMapTable: number_of_entries = 1 > frame_type = 0 /* same */ > > public static void main(java.lang.String[]); > descriptor: ([Ljava/lang/String;)V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=0, locals=1, args_size=1 > 0: return > } > > From vladimir.kozlov at oracle.com Wed Apr 19 16:59:45 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Apr 2017 09:59:45 -0700 Subject: RFR(XS) 8178047: Aliasing problem with raw memory accesses In-Reply-To: References: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> <8ee16b46-0ecb-a23f-fc96-31771f4d9552@oracle.com> <698356e6-5505-053f-b6db-8583e9c02ae9@oracle.com> Message-ID: <770c25cb-7ed7-53f2-41c6-78afff1ac9c3@oracle.com> Nice. Thanks, Vladimir On 4/19/17 9:48 AM, Igor Veresov wrote: > I?ve updated the webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.01 > I did an RBT run and the results look good. > > igor > > >> On Apr 14, 2017, at 11:21 AM, Vladimir Kozlov wrote: >> >> On 4/14/17 10:31 AM, Igor Veresov wrote: >>> >>>> On Apr 14, 2017, at 9:53 AM, Vladimir Kozlov wrote: >>>> >>>> Klass pointers should be also fine I think. >>>> The problem is only Raw pointers which could point to the same memory but different offset. >>>> May be use >>>> >>>> bool is_raw = adr->bottom_type()->isa_rawptr() != NULL; >>>> ... >>>> if (is_raw && st_base != base) { >>> >>> I guess in that case AnyPtr should be be also checked for, because it includes RawPtr, right? >> >> Yes. >> >>> >>>> >>>> Also what if pointer type is mixed: original is oop and mem node is raw? >>>> May we should check that if when one of them is raw we should compare bases. >>> >>> Is it possible for that to happen? >> >> May be not. Usually we will have membars around unsafe memory access. But if we have AnyPtr, as you said, it could be mixed I think. I think it is better to check for such case even if it may not happen. >> >> Vladimir >> >>> >>> igor >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/13/17 8:30 PM, Igor Veresov wrote: >>>>> This seems like a long-standing bug. Analysis in MemNode::find_previous_store() tries to relax memory dependencies by proving that memory accesses don?t alias. The code is fine for oops: if [offset, offset+length) intervals don?t overlap it proves the accesses don?t alias because bases always point to the start of an object. For raw accesses that?s not true. Offset analysis doesn?t mean much without proving that bases are not the same. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.00 >>>>> >>>>> Thanks, >>>>> igor >>>>> >>> > From vladimir.x.ivanov at oracle.com Wed Apr 19 17:21:53 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 19 Apr 2017 20:21:53 +0300 Subject: RFR(XS) 8178047: Aliasing problem with raw memory accesses In-Reply-To: References: <42C114F6-DEA1-4CC7-9B10-4BDA457E4847@oracle.com> <8ee16b46-0ecb-a23f-fc96-31771f4d9552@oracle.com> <698356e6-5505-053f-b6db-8583e9c02ae9@oracle.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 4/19/17 7:48 PM, Igor Veresov wrote: > I?ve updated the webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.01 > I did an RBT run and the results look good. > > igor > > >> On Apr 14, 2017, at 11:21 AM, Vladimir Kozlov wrote: >> >> On 4/14/17 10:31 AM, Igor Veresov wrote: >>> >>>> On Apr 14, 2017, at 9:53 AM, Vladimir Kozlov wrote: >>>> >>>> Klass pointers should be also fine I think. >>>> The problem is only Raw pointers which could point to the same memory but different offset. >>>> May be use >>>> >>>> bool is_raw = adr->bottom_type()->isa_rawptr() != NULL; >>>> ... >>>> if (is_raw && st_base != base) { >>> >>> I guess in that case AnyPtr should be be also checked for, because it includes RawPtr, right? >> >> Yes. >> >>> >>>> >>>> Also what if pointer type is mixed: original is oop and mem node is raw? >>>> May we should check that if when one of them is raw we should compare bases. >>> >>> Is it possible for that to happen? >> >> May be not. Usually we will have membars around unsafe memory access. But if we have AnyPtr, as you said, it could be mixed I think. I think it is better to check for such case even if it may not happen. >> >> Vladimir >> >>> >>> igor >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/13/17 8:30 PM, Igor Veresov wrote: >>>>> This seems like a long-standing bug. Analysis in MemNode::find_previous_store() tries to relax memory dependencies by proving that memory accesses don?t alias. The code is fine for oops: if [offset, offset+length) intervals don?t overlap it proves the accesses don?t alias because bases always point to the start of an object. For raw accesses that?s not true. Offset analysis doesn?t mean much without proving that bases are not the same. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8178047/webrev.00 >>>>> >>>>> Thanks, >>>>> igor >>>>> >>> > From george.triantafillou at oracle.com Wed Apr 19 17:54:08 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 19 Apr 2017 13:54:08 -0400 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: <8C096D6B-AFEB-44BD-ACDF-0709E04300A9@oracle.com> References: <8C096D6B-AFEB-44BD-ACDF-0709E04300A9@oracle.com> Message-ID: <6d45bbc8-8a2b-1cc4-461f-c7dd37e7d239@oracle.com> Hi Kim, Comments inline: On 4/15/2017 4:27 AM, Kim Barrett wrote: >> On Apr 7, 2017, at 10:47 AM, George Triantafillou wrote: >> >> (Adding compiler). >> Please review this fix to remove SPARC 32-bit support. Support for solaris-sparc has been dropped from the list of supported platforms. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 >> webrev: http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ >> >> Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. >> >> Thanks. >> >> -George > That's a lot of files and changes! I hope you'll be providing > incremental webrevs for updates. I've checked in the change for 8150388, but will address the issues you raised. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp > 1393 // the poll may need a register so just pick one that isn't the return register > > This comment appears to refer to the 32bit code that followed it and > was removed. I think the comment should be removed too. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp > 1490 Register yhi = opr2->as_register_hi(); > > After the removal of the 32bit code, I don't see any remaining > references to yhi. Not sure what that implies, other than there's > likely further work to do here. It's unclear to me what what should be done here. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp > 1559 } else > 1560 __ brx(acond, false, Assembler::pt, skip); // checks icc on 32bit and xcc on 64bit > > Please add braces to that else-clause. They were missing before > because the if/else was 64bit-only, and the close brace would have > also needed 64bit conditionalization. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp > 2574 Register cmp_value_hi = op->cmp_value()->as_register_hi(); > ... > 2576 Register new_value_hi = op->new_value()->as_register_hi(); > > After the removal of the 32bit code, I don't see any remaining > references to the xxx_hi variables. Not sure what that implies, other > than there's likely further work to do here. It's unclear to me what what should be done here. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp > 3047 void LIR_Assembler::volatile_move_op(LIR_Opr src, LIR_Opr dest, BasicType type, CodeEmitInfo* info) { > 3048 ShouldNotReachHere(); > 3049 > 3050 NEEDS_CLEANUP; > > It appears that in 64bit mode this function has no implementation, and > the following 50+ lines of code are presently 32bit-only. Likely > further work to do here. It's unclear to me what what should be done here. > > ------------------------------------------------------------------------------ > rc/cpu/sparc/vm/copy_sparc.hpp > 116 static void pd_conjoint_jlongs_atomic(jlong* from, jlong* to, size_t count) { > > --- TBD > Removed call to _Copy_conjoint_jlongs_atomic. Check if it's still > needed elsewhere or definition is removed. It's used elsewhere. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/globalDefinitions_sparc.hpp > 43 #elif defined(COMPILER1) > 44 // pure C1, 32-bit, small machine > 45 #define DEFAULT_CACHE_LINE_SIZE 16 > > Comment suggests this is a configuration we don't use with 64bit. It's unclear to me what what should be done here. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/globals_sparc.hpp > 59 // Stack slots are 2X larger in LP64 than in the 32 bit VM. > > Comment seems dead now. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp > > There are a lot of operations here that are for dispatching on 32/64. > Some of them may be worth keeping for documentation purposes, but some > might be better off being removed. That kind of cleanup should > probably wait for a later RFE though. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp > 323 inline intptr_t MacroAssembler::load_pc_address( Register reg, int bytes_to_skip ) { > 324 intptr_t thepc = (intptr_t)pc() + 2*BytesPerInstWord + bytes_to_skip; > > 325 Unimplemented(); > > Presumably never called in 64bit mode. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/sparc.ad > 314 // 64-bit build means 64-bit pointers means hi/lo pairs > > "64-bit build means" seems superfluous now. Really? Suggestions? > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/sparc.ad > 355 // 32-bit, longs in 1 register: cannot use I's and L's. Restrict to O's and G's. > > Comment seems superfluous now. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/sparc.ad > 1856 // Note that we if-def off of _LP64. > 1857 // The relevant question is how the int is callee-saved. In _LP64 > 1858 // the whole long is written but de-opt'ing will have to extract > 1859 // the relevant 32 bits, in not-_LP64 only the low 32 bits is written. > > The commentary here needs some updating; there is no not-_LP64 > anymore. Agreed. How should it read? > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/sparc.ad > 1947 // The intptr_t operand types, defined by textual substitution. > 1948 // (Cf. opto/type.hpp. This lets us avoid many, many other ifdefs.) > > These comments suggest there are further cleanup opportunities, > probably for a later RFE. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/stubGenerator_sparc.cpp > Removed block starting with: > 831 #if defined(ASSERT) && defined(_LP64) > > That looks like an incorrect removal. The checked in change looks like this: 779 void assert_clean_int(Register Rint, Register Rtmp) { 780 #if defined(ASSERT) 781 __ signx(Rint, Rtmp); 782 __ cmp(Rint, Rtmp); 783 __ breakpoint_trap(Assembler::notEqual, Assembler::xcc); 784 #endif 785 } > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/stubGenerator_sparc.cpp > 1232 if (!aligned) > > 1233 { > > Please move the { to line 1232. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/stubGenerator_sparc.cpp > 1334 } else > > 1335 { > > Please move the { to line 1334. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/stubGenerator_sparc.cpp > 1445 if (!aligned) > > 1446 { > > Please move the { to line 1445. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/stubGenerator_sparc.cpp > 1562 if (!aligned) { > > 1563 // align to 8 bytes, we know we are 4 byte aligned to start > 1564 __ andcc(to, 7, G0); > 1565 __ br(Assembler::zero, false, Assembler::pt, L_fill_32_bytes); > 1566 __ delayed()->nop(); > 1567 __ stw(value, to, 0); > 1568 __ inc(to, 4); > 1569 __ dec(count, 1 << shift); > 1570 __ BIND(L_fill_32_bytes); > > 1571 } > > Please fix the indentation. Agreed. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/stubGenerator_sparc.cpp > 1777 } else > > 1778 { > > Please move the { to line 1777. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/stubGenerator_sparc.cpp > 1887 if (!aligned) > > 1888 { > > Please move the { to line 1887. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/stubGenerator_sparc.cpp > 3085 } else > > 3086 { > > Please move the { to line 3085. Agreed. > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/stubGenerator_sparc.cpp > 5103 // Write the high part of the address > 5104 // [RGV] Check if there is a dependency on the size of this prolog > > Pre-existing: These comments seem mis-indented. I wonder who RGV is, > and how old this comment is. Agreed. I'll fix the indentation. It's a very old comment. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp > 60 // The sethi() instruction generates lots more instructions when shell > 61 // stack limit is unlimited, so that's why this is much bigger. > > "why this is much bigger" ? than what? Oh, the 32bit value. Some > revision of comment is called for here. It's from Changeset: 9934 (fd5d53ecf040) 8146410: Interpreter functions are declared and defined in the wrong files. > > ------------------------------------------------------------------------------ > src/cpu/sparc/vm/vm_version_sparc.cpp > 73 // 32-bit oops don't make sense for the 64-bit VM on sparc > 74 // since the 32-bit VM has the same registers and smaller objects. > > This comment probably needs updating. It's from Changeset: 642 (660978a2a31a) 6791178: Specialize for zero as the compressed oop vm heap base > > ------------------------------------------------------------------------------ > src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.hpp > 166 #if defined(COMPILER2) || defined(_LP64) > and > 228 #endif // _LP64 || COMPILER2 > > I think the _LP64 parts of these can be removed. The checked in change addresses this. > > ------------------------------------------------------------------------------ > src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.hpp > 57 #ifdef _GNU_SOURCE > > For a future clenaup, Solaris Studio now supports the gcc-style inline > assembler being protected by this #ifdef. We could probably eliminate > the alternative definitions, though if we're not already using the > inline versions they will need to be carefully examined first. Agreed. > > ------------------------------------------------------------------------------ > src/os_cpu/solaris_sparc/vm/prefetch_solaris_sparc.inline.hpp > 30 #if defined(COMPILER2) || defined(_LP64) > and > 58 #endif // defined(COMPILER2) || defined(_LP64) > > I think the _LP64 parts of these can be removed. The checked in change addresses this. > > ------------------------------------------------------------------------------ > From cthalinger at twitter.com Wed Apr 19 18:11:30 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 19 Apr 2017 08:11:30 -1000 Subject: RFR(XXL) 8178864: Update Graal In-Reply-To: References: <008050D5-DEC7-4117-8EEF-B77BF3E22B24@oracle.com> <2D2B20C1-65C5-4DBE-BC74-0D280D686D49@twitter.com> Message-ID: > On Apr 18, 2017, at 5:26 PM, Igor Veresov wrote: > > It goes something like this: > > update-graal() { > cd ~/work/jdk10-hs/hotspot/src/jdk.internal.vm.compiler/share/classes/ > rm -rf org.graalvm.* > cp -R ~/work/veresov-graal/graal-core/graal/org.graalvm.* . > rm -rf org.graalvm.compiler.truffle* > cd ~/work/jdk10-hs/hotspot > hg add `hg status -un` > hg rm `hg status -dn` > } > > Note, that I?m not doing merges. It?s just a plain copy of Graal from GitHub. > And then you?d have to update suites.py manually.. Sure. Thanks! > > igor > > >> On Apr 18, 2017, at 4:03 PM, Christian Thalinger > wrote: >> >> Igor, do you have a script you are using to update Graal in OpenJDK? If yes, could you share it? >> >>> On Apr 17, 2017, at 11:08 AM, Igor Veresov > wrote: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8178864 >>> Webrev: http://cr.openjdk.java.net/~iveresov/8178864/webrev.00/ >>> >>> Thanks, >>> igor >>> >>> p.s. >>> >>> Changes: >>> >>> commit 415a4ef635029f49ab2c4fef0e6f2012be916db7 >>> Merge: 768caab 294900b >>> Author: Tom Rodriguez > >>> Date: Mon Apr 17 10:36:23 2017 -0700 >>> >>> [GR-3667] Fix probability for intrinsic guard. >>> >>> commit 294900b270c2f866a9a33a3a027a63ba85562792 >>> Author: Tom Rodriguez > >>> Date: Fri Apr 14 10:00:47 2017 -0700 >>> >>> Fix probability for intrinsic guard >>> >>> commit 768caabc4aad572e7fa8a08e708b81eaf9c8e119 >>> Merge: c3ab66a 78f5562 >>> Author: Doug Simon > >>> Date: Mon Apr 17 09:06:14 2017 -0700 >>> >>> [GR-3673] Remove forced dumps. >>> >>> commit c3ab66a7fb72311ed479d0f47b87cf867453915d >>> Merge: 4d1095d 9a66f88 >>> Author: Tom Rodriguez > >>> Date: Mon Apr 17 09:01:21 2017 -0700 >>> >>> [GR-3657] Fix possible infinite loop in nodesInLoopBranch. >>> >>> commit 9a66f887d1f6c8308f15c8c8df7c40578923369c >>> Author: Tom Rodriguez > >>> Date: Thu Apr 13 21:20:49 2017 -0700 >>> >>> Fix possible infinite loop in nodesInLoopBranch >>> >>> commit 78f55621c9301ae9c6e6e5b8d0d3fab7c2e4de6c >>> Author: Doug Simon > >>> Date: Mon Apr 17 10:41:29 2017 +0200 >>> >>> removed uses of Debug.forceDump that pollute test logs >>> >>> commit 4d1095d1ea9fc4c317c7f584a02344e64df7a5f3 >>> Merge: 02a2a3d cf9a623 >>> Author: Christian Wimmer > >>> Date: Fri Apr 14 10:25:21 2017 -0700 >>> >>> [GR-3666] Remove redundant final modifier as reported by newest Checkstyle version. >>> >>> commit cf9a6238a826e77c94ab0602c2214b0f0afd1aa6 >>> Author: Christian Wimmer > >>> Date: Fri Apr 14 09:02:55 2017 -0700 >>> >>> Remove redundant final modifier as reported by newest Checkstyle version >>> >>> commit 02a2a3d9ba60c5db87c83c701a500e41d79583b2 >>> Merge: e8acaea 92a1821 >>> Author: Josef Eisl > >>> Date: Fri Apr 14 02:24:54 2017 -0700 >>> >>> [GR-3206] The parallel scala actors fix should not overwrite the other results. >>> >>> commit e8acaea4d026244a187e50f9f39206730473da30 >>> Merge: 52a9ed9 fa1e93f >>> Author: Doug Simon > >>> Date: Thu Apr 13 07:57:55 2017 -0700 >>> >>> [GR-3627] Correct various errors in code generation (#267). >>> >>> commit 52a9ed925be5511d7984174136d07a2568cd83e5 >>> Merge: 0c30850 fc12456 >>> Author: Matthias Grimmer > >>> Date: Thu Apr 13 07:04:06 2017 -0700 >>> >>> [GR-3642] Explicit hosted (e.g. hosted-graal-core) jvm-config. >>> >>> commit 92a18214d2279ab421c15300d46bab93cac90619 >>> Author: Josef Eisl > >>> Date: Thu Apr 13 15:51:51 2017 +0200 >>> >>> [ci,fix] the parallel scala actors fix should not overwrite the other results >>> >>> commit fa1e93f806c16dfe79b79cc0932b5d2bbea342c4 >>> Merge: 425a9c4 f1f981e >>> Author: Doug Simon > >>> Date: Thu Apr 13 15:27:39 2017 +0200 >>> >>> Merge. >>> >>> commit fc12456b4e654a51009b07d1ff437622bcc5e2b7 >>> Author: Matthias Grimmer > >>> Date: Thu Apr 13 11:27:16 2017 +0200 >>> >>> Add hosted configurations to mx benchmark. >>> >>> commit 0c30850da9fcf74d0b08e3e53f4a99e036294d30 >>> Merge: f1f981e fdf7341 >>> Author: Roland Schatz > >>> Date: Thu Apr 13 04:11:34 2017 -0700 >>> >>> [GR-3629] Fix wrong callRootMethod in GraalTestTVMCI. >>> >>> commit 425a9c4e4d346b1018786d02ba3d9d0a6433cae4 >>> Author: Andrew Dinn > >>> Date: Wed Apr 12 15:43:56 2017 +0100 >>> >>> fix problem in emit for CompressRegister and Uncompressregister >>> >>> commit fdf7341635824a7c6eb3b7be908dd74372aa4736 >>> Author: Roland Schatz > >>> Date: Wed Apr 12 15:50:26 2017 +0200 >>> >>> Fix wrong callRootMethod in GraalTestTVMCI. >>> >>> commit 1c0da37a2cff42a9b46cdfad40d9ccc932e948cb >>> Author: Andrew Dinn > >>> Date: Wed Apr 12 14:53:56 2017 +0100 >>> >>> correct cut-and-pasteo in original patch >>> >>> commit cb8ee4804de9bec5eea213470bd237a83c981cac >>> Author: Andrew Dinn > >>> Date: Wed Apr 12 13:50:36 2017 +0100 >>> >>> correct two small errors in code generation >>> >>> commit f1f981e8002fa6de2989fc223d67d7589d11c0c0 >>> Merge: 1e9c29d 3685425 >>> Author: Doug Simon > >>> Date: Wed Apr 12 04:46:39 2017 -0700 >>> >>> [GR-3598] Remove use of JDK internal API in CompileTheWorld. >>> >>> commit 1e9c29d7bd62ddb5b0180d081db7b9230ea9383d >>> Merge: 8b0ff79 e01a696 >>> Author: Doug Simon > >>> Date: Wed Apr 12 01:46:57 2017 -0700 >>> >>> [GR-3610] Unstrip VM output when running with stripped jars. >>> >>> commit 8b0ff796db6d6d5eae4711f3740b9ec18b68a284 >>> Merge: dde444f 78aecaa >>> Author: Paul W?gerer > >>> Date: Wed Apr 12 01:19:57 2017 -0700 >>> >>> [GR-3556] Handle inlining during parsing more like inlining after parsing. >>> >>> commit e01a696368522b6965e2a73155881ce873858b1d >>> Author: Doug Simon > >>> Date: Tue Apr 11 14:25:13 2017 +0200 >>> >>> apply retrace tool to VM output if running with stripped jars >>> >>> commit 368542591c5d5d0547774cf556217f38b4fd162d >>> Author: Doug Simon > >>> Date: Mon Apr 10 17:17:00 2017 +0200 >>> >>> moved CompileTheWorld out of GRAAL dist and removed its use of JDK internal API >>> added CTW 9 tests to gate >>> >>> commit 78aecaa0a0ac7bbecbdc820f3393eaf09fddb16e >>> Author: Christian Wimmer > >>> Date: Tue Apr 11 13:49:23 2017 -0700 >>> >>> Handle inlining during parsing more like inlining after parsing >>> >>> When a method has multiple returns, inlinig during parsing created a merge frame state with a bci of one of the return bytecodes. Now the handling is the same as in the inlining phase: the merge frame state that does not include the callee (just the caller frame state after the call). >>> >>> commit dde444fdb4608a48b90dacd32719c12efb59f84c >>> Merge: 8c016d0 1d1a3b0 >>> Author: Tom Rodriguez > >>> Date: Tue Apr 11 13:49:12 2017 -0700 >>> >>> [GR-3153] Revert Handle placeholder states specially in PEA. >>> >>> commit 1d1a3b0e18c8c0e5499c719d658013967111e875 >>> Author: Tom Rodriguez > >>> Date: Tue Apr 11 13:12:10 2017 -0700 >>> >>> Revert Handle placeholder states specially in PEA >>> >>> commit 8c016d06d3c18ce9a62d958bf3bed6b30b997687 >>> Merge: 4c4144b 9735c8c >>> Author: David Leopoldseder > >>> Date: Tue Apr 11 10:17:45 2017 -0700 >>> >>> [GR-3476] Remove TruffleCompilationCancellationTest. >>> >>> commit 4c4144b71d527d984637ade1c0ba8f361c326143 >>> Merge: 978c49a a1d0705 >>> Author: Aleksandar Prokopec > >>> Date: Tue Apr 11 05:53:09 2017 -0700 >>> >>> [GR-3601] Ensure that a more specific create method is used when creating comparison nodes. >>> >>> commit a1d0705cd0b7f74075208365bd42b78cdaf1eff2 >>> Author: Aleksandar Prokopec > >>> Date: Mon Apr 10 17:25:10 2017 +0200 >>> >>> Use more specific create method for comparison nodes. >>> >>> commit 978c49ae5c2b4d9cfb000a4c0917b18ef255857d >>> Merge: d07c8b2 af5dd81 >>> Author: Christian Haeubl > >>> Date: Tue Apr 11 05:11:50 2017 -0700 >>> >>> [GR-3595] Cache if a method is covered by an InvocationPlugin. >>> >>> commit af5dd81295c8d7f8070fd051c9848599459afffe >>> Author: Christian Haeubl > >>> Date: Mon Apr 10 12:10:23 2017 +0200 >>> >>> Cache if a method is covered by an InvocationPlugin. >>> >>> commit d07c8b25d76f5956d6d7b62849eafc8ba944abe0 >>> Merge: c72a5d5 d53ce49 >>> Author: Vojin Jovanovic > >>> Date: Tue Apr 11 03:39:18 2017 -0700 >>> >>> [GR-3393] Revert. >>> >>> commit d53ce499e9ce85de2303e642d17ca069b1a47af2 >>> Author: Vojin Jovanovic > >>> Date: Tue Apr 11 11:38:42 2017 +0200 >>> >>> Revert "[GR-3393] Separate compressed oops from HotSpot as much as possible." >>> >>> This reverts commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43, reversing >>> changes made to a872965c61c942ce33fd295a2280dcb54a3b38f4. >>> >>> commit 9735c8c573c1b869b38dbe8cabbf37ebcb82a4e7 >>> Author: David Leopoldseder > >>> Date: Tue Apr 11 10:59:33 2017 +0200 >>> >>> [fix] Remove TruffleCompilationCancellationTest. >>> >>> commit c72a5d5e78538cea5d42967b238fe91198c95ae3 >>> Merge: 0b9c9ee 2d18d0a >>> Author: Tom Rodriguez > >>> Date: Mon Apr 10 09:38:09 2017 -0700 >>> >>> [GR-3153] Handle placeholder states specially in PEA. >>> >>> commit 0b9c9eea96398d0d6bd9ecde2466b12f9aaa2b43 >>> Merge: a872965 eb2ef20 >>> Author: Vojin Jovanovic > >>> Date: Mon Apr 10 07:25:07 2017 -0700 >>> >>> [GR-3393] Separate compressed oops from HotSpot as much as possible. >>> >>> commit eb2ef20805d6c24ff4b0dcc9af644a0365cdb926 >>> Author: Vojin Jovanovic > >>> Date: Mon Mar 27 17:24:40 2017 +0200 >>> >>> [cleanup] separate compressed oops from HotSpot as much as possible >>> >>> commit a872965c61c942ce33fd295a2280dcb54a3b38f4 >>> Merge: 448e5d8 2722294 >>> Author: Josef Eisl > >>> Date: Mon Apr 10 03:14:51 2017 -0700 >>> >>> [GR-3581] Set machine node for parallel benchmarks. >>> >>> commit 27222942948eb21a3be34a3bec1c7aa03d11aed3 >>> Author: Josef Eisl > >>> Date: Mon Apr 10 10:45:16 2017 +0200 >>> >>> [ci] add MACHINE_NODE to parallel benchmarks >>> >>> commit 448e5d899e46c37e3800c92ffa9fdb69f5c5307c >>> Merge: 7cc4f5d 24dba6b >>> Author: Josef Eisl > >>> Date: Mon Apr 10 01:24:11 2017 -0700 >>> >>> [GR-3525] Refine LIR dumping. >>> >>> commit 24dba6b3d9fe7472cb8cd50d00e3b95c0e9118f3 >>> Author: Josef Eisl > >>> Date: Fri Apr 7 17:48:49 2017 +0200 >>> >>> [fix] consolidate stack slot allocation dumping >>> >>> commit d2eacbdc80797f3032ee7a8de383e957b68aef9c >>> Author: Josef Eisl > >>> Date: Fri Apr 7 17:41:33 2017 +0200 >>> >>> [fix] consolidate linear scan dumping >>> >>> commit cbe02790cad450e1fb2af010fc3e56bb87ddd99e >>> Author: Josef Eisl > >>> Date: Fri Apr 7 16:38:57 2017 +0200 >>> >>> [fix] consolidate TraceRA dumping >>> >>> commit 55490c13f6274258b4ca339e30775097e8a97c1c >>> Author: Josef Eisl > >>> Date: Fri Apr 7 16:13:18 2017 +0200 >>> >>> [fix] Remove useless scopes and dumps from emitLIR >>> >>> commit 3f8355da125f50efb0180fdf9c019ae70234db14 >>> Author: Josef Eisl > >>> Date: Fri Apr 7 15:25:24 2017 +0200 >>> >>> [feature] Dump LIR stages in GraalCompiler >>> >>> commit 9c56f54ed009c9d93e0cb3f967f00c03c82028f2 >>> Author: Josef Eisl > >>> Date: Fri Apr 7 15:24:49 2017 +0200 >>> >>> [doc] document LIR dumping levels >>> >>> commit 7cc4f5dcea60bf0dabca37ef28eb97c378e494db >>> Merge: 9edeefc c6fe486 >>> Author: Aleksandar Prokopec > >>> Date: Fri Apr 7 12:35:10 2017 -0700 >>> >>> [GR-3551] Add early canonicalization to IntegerEqualsNode and ObjectEqualsNode. >>> >>> commit c6fe4861464787def1c5eb66842b3ad843285a55 >>> Merge: 8948675 9edeefc >>> Author: Aleksandar Prokopec > >>> Date: Fri Apr 7 19:24:18 2017 +0200 >>> >>> Merge branch 'master' into topic/GR-3551 >>> >>> commit 9edeefc2b6635d97c571c41a3708a2d90ae1ab3a >>> Merge: 8a0a87e c152e63 >>> Author: Josef Eisl > >>> Date: Fri Apr 7 09:27:55 2017 -0700 >>> >>> [GR-3206] Do not execute scala-dacapo actors in parallel. >>> >>> commit 8a0a87eb63cbbc94c8cead115921f96a69d6869b >>> Merge: 633e409 5282a7c >>> Author: Roland Schatz > >>> Date: Fri Apr 7 06:00:40 2017 -0700 >>> >>> [GR-3583] Update truffle import. >>> >>> commit 5282a7c3ffa0cbd0505a3825c718fee32ac1a202 >>> Author: Roland Schatz > >>> Date: Fri Apr 7 13:32:00 2017 +0200 >>> >>> Update truffle import. >>> >>> commit 633e40969f800a2231e5f7e7747f8eb812ebeb6e >>> Merge: d8d8c22 2bac7bc >>> Author: Christian Haeubl > >>> Date: Fri Apr 7 02:08:18 2017 -0700 >>> >>> [GR-3435] Cache JVMCI call results during graph decoding. >>> >>> commit 2bac7bcfcac159d4e7c5b63ab64a83b48b91300b >>> Author: Christian Haeubl > >>> Date: Thu Mar 30 17:10:55 2017 +0200 >>> >>> Cache methods while doing graph decoding. >>> >>> commit 10968ad0ed8432049ee937170df8fbf075807427 >>> Author: Christian Haeubl > >>> Date: Thu Mar 30 14:32:15 2017 +0200 >>> >>> Cache annotations while doing graph decoding. >>> >>> commit d8d8c22904a4cee00988356183e16aaac6cf4e01 >>> Merge: 0ea748e 5a50222 >>> Author: Josef Eisl > >>> Date: Thu Apr 6 09:39:21 2017 -0700 >>> >>> [GR-3515] Explicitly specify phases for compile time benchmarks. >>> >>> commit 89486753b1c8ba3dd85e259eef60556c84b43873 >>> Merge: cca4aa3 65e6110 >>> Author: Aleksandar Prokopec > >>> Date: Thu Apr 6 17:16:00 2017 +0200 >>> >>> Merge branch 'master' into topic/GR-3551 >>> >>> commit 0ea748e92d0ef075da80234cb6e8f2181c55ac88 >>> Merge: 65e6110 c60b383 >>> Author: Roland Schatz > >>> Date: Thu Apr 6 08:06:18 2017 -0700 >>> >>> [GR-3169] Graal produces wrong code for HeapByteBuffer on JDK9. >>> >>> commit cca4aa3eb4377d132cd314a57ff03b8cd7c21d61 >>> Merge: b7cb98d ccd2af9 >>> Author: Aleksandar Prokopec > >>> Date: Thu Apr 6 15:16:19 2017 +0200 >>> >>> Merge branch 'master' into topic/GR-3551 >>> >>> commit c152e63aaa3b0d00d714f33dfbf1c01a14e72acc >>> Author: Josef Eisl > >>> Date: Thu Apr 6 16:37:51 2017 +0200 >>> >>> [ci] do not execute scala-dacapo actors in parallel >>> >>> commit 65e61109f0edc70864767b200ae33a660c6e8dcb >>> Merge: 429d5da 57189f6 >>> Author: Doug Simon > >>> Date: Thu Apr 6 06:58:52 2017 -0700 >>> >>> [GR-3557] Fix regression in reading options from a file. >>> >>> commit c60b3830dc4765f2fd7f4d3f2dd85380bc6861e1 >>> Author: Roland Schatz > >>> Date: Thu Apr 6 15:36:10 2017 +0200 >>> >>> Fix escape analysis of byte array in HeapByteBuffer on JDK 9. >>> >>> commit 429d5da9377ac9f0951e472a93f68ad7d2fd40c8 >>> Merge: ccd2af9 926fe31 >>> Author: Gilles Duboscq > >>> Date: Thu Apr 6 06:11:27 2017 -0700 >>> >>> [GR-3522] Canonicalize `NormalizeCompare < 1`. >>> >>> commit b7cb98d8b43d92ce1a7591e05fc7e5e0c6e453ec >>> Author: Aleksandar Prokopec > >>> Date: Thu Apr 6 15:00:37 2017 +0200 >>> >>> Rewire node creation for CompareNode subclasses and add static creation methods that invoke canonicalization. >>> >>> commit ccd2af9473a022c66eb399d34db22986a4a1b00e >>> Merge: 01222aa 7f3278c >>> Author: David Leopoldseder > >>> Date: Thu Apr 6 05:17:49 2017 -0700 >>> >>> [GR-3568] NodeCostDumpUtil: swallow errors during class loading of nodes. >>> >>> commit 57189f612c106a041ecc4a79c82360c43ca581eb >>> Author: Doug Simon > >>> Date: Wed Apr 5 22:18:24 2017 +0200 >>> >>> fixed regression of handling options in a file >>> >>> commit 7f3278c8530a10d64c9d2e9d5c7c1525847655eb >>> Author: David Leopoldseder > >>> Date: Thu Apr 6 12:48:59 2017 +0200 >>> >>> [fix] NodeCostDumpUtil: swallow errors during class loading of nodes. >>> >>> commit 926fe31632e616776659c289f9376781647b98a1 >>> Author: Gilles Duboscq > >>> Date: Thu Apr 6 13:10:00 2017 +0200 >>> >>> Canonicalize `NormalizeCompare == c` >>> >>> commit 3a72610a51ba874a81c5b7dcd4a5b4dc13aece3b >>> Author: Gilles Duboscq > >>> Date: Tue Apr 4 19:38:10 2017 +0200 >>> >>> [GR-3522] Canonicalize `NormalizeCompare < 1` >>> >>> commit 01222aa50cd049253da87b18d9b86aa1fa8958f6 >>> Merge: 8145122 7c59459 >>> Author: Roland Schatz > >>> Date: Thu Apr 6 03:17:24 2017 -0700 >>> >>> [GR-2925] Graal support for Truffle TestTVMCI. >>> >>> commit 5a502228765bcf2a8f5243708a8c6de0fdad3f15 >>> Author: Josef Eisl > >>> Date: Wed Apr 5 16:49:57 2017 +0200 >>> >>> [ci] restrict TimingBenchmarkMixin timers >>> >>> commit bbcd46991b0b776eb69df17e2130ad9c5e095cab >>> Author: Josef Eisl > >>> Date: Tue Apr 4 13:34:26 2017 +0200 >>> >>> [ci] use -Dgraaldebug.timer.XXX instead of -Dgraal.Time= for TimingBenchmarkMixin >>> >>> commit 4974eb04f4ee81dc48e68eacc505b8e7524c91eb >>> Author: Josef Eisl > >>> Date: Tue Apr 4 13:23:30 2017 +0200 >>> >>> [ci] outsource timerArgs in TimingBenchmarkMixin >>> >>> commit 81451226de18cbe2ccb1f2f23c2110a5cf874169 >>> Merge: 2fc6719 42650bb >>> Author: David Leopoldseder > >>> Date: Thu Apr 6 01:20:45 2017 -0700 >>> >>> [GR-2552] NodeCost Model Improvements. >>> >>> commit 2fc6719fec619137e9e82d74be3c802341761790 >>> Merge: 7f32177 b1f5952 >>> Author: Josef Eisl > >>> Date: Thu Apr 6 00:46:25 2017 -0700 >>> >>> [GR-3514] Register allocation sub-phases do not need to be proper LIRPhases. >>> >>> commit 2d18d0a330c3123f9e62851580a2e18aed231697 >>> Author: Tom Rodriguez > >>> Date: Wed Apr 5 23:56:50 2017 -0700 >>> >>> Handle placeholder states specially in PEA >>> >>> commit 42650bbebbb8d89c66d5517cb761f9e92c1f68cf >>> Author: David Leopoldseder > >>> Date: Tue Feb 21 15:58:33 2017 +0100 >>> >>> [fix] NodeCost: Ensure all nodes specify default costs. >>> >>> commit caf972182c4bd958f658185520e32e88843b200d >>> Author: David Leopoldseder > >>> Date: Mon Feb 20 09:46:56 2017 +0100 >>> >>> [feature] NodeCosts: Verify node cost model integrity in CheckGraalInvariants. >>> >>> commit 7cd39f545c0db26610dc12eb37364b3d3265ec99 >>> Author: David Leopoldseder > >>> Date: Mon Jan 30 11:05:11 2017 +0100 >>> >>> [fix] NodeCosts: Remove provider, move dynamic logic into nodes and fix scale. >>> >>> commit fde0d24a2dddaf45e46cf6dc1dcade625261c5e3 >>> Author: David Leopoldseder > >>> Date: Mon Jan 30 15:46:45 2017 +0100 >>> >>> [feature] NodeCosts: Add option to dump node cost related information to IGV. >>> >>> commit e72bbb87cb4ec9b08f1ee9de9546a2166a5db54d >>> Author: David Leopoldseder > >>> Date: Mon Jan 30 15:08:01 2017 +0100 >>> >>> [feature] NodeCost: Add dump util to dump costs of all node classes >>> >>> commit 7f32177fad91fedabefea6e9919aa5f51657481b >>> Merge: 2eacdb3 ba5773e >>> Author: Doug Simon > >>> Date: Wed Apr 5 13:32:29 2017 -0700 >>> >>> [GR-3528] Convert some assertions in Node to guarantees. >>> >>> commit 63f10a5f38680435c750232702d183f05ad7e67f >>> Merge: cce0b88 2eacdb3 >>> Author: Aleksandar Prokopec > >>> Date: Wed Apr 5 21:47:11 2017 +0200 >>> >>> Merge branch 'master' into topic/GR-3551 >>> >>> commit 2eacdb37f19de982e14d1bb6ea224d2c5ad0c0cc >>> Merge: ee4cbef ba57d4d >>> Author: Doug Simon > >>> Date: Wed Apr 5 11:38:14 2017 -0700 >>> >>> [GR-3521] GraphBuilder: Change semantic of append to be recursive & remove recursiveAppend. >>> >>> commit ba57d4d7f716e5698e040196f9eeb03e2b4d42c5 >>> Merge: 48d9d36 ee4cbef >>> Author: Doug Simon > >>> Date: Wed Apr 5 19:45:58 2017 +0200 >>> >>> Merge branch 'master' into topic/GR-3521 >>> >>> commit cce0b8820624ff627b999a743ff9274e1ee5f9af >>> Author: Aleksandar Prokopec > >>> Date: Wed Apr 5 17:31:13 2017 +0200 >>> >>> Make LowerOp extends CompareOp from CompareNode. >>> >>> commit 41f62af348083b11684927a5222f92abead5bfec >>> Author: Aleksandar Prokopec > >>> Date: Wed Apr 5 17:13:44 2017 +0200 >>> >>> Introduce CompareOp to CompareNode. >>> >>> commit ba5773e0575c5d18974b8bc0470c0fc306161075 >>> Author: Doug Simon > >>> Date: Tue Apr 4 21:21:32 2017 +0200 >>> >>> deprecated varargs version of GraalError.guarantee and replaced with fixed arg versions >>> >>> commit bc448373357aa8825a2cca6be86d0573a8442f17 >>> Author: Doug Simon > >>> Date: Tue Apr 4 21:20:41 2017 +0200 >>> >>> converted some assertions in Node to be guarantees >>> >>> commit 48d9d363d0e78dad51d1b5a6c87ddbfe6df4cece >>> Author: David Leopoldseder > >>> Date: Wed Apr 5 10:07:43 2017 +0200 >>> >>> [fix] GraphBuilder: Change semantic of append to be recursive & remove recursiveAppend >>> >>> commit ee4cbef108f34b17b55ffab2100a59b9b3529881 >>> Merge: 898a31a ce55244 >>> Author: Aleksandar Prokopec > >>> Date: Wed Apr 5 02:55:54 2017 -0700 >>> >>> [GR-3208] Apply node plugins during graph decoding. >>> >>> commit ce55244ca5f6304c3c0a83233976f3fa7af852f4 >>> Merge: 3e99694 898a31a >>> Author: Aleksandar Prokopec > >>> Date: Wed Apr 5 11:08:41 2017 +0200 >>> >>> Merge branch 'master' into topic/GR-3208 >>> >>> commit b1f595227b39ea9017a62129780fd8eddd8ffb64 >>> Author: Josef Eisl > >>> Date: Tue Apr 4 15:44:19 2017 +0200 >>> >>> [fix] LSRA subphases do not need to be AllocationPhases >>> >>> commit 4898e53ab808bf5a0f92da49705743d6da55fd46 >>> Author: Josef Eisl > >>> Date: Tue Apr 4 15:54:36 2017 +0200 >>> >>> [fix] TraceRA: TraceLinearScanAllocationPhase is no TraceAllocationPhase >>> >>> commit 3e99694c859bc1e1243dd0cb2ffdeb52b3364a8a >>> Author: Aleksandar Prokopec > >>> Date: Mon Apr 3 11:10:37 2017 +0200 >>> >>> Move graph builder context allocation to relevant branches, and document the graph builder context subclass. >>> >>> commit f80747fbabf07d9b0b276e9f6db00629dcd2cd1e >>> Merge: ac63293 2de905e >>> Author: Aleksandar Prokopec > >>> Date: Fri Mar 31 16:01:10 2017 +0200 >>> >>> Merge branch 'master' into topic/GR-3208 >>> >>> commit 7c5945907a5e4c5737dd2dcbd52e4af9eb44cce5 >>> Author: Roland Schatz > >>> Date: Fri Mar 31 12:09:05 2017 +0200 >>> >>> Graal support for Truffle TestTVMCI. >>> >>> commit ac63293ed26263d161b0b0ba4b9fcce767f54899 >>> Merge: 61436b1 14702f0 >>> Author: Aleksandar Prokopec > >>> Date: Thu Mar 30 11:50:05 2017 +0200 >>> >>> Merge branch 'master' into topic/GR-3208 >>> >>> commit 61436b1743ea8d785e186fda82ce1d9e5f51334c >>> Merge: 9a18509 acbd663 >>> Author: Aleksandar Prokopec > >>> Date: Thu Mar 30 11:49:10 2017 +0200 >>> >>> Merge branch 'master' into topic/GR-3208 >>> >>> commit 9a18509ff88b8cd184f0f53bb363460741fd0328 >>> Author: Aleksandar Prokopec > >>> Date: Fri Mar 24 12:11:41 2017 +0100 >>> >>> Ensure that node plugins passed to the graph decoder handle all relevant node types. >>> >>> commit cacbd1effa1f1466c8d8b4978bd1d78b8d8b6941 >>> Author: Aleksandar Prokopec > >>> Date: Fri Mar 24 10:46:03 2017 +0100 >>> >>> Add overridable hook for instantiating node plugins. >>> >>> commit a71e6a7326a6a97d129734e22410993951aff00f >>> Author: Aleksandar Prokopec > >>> Date: Thu Mar 23 15:26:01 2017 +0100 >>> >>> Add on-demand handling of load-indexed nodes. >>> >>> commit d9165694fb9c486c6d05aafddcace65e55a4bf8e >>> Merge: e36255e f304652 >>> Author: Aleksandar Prokopec > >>> Date: Thu Mar 23 14:12:55 2017 +0100 >>> >>> Merge branch 'master' into topic/GR-3208-alternative >>> >>> commit e36255e119b994ddca01a54d5fc1c3976935eaf3 >>> Author: Aleksandar Prokopec > >>> Date: Fri Mar 17 11:29:34 2017 +0100 >>> >>> [refactor] Remove CompositeNodePlugin and use NodePlugin arrays instead. >>> >>> commit 859d2e0fe86cae9933fbc6ae71a7ccbad196baff >>> Author: Aleksandar Prokopec > >>> Date: Tue Mar 14 15:55:18 2017 +0100 >>> >>> [feature] Add support for all the node plugin cases to graph decoding. >>> >>> commit e45ae3f1fb381d505351e23ff1bfe5fa1faf97c6 >>> Author: Aleksandar Prokopec > >>> Date: Tue Mar 14 12:29:13 2017 +0100 >>> >>> [fix] Prevent node plugin graph changes when not necessary. >>> >>> commit f8589ed80ce1f759ae14cd7ee314b0f4d82e4cc4 >>> Author: Aleksandar Prokopec > >>> Date: Mon Mar 13 17:16:31 2017 +0100 >>> >>> [feature] Add node plugins to graph decoder, and implement the handleLoadIndexed case. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cthalinger at twitter.com Wed Apr 19 18:24:48 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 19 Apr 2017 08:24:48 -1000 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: Message-ID: I lost track a bit but why are we exporting jdk.vm.ci.services to the world now? module jdk.internal.vm.ci { - exports jdk.vm.ci.services to jdk.internal.vm.compiler; + exports jdk.vm.ci.services; > On Apr 18, 2017, at 9:16 PM, Doug Simon wrote: > > (adding hotspot-compiler-dev) > > Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. > The primary requirement for this is to remove all usage of JDK internals from Graal. > While this most involves changes in Graal, there remain a few capabilities that must > be exposed via JVMCI. Namely: > > 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize > can use system properties that are guaranteed not to have been modified by application > code (Graal initialization is lazy and may occur after application code has been run). > > 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal > optimized implementation of the Truffle runtime. > > These capabilities have been added to jdk.vm.ci.services.Services. A comment has > also been added to this class to denote the current methods to be removed > in a subsequent bug to update the JDK copy of Graal with the upstream version which > no longer uses the methods. The methods destined for removal are: > > exportJVMCITo(Class requestor) > load(Class service) > loadSingle(Class service, boolean required) > > The first one is no longer needed as JVMCI exports itself to Graal service providers > it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. > The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API > is only useful for JVMCI-8 where a hidden JVMCI class loader is used. > > These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra > minor changes were required: > > 1. In JDK-8177673, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException > on all error paths except one which throws AssertionError. The latter was a mistake and has been > fixed to also throw IllegalArgumentException. > 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. > Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. > This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. > > As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and > remove use of JDK internal API from the jdk.aot module. The qualified exports to > jdk.vm.internal.compiler and jdk.aot can then be removed. > > -Doug > > https://bugs.openjdk.java.net/browse/JDK-8177845 > http://cr.openjdk.java.net/~dnsimon/8177845/ > > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Apr 19 18:38:04 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 11:38:04 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: Message-ID: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. Mandy > On Apr 19, 2017, at 11:24 AM, Christian Thalinger wrote: > > I lost track a bit but why are we exporting jdk.vm.ci.services to the world now? > > module jdk.internal.vm.ci { > - exports jdk.vm.ci.services to jdk.internal.vm.compiler; > + exports jdk.vm.ci.services; > >> On Apr 18, 2017, at 9:16 PM, Doug Simon wrote: >> >> (adding hotspot-compiler-dev) >> >> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >> The primary requirement for this is to remove all usage of JDK internals from Graal. >> While this most involves changes in Graal, there remain a few capabilities that must >> be exposed via JVMCI. Namely: >> >> 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize >> can use system properties that are guaranteed not to have been modified by application >> code (Graal initialization is lazy and may occur after application code has been run). >> >> 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal >> optimized implementation of the Truffle runtime. >> >> These capabilities have been added to jdk.vm.ci.services.Services. A comment has >> also been added to this class to denote the current methods to be removed >> in a subsequent bug to update the JDK copy of Graal with the upstream version which >> no longer uses the methods. The methods destined for removal are: >> >> exportJVMCITo(Class requestor) >> load(Class service) >> loadSingle(Class service, boolean required) >> >> The first one is no longer needed as JVMCI exports itself to Graal service providers >> it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. >> The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API >> is only useful for JVMCI-8 where a hidden JVMCI class loader is used. >> >> These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra >> minor changes were required: >> >> 1. In JDK-8177673, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException >> on all error paths except one which throws AssertionError. The latter was a mistake and has been >> fixed to also throw IllegalArgumentException. >> 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. >> Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. >> This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. >> >> As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and >> remove use of JDK internal API from the jdk.aot module. The qualified exports to >> jdk.vm.internal.compiler and jdk.aot can then be removed. >> >> -Doug >> >> https://bugs.openjdk.java.net/browse/JDK-8177845 >> http://cr.openjdk.java.net/~dnsimon/8177845/ >> >> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess >> >> >> > From cthalinger at twitter.com Wed Apr 19 18:55:29 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 19 Apr 2017 08:55:29 -1000 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> Message-ID: <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> > On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: > > Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. > > The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? After all, this is a security issue. > > Mandy > >> On Apr 19, 2017, at 11:24 AM, Christian Thalinger wrote: >> >> I lost track a bit but why are we exporting jdk.vm.ci.services to the world now? >> >> module jdk.internal.vm.ci { >> - exports jdk.vm.ci.services to jdk.internal.vm.compiler; >> + exports jdk.vm.ci.services; >> >>> On Apr 18, 2017, at 9:16 PM, Doug Simon wrote: >>> >>> (adding hotspot-compiler-dev) >>> >>> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >>> The primary requirement for this is to remove all usage of JDK internals from Graal. >>> While this most involves changes in Graal, there remain a few capabilities that must >>> be exposed via JVMCI. Namely: >>> >>> 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize >>> can use system properties that are guaranteed not to have been modified by application >>> code (Graal initialization is lazy and may occur after application code has been run). >>> >>> 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal >>> optimized implementation of the Truffle runtime. >>> >>> These capabilities have been added to jdk.vm.ci.services.Services. A comment has >>> also been added to this class to denote the current methods to be removed >>> in a subsequent bug to update the JDK copy of Graal with the upstream version which >>> no longer uses the methods. The methods destined for removal are: >>> >>> exportJVMCITo(Class requestor) >>> load(Class service) >>> loadSingle(Class service, boolean required) >>> >>> The first one is no longer needed as JVMCI exports itself to Graal service providers >>> it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. >>> The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API >>> is only useful for JVMCI-8 where a hidden JVMCI class loader is used. >>> >>> These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra >>> minor changes were required: >>> >>> 1. In JDK-8177673, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException >>> on all error paths except one which throws AssertionError. The latter was a mistake and has been >>> fixed to also throw IllegalArgumentException. >>> 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. >>> Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. >>> This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. >>> >>> As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and >>> remove use of JDK internal API from the jdk.aot module. The qualified exports to >>> jdk.vm.internal.compiler and jdk.aot can then be removed. >>> >>> -Doug >>> >>> https://bugs.openjdk.java.net/browse/JDK-8177845 >>> http://cr.openjdk.java.net/~dnsimon/8177845/ >>> >>> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess >>> >>> >>> >> > From mandy.chung at oracle.com Wed Apr 19 19:04:49 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 12:04:49 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> Message-ID: > On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: > > >> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >> >> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >> >> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. > > This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? It's unqualified and no restriction in this change. Mandy From doug.simon at oracle.com Wed Apr 19 19:27:38 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 21:27:38 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> Message-ID: > On 19 Apr 2017, at 21:04, Mandy Chung wrote: > > >> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >> >> >>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>> >>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>> >>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >> >> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? > > It's unqualified and no restriction in this change. The public methods currently in jdk.vm.ci.services are: 1. JVMCIServiceLocator.getProvider(Class) 2. JVMCIServiceLocator.getProviders(Class) 3. Services.initializeJVMCI() 4. Services.getSavedProperties() 5. Services.exportJVMCITo(Class) 6. Services.load(Class) 7. Services.loadSingle(Class, boolean) 1 should be made protected. I'll update the webrev with this change. 2 should check for JVMCIPermission. I'll update the webrev with this change. 3 is harmless from a security perspective in my opinion. 4 checks for JVMCIPermission. 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). Does this address the security concerns? -Doug From cthalinger at twitter.com Wed Apr 19 19:40:19 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 19 Apr 2017 09:40:19 -1000 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> Message-ID: > On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: > >> >> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >> >> >>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>> >>> >>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>> >>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>> >>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>> >>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >> >> It's unqualified and no restriction in this change. > > The public methods currently in jdk.vm.ci.services are: > > 1. JVMCIServiceLocator.getProvider(Class) > 2. JVMCIServiceLocator.getProviders(Class) > 3. Services.initializeJVMCI() > 4. Services.getSavedProperties() > 5. Services.exportJVMCITo(Class) > 6. Services.load(Class) > 7. Services.loadSingle(Class, boolean) > > 1 should be made protected. I'll update the webrev with this change. Good. > > 2 should check for JVMCIPermission. I'll update the webrev with this change. Good. > > 3 is harmless from a security perspective in my opinion. Would be good if one of Oracle?s security engineers could take a quick look just to be sure. > > 4 checks for JVMCIPermission. Ok. > > 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). About this, will this Graal update happen for JDK 9? It?s awfully late in the cycle... > > Does this address the security concerns? Mostly, yes. Thanks. > > -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Wed Apr 19 21:12:22 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 23:12:22 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> Message-ID: <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> > On 19 Apr 2017, at 21:40, Christian Thalinger wrote: > >> >> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >> >>> >>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>> >>> >>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>> >>>> >>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>> >>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>> >>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>> >>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>> >>> It's unqualified and no restriction in this change. >> >> The public methods currently in jdk.vm.ci.services are: >> >> 1. JVMCIServiceLocator.getProvider(Class) >> 2. JVMCIServiceLocator.getProviders(Class) >> 3. Services.initializeJVMCI() >> 4. Services.getSavedProperties() >> 5. Services.exportJVMCITo(Class) >> 6. Services.load(Class) >> 7. Services.loadSingle(Class, boolean) >> >> 1 should be made protected. I'll update the webrev with this change. > > Good. > >> >> 2 should check for JVMCIPermission. I'll update the webrev with this change. > > Good. > >> >> 3 is harmless from a security perspective in my opinion. > > Would be good if one of Oracle?s security engineers could take a quick look just to be sure. Vladimir, can you please bring this to the attention of the relevant engineer. >> >> 4 checks for JVMCIPermission. > > Ok. > >> >> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). > > About this, will this Graal update happen for JDK 9? Yes. > It?s awfully late in the cycle... These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). -Doug From doug.simon at oracle.com Wed Apr 19 21:26:28 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 23:26:28 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> Message-ID: <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: 1. JVMCIServiceLocator.getProvider(Class) is now protected 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK -Doug > On 19 Apr 2017, at 23:12, Doug Simon wrote: > >> >> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >> >>> >>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>> >>>> >>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>> >>>> >>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>> >>>>> >>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>> >>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>> >>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>> >>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>> >>>> It's unqualified and no restriction in this change. >>> >>> The public methods currently in jdk.vm.ci.services are: >>> >>> 1. JVMCIServiceLocator.getProvider(Class) >>> 2. JVMCIServiceLocator.getProviders(Class) >>> 3. Services.initializeJVMCI() >>> 4. Services.getSavedProperties() >>> 5. Services.exportJVMCITo(Class) >>> 6. Services.load(Class) >>> 7. Services.loadSingle(Class, boolean) >>> >>> 1 should be made protected. I'll update the webrev with this change. >> >> Good. >> >>> >>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >> >> Good. >> >>> >>> 3 is harmless from a security perspective in my opinion. >> >> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. > > Vladimir, can you please bring this to the attention of the relevant engineer. > >>> >>> 4 checks for JVMCIPermission. >> >> Ok. >> >>> >>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >> >> About this, will this Graal update happen for JDK 9? > > Yes. > >> It?s awfully late in the cycle... > > These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). > > -Doug From igor.ignatyev at oracle.com Wed Apr 19 21:45:16 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 19 Apr 2017 14:45:16 -0700 Subject: RFR(XL/M) : 8178788: wrap JCStress test suite as jtreg tests In-Reply-To: <28eafe0f-c951-7a24-2fa0-7e994db7beec@oracle.com> References: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> <5a1da3e4-622b-66a4-1228-4a7e3ebbee91@oracle.com> <33C90E84-6872-4DC4-B6F9-74055D943876@oracle.com> <28eafe0f-c951-7a24-2fa0-7e994db7beec@oracle.com> Message-ID: Hi David, thank for catching those, the incremental webrev : http://cr.openjdk.java.net/~iignatyev/8178788/webrev.01-02/ Cheers, -- Igor > On Apr 18, 2017, at 11:17 PM, David Holmes wrote: > > Hi Igor, > > Thanks for the jtreg info! > > You missed a couple of things in the README: > > 27 All the tests are run thought test driver class -- JcstressRunner, which > > s/thought/through the/ > > And I just noticed an additional typo: > > 29 spawns a new JVM to run one jsctress test > > jsctress -> jcstress > > Thanks, > David > ----- > > On 19/04/2017 12:51 PM, Igor Ignatyev wrote: >> Hi David, >> >> thank you for your comments, I've tried to address them all, please look at the incremental webrev: http://cr.openjdk.java.net/~iignatyev/8178788/webrev.00-01/index.html >> >> regarding multiple test declarations, jtreg supports that, but in the current version it's not fully/officially supported and hence it's not documented. Jon has fixed a few jtreg bugs[1-3] related to this and AFAIK is working towards full support, so I hope it will be supported and documented in the next promoted build of jtreg. >> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7900144 : Implement multiple tests in one file in jtreg >> [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7901914 : Failure to find multiple @test in a single file >> [3] https://bugs.openjdk.java.net/browse/CODETOOLS-7901940 : support multiple @test in one test file >> >> Thanks, >> -- Igor >> >>> On Apr 18, 2017, at 6:28 PM, David Holmes wrote: >>> >>> Hi Igor, >>> >>> On 19/04/2017 8:12 AM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >>>>> 69903 lines changed: 69903 ins; 0 del; 0 mod; >>>> (69524 lines are generated) >>>> >>>> Hi all, >>>> >>>> could you please review this patch which adds a jtreg test wrapper for jcstress test suite and jtreg tests which run jsctress tests thru this wrapper? >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8178788 >>>> testing: applications/jcstress >>> >>> This looks really good! Only concern is that according to the docs jtreg doesn't seem to support multiple test declarations in a single file ?? Maybe the docs are out of date? >> >>> >>> http://openjdk.java.net/jtreg/tag-spec.html >>> >>> A few grammatical nits in the README: >>> >>> 23 The tests located under this directory run tests from Java Concurrency Stress >>> >>> from Java -> from the Java >>> >>> 24 [1] aka jcstress test suite. This suite aims to verify the correctness of >>> >>> Suggest: >>> >>> test suite [1] (a.k.a. jcstress). This suite ... >>> >>> 25 concurrency support in JDK. >>> >>> in JDK -> in the JDK >>> >>> 27 All the tests are run thought test driver class -- JcstressRunner, which >>> >>> s/thought/through the/ >>> >>> 29 spawns a new JVM to run one jsctress test and checks that it is finished >>> >>> is finished -> finishes >>> >>> 33 changed, one should make corresponding changes in the artifact description in >>> >>> in the -> to the >>> >>> 36 */Test.java files should never be modified directly, because they are >>> >>> Insert "The" at start. >>> >>> --- >>> >>> General Java style nits re long ling wrapping. You seem to be using a consistent "indent by 8" style when wrapping long lines. The "usual" style guidelines suggest a more structured indentation style, for example: >>> >>> - when wrapping the arguments to a call align after the opening ( of the call ie: >>> >>> throw new Error("TESTBUG: Can not resolve artifacts for " >>> + JcstressRunner.class.getName(), e); >>> >>> - when you have chained method calls, try to align at the dots ie: >>> >>> return artifacts.get("org.openjdk.jcstress.jcstress-tests-all-0.3") >>> .toAbsolutePath(); >>> >>> and >>> >>> ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(getCmd(args)) >>> .redirectErrorStream(true) >>> .redirectOutput(out.toFile()); >>> >>> --- >>> >>> test/applications/jcstress/TestGenerator.java >>> >>> 44 * This is a test generator, should be run only when jsctress is changed >>> >>> Typo: jsctress -> jcstress >>> >>> 51 * Use jcstress test suite to generates >>> >>> generates -> generate >>> >>> Strictly speaking the copyright years should only be updated when there is a substantive change to the text of the file, so updating whenever the files are regenerated is not really correct. This may need to be manually adjusted when commiting updated files ... though if there is no change other than to copyright year then the changes can simply be ignored (hg revert) and no update pushed. >>> >>> Thanks, >>> David >>> ------ >>> >>>> Thanks, >>>> -- Igor >>>> >> From vladimir.kozlov at oracle.com Wed Apr 19 22:28:09 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Apr 2017 15:28:09 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> Message-ID: <21999ed5-23aa-939b-f1e5-1eb08b3c03e4@oracle.com> Hotspot changes looks good to me. Thanks, Vladimir On 4/19/17 2:26 PM, Doug Simon wrote: > I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: > > 1. JVMCIServiceLocator.getProvider(Class) is now protected > 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission > 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK > > -Doug > >> On 19 Apr 2017, at 23:12, Doug Simon wrote: >> >>> >>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>> >>>> >>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>> >>>>> >>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>> >>>>> >>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>> >>>>>> >>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>> >>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>> >>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>> >>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>> >>>>> It's unqualified and no restriction in this change. >>>> >>>> The public methods currently in jdk.vm.ci.services are: >>>> >>>> 1. JVMCIServiceLocator.getProvider(Class) >>>> 2. JVMCIServiceLocator.getProviders(Class) >>>> 3. Services.initializeJVMCI() >>>> 4. Services.getSavedProperties() >>>> 5. Services.exportJVMCITo(Class) >>>> 6. Services.load(Class) >>>> 7. Services.loadSingle(Class, boolean) >>>> >>>> 1 should be made protected. I'll update the webrev with this change. >>> >>> Good. >>> >>>> >>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>> >>> Good. >>> >>>> >>>> 3 is harmless from a security perspective in my opinion. >>> >>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >> >> Vladimir, can you please bring this to the attention of the relevant engineer. >> >>>> >>>> 4 checks for JVMCIPermission. >>> >>> Ok. >>> >>>> >>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>> >>> About this, will this Graal update happen for JDK 9? >> >> Yes. >> >>> It?s awfully late in the cycle... >> >> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >> >> -Doug > From vladimir.kozlov at oracle.com Wed Apr 19 22:31:25 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Apr 2017 15:31:25 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> Message-ID: Doug, Can you point (link) particular code which needs to be reviewed? And what security issues could be? Thanks, Vladimir On 4/19/17 2:12 PM, Doug Simon wrote: >> 3. Services.initializeJVMCI() >>> 3 is harmless from a security perspective in my opinion. >> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. > Vladimir, can you please bring this to the attention of the relevant engineer. > From david.holmes at oracle.com Wed Apr 19 23:16:39 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Apr 2017 09:16:39 +1000 Subject: RFR(XL/M) : 8178788: wrap JCStress test suite as jtreg tests In-Reply-To: References: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> <5a1da3e4-622b-66a4-1228-4a7e3ebbee91@oracle.com> <33C90E84-6872-4DC4-B6F9-74055D943876@oracle.com> <28eafe0f-c951-7a24-2fa0-7e994db7beec@oracle.com> Message-ID: <25befcfc-9f25-70de-5a90-0b76e34fc737@oracle.com> Looks good! Sorry I should have said no new webrev needed :) Thanks, David On 20/04/2017 7:45 AM, Igor Ignatyev wrote: > Hi David, > > thank for catching those, the incremental webrev : http://cr.openjdk.java.net/~iignatyev/8178788/webrev.01-02/ > > Cheers, > -- Igor > >> On Apr 18, 2017, at 11:17 PM, David Holmes wrote: >> >> Hi Igor, >> >> Thanks for the jtreg info! >> >> You missed a couple of things in the README: >> >> 27 All the tests are run thought test driver class -- JcstressRunner, which >> >> s/thought/through the/ >> >> And I just noticed an additional typo: >> >> 29 spawns a new JVM to run one jsctress test >> >> jsctress -> jcstress >> >> Thanks, >> David >> ----- >> >> On 19/04/2017 12:51 PM, Igor Ignatyev wrote: >>> Hi David, >>> >>> thank you for your comments, I've tried to address them all, please look at the incremental webrev: http://cr.openjdk.java.net/~iignatyev/8178788/webrev.00-01/index.html >>> >>> regarding multiple test declarations, jtreg supports that, but in the current version it's not fully/officially supported and hence it's not documented. Jon has fixed a few jtreg bugs[1-3] related to this and AFAIK is working towards full support, so I hope it will be supported and documented in the next promoted build of jtreg. >>> >>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7900144 : Implement multiple tests in one file in jtreg >>> [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7901914 : Failure to find multiple @test in a single file >>> [3] https://bugs.openjdk.java.net/browse/CODETOOLS-7901940 : support multiple @test in one test file >>> >>> Thanks, >>> -- Igor >>> >>>> On Apr 18, 2017, at 6:28 PM, David Holmes wrote: >>>> >>>> Hi Igor, >>>> >>>> On 19/04/2017 8:12 AM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >>>>>> 69903 lines changed: 69903 ins; 0 del; 0 mod; >>>>> (69524 lines are generated) >>>>> >>>>> Hi all, >>>>> >>>>> could you please review this patch which adds a jtreg test wrapper for jcstress test suite and jtreg tests which run jsctress tests thru this wrapper? >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8178788 >>>>> testing: applications/jcstress >>>> >>>> This looks really good! Only concern is that according to the docs jtreg doesn't seem to support multiple test declarations in a single file ?? Maybe the docs are out of date? >>> >>>> >>>> http://openjdk.java.net/jtreg/tag-spec.html >>>> >>>> A few grammatical nits in the README: >>>> >>>> 23 The tests located under this directory run tests from Java Concurrency Stress >>>> >>>> from Java -> from the Java >>>> >>>> 24 [1] aka jcstress test suite. This suite aims to verify the correctness of >>>> >>>> Suggest: >>>> >>>> test suite [1] (a.k.a. jcstress). This suite ... >>>> >>>> 25 concurrency support in JDK. >>>> >>>> in JDK -> in the JDK >>>> >>>> 27 All the tests are run thought test driver class -- JcstressRunner, which >>>> >>>> s/thought/through the/ >>>> >>>> 29 spawns a new JVM to run one jsctress test and checks that it is finished >>>> >>>> is finished -> finishes >>>> >>>> 33 changed, one should make corresponding changes in the artifact description in >>>> >>>> in the -> to the >>>> >>>> 36 */Test.java files should never be modified directly, because they are >>>> >>>> Insert "The" at start. >>>> >>>> --- >>>> >>>> General Java style nits re long ling wrapping. You seem to be using a consistent "indent by 8" style when wrapping long lines. The "usual" style guidelines suggest a more structured indentation style, for example: >>>> >>>> - when wrapping the arguments to a call align after the opening ( of the call ie: >>>> >>>> throw new Error("TESTBUG: Can not resolve artifacts for " >>>> + JcstressRunner.class.getName(), e); >>>> >>>> - when you have chained method calls, try to align at the dots ie: >>>> >>>> return artifacts.get("org.openjdk.jcstress.jcstress-tests-all-0.3") >>>> .toAbsolutePath(); >>>> >>>> and >>>> >>>> ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(getCmd(args)) >>>> .redirectErrorStream(true) >>>> .redirectOutput(out.toFile()); >>>> >>>> --- >>>> >>>> test/applications/jcstress/TestGenerator.java >>>> >>>> 44 * This is a test generator, should be run only when jsctress is changed >>>> >>>> Typo: jsctress -> jcstress >>>> >>>> 51 * Use jcstress test suite to generates >>>> >>>> generates -> generate >>>> >>>> Strictly speaking the copyright years should only be updated when there is a substantive change to the text of the file, so updating whenever the files are regenerated is not really correct. This may need to be manually adjusted when commiting updated files ... though if there is no change other than to copyright year then the changes can simply be ignored (hg revert) and no update pushed. >>>> >>>> Thanks, >>>> David >>>> ------ >>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>> > From aph at redhat.com Thu Apr 20 07:46:45 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Apr 2017 08:46:45 +0100 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> Message-ID: <485a1ba1-9b67-fb08-e575-51047575b0fc@redhat.com> On 19/04/17 19:55, Christian Thalinger wrote: > This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? After all, this is a security issue. Does that make any sense? Surely the *user* of a system can call Truffle, and therefore can call JMCI. I thought that was the idea. If you can call Truffle from your own code, why shouldn't you be able to call JVMCI from your own compiler? Andrew. From doug.simon at oracle.com Thu Apr 20 07:49:10 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 20 Apr 2017 09:49:10 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> Message-ID: > On 20 Apr 2017, at 00:31, Vladimir Kozlov wrote: > > Doug, > > Can you point (link) particular code which needs to be reviewed? And what security issues could be? I believe Chris had possible concerns with Services.initializeJVMCI() (at http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java.udiff.html). As previously stated, I can't see any security issues with this method which is why it doesn't check JVMCIPermission. -Doug > > Thanks, > Vladimir > > On 4/19/17 2:12 PM, Doug Simon wrote: >>> 3. Services.initializeJVMCI() > >>>> 3 is harmless from a security perspective in my opinion. >>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >> Vladimir, can you please bring this to the attention of the relevant engineer. >> From doug.simon at oracle.com Thu Apr 20 07:56:45 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 20 Apr 2017 09:56:45 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <485a1ba1-9b67-fb08-e575-51047575b0fc@redhat.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <485a1ba1-9b67-fb08-e575-51047575b0fc@redhat.com> Message-ID: <416E3E08-88A6-4DE4-B251-6E0992C1D702@oracle.com> > On 20 Apr 2017, at 09:46, Andrew Haley wrote: > > On 19/04/17 19:55, Christian Thalinger wrote: >> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? After all, this is a security issue. > > Does that make any sense? Surely the *user* of a system can call Truffle, > and therefore can call JMCI. Truffle is completely separate from JVMCI. Only the Graal implementation of TruffleRuntime knows about JVMCI. > I thought that was the idea. If you can call > Truffle from your own code, why shouldn't you be able to call JVMCI from > your own compiler? We may need to add some doPrivileged sections to Graal at some point ensure everything works when running Truffle under a security manager. -Doug From aph at redhat.com Thu Apr 20 08:01:07 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Apr 2017 09:01:07 +0100 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <416E3E08-88A6-4DE4-B251-6E0992C1D702@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <485a1ba1-9b67-fb08-e575-51047575b0fc@redhat.com> <416E3E08-88A6-4DE4-B251-6E0992C1D702@oracle.com> Message-ID: <85062406-dda1-b229-b009-d53240f95fef@redhat.com> On 20/04/17 08:56, Doug Simon wrote: > >> On 20 Apr 2017, at 09:46, Andrew Haley wrote: >> >> On 19/04/17 19:55, Christian Thalinger wrote: >>> This all makes sense but where is the restriction that only >>> jdk.internal.vm.compiler can use jdk.vm.ci.services? After all, >>> this is a security issue. >> >> Does that make any sense? Surely the *user* of a system can call Truffle, >> and therefore can call JMCI. > > Truffle is completely separate from JVMCI. Only the Graal > implementation of TruffleRuntime knows about JVMCI. Yes, I am aware of that. :-) >> I thought that was the idea. If you can call Truffle from your own >> code, why shouldn't you be able to call JVMCI from your own >> compiler? > > We may need to add some doPrivileged sections to Graal at some point > ensure everything works when running Truffle under a security > manager. That would be courageous. But what Christian was saying, I believe, was that JVMCI could be restricted to only being available from jdk.internal.vm.compiler. Andrew. From doug.simon at oracle.com Thu Apr 20 08:34:55 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 20 Apr 2017 10:34:55 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <85062406-dda1-b229-b009-d53240f95fef@redhat.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <485a1ba1-9b67-fb08-e575-51047575b0fc@redhat.com> <416E3E08-88A6-4DE4-B251-6E0992C1D702@oracle.com> <85062406-dda1-b229-b009-d53240f95fef@redhat.com> Message-ID: <641462BB-A1A1-4CF6-B0A4-E279E795ACA7@oracle.com> > On 20 Apr 2017, at 10:01, Andrew Haley wrote: > > On 20/04/17 08:56, Doug Simon wrote: >> >>> On 20 Apr 2017, at 09:46, Andrew Haley wrote: >>> >>> On 19/04/17 19:55, Christian Thalinger wrote: >>>> This all makes sense but where is the restriction that only >>>> jdk.internal.vm.compiler can use jdk.vm.ci.services? After all, >>>> this is a security issue. >>> >>> Does that make any sense? Surely the *user* of a system can call Truffle, >>> and therefore can call JMCI. >> >> Truffle is completely separate from JVMCI. Only the Graal >> implementation of TruffleRuntime knows about JVMCI. > > Yes, I am aware of that. :-) Ok, sorry for being confused by your statement ;-) >>> I thought that was the idea. If you can call Truffle from your own >>> code, why shouldn't you be able to call JVMCI from your own >>> compiler? >> >> We may need to add some doPrivileged sections to Graal at some point >> ensure everything works when running Truffle under a security >> manager. > > That would be courageous. But what Christian was saying, I believe, > was that JVMCI could be restricted to only being available from > jdk.internal.vm.compiler. Ah, ok. That would go against the move to make jdk.internal.vm.compiler an upgradeable module as there should not be any qualified exports to an upgradeable module. For this reason, the security of JVMCI relies on exporting as little of the API as possible and having JVMCIPermission checks on the exported methods where necessary. -Doug From rwestrel at redhat.com Thu Apr 20 11:12:03 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 20 Apr 2017 13:12:03 +0200 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> Message-ID: Hi Vladimir, Thanks for reviewing this change. > Did you run performance testing? I would have expected standard benchmarks such as specjvm2008 to not be affected by this change. Do you think they can be? Any other performance testing you would recommend? > It could affect loop optimizations and cause performance regression > loops have unsafe access. On other hand unsafe accesses have membars so > it may be not big deal. > At least run Andrew's ByteBuffers ;) This change hurts Andrew's ByteBuffers test. But I intend to next propose a change that uses profiling at unsafe call sites to speculate that an unsafe access is on heap (at the cost of a null check). With this change C2 will generate code as good as it currently does for Andrew's test. Roland. From aph at redhat.com Thu Apr 20 11:21:24 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Apr 2017 12:21:24 +0100 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> Message-ID: <352faa06-3fe4-de8a-eeb6-3506bf555a1e@redhat.com> On 20/04/17 12:12, Roland Westrelin wrote: >> It could affect loop optimizations and cause performance regression >> loops have unsafe access. On other hand unsafe accesses have membars so >> it may be not big deal. >> At least run Andrew's ByteBuffers ;) > > This change hurts Andrew's ByteBuffers test. But I intend to next > propose a change that uses profiling at unsafe call sites to speculate > that an unsafe access is on heap (at the cost of a null check). With > this change C2 will generate code as good as it currently does for > Andrew's test. Well, yes, I know. :-) But the real goal of that ByteBuffer test (and indeed all of the ByteBuffer optimizations) is to provide access to raw memory "as fast as C", and has implications for project Valhalla, etc. So it's really important that it not regress. Andrew. From rwestrel at redhat.com Thu Apr 20 13:06:33 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 20 Apr 2017 15:06:33 +0200 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: <352faa06-3fe4-de8a-eeb6-3506bf555a1e@redhat.com> References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> <352faa06-3fe4-de8a-eeb6-3506bf555a1e@redhat.com> Message-ID: > But the real goal of that ByteBuffer test (and indeed all of the > ByteBuffer optimizations) is to provide access to raw memory "as fast > as C", and has implications for project Valhalla, etc. In the case of the ByteBuffer test, with the changes I'm proposing there will be an extra null check to verify accesses are on heap. That null check will be out of loop so essentially free and there won't be any regression. Off heap accesses or a mix of on heap and off heap accesses in the same method would regress. Roland. From aph at redhat.com Thu Apr 20 13:28:02 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Apr 2017 14:28:02 +0100 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> <352faa06-3fe4-de8a-eeb6-3506bf555a1e@redhat.com> Message-ID: <426f8c5d-e012-64ce-3696-c4d1c80fd692@redhat.com> On 20/04/17 14:06, Roland Westrelin wrote: > >> But the real goal of that ByteBuffer test (and indeed all of the >> ByteBuffer optimizations) is to provide access to raw memory "as fast >> as C", and has implications for project Valhalla, etc. > > In the case of the ByteBuffer test, with the changes I'm proposing there > will be an extra null check to verify accesses are on heap. That null > check will be out of loop so essentially free and there won't be any > regression. Off heap accesses or a mix of on heap and off heap accesses > in the same method would regress. A lot of people need off-heap ByteBuffers to be really fast. This is important for Lucene, big data, etc. So we must be careful. Andrew. From rwestrel at redhat.com Thu Apr 20 13:57:09 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 20 Apr 2017 15:57:09 +0200 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: <426f8c5d-e012-64ce-3696-c4d1c80fd692@redhat.com> References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> <352faa06-3fe4-de8a-eeb6-3506bf555a1e@redhat.com> <426f8c5d-e012-64ce-3696-c4d1c80fd692@redhat.com> Message-ID: > A lot of people need off-heap ByteBuffers to be really fast. This is > important for Lucene, big data, etc. So we must be careful. For off heap accesses, with this change, I expect we should be back to where we were before https://bugs.openjdk.java.net/browse/JDK-8176513 was fixed. From that thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026169.html as I understand, the lucene folks were ok with the level of optimizations before JDK-8176513 was fixed. Actually, profiling would tell us if an access is always on heap, always off heap or mixed and I suppose we could drop membars and be less conservative for always off heap accesses. Mixed accesses are the hard ones. Roland. From vladimir.kozlov at oracle.com Thu Apr 20 16:44:17 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Apr 2017 09:44:17 -0700 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> Message-ID: <8b01bdd0-6fad-8355-1433-47999aaa2d64@oracle.com> Okay. It is good to know that you have a plan to address regression. Thanks, Vladimir On 4/20/17 4:12 AM, Roland Westrelin wrote: > > Hi Vladimir, > > Thanks for reviewing this change. > >> Did you run performance testing? > > I would have expected standard benchmarks such as specjvm2008 to not be > affected by this change. Do you think they can be? Any other performance > testing you would recommend? > >> It could affect loop optimizations and cause performance regression >> loops have unsafe access. On other hand unsafe accesses have membars so >> it may be not big deal. >> At least run Andrew's ByteBuffers ;) > > This change hurts Andrew's ByteBuffers test. But I intend to next > propose a change that uses profiling at unsafe call sites to speculate > that an unsafe access is on heap (at the cost of a null check). With > this change C2 will generate code as good as it currently does for > Andrew's test. > > Roland. > From cthalinger at twitter.com Thu Apr 20 17:27:16 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 20 Apr 2017 07:27:16 -1000 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <641462BB-A1A1-4CF6-B0A4-E279E795ACA7@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <485a1ba1-9b67-fb08-e575-51047575b0fc@redhat.com> <416E3E08-88A6-4DE4-B251-6E0992C1D702@oracle.com> <85062406-dda1-b229-b009-d53240f95fef@redhat.com> <641462BB-A1A1-4CF6-B0A4-E279E795ACA7@oracle.com> Message-ID: <8C577E96-2E55-4056-882B-7E8D0CB95E52@twitter.com> > On Apr 19, 2017, at 10:34 PM, Doug Simon wrote: > >> >> On 20 Apr 2017, at 10:01, Andrew Haley wrote: >> >> On 20/04/17 08:56, Doug Simon wrote: >>> >>>> On 20 Apr 2017, at 09:46, Andrew Haley wrote: >>>> >>>> On 19/04/17 19:55, Christian Thalinger wrote: >>>>> This all makes sense but where is the restriction that only >>>>> jdk.internal.vm.compiler can use jdk.vm.ci.services? After all, >>>>> this is a security issue. >>>> >>>> Does that make any sense? Surely the *user* of a system can call Truffle, >>>> and therefore can call JMCI. >>> >>> Truffle is completely separate from JVMCI. Only the Graal >>> implementation of TruffleRuntime knows about JVMCI. >> >> Yes, I am aware of that. :-) > > Ok, sorry for being confused by your statement ;-) > >>>> I thought that was the idea. If you can call Truffle from your own >>>> code, why shouldn't you be able to call JVMCI from your own >>>> compiler? >>> >>> We may need to add some doPrivileged sections to Graal at some point >>> ensure everything works when running Truffle under a security >>> manager. >> >> That would be courageous. But what Christian was saying, I believe, >> was that JVMCI could be restricted to only being available from >> jdk.internal.vm.compiler. > > Ah, ok. That would go against the move to make jdk.internal.vm.compiler an upgradeable module as there should not be any qualified exports to an upgradeable module. For this reason, the security of JVMCI relies on exporting as little of the API as possible and having JVMCIPermission checks on the exported methods where necessary. If that?s the case then I?m fine. We just have to make sure all JVMCIPermission checks are in place. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Thu Apr 20 17:59:36 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 20 Apr 2017 10:59:36 -0700 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> <352faa06-3fe4-de8a-eeb6-3506bf555a1e@redhat.com> Message-ID: In addition to Andrew?s test i have a simple JMH microbenchmark i can send you, which i used to measure performance and identify issues with code generation, misalignment, and unrolled loops for byte buffer access (off/on heap) and VarHandle views. specjvm2008 is likely too coarse grained. Paul. > On 20 Apr 2017, at 06:06, Roland Westrelin wrote: > > >> But the real goal of that ByteBuffer test (and indeed all of the >> ByteBuffer optimizations) is to provide access to raw memory "as fast >> as C", and has implications for project Valhalla, etc. > > In the case of the ByteBuffer test, with the changes I'm proposing there > will be an extra null check to verify accesses are on heap. That null > check will be out of loop so essentially free and there won't be any > regression. Off heap accesses or a mix of on heap and off heap accesses > in the same method would regress. > > Roland. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From doug.simon at oracle.com Thu Apr 20 18:50:16 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 20 Apr 2017 20:50:16 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <69BA05B6-C33A-4D97-A323-3E3216515A38@oracle.com> Message-ID: > On 19 Apr 2017, at 22:29, Vladimir Kozlov wrote: > > ReflectionAccessJDK ? Based on your comment in the file. > > Vladimir > > On 4/19/17 1:02 PM, Doug Simon wrote: >> Sure - how about good old Util? ;-) I'm open to other suggestions. >> >> Sent from my iPhone >> >>> On Apr 19, 2017, at 9:46 PM, Vladimir Kozlov wrote: >>> >>> Hi Doug, >>> >>> Can you consider using other name and not JDK9 for new JVMCI class? It will be used in JDK 10 too: >>> >>> jdk.vm.ci.services.internal.JDK9; >>> >>> Thanks, >>> Vladimir >>> >>>> On 4/18/17 3:13 PM, Doug Simon wrote: >>>> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >>>> The primary requirement for this is to remove all usage of JDK internals from Graal. >>>> While this most involves changes in Graal, there remain a few capabilities that must >>>> be exposed via JVMCI. Namely: >>>> >>>> 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize >>>> can use system properties that are guaranteed not to have been modified by application >>>> code (Graal initialization is lazy and may occur after application code has been run). >>>> >>>> 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal >>>> optimized implementation of the Truffle runtime. >>>> >>>> These capabilities have been added to jdk.vm.ci.services.Services. A comment has >>>> also been added to this class to denote the current methods to be removed >>>> in a subsequent bug to update the JDK copy of Graal with the upstream version which >>>> no longer uses the methods. The methods destined for removal are: >>>> >>>> exportJVMCITo(Class requestor) >>>> load(Class service) >>>> loadSingle(Class service, boolean required) >>>> >>>> The first one is no longer needed as JVMCI exports itself to Graal service providers >>>> it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. >>>> The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API >>>> is only useful for JVMCI-8 where a hidden JVMCI class loader is used. >>>> >>>> These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra >>>> minor changes were required: >>>> >>>> 1. In JDK-8177663, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException >>>> on all error paths except one which throws AssertionError. The latter was a mistake and has been >>>> fixed to also throw IllegalArgumentException. >>>> 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. >>>> Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. >>>> This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. >>>> >>>> As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and >>>> remove use of JDK internal API from the jdk.aot module. The qualified exports to >>>> jdk.vm.internal.compiler and jdk.aot can then be removed. >>>> >>>> -Doug >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8177845 >>>> http://cr.openjdk.java.net/~dnsimon/8177845/ >>>> >>>> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess >>>> >>>> >>>> >> From doug.simon at oracle.com Thu Apr 20 18:50:56 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 20 Apr 2017 20:50:56 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> Message-ID: <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg tests to prevent Graal being selected and initialized by the JVMCI compiler auto-selection mechanism. Initializing Graal will currently fail with errors (see stack trace below) until Graal is updated to the version compatible with the JVMCI API changes. In addition to resolving the compatibility issue, explicitly selecting the "null" compiler for these tests better isolates them from parts of the runtime they are not aiming to test. org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217) at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138) at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native Method) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185) at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59) at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64) at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125) at java.base/java.util.ArrayList.forEach(ArrayList.java:1378) at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:563) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215) ... 26 more -Doug > On 19 Apr 2017, at 23:26, Doug Simon wrote: > > I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: > > 1. JVMCIServiceLocator.getProvider(Class) is now protected > 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission > 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK > > -Doug > >> On 19 Apr 2017, at 23:12, Doug Simon wrote: >> >>> >>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>> >>>> >>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>> >>>>> >>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>> >>>>> >>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>> >>>>>> >>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>> >>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>> >>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>> >>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>> >>>>> It's unqualified and no restriction in this change. >>>> >>>> The public methods currently in jdk.vm.ci.services are: >>>> >>>> 1. JVMCIServiceLocator.getProvider(Class) >>>> 2. JVMCIServiceLocator.getProviders(Class) >>>> 3. Services.initializeJVMCI() >>>> 4. Services.getSavedProperties() >>>> 5. Services.exportJVMCITo(Class) >>>> 6. Services.load(Class) >>>> 7. Services.loadSingle(Class, boolean) >>>> >>>> 1 should be made protected. I'll update the webrev with this change. >>> >>> Good. >>> >>>> >>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>> >>> Good. >>> >>>> >>>> 3 is harmless from a security perspective in my opinion. >>> >>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >> >> Vladimir, can you please bring this to the attention of the relevant engineer. >> >>>> >>>> 4 checks for JVMCIPermission. >>> >>> Ok. >>> >>>> >>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>> >>> About this, will this Graal update happen for JDK 9? >> >> Yes. >> >>> It?s awfully late in the cycle... >> >> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >> >> -Doug > From vivek.r.deshpande at intel.com Thu Apr 20 20:54:28 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 20 Apr 2017 20:54:28 +0000 Subject: RFR(S): 8178811: Minimize the AVX <-> SSE transition penalty on x86 In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A63CD479B@ORSMSX106.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A63CDA33F@ORSMSX106.amr.corp.intel.com> HI Vladimir We added almost all the vzeroupper instructions by analyzing SPECjbb2015. We need vzeroupper after we execute avx2/avx-512 and before transition to SSE to avoid penalty of saving and restoring higher bits in YMM/ZMM registers. Since JVM is SSE compiled, mixing of AVX and SSE code happens in C1 and interpreter with usage of intrinsics, so I have added vzerouppers at these transitions in the stubs. I think max_vector_size() > 16 would be with auto vectorization, but we need to have vzeroupper with stubs and intrinsics. I have made all the changes which you suggested. Please take a look at the patch and let me know your thoughts. The updated Webrev is here: http://cr.openjdk.java.net/~vdeshpande/8178811/webrev.01/ Thank you. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, April 14, 2017 12:48 PM To: Deshpande, Vivek R; hotspot compiler Cc: Viswanathan, Sandhya Subject: Re: RFR(S): 8178811: Minimize the AVX <-> SSE transition penalty on x86 Hi Vivek, Did you pinpoint particular change which helps SPECjbb2015? From what I remember it is mostly during call to runtime or JNI calls. // AVX instruction which is used to clear upper 128 bits of YMM registers and // to avoid transaction penalty between AVX and SSE states. There is no // penalty if legacy SSE instructions are encoded using VEX prefix because // they always clear upper 128 bits. It should be used before calling // runtime code and native libraries. void vzeroupper(); So why you added vzeroupper() into arraycopy and other stubs? If AVX is supported all instructions should be encoded with VEX prefix. Or the statement in the comment is incorrect? About UseVzeroupper flag. We should avoid adding new product flags if possible. IT only make sense if you want to do experiments to check performance with and without it. But we already know that it is needed on most CPUs. I would suggest to add VM_Version::supports_vzeroupper() { return (_features & CPU_VZEROUPPER) != 0; } Set CPU_VZEROUPPE if AVX is supported and clear it for Knights CPU. The add check inside assembler instruction: void Assembler::vzeroupper() { - assert(VM_Version::supports_avx(), ""); + if (VM_Version::supports_vzeroupper()) { It will allow to avoid supports_avx() checks on each vzeroupper() call. You missed check in MachEpilogNode::emit() in x86_64.ad Note, I used (C->max_vector_size() > 16) checks in .ad files because of the same reasons as above: // There is no penalty if legacy SSE instructions are encoded using VEX prefix because // they always clear upper 128 bits. I thought if vectors are small and we use VEX prefix then upper bits will be 0 anyway so you don't need vzeroupper(). Thanks, Vladimir On 4/14/17 11:17 AM, Deshpande, Vivek R wrote: > Hi All > > > > This fix minimizes the AVX to SSE and SSE to AVX transition penalty > through generation of vzeroupper instruction. With this patch we see > zero transitions with penalty per SPECjbb2015 jOPS on BDW and a significant reduction on SKX CPU event vector width mismatch from 65 to 0.01 per SPECjbb2015 jOPS. We have also implemented an enhancement to disable vzeroupper generation for Knights family where the instruction has high penalty and is not recommended. The option UseVzeroupper is used to control generation of vzeroupper instruction and gets set to false on the Knights family. > We observed ~3% gain on SPECJvm2008 composite result on Skylake. > > Webrev: > > http://cr.openjdk.java.net/~vdeshpande/8178811/webrev.00/ > > I have also updated the JBS entry. > > https://bugs.openjdk.java.net/browse/JDK-8178811 > > Would you please review and sponsor it. > > > > Regards, > > Vivek > > > From kim.barrett at oracle.com Fri Apr 21 00:32:12 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 20 Apr 2017 20:32:12 -0400 Subject: RFR 8150388: Remove SPARC 32-bit support In-Reply-To: <6d45bbc8-8a2b-1cc4-461f-c7dd37e7d239@oracle.com> References: <8C096D6B-AFEB-44BD-ACDF-0709E04300A9@oracle.com> <6d45bbc8-8a2b-1cc4-461f-c7dd37e7d239@oracle.com> Message-ID: <9A56C2CB-893E-4759-9882-434B2CA8E6CB@oracle.com> On Apr 19, 2017, at 1:54 PM, George Triantafillou wrote: > > Hi Kim, > > Comments inline: > > On 4/15/2017 4:27 AM, Kim Barrett wrote: >>> On Apr 7, 2017, at 10:47 AM, George Triantafillou wrote: >>> >>> (Adding compiler). >>> Please review this fix to remove SPARC 32-bit support. Support for solaris-sparc has been dropped from the list of supported platforms. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150388 >>> webrev: http://cr.openjdk.java.net/~gtriantafill/8150388-webrev/webrev/ >>> >>> Built and tested on solaris-sparcv9-debug,solaris-x64-debug with the nsk.jvmti, nsk.jdwp, and nsk.jdi testlists. >>> >>> Thanks. >>> >>> -George >> That's a lot of files and changes! I hope you'll be providing >> incremental webrevs for updates. > I've checked in the change for 8150388, but will address the issues you raised. Thanks. [My email client threaded the message cc'd to the compiler list separately from the one only to the runtime list where most of the discussion occurred, so I missed that there had been lots of other folks looking at this.] For the places where you said you weren't sure what should be done in response to my comment, mostly I'm not either. These are places where I think further cleanup is needed, but it's not mechanical in the way removing conditionalized dead code was. Rather, someone who actually understands the code needs to look at it and make appropriate changes. >> src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp >> 1490 Register yhi = opr2->as_register_hi(); >> >> After the removal of the 32bit code, I don't see any remaining >> references to yhi. Not sure what that implies, other than there's >> likely further work to do here. > It's unclear to me what what should be done here. Make sure it isn't a bug that yhi is no longer referenced. Remove if that's appropriate. Maybe some variable renaming? >> src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp >> 2574 Register cmp_value_hi = op->cmp_value()->as_register_hi(); >> ... >> 2576 Register new_value_hi = op->new_value()->as_register_hi(); >> >> After the removal of the 32bit code, I don't see any remaining >> references to the xxx_hi variables. Not sure what that implies, other >> than there's likely further work to do here. > It's unclear to me what what should be done here. Like the similar problem at line 1490. >> src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp >> 3047 void LIR_Assembler::volatile_move_op(LIR_Opr src, LIR_Opr dest, BasicType type, CodeEmitInfo* info) { >> 3048 ShouldNotReachHere(); >> 3049 >> 3050 NEEDS_CLEANUP; >> >> It appears that in 64bit mode this function has no implementation, and >> the following 50+ lines of code are presently 32bit-only. Likely >> further work to do here. > It's unclear to me what what should be done here. I'm not sure either. Possibly just delete everything in that function after the ShouldNotReacheHere(), and comment that line as this not being needed for _LP64. That would be consistent with the PPC and S390 ports. But x86 and aarch64 ports have code there, and arm port has an Unimplemented() with a TODO comment for AARCH64. There may be code elsewhere that is artificially preventing reaching the ShouldNotReachHere / Unimplemented cases. Again, something for someone who actually understands the code to look at. >> src/cpu/sparc/vm/globalDefinitions_sparc.hpp >> 43 #elif defined(COMPILER1) >> 44 // pure C1, 32-bit, small machine >> 45 #define DEFAULT_CACHE_LINE_SIZE 16 >> >> Comment suggests this is a configuration we don't use with 64bit. > It's unclear to me what what should be done here. Just remove the conditionalization and always define as 128? Again, needs someone who understands the code to look at this. Note the default (in globalDefinitions.hpp) is 64. >> src/cpu/sparc/vm/sparc.ad >> 314 // 64-bit build means 64-bit pointers means hi/lo pairs >> >> "64-bit build means" seems superfluous now. > Really? Suggestions? Since there are now only 64-bit builds, that part of the comment seems unnecessary, so just trim it off the front, leaving the rest of the comment. >> src/cpu/sparc/vm/sparc.ad >> 1856 // Note that we if-def off of _LP64. >> 1857 // The relevant question is how the int is callee-saved. In _LP64 >> 1858 // the whole long is written but de-opt'ing will have to extract >> 1859 // the relevant 32 bits, in not-_LP64 only the low 32 bits is written. >> >> The commentary here needs some updating; there is no not-_LP64 >> anymore. > Agreed. How should it read? Perhaps something like: When callee-saving an int value, in _LP64 the whole thing is written, but de-opt'ing will have to extract the relevant 32 bits. But again, someone who knows the code should look at it. >> src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp >> 60 // The sethi() instruction generates lots more instructions when shell >> 61 // stack limit is unlimited, so that's why this is much bigger. >> >> "why this is much bigger" ? than what? Oh, the 32bit value. Some >> revision of comment is called for here. > It's from Changeset: 9934 (fd5d53ecf040) 8146410: Interpreter functions are declared and defined in the wrong files. It?s still confusing, since the referent is to the no longer present 32bit code. >> src/cpu/sparc/vm/vm_version_sparc.cpp >> 73 // 32-bit oops don't make sense for the 64-bit VM on sparc >> 74 // since the 32-bit VM has the same registers and smaller objects. >> >> This comment probably needs updating. > It's from Changeset: 642 (660978a2a31a) 6791178: Specialize for zero as the compressed oop vm heap base Yes, but the reference to a 32-bit VM seems orphaned now. Something should be changed here, but I don?t know what it should be changed to. From aph at redhat.com Fri Apr 21 07:23:37 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Apr 2017 08:23:37 +0100 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> <352faa06-3fe4-de8a-eeb6-3506bf555a1e@redhat.com> Message-ID: <297c1c5e-9fde-a82d-e8cb-34cb3641dae1@redhat.com> On 20/04/17 18:59, Paul Sandoz wrote: > In addition to Andrew?s test i have a simple JMH microbenchmark i can send you, which i used to measure performance and identify issues with code generation, misalignment, and unrolled loops for byte buffer access (off/on heap) and VarHandle views. specjvm2008 is likely too coarse grained. It'd be nice to have that. I might try put do it in an automated regression test. Andrew. From doug.simon at oracle.com Fri Apr 21 11:46:11 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 21 Apr 2017 13:46:11 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> Message-ID: <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> There has been some discussion about whether we want to update Graal in the JDK at this late stage. The main (only?) risk is a regression in the AOT tool. If we don't update Graal from upstream, then the qualified exports from JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in addition to updating Graal to remove the qualified exports, there would also need to be changes in the relevant make files to add --add-exports options when compiling Graal and jaotc as they use the dynamically exported JVMCI packages. I have an updated hotspot patch that adapts Graal to the JVMCI API changes: http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/ Note that this patch does not include the changes removing use of JDK internal API from Graal. Cherry picking those upstream Graal changes would be more work than simply doing a complete update from upstream Graal. As I see it, there are 2 options here: 1. Go with the current webrev (including hotspot.02 patch) and live with the qualified exports. 2. Go with the current webrev (including hotspot.02 patch) and create a follow up bug to update Graal from upstream, perform the relevant make file changes and remove the qualified exports. I've tested the current webrev (including hotspot.02 patch) against both upstream Graal and with jprt. -Doug > On 20 Apr 2017, at 20:50, Doug Simon wrote: > > I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an > exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg > tests to prevent Graal being selected and initialized by the JVMCI compiler auto-selection mechanism. > Initializing Graal will currently fail with errors (see stack trace below) until Graal is updated to > the version compatible with the JVMCI API changes. > > In addition to resolving the compatibility issue, explicitly selecting the "null" compiler for these > tests better isolates them from parts of the runtime they are not aiming to test. > > org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties > at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217) > at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138) > at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) > at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) > at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native Method) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185) > at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59) > at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64) > at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1378) > at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:563) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) > at java.base/java.lang.Thread.run(Thread.java:844) > Caused by: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties > at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215) > ... 26 more > > -Doug > >> On 19 Apr 2017, at 23:26, Doug Simon wrote: >> >> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: >> >> 1. JVMCIServiceLocator.getProvider(Class) is now protected >> 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission >> 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK >> >> -Doug >> >>> On 19 Apr 2017, at 23:12, Doug Simon wrote: >>> >>>> >>>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>>> >>>>> >>>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>>> >>>>>> >>>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>>> >>>>>> >>>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>>> >>>>>>> >>>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>>> >>>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>>> >>>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>>> >>>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>>> >>>>>> It's unqualified and no restriction in this change. >>>>> >>>>> The public methods currently in jdk.vm.ci.services are: >>>>> >>>>> 1. JVMCIServiceLocator.getProvider(Class) >>>>> 2. JVMCIServiceLocator.getProviders(Class) >>>>> 3. Services.initializeJVMCI() >>>>> 4. Services.getSavedProperties() >>>>> 5. Services.exportJVMCITo(Class) >>>>> 6. Services.load(Class) >>>>> 7. Services.loadSingle(Class, boolean) >>>>> >>>>> 1 should be made protected. I'll update the webrev with this change. >>>> >>>> Good. >>>> >>>>> >>>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>>> >>>> Good. >>>> >>>>> >>>>> 3 is harmless from a security perspective in my opinion. >>>> >>>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >>> >>> Vladimir, can you please bring this to the attention of the relevant engineer. >>> >>>>> >>>>> 4 checks for JVMCIPermission. >>>> >>>> Ok. >>>> >>>>> >>>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>>> >>>> About this, will this Graal update happen for JDK 9? >>> >>> Yes. >>> >>>> It?s awfully late in the cycle... >>> >>> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >>> >>> -Doug >> > From igor.veresov at oracle.com Fri Apr 21 20:55:57 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 21 Apr 2017 13:55:57 -0700 Subject: RFR(M) 8179100: [AOT] Rewrite redundant initialization elimination Message-ID: Redundant initialization elimination can be rewritten using the dominator tree visitor pattern. This makes code much more readable. It also now handle the case of the dominating initialization of a subclass. And since now we have more time the phase requires a unit test. Webrev: http://cr.openjdk.java.net/~iveresov/8179100/webrev.00 (It?s a complete rewrite, so don?t look at the diffs, they are messy). I?ll be pushing this through graal-core and doing a graal update after that. igor From vladimir.kozlov at oracle.com Fri Apr 21 22:27:45 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Apr 2017 15:27:45 -0700 Subject: RFR(M) 8179100: [AOT] Rewrite redundant initialization elimination In-Reply-To: References: Message-ID: <52eb066a-9629-3737-bbba-a1f1bc9931af@oracle.com> On 4/21/17 1:55 PM, Igor Veresov wrote: > Redundant initialization elimination can be rewritten using the dominator tree visitor pattern. This makes code much more readable. It also now handle the case of the dominating initialization of a subclass. And since now we have more time the phase requires a unit test. I don't see unit test. > > Webrev: http://cr.openjdk.java.net/~iveresov/8179100/webrev.00 Seems good. But I assume Graal guys will review it too. > (It?s a complete rewrite, so don?t look at the diffs, they are messy). Thank you for warning ;) Thanks, Vladimir > > I?ll be pushing this through graal-core and doing a graal update after that. > > igor > From igor.veresov at oracle.com Fri Apr 21 22:57:35 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 21 Apr 2017 15:57:35 -0700 Subject: RFR(M) 8179100: [AOT] Rewrite redundant initialization elimination In-Reply-To: <52eb066a-9629-3737-bbba-a1f1bc9931af@oracle.com> References: <52eb066a-9629-3737-bbba-a1f1bc9931af@oracle.com> Message-ID: > On Apr 21, 2017, at 3:27 PM, Vladimir Kozlov wrote: > > On 4/21/17 1:55 PM, Igor Veresov wrote: >> Redundant initialization elimination can be rewritten using the dominator tree visitor pattern. This makes code much more readable. It also now handle the case of the dominating initialization of a subclass. And since now we have more time the phase requires a unit test. > > I don't see unit test. Yeah, forgot it, webrev updated in-place. igor > >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8179100/webrev.00 > > Seems good. But I assume Graal guys will review it too. > >> (It?s a complete rewrite, so don?t look at the diffs, they are messy). > > Thank you for warning ;) > > Thanks, > Vladimir > >> >> I?ll be pushing this through graal-core and doing a graal update after that. >> >> igor >> From vladimir.kozlov at oracle.com Fri Apr 21 23:34:37 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Apr 2017 16:34:37 -0700 Subject: RFR(M) 8179100: [AOT] Rewrite redundant initialization elimination In-Reply-To: References: <52eb066a-9629-3737-bbba-a1f1bc9931af@oracle.com> Message-ID: Okay. Thanks, Vladimir On 4/21/17 3:57 PM, Igor Veresov wrote: > >> On Apr 21, 2017, at 3:27 PM, Vladimir Kozlov wrote: >> >> On 4/21/17 1:55 PM, Igor Veresov wrote: >>> Redundant initialization elimination can be rewritten using the dominator tree visitor pattern. This makes code much more readable. It also now handle the case of the dominating initialization of a subclass. And since now we have more time the phase requires a unit test. >> >> I don't see unit test. > > Yeah, forgot it, webrev updated in-place. > > igor > >> >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8179100/webrev.00 >> >> Seems good. But I assume Graal guys will review it too. >> >>> (It?s a complete rewrite, so don?t look at the diffs, they are messy). >> >> Thank you for warning ;) >> >> Thanks, >> Vladimir >> >>> >>> I?ll be pushing this through graal-core and doing a graal update after that. >>> >>> igor >>> > From zoltan.majo at oracle.com Mon Apr 24 15:20:38 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 24 Apr 2017 17:20:38 +0200 Subject: [1] RFR (S) 8179019: Correct range checks for command-line options ArraycopySrcPrefetchDistance and ArraycopyDstPrefetchDistance Message-ID: Hi, please review the following fix for 8179019. https://bugs.openjdk.java.net/browse/JDK-8179019 http://cr.openjdk.java.net/~zmajo/8179019/webrev.00/ Currently, the HotSpot allows Arraycopy{Src|Dst}PrefetchDistance only one value. Before JDK-8078554, values in the interval [0, 4096] were allowed (without explicit checking, though). This change extends the set of values allowed to the interval [0, 4031]. We need the high bound 4032 (instead of 4096) because of [1]: the largest value of offset is 64, so 4031 + 64 = 4095 is the maximum that fits into the signed range of 13 bits. The change also includes suggestions by Vladimir K [2] to avoid using too large immediate values. I tested the change manually with some values from both ends of the range and also with JPRT (incl. the currently disabled TestOptionsWithRanges.java test). Thank you! Best regards, Zoltan [1] http://hg.openjdk.java.net/jdk10/hs/hotspot/file/1617b39a1ae4/src/cpu/sparc/vm/stubGenerator_sparc.cpp#l2128 [2] https://bugs.openjdk.java.net/browse/JDK-8179019?focusedCommentId=14071776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14071776 From zoltan.majo at oracle.com Mon Apr 24 15:26:04 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 24 Apr 2017 17:26:04 +0200 Subject: [1] RFR (S) 8179019: Correct range checks for command-line options ArraycopySrcPrefetchDistance and ArraycopyDstPrefetchDistance In-Reply-To: References: Message-ID: P.S.: Sorry for the error in the subject: I suggest this change for JDK 10 (and not 1.0). On 04/24/2017 05:20 PM, Zolt?n Maj? wrote: > Hi, > > > please review the following fix for 8179019. > https://bugs.openjdk.java.net/browse/JDK-8179019 > http://cr.openjdk.java.net/~zmajo/8179019/webrev.00/ > > Currently, the HotSpot allows Arraycopy{Src|Dst}PrefetchDistance only > one value. Before JDK-8078554, values in the interval [0, 4096] were > allowed (without explicit checking, though). > > This change extends the set of values allowed to the interval [0, > 4031]. We need the high bound 4032 (instead of 4096) because of [1]: > the largest value of offset is 64, so 4031 + 64 = 4095 is the maximum > that fits into the signed range of 13 bits. The change also includes > suggestions by Vladimir K [2] to avoid using too large immediate values. > > I tested the change manually with some values from both ends of the > range and also with JPRT (incl. the currently disabled > TestOptionsWithRanges.java test). > > Thank you! > > Best regards, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk10/hs/hotspot/file/1617b39a1ae4/src/cpu/sparc/vm/stubGenerator_sparc.cpp#l2128 > [2] > https://bugs.openjdk.java.net/browse/JDK-8179019?focusedCommentId=14071776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14071776 > From vladimir.kozlov at oracle.com Tue Apr 25 07:34:10 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Apr 2017 00:34:10 -0700 Subject: [1] RFR (S) 8179019: Correct range checks for command-line options ArraycopySrcPrefetchDistance and ArraycopyDstPrefetchDistance In-Reply-To: References: Message-ID: <1515d4fa-c214-8b64-8267-ba151fff80c7@oracle.com> Good. Thanks, vladimir On 4/24/17 8:20 AM, Zolt?n Maj? wrote: > Hi, > > > please review the following fix for 8179019. > https://bugs.openjdk.java.net/browse/JDK-8179019 > http://cr.openjdk.java.net/~zmajo/8179019/webrev.00/ > > Currently, the HotSpot allows Arraycopy{Src|Dst}PrefetchDistance only > one value. Before JDK-8078554, values in the interval [0, 4096] were > allowed (without explicit checking, though). > > This change extends the set of values allowed to the interval [0, 4031]. > We need the high bound 4032 (instead of 4096) because of [1]: the > largest value of offset is 64, so 4031 + 64 = 4095 is the maximum that > fits into the signed range of 13 bits. The change also includes > suggestions by Vladimir K [2] to avoid using too large immediate values. > > I tested the change manually with some values from both ends of the > range and also with JPRT (incl. the currently disabled > TestOptionsWithRanges.java test). > > Thank you! > > Best regards, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk10/hs/hotspot/file/1617b39a1ae4/src/cpu/sparc/vm/stubGenerator_sparc.cpp#l2128 > > [2] > https://bugs.openjdk.java.net/browse/JDK-8179019?focusedCommentId=14071776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14071776 > > From zoltan.majo at oracle.com Tue Apr 25 08:15:11 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 25 Apr 2017 10:15:11 +0200 Subject: [1] RFR (S) 8179019: Correct range checks for command-line options ArraycopySrcPrefetchDistance and ArraycopyDstPrefetchDistance In-Reply-To: <1515d4fa-c214-8b64-8267-ba151fff80c7@oracle.com> References: <1515d4fa-c214-8b64-8267-ba151fff80c7@oracle.com> Message-ID: <2833ecdd-622d-918e-ace9-1dda110d4355@oracle.com> Thank you, Vladimir. Best regards, Zoltan On 04/25/2017 09:34 AM, Vladimir Kozlov wrote: > Good. > > Thanks, > vladimir > > On 4/24/17 8:20 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following fix for 8179019. >> https://bugs.openjdk.java.net/browse/JDK-8179019 >> http://cr.openjdk.java.net/~zmajo/8179019/webrev.00/ >> >> Currently, the HotSpot allows Arraycopy{Src|Dst}PrefetchDistance only >> one value. Before JDK-8078554, values in the interval [0, 4096] were >> allowed (without explicit checking, though). >> >> This change extends the set of values allowed to the interval [0, 4031]. >> We need the high bound 4032 (instead of 4096) because of [1]: the >> largest value of offset is 64, so 4031 + 64 = 4095 is the maximum that >> fits into the signed range of 13 bits. The change also includes >> suggestions by Vladimir K [2] to avoid using too large immediate values. >> >> I tested the change manually with some values from both ends of the >> range and also with JPRT (incl. the currently disabled >> TestOptionsWithRanges.java test). >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> [1] >> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/1617b39a1ae4/src/cpu/sparc/vm/stubGenerator_sparc.cpp#l2128 >> >> >> [2] >> https://bugs.openjdk.java.net/browse/JDK-8179019?focusedCommentId=14071776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14071776 >> >> >> From rwestrel at redhat.com Tue Apr 25 08:38:00 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 25 Apr 2017 10:38:00 +0200 Subject: [9 or 10] RFR(S): 8179070: nashorn+octane's box2d causes c2 to crash with "Bad graph detected in compute_lca_of_uses" Message-ID: http://cr.openjdk.java.net/~roland/8179070/webrev.00/ The test case below reproduces a similar problem: http://cr.openjdk.java.net/~roland/8179070/TestClassLoadingConstant.java This is a concurrency issue between a compiler thread and a thread initializing a class. The test case can be used to cause a "malformed control flow" compilation failure. This only really happens if the compiler thread is artifically paused at a strategic point during compilation to allow concurrent class initialization. When compiling TestClassLoadingConstant.test(), when ciTypeFlow processes: o2 = D.unloaded_field; it finds class D to be loaded but not initialized and class UnloadedClass to be unloaded. Assuming class loading of C happens concurrently at this point, ciTypeFlow will then process: Object o1 = C.unloaded_field; and find C to be initialized but will still consider UnloadedClass to be unloaded because it was processed before. ciTypeFlow::StateVector::do_getstatic() speculates an access to a field of unloaded type is a null field. Parse::do_get_xxx() makes the same assumption to keep everything consistent. The type of o1 on loop entry after ciTypeFlow is done is the meet of null from o1 = C.unloaded_field; and LoadedClass from o1 = loaded_field; so LoadedClass. When C2 parses: Object o1 = C.unloaded_field; it finds the field is a non null constant. The check: if (field->is_constant()) { in Parse::do_get_xxx() happens before the code that mirrors the logic of ciTypeFlow and treats an unloaded field as null. When C2 parses the loop entry, it creates a Phi for o1 of the type computed by ciTypeFlow so LoadedClass. That Phi's first input is the constant of unrelated type UnloadClass. During CCP, the inconsistency causes the Phi to becomes top and some part of the control flow to die. I can reproduce the failure with the TestClassLoadingConstant test case on 9 and 10. I see the failure with box2d on almost all runs of box2d with 10. I suspect the issues reproduces very easily, because the method being compiled is huge with a lot of incremental inlining going on so the window for the concurrent class loading to occur is quite large. I couldn't reproduce it with 9 though. The fix seems safe enough that I would say this would better be fixed in 9. Roland. From shade at redhat.com Tue Apr 25 10:47:05 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Apr 2017 12:47:05 +0200 Subject: RFR(XL/M) : 8178788: wrap JCStress test suite as jtreg tests In-Reply-To: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> References: <9A2C94EA-89A3-4C75-9D3C-51E058BD8A1D@oracle.com> Message-ID: <342c3748-616f-8a7d-74f4-3ce929b1e0dc@redhat.com> On 04/19/2017 12:12 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html >> 69903 lines changed: 69903 ins; 0 del; 0 mod; > (69524 lines are generated) > > Hi all, > > could you please review this patch which adds a jtreg test wrapper for > jcstress test suite and jtreg tests which run jsctress tests thru this > wrapper? > > webrev: http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8178788 testing: TL;DR: This patch introduces more problems than it solves. Just run the jcstress tests-all JAR against the tested runtime. Wrapping jcstress tests with jtreg defies the purpose of jcstress harness -- that is, running lots of tests as fast as it possibly could without affecting testing quality. For example, by cleverly reusing VMs between the tests, using Whitebox to deoptimize without restarting the VMs, etc. It really wastes CPU time to run each test in isolation. Also, it does not "automatically" work, which defies "easy to run" goal: Caused by: java.io.FileNotFoundException: Couldn't automatically resolve dependency for jcstress-tests-all , revision 0.3 Please specify the location using jdk.test.lib.artifacts.jcstress-tests-all at jdk.test.lib.artifacts.DefaultArtifactManager.resolve(DefaultArtifactManager.java:37) at jdk.test.lib.artifacts.ArtifactResolver.resolve(ArtifactResolver.java:54) at applications.jcstress.JcstressRunner.pathToArtifact(JcstressRunner.java:53) ... 8 more Okay, brilliant! How do I configure this, if I run "make test"? CONF=linux-x86_64-normal-server-release LOG=info make test TEST="hotspot_all" -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From igor.veresov at oracle.com Tue Apr 25 17:38:42 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 25 Apr 2017 10:38:42 -0700 Subject: RFR(M) 8179100: [AOT] Rewrite redundant initialization elimination In-Reply-To: References: <52eb066a-9629-3737-bbba-a1f1bc9931af@oracle.com> Message-ID: Tom suggested to use data flow to do this. Otherwise I was missing the case when initialization happen on both paths of a diamond. So, no scheduling this time, only walking the control flow. Here?s the new review: http://cr.openjdk.java.net/~iveresov/8179100/webrev.01 igor > On Apr 21, 2017, at 4:34 PM, Vladimir Kozlov wrote: > > Okay. > > Thanks, > Vladimir > > On 4/21/17 3:57 PM, Igor Veresov wrote: >> >>> On Apr 21, 2017, at 3:27 PM, Vladimir Kozlov wrote: >>> >>> On 4/21/17 1:55 PM, Igor Veresov wrote: >>>> Redundant initialization elimination can be rewritten using the dominator tree visitor pattern. This makes code much more readable. It also now handle the case of the dominating initialization of a subclass. And since now we have more time the phase requires a unit test. >>> >>> I don't see unit test. >> >> Yeah, forgot it, webrev updated in-place. >> >> igor >> >>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8179100/webrev.00 >>> >>> Seems good. But I assume Graal guys will review it too. >>> >>>> (It?s a complete rewrite, so don?t look at the diffs, they are messy). >>> >>> Thank you for warning ;) >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> I?ll be pushing this through graal-core and doing a graal update after that. >>>> >>>> igor >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Apr 25 18:13:18 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Apr 2017 11:13:18 -0700 Subject: RFR(M) 8179100: [AOT] Rewrite redundant initialization elimination In-Reply-To: References: <52eb066a-9629-3737-bbba-a1f1bc9931af@oracle.com> Message-ID: <99a11b76-42f5-58b4-44e9-3334e418b690@oracle.com> Good. Thanks, Vladimir On 4/25/17 10:38 AM, Igor Veresov wrote: > Tom suggested to use data flow to do this. Otherwise I was missing the > case when initialization happen on both paths of a diamond. > So, no scheduling this time, only walking the control flow. > > Here?s the new > review: http://cr.openjdk.java.net/~iveresov/8179100/webrev.01 > > igor > >> On Apr 21, 2017, at 4:34 PM, Vladimir Kozlov >> > wrote: >> >> Okay. >> >> Thanks, >> Vladimir >> >> On 4/21/17 3:57 PM, Igor Veresov wrote: >>> >>>> On Apr 21, 2017, at 3:27 PM, Vladimir Kozlov >>>> > wrote: >>>> >>>> On 4/21/17 1:55 PM, Igor Veresov wrote: >>>>> Redundant initialization elimination can be rewritten using the >>>>> dominator tree visitor pattern. This makes code much more readable. >>>>> It also now handle the case of the dominating initialization of a >>>>> subclass. And since now we have more time the phase requires a unit >>>>> test. >>>> >>>> I don't see unit test. >>> >>> Yeah, forgot it, webrev updated in-place. >>> >>> igor >>> >>>> >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8179100/webrev.00 >>>> >>>> Seems good. But I assume Graal guys will review it too. >>>> >>>>> (It?s a complete rewrite, so don?t look at the diffs, they are messy). >>>> >>>> Thank you for warning ;) >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> I?ll be pushing this through graal-core and doing a graal update >>>>> after that. >>>>> >>>>> igor >>>>> >>> > From zoltan.majo at oracle.com Wed Apr 26 12:15:44 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 26 Apr 2017 14:15:44 +0200 Subject: [1] RFR (S) 8179019: Correct range checks for command-line options ArraycopySrcPrefetchDistance and ArraycopyDstPrefetchDistance In-Reply-To: <1515d4fa-c214-8b64-8267-ba151fff80c7@oracle.com> References: <1515d4fa-c214-8b64-8267-ba151fff80c7@oracle.com> Message-ID: <9e58d901-534e-40f2-85a8-a46f8e738b16@oracle.com> Hi Vladimir, testing on all JPRT platforms (previously I tested only on SPARC) revealed a small problem. The flags we're checking are *unsigned* ints, therefore in commandLineFlagConstraintsCompiler.cpp it is sufficient to check if (value >= 4032) { instead of if (value < 0 || value >= 4032) { The change is necessary to make gcc happy on linux_arm. (The '< 0' part of the check is anyway performed when the value is read -- I verified). Here's the updated webrev, please take a look: http://cr.openjdk.java.net/~zmajo/8179019/webrev.01/ I re-tested with JPRT and did also some manual testing. Thank you! Best regards, Zoltan On 04/25/2017 09:34 AM, Vladimir Kozlov wrote: > Good. > > Thanks, > vladimir > > On 4/24/17 8:20 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following fix for 8179019. >> https://bugs.openjdk.java.net/browse/JDK-8179019 >> http://cr.openjdk.java.net/~zmajo/8179019/webrev.00/ >> >> Currently, the HotSpot allows Arraycopy{Src|Dst}PrefetchDistance only >> one value. Before JDK-8078554, values in the interval [0, 4096] were >> allowed (without explicit checking, though). >> >> This change extends the set of values allowed to the interval [0, 4031]. >> We need the high bound 4032 (instead of 4096) because of [1]: the >> largest value of offset is 64, so 4031 + 64 = 4095 is the maximum that >> fits into the signed range of 13 bits. The change also includes >> suggestions by Vladimir K [2] to avoid using too large immediate values. >> >> I tested the change manually with some values from both ends of the >> range and also with JPRT (incl. the currently disabled >> TestOptionsWithRanges.java test). >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> [1] >> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/1617b39a1ae4/src/cpu/sparc/vm/stubGenerator_sparc.cpp#l2128 >> >> >> [2] >> https://bugs.openjdk.java.net/browse/JDK-8179019?focusedCommentId=14071776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14071776 >> >> >> From vladimir.kozlov at oracle.com Wed Apr 26 17:09:54 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Apr 2017 10:09:54 -0700 Subject: [1] RFR (S) 8179019: Correct range checks for command-line options ArraycopySrcPrefetchDistance and ArraycopyDstPrefetchDistance In-Reply-To: <9e58d901-534e-40f2-85a8-a46f8e738b16@oracle.com> References: <1515d4fa-c214-8b64-8267-ba151fff80c7@oracle.com> <9e58d901-534e-40f2-85a8-a46f8e738b16@oracle.com> Message-ID: <8940ea11-ec54-3254-a0d8-bd4558f0764d@oracle.com> On 4/26/17 5:15 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > testing on all JPRT platforms (previously I tested only on SPARC) > revealed a small problem. > > The flags we're checking are *unsigned* ints, therefore in > commandLineFlagConstraintsCompiler.cpp it is sufficient to check > > if (value >= 4032) { okay > > instead of > > if (value < 0 || value >= 4032) { > > The change is necessary to make gcc happy on linux_arm. (The '< 0' part > of the check is anyway performed when the value is read -- I verified). > > Here's the updated webrev, please take a look: > http://cr.openjdk.java.net/~zmajo/8179019/webrev.01/ Good. Thanks, Vladimir > > I re-tested with JPRT and did also some manual testing. > > Thank you! > > Best regards, > > > Zoltan > > On 04/25/2017 09:34 AM, Vladimir Kozlov wrote: >> Good. >> >> Thanks, >> vladimir >> >> On 4/24/17 8:20 AM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the following fix for 8179019. >>> https://bugs.openjdk.java.net/browse/JDK-8179019 >>> http://cr.openjdk.java.net/~zmajo/8179019/webrev.00/ >>> >>> Currently, the HotSpot allows Arraycopy{Src|Dst}PrefetchDistance only >>> one value. Before JDK-8078554, values in the interval [0, 4096] were >>> allowed (without explicit checking, though). >>> >>> This change extends the set of values allowed to the interval [0, 4031]. >>> We need the high bound 4032 (instead of 4096) because of [1]: the >>> largest value of offset is 64, so 4031 + 64 = 4095 is the maximum that >>> fits into the signed range of 13 bits. The change also includes >>> suggestions by Vladimir K [2] to avoid using too large immediate values. >>> >>> I tested the change manually with some values from both ends of the >>> range and also with JPRT (incl. the currently disabled >>> TestOptionsWithRanges.java test). >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> [1] >>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/1617b39a1ae4/src/cpu/sparc/vm/stubGenerator_sparc.cpp#l2128 >>> >>> >>> [2] >>> https://bugs.openjdk.java.net/browse/JDK-8179019?focusedCommentId=14071776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14071776 >>> >>> >>> > From zoltan.majo at oracle.com Thu Apr 27 14:38:43 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 27 Apr 2017 16:38:43 +0200 Subject: [1] RFR (S) 8179019: Correct range checks for command-line options ArraycopySrcPrefetchDistance and ArraycopyDstPrefetchDistance In-Reply-To: <8940ea11-ec54-3254-a0d8-bd4558f0764d@oracle.com> References: <1515d4fa-c214-8b64-8267-ba151fff80c7@oracle.com> <9e58d901-534e-40f2-85a8-a46f8e738b16@oracle.com> <8940ea11-ec54-3254-a0d8-bd4558f0764d@oracle.com> Message-ID: <848ee007-599f-5aa6-edee-becc39d7a0ce@oracle.com> Hi Vladimir, On 04/26/2017 07:09 PM, Vladimir Kozlov wrote: > On 4/26/17 5:15 AM, Zolt?n Maj? wrote: >> [...] >> Here's the updated webrev, please take a look: >> http://cr.openjdk.java.net/~zmajo/8179019/webrev.01/ > > Good. Thank you for the review! Best regards, Zoltan > > > Thanks, > Vladimir > >> >> I re-tested with JPRT and did also some manual testing. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> On 04/25/2017 09:34 AM, Vladimir Kozlov wrote: >>> Good. >>> >>> Thanks, >>> vladimir >>> >>> On 4/24/17 8:20 AM, Zolt?n Maj? wrote: >>>> Hi, >>>> >>>> >>>> please review the following fix for 8179019. >>>> https://bugs.openjdk.java.net/browse/JDK-8179019 >>>> http://cr.openjdk.java.net/~zmajo/8179019/webrev.00/ >>>> >>>> Currently, the HotSpot allows Arraycopy{Src|Dst}PrefetchDistance only >>>> one value. Before JDK-8078554, values in the interval [0, 4096] were >>>> allowed (without explicit checking, though). >>>> >>>> This change extends the set of values allowed to the interval [0, >>>> 4031]. >>>> We need the high bound 4032 (instead of 4096) because of [1]: the >>>> largest value of offset is 64, so 4031 + 64 = 4095 is the maximum that >>>> fits into the signed range of 13 bits. The change also includes >>>> suggestions by Vladimir K [2] to avoid using too large immediate >>>> values. >>>> >>>> I tested the change manually with some values from both ends of the >>>> range and also with JPRT (incl. the currently disabled >>>> TestOptionsWithRanges.java test). >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/1617b39a1ae4/src/cpu/sparc/vm/stubGenerator_sparc.cpp#l2128 >>>> >>>> >>>> >>>> [2] >>>> https://bugs.openjdk.java.net/browse/JDK-8179019?focusedCommentId=14071776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14071776 >>>> >>>> >>>> >>>> >> From doug.simon at oracle.com Thu Apr 27 14:47:53 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 27 Apr 2017 16:47:53 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> Message-ID: <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> > On 21 Apr 2017, at 13:46, Doug Simon wrote: > > There has been some discussion about whether we want to update Graal in the JDK at this late stage. The main (only?) risk is a regression in the AOT tool. > > If we don't update Graal from upstream, then the qualified exports from JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in addition to updating Graal to remove the qualified exports, there would also need to be changes in the relevant make files to add --add-exports options when compiling Graal and jaotc as they use the dynamically exported JVMCI packages. > > I have an updated hotspot patch that adapts Graal to the JVMCI API changes: > > http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/ > > Note that this patch does not include the changes removing use of JDK internal API from Graal. Cherry picking those upstream Graal changes would be more work than simply doing a complete update from upstream Graal. > > As I see it, there are 2 options here: > > 1. Go with the current webrev (including hotspot.02 patch) and live with the qualified exports. > 2. Go with the current webrev (including hotspot.02 patch) and create a follow up bug to update Graal from upstream, perform the relevant make file changes and remove the qualified exports. I made a new webrev[1] that implements option 1.5 ;-) The changes added since the first webrev[2] are: - Cherry picked changes from upstream Graal that remove use of JDK internals. - The jdk.internal.vm.ci.enabled system property is set to true in arguments.cpp[3] iff EnableJVMCI is true and this property is checked in all the public methods in jdk.vm.ci.services. - The jdk.vm.ci.services package is (once again) only exported to jdk.internal.vm.compiler based on advice from the jigsaw team: "We reviewed the unqualified export jdk.vm.ci.services from jdk.internal.vm.ci module. This brings jdk.internal.vm.ci to be resolved by default that of course may resolve additional modules that provides the services that JVMCI uses. In addition. JVMCI is meant to be used (only) when -XX:+EnableJVMCI is specified but now it?s defined by default. An internal module should only have qualified exports as a design principle. The Lab Graal will have the same module name, jdk.internal.vm.compiler. The advise is to keep it as qualified export `exports jdk.vm.ci.services to jdk.internal.vm.compiler` and remove all other qualified exports as we discussed." - The jaotc launcher now needs to explicitly export JVMCI and jdk.internal.vm.compiler to jdk.aot[4]. Unfortunately there needs to be one --add-exports option per qualified export target as combining them with a comma (e.g., --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot) breaks the make process: Launcher-jdk.aot.gmk:31: *** missing separator. Stop. make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed. The latest webrev has been tested against upstream Graal, the closed AOT tests and jprt. -Doug [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 [2] http://cr.openjdk.java.net/~dnsimon/8177845 [3] http://cr.openjdk.java.net/~dnsimon/8177845.02/hotspot/src/share/vm/runtime/arguments.cpp.udiff.html [4] http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html > >> On 20 Apr 2017, at 20:50, Doug Simon wrote: >> >> I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an >> exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg >> tests to prevent Graal being selected and initialized by the JVMCI compiler auto-selection mechanism. >> Initializing Graal will currently fail with errors (see stack trace below) until Graal is updated to >> the version compatible with the JVMCI API changes. >> >> In addition to resolving the compatibility issue, explicitly selecting the "null" compiler for these >> tests better isolates them from parts of the runtime they are not aiming to test. >> >> org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217) >> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138) >> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) >> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) >> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native Method) >> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185) >> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59) >> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64) >> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125) >> at java.base/java.util.ArrayList.forEach(ArrayList.java:1378) >> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:563) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >> at java.base/java.lang.Thread.run(Thread.java:844) >> Caused by: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215) >> ... 26 more >> >> -Doug >> >>> On 19 Apr 2017, at 23:26, Doug Simon wrote: >>> >>> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: >>> >>> 1. JVMCIServiceLocator.getProvider(Class) is now protected >>> 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission >>> 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK >>> >>> -Doug >>> >>>> On 19 Apr 2017, at 23:12, Doug Simon wrote: >>>> >>>>> >>>>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>>>> >>>>>>> >>>>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>>>> >>>>>>> >>>>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>>>> >>>>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>>>> >>>>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>>>> >>>>>>> It's unqualified and no restriction in this change. >>>>>> >>>>>> The public methods currently in jdk.vm.ci.services are: >>>>>> >>>>>> 1. JVMCIServiceLocator.getProvider(Class) >>>>>> 2. JVMCIServiceLocator.getProviders(Class) >>>>>> 3. Services.initializeJVMCI() >>>>>> 4. Services.getSavedProperties() >>>>>> 5. Services.exportJVMCITo(Class) >>>>>> 6. Services.load(Class) >>>>>> 7. Services.loadSingle(Class, boolean) >>>>>> >>>>>> 1 should be made protected. I'll update the webrev with this change. >>>>> >>>>> Good. >>>>> >>>>>> >>>>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>>>> >>>>> Good. >>>>> >>>>>> >>>>>> 3 is harmless from a security perspective in my opinion. >>>>> >>>>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >>>> >>>> Vladimir, can you please bring this to the attention of the relevant engineer. >>>> >>>>>> >>>>>> 4 checks for JVMCIPermission. >>>>> >>>>> Ok. >>>>> >>>>>> >>>>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>>>> >>>>> About this, will this Graal update happen for JDK 9? >>>> >>>> Yes. >>>> >>>>> It?s awfully late in the cycle... >>>> >>>> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >>>> >>>> -Doug >>> >> > From Alan.Bateman at oracle.com Thu Apr 27 15:40:54 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Apr 2017 16:40:54 +0100 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> Message-ID: <18ba3d88-1fa0-7d89-d57b-043cea141722@oracle.com> On 27/04/2017 15:47, Doug Simon wrote: > : > > - The jaotc launcher now needs to explicitly export JVMCI and jdk.internal.vm.compiler to jdk.aot[4]. > Unfortunately there needs to be one --add-exports option per qualified export target as combining > them with a comma (e.g., --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot) > breaks the make process: > > Launcher-jdk.aot.gmk:31: *** missing separator. Stop. > make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed. > `--add-exports` is accumulative so what you have is okay. Alternatively the build has CommaList to convert space separated lists into comma separated lists so I would expect this should work: --add-exports=jdk.internal.vm.ci/jdk.vm.ci.amd64=$(call CommaList, jdk.internal.vm.compiler jdk.aot) -Alan From doug.simon at oracle.com Thu Apr 27 15:42:56 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 27 Apr 2017 17:42:56 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <18ba3d88-1fa0-7d89-d57b-043cea141722@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> <18ba3d88-1fa0-7d89-d57b-043cea141722@oracle.com> Message-ID: <4E03F554-1596-497B-A972-469782AAB12C@oracle.com> > On 27 Apr 2017, at 17:40, Alan Bateman wrote: > > On 27/04/2017 15:47, Doug Simon wrote: > >> : >> >> - The jaotc launcher now needs to explicitly export JVMCI and jdk.internal.vm.compiler to jdk.aot[4]. >> Unfortunately there needs to be one --add-exports option per qualified export target as combining >> them with a comma (e.g., --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot) >> breaks the make process: >> >> Launcher-jdk.aot.gmk:31: *** missing separator. Stop. >> make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed. >> > `--add-exports` is accumulative so what you have is okay. Yes, it seems to work so I'm going to leave it as is. > Alternatively the build has CommaList to convert space separated lists into comma separated lists so I would expect this should work: > > --add-exports=jdk.internal.vm.ci/jdk.vm.ci.amd64=$(call CommaList, jdk.internal.vm.compiler jdk.aot) Thanks. Good to know in the future. -Doug From cthalinger at twitter.com Thu Apr 27 16:44:09 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 27 Apr 2017 09:44:09 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> Message-ID: Thanks for doing this. I have a hard time following what?s happening :-) src/jdk.internal.vm.compiler/.mx.graal/suite.py + "jdklibraries" : { + "JVMCI_SERVICES" : { + "path" : "lib/jvmci-services.jar", + "sourcePath" : "lib/jvmci-services.src.zip", + "optional" : False, + "jdkStandardizedSince" : "9", + "module" : "jdk.internal.vm.ci" + }, + "JVMCI_API" : { + "path" : "lib/jvmci/jvmci-api.jar", + "sourcePath" : "lib/jvmci/jvmci-api.src.zip", + "dependencies" : [ + "JVMCI_SERVICES", + ], + "optional" : False, + "jdkStandardizedSince" : "9", + "module" : "jdk.internal.vm.ci" + }, + "JVMCI_HOTSPOT" : { + "path" : "lib/jvmci/jvmci-hotspot.jar", + "sourcePath" : "lib/jvmci/jvmci-hotspot.src.zip", + "dependencies" : [ + "JVMCI_API", + ], + "optional" : False, + "jdkStandardizedSince" : "9", + "module" : "jdk.internal.vm.ci" + }, + }, Can you explain to me why we need this? I don?t think these files are built in 9. src/jdk.internal.vm.ci/share/classes/module-info.java Why can we remove the exports to jdk.internal.vm.compiler? Because of this in JVMCIServiceLocator: + ReflectionAccessJDK.openJVMCITo(getClass()); ? > On Apr 27, 2017, at 7:47 AM, Doug Simon wrote: > >> >> On 21 Apr 2017, at 13:46, Doug Simon wrote: >> >> There has been some discussion about whether we want to update Graal in the JDK at this late stage. The main (only?) risk is a regression in the AOT tool. >> >> If we don't update Graal from upstream, then the qualified exports from JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in addition to updating Graal to remove the qualified exports, there would also need to be changes in the relevant make files to add --add-exports options when compiling Graal and jaotc as they use the dynamically exported JVMCI packages. >> >> I have an updated hotspot patch that adapts Graal to the JVMCI API changes: >> >> http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/ >> >> Note that this patch does not include the changes removing use of JDK internal API from Graal. Cherry picking those upstream Graal changes would be more work than simply doing a complete update from upstream Graal. >> >> As I see it, there are 2 options here: >> >> 1. Go with the current webrev (including hotspot.02 patch) and live with the qualified exports. >> 2. Go with the current webrev (including hotspot.02 patch) and create a follow up bug to update Graal from upstream, perform the relevant make file changes and remove the qualified exports. > > I made a new webrev[1] that implements option 1.5 ;-) The changes added since the first webrev[2] are: > > - Cherry picked changes from upstream Graal that remove use of JDK internals. > > - The jdk.internal.vm.ci.enabled system property is set to true in arguments.cpp[3] iff EnableJVMCI is true > and this property is checked in all the public methods in jdk.vm.ci.services. > > - The jdk.vm.ci.services package is (once again) only exported to jdk.internal.vm.compiler based on > advice from the jigsaw team: > > "We reviewed the unqualified export jdk.vm.ci.services from jdk.internal.vm.ci module. This brings > jdk.internal.vm.ci to be resolved by default that of course may resolve additional modules that > provides the services that JVMCI uses. In addition. JVMCI is meant to be used (only) when > -XX:+EnableJVMCI is specified but now it?s defined by default. > > An internal module should only have qualified exports as a design principle. The Lab Graal will > have the same module name, jdk.internal.vm.compiler. The advise is to keep it as qualified export > `exports jdk.vm.ci.services to jdk.internal.vm.compiler` and remove all other qualified exports as > we discussed." > > - The jaotc launcher now needs to explicitly export JVMCI and jdk.internal.vm.compiler to jdk.aot[4]. > Unfortunately there needs to be one --add-exports option per qualified export target as combining > them with a comma (e.g., --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot) > breaks the make process: > > Launcher-jdk.aot.gmk:31: *** missing separator. Stop. > make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed. > > The latest webrev has been tested against upstream Graal, the closed AOT tests and jprt. > > -Doug > > [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 > [2] http://cr.openjdk.java.net/~dnsimon/8177845 > [3] http://cr.openjdk.java.net/~dnsimon/8177845.02/hotspot/src/share/vm/runtime/arguments.cpp.udiff.html > [4] http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html > >> >>> On 20 Apr 2017, at 20:50, Doug Simon wrote: >>> >>> I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an >>> exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg >>> tests to prevent Graal being selected and initialized by the JVMCI compiler auto-selection mechanism. >>> Initializing Graal will currently fail with errors (see stack trace below) until Graal is updated to >>> the version compatible with the JVMCI API changes. >>> >>> In addition to resolving the compatibility issue, explicitly selecting the "null" compiler for these >>> tests better isolates them from parts of the runtime they are not aiming to test. >>> >>> org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217) >>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138) >>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) >>> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) >>> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native Method) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185) >>> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59) >>> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64) >>> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125) >>> at java.base/java.util.ArrayList.forEach(ArrayList.java:1378) >>> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:563) >>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >>> at java.base/java.lang.Thread.run(Thread.java:844) >>> Caused by: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215) >>> ... 26 more >>> >>> -Doug >>> >>>> On 19 Apr 2017, at 23:26, Doug Simon wrote: >>>> >>>> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: >>>> >>>> 1. JVMCIServiceLocator.getProvider(Class) is now protected >>>> 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission >>>> 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK >>>> >>>> -Doug >>>> >>>>> On 19 Apr 2017, at 23:12, Doug Simon wrote: >>>>> >>>>>> >>>>>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>>>>> >>>>>>> >>>>>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>>>>> >>>>>>>> >>>>>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>>>>> >>>>>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>>>>> >>>>>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>>>>> >>>>>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>>>>> >>>>>>>> It's unqualified and no restriction in this change. >>>>>>> >>>>>>> The public methods currently in jdk.vm.ci.services are: >>>>>>> >>>>>>> 1. JVMCIServiceLocator.getProvider(Class) >>>>>>> 2. JVMCIServiceLocator.getProviders(Class) >>>>>>> 3. Services.initializeJVMCI() >>>>>>> 4. Services.getSavedProperties() >>>>>>> 5. Services.exportJVMCITo(Class) >>>>>>> 6. Services.load(Class) >>>>>>> 7. Services.loadSingle(Class, boolean) >>>>>>> >>>>>>> 1 should be made protected. I'll update the webrev with this change. >>>>>> >>>>>> Good. >>>>>> >>>>>>> >>>>>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>>>>> >>>>>> Good. >>>>>> >>>>>>> >>>>>>> 3 is harmless from a security perspective in my opinion. >>>>>> >>>>>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >>>>> >>>>> Vladimir, can you please bring this to the attention of the relevant engineer. >>>>> >>>>>>> >>>>>>> 4 checks for JVMCIPermission. >>>>>> >>>>>> Ok. >>>>>> >>>>>>> >>>>>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>>>>> >>>>>> About this, will this Graal update happen for JDK 9? >>>>> >>>>> Yes. >>>>> >>>>>> It?s awfully late in the cycle... >>>>> >>>>> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >>>>> >>>>> -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Thu Apr 27 18:51:43 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 27 Apr 2017 20:51:43 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> Message-ID: <70D315B0-38E8-444C-AC89-897263638D4F@oracle.com> > On 27 Apr 2017, at 18:44, Christian Thalinger wrote: > > Thanks for doing this. I have a hard time following what?s happening :-) > > src/jdk.internal.vm.compiler/.mx.graal/suite.py > > + "jdklibraries" : { > + "JVMCI_SERVICES" : { > + "path" : "lib/jvmci-services.jar", > + "sourcePath" : "lib/jvmci-services.src.zip", > + "optional" : False, > + "jdkStandardizedSince" : "9", > + "module" : "jdk.internal.vm.ci" > + }, > + "JVMCI_API" : { > + "path" : "lib/jvmci/jvmci-api.jar", > + "sourcePath" : "lib/jvmci/jvmci-api.src.zip", > + "dependencies" : [ > + "JVMCI_SERVICES", > + ], > + "optional" : False, > + "jdkStandardizedSince" : "9", > + "module" : "jdk.internal.vm.ci" > + }, > + "JVMCI_HOTSPOT" : { > + "path" : "lib/jvmci/jvmci-hotspot.jar", > + "sourcePath" : "lib/jvmci/jvmci-hotspot.src.zip", > + "dependencies" : [ > + "JVMCI_API", > + ], > + "optional" : False, > + "jdkStandardizedSince" : "9", > + "module" : "jdk.internal.vm.ci" > + }, > + }, > > Can you explain to me why we need this? I don?t think these files are built in 9. This simply allows `mx eclipseinit` to work when wanting to edit the JDK Graal sources in Eclipse. As you state, this is completely by-passed by the JDK make system. > > src/jdk.internal.vm.ci/share/classes/module-info.java > > Why can we remove the exports to jdk.internal.vm.compiler? Because of this in JVMCIServiceLocator: > > + ReflectionAccessJDK.openJVMCITo(getClass()); Yes. And the --add-exports in CompileJavaModules.gmk[1] and Launcher-jdk.aot.gmk[2]. It also means these VM options are required in upstream Graal when running the Graal junit tests. -Doug [1] http://cr.openjdk.java.net/~dnsimon/8177845.02/make/make/CompileJavaModules.gmk.udiff.html [2] http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html > > ? > >> On Apr 27, 2017, at 7:47 AM, Doug Simon wrote: >> >>> >>> On 21 Apr 2017, at 13:46, Doug Simon wrote: >>> >>> There has been some discussion about whether we want to update Graal in the JDK at this late stage. The main (only?) risk is a regression in the AOT tool. >>> >>> If we don't update Graal from upstream, then the qualified exports from JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in addition to updating Graal to remove the qualified exports, there would also need to be changes in the relevant make files to add --add-exports options when compiling Graal and jaotc as they use the dynamically exported JVMCI packages. >>> >>> I have an updated hotspot patch that adapts Graal to the JVMCI API changes: >>> >>> http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/ >>> >>> Note that this patch does not include the changes removing use of JDK internal API from Graal. Cherry picking those upstream Graal changes would be more work than simply doing a complete update from upstream Graal. >>> >>> As I see it, there are 2 options here: >>> >>> 1. Go with the current webrev (including hotspot.02 patch) and live with the qualified exports. >>> 2. Go with the current webrev (including hotspot.02 patch) and create a follow up bug to update Graal from upstream, perform the relevant make file changes and remove the qualified exports. >> >> I made a new webrev[1] that implements option 1.5 ;-) The changes added since the first webrev[2] are: >> >> - Cherry picked changes from upstream Graal that remove use of JDK internals. >> >> - The jdk.internal.vm.ci.enabled system property is set to true in arguments.cpp[3] iff EnableJVMCI is true >> and this property is checked in all the public methods in jdk.vm.ci.services. >> >> - The jdk.vm.ci.services package is (once again) only exported to jdk.internal.vm.compiler based on >> advice from the jigsaw team: >> >> "We reviewed the unqualified export jdk.vm.ci.services from jdk.internal.vm.ci module. This brings >> jdk.internal.vm.ci to be resolved by default that of course may resolve additional modules that >> provides the services that JVMCI uses. In addition. JVMCI is meant to be used (only) when >> -XX:+EnableJVMCI is specified but now it?s defined by default. >> >> An internal module should only have qualified exports as a design principle. The Lab Graal will >> have the same module name, jdk.internal.vm.compiler. The advise is to keep it as qualified export >> `exports jdk.vm.ci.services to jdk.internal.vm.compiler` and remove all other qualified exports as >> we discussed." >> >> - The jaotc launcher now needs to explicitly export JVMCI and jdk.internal.vm.compiler to jdk.aot[4]. >> Unfortunately there needs to be one --add-exports option per qualified export target as combining >> them with a comma (e.g., --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot) >> breaks the make process: >> >> Launcher-jdk.aot.gmk:31: *** missing separator. Stop. >> make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed. >> >> The latest webrev has been tested against upstream Graal, the closed AOT tests and jprt. >> >> -Doug >> >> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 >> [2] http://cr.openjdk.java.net/~dnsimon/8177845 >> [3] http://cr.openjdk.java.net/~dnsimon/8177845.02/hotspot/src/share/vm/runtime/arguments.cpp.udiff.html >> [4] http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html >> >>> >>>> On 20 Apr 2017, at 20:50, Doug Simon wrote: >>>> >>>> I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an >>>> exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg >>>> tests to prevent Graal being selected and initialized by the JVMCI compiler auto-selection mechanism. >>>> Initializing Graal will currently fail with errors (see stack trace below) until Graal is updated to >>>> the version compatible with the JVMCI API changes. >>>> >>>> In addition to resolving the compatibility issue, explicitly selecting the "null" compiler for these >>>> tests better isolates them from parts of the runtime they are not aiming to test. >>>> >>>> org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217) >>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138) >>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) >>>> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) >>>> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native Method) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185) >>>> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59) >>>> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64) >>>> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125) >>>> at java.base/java.util.ArrayList.forEach(ArrayList.java:1378) >>>> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71) >>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.base/java.lang.reflect.Method.invoke(Method.java:563) >>>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>> Caused by: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215) >>>> ... 26 more >>>> >>>> -Doug >>>> >>>>> On 19 Apr 2017, at 23:26, Doug Simon wrote: >>>>> >>>>> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: >>>>> >>>>> 1. JVMCIServiceLocator.getProvider(Class) is now protected >>>>> 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission >>>>> 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK >>>>> >>>>> -Doug >>>>> >>>>>> On 19 Apr 2017, at 23:12, Doug Simon wrote: >>>>>> >>>>>>> >>>>>>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>>>>>> >>>>>>>> >>>>>>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>>>>>> >>>>>>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>>>>>> >>>>>>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>>>>>> >>>>>>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>>>>>> >>>>>>>>> It's unqualified and no restriction in this change. >>>>>>>> >>>>>>>> The public methods currently in jdk.vm.ci.services are: >>>>>>>> >>>>>>>> 1. JVMCIServiceLocator.getProvider(Class) >>>>>>>> 2. JVMCIServiceLocator.getProviders(Class) >>>>>>>> 3. Services.initializeJVMCI() >>>>>>>> 4. Services.getSavedProperties() >>>>>>>> 5. Services.exportJVMCITo(Class) >>>>>>>> 6. Services.load(Class) >>>>>>>> 7. Services.loadSingle(Class, boolean) >>>>>>>> >>>>>>>> 1 should be made protected. I'll update the webrev with this change. >>>>>>> >>>>>>> Good. >>>>>>> >>>>>>>> >>>>>>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>>>>>> >>>>>>> Good. >>>>>>> >>>>>>>> >>>>>>>> 3 is harmless from a security perspective in my opinion. >>>>>>> >>>>>>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >>>>>> >>>>>> Vladimir, can you please bring this to the attention of the relevant engineer. >>>>>> >>>>>>>> >>>>>>>> 4 checks for JVMCIPermission. >>>>>>> >>>>>>> Ok. >>>>>>> >>>>>>>> >>>>>>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>>>>>> >>>>>>> About this, will this Graal update happen for JDK 9? >>>>>> >>>>>> Yes. >>>>>> >>>>>>> It?s awfully late in the cycle... >>>>>> >>>>>> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >>>>>> >>>>>> -Doug > From cthalinger at twitter.com Thu Apr 27 18:53:29 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 27 Apr 2017 11:53:29 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <70D315B0-38E8-444C-AC89-897263638D4F@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> <70D315B0-38E8-444C-AC89-897263638D4F@oracle.com> Message-ID: <0FCF026F-AB78-4D1C-857B-667FB7FA7FCA@twitter.com> > On Apr 27, 2017, at 11:51 AM, Doug Simon wrote: > >> >> On 27 Apr 2017, at 18:44, Christian Thalinger wrote: >> >> Thanks for doing this. I have a hard time following what?s happening :-) >> >> src/jdk.internal.vm.compiler/.mx.graal/suite.py >> >> + "jdklibraries" : { >> + "JVMCI_SERVICES" : { >> + "path" : "lib/jvmci-services.jar", >> + "sourcePath" : "lib/jvmci-services.src.zip", >> + "optional" : False, >> + "jdkStandardizedSince" : "9", >> + "module" : "jdk.internal.vm.ci" >> + }, >> + "JVMCI_API" : { >> + "path" : "lib/jvmci/jvmci-api.jar", >> + "sourcePath" : "lib/jvmci/jvmci-api.src.zip", >> + "dependencies" : [ >> + "JVMCI_SERVICES", >> + ], >> + "optional" : False, >> + "jdkStandardizedSince" : "9", >> + "module" : "jdk.internal.vm.ci" >> + }, >> + "JVMCI_HOTSPOT" : { >> + "path" : "lib/jvmci/jvmci-hotspot.jar", >> + "sourcePath" : "lib/jvmci/jvmci-hotspot.src.zip", >> + "dependencies" : [ >> + "JVMCI_API", >> + ], >> + "optional" : False, >> + "jdkStandardizedSince" : "9", >> + "module" : "jdk.internal.vm.ci" >> + }, >> + }, >> >> Can you explain to me why we need this? I don?t think these files are built in 9. > > This simply allows `mx eclipseinit` to work when wanting to edit the JDK Graal sources in Eclipse. As you state, this is completely by-passed by the JDK make system. Got it. > >> >> src/jdk.internal.vm.ci/share/classes/module-info.java >> >> Why can we remove the exports to jdk.internal.vm.compiler? Because of this in JVMCIServiceLocator: >> >> + ReflectionAccessJDK.openJVMCITo(getClass()); > > Yes. And the --add-exports in CompileJavaModules.gmk[1] and Launcher-jdk.aot.gmk[2]. It also means these VM options are required in upstream Graal when running the Graal junit tests. Ok, thanks. > > -Doug > > [1] http://cr.openjdk.java.net/~dnsimon/8177845.02/make/make/CompileJavaModules.gmk.udiff.html > [2] http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html > >> >> ? >> >>> On Apr 27, 2017, at 7:47 AM, Doug Simon wrote: >>> >>>> >>>> On 21 Apr 2017, at 13:46, Doug Simon wrote: >>>> >>>> There has been some discussion about whether we want to update Graal in the JDK at this late stage. The main (only?) risk is a regression in the AOT tool. >>>> >>>> If we don't update Graal from upstream, then the qualified exports from JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in addition to updating Graal to remove the qualified exports, there would also need to be changes in the relevant make files to add --add-exports options when compiling Graal and jaotc as they use the dynamically exported JVMCI packages. >>>> >>>> I have an updated hotspot patch that adapts Graal to the JVMCI API changes: >>>> >>>> http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/ >>>> >>>> Note that this patch does not include the changes removing use of JDK internal API from Graal. Cherry picking those upstream Graal changes would be more work than simply doing a complete update from upstream Graal. >>>> >>>> As I see it, there are 2 options here: >>>> >>>> 1. Go with the current webrev (including hotspot.02 patch) and live with the qualified exports. >>>> 2. Go with the current webrev (including hotspot.02 patch) and create a follow up bug to update Graal from upstream, perform the relevant make file changes and remove the qualified exports. >>> >>> I made a new webrev[1] that implements option 1.5 ;-) The changes added since the first webrev[2] are: >>> >>> - Cherry picked changes from upstream Graal that remove use of JDK internals. >>> >>> - The jdk.internal.vm.ci.enabled system property is set to true in arguments.cpp[3] iff EnableJVMCI is true >>> and this property is checked in all the public methods in jdk.vm.ci.services. >>> >>> - The jdk.vm.ci.services package is (once again) only exported to jdk.internal.vm.compiler based on >>> advice from the jigsaw team: >>> >>> "We reviewed the unqualified export jdk.vm.ci.services from jdk.internal.vm.ci module. This brings >>> jdk.internal.vm.ci to be resolved by default that of course may resolve additional modules that >>> provides the services that JVMCI uses. In addition. JVMCI is meant to be used (only) when >>> -XX:+EnableJVMCI is specified but now it?s defined by default. >>> >>> An internal module should only have qualified exports as a design principle. The Lab Graal will >>> have the same module name, jdk.internal.vm.compiler. The advise is to keep it as qualified export >>> `exports jdk.vm.ci.services to jdk.internal.vm.compiler` and remove all other qualified exports as >>> we discussed." >>> >>> - The jaotc launcher now needs to explicitly export JVMCI and jdk.internal.vm.compiler to jdk.aot[4]. >>> Unfortunately there needs to be one --add-exports option per qualified export target as combining >>> them with a comma (e.g., --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot) >>> breaks the make process: >>> >>> Launcher-jdk.aot.gmk:31: *** missing separator. Stop. >>> make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed. >>> >>> The latest webrev has been tested against upstream Graal, the closed AOT tests and jprt. >>> >>> -Doug >>> >>> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 >>> [2] http://cr.openjdk.java.net/~dnsimon/8177845 >>> [3] http://cr.openjdk.java.net/~dnsimon/8177845.02/hotspot/src/share/vm/runtime/arguments.cpp.udiff.html >>> [4] http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html >>> >>>> >>>>> On 20 Apr 2017, at 20:50, Doug Simon wrote: >>>>> >>>>> I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an >>>>> exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg >>>>> tests to prevent Graal being selected and initialized by the JVMCI compiler auto-selection mechanism. >>>>> Initializing Graal will currently fail with errors (see stack trace below) until Graal is updated to >>>>> the version compatible with the JVMCI API changes. >>>>> >>>>> In addition to resolving the compatibility issue, explicitly selecting the "null" compiler for these >>>>> tests better isolates them from parts of the runtime they are not aiming to test. >>>>> >>>>> org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >>>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217) >>>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138) >>>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native Method) >>>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185) >>>>> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59) >>>>> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64) >>>>> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125) >>>>> at java.base/java.util.ArrayList.forEach(ArrayList.java:1378) >>>>> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71) >>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:563) >>>>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>> Caused by: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >>>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215) >>>>> ... 26 more >>>>> >>>>> -Doug >>>>> >>>>>> On 19 Apr 2017, at 23:26, Doug Simon wrote: >>>>>> >>>>>> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: >>>>>> >>>>>> 1. JVMCIServiceLocator.getProvider(Class) is now protected >>>>>> 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission >>>>>> 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK >>>>>> >>>>>> -Doug >>>>>> >>>>>>> On 19 Apr 2017, at 23:12, Doug Simon wrote: >>>>>>> >>>>>>>> >>>>>>>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>>>>>>> >>>>>>>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>>>>>>> >>>>>>>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>>>>>>> >>>>>>>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>>>>>>> >>>>>>>>>> It's unqualified and no restriction in this change. >>>>>>>>> >>>>>>>>> The public methods currently in jdk.vm.ci.services are: >>>>>>>>> >>>>>>>>> 1. JVMCIServiceLocator.getProvider(Class) >>>>>>>>> 2. JVMCIServiceLocator.getProviders(Class) >>>>>>>>> 3. Services.initializeJVMCI() >>>>>>>>> 4. Services.getSavedProperties() >>>>>>>>> 5. Services.exportJVMCITo(Class) >>>>>>>>> 6. Services.load(Class) >>>>>>>>> 7. Services.loadSingle(Class, boolean) >>>>>>>>> >>>>>>>>> 1 should be made protected. I'll update the webrev with this change. >>>>>>>> >>>>>>>> Good. >>>>>>>> >>>>>>>>> >>>>>>>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>>>>>>> >>>>>>>> Good. >>>>>>>> >>>>>>>>> >>>>>>>>> 3 is harmless from a security perspective in my opinion. >>>>>>>> >>>>>>>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >>>>>>> >>>>>>> Vladimir, can you please bring this to the attention of the relevant engineer. >>>>>>> >>>>>>>>> >>>>>>>>> 4 checks for JVMCIPermission. >>>>>>>> >>>>>>>> Ok. >>>>>>>> >>>>>>>>> >>>>>>>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>>>>>>> >>>>>>>> About this, will this Graal update happen for JDK 9? >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>> It?s awfully late in the cycle... >>>>>>> >>>>>>> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >>>>>>> >>>>>>> -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Apr 27 19:15:19 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Apr 2017 12:15:19 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> Message-ID: make/CompileJavaModules.gmk Please, adjust comment for jdk.aot: ># Don't use Indy strings concatenation to have good JVMCI startup performance. --- <# Don't use Indy strings concatenation to have good JAOTC startup performance. Should we also add jdk.vm.ci.aarch64 and jdk.vm.ci.sparc exports for AOT? It is not needed for JDK 9 but we will support them in a future and analyze build failures is painful. Same in make/launcher/Launcher-jdk.aot.gmk. I don't see changes in hotspot/make/CompileTools.gmk and hotspot/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk (which do annotation processor build): http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f1cca489e9c6/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk I assume you don't need to change anything there. Right? Overall changes looks good to me. thanks, Vladimir On 4/27/17 7:47 AM, Doug Simon wrote: > >> On 21 Apr 2017, at 13:46, Doug Simon wrote: >> >> There has been some discussion about whether we want to update Graal in the JDK at this late stage. The main (only?) risk is a regression in the AOT tool. >> >> If we don't update Graal from upstream, then the qualified exports from JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in addition to updating Graal to remove the qualified exports, there would also need to be changes in the relevant make files to add --add-exports options when compiling Graal and jaotc as they use the dynamically exported JVMCI packages. >> >> I have an updated hotspot patch that adapts Graal to the JVMCI API changes: >> >> http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/ >> >> Note that this patch does not include the changes removing use of JDK internal API from Graal. Cherry picking those upstream Graal changes would be more work than simply doing a complete update from upstream Graal. >> >> As I see it, there are 2 options here: >> >> 1. Go with the current webrev (including hotspot.02 patch) and live with the qualified exports. >> 2. Go with the current webrev (including hotspot.02 patch) and create a follow up bug to update Graal from upstream, perform the relevant make file changes and remove the qualified exports. > > I made a new webrev[1] that implements option 1.5 ;-) The changes added since the first webrev[2] are: > > - Cherry picked changes from upstream Graal that remove use of JDK internals. > > - The jdk.internal.vm.ci.enabled system property is set to true in arguments.cpp[3] iff EnableJVMCI is true > and this property is checked in all the public methods in jdk.vm.ci.services. > > - The jdk.vm.ci.services package is (once again) only exported to jdk.internal.vm.compiler based on > advice from the jigsaw team: > > "We reviewed the unqualified export jdk.vm.ci.services from jdk.internal.vm.ci module. This brings > jdk.internal.vm.ci to be resolved by default that of course may resolve additional modules that > provides the services that JVMCI uses. In addition. JVMCI is meant to be used (only) when > -XX:+EnableJVMCI is specified but now it?s defined by default. > > An internal module should only have qualified exports as a design principle. The Lab Graal will > have the same module name, jdk.internal.vm.compiler. The advise is to keep it as qualified export > `exports jdk.vm.ci.services to jdk.internal.vm.compiler` and remove all other qualified exports as > we discussed." > > - The jaotc launcher now needs to explicitly export JVMCI and jdk.internal.vm.compiler to jdk.aot[4]. > Unfortunately there needs to be one --add-exports option per qualified export target as combining > them with a comma (e.g., --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot) > breaks the make process: > > Launcher-jdk.aot.gmk:31: *** missing separator. Stop. > make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed. > > The latest webrev has been tested against upstream Graal, the closed AOT tests and jprt. > > -Doug > > [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 > [2] http://cr.openjdk.java.net/~dnsimon/8177845 > [3] http://cr.openjdk.java.net/~dnsimon/8177845.02/hotspot/src/share/vm/runtime/arguments.cpp.udiff.html > [4] http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html > >> >>> On 20 Apr 2017, at 20:50, Doug Simon wrote: >>> >>> I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an >>> exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg >>> tests to prevent Graal being selected and initialized by the JVMCI compiler auto-selection mechanism. >>> Initializing Graal will currently fail with errors (see stack trace below) until Graal is updated to >>> the version compatible with the JVMCI API changes. >>> >>> In addition to resolving the compatibility issue, explicitly selecting the "null" compiler for these >>> tests better isolates them from parts of the runtime they are not aiming to test. >>> >>> org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217) >>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138) >>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) >>> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) >>> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native Method) >>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185) >>> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59) >>> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64) >>> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125) >>> at java.base/java.util.ArrayList.forEach(ArrayList.java:1378) >>> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:563) >>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >>> at java.base/java.lang.Thread.run(Thread.java:844) >>> Caused by: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215) >>> ... 26 more >>> >>> -Doug >>> >>>> On 19 Apr 2017, at 23:26, Doug Simon wrote: >>>> >>>> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: >>>> >>>> 1. JVMCIServiceLocator.getProvider(Class) is now protected >>>> 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission >>>> 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK >>>> >>>> -Doug >>>> >>>>> On 19 Apr 2017, at 23:12, Doug Simon wrote: >>>>> >>>>>> >>>>>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>>>>> >>>>>>> >>>>>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>>>>> >>>>>>>> >>>>>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>>>>> >>>>>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>>>>> >>>>>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>>>>> >>>>>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>>>>> >>>>>>>> It's unqualified and no restriction in this change. >>>>>>> >>>>>>> The public methods currently in jdk.vm.ci.services are: >>>>>>> >>>>>>> 1. JVMCIServiceLocator.getProvider(Class) >>>>>>> 2. JVMCIServiceLocator.getProviders(Class) >>>>>>> 3. Services.initializeJVMCI() >>>>>>> 4. Services.getSavedProperties() >>>>>>> 5. Services.exportJVMCITo(Class) >>>>>>> 6. Services.load(Class) >>>>>>> 7. Services.loadSingle(Class, boolean) >>>>>>> >>>>>>> 1 should be made protected. I'll update the webrev with this change. >>>>>> >>>>>> Good. >>>>>> >>>>>>> >>>>>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>>>>> >>>>>> Good. >>>>>> >>>>>>> >>>>>>> 3 is harmless from a security perspective in my opinion. >>>>>> >>>>>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >>>>> >>>>> Vladimir, can you please bring this to the attention of the relevant engineer. >>>>> >>>>>>> >>>>>>> 4 checks for JVMCIPermission. >>>>>> >>>>>> Ok. >>>>>> >>>>>>> >>>>>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>>>>> >>>>>> About this, will this Graal update happen for JDK 9? >>>>> >>>>> Yes. >>>>> >>>>>> It?s awfully late in the cycle... >>>>> >>>>> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >>>>> >>>>> -Doug >>>> >>> >> > From doug.simon at oracle.com Thu Apr 27 19:34:45 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 27 Apr 2017 21:34:45 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> Message-ID: <8B0AC7A0-33E5-4D19-A36A-505807720A4D@oracle.com> > On 27 Apr 2017, at 21:15, Vladimir Kozlov wrote: > > make/CompileJavaModules.gmk Please, adjust comment for jdk.aot: > > ># Don't use Indy strings concatenation to have good JVMCI startup performance. > --- > <# Don't use Indy strings concatenation to have good JAOTC startup performance. > > Should we also add jdk.vm.ci.aarch64 and jdk.vm.ci.sparc exports for AOT? It is not needed for JDK 9 but we will support them in a future and analyze build failures is painful. > > Same in make/launcher/Launcher-jdk.aot.gmk. Good point. I made it the same set of exports as for jdk.internal.vm.compiler (in both locations[1][2]). > I don't see changes in hotspot/make/CompileTools.gmk and hotspot/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk (which do annotation processor build): > > http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f1cca489e9c6/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk > > I assume you don't need to change anything there. Right? I presume not as well. These sources are compiled as Java 8 sources where modules are not a concept. > Overall changes looks good to me. Thanks for the review! I'll run the Graal and AOT tests once more and then integrate this change. -Doug [1] http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html [2] http://cr.openjdk.java.net/~dnsimon/8177845.02/make/make/CompileJavaModules.gmk.udiff.html > On 4/27/17 7:47 AM, Doug Simon wrote: >> >>> On 21 Apr 2017, at 13:46, Doug Simon wrote: >>> >>> There has been some discussion about whether we want to update Graal in the JDK at this late stage. The main (only?) risk is a regression in the AOT tool. >>> >>> If we don't update Graal from upstream, then the qualified exports from JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in addition to updating Graal to remove the qualified exports, there would also need to be changes in the relevant make files to add --add-exports options when compiling Graal and jaotc as they use the dynamically exported JVMCI packages. >>> >>> I have an updated hotspot patch that adapts Graal to the JVMCI API changes: >>> >>> http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/ >>> >>> Note that this patch does not include the changes removing use of JDK internal API from Graal. Cherry picking those upstream Graal changes would be more work than simply doing a complete update from upstream Graal. >>> >>> As I see it, there are 2 options here: >>> >>> 1. Go with the current webrev (including hotspot.02 patch) and live with the qualified exports. >>> 2. Go with the current webrev (including hotspot.02 patch) and create a follow up bug to update Graal from upstream, perform the relevant make file changes and remove the qualified exports. >> >> I made a new webrev[1] that implements option 1.5 ;-) The changes added since the first webrev[2] are: >> >> - Cherry picked changes from upstream Graal that remove use of JDK internals. >> >> - The jdk.internal.vm.ci.enabled system property is set to true in arguments.cpp[3] iff EnableJVMCI is true >> and this property is checked in all the public methods in jdk.vm.ci.services. >> >> - The jdk.vm.ci.services package is (once again) only exported to jdk.internal.vm.compiler based on >> advice from the jigsaw team: >> >> "We reviewed the unqualified export jdk.vm.ci.services from jdk.internal.vm.ci module. This brings >> jdk.internal.vm.ci to be resolved by default that of course may resolve additional modules that >> provides the services that JVMCI uses. In addition. JVMCI is meant to be used (only) when >> -XX:+EnableJVMCI is specified but now it?s defined by default. >> >> An internal module should only have qualified exports as a design principle. The Lab Graal will >> have the same module name, jdk.internal.vm.compiler. The advise is to keep it as qualified export >> `exports jdk.vm.ci.services to jdk.internal.vm.compiler` and remove all other qualified exports as >> we discussed." >> >> - The jaotc launcher now needs to explicitly export JVMCI and jdk.internal.vm.compiler to jdk.aot[4]. >> Unfortunately there needs to be one --add-exports option per qualified export target as combining >> them with a comma (e.g., --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot) >> breaks the make process: >> >> Launcher-jdk.aot.gmk:31: *** missing separator. Stop. >> make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed. >> >> The latest webrev has been tested against upstream Graal, the closed AOT tests and jprt. >> >> -Doug >> >> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 >> [2] http://cr.openjdk.java.net/~dnsimon/8177845 >> [3] http://cr.openjdk.java.net/~dnsimon/8177845.02/hotspot/src/share/vm/runtime/arguments.cpp.udiff.html >> [4] http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html >> >>> >>>> On 20 Apr 2017, at 20:50, Doug Simon wrote: >>>> >>>> I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an >>>> exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg >>>> tests to prevent Graal being selected and initialized by the JVMCI compiler auto-selection mechanism. >>>> Initializing Graal will currently fail with errors (see stack trace below) until Graal is updated to >>>> the version compatible with the JVMCI API changes. >>>> >>>> In addition to resolving the compatibility issue, explicitly selecting the "null" compiler for these >>>> tests better isolates them from parts of the runtime they are not aiming to test. >>>> >>>> org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217) >>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138) >>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) >>>> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) >>>> at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native Method) >>>> at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185) >>>> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59) >>>> at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64) >>>> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125) >>>> at java.base/java.util.ArrayList.forEach(ArrayList.java:1378) >>>> at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71) >>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.base/java.lang.reflect.Method.invoke(Method.java:563) >>>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>> Caused by: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties >>>> at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215) >>>> ... 26 more >>>> >>>> -Doug >>>> >>>>> On 19 Apr 2017, at 23:26, Doug Simon wrote: >>>>> >>>>> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: >>>>> >>>>> 1. JVMCIServiceLocator.getProvider(Class) is now protected >>>>> 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission >>>>> 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK >>>>> >>>>> -Doug >>>>> >>>>>> On 19 Apr 2017, at 23:12, Doug Simon wrote: >>>>>> >>>>>>> >>>>>>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>>>>>> >>>>>>>> >>>>>>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>>>>>> >>>>>>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>>>>>> >>>>>>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>>>>>> >>>>>>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>>>>>> >>>>>>>>> It's unqualified and no restriction in this change. >>>>>>>> >>>>>>>> The public methods currently in jdk.vm.ci.services are: >>>>>>>> >>>>>>>> 1. JVMCIServiceLocator.getProvider(Class) >>>>>>>> 2. JVMCIServiceLocator.getProviders(Class) >>>>>>>> 3. Services.initializeJVMCI() >>>>>>>> 4. Services.getSavedProperties() >>>>>>>> 5. Services.exportJVMCITo(Class) >>>>>>>> 6. Services.load(Class) >>>>>>>> 7. Services.loadSingle(Class, boolean) >>>>>>>> >>>>>>>> 1 should be made protected. I'll update the webrev with this change. >>>>>>> >>>>>>> Good. >>>>>>> >>>>>>>> >>>>>>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>>>>>> >>>>>>> Good. >>>>>>> >>>>>>>> >>>>>>>> 3 is harmless from a security perspective in my opinion. >>>>>>> >>>>>>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >>>>>> >>>>>> Vladimir, can you please bring this to the attention of the relevant engineer. >>>>>> >>>>>>>> >>>>>>>> 4 checks for JVMCIPermission. >>>>>>> >>>>>>> Ok. >>>>>>> >>>>>>>> >>>>>>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>>>>>> >>>>>>> About this, will this Graal update happen for JDK 9? >>>>>> >>>>>> Yes. >>>>>> >>>>>>> It?s awfully late in the cycle... >>>>>> >>>>>> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >>>>>> >>>>>> -Doug >>>>> >>>> >>> >> From mandy.chung at oracle.com Thu Apr 27 21:24:44 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 27 Apr 2017 14:24:44 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> Message-ID: <450F2636-45EB-4551-A1D3-EFC0A34C59C5@oracle.com> > On Apr 27, 2017, at 7:47 AM, Doug Simon wrote: > > [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 I reviewed the top repo and jdk repo change. For hotspot change, I reviewed jdk.vm.ci.services/* and jdk.internal.vm.ci module-info.java. make/make/CompileJavaModules.gmk jdk/make/launcher/Launcher-jdk.aot.gmk Reading the original jdk.internal.vm.ci module-info.java [1], jdk.aot only accesses a small set of packages. e.g. it does not access jdk.vm.ci.aarch64, jdk.vm.ci.code.stack, jdk.vm.ci.common, etc. 115 jdk.internal.vm.compiler \ This should be removed from PLATFORM_MODULES list. $PLATFORM_MODULES already includes $UPGRADEABLE_MODULES. Otherwise, looks good to me. There are jdk tests verifying upgradeable modules and qualified exports. I suggest to run through JPRT -testset core options to catch any test failure. Mandy [1] http://cr.openjdk.java.net/~dnsimon/8177845.02/hotspot/src/jdk.internal.vm.ci/share/classes/module-info.java.sdiff.html From doug.simon at oracle.com Thu Apr 27 21:30:06 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 27 Apr 2017 23:30:06 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <450F2636-45EB-4551-A1D3-EFC0A34C59C5@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> <450F2636-45EB-4551-A1D3-EFC0A34C59C5@oracle.com> Message-ID: <1512A408-8CEA-40FC-BDFC-1AA7B9A1312E@oracle.com> > On 27 Apr 2017, at 23:24, Mandy Chung wrote: > > >> On Apr 27, 2017, at 7:47 AM, Doug Simon wrote: >> >> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 > > I reviewed the top repo and jdk repo change. For hotspot change, > I reviewed jdk.vm.ci.services/* and jdk.internal.vm.ci module-info.java. > > make/make/CompileJavaModules.gmk > jdk/make/launcher/Launcher-jdk.aot.gmk > Reading the original jdk.internal.vm.ci module-info.java [1], > jdk.aot only accesses a small set of packages. e.g. it does not > access jdk.vm.ci.aarch64, jdk.vm.ci.code.stack, jdk.vm.ci.common, etc. I know but I agree with Vladimir that there's no harm in exporting everything to jdk.aot to simplify continued development of this tool as support for other platforms is added. As I learnt putting this patch together, missing these exports when they're actually needed leads to very confusing compiler error messages. > 115 jdk.internal.vm.compiler \ > > This should be removed from PLATFORM_MODULES list. $PLATFORM_MODULES > already includes $UPGRADEABLE_MODULES. Will do. > Otherwise, looks good to me. Thanks for the review. > There are jdk tests verifying upgradeable modules and qualified exports. > I suggest to run through JPRT -testset core options to catch any test failure. Will do. -Doug From mandy.chung at oracle.com Thu Apr 27 22:04:41 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 27 Apr 2017 15:04:41 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <1512A408-8CEA-40FC-BDFC-1AA7B9A1312E@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> <9BF3C1FD-C963-4661-8442-DE06313565AE@oracle.com> <450F2636-45EB-4551-A1D3-EFC0A34C59C5@oracle.com> <1512A408-8CEA-40FC-BDFC-1AA7B9A1312E@oracle.com> Message-ID: <090FBD05-CAD2-424F-B447-AD28870F3F46@oracle.com> > On Apr 27, 2017, at 2:30 PM, Doug Simon wrote: > > >> On 27 Apr 2017, at 23:24, Mandy Chung wrote: >> >> >>> On Apr 27, 2017, at 7:47 AM, Doug Simon wrote: >>> >>> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 >> >> I reviewed the top repo and jdk repo change. For hotspot change, >> I reviewed jdk.vm.ci.services/* and jdk.internal.vm.ci module-info.java. >> >> make/make/CompileJavaModules.gmk >> jdk/make/launcher/Launcher-jdk.aot.gmk >> Reading the original jdk.internal.vm.ci module-info.java [1], >> jdk.aot only accesses a small set of packages. e.g. it does not >> access jdk.vm.ci.aarch64, jdk.vm.ci.code.stack, jdk.vm.ci.common, etc. > > I know but I agree with Vladimir that there's no harm in exporting everything to jdk.aot to simplify continued development of this tool as support for other platforms is added. As I learnt putting this patch together, missing these exports when they're actually needed leads to very confusing compiler error messages. Indeed the compiler error message is very confusing and ought to be improved (JDK-8179359). I have no issue to export these packages to jdk.aot, as you agree to do. Mandy From rwestrel at redhat.com Fri Apr 28 08:46:18 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 28 Apr 2017 10:46:18 +0200 Subject: [10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash In-Reply-To: References: <6ce634a9-cd51-d98b-8e46-fbe6cb1f3f43@oracle.com> <1aef21ad-3676-2ffd-069a-c74ef36a668a@oracle.com> <83aed7fe-cafa-f28b-577d-c6871123e269@oracle.com> <8cfe23ac-b308-24e3-2725-44992031cddd@oracle.com> <352faa06-3fe4-de8a-eeb6-3506bf555a1e@redhat.com> Message-ID: > In addition to Andrew?s test i have a simple JMH microbenchmark i can > send you, which i used to measure performance and identify issues with > code generation, misalignment, and unrolled loops for byte buffer > access (off/on heap) and VarHandle views. specjvm2008 is likely too > coarse grained. I found some regressions with Paul's tests but I can recover lost performance using profiling data and some tweaks to the compiler. I'll take care of all that as part of a follow up change. Here is a new webrev: http://cr.openjdk.java.net/~roland/8176506/webrev.03/ I found I introduced a bug in LibraryCallKit::make_unsafe_address(): in case of a raw memory access classify_unsafe_addr() changes base but we don't want that change to propagate to LibraryCallKit::inline_unsafe_access() otherwise it won't see a null base for a raw memory access. If C2 compiles a method that makes incorrect use of Unsafe (by trying to load a field from a null object for instance), the C2 HaltNode can be executed. Its current implementation on several platforms result in a call to os::breakpoint() which is an empty method. So execution would happily return to the compiled method and continue and fail in some mysterious way. That's why in my previous webrevs, I had implemented the HaltNode on x86 and aarch64 as a call to a method that call ShouldNotReachHere(). This needs to be taken care of on all platforms. The webrev now includes an implementation on arm64 (that I tested), arm32 and sparc (that I can't build or test). I would need someone to verify them. I suppose PPC would need something similar as well but I have limited PPC skills so I would need code for that too. The easy way to test the halt implementation is to modify the TestMaybeNullUnsafeAccess test from the patch and add a: test2(null); call after the loop of the main method. This should result in the Halt node being executed. Roland. From rwestrel at redhat.com Fri Apr 28 10:58:08 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 28 Apr 2017 12:58:08 +0200 Subject: [10] RFR(XS): 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: References: <15b3b2dc-481f-98fd-c7db-f72f58d970e1@oracle.com> Message-ID: > The patch has been updated in > http://cr.openjdk.java.net/~njian/8169697/webrev.01/. That patch looks good to me. Can we have a sponsor for it (in jdk 10)? Roland. From patric.hedlin at oracle.com Fri Apr 28 13:48:49 2017 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Fri, 28 Apr 2017 15:48:49 +0200 Subject: JDK10/RFR(L): 8172231: SPARC ISA/CPU feature detection is broken/insufficient (on Solaris). Message-ID: <6801aebd-eb60-6711-2859-0096818007eb@oracle.com> Dear all, I would like to ask for help to review the following change/update: Issue: https://bugs.openjdk.java.net/browse/JDK-8172231 Webrev: http://cr.openjdk.java.net/~neliasso/8172231/ 8172231: SPARC ISA/CPU feature detection is broken/insufficient (on Solaris). Updating SPARC feature/capability detection (incorporating changes from Martin Walsh). More complete set of features as provided by 'getisax(2)' interface, propagated via JVMCI. More robust hardware probing for additional features (up to Core S4). Removing support for old, pre Niagara, hardware. Removing support for old, pre 11.1, Solaris. Changed behaviour: Changing SPARC setup for AllocatePrefetchLines and AllocateInstancePrefetchLines such that they will (still) be doubled when cache-line size is small (32 bytes), but more moderately increased on new/contemporary hardware (inc >= 50%). Changing to default instruction fetch alignment based on derived caps. instead of relying on default/configuration values. The above changes also subsumes: 8035146: assert(is_T_family(features) == is_niagara(features), "Niagara should be T series") is incorrect 8054979: Remove unnecessary defines in SPARC's VM_Version::platform_features Rationale: Current hardware detection on Solaris/SPARC is not up to date with the "latest" (here, meaning commercially available server solutions, i.e. T7/M7). To facilitate improved use of the new hardware features provided (by Core S3&S4) these capabilities need to be recognised by the JVM. NOTE: This update is limited to Core S3&S4, i.e. not including Core S5. Proper Core S5 support will be added when regular testing and benchmarking resources are available, i.e. regular testing need to include M8 hardware. Caveat: This update will introduce some redundancies into the code base, features and definitions currently not used, as well as a (small) number of FIXMEs, addressed by subsequent bug or feature updates/patches. Fujitsu HW is treated very conservatively. Testing: Mostly tested on JDK9 (RBT/hotspot/comp). Only local testing on JDK10 (jtreg/hotspot). Benchmarking: Benchmark reports from a limited set of runs can be found at: http://aurora.se.oracle.com/performance/reporting/report/patric.hedlin.TvM.jbb05 http://aurora.se.oracle.com/performance/reporting/report/patric.hedlin.TvM.jvm08 http://aurora.se.oracle.com/performance/reporting/report/patric.hedlin.TvM.octane.plus (Limited availability of M7 hardware prevents complete suites/runs.) Best regards, Patric -------------- next part -------------- An HTML attachment was scrubbed... URL: From chenyt.cs.sjtu at gmail.com Tue Apr 18 16:42:51 2017 From: chenyt.cs.sjtu at gmail.com (Yuting Chen) Date: Tue, 18 Apr 2017 16:42:51 -0000 Subject: aot compiler halts when there exists an infinite loop in clinit() Message-ID: Hi, are there any comments to this case? I found that the clinit method will be compiled if it does not contain the infinite loop. It's weird. The bytecode is shown as follows: public class Vector1 minor version: 0 major version: 52 flags: ACC_PUBLIC, ACC_SUPER Constant pool: #1 = Utf8 Vector1 #2 = Class #1 // Vector1 #3 = Utf8 java/lang/Object #4 = Class #3 // java/lang/Object #5 = Utf8 serialVersionUID #6 = Utf8 J #7 = Long -2767605614048989439l #9 = Utf8 #10 = Utf8 ()V #11 = NameAndType #5:#6 // serialVersionUID:J #12 = Fieldref #2.#11 // Vector1.serialVersionUID:J #13 = Utf8 main #14 = Utf8 ([Ljava/lang/String;)V #15 = Utf8 ConstantValue #16 = Utf8 Code #17 = Utf8 StackMapTable { public static {}; descriptor: ()V flags: ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=0, args_size=0 0: ldc2_w #7 // long -2767605614048989439l 3: putstatic #12 // Field serialVersionUID:J 6: iconst_1 7: iconst_m1 8: iadd 9: ifge 0 12: return StackMapTable: number_of_entries = 1 frame_type = 0 /* same */ public static void main(java.lang.String[]); descriptor: ([Ljava/lang/String;)V flags: ACC_PUBLIC, ACC_STATIC Code: stack=0, locals=1, args_size=1 0: return }