From kim.barrett at oracle.com Wed Jul 1 17:16:20 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Jul 2020 13:16:20 -0400 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: <0f4bb5cf-9a88-95fc-f049-ce69e8a18af9@oracle.com> References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> <1CFC36DF-5493-4389-B5A9-FD3A4F3146C5@oracle.com> <3724b7b5-c7a0-63f0-f598-8b0ed4e37696@oracle.com> <0f4bb5cf-9a88-95fc-f049-ce69e8a18af9@oracle.com> Message-ID: > On Jun 28, 2020, at 8:08 PM, David Holmes wrote: > > Hi Kim, > > Updates look good. One minor nit, titles should not use abbreviations that have not yet been defined > > e.g. > > #### RTTI (Runtime Type Information) > > should just be > > #### Runtime Type Information > > (you don't introduce abbreviations in headings/titles either). > > And: > > #### Expression SFINAE > > also needs fixing - though simply expanding SFINAE doesn't really make sense as it seems to be being used as a verb, which seems odd in itself. I don't know how to rewrite that title in a meaningful way. I suppose one way around this would be to say: > > #### Expression "SFINAE" > > though even that is a stretch. I'm going to claim these are not abbreviations in the usual sense, but rather are well-known terms of art. And this document is not targeted at an audience unskilled in the art. That's particularly true for SFINAE; I suspect most people (including me) have to stop and think about it to correctly recall its expansion, and nobody actually uses or cares about the expansion. Even more so for "Expression SFINAE"; one would never say or write "Expression Substitution Failure...". Books on C++ (such as Dewhurst's "C++ Common Knowledge") will give the expansion almost as an aside, but "SFINAE" is the section title and index entry. I'm considering going back to always using the "term" in normal text, with a parenthetical expansion on first use. I find the latest approach jarring, as the specialized terms are the normal usage. From david.holmes at oracle.com Thu Jul 2 00:28:35 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Jul 2020 10:28:35 +1000 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> <1CFC36DF-5493-4389-B5A9-FD3A4F3146C5@oracle.com> <3724b7b5-c7a0-63f0-f598-8b0ed4e37696@oracle.com> <0f4bb5cf-9a88-95fc-f049-ce69e8a18af9@oracle.com> Message-ID: <18fbdc66-f4f7-05da-95b2-f480cb67342e@oracle.com> On 2/07/2020 3:16 am, Kim Barrett wrote: >> On Jun 28, 2020, at 8:08 PM, David Holmes wrote: >> >> Hi Kim, >> >> Updates look good. One minor nit, titles should not use abbreviations that have not yet been defined >> >> e.g. >> >> #### RTTI (Runtime Type Information) >> >> should just be >> >> #### Runtime Type Information >> >> (you don't introduce abbreviations in headings/titles either). >> >> And: >> >> #### Expression SFINAE >> >> also needs fixing - though simply expanding SFINAE doesn't really make sense as it seems to be being used as a verb, which seems odd in itself. I don't know how to rewrite that title in a meaningful way. I suppose one way around this would be to say: >> >> #### Expression "SFINAE" >> >> though even that is a stretch. > > I'm going to claim these are not abbreviations in the usual sense, but > rather are well-known terms of art. And this document is not targeted > at an audience unskilled in the art. I'm sure for some, perhaps many, C++ template practitioners that SFINAE is a blindingly obvious term/concept/whatever, but for others it will not be. I can neither readily recall what it expands to, nor what underlying principle it refers to. > That's particularly true for SFINAE; I suspect most people (including > me) have to stop and think about it to correctly recall its expansion, > and nobody actually uses or cares about the expansion. Even more so > for "Expression SFINAE"; one would never say or write "Expression > Substitution Failure...". I think "Expression SFINAE" is a grammatically meaningless phrase. > Books on C++ (such as Dewhurst's "C++ Common Knowledge") will give the > expansion almost as an aside, but "SFINAE" is the section title and > index entry. And that is not completely unreasonable for a book on C++ that wants to focus on the vocabulary of C++ practitioners. But I note that even the person credited with at least popularising, if not introducing, this term did so thusly [1]: 'This "substitution-failure-is-not-an-error" (SFINAE) principle is clearly an important ingredient to make the overloading of function templates practical.' [1] C++ Templates: The Complete Guide, Book by David Vandevoorde and Nicolai M. Josuttis > I'm considering going back to always using the "term" in normal text, > with a parenthetical expansion on first use. I find the latest > approach jarring, as the specialized terms are the normal usage. Only if you think this document's audience is C++ experts who happen to be working on hotspot, rather than hotspot developers who will have a wide range of experience in C++. I obviously consider it to be the latter. Cheers, David ----- From kim.barrett at oracle.com Thu Jul 2 13:36:20 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 2 Jul 2020 09:36:20 -0400 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: <18fbdc66-f4f7-05da-95b2-f480cb67342e@oracle.com> References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> <1CFC36DF-5493-4389-B5A9-FD3A4F3146C5@oracle.com> <3724b7b5-c7a0-63f0-f598-8b0ed4e37696@oracle.com> <0f4bb5cf-9a88-95fc-f049-ce69e8a18af9@oracle.com> <18fbdc66-f4f7-05da-95b2-f480cb67342e@oracle.com> Message-ID: <3D09A7A6-5B81-4C15-895D-8F54AC20C8A6@oracle.com> > On Jul 1, 2020, at 8:28 PM, David Holmes wrote: > > On 2/07/2020 3:16 am, Kim Barrett wrote: > >> That's particularly true for SFINAE; I suspect most people (including >> me) have to stop and think about it to correctly recall its expansion, >> and nobody actually uses or cares about the expansion. Even more so >> for "Expression SFINAE"; one would never say or write "Expression >> Substitution Failure...". > > I think "Expression SFINAE" is a grammatically meaningless phrase. "Expression SFINAE" is the (informal) name of a C++ feature (which doesn't have a formal name, per se; it's part of [temp.deduct] and [temp.over]). >> I'm considering going back to always using the "term" in normal text, >> with a parenthetical expansion on first use. I find the latest >> approach jarring, as the specialized terms are the normal usage. > > Only if you think this document's audience is C++ experts who happen to be working on hotspot, rather than hotspot developers who will have a wide range of experience in C++. I obviously consider it to be the latter. The only reason "Expression SFINAE" isn't just a simple entry like this: * Expression SFINAE ([n2634](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html) in the Permitted Features list is that I ran into some seriously weird bugs in obscure corners, so decided to add a few words of caution. I'm assuming some C++ competence and willingness to do a little research to fill in knowledge gaps. The abbreviated forms are common usage, and if one doesn't already know what they mean, the expansions don't provide much of a clue. From chris.plummer at oracle.com Thu Jul 2 14:21:14 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 2 Jul 2020 07:21:14 -0700 Subject: RFR (L): 8248194: Need better support for running SA tests on core files Message-ID: <5760b18e-7ba2-2fdd-94af-1e555cef74cc@oracle.com> [Note, the following changes only impact serviceability tests, but I am adding some test library code to assist with creating and finding core files, and I thought others on hotspot-dev might have an interest in that.] Hello, Please help review the following changes to add better support for writing SA tests that work on core files: https://bugs.openjdk.java.net/browse/JDK-8248194 http://cr.openjdk.java.net/~cjplummer/8248194/webrev.01/index.html As outlined in the CR, these are the 3 main goals of this CR: 1. Add a shared API for locating the path to the core file. This includes parsing the output of the crashed process to locate where the core file was saved, and returning this location to the user. This API will be placed in the new CoreUtils class. 2. Add a shared API to support adding the "ulimit -c unlimited" prefix to the command that will produce the core file, allowing the overriding of any lower limit so we can be sure the core file will be produced. This API will also be placed in the new CoreUtils class. 3. LingeredApp should include support for producing a core file. As proof of concept for these improvements, I'm updating the following 3 tests to make use of them: ClhsdbCDSCore.java and TestJmapCore.java: Use the CoreUtils support listed above. These tests do not use LingeredApp, so those improvements don't apply. ClhsdbFindPC.java: Use all the above new features, including having LingeredApp produce a core file. This is the only test modified to start testing on core files that didn't previously do so. It still also tests on a live process. In the future more Clhsdb tests will be converted to work on core files in a manner similar to ClhsdbFindPC. The new CoreUtils code is borrowed from (more like ripped out of) ClhsdbCDSCore.java and TestJmapCore.java. They both had a lot of code dedicated to finding the core file and also applying "ulimit -c unlimited", but didn't do so in quite the same way. Now both these tests share code in CoreUtils.java. One thing I did drop is TestJmapCore.java use of ":KILLED_PID" in the output to help find the core file. It's no longer necessary based on the smarter core locating code I pulled from ClhsdbCDSCore.java. One other improvement was to enable windows support for ClhsdbCDSCore. The only reason it was not enabled previously is because the author couldn't figure out how to properly generate the command for the process that produces the core. Since it is launched using "sh -c", the path has to be converted to use forward slashes. This is now done in CoreUtils. One other change in ClhsdbCDSCore is that it no longer renames the core file to a well known name in the cwd. This was unnecessary. It originated in code from ciReplayBase.java, which does have a reason to do the rename, but ClhsdbCDSCore does not. The new libLingeredApp.c relies on JDK-8248667 [1] being in place in order to have the build system properly compile it. JDK-8248667 will be reviewed separately on build-dev and pushed just before the changes for this CR. thanks, Chris [1] https://bugs.openjdk.java.net/browse/JDK-8248667 From Yang.Zhang at arm.com Fri Jul 3 02:15:27 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Fri, 3 Jul 2020 02:15:27 +0000 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> Message-ID: Hi Sandhya Thanks very much for your help. Regards, Yang -----Original Message----- From: Viswanathan, Sandhya Sent: Wednesday, July 1, 2020 2:57 AM To: Yang Zhang ; Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes Hi Yang, I have merged vectorIntrinsics with changes from panama/default. Hope this helps. Best Regards, Sandhya -----Original Message----- From: Yang Zhang Sent: Monday, June 29, 2020 12:49 AM To: Viswanathan, Sandhya ; Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes Hi Andrew, 1. Instructions that can be matched with NEON instructions directly. MulVB, SqrtVF and AbsV have been merged into jdk master already. 2. Instructions that jdk master has middle end support for, but they cannot be matched with NEON instructions directly. Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. 3. Panama/Vector API specific instructions such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. These instructions cannot be moved into jdk master first because there isn't middle-end support. I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send it again. Hi Sandhya, Could you please help to manual merge panama vectorIntrinsics/vector-unstable to jdk master? So that I can update this patch based on latest jdk master. Regards Yang -----Original Message----- From: Viswanathan, Sandhya Sent: Thursday, June 25, 2020 3:04 AM To: Yang Zhang ; Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes Hi Andrew/Yang, We couldn?t propose Vector API to target in time for JDK 15 and hoping to do so early in JDK 16 timeframe. The implementation reviews on other components have made good progress. We have so far ok to PPT from (runtime, shared compiler changes, x86 backend). Java API implementation review is in progress. I wanted to check with you both if we have a go ahead from aarch64 backed point of view. Best Regards, Sandhya -----Original Message----- From: hotspot-compiler-dev On Behalf Of Yang Zhang Sent: Tuesday, May 26, 2020 7:59 PM To: Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes > But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? The new instructions can be classified as: 1. Instructions that can be matched with NEON instructions directly. MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is in review [1]. 2. Instructions that Jdk master has middle end support for, but they cannot be matched with NEON instructions directly. Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. May I have a new patch for these? 3. Panama/Vector API specific instructions Such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. These instructions cannot be moved into jdk master first because there isn't middle-end support. Regards Yang [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html -----Original Message----- From: Andrew Haley Sent: Tuesday, May 26, 2020 4:25 PM To: Yang Zhang ; Paul Sandoz Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; nd Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes On 25/05/2020 09:26, Yang Zhang wrote: > In jdk master, what we need to do is that writing m4 file for existing > vector instructions and placed them to a new file aarch64_neon.ad. > If no question, I will do it right away. I'm not entirely sure that such a change is necessary now. In particular, reorganizing the existing vector instructions is IMO excessive, but I admit that it might be an improvement. But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? It'd help if this was possible. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From patric.hedlin at oracle.com Sun Jul 5 15:26:48 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Sun, 5 Jul 2020 17:26:48 +0200 Subject: RFR(S): 8247762: [aarch64] Timeout in .../HeapDumpTestWithActiveProcess.java due to inf. loop in AARCH64CurrentFrameGuess.run() Message-ID: Dear all, I would like to ask for help to review the following change/update: Issue:? https://bugs.openjdk.java.net/browse/JDK-8247762 Webrev: http://cr.openjdk.java.net/~phedlin/tr8247762/ AARCH64CurrentFrameGuess.run() may loop indefinitely in a bad stack-walk. This is JDK-8231635 applied to AArch64. NOTE: This patch is only a partial solution to the various /stack-walk/timeout/ issues in this particular test-case. Testing: HeapDumpTestWithActiveProcess.java Best regards, Patric From aph at redhat.com Mon Jul 6 08:37:35 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 6 Jul 2020 09:37:35 +0100 Subject: RFR(S): 8247762: [aarch64] Timeout in .../HeapDumpTestWithActiveProcess.java due to inf. loop in AARCH64CurrentFrameGuess.run() In-Reply-To: References: Message-ID: <36c12487-cfc9-3823-c4a3-7605629beca5@redhat.com> On 05/07/2020 16:26, Patric Hedlin wrote: > Issue:? https://bugs.openjdk.java.net/browse/JDK-8247762 > Webrev: http://cr.openjdk.java.net/~phedlin/tr8247762/ > > > AARCH64CurrentFrameGuess.run() may loop indefinitely in a bad > stack-walk. This is JDK-8231635 applied to AArch64. 141 Frame oldFrame = frame; 142 frame = frame.sender(map); 143 if (frame.getSP().lessThanOrEqual(oldFrame.getSP())) { 144 // Frame points to itself or to a location in the wrong direction. 145 // Break the loop and move on to next offset. 146 if (DEBUG) { 147 System.out.println("CurrentFrameGuess: frame <= oldFrame: " + frame); 148 } 149 break; 150 } 151 } OK, that looks like a reasonable thing to do, but I would wonder how the stack got into that mess. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From chris.plummer at oracle.com Mon Jul 6 15:52:00 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Jul 2020 08:52:00 -0700 Subject: RFR(S): 8247762: [aarch64] Timeout in .../HeapDumpTestWithActiveProcess.java due to inf. loop in AARCH64CurrentFrameGuess.run() In-Reply-To: <36c12487-cfc9-3823-c4a3-7605629beca5@redhat.com> References: <36c12487-cfc9-3823-c4a3-7605629beca5@redhat.com> Message-ID: <78a1d527-bd3f-6bc2-7880-ca5f34215267@oracle.com> On 7/6/20 1:37 AM, Andrew Haley wrote: > On 05/07/2020 16:26, Patric Hedlin wrote: >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8247762 >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8247762/ >> >> >> AARCH64CurrentFrameGuess.run() may loop indefinitely in a bad >> stack-walk. This is JDK-8231635 applied to AArch64. > 141 Frame oldFrame = frame; > 142 frame = frame.sender(map); > 143 if (frame.getSP().lessThanOrEqual(oldFrame.getSP())) { > 144 // Frame points to itself or to a location in the wrong direction. > 145 // Break the loop and move on to next offset. > 146 if (DEBUG) { > 147 System.out.println("CurrentFrameGuess: frame <= oldFrame: " + frame); > 148 } > 149 break; > 150 } > 151 } > > OK, that looks like a reasonable thing to do, but I would wonder how the stack got > into that mess. > Hi Patric, The changes look good to me. Andrew, The problem is not the stack per se. AARCH64CurrentFrameGuess.run() tries to find the "current frame". It starts with the specified SP (which I believe comes from the SP register), and validates that it represents the current frame by using it to walk the stack until the first entry frame is found. If it doesn't find it, then it increments SP by a word and tries again. It does this until it either can successfully walk to the first entry frame, or SP leaves the range it is willing to search, at which point it gives up. During this search all manner of bad addresses can be accessed. This is why there is an exception handler that when triggered simply moves on to the next SP to check. So it's not at all surprising that on occasion a bad SP results in frame->sender() pointing to a frame that was already visited. thanks, Chris From patric.hedlin at oracle.com Mon Jul 6 19:54:40 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Mon, 6 Jul 2020 21:54:40 +0200 Subject: RFR(S): 8247762: [aarch64] Timeout in .../HeapDumpTestWithActiveProcess.java due to inf. loop in AARCH64CurrentFrameGuess.run() In-Reply-To: <78a1d527-bd3f-6bc2-7880-ca5f34215267@oracle.com> References: <36c12487-cfc9-3823-c4a3-7605629beca5@redhat.com> <78a1d527-bd3f-6bc2-7880-ca5f34215267@oracle.com> Message-ID: <6322edbb-ab38-4956-6a29-5b1c3d48c132@oracle.com> Thanks Chris, for review and laying out the text. Andrew, Something you can live with? /Patric On 2020-07-06 17:52, Chris Plummer wrote: > On 7/6/20 1:37 AM, Andrew Haley wrote: >> On 05/07/2020 16:26, Patric Hedlin wrote: >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8247762 >>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8247762/ >>> >>> >>> AARCH64CurrentFrameGuess.run() may loop indefinitely in a bad >>> stack-walk. This is JDK-8231635 applied to AArch64. >> ? 141?????????????? Frame oldFrame = frame; >> ? 142?????????????? frame = frame.sender(map); >> ? 143?????????????? if >> (frame.getSP().lessThanOrEqual(oldFrame.getSP())) { >> ? 144???????????????? // Frame points to itself or to a location in >> the wrong direction. >> ? 145???????????????? // Break the loop and move on to next offset. >> ? 146???????????????? if (DEBUG) { >> ? 147?????????????????? System.out.println("CurrentFrameGuess: frame >> <= oldFrame: " + frame); >> ? 148???????????????? } >> ? 149???????????????? break; >> ? 150?????????????? } >> ? 151???????????? } >> >> OK, that looks like a reasonable thing to do, but I would wonder how >> the stack got >> into that mess. >> > Hi Patric, > > The changes look good to me. > > Andrew, > > The problem is not the stack per se. AARCH64CurrentFrameGuess.run() > tries to find the "current frame". It starts with the specified SP > (which I believe comes from the SP register), and validates that it > represents the current frame by using it to walk the stack until the > first entry frame is found. If it doesn't find it, then it increments > SP by a word and tries again. It does this until it either can > successfully walk to the first entry frame, or SP leaves the range it > is willing to search, at which point it gives up. During this search > all manner of bad addresses can be accessed. This is why there is an > exception handler that when triggered simply moves on to the next SP > to check. So it's not at all surprising that on occasion a bad SP > results in frame->sender() pointing to a frame that was already visited. > > thanks, > > Chris > From leonid.mesnik at oracle.com Mon Jul 6 22:27:36 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 6 Jul 2020 15:27:36 -0700 Subject: RFR (L): 8248194: Need better support for running SA tests on core files In-Reply-To: <5760b18e-7ba2-2fdd-94af-1e555cef74cc@oracle.com> References: <5760b18e-7ba2-2fdd-94af-1e555cef74cc@oracle.com> Message-ID: Hi The changes look good for me. Leonid > On Jul 2, 2020, at 7:21 AM, Chris Plummer wrote: > > [Note, the following changes only impact serviceability tests, but I am adding some test library code to assist with creating and finding core files, and I thought others on hotspot-dev might have an interest in that.] > > Hello, > > Please help review the following changes to add better support for writing SA tests that work on core files: > > https://bugs.openjdk.java.net/browse/JDK-8248194 > http://cr.openjdk.java.net/~cjplummer/8248194/webrev.01/index.html > > As outlined in the CR, these are the 3 main goals of this CR: > > 1. Add a shared API for locating the path to the core file. This includes parsing the output of the crashed process to locate where the core file was saved, and returning this location to the user. This API will be placed in the new CoreUtils class. > > 2. Add a shared API to support adding the "ulimit -c unlimited" prefix to the command that will produce the core file, allowing the overriding of any lower limit so we can be sure the core file will be produced. This API will also be placed in the new CoreUtils class. > > 3. LingeredApp should include support for producing a core file. > > As proof of concept for these improvements, I'm updating the following 3 tests to make use of them: > > ClhsdbCDSCore.java and TestJmapCore.java: Use the CoreUtils support listed above. These tests do not use LingeredApp, so those improvements don't apply. > > ClhsdbFindPC.java: Use all the above new features, including having LingeredApp produce a core file. This is the only test modified to start testing on core files that didn't previously do so. It still also tests on a live process. > > In the future more Clhsdb tests will be converted to work on core files in a manner similar to ClhsdbFindPC. > > The new CoreUtils code is borrowed from (more like ripped out of) ClhsdbCDSCore.java and TestJmapCore.java. They both had a lot of code dedicated to finding the core file and also applying "ulimit -c unlimited", but didn't do so in quite the same way. Now both these tests share code in CoreUtils.java. One thing I did drop is TestJmapCore.java use of ":KILLED_PID" in the output to help find the core file. It's no longer necessary based on the smarter core locating code I pulled from ClhsdbCDSCore.java. > > One other improvement was to enable windows support for ClhsdbCDSCore. The only reason it was not enabled previously is because the author couldn't figure out how to properly generate the command for the process that produces the core. Since it is launched using "sh -c", the path has to be converted to use forward slashes. This is now done in CoreUtils. > > One other change in ClhsdbCDSCore is that it no longer renames the core file to a well known name in the cwd. This was unnecessary. It originated in code from ciReplayBase.java, which does have a reason to do the rename, but ClhsdbCDSCore does not. > > The new libLingeredApp.c relies on JDK-8248667 [1] being in place in order to have the build system properly compile it. JDK-8248667 will be reviewed separately on build-dev and pushed just before the changes for this CR. > > thanks, > > Chris > > [1] https://bugs.openjdk.java.net/browse/JDK-8248667 From chris.plummer at oracle.com Mon Jul 6 22:41:21 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Jul 2020 15:41:21 -0700 Subject: RFR (L): 8248194: Need better support for running SA tests on core files In-Reply-To: References: <5760b18e-7ba2-2fdd-94af-1e555cef74cc@oracle.com> Message-ID: Thanks, Leonid! On 7/6/20 3:27 PM, Leonid Mesnik wrote: > Hi > > The changes look good for me. > > Leonid > >> On Jul 2, 2020, at 7:21 AM, Chris Plummer wrote: >> >> [Note, the following changes only impact serviceability tests, but I am adding some test library code to assist with creating and finding core files, and I thought others on hotspot-dev might have an interest in that.] >> >> Hello, >> >> Please help review the following changes to add better support for writing SA tests that work on core files: >> >> https://bugs.openjdk.java.net/browse/JDK-8248194 >> http://cr.openjdk.java.net/~cjplummer/8248194/webrev.01/index.html >> >> As outlined in the CR, these are the 3 main goals of this CR: >> >> 1. Add a shared API for locating the path to the core file. This includes parsing the output of the crashed process to locate where the core file was saved, and returning this location to the user. This API will be placed in the new CoreUtils class. >> >> 2. Add a shared API to support adding the "ulimit -c unlimited" prefix to the command that will produce the core file, allowing the overriding of any lower limit so we can be sure the core file will be produced. This API will also be placed in the new CoreUtils class. >> >> 3. LingeredApp should include support for producing a core file. >> >> As proof of concept for these improvements, I'm updating the following 3 tests to make use of them: >> >> ClhsdbCDSCore.java and TestJmapCore.java: Use the CoreUtils support listed above. These tests do not use LingeredApp, so those improvements don't apply. >> >> ClhsdbFindPC.java: Use all the above new features, including having LingeredApp produce a core file. This is the only test modified to start testing on core files that didn't previously do so. It still also tests on a live process. >> >> In the future more Clhsdb tests will be converted to work on core files in a manner similar to ClhsdbFindPC. >> >> The new CoreUtils code is borrowed from (more like ripped out of) ClhsdbCDSCore.java and TestJmapCore.java. They both had a lot of code dedicated to finding the core file and also applying "ulimit -c unlimited", but didn't do so in quite the same way. Now both these tests share code in CoreUtils.java. One thing I did drop is TestJmapCore.java use of ":KILLED_PID" in the output to help find the core file. It's no longer necessary based on the smarter core locating code I pulled from ClhsdbCDSCore.java. >> >> One other improvement was to enable windows support for ClhsdbCDSCore. The only reason it was not enabled previously is because the author couldn't figure out how to properly generate the command for the process that produces the core. Since it is launched using "sh -c", the path has to be converted to use forward slashes. This is now done in CoreUtils. >> >> One other change in ClhsdbCDSCore is that it no longer renames the core file to a well known name in the cwd. This was unnecessary. It originated in code from ciReplayBase.java, which does have a reason to do the rename, but ClhsdbCDSCore does not. >> >> The new libLingeredApp.c relies on JDK-8248667 [1] being in place in order to have the build system properly compile it. JDK-8248667 will be reviewed separately on build-dev and pushed just before the changes for this CR. >> >> thanks, >> >> Chris >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8248667 From alexey.menkov at oracle.com Mon Jul 6 23:16:02 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 6 Jul 2020 16:16:02 -0700 Subject: RFR (L): 8248194: Need better support for running SA tests on core files In-Reply-To: <5760b18e-7ba2-2fdd-94af-1e555cef74cc@oracle.com> References: <5760b18e-7ba2-2fdd-94af-1e555cef74cc@oracle.com> Message-ID: <2f2d3b21-8f8e-3c01-1e33-ad68bd39254b@oracle.com> Hi Chris, Generally looks good to me. CoreUtils.java: 86 String[] cmds; - unused var And one question. You use OutputAnalyzer.getStdout() get extract core file location. I thought it should be printed in stderr. Or we have duplicated stdout and stderr in the case? --alex On 07/02/2020 07:21, Chris Plummer wrote: > [Note, the following changes only impact serviceability tests, but I am > adding some test library code to assist with creating and finding core > files, and I thought others on hotspot-dev might have an interest in that.] > > Hello, > > Please help review the following changes to add better support for > writing SA tests that work on core files: > > https://bugs.openjdk.java.net/browse/JDK-8248194 > http://cr.openjdk.java.net/~cjplummer/8248194/webrev.01/index.html > > As outlined in the CR, these are the 3 main goals of this CR: > > 1. Add a shared API for locating the path to the core file. This > includes parsing the output of the crashed process to locate where the > core file was saved, and returning this location to the user. This API > will be placed in the new CoreUtils class. > > 2. Add a shared API to support adding the "ulimit -c unlimited" prefix > to the command that will produce the core file, allowing the overriding > of any lower limit so we can be sure the core file will be produced. > This API will also be placed in the new CoreUtils class. > > 3. LingeredApp should include support for producing a core file. > > As proof of concept for these improvements, I'm updating the following 3 > tests to make use of them: > > ClhsdbCDSCore.java and TestJmapCore.java: Use the CoreUtils support > listed above. These tests do not use LingeredApp, so those improvements > don't apply. > > ClhsdbFindPC.java: Use all the above new features, including having > LingeredApp produce a core file. This is the only test modified to start > testing on core files that didn't previously do so. It still also tests > on a live process. > > In the future more Clhsdb tests will be converted to work on core files > in a manner similar to ClhsdbFindPC. > > The new CoreUtils code is borrowed from (more like ripped out of) > ClhsdbCDSCore.java and TestJmapCore.java. They both had a lot of code > dedicated to finding the core file and also applying "ulimit -c > unlimited", but didn't do so in quite the same way. Now both these tests > share code in CoreUtils.java. One thing I did drop is TestJmapCore.java > use of ":KILLED_PID" in the output to help find the core file. It's no > longer necessary based on the smarter core locating code I pulled from > ClhsdbCDSCore.java. > > One other improvement was to enable windows support for ClhsdbCDSCore. > The only reason it was not enabled previously is because the author > couldn't figure out how to properly generate the command for the process > that produces the core. Since it is launched using "sh -c", the path has > to be converted to use forward slashes. This is now done in CoreUtils. > > One other change in ClhsdbCDSCore is that it no longer renames the core > file to a well known name in the cwd. This was unnecessary. It > originated in code from ciReplayBase.java, which does have a reason to > do the rename, but ClhsdbCDSCore does not. > > The new libLingeredApp.c relies on JDK-8248667 [1] being in place in > order to have the build system properly compile it. JDK-8248667 will be > reviewed separately on build-dev and pushed just before the changes for > this CR. > > thanks, > > Chris > > [1] https://bugs.openjdk.java.net/browse/JDK-8248667 From chris.plummer at oracle.com Tue Jul 7 00:06:09 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Jul 2020 17:06:09 -0700 Subject: RFR (L): 8248194: Need better support for running SA tests on core files In-Reply-To: <2f2d3b21-8f8e-3c01-1e33-ad68bd39254b@oracle.com> References: <5760b18e-7ba2-2fdd-94af-1e555cef74cc@oracle.com> <2f2d3b21-8f8e-3c01-1e33-ad68bd39254b@oracle.com> Message-ID: <8bd159c8-1ba4-6b59-6f5d-64fd7b3b392f@oracle.com> Hi Alex, Thanks for the review. I'll cleanup the unused var. The crash output is on stdout, not stderr. From VMError::report_and_die(): ? // File descriptor to tty to print an error summary to. ? // Hard wired to stdout; see JDK-8215004 (compatibility concerns). ? static const int fd_out = 1; // stdout thanks, Chris On 7/6/20 4:16 PM, Alex Menkov wrote: > Hi Chris, > > Generally looks good to me. > > CoreUtils.java: > > 86???????? String[] cmds; > - unused var > > And one question. > You use OutputAnalyzer.getStdout() get extract core file location. > I thought it should be printed in stderr. > Or we have duplicated stdout and stderr in the case? > > --alex > > On 07/02/2020 07:21, Chris Plummer wrote: >> [Note, the following changes only impact serviceability tests, but I >> am adding some test library code to assist with creating and finding >> core files, and I thought others on hotspot-dev might have an >> interest in that.] >> >> Hello, >> >> Please help review the following changes to add better support for >> writing SA tests that work on core files: >> >> https://bugs.openjdk.java.net/browse/JDK-8248194 >> http://cr.openjdk.java.net/~cjplummer/8248194/webrev.01/index.html >> >> As outlined in the CR, these are the 3 main goals of this CR: >> >> 1. Add a shared API for locating the path to the core file. This >> includes parsing the output of the crashed process to locate where >> the core file was saved, and returning this location to the user. >> This API will be placed in the new CoreUtils class. >> >> 2. Add a shared API to support adding the "ulimit -c unlimited" >> prefix to the command that will produce the core file, allowing the >> overriding of any lower limit so we can be sure the core file will be >> produced. This API will also be placed in the new CoreUtils class. >> >> 3. LingeredApp should include support for producing a core file. >> >> As proof of concept for these improvements, I'm updating the >> following 3 tests to make use of them: >> >> ClhsdbCDSCore.java and TestJmapCore.java: Use the CoreUtils support >> listed above. These tests do not use LingeredApp, so those >> improvements don't apply. >> >> ClhsdbFindPC.java: Use all the above new features, including having >> LingeredApp produce a core file. This is the only test modified to >> start testing on core files that didn't previously do so. It still >> also tests on a live process. >> >> In the future more Clhsdb tests will be converted to work on core >> files in a manner similar to ClhsdbFindPC. >> >> The new CoreUtils code is borrowed from (more like ripped out of) >> ClhsdbCDSCore.java and TestJmapCore.java. They both had a lot of code >> dedicated to finding the core file and also applying "ulimit -c >> unlimited", but didn't do so in quite the same way. Now both these >> tests share code in CoreUtils.java. One thing I did drop is >> TestJmapCore.java use of ":KILLED_PID" in the output to help find the >> core file. It's no longer necessary based on the smarter core >> locating code I pulled from ClhsdbCDSCore.java. >> >> One other improvement was to enable windows support for >> ClhsdbCDSCore. The only reason it was not enabled previously is >> because the author couldn't figure out how to properly generate the >> command for the process that produces the core. Since it is launched >> using "sh -c", the path has to be converted to use forward slashes. >> This is now done in CoreUtils. >> >> One other change in ClhsdbCDSCore is that it no longer renames the >> core file to a well known name in the cwd. This was unnecessary. It >> originated in code from ciReplayBase.java, which does have a reason >> to do the rename, but ClhsdbCDSCore does not. >> >> The new libLingeredApp.c relies on JDK-8248667 [1] being in place in >> order to have the build system properly compile it. JDK-8248667 will >> be reviewed separately on build-dev and pushed just before the >> changes for this CR. >> >> thanks, >> >> Chris >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8248667 From kim.barrett at oracle.com Tue Jul 7 01:10:54 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 6 Jul 2020 21:10:54 -0400 Subject: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot In-Reply-To: References: <5EDE9A75.6020504@oracle.com> <5EE5AB71.20505@oracle.com> Message-ID: <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com> I just noticed that doc/building.{md,html} describes minimum toolchain versions, so also needs to be updated. Here?s the update, matching what?s now in the JEP: full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/ incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/ I also deleted a discussion of a problem one might run into when building with Visual Studio 2010, since that version is no longer relevant. From patric.hedlin at oracle.com Tue Jul 7 11:00:12 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Tue, 7 Jul 2020 13:00:12 +0200 Subject: RFR(S): 8248901: Signed immediate support in .../share/assembler.hpp is broken. Message-ID: <3df3dab6-aa2f-bbbc-d231-6cda8f2a0ff7@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-8248901 Webrev: http://cr.openjdk.java.net/~phedlin/tr8248901/ Current definition(s) of is_simm() and friends are not robust over inputs. Both min and max values are undefined for width > 32 (and width < 0). No is_uimm() is currently provided (added). Several definitions are not used (cleanup). NOTE: Adding currently unused is_simm9() and is_uimm12(), required by JDK-8247766. Testing: hs-tier1-3 Best regards, Patric From nils.eliasson at oracle.com Tue Jul 7 13:59:23 2020 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 7 Jul 2020 15:59:23 +0200 Subject: RFR(S): 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <3df3dab6-aa2f-bbbc-d231-6cda8f2a0ff7@oracle.com> References: <3df3dab6-aa2f-bbbc-d231-6cda8f2a0ff7@oracle.com> Message-ID: Hi Patric, Your change looks good. Best regards, Nils On 2020-07-07 13:00, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8248901 > Webrev: http://cr.openjdk.java.net/~phedlin/tr8248901/ > > > Current definition(s) of is_simm() and friends are not robust over > inputs. Both min and max values are undefined for width > 32 (and > width < 0). > No is_uimm() is currently provided (added). Several definitions are > not used (cleanup). > > NOTE: Adding currently unused is_simm9() and is_uimm12(), required by > JDK-8247766. > > > Testing: hs-tier1-3 > > > Best regards, > Patric From erik.joelsson at oracle.com Tue Jul 7 13:59:01 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 7 Jul 2020 06:59:01 -0700 Subject: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot In-Reply-To: <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com> References: <5EDE9A75.6020504@oracle.com> <5EE5AB71.20505@oracle.com> <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com> Message-ID: <8c4bb4ee-73fa-3568-0d70-c21703e2e06f@oracle.com> Doc changes look good. /Erik On 2020-07-06 18:10, Kim Barrett wrote: > I just noticed that doc/building.{md,html} describes minimum toolchain versions, > so also needs to be updated. Here?s the update, matching what?s now in the JEP: > > full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/ > incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/ > > I also deleted a discussion of a problem one might run into when building with > Visual Studio 2010, since that version is no longer relevant. > From patric.hedlin at oracle.com Tue Jul 7 14:36:14 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Tue, 7 Jul 2020 16:36:14 +0200 Subject: RFR(S): 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: References: <3df3dab6-aa2f-bbbc-d231-6cda8f2a0ff7@oracle.com> Message-ID: <37ec8c97-3fbc-6d96-037a-4935bd25d7d1@oracle.com> Thanks for reviewing Nils. /Patric On 2020-07-07 15:59, Nils Eliasson wrote: > Hi Patric, > > Your change looks good. > > Best regards, > Nils > > On 2020-07-07 13:00, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8248901 >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8248901/ >> >> >> Current definition(s) of is_simm() and friends are not robust over >> inputs. Both min and max values are undefined for width > 32 (and >> width < 0). >> No is_uimm() is currently provided (added). Several definitions are >> not used (cleanup). >> >> NOTE: Adding currently unused is_simm9() and is_uimm12(), required by >> JDK-8247766. >> >> >> Testing: hs-tier1-3 >> >> >> Best regards, >> Patric From kim.barrett at oracle.com Tue Jul 7 14:38:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 7 Jul 2020 10:38:48 -0400 Subject: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot In-Reply-To: <8c4bb4ee-73fa-3568-0d70-c21703e2e06f@oracle.com> References: <5EDE9A75.6020504@oracle.com> <5EE5AB71.20505@oracle.com> <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com> <8c4bb4ee-73fa-3568-0d70-c21703e2e06f@oracle.com> Message-ID: <0680F1AA-351F-405C-A73D-CDA217D66CFF@oracle.com> > On Jul 7, 2020, at 9:59 AM, Erik Joelsson wrote: > > Doc changes look good. > > /Erik > > On 2020-07-06 18:10, Kim Barrett wrote: >> I just noticed that doc/building.{md,html} describes minimum toolchain versions, >> so also needs to be updated. Here?s the update, matching what?s now in the JEP: >> >> full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/ >> incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/ >> >> I also deleted a discussion of a problem one might run into when building with >> Visual Studio 2010, since that version is no longer relevant. Thanks. From david.holmes at oracle.com Wed Jul 8 06:39:52 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Jul 2020 16:39:52 +1000 Subject: RFR: 8248403: AArch64: Remove uses of kernel integer types In-Reply-To: <801cd876-2d3a-69c9-b139-905fe21cd52f@redhat.com> References: <801cd876-2d3a-69c9-b139-905fe21cd52f@redhat.com> Message-ID: Hi Andrew, On 27/06/2020 1:40 am, Andrew Haley wrote: > In several places the AArch64 back end uses integer types from the kernel such as u_int32_t rather than the standard C type uint64_t. These should be removed. > > http://cr.openjdk.java.net/~aph/8248403/ That all looks good to me. Thanks, David ----- From Yang.Zhang at arm.com Wed Jul 8 07:05:09 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Wed, 8 Jul 2020 07:05:09 +0000 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com> Message-ID: Hi Andrew I have updated this patch. Could you please help to review it again? In this patch, the following changes are made: 1. Separate newly added NEON instructions to a new ad file aarch64_neon.ad 2. Add assembler tests for NEON instructions. Trailing spaces in the python script are also removed. http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ Thanks, Yang -----Original Message----- From: Andrew Haley Sent: Tuesday, June 30, 2020 12:10 AM To: Yang Zhang ; Viswanathan, Sandhya ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes On 29/06/2020 08:48, Yang Zhang wrote: > 1. Instructions that can be matched with NEON instructions directly. > MulVB, SqrtVF and AbsV have been merged into jdk master already. > > 2. Instructions that jdk master has middle end support for, but they cannot be matched with NEON instructions directly. > Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. > > 3. Panama/Vector API specific instructions such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. > These instructions cannot be moved into jdk master first because there isn't middle-end support. > > I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send it again. Thank you *very* much for your hard work. Appreciated! -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Wed Jul 8 07:29:25 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Jul 2020 17:29:25 +1000 Subject: RFR: 8248414: AArch64: Remove uses of long and unsigned long ints In-Reply-To: <46226794-abac-3248-85c7-f0e995f5f1eb@redhat.com> References: <46226794-abac-3248-85c7-f0e995f5f1eb@redhat.com> Message-ID: <5b5a0943-4dee-9178-8113-c49b72075639@oracle.com> Hi Andrew, On 27/06/2020 1:43 am, Andrew Haley wrote: > All of the uses of long and unsigned long int should be replaced with > more appropriate types. Where signed and unsigned 64-bit integers are > required, use int64_t. Where pointers are required, use > intptr_t. Where Java longs are required, use jlong. > > http://cr.openjdk.java.net/~aph/8248414/ Generally okay but a few comments/queries below. The change to add all the: + // This pattern is automatically generated from aarch64_ad.m4 + // DO NOT EDIT ANYTHING IN THIS SECTION OF THE FILE headers in the ad file made it much harder to spot the actual type changes. src/hotspot/cpu/aarch64/assembler_aarch64.cpp 1704 bool Assembler::operand_valid_for_add_sub_immediate(*int64_t* imm) { 1705 bool shift = false; 1706 *julong* uimm = uabs(imm); That seems a strange mix of C types and Java types --- src/hotspot/cpu/aarch64/assembler_aarch64.hpp int64_t offset = (dest - pc()) >> 2; It isn't immediately obvious to me why the offset should be signed in these cases whereas in other parts of the code offsets are unsigned. Just an observation though as you are not changing the signedness. --- src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp 136 Instruction_aarch64::patch(branch + 4, 20, 5, (uint64_t)target >> 32); 137 intptr_t dest = ((int64_t)target & 0xffffffffL) | ((int64_t)branch & 0xffff00000000L); 138 intptr_t pc_page = (int64_t)branch >> 12; 139 intptr_t adr_page = (int64_t)dest >> 12; There's an extra leading space on line 137. It's not obvious to me why the casts are to int64_t and the variable assigned to is intptr_t, especially when just up from this we have: 96 uint64_t dest = (uint64_t)target; 97 uint64_t pc_page = (uint64_t)branch >> 12; 98 uint64_t adr_page = (uint64_t)target >> 12; Also should those constants be LL for good measure? 1720 uint64_t mask = (1ul << shift) - 1; Making the mask 64-bit instead of 32-bit seems like a functional change. Also the 1ul should be 1ull shouldn't it? 4352 = (target & 0xffffffffUL) | ((uint64_t)pc() & 0xffff00000000UL); Should those constants be ULL? (they seem oddly expressed for 64-bit constants) --- src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp Not obvious why the constants should be Java types. --- src/hotspot/cpu/aarch64/macroAssembler_aarch64_trig.cpp Not obvious why the constants should be Java types. ! // * jlong double t,w,r_head, r_tail; The "long" is part of "long double" and shouldn't have been changed to jlong. --- src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! // However to make thing extra confusing. Because we can fit a jlong/double in ! // jlong/double in gpr I think it was clear from context that "long" was referring to the Java type. If you wanted to be sure I'd suggest writing "Java long/double". --- src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp montgomery_multiply: not at all clear why these should be julong --- Thanks, David ----- From aph at redhat.com Wed Jul 8 09:28:48 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Jul 2020 10:28:48 +0100 Subject: RFR: 8248414: AArch64: Remove uses of long and unsigned long ints In-Reply-To: <5b5a0943-4dee-9178-8113-c49b72075639@oracle.com> References: <46226794-abac-3248-85c7-f0e995f5f1eb@redhat.com> <5b5a0943-4dee-9178-8113-c49b72075639@oracle.com> Message-ID: On 08/07/2020 08:29, David Holmes wrote: > Hi Andrew, > > On 27/06/2020 1:43 am, Andrew Haley wrote: >> All of the uses of long and unsigned long int should be replaced with >> more appropriate types. Where signed and unsigned 64-bit integers are >> required, use int64_t. Where pointers are required, use >> intptr_t. Where Java longs are required, use jlong. >> >> http://cr.openjdk.java.net/~aph/8248414/ > > Generally okay but a few comments/queries below. > > The change to add all the: > > + // This pattern is automatically generated from aarch64_ad.m4 > + // DO NOT EDIT ANYTHING IN THIS SECTION OF THE FILE > > headers in the ad file made it much harder to spot the actual type changes. My apologies, but we've had several instances of people editing auto-generated patterns. I resolved to make the DO NOT EDIT changes next time anything in that part of the file changed. > src/hotspot/cpu/aarch64/assembler_aarch64.cpp > > 1704 bool Assembler::operand_valid_for_add_sub_immediate(*int64_t* imm) { > 1705 bool shift = false; > 1706 *julong* uimm = uabs(imm); > > That seems a strange mix of C types and Java types Ummm, true. I did it because uabs() is defined to take a jlong and return a julong. I will cast the returned value to uint64_t. > src/hotspot/cpu/aarch64/assembler_aarch64.hpp > > int64_t offset = (dest - pc()) >> 2; > > It isn't immediately obvious to me why the offset should be signed in > these cases whereas in other parts of the code offsets are unsigned. > Just an observation though as you are not changing the signedness. That's how the processor works: some offsets are signed, some are unsigned. I've tried to make it so that the signedness of the offset is always the signedness of the instruction. I may have made some mistakes in this area. > --- > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > > 136 Instruction_aarch64::patch(branch + 4, 20, 5, > (uint64_t)target >> 32); > 137 intptr_t dest = ((int64_t)target & 0xffffffffL) | > ((int64_t)branch & 0xffff00000000L); > 138 intptr_t pc_page = (int64_t)branch >> 12; > 139 intptr_t adr_page = (int64_t)dest >> 12; > > There's an extra leading space on line 137. OK. > It's not obvious to me why the casts are to int64_t and the variable > assigned to is intptr_t, especially when just up from this we have: It's not obvious to me either! I'll try to be more consistent. > 96 uint64_t dest = (uint64_t)target; > 97 uint64_t pc_page = (uint64_t)branch >> 12; > 98 uint64_t adr_page = (uint64_t)target >> 12; > > Also should those constants be LL for good measure? > > 1720 uint64_t mask = (1ul << shift) - 1; Yes! Well spotted. > Making the mask 64-bit instead of 32-bit seems like a functional change. > Also the 1ul should be 1ull shouldn't it? I'll take another look. I don't wany to make any functional changes in this patch. > 4352 = (target & 0xffffffffUL) | ((uint64_t)pc() & 0xffff00000000UL); > > Should those constants be ULL? (they seem oddly expressed for 64-bit > constants) OK. > --- > > src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp > > Not obvious why the constants should be Java types. > > --- > > src/hotspot/cpu/aarch64/macroAssembler_aarch64_trig.cpp > > Not obvious why the constants should be Java types. > > ! // * jlong double t,w,r_head, r_tail; > > The "long" is part of "long double" and shouldn't have been changed to > jlong. OK. > --- > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp > > ! // However to make thing extra confusing. Because we can fit a > jlong/double in > ! // jlong/double in gpr > > I think it was clear from context that "long" was referring to the Java > type. If you wanted to be sure I'd suggest writing "Java long/double". OK. Thank you for such a careful and heplful review. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Jul 8 09:49:35 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Jul 2020 10:49:35 +0100 Subject: RFR(S): 8247762: [aarch64] Timeout in .../HeapDumpTestWithActiveProcess.java due to inf. loop in AARCH64CurrentFrameGuess.run() In-Reply-To: <6322edbb-ab38-4956-6a29-5b1c3d48c132@oracle.com> References: <36c12487-cfc9-3823-c4a3-7605629beca5@redhat.com> <78a1d527-bd3f-6bc2-7880-ca5f34215267@oracle.com> <6322edbb-ab38-4956-6a29-5b1c3d48c132@oracle.com> Message-ID: <24bcb11a-ae3e-a29c-bcc0-a377eb90e19b@redhat.com> On 06/07/2020 20:54, Patric Hedlin wrote: > Andrew, > > Something you can live with? Totally. Great explanation too. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From patric.hedlin at oracle.com Wed Jul 8 10:07:14 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Wed, 8 Jul 2020 12:07:14 +0200 Subject: RFR(S): 8247762: [aarch64] Timeout in .../HeapDumpTestWithActiveProcess.java due to inf. loop in AARCH64CurrentFrameGuess.run() In-Reply-To: <24bcb11a-ae3e-a29c-bcc0-a377eb90e19b@redhat.com> References: <36c12487-cfc9-3823-c4a3-7605629beca5@redhat.com> <78a1d527-bd3f-6bc2-7880-ca5f34215267@oracle.com> <6322edbb-ab38-4956-6a29-5b1c3d48c132@oracle.com> <24bcb11a-ae3e-a29c-bcc0-a377eb90e19b@redhat.com> Message-ID: <0d569e36-5a8e-df1a-ab34-63ebe864f9ec@oracle.com> Thanks for reviewing Andrew. /Patric On 2020-07-08 11:49, Andrew Haley wrote: > On 06/07/2020 20:54, Patric Hedlin wrote: >> Andrew, >> >> Something you can live with? > Totally. Great explanation too. > From kim.barrett at oracle.com Wed Jul 8 17:32:40 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 8 Jul 2020 13:32:40 -0400 Subject: RFR: 8248403: AArch64: Remove uses of kernel integer types In-Reply-To: <801cd876-2d3a-69c9-b139-905fe21cd52f@redhat.com> References: <801cd876-2d3a-69c9-b139-905fe21cd52f@redhat.com> Message-ID: <693CB96C-D9A1-47F9-AE24-5D0B4D63C9E8@oracle.com> > On Jun 26, 2020, at 11:40 AM, Andrew Haley wrote: > > In several places the AArch64 back end uses integer types from the kernel such as u_int32_t rather than the standard C type uint64_t. These should be removed. > > http://cr.openjdk.java.net/~aph/8248403/ > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 Looks good. src/hotspot/cpu/aarch64/immediate_aarch64.cpp 147 int len; // ought to be <= 6 148 uint32_t levels; // 6 bits Changing the type of levels and followers moved the aligned comments to the left, leaving len's comment unaligned with the rest. From patric.hedlin at oracle.com Wed Jul 8 19:17:08 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Wed, 8 Jul 2020 21:17:08 +0200 Subject: RFR(M): 8245226: Clean-up FlagSetting and remove misuse. Message-ID: Dear all, I would like to ask for help to review the following change/update: Issue:? https://bugs.openjdk.java.net/browse/JDK-8245226 Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/ FlagSetting is sometimes used as a general mechanism for local save/modify and restore. This is not the intention (it should work as a red-flag when modifying debug options). Instead, use a general mechanism in these cases (introduced in here), and preserve FlagSetting for its intended purpose (including clean-up). Testing: hs-tier1-3 Best regards, Patric From nils.eliasson at oracle.com Wed Jul 8 20:10:27 2020 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 8 Jul 2020 22:10:27 +0200 Subject: RFR(M): 8245226: Clean-up FlagSetting and remove misuse. In-Reply-To: References: Message-ID: <2ce1a3c6-6781-a756-e434-51291876530e@oracle.com> Hi Patric, Nice clean-up! Looks good. Best regards, Nils On 2020-07-08 21:17, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8245226 > Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/ > > > FlagSetting is sometimes used as a general mechanism for local > save/modify and restore. This is not the intention (it should work as > a red-flag when modifying debug options). Instead, use a general > mechanism in these cases (introduced in here), and preserve > FlagSetting for its intended purpose (including clean-up). > > > Testing: hs-tier1-3 > > > Best regards, > Patric From patric.hedlin at oracle.com Thu Jul 9 08:16:09 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Thu, 9 Jul 2020 10:16:09 +0200 Subject: RFR(M): 8245226: Clean-up FlagSetting and remove misuse. In-Reply-To: <2ce1a3c6-6781-a756-e434-51291876530e@oracle.com> References: <2ce1a3c6-6781-a756-e434-51291876530e@oracle.com> Message-ID: Thanks for reviewing Nils. /Patric On 2020-07-08 22:10, Nils Eliasson wrote: > Hi Patric, > > Nice clean-up! > > Looks good. > > Best regards, > Nils > > On 2020-07-08 21:17, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8245226 >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/ >> >> >> FlagSetting is sometimes used as a general mechanism for local >> save/modify and restore. This is not the intention (it should work as >> a red-flag when modifying debug options). Instead, use a general >> mechanism in these cases (introduced in here), and preserve >> FlagSetting for its intended purpose (including clean-up). >> >> >> Testing: hs-tier1-3 >> >> >> Best regards, >> Patric > From david.holmes at oracle.com Thu Jul 9 09:09:13 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Jul 2020 19:09:13 +1000 Subject: RFR(M): 8245226: Clean-up FlagSetting and remove misuse. In-Reply-To: References: Message-ID: <754038df-25a5-e107-8881-5599628e9b28@oracle.com> Hi Patric, On 9/07/2020 5:17 am, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8245226 > Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/ > > > FlagSetting is sometimes used as a general mechanism for local > save/modify and restore. This is not the intention (it should work as a > red-flag when modifying debug options). Instead, use a general mechanism > in these cases (introduced in here), and preserve FlagSetting for its > intended purpose (including clean-up). Sorry but I'm not seeing why FlagSetting can't be used as a general mechanism even though it is described as being for debug flags. Introducing a similar mechanism seems redundant to me. Thanks, David > > Testing: hs-tier1-3 > > > Best regards, > Patric From patric.hedlin at oracle.com Thu Jul 9 11:56:52 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Thu, 9 Jul 2020 13:56:52 +0200 Subject: RFR(M): 8245226: Clean-up FlagSetting and remove misuse. In-Reply-To: <754038df-25a5-e107-8881-5599628e9b28@oracle.com> References: <754038df-25a5-e107-8881-5599628e9b28@oracle.com> Message-ID: <0baa3d37-6667-ce8f-b78c-d8b0ffa6f8e6@oracle.com> Hi David, On 2020-07-09 11:09, David Holmes wrote: > Hi Patric, > > On 9/07/2020 5:17 am, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8245226 >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/ >> >> >> FlagSetting is sometimes used as a general mechanism for local >> save/modify and restore. This is not the intention (it should work as >> a red-flag when modifying debug options). Instead, use a general >> mechanism in these cases (introduced in here), and preserve >> FlagSetting for its intended purpose (including clean-up). > > Sorry but I'm not seeing why FlagSetting can't be used as a general > mechanism even though it is described as being for debug flags. > Introducing a similar mechanism seems redundant to me. > Let me ask you this. How well do you think 'FlagSetting' describes the actual operation performed in the general use-case? Is it more clear than explicitly stating that you intend a save/modify and a restore in the local context? It is not as much about if it can be used as it is about if it should be used. The use of 'FlagSetting' and friends should be moved aside, given a new name (signalling the thin ice you are entering) and restricted to use on admissible flag/options only. I'm assuming you agree that modifying global options might have undesirable effects. But that can wait until after, or be part of, the rework. This part is about separating the use-cases. If you feel strongly about preserving 'FlagSetting' (and friends), please make your argument based on the merits of the current concept and implementation (such as the use of memcpy), not a dismissive "I don't see the point". /Patric From aph at redhat.com Thu Jul 9 13:04:03 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Jul 2020 14:04:03 +0100 Subject: RFR: 8248414: AArch64: Remove uses of long and unsigned long ints In-Reply-To: <5b5a0943-4dee-9178-8113-c49b72075639@oracle.com> References: <46226794-abac-3248-85c7-f0e995f5f1eb@redhat.com> <5b5a0943-4dee-9178-8113-c49b72075639@oracle.com> Message-ID: <6c44629c-6a05-dfa0-cd53-71d2df621cfe@redhat.com> New webrev at http://cr.openjdk.java.net/~aph/8248414-2 I think I've covered everything that was mentioned. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Jul 9 13:04:38 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Jul 2020 14:04:38 +0100 Subject: RFR: 8248414: AArch64: Remove uses of long and unsigned long ints In-Reply-To: <5b5a0943-4dee-9178-8113-c49b72075639@oracle.com> References: <46226794-abac-3248-85c7-f0e995f5f1eb@redhat.com> <5b5a0943-4dee-9178-8113-c49b72075639@oracle.com> Message-ID: <42c75096-90a3-20ca-461f-863476156548@redhat.com> On 08/07/2020 08:29, David Holmes wrote: > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp > > montgomery_multiply: not at all clear why these should be julong The digits are pairs of juints which represent 64-bit unsigned integers. This, in my mind, makes julong a natural fit. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Thu Jul 9 13:19:29 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 9 Jul 2020 09:19:29 -0400 Subject: [16] RFR(XS) Potential memory leak in TypedMethodOptionMatcher Message-ID: TypedMethodOptionMatcher owns ccstr value (vs. os::strdup_check_oom()), but never frees it in destructor. It does not appear to a real issue so far, because TypedMethodOptionMatcher seems immortal. Given it releases _option string, it should also release ccstr value. Webrev: http://cr.openjdk.java.net/~zgu/JDK-8249144/webrev.00/ Test: tier1_compiler on Linux x86_64 Submit test in progress Thanks, -Zhengyu From vladimir.kozlov at oracle.com Thu Jul 9 15:51:32 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 9 Jul 2020 08:51:32 -0700 Subject: [16] RFR(XS) Potential memory leak in TypedMethodOptionMatcher In-Reply-To: References: Message-ID: <255ca393-95bf-bc0c-8636-f9a523891801@oracle.com> Looks good. I thought about adding NULL check but ::free() accepts NULLs. NMT can also process NULL. Thanks, Vladimir On 7/9/20 6:19 AM, Zhengyu Gu wrote: > TypedMethodOptionMatcher owns ccstr value (vs. os::strdup_check_oom()), but never frees it in destructor. > > It does not appear to a real issue so far, because TypedMethodOptionMatcher seems immortal. Given it releases _option > string, it should also release ccstr value. > > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8249144/webrev.00/ > > Test: > ? tier1_compiler on Linux x86_64 > ? Submit test in progress > > Thanks, > > -Zhengyu > From beurba at microsoft.com Thu Jul 9 21:08:48 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Thu, 9 Jul 2020 21:08:48 +0000 Subject: RFR(XS) 8248671: AArch64: Remove unused variables Message-ID: Hello everyone, please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8248671 Webrev: http://cr.openjdk.java.net/~burban/8248671_unused-vars/ We found this issue while bringing up Windows+AArch64 support for HotSpot. The Microsoft toolchain (MSVC) seems to be slightly more pedantic than GCC. Thanks, -Bernhard From aph at redhat.com Fri Jul 10 08:11:13 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Jul 2020 09:11:13 +0100 Subject: [aarch64-port-dev ] RFR(XS) 8248671: AArch64: Remove unused variables In-Reply-To: References: Message-ID: <108fd979-c60c-11d1-f125-e8e67160d099@redhat.com> On 09/07/2020 22:08, Bernhard Urban-Forster wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8248671 > Webrev: http://cr.openjdk.java.net/~burban/8248671_unused-vars/ > > We found this issue while bringing up Windows+AArch64 support for HotSpot. The Microsoft toolchain (MSVC) seems to be slightly more pedantic than GCC. OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Jul 10 09:09:24 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Jul 2020 10:09:24 +0100 Subject: [aarch64-port-dev ] RFR: 8248414: AArch64: Remove uses of long and unsigned long ints In-Reply-To: References: Message-ID: <34aa0298-4772-3581-53d5-de9015617da1@redhat.com> On 09/07/2020 19:47, Bernhard Urban-Forster wrote: > > unfortunately I still can't sign up for the hotspot-dev mailing list > (we are working on it!), thus replying to aarch64-port-dev. Emails > are still hard in 2020 :-) > > Andrew and I had a private email conversation about this change, and > the latest one looks fine to me: > http://cr.openjdk.java.net/~aph/8248414-3/ (I'm not a reviewer > though). > > I tested it with our patch series applied on Windows+aarch64, and it > works fine. OK, thanks. http://cr.openjdk.java.net/~aph/8248414-3/ Incremental diff from the first version at: http://cr.openjdk.java.net/~aph/8248414-3-incremental.diff -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Sat Jul 11 14:00:07 2020 From: david.holmes at oracle.com (David Holmes) Date: Sun, 12 Jul 2020 00:00:07 +1000 Subject: RFR(M): 8245226: Clean-up FlagSetting and remove misuse. In-Reply-To: <0baa3d37-6667-ce8f-b78c-d8b0ffa6f8e6@oracle.com> References: <754038df-25a5-e107-8881-5599628e9b28@oracle.com> <0baa3d37-6667-ce8f-b78c-d8b0ffa6f8e6@oracle.com> Message-ID: <5f57316b-ed50-3300-c587-d7eb6ce245bc@oracle.com> On 9/07/2020 9:56 pm, Patric Hedlin wrote: > Hi David, > > On 2020-07-09 11:09, David Holmes wrote: >> Hi Patric, >> >> On 9/07/2020 5:17 am, Patric Hedlin wrote: >>> Dear all, >>> >>> I would like to ask for help to review the following change/update: >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245226 >>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/ >>> >>> >>> FlagSetting is sometimes used as a general mechanism for local >>> save/modify and restore. This is not the intention (it should work as >>> a red-flag when modifying debug options). Instead, use a general >>> mechanism in these cases (introduced in here), and preserve >>> FlagSetting for its intended purpose (including clean-up). >> >> Sorry but I'm not seeing why FlagSetting can't be used as a general >> mechanism even though it is described as being for debug flags. >> Introducing a similar mechanism seems redundant to me. >> > > Let me ask you this. How well do you think 'FlagSetting' describes the > actual operation performed in the general use-case? Is it more clear > than explicitly stating that you intend a save/modify and a restore in > the local context? It is not as much about if it can be used as it is > about if it should be used. The use of 'FlagSetting' and friends should > be moved aside, given a new name (signalling the thin ice you are > entering) and restricted to use on admissible flag/options only. I'm > assuming you agree that modifying global options might have undesirable > effects. But that can wait until after, or be part of, the rework. This > part is about separating the use-cases. If you feel strongly about > preserving 'FlagSetting' (and friends), please make your argument based > on the merits of the current concept and implementation (such as the use > of memcpy), not a dismissive "I don't see the point". Didn't intend to be dismissive, but if there is a bigger picture here then you needed to explain it - as you now have. I agree as a general mechanism FlagSetting is misnamed. So if the intent is to set it aside as a second step then that seems reasonable. Thanks, David > > /Patric > From kim.barrett at oracle.com Sat Jul 11 14:56:33 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 11 Jul 2020 10:56:33 -0400 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> Message-ID: <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> > On Jun 23, 2020, at 3:32 PM, Kim Barrett wrote: > > Please review / comment on this proposed update to the HotSpot Style > Guide. This is part of the work for JDK-8208089: JEP 347: Adopt C++14 > Language Features in the JDK. > > [?] Once > reviewed, the finished text can be used to update the wiki, unless we > decide it should be homed somewhere else. There has recently been a lot of discussion about where this and somewhat similar documents should reside. Most of that has been about a Java Style Guide, which has somewhat different issues than this one. (The HotSpot Style Guide is very focused in scope, and is unlikely to have much, if any, influence on usage by the wider C++ community.) Proposed homes include: - Remain in the OpenJDK wiki. - Use an informational JEP. - Move to the new Developer's Guide. - Move to the JDK repository. For some of the discussion, see comments in JDK-8208089, as well as the recent thread on the jdk-dev mailing list: https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004443.html https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004461.html Based on that discussion, I'm planning to move it to the JDK repository, in jdk/jdk/doc. That is already a place for developer-focused documentation; it's the home of building.{md,html}, testing.{md,html}, and ide.{md,html}. I think this style guide fits well with that collection. I think the other two wiki pages associated with the current wiki HotSpot Style Guide would similarly fit well there, and I suggest we move them as well. Comments? From jesper.wilhelmsson at oracle.com Sat Jul 11 18:08:03 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Sat, 11 Jul 2020 20:08:03 +0200 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> Message-ID: <8FFB004A-0455-4FB0-A87B-DDC5D6C0E8A3@oracle.com> > On 11 Jul 2020, at 16:56, Kim Barrett wrote: > >> On Jun 23, 2020, at 3:32 PM, Kim Barrett wrote: >> >> Please review / comment on this proposed update to the HotSpot Style >> Guide. This is part of the work for JDK-8208089: JEP 347: Adopt C++14 >> Language Features in the JDK. >> >> [?] Once >> reviewed, the finished text can be used to update the wiki, unless we >> decide it should be homed somewhere else. > > There has recently been a lot of discussion about where this and > somewhat similar documents should reside. Most of that has been about > a Java Style Guide, which has somewhat different issues than this one. > (The HotSpot Style Guide is very focused in scope, and is unlikely to > have much, if any, influence on usage by the wider C++ community.) > > Proposed homes include: > > - Remain in the OpenJDK wiki. > - Use an informational JEP. > - Move to the new Developer's Guide. > - Move to the JDK repository. > > For some of the discussion, see comments in JDK-8208089, as well as > the recent thread on the jdk-dev mailing list: > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004443.html > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004461.html > > Based on that discussion, I'm planning to move it to the JDK > repository, in jdk/jdk/doc. That is already a place for > developer-focused documentation; it's the home of building.{md,html}, > testing.{md,html}, and ide.{md,html}. I think this style guide fits > well with that collection. I agree. jdk/jdk/doc is a good place for the C++ style guide. > I think the other two wiki pages associated with the current wiki > HotSpot Style Guide would similarly fit well there, and I suggest we > move them as well. +1 /Jesper > > Comments? > From kim.barrett at oracle.com Sun Jul 12 01:41:43 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 11 Jul 2020 21:41:43 -0400 Subject: CFV: New HotSpot Group Member: Stefan Johansson Message-ID: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> I hereby nominate Stefan Johansson to Membership in the HotSpot Group. Stefan has been a JDK Reviewer and member of the Oracle GC team for many years, primarily working on G1. He has made many substantial contributions [1] including the Parallel Full GC for G1 and G1 Abortable Mixed Collections. Votes are due by Sunday, 26-July-2020 at 12h00 UTC. Only current Members of the HotSpot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [3]. Kim Barrett [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() [2] https://openjdk.java.net/census [3] https://openjdk.java.net/groups/#member-vote From jesper.wilhelmsson at oracle.com Sun Jul 12 09:27:39 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Sun, 12 Jul 2020 11:27:39 +0200 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: <98550DF7-CFBD-40F1-A2C2-3450A14E3132@oracle.com> Vote: Yes /Jesper > On 12 Jul 2020, at 03:41, Kim Barrett wrote: > > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > From thomas.schatzl at oracle.com Sun Jul 12 10:52:31 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Sun, 12 Jul 2020 12:52:31 +0200 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: <939ad703-1d53-658a-02be-b1cbca6b8965@oracle.com> Vote: yes On 12.07.20 03:41, Kim Barrett wrote: > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > From daniel.daugherty at oracle.com Sun Jul 12 13:04:21 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 12 Jul 2020 09:04:21 -0400 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: <4df71429-6171-ca7a-b9b2-0ebcc9b5adfd@oracle.com> Vote: yes Dan On 7/11/20 9:41 PM, Kim Barrett wrote: > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > From vladimir.kozlov at oracle.com Sun Jul 12 19:03:42 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 12 Jul 2020 12:03:42 -0700 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: <2a891fd3-fb02-f1b5-7c9e-225a4b4bd1aa@oracle.com> Vote: yes On 7/11/20 6:41 PM, Kim Barrett wrote: > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > From mikael.vidstedt at oracle.com Sun Jul 12 22:11:03 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Sun, 12 Jul 2020 15:11:03 -0700 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: <35CBC7BA-DB76-48C4-9193-5F03B2116E82@oracle.com> Vote: yes Cheers, Mikael > On Jul 11, 2020, at 6:41 PM, Kim Barrett wrote: > > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > From david.holmes at oracle.com Sun Jul 12 23:14:05 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jul 2020 09:14:05 +1000 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: <38bfcbd7-01c7-f461-b279-6a3a5ca95764@oracle.com> Vote: yes David On 12/07/2020 11:41 am, Kim Barrett wrote: > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > From david.holmes at oracle.com Mon Jul 13 00:43:33 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jul 2020 10:43:33 +1000 Subject: RFR(M): 8245226: Clean-up FlagSetting and remove misuse. In-Reply-To: <5f57316b-ed50-3300-c587-d7eb6ce245bc@oracle.com> References: <754038df-25a5-e107-8881-5599628e9b28@oracle.com> <0baa3d37-6667-ce8f-b78c-d8b0ffa6f8e6@oracle.com> <5f57316b-ed50-3300-c587-d7eb6ce245bc@oracle.com> Message-ID: Hi Patric, On 12/07/2020 12:00 am, David Holmes wrote: > On 9/07/2020 9:56 pm, Patric Hedlin wrote: >> Hi David, >> >> On 2020-07-09 11:09, David Holmes wrote: >>> Hi Patric, >>> >>> On 9/07/2020 5:17 am, Patric Hedlin wrote: >>>> Dear all, >>>> >>>> I would like to ask for help to review the following change/update: >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245226 >>>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/ >>>> >>>> >>>> FlagSetting is sometimes used as a general mechanism for local >>>> save/modify and restore. This is not the intention (it should work >>>> as a red-flag when modifying debug options). Instead, use a general >>>> mechanism in these cases (introduced in here), and preserve >>>> FlagSetting for its intended purpose (including clean-up). >>> >>> Sorry but I'm not seeing why FlagSetting can't be used as a general >>> mechanism even though it is described as being for debug flags. >>> Introducing a similar mechanism seems redundant to me. >>> >> >> Let me ask you this. How well do you think 'FlagSetting' describes the >> actual operation performed in the general use-case? Is it more clear >> than explicitly stating that you intend a save/modify and a restore in >> the local context? It is not as much about if it can be used as it is >> about if it should be used. The use of 'FlagSetting' and friends >> should be moved aside, given a new name (signalling the thin ice you >> are entering) and restricted to use on admissible flag/options only. >> I'm assuming you agree that modifying global options might have >> undesirable effects. But that can wait until after, or be part of, the >> rework. This part is about separating the use-cases. If you feel >> strongly about preserving 'FlagSetting' (and friends), please make >> your argument based on the merits of the current concept and >> implementation (such as the use of memcpy), not a dismissive "I don't >> see the point". > > Didn't intend to be dismissive, but if there is a bigger picture here > then you needed to explain it - as you now have. I agree as a general > mechanism FlagSetting is misnamed. So if the intent is to set it aside > as a second step then that seems reasonable. I don't know what I thought I saw when I initially looked at this, but what I see now is not what I thought. My apologies for that. I'm not sure that defining FLAG_GUARD purely as a means to introduce a temporary variable name that isn't even visible to the reader, serves a useful purpose. If it can't retain its existing functionality of being a full declaration then I would suggest just dropping it. Thanks, David > Thanks, > David > >> >> /Patric >> From david.holmes at oracle.com Mon Jul 13 04:07:35 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jul 2020 14:07:35 +1000 Subject: RFR(XS) 8248671: AArch64: Remove unused variables In-Reply-To: References: Message-ID: <1c652b56-2476-ede0-47f8-13c4e99639d0@oracle.com> Hi Bernhard, On 10/07/2020 7:08 am, Bernhard Urban-Forster wrote: > Hello everyone, > > > please review this change: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248671 > Webrev: http://cr.openjdk.java.net/~burban/8248671_unused-vars/ > > We found this issue while bringing up Windows+AArch64 support for HotSpot. The Microsoft toolchain (MSVC) seems to be slightly more pedantic than GCC. Looks good and trivial. But could I request that webrevs/patches for mainline be generated against the mainline hg repository rather than the git mirror. Thanks, David > > Thanks, > -Bernhard > From igor.ignatyev at oracle.com Mon Jul 13 04:19:26 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 12 Jul 2020 21:19:26 -0700 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: > On Jul 11, 2020, at 6:41 PM, Kim Barrett wrote: > > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. Vote: yes -- Igor From volker.simonis at gmail.com Mon Jul 13 07:32:07 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 13 Jul 2020 09:32:07 +0200 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: Vote: yes On Sun, Jul 12, 2020 at 3:42 AM Kim Barrett wrote: > > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > From goetz.lindenmaier at sap.com Mon Jul 13 07:56:22 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 Jul 2020 07:56:22 +0000 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: Vote: yes Best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of Kim > Barrett > Sent: Sunday, July 12, 2020 3:42 AM > To: hotspot-dev developers > Subject: CFV: New HotSpot Group Member: Stefan Johansson > > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss > )+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote From adinn at redhat.com Mon Jul 13 09:48:07 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 13 Jul 2020 10:48:07 +0100 Subject: [aarch64-port-dev ] RFR: 8248414: AArch64: Remove uses of long and unsigned long ints In-Reply-To: <34aa0298-4772-3581-53d5-de9015617da1@redhat.com> References: <34aa0298-4772-3581-53d5-de9015617da1@redhat.com> Message-ID: <8c3f5ab3-5075-bd00-7116-49b380948780@redhat.com> Hi Andrew, On 10/07/2020 10:09, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8248414-3/ > > Incremental diff from the first version at: > > http://cr.openjdk.java.net/~aph/8248414-3-incremental.diff The patch looks fine except for this one change at assembler_aarch64.hpp:673 void f(unsigned val, int msb) { current->f(val, msb, msb); } - void sf(long val, int msb, int lsb) { + void sf(uint64_t val, int msb, int lsb) { current->sf(val, msb, lsb); } I think val ought to be declared as int64_t. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From zgu at redhat.com Mon Jul 13 12:21:42 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 13 Jul 2020 08:21:42 -0400 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: Vote: yes -Zhengyu On 7/11/20 9:41 PM, Kim Barrett wrote: > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > From coleen.phillimore at oracle.com Mon Jul 13 13:39:20 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 13 Jul 2020 13:39:20 +0000 (UTC) Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: <22e21f71-8120-28f7-1bb6-8411a5fada65@oracle.com> Vote: yes On 7/11/20 9:41 PM, Kim Barrett wrote: > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > From ChrisPhi at LGonQn.Org Mon Jul 13 13:39:05 2020 From: ChrisPhi at LGonQn.Org ("Chris Phillips"@T O) Date: Mon, 13 Jul 2020 09:39:05 -0400 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: <76c08925-3a32-37f3-d202-cc33a16c9138@LGonQn.Org> On 11/07/20 09:41 PM, Kim Barrett wrote: > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > > > > Vote: yes Cheers! ChrisPhi From beurba at microsoft.com Mon Jul 13 14:03:57 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Mon, 13 Jul 2020 14:03:57 +0000 Subject: RFR(XS) 8248671: AArch64: Remove unused variables In-Reply-To: <1c652b56-2476-ede0-47f8-13c4e99639d0@oracle.com> References: <1c652b56-2476-ede0-47f8-13c4e99639d0@oracle.com> Message-ID: Thank you for your review Andrew and David. Here is the webrev based on https://hg.openjdk.java.net/jdk/jdk/: http://cr.openjdk.java.net/~burban/8248671_hg/ Thanks, -Bernhard > -----Original Message----- > From: David Holmes > Sent: Monday, July 13, 2020 6:08 AM > To: Bernhard Urban-Forster ; aarch64-port- > dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(XS) 8248671: AArch64: Remove unused variables > > Hi Bernhard, > > On 10/07/2020 7:08 am, Bernhard Urban-Forster wrote: > > Hello everyone, > > > > > > please review this change: > > > > JBS: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > > .openjdk.java.net%2Fbrowse%2FJDK- > 8248671&data=02%7C01%7Cbeurba%40m > > > icrosoft.com%7Cfa08ce93e8d44b4f38a708d826e296ed%7C72f988bf86f141af > 91ab > > > 2d7cd011db47%7C1%7C0%7C637302101922573034&sdata=Bv6Fsw104 > ZizId5EdC > > %2BTnV8DrJCJyQzVk9ht6rWjLMw%3D&reserved=0 > > Webrev: > > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open > > jdk.java.net%2F~burban%2F8248671_unused- > vars%2F&data=02%7C01%7Cbeu > > > rba%40microsoft.com%7Cfa08ce93e8d44b4f38a708d826e296ed%7C72f988bf > 86f14 > > > 1af91ab2d7cd011db47%7C1%7C0%7C637302101922573034&sdata=X7 > 7Ri2iWLkm > > %2FOSmdP9HyEWEwMA7rO%2BM6oKVRAg4zHGQ%3D&reserved=0 > > > > We found this issue while bringing up Windows+AArch64 support for > HotSpot. The Microsoft toolchain (MSVC) seems to be slightly more pedantic > than GCC. > > Looks good and trivial. > > But could I request that webrevs/patches for mainline be generated against the > mainline hg repository rather than the git mirror. > > Thanks, > David > > > > > Thanks, > > -Bernhard > > From patric.hedlin at oracle.com Mon Jul 13 14:49:24 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Mon, 13 Jul 2020 16:49:24 +0200 Subject: RFR(M): 8245226: Clean-up FlagSetting and remove misuse. In-Reply-To: References: <754038df-25a5-e107-8881-5599628e9b28@oracle.com> <0baa3d37-6667-ce8f-b78c-d8b0ffa6f8e6@oracle.com> <5f57316b-ed50-3300-c587-d7eb6ce245bc@oracle.com> Message-ID: Hi David On 2020-07-13 02:43, David Holmes wrote: > Hi Patric, > > < . . . > >>>>> I would like to ask for help to review the following change/update: >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245226 >>>>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/ >>>>> >>>>> >>>>> FlagSetting is sometimes used as a general mechanism for local >>>>> save/modify and restore. This is not the intention (it should work >>>>> as a red-flag when modifying debug options). Instead, use a >>>>> general mechanism in these cases (introduced in here), and >>>>> preserve FlagSetting for its intended purpose (including clean-up). >>>> >>>> Sorry but I'm not seeing why FlagSetting can't be used as a general >>>> mechanism even though it is described as being for debug flags. >>>> Introducing a similar mechanism seems redundant to me. >>>> >>> >>> Let me ask you this. How well do you think 'FlagSetting' describes >>> the actual operation performed in the general use-case? Is it more >>> clear than explicitly stating that you intend a save/modify and a >>> restore in the local context? It is not as much about if it can be >>> used as it is about if it should be used. The use of 'FlagSetting' >>> and friends should be moved aside, given a new name (signalling the >>> thin ice you are entering) and restricted to use on admissible >>> flag/options only. I'm assuming you agree that modifying global >>> options might have undesirable effects. But that can wait until >>> after, or be part of, the rework. This part is about separating the >>> use-cases. If you feel strongly about preserving 'FlagSetting' (and >>> friends), please make your argument based on the merits of the >>> current concept and implementation (such as the use of memcpy), not >>> a dismissive "I don't see the point". >> >> Didn't intend to be dismissive, but if there is a bigger picture here >> then you needed to explain it - as you now have. I agree as a general >> mechanism FlagSetting is misnamed. So if the intent is to set it >> aside as a second step then that seems reasonable. > > I don't know what I thought I saw when I initially looked at this, but > what I see now is not what I thought. My apologies for that. > No need David. I just want the sharper end of your reviews. > I'm not sure that defining FLAG_GUARD purely as a means to introduce a > temporary variable name that isn't even visible to the reader, serves > a useful purpose. If it can't retain its existing functionality of > being a full declaration then I would suggest just dropping it. I agree it should be removed, but at a later time, with the rest of the file. After (at least) a little thought, I decided to let it remain in the code as a "warning", of use both brittle and ugly. Its use leads back to "flagSetting.hpp" (as do *FlagSetting), with a documented legacy purpose and it identifies (if nothing else) a number of "suspects". I will simply add a clarifying comment. Thanks David. /Patric From aph at redhat.com Mon Jul 13 16:55:36 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Jul 2020 17:55:36 +0100 Subject: [aarch64-port-dev ] RFR: 8248414: AArch64: Remove uses of long and unsigned long ints In-Reply-To: <8c3f5ab3-5075-bd00-7116-49b380948780@redhat.com> References: <34aa0298-4772-3581-53d5-de9015617da1@redhat.com> <8c3f5ab3-5075-bd00-7116-49b380948780@redhat.com> Message-ID: On 13/07/2020 10:48, Andrew Dinn wrote: > The patch looks fine except for this one change at assembler_aarch64.hpp:673 > > void f(unsigned val, int msb) { > current->f(val, msb, msb); > } > - void sf(long val, int msb, int lsb) { > + void sf(uint64_t val, int msb, int lsb) { > current->sf(val, msb, lsb); > } > > I think val ought to be declared as int64_t. Wow! How did I miss that one? Well spotted. Is it OK with that change? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Jul 13 17:42:00 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 13 Jul 2020 18:42:00 +0100 Subject: [aarch64-port-dev ] RFR: 8248414: AArch64: Remove uses of long and unsigned long ints In-Reply-To: References: <34aa0298-4772-3581-53d5-de9015617da1@redhat.com> <8c3f5ab3-5075-bd00-7116-49b380948780@redhat.com> Message-ID: On 13/07/2020 17:55, Andrew Haley wrote: > On 13/07/2020 10:48, Andrew Dinn wrote: >> The patch looks fine except for this one change at assembler_aarch64.hpp:673 >> >> void f(unsigned val, int msb) { >> current->f(val, msb, msb); >> } >> - void sf(long val, int msb, int lsb) { >> + void sf(uint64_t val, int msb, int lsb) { >> current->sf(val, msb, lsb); >> } >> >> I think val ought to be declared as int64_t. > > Wow! How did I miss that one? Well spotted. > > Is it OK with that change? Yes, that was the only issue. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From chris.hegarty at oracle.com Mon Jul 13 18:01:58 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 Jul 2020 19:01:58 +0100 Subject: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> Message-ID: <5C553417-8DED-41A7-AEE5-5366BAA66EAA@oracle.com> > On 1 Apr 2020, at 23:46, Paul Sandoz wrote: > > Hi, > > A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html > > This email expands the review of the API to the Java implementation and Java tests: > > http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ > > http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ Overall the code seems very well structured, very repetitive (similar to any of these implementations that are generated from templates). From what I know of the concepts, the approach seems sound and clearly deliberate (with performance in mind). The API surfaces seems large at first glance (and it is), but once the reader gets the concepts clear in their head I think it kinda works well (albeit obviously low-level). I?m happy to see the use of asserts in several places the code. I know that they are not always enabled, but they are at least in our testing. There are a bunch of FIXMEs in AbstractMask which look like they could be (easily?) resolved, but maybe they need perf analysis before doing that? Silly repetitive typo in the X-Vector.java template spills into several javadocs, so I cannot resist: * This is not a full-service named operation like * {@link #add(Vector) add}. A masked ****version of**** * version of this operation is not directly available * but may be obtained via the masked version of * {@code lanewise}. -Chris. From calvin.cheung at oracle.com Mon Jul 13 18:18:21 2020 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 13 Jul 2020 11:18:21 -0700 Subject: CFV: New HotSpot Group Member: Stefan Johansson In-Reply-To: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> References: <7F4AFC8C-A632-4203-B3FD-E39A50118785@oracle.com> Message-ID: Vote: yes On 7/11/20 6:41 PM, Kim Barrett wrote: > I hereby nominate Stefan Johansson to Membership in the HotSpot > Group. > > Stefan has been a JDK Reviewer and member of the Oracle GC team for > many years, primarily working on G1. He has made many substantial > contributions [1] including the Parallel Full GC for G1 and G1 > Abortable Mixed Collections. > > Votes are due by Sunday, 26-July-2020 at 12h00 UTC. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > Kim Barrett > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/groups/#member-vote > From hohensee at amazon.com Mon Jul 13 18:38:54 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 13 Jul 2020 18:38:54 +0000 Subject: CFV: New HotSpot Group Member: Stefan Johansson Message-ID: Vote: yes ?On 7/11/20, 6:42 PM, "hotspot-dev on behalf of Kim Barrett" wrote: I hereby nominate Stefan Johansson to Membership in the HotSpot Group. Stefan has been a JDK Reviewer and member of the Oracle GC team for many years, primarily working on G1. He has made many substantial contributions [1] including the Parallel Full GC for G1 and G1 Abortable Mixed Collections. Votes are due by Sunday, 26-July-2020 at 12h00 UTC. Only current Members of the HotSpot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [3]. Kim Barrett [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sjohanss)+or+desc(%22stefan.johansson%40oracle.com%22))+and+not+merge() [2] https://openjdk.java.net/census [3] https://openjdk.java.net/groups/#member-vote From mikael.vidstedt at oracle.com Mon Jul 13 19:02:14 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 13 Jul 2020 12:02:14 -0700 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> Message-ID: <02DBFA16-D399-4E96-B143-B04F53E8F46E@oracle.com> > On Jul 11, 2020, at 7:56 AM, Kim Barrett wrote: > >> On Jun 23, 2020, at 3:32 PM, Kim Barrett wrote: >> >> Please review / comment on this proposed update to the HotSpot Style >> Guide. This is part of the work for JDK-8208089: JEP 347: Adopt C++14 >> Language Features in the JDK. >> >> [?] Once >> reviewed, the finished text can be used to update the wiki, unless we >> decide it should be homed somewhere else. > > There has recently been a lot of discussion about where this and > somewhat similar documents should reside. Most of that has been about > a Java Style Guide, which has somewhat different issues than this one. > (The HotSpot Style Guide is very focused in scope, and is unlikely to > have much, if any, influence on usage by the wider C++ community.) > > Proposed homes include: > > - Remain in the OpenJDK wiki. > - Use an informational JEP. > - Move to the new Developer's Guide. > - Move to the JDK repository. > > For some of the discussion, see comments in JDK-8208089, as well as > the recent thread on the jdk-dev mailing list: > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004443.html > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004461.html > > Based on that discussion, I'm planning to move it to the JDK > repository, in jdk/jdk/doc. That is already a place for > developer-focused documentation; it's the home of building.{md,html}, > testing.{md,html}, and ide.{md,html}. I think this style guide fits > well with that collection. > > I think the other two wiki pages associated with the current wiki > HotSpot Style Guide would similarly fit well there, and I suggest we > move them as well. > > Comments? I think that?s a great new home! Cheers, Mikael From igor.ignatyev at oracle.com Mon Jul 13 21:29:18 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 13 Jul 2020 14:29:18 -0700 Subject: RFR [15] : 8249036 : clean up FileInstaller $test.src $cwd in vmTestbase_nsk_stress tests Message-ID: <5E2ED18E-9CD6-44D6-95D0-E13D1AFC1BC3@oracle.com> http://cr.openjdk.java.net/~iignatyev//8249036/webrev.00/ > 44 lines changed: 0 ins; 23 del; 21 mod; Hi all, could you please review this clean-up which removes unnecessary `FileInstaller` actions for :vmTestbase_nsk_stress tests? from the main issue(8204985): > all vmTestbase tests have '@run driver jdk.test.lib.FileInstaller . .' to mimic old test harness behavior and copy all files from a test source directory to a current work directory. some tests depend on this step, so we need 1st identify such tests and then either rewrite them not to have this dependency or leave FileInstaller only in these tests. none of vmTestbase_nsk_stress tests need FileInstaller, hence the patch is just `ag -l '@run driver jdk.test.lib.FileInstaller . .' vmTestbase/nsk/stress xargs -I{} gsed -i '/@run driver jdk.test.lib.FileInstaller \. \./d' {}`. JBS: https://bugs.openjdk.java.net/browse/JDK-8249036 webrev: http://cr.openjdk.java.net/~iignatyev//8249036/webrev.00/ testing: :vmTestbase_nsk_stress on linux-x64 Thanks, -- Igor From vladimir.kozlov at oracle.com Mon Jul 13 21:34:06 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Jul 2020 14:34:06 -0700 Subject: RFR [15] : 8249036 : clean up FileInstaller $test.src $cwd in vmTestbase_nsk_stress tests In-Reply-To: <5E2ED18E-9CD6-44D6-95D0-E13D1AFC1BC3@oracle.com> References: <5E2ED18E-9CD6-44D6-95D0-E13D1AFC1BC3@oracle.com> Message-ID: <5720357e-c3c6-6f7f-7993-535561fd84e2@oracle.com> Good. Thanks, Vladimir K On 7/13/20 2:29 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8249036/webrev.00/ >> 44 lines changed: 0 ins; 23 del; 21 mod; > > Hi all, > > could you please review this clean-up which removes unnecessary `FileInstaller` actions for :vmTestbase_nsk_stress tests? > from the main issue(8204985): >> all vmTestbase tests have '@run driver jdk.test.lib.FileInstaller . .' to mimic old test harness behavior and copy all files from a test source directory to a current work directory. some tests depend on this step, so we need 1st identify such tests and then either rewrite them not to have this dependency or leave FileInstaller only in these tests. > > none of vmTestbase_nsk_stress tests need FileInstaller, hence the patch is just `ag -l '@run driver jdk.test.lib.FileInstaller . .' vmTestbase/nsk/stress xargs -I{} gsed -i '/@run driver jdk.test.lib.FileInstaller \. \./d' {}`. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8249036 > webrev: http://cr.openjdk.java.net/~iignatyev//8249036/webrev.00/ > testing: :vmTestbase_nsk_stress on linux-x64 > > Thanks, > -- Igor > From paul.sandoz at oracle.com Mon Jul 13 21:59:17 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 13 Jul 2020 14:59:17 -0700 Subject: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: <5C553417-8DED-41A7-AEE5-5366BAA66EAA@oracle.com> References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> <5C553417-8DED-41A7-AEE5-5366BAA66EAA@oracle.com> Message-ID: <64735010-6681-4C24-845E-7398CB4CBA73@oracle.com> Hi Chris, Thank you for jumping in at the deep end and reviewing. I fixed the typos and sent a review of a patch on the panama-dev list [1], to be pushed in the panama repo and rolled back in to patches at some point, likely with other updates to expand testing to cover more API points. Operations on masks and mask accepting vector operations require more work, as you rightly observed! Both are not trivial and will need deeper intrinsic work after incubation. A particular challenge is the three different kinds of architecture, x64 AVX2 and aarch64 NEON, x64 AVX512, and aarch64 SVE. These architectures affect how a mask is represented in hardware registers and how masked operations are translated to hardware instructions. Paul. [1] https://mail.openjdk.java.net/pipermail/panama-dev/2020-July/009860.html > On Jul 13, 2020, at 11:01 AM, Chris Hegarty wrote: > >> >> On 1 Apr 2020, at 23:46, Paul Sandoz > wrote: >> >> Hi, >> >> A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target: >> >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html > >> >> This email expands the review of the API to the Java implementation and Java tests: >> >> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ > >> >> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ > > > Overall the code seems very well structured, very repetitive (similar to any of these implementations that are generated from templates). From what I know of the concepts, the approach seems sound and clearly deliberate (with performance in mind). > > The API surfaces seems large at first glance (and it is), but once the reader gets the concepts clear in their head I think it kinda works well (albeit obviously low-level). > > I?m happy to see the use of asserts in several places the code. I know that they are not always enabled, but they are at least in our testing. > > There are a bunch of FIXMEs in AbstractMask which look like they could be (easily?) resolved, but maybe they need perf analysis before doing that? > > Silly repetitive typo in the X-Vector.java template spills into several javadocs, so I cannot resist: > * This is not a full-service named operation like > * {@link #add(Vector) add}. A masked ****version of**** > * version of this operation is not directly available > * but may be obtained via the masked version of > * {@code lanewise}. > > -Chris. From david.holmes at oracle.com Tue Jul 14 03:39:57 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jul 2020 13:39:57 +1000 Subject: RFR(M): 8245226: Clean-up FlagSetting and remove misuse. In-Reply-To: References: <754038df-25a5-e107-8881-5599628e9b28@oracle.com> <0baa3d37-6667-ce8f-b78c-d8b0ffa6f8e6@oracle.com> <5f57316b-ed50-3300-c587-d7eb6ce245bc@oracle.com> Message-ID: <4d04a0cf-3b2d-44f8-44ae-54c09f25ce12@oracle.com> Hi Patric, On 14/07/2020 12:49 am, Patric Hedlin wrote: > Hi David > > On 2020-07-13 02:43, David Holmes wrote: >> Hi Patric, >> >> < . . . > >>>>>> I would like to ask for help to review the following change/update: >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245226 >>>>>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/ >>>>>> >>>>>> >>>>>> FlagSetting is sometimes used as a general mechanism for local >>>>>> save/modify and restore. This is not the intention (it should work >>>>>> as a red-flag when modifying debug options). Instead, use a >>>>>> general mechanism in these cases (introduced in here), and >>>>>> preserve FlagSetting for its intended purpose (including clean-up). >>>>> >>>>> Sorry but I'm not seeing why FlagSetting can't be used as a general >>>>> mechanism even though it is described as being for debug flags. >>>>> Introducing a similar mechanism seems redundant to me. >>>>> >>>> >>>> Let me ask you this. How well do you think 'FlagSetting' describes >>>> the actual operation performed in the general use-case? Is it more >>>> clear than explicitly stating that you intend a save/modify and a >>>> restore in the local context? It is not as much about if it can be >>>> used as it is about if it should be used. The use of 'FlagSetting' >>>> and friends should be moved aside, given a new name (signalling the >>>> thin ice you are entering) and restricted to use on admissible >>>> flag/options only. I'm assuming you agree that modifying global >>>> options might have undesirable effects. But that can wait until >>>> after, or be part of, the rework. This part is about separating the >>>> use-cases. If you feel strongly about preserving 'FlagSetting' (and >>>> friends), please make your argument based on the merits of the >>>> current concept and implementation (such as the use of memcpy), not >>>> a dismissive "I don't see the point". >>> >>> Didn't intend to be dismissive, but if there is a bigger picture here >>> then you needed to explain it - as you now have. I agree as a general >>> mechanism FlagSetting is misnamed. So if the intent is to set it >>> aside as a second step then that seems reasonable. >> >> I don't know what I thought I saw when I initially looked at this, but >> what I see now is not what I thought. My apologies for that. >> > No need David. I just want the sharper end of your reviews. > >> I'm not sure that defining FLAG_GUARD purely as a means to introduce a >> temporary variable name that isn't even visible to the reader, serves >> a useful purpose. If it can't retain its existing functionality of >> being a full declaration then I would suggest just dropping it. > > I agree it should be removed, but at a later time, with the rest of the > file. After (at least) a little thought, I decided to let it remain in > the code as a "warning", of use both brittle and ugly. Its use leads > back to "flagSetting.hpp" (as do *FlagSetting), with a documented legacy > purpose and it identifies (if nothing else) a number of "suspects". I > will simply add a clarifying comment. Given it is only used in test code and given you have already changed things like: FLAG_GUARD(MinHeapSize); to AutoSaveRestore FLAG_GUARD(MinHeapSize); it seems a simple step to just remove FLAG_GUARD altogether: AutoSaveRestore _guard1(MinHeapSize); But your call. Thanks, David > > Thanks David. > > /Patric From ioi.lam at oracle.com Tue Jul 14 15:51:11 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 14 Jul 2020 08:51:11 -0700 Subject: RFR(M): 8245226: Clean-up FlagSetting and remove misuse. In-Reply-To: <4d04a0cf-3b2d-44f8-44ae-54c09f25ce12@oracle.com> References: <754038df-25a5-e107-8881-5599628e9b28@oracle.com> <0baa3d37-6667-ce8f-b78c-d8b0ffa6f8e6@oracle.com> <5f57316b-ed50-3300-c587-d7eb6ce245bc@oracle.com> <4d04a0cf-3b2d-44f8-44ae-54c09f25ce12@oracle.com> Message-ID: <380d2795-e188-f4f0-b913-c0fffc3bd60d@oracle.com> The webrev looks OK to me. I would suggest using a name like PreserveFlag to be consistent with existing classes ./share/adlc/forms.hpp:class PreserveIter { ./share/gc/serial/markSweep.hpp:class PreservedMark { ./share/gc/shared/preservedMarks.hpp:class PreservedMarks { ./share/gc/shared/preservedMarks.hpp:class PreservedMarksSet : public CHeapObj { ./share/utilities/preserveException.hpp:class PreserveExceptionMark { ./share/utilities/preserveException.hpp:class CautiouslyPreserveExceptionMark { ./share/utilities/preserveException.hpp:class WeakPreserveExceptionMark { ./share/opto/graphKit.hpp:class PreserveJVMState: public StackObj { ./share/opto/graphKit.hpp:class PreserveReexecuteState: public StackObj { ... especially we already have a class SaveRestore, so AutoSaveRestore makes it confusing. ./share/jfr/leakprofiler/utilities/saveRestore.hpp:class SaveRestore { ./share/jfr/leakprofiler/utilities/saveRestore.hpp:class SaveRestoreCLDClaimBits : public StackObj { Thanks - Ioi On 7/13/20 8:39 PM, David Holmes wrote: > Hi Patric, > > On 14/07/2020 12:49 am, Patric Hedlin wrote: >> Hi David >> >> On 2020-07-13 02:43, David Holmes wrote: >>> Hi Patric, >>> >>> < . . . > >>>>>>> I would like to ask for help to review the following change/update: >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245226 >>>>>>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/ >>>>>>> >>>>>>> >>>>>>> FlagSetting is sometimes used as a general mechanism for local >>>>>>> save/modify and restore. This is not the intention (it should >>>>>>> work as a red-flag when modifying debug options). Instead, use a >>>>>>> general mechanism in these cases (introduced in here), and >>>>>>> preserve FlagSetting for its intended purpose (including clean-up). >>>>>> >>>>>> Sorry but I'm not seeing why FlagSetting can't be used as a >>>>>> general mechanism even though it is described as being for debug >>>>>> flags. Introducing a similar mechanism seems redundant to me. >>>>>> >>>>> >>>>> Let me ask you this. How well do you think 'FlagSetting' describes >>>>> the actual operation performed in the general use-case? Is it more >>>>> clear than explicitly stating that you intend a save/modify and a >>>>> restore in the local context? It is not as much about if it can be >>>>> used as it is about if it should be used. The use of 'FlagSetting' >>>>> and friends should be moved aside, given a new name (signalling >>>>> the thin ice you are entering) and restricted to use on admissible >>>>> flag/options only. I'm assuming you agree that modifying global >>>>> options might have undesirable effects. But that can wait until >>>>> after, or be part of, the rework. This part is about separating >>>>> the use-cases. If you feel strongly about preserving 'FlagSetting' >>>>> (and friends), please make your argument based on the merits of >>>>> the current concept and implementation (such as the use of >>>>> memcpy), not a dismissive "I don't see the point". >>>> >>>> Didn't intend to be dismissive, but if there is a bigger picture >>>> here then you needed to explain it - as you now have. I agree as a >>>> general mechanism FlagSetting is misnamed. So if the intent is to >>>> set it aside as a second step then that seems reasonable. >>> >>> I don't know what I thought I saw when I initially looked at this, >>> but what I see now is not what I thought. My apologies for that. >>> >> No need David. I just want the sharper end of your reviews. >> >>> I'm not sure that defining FLAG_GUARD purely as a means to introduce >>> a temporary variable name that isn't even visible to the reader, >>> serves a useful purpose. If it can't retain its existing >>> functionality of being a full declaration then I would suggest just >>> dropping it. >> >> I agree it should be removed, but at a later time, with the rest of >> the file. After (at least) a little thought, I decided to let it >> remain in the code as a "warning", of use both brittle and ugly. Its >> use leads back to "flagSetting.hpp" (as do *FlagSetting), with a >> documented legacy purpose and it identifies (if nothing else) a >> number of "suspects". I will simply add a clarifying comment. > > Given it is only used in test code and given you have already changed > things like: > > FLAG_GUARD(MinHeapSize); > > to > > AutoSaveRestore FLAG_GUARD(MinHeapSize); > > it seems a simple step to just remove FLAG_GUARD altogether: > > AutoSaveRestore _guard1(MinHeapSize); > > But your call. > > Thanks, > David > >> >> Thanks David. >> >> /Patric From igor.ignatyev at oracle.com Tue Jul 14 18:25:44 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 14 Jul 2020 11:25:44 -0700 Subject: RFR [15] : 8249036 : clean up FileInstaller $test.src $cwd in vmTestbase_nsk_stress tests In-Reply-To: <5720357e-c3c6-6f7f-7993-535561fd84e2@oracle.com> References: <5E2ED18E-9CD6-44D6-95D0-E13D1AFC1BC3@oracle.com> <5720357e-c3c6-6f7f-7993-535561fd84e2@oracle.com> Message-ID: Thanks Vladimir, pushed to jdk15. -- Igor > On Jul 13, 2020, at 2:34 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir K > > On 7/13/20 2:29 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8249036/webrev.00/ >>> 44 lines changed: 0 ins; 23 del; 21 mod; >> Hi all, >> could you please review this clean-up which removes unnecessary `FileInstaller` actions for :vmTestbase_nsk_stress tests? >> from the main issue(8204985): >>> all vmTestbase tests have '@run driver jdk.test.lib.FileInstaller . .' to mimic old test harness behavior and copy all files from a test source directory to a current work directory. some tests depend on this step, so we need 1st identify such tests and then either rewrite them not to have this dependency or leave FileInstaller only in these tests. >> none of vmTestbase_nsk_stress tests need FileInstaller, hence the patch is just `ag -l '@run driver jdk.test.lib.FileInstaller . .' vmTestbase/nsk/stress xargs -I{} gsed -i '/@run driver jdk.test.lib.FileInstaller \. \./d' {}`. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8249036 >> webrev: http://cr.openjdk.java.net/~iignatyev//8249036/webrev.00/ >> testing: :vmTestbase_nsk_stress on linux-x64 >> Thanks, >> -- Igor From Monica.Beckwith at microsoft.com Tue Jul 14 21:11:18 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Tue, 14 Jul 2020 21:11:18 +0000 Subject: RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ Message-ID: Hi all, Please review the change for MSVC, which doesn't have the __PRETTY_FUNCTION__ macro. I have instead added __FUNCSIG__ within appropriate #ifdef and also added the following comments: +// Microsoft's MSVC team thinks that the __FUNCSIG__ is approximately (sympathy for calling conventions) equivalent to __PRETTY_FUNCTION__ +// Also, from the Clang patch: "It is very similar to GCC's PRETTY_FUNCTION, except it prints the calling convention." +// https://reviews.llvm.org/D3311 JBS: https://bugs.openjdk.java.net/browse/JDK-8248681 Webrev: http://cr.openjdk.java.net/~mbeckwit/8248681/webrev.00/ Regards, Monica From Monica.Beckwith at microsoft.com Tue Jul 14 21:26:22 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Tue, 14 Jul 2020 21:26:22 +0000 Subject: RFR(S) 8248660: AArch64: Use MSVC built-ins where applicable Message-ID: Hello all, We are looking at utilizing MSVC built-ins as applicable. Please review the following: JBS: https://bugs.openjdk.java.net/browse/JDK-8248660 Webrev: http://cr.openjdk.java.net/~mbeckwit/8248660/webrev.00/ Regards, Monica From kim.barrett at oracle.com Tue Jul 14 23:18:43 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 14 Jul 2020 19:18:43 -0400 Subject: RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ In-Reply-To: References: Message-ID: <6CCC190A-B7CB-44B8-8611-2CC387214FF8@oracle.com> > On Jul 14, 2020, at 5:11 PM, Monica Beckwith wrote: > > Hi all, > > Please review the change for MSVC, which doesn't have the __PRETTY_FUNCTION__ macro. > I have instead added __FUNCSIG__ within appropriate #ifdef and also added the following comments: > > +// Microsoft's MSVC team thinks that the __FUNCSIG__ is approximately (sympathy for calling conventions) equivalent to __PRETTY_FUNCTION__ > +// Also, from the Clang patch: "It is very similar to GCC's PRETTY_FUNCTION, except it prints the calling convention." > +// https://reviews.llvm.org/D3311 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248681 > Webrev: http://cr.openjdk.java.net/~mbeckwit/8248681/webrev.00/ > > Regards, > Monica Not so much a review as a comment / suggested alternative. There is a general preference in HotSpot code toward avoiding toolchain-specific conditional compilation in shared code. (Obviously this is not a hard and fast rule.) This is even called out in the HotSpot Style Guide. Before the MSVC/aarch64 port the code being modified by this change is gcc-specific rather than shared, but with that port it becomes shared. It seems like this might be a case where we should have some macro defined somewhere like globalDefinitions_xxx.hpp that for gcc/clang expands to __PRETTY_FUNCTION__ and for MSVC expands to __FUNCSIG__. (Probably with a default expansion to __func__ since we should very shortly have C++11/14.) Of course, this is currently the only use of __PRETTY_FUNCTION__ in all of HotSpot, so that might be considered excessive overhead. But if we had such a macro it would simplify (and so perhaps encourage) the use of this feature. From david.holmes at oracle.com Tue Jul 14 23:48:34 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jul 2020 09:48:34 +1000 Subject: RFR(S) 8248660: AArch64: Use MSVC built-ins where applicable In-Reply-To: References: Message-ID: <1d66e71d-42fb-0d50-f700-8c9958a1f2c2@oracle.com> Hi Monica, On 15/07/2020 7:26 am, Monica Beckwith wrote: > Hello all, > > We are looking at utilizing MSVC built-ins as applicable. Please review the following: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248660 > Webrev: http://cr.openjdk.java.net/~mbeckwit/8248660/webrev.00/ Sorry but this is definitely part of the Windows-Aarch64 port and as such should be done under the implementation of the JEP, once targeted. If the intent was to push this to the aarch64-port repo then please update the bug with the repo-aarch64-port release values. Thanks, David > Regards, > Monica > > From kim.barrett at oracle.com Tue Jul 14 23:50:20 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 14 Jul 2020 19:50:20 -0400 Subject: RFR(S) 8248660: AArch64: Use MSVC built-ins where applicable In-Reply-To: References: Message-ID: > On Jul 14, 2020, at 5:26 PM, Monica Beckwith wrote: > > Hello all, > > We are looking at utilizing MSVC built-ins as applicable. Please review the following: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248660 > Webrev: http://cr.openjdk.java.net/~mbeckwit/8248660/webrev.00/ > > Regards, > Monica There is a general preference in HotSpot code toward avoiding toolchain-specific conditional compilation in shared code. (Obviously this is not a hard and fast rule.) This is even called out in the HotSpot Style Guide. Before the Windows/MSVC/aarch64 port the code being modified by this change is gcc-specific rather than shared, but with that port it becomes shared. I think the "normal" way to handle something like this would be to move the current code to os_cpu/linux_aarch64 and have the new MSVC/aarch64 port provide similar functionality in it's own os_cpu/windows_aarch64 file. I would be okay with moving the existing code as a preperatory "cleanup", rather than having it be part of the windows_aarch64 porting changeset. Others might have a different opinion about that. From david.holmes at oracle.com Tue Jul 14 23:52:22 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jul 2020 09:52:22 +1000 Subject: RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ In-Reply-To: References: Message-ID: <57c2d6d7-63f9-1c70-7483-17399ebac9e3@oracle.com> Hi Monica, On 15/07/2020 7:11 am, Monica Beckwith wrote: > Hi all, > > Please review the change for MSVC, which doesn't have the __PRETTY_FUNCTION__ macro. > I have instead added __FUNCSIG__ within appropriate #ifdef and also added the following comments: > > +// Microsoft's MSVC team thinks that the __FUNCSIG__ is approximately (sympathy for calling conventions) equivalent to __PRETTY_FUNCTION__ > +// Also, from the Clang patch: "It is very similar to GCC's PRETTY_FUNCTION, except it prints the calling convention." > +// https://reviews.llvm.org/D3311 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248681 > Webrev: http://cr.openjdk.java.net/~mbeckwit/8248681/webrev.00/ Sorry but this is definitely part of the Windows-Aarch64 port and as such should be done under the implementation of the JEP, once targeted. If the intent was to push this to the aarch64-port repo then please update the bug with the repo-aarch64-port release values. Thanks, David > Regards, > Monica > > From kim.barrett at oracle.com Wed Jul 15 00:42:59 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 14 Jul 2020 20:42:59 -0400 Subject: RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ In-Reply-To: <6CCC190A-B7CB-44B8-8611-2CC387214FF8@oracle.com> References: <6CCC190A-B7CB-44B8-8611-2CC387214FF8@oracle.com> Message-ID: > On Jul 14, 2020, at 7:18 PM, Kim Barrett wrote: > >> On Jul 14, 2020, at 5:11 PM, Monica Beckwith wrote: >> >> Hi all, >> >> Please review the change for MSVC, which doesn't have the __PRETTY_FUNCTION__ macro. >> I have instead added __FUNCSIG__ within appropriate #ifdef and also added the following comments: >> >> +// Microsoft's MSVC team thinks that the __FUNCSIG__ is approximately (sympathy for calling conventions) equivalent to __PRETTY_FUNCTION__ >> +// Also, from the Clang patch: "It is very similar to GCC's PRETTY_FUNCTION, except it prints the calling convention." >> +// https://reviews.llvm.org/D3311 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8248681 >> Webrev: http://cr.openjdk.java.net/~mbeckwit/8248681/webrev.00/ >> >> Regards, >> Monica > > Not so much a review as a comment / suggested alternative. Thinking about this some more, because of the toolchain-specific conditionalization I think I would argue against this change in this form, even if it were part of an eventual windows-aarch64 targeted port. I really don't think the proposed change should be made to mainline at this time. That is a review rather than just a comment. From aph at redhat.com Wed Jul 15 08:24:47 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Jul 2020 09:24:47 +0100 Subject: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ In-Reply-To: <6CCC190A-B7CB-44B8-8611-2CC387214FF8@oracle.com> References: <6CCC190A-B7CB-44B8-8611-2CC387214FF8@oracle.com> Message-ID: <4fbdac44-eb48-9bd6-9fd6-b79a6982a3b6@redhat.com> On 15/07/2020 00:18, Kim Barrett wrote: > > Not so much a review as a comment / suggested alternative. > > There is a general preference in HotSpot code toward avoiding > toolchain-specific conditional compilation in shared code. (Obviously > this is not a hard and fast rule.) This is even called out in the > HotSpot Style Guide. Before the MSVC/aarch64 port the code being > modified by this change is gcc-specific rather than shared, but with > that port it becomes shared. > > It seems like this might be a case where we should have some macro > defined somewhere like globalDefinitions_xxx.hpp that for gcc/clang > expands to __PRETTY_FUNCTION__ and for MSVC expands to __FUNCSIG__. > (Probably with a default expansion to __func__ since we should very > shortly have C++11/14.) > > Of course, this is currently the only use of __PRETTY_FUNCTION__ in > all of HotSpot, so that might be considered excessive overhead. But > if we had such a macro it would simplify (and so perhaps encourage) > the use of this feature. I don't think we need __PRETTY_FUNCTION__ here. Anyway, I'm leaning towards David Holmes' position that this is AArch64/Windows specific, so we should apply this patch to http://hg.openjdk.java.net/aarch64-port/jdk-windows/ The best way to do that is if I push the already-approved cleanup ports to jdk-jdk, pull from there to aarch64-port/jdk-windows, and we can push a patch for the __PRETTY_FUNCTION__ problem to aarch64-port/jdk-windows. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Wed Jul 15 10:48:28 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 15 Jul 2020 06:48:28 -0400 Subject: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ In-Reply-To: <4fbdac44-eb48-9bd6-9fd6-b79a6982a3b6@redhat.com> References: <6CCC190A-B7CB-44B8-8611-2CC387214FF8@oracle.com> <4fbdac44-eb48-9bd6-9fd6-b79a6982a3b6@redhat.com> Message-ID: <02CE223D-5D11-431A-98EA-9AD1C2233540@oracle.com> > On Jul 15, 2020, at 4:24 AM, Andrew Haley wrote: > > On 15/07/2020 00:18, Kim Barrett wrote: >> Of course, this is currently the only use of __PRETTY_FUNCTION__ in >> all of HotSpot, so that might be considered excessive overhead. But >> if we had such a macro it would simplify (and so perhaps encourage) >> the use of this feature. > > I don't think we need __PRETTY_FUNCTION__ here. Anyway, I'm leaning towards > David Holmes' position that this is AArch64/Windows specific, Eliminating the only use of __PRETTY_FUNCTION__ also seems like a good solution, and doesn?t seem aarch64/windows-specific to me. From coleen.phillimore at oracle.com Wed Jul 15 15:38:30 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Jul 2020 11:38:30 -0400 Subject: RFR 8247808: Move JVMTI strong oops to OopStorage In-Reply-To: <5051e29d-f519-f270-3a55-b8d2d0a02854@oracle.com> References: <890246ae-2d56-95ff-c360-dd66532579a8@oracle.com> <5051e29d-f519-f270-3a55-b8d2d0a02854@oracle.com> Message-ID: <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> Hi, This patch has been reviewed and I was waiting for the ability to define different OopStorages, but I'd like to fix that in a further change after the GC changes have been agreed upon and reviewed.? Adding a new JVMTI OopStorage in the new mechanism is a smaller change. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev Retested with tier1-3. Thanks, Coleen On 6/18/20 3:48 PM, coleen.phillimore at oracle.com wrote: > > > On 6/18/20 3:58 AM, Thomas Schatzl wrote: >> Hi, >> >> On 18.06.20 03:09, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 6/17/20 7:49 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 18/06/2020 7:25 am, coleen.phillimore at oracle.com wrote: >>>>> Summary: Remove JVMTI oops_do calls from JVMTI and GCs >>>>> >>>>> Tested with tier1-3, also built shenandoah to verify shenandoah >>>>> changes. >>>>> >> [...] >>> >>> Kim noticed that G1 and ParallelGC should be processing these roots >>> in parallel (with many threads, since OopStorage has that support) >>> and he's going to or has filed a bug to fix it. As we add more >>> things to OopStorage (see upcoming RFRs), this will become important. >>> >> >> I do not know which exact roots you want to move into OopStorage, but >> I would like to mention this concern: with moving everything into a >> single OopStorage (i.e. vm_globals in this case), I am worried that >> every time important information about the source for these gets lost. >> >> Which makes it hard to understand from where these oops came from >> when there is a performance problem in the "VM Globals" bucket. > Hi Thomas, > > I understand this concern.? On the GC list there is a discussion about > having the ability to create different strong OopStorages, changing > the OopStorage code to process these roots and report statistics in > parallel (and/or concurrent), and not having to cascade the code > through all the GCs. > > I'm going to hold this change until this discussion is complete and > move the JVMTI and services/management oops_do oops into a different > OopStorage that can make use of this.? Then you'll have your > statistics and we won't have classes needing traversal with oops_do. > > Thanks, > Coleen > >> >> This may not apply to JVMTI oops, but others may occasionally have a >> significant amount of oops where it would be very interesting to know >> from where a particular slowdown comes from. >> >> So I would prefer keep some accounting here. >> >> Thanks, >> ? Thomas > From Monica.Beckwith at microsoft.com Wed Jul 15 15:47:43 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Wed, 15 Jul 2020 15:47:43 +0000 Subject: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ In-Reply-To: <02CE223D-5D11-431A-98EA-9AD1C2233540@oracle.com> References: <6CCC190A-B7CB-44B8-8611-2CC387214FF8@oracle.com> <4fbdac44-eb48-9bd6-9fd6-b79a6982a3b6@redhat.com> <02CE223D-5D11-431A-98EA-9AD1C2233540@oracle.com> Message-ID: Hello everyone - Here's some background on this and similar RFRs that we are sending out ahead of the `repo-aarch64-port` tagged RFRs: - we are sending these right now to encourage discussions around the changes that we had initially guarded by appropriate ifdefs since we were modifying shared code for the default use-case (such as having GCC specific macros for aarch64). - for this particular one, I too thought that dropping __PRETTY_FUNCTION__ was a better option. (So, thank you both for suggesting that) - there are just 2 more cleanups to `cpu/aarch64/*` where MSVC keywords or macro names are employed, and I was hoping to send those out shortly. So, @Andrew Haley, let us know if we should stop and wait for all existing cleanups to get pushed to tip. Or if we should send out the last 2 (as mentioned above) and then sync and start pushing our Windows + AArch64 specific changes to `repo-aarch64-port.` -Monica -----Original Message----- From: Kim Barrett Sent: Wednesday, July 15, 2020 5:48 AM To: Andrew Haley Cc: Monica Beckwith ; aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers ; openjdk-aarch64 Subject: Re: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ > On Jul 15, 2020, at 4:24 AM, Andrew Haley wrote: > > On 15/07/2020 00:18, Kim Barrett wrote: >> Of course, this is currently the only use of __PRETTY_FUNCTION__ in >> all of HotSpot, so that might be considered excessive overhead. But >> if we had such a macro it would simplify (and so perhaps encourage) >> the use of this feature. > > I don't think we need __PRETTY_FUNCTION__ here. Anyway, I'm leaning > towards David Holmes' position that this is AArch64/Windows specific, Eliminating the only use of __PRETTY_FUNCTION__ also seems like a good solution, and doesn?t seem aarch64/windows-specific to me. From vladimir.kozlov at oracle.com Wed Jul 15 17:12:46 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Jul 2020 10:12:46 -0700 Subject: RFR(S): 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: References: <3df3dab6-aa2f-bbbc-d231-6cda8f2a0ff7@oracle.com> Message-ID: +1 Thanks, Vladimir K On 7/7/20 6:59 AM, Nils Eliasson wrote: > Hi Patric, > > Your change looks good. > > Best regards, > Nils > > On 2020-07-07 13:00, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8248901 >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8248901/ >> >> >> Current definition(s) of is_simm() and friends are not robust over inputs. Both min and max values are undefined for >> width > 32 (and width < 0). >> No is_uimm() is currently provided (added). Several definitions are not used (cleanup). >> >> NOTE: Adding currently unused is_simm9() and is_uimm12(), required by JDK-8247766. >> >> >> Testing: hs-tier1-3 >> >> >> Best regards, >> Patric > From serguei.spitsyn at oracle.com Wed Jul 15 17:33:08 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Jul 2020 10:33:08 -0700 Subject: RFR 8247808: Move JVMTI strong oops to OopStorage In-Reply-To: <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> References: <890246ae-2d56-95ff-c360-dd66532579a8@oracle.com> <5051e29d-f519-f270-3a55-b8d2d0a02854@oracle.com> <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> Message-ID: Hi Coleen, The update looks okay to me. Also, I wonder what should happen to the JvmtiExport::weak_oops_do(). Thanks, Serguei On 7/15/20 08:38, coleen.phillimore at oracle.com wrote: > > Hi, This patch has been reviewed and I was waiting for the ability to > define different OopStorages, but I'd like to fix that in a further > change after the GC changes have been agreed upon and reviewed.? > Adding a new JVMTI OopStorage in the new mechanism is a smaller change. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev > > Retested with tier1-3. > > Thanks, > Coleen > > > > On 6/18/20 3:48 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 6/18/20 3:58 AM, Thomas Schatzl wrote: >>> Hi, >>> >>> On 18.06.20 03:09, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 6/17/20 7:49 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 18/06/2020 7:25 am, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Remove JVMTI oops_do calls from JVMTI and GCs >>>>>> >>>>>> Tested with tier1-3, also built shenandoah to verify shenandoah >>>>>> changes. >>>>>> >>> [...] >>>> >>>> Kim noticed that G1 and ParallelGC should be processing these roots >>>> in parallel (with many threads, since OopStorage has that support) >>>> and he's going to or has filed a bug to fix it. As we add more >>>> things to OopStorage (see upcoming RFRs), this will become important. >>>> >>> >>> I do not know which exact roots you want to move into OopStorage, >>> but I would like to mention this concern: with moving everything >>> into a single OopStorage (i.e. vm_globals in this case), I am >>> worried that every time important information about the source for >>> these gets lost. >>> >>> Which makes it hard to understand from where these oops came from >>> when there is a performance problem in the "VM Globals" bucket. >> Hi Thomas, >> >> I understand this concern.? On the GC list there is a discussion >> about having the ability to create different strong OopStorages, >> changing the OopStorage code to process these roots and report >> statistics in parallel (and/or concurrent), and not having to cascade >> the code through all the GCs. >> >> I'm going to hold this change until this discussion is complete and >> move the JVMTI and services/management oops_do oops into a different >> OopStorage that can make use of this.? Then you'll have your >> statistics and we won't have classes needing traversal with oops_do. >> >> Thanks, >> Coleen >> >>> >>> This may not apply to JVMTI oops, but others may occasionally have a >>> significant amount of oops where it would be very interesting to >>> know from where a particular slowdown comes from. >>> >>> So I would prefer keep some accounting here. >>> >>> Thanks, >>> ? Thomas >> > From zgu at redhat.com Wed Jul 15 18:35:41 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 15 Jul 2020 14:35:41 -0400 Subject: RFR 8247808: Move JVMTI strong oops to OopStorage In-Reply-To: <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> References: <890246ae-2d56-95ff-c360-dd66532579a8@oracle.com> <5051e29d-f519-f270-3a55-b8d2d0a02854@oracle.com> <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> Message-ID: <008cb366-a64f-a7ab-c70a-bbae09478b92@redhat.com> Hi Coleen, Shenandoah part looks good. Thanks, -Zhengyu On 7/15/20 11:38 AM, coleen.phillimore at oracle.com wrote: > > Hi, This patch has been reviewed and I was waiting for the ability to > define different OopStorages, but I'd like to fix that in a further > change after the GC changes have been agreed upon and reviewed.? Adding > a new JVMTI OopStorage in the new mechanism is a smaller change. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev > > Retested with tier1-3. > > Thanks, > Coleen > > > > On 6/18/20 3:48 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 6/18/20 3:58 AM, Thomas Schatzl wrote: >>> Hi, >>> >>> On 18.06.20 03:09, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 6/17/20 7:49 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 18/06/2020 7:25 am, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Remove JVMTI oops_do calls from JVMTI and GCs >>>>>> >>>>>> Tested with tier1-3, also built shenandoah to verify shenandoah >>>>>> changes. >>>>>> >>> [...] >>>> >>>> Kim noticed that G1 and ParallelGC should be processing these roots >>>> in parallel (with many threads, since OopStorage has that support) >>>> and he's going to or has filed a bug to fix it. As we add more >>>> things to OopStorage (see upcoming RFRs), this will become important. >>>> >>> >>> I do not know which exact roots you want to move into OopStorage, but >>> I would like to mention this concern: with moving everything into a >>> single OopStorage (i.e. vm_globals in this case), I am worried that >>> every time important information about the source for these gets lost. >>> >>> Which makes it hard to understand from where these oops came from >>> when there is a performance problem in the "VM Globals" bucket. >> Hi Thomas, >> >> I understand this concern.? On the GC list there is a discussion about >> having the ability to create different strong OopStorages, changing >> the OopStorage code to process these roots and report statistics in >> parallel (and/or concurrent), and not having to cascade the code >> through all the GCs. >> >> I'm going to hold this change until this discussion is complete and >> move the JVMTI and services/management oops_do oops into a different >> OopStorage that can make use of this.? Then you'll have your >> statistics and we won't have classes needing traversal with oops_do. >> >> Thanks, >> Coleen >> >>> >>> This may not apply to JVMTI oops, but others may occasionally have a >>> significant amount of oops where it would be very interesting to know >>> from where a particular slowdown comes from. >>> >>> So I would prefer keep some accounting here. >>> >>> Thanks, >>> ? Thomas >> > From coleen.phillimore at oracle.com Wed Jul 15 19:45:32 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Jul 2020 15:45:32 -0400 Subject: RFR 8247808: Move JVMTI strong oops to OopStorage In-Reply-To: References: <890246ae-2d56-95ff-c360-dd66532579a8@oracle.com> <5051e29d-f519-f270-3a55-b8d2d0a02854@oracle.com> <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> Message-ID: <730b30d5-db2f-6a15-82e7-326b19b6c1b8@oracle.com> Thank you for reviewing this, Serguei. On 7/15/20 1:33 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > The update looks okay to me. > Also, I wonder what should happen to the JvmtiExport::weak_oops_do(). Unfortunately, JvmtiExport::weak_oops_do() calls JvmtiTagMap::weak_oops_do which ends up doing more than just doing GC on the weak oops in the hashtable that is stored for object tagging.? Since the hash code for the objects tagged is the address of the oop, GC also has to rehash the objects if they've been moved. I had a patch once to try go fix this to use weak OopStorage and use object->identity_hash() but hashing all the objects that JVMTI was trying to tag didn't turn out to be a good thing to do.? I ended up abandoning that change. Thanks, Coleen > > Thanks, > Serguei > > > On 7/15/20 08:38, coleen.phillimore at oracle.com wrote: >> >> Hi, This patch has been reviewed and I was waiting for the ability to >> define different OopStorages, but I'd like to fix that in a further >> change after the GC changes have been agreed upon and reviewed.? >> Adding a new JVMTI OopStorage in the new mechanism is a smaller change. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev >> >> Retested with tier1-3. >> >> Thanks, >> Coleen >> >> >> >> On 6/18/20 3:48 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 6/18/20 3:58 AM, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On 18.06.20 03:09, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 6/17/20 7:49 PM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 18/06/2020 7:25 am, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Remove JVMTI oops_do calls from JVMTI and GCs >>>>>>> >>>>>>> Tested with tier1-3, also built shenandoah to verify shenandoah >>>>>>> changes. >>>>>>> >>>> [...] >>>>> >>>>> Kim noticed that G1 and ParallelGC should be processing these >>>>> roots in parallel (with many threads, since OopStorage has that >>>>> support) and he's going to or has filed a bug to fix it. As we add >>>>> more things to OopStorage (see upcoming RFRs), this will become >>>>> important. >>>>> >>>> >>>> I do not know which exact roots you want to move into OopStorage, >>>> but I would like to mention this concern: with moving everything >>>> into a single OopStorage (i.e. vm_globals in this case), I am >>>> worried that every time important information about the source for >>>> these gets lost. >>>> >>>> Which makes it hard to understand from where these oops came from >>>> when there is a performance problem in the "VM Globals" bucket. >>> Hi Thomas, >>> >>> I understand this concern.? On the GC list there is a discussion >>> about having the ability to create different strong OopStorages, >>> changing the OopStorage code to process these roots and report >>> statistics in parallel (and/or concurrent), and not having to >>> cascade the code through all the GCs. >>> >>> I'm going to hold this change until this discussion is complete and >>> move the JVMTI and services/management oops_do oops into a different >>> OopStorage that can make use of this. Then you'll have your >>> statistics and we won't have classes needing traversal with oops_do. >>> >>> Thanks, >>> Coleen >>> >>>> >>>> This may not apply to JVMTI oops, but others may occasionally have >>>> a significant amount of oops where it would be very interesting to >>>> know from where a particular slowdown comes from. >>>> >>>> So I would prefer keep some accounting here. >>>> >>>> Thanks, >>>> ? Thomas >>> >> > From coleen.phillimore at oracle.com Wed Jul 15 19:45:52 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Jul 2020 15:45:52 -0400 Subject: RFR 8247808: Move JVMTI strong oops to OopStorage In-Reply-To: <008cb366-a64f-a7ab-c70a-bbae09478b92@redhat.com> References: <890246ae-2d56-95ff-c360-dd66532579a8@oracle.com> <5051e29d-f519-f270-3a55-b8d2d0a02854@oracle.com> <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> <008cb366-a64f-a7ab-c70a-bbae09478b92@redhat.com> Message-ID: <07a90bcc-9ceb-182d-0a54-ca8c38e32bdc@oracle.com> Thank you Zhengyu. Coleen On 7/15/20 2:35 PM, Zhengyu Gu wrote: > Hi Coleen, > > Shenandoah part looks good. > > Thanks, > > -Zhengyu > > On 7/15/20 11:38 AM, coleen.phillimore at oracle.com wrote: >> >> Hi, This patch has been reviewed and I was waiting for the ability to >> define different OopStorages, but I'd like to fix that in a further >> change after the GC changes have been agreed upon and reviewed.? >> Adding a new JVMTI OopStorage in the new mechanism is a smaller change. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev >> >> Retested with tier1-3. >> >> Thanks, >> Coleen >> >> >> >> On 6/18/20 3:48 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 6/18/20 3:58 AM, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On 18.06.20 03:09, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 6/17/20 7:49 PM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 18/06/2020 7:25 am, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Remove JVMTI oops_do calls from JVMTI and GCs >>>>>>> >>>>>>> Tested with tier1-3, also built shenandoah to verify shenandoah >>>>>>> changes. >>>>>>> >>>> [...] >>>>> >>>>> Kim noticed that G1 and ParallelGC should be processing these >>>>> roots in parallel (with many threads, since OopStorage has that >>>>> support) and he's going to or has filed a bug to fix it. As we add >>>>> more things to OopStorage (see upcoming RFRs), this will become >>>>> important. >>>>> >>>> >>>> I do not know which exact roots you want to move into OopStorage, >>>> but I would like to mention this concern: with moving everything >>>> into a single OopStorage (i.e. vm_globals in this case), I am >>>> worried that every time important information about the source for >>>> these gets lost. >>>> >>>> Which makes it hard to understand from where these oops came from >>>> when there is a performance problem in the "VM Globals" bucket. >>> Hi Thomas, >>> >>> I understand this concern.? On the GC list there is a discussion >>> about having the ability to create different strong OopStorages, >>> changing the OopStorage code to process these roots and report >>> statistics in parallel (and/or concurrent), and not having to >>> cascade the code through all the GCs. >>> >>> I'm going to hold this change until this discussion is complete and >>> move the JVMTI and services/management oops_do oops into a different >>> OopStorage that can make use of this. Then you'll have your >>> statistics and we won't have classes needing traversal with oops_do. >>> >>> Thanks, >>> Coleen >>> >>>> >>>> This may not apply to JVMTI oops, but others may occasionally have >>>> a significant amount of oops where it would be very interesting to >>>> know from where a particular slowdown comes from. >>>> >>>> So I would prefer keep some accounting here. >>>> >>>> Thanks, >>>> ? Thomas >>> >> > From serguei.spitsyn at oracle.com Wed Jul 15 22:26:29 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Jul 2020 15:26:29 -0700 Subject: RFR 8247808: Move JVMTI strong oops to OopStorage In-Reply-To: <730b30d5-db2f-6a15-82e7-326b19b6c1b8@oracle.com> References: <890246ae-2d56-95ff-c360-dd66532579a8@oracle.com> <5051e29d-f519-f270-3a55-b8d2d0a02854@oracle.com> <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> <730b30d5-db2f-6a15-82e7-326b19b6c1b8@oracle.com> Message-ID: <2fd78eda-4713-3cde-9f38-2b32b96751eb@oracle.com> Hi Coleen, Thank you for the explanation. Thanks, Serguei On 7/15/20 12:45, coleen.phillimore at oracle.com wrote: > > Thank you for reviewing this, Serguei. > > On 7/15/20 1:33 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> The update looks okay to me. >> Also, I wonder what should happen to the JvmtiExport::weak_oops_do(). > > Unfortunately, JvmtiExport::weak_oops_do() calls > JvmtiTagMap::weak_oops_do which ends up doing more than just doing GC > on the weak oops in the hashtable that is stored for object tagging.? > Since the hash code for the objects tagged is the address of the oop, > GC also has to rehash the objects if they've been moved. > > I had a patch once to try go fix this to use weak OopStorage and use > object->identity_hash() but hashing all the objects that JVMTI was > trying to tag didn't turn out to be a good thing to do. I ended up > abandoning that change. > > Thanks, > Coleen >> >> Thanks, >> Serguei >> >> >> On 7/15/20 08:38, coleen.phillimore at oracle.com wrote: >>> >>> Hi, This patch has been reviewed and I was waiting for the ability >>> to define different OopStorages, but I'd like to fix that in a >>> further change after the GC changes have been agreed upon and >>> reviewed.? Adding a new JVMTI OopStorage in the new mechanism is a >>> smaller change. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev >>> >>> Retested with tier1-3. >>> >>> Thanks, >>> Coleen >>> >>> >>> >>> On 6/18/20 3:48 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 6/18/20 3:58 AM, Thomas Schatzl wrote: >>>>> Hi, >>>>> >>>>> On 18.06.20 03:09, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> >>>>>> On 6/17/20 7:49 PM, David Holmes wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> On 18/06/2020 7:25 am, coleen.phillimore at oracle.com wrote: >>>>>>>> Summary: Remove JVMTI oops_do calls from JVMTI and GCs >>>>>>>> >>>>>>>> Tested with tier1-3, also built shenandoah to verify shenandoah >>>>>>>> changes. >>>>>>>> >>>>> [...] >>>>>> >>>>>> Kim noticed that G1 and ParallelGC should be processing these >>>>>> roots in parallel (with many threads, since OopStorage has that >>>>>> support) and he's going to or has filed a bug to fix it. As we >>>>>> add more things to OopStorage (see upcoming RFRs), this will >>>>>> become important. >>>>>> >>>>> >>>>> I do not know which exact roots you want to move into OopStorage, >>>>> but I would like to mention this concern: with moving everything >>>>> into a single OopStorage (i.e. vm_globals in this case), I am >>>>> worried that every time important information about the source for >>>>> these gets lost. >>>>> >>>>> Which makes it hard to understand from where these oops came from >>>>> when there is a performance problem in the "VM Globals" bucket. >>>> Hi Thomas, >>>> >>>> I understand this concern.? On the GC list there is a discussion >>>> about having the ability to create different strong OopStorages, >>>> changing the OopStorage code to process these roots and report >>>> statistics in parallel (and/or concurrent), and not having to >>>> cascade the code through all the GCs. >>>> >>>> I'm going to hold this change until this discussion is complete and >>>> move the JVMTI and services/management oops_do oops into a >>>> different OopStorage that can make use of this. Then you'll have >>>> your statistics and we won't have classes needing traversal with >>>> oops_do. >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> This may not apply to JVMTI oops, but others may occasionally have >>>>> a significant amount of oops where it would be very interesting to >>>>> know from where a particular slowdown comes from. >>>>> >>>>> So I would prefer keep some accounting here. >>>>> >>>>> Thanks, >>>>> ? Thomas >>>> >>> >> > From david.holmes at oracle.com Thu Jul 16 01:32:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jul 2020 11:32:48 +1000 Subject: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ In-Reply-To: References: <6CCC190A-B7CB-44B8-8611-2CC387214FF8@oracle.com> <4fbdac44-eb48-9bd6-9fd6-b79a6982a3b6@redhat.com> <02CE223D-5D11-431A-98EA-9AD1C2233540@oracle.com> Message-ID: <50b4ac68-7eaa-db72-4a98-d54945fc9502@oracle.com> Hi Monica, On 16/07/2020 1:47 am, Monica Beckwith wrote: > Hello everyone - > > Here's some background on this and similar RFRs that we are sending out ahead of the `repo-aarch64-port` tagged RFRs: > > - we are sending these right now to encourage discussions around the changes that we had initially guarded by appropriate ifdefs since we were modifying shared code for the default use-case (such as having GCC specific macros for aarch64). Pushing general cleanups is fine. But no change that adds an ifdef for WIN64 or the VS toolchain to the existing Aarch64 code, can be considered a general cleanup as it obviously exists purely to support the Windows-aarch64 port. All such issues should be marked for repo-aarch64-port and pushed to the staging repo. Once the port JEP has been targeted they will then become part of the single changeset that implements the JEP. Thanks, David ----- > - for this particular one, I too thought that dropping __PRETTY_FUNCTION__ was a better option. (So, thank you both for suggesting that) > - there are just 2 more cleanups to `cpu/aarch64/*` where MSVC keywords or macro names are employed, and I was hoping to send those out shortly. > > So, @Andrew Haley, let us know if we should stop and wait for all existing cleanups to get pushed to tip. Or if we should send out the last 2 (as mentioned above) and then sync and start pushing our Windows + AArch64 specific changes to `repo-aarch64-port.` > > -Monica > > > > -----Original Message----- > From: Kim Barrett > Sent: Wednesday, July 15, 2020 5:48 AM > To: Andrew Haley > Cc: Monica Beckwith ; aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers ; openjdk-aarch64 > Subject: Re: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ > >> On Jul 15, 2020, at 4:24 AM, Andrew Haley wrote: >> >> On 15/07/2020 00:18, Kim Barrett wrote: >>> Of course, this is currently the only use of __PRETTY_FUNCTION__ in >>> all of HotSpot, so that might be considered excessive overhead. But >>> if we had such a macro it would simplify (and so perhaps encourage) >>> the use of this feature. >> >> I don't think we need __PRETTY_FUNCTION__ here. Anyway, I'm leaning >> towards David Holmes' position that this is AArch64/Windows specific, > > Eliminating the only use of __PRETTY_FUNCTION__ also seems like a good solution, and doesn?t seem aarch64/windows-specific to me. > > From Monica.Beckwith at microsoft.com Thu Jul 16 05:34:36 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Thu, 16 Jul 2020 05:34:36 +0000 Subject: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ In-Reply-To: <50b4ac68-7eaa-db72-4a98-d54945fc9502@oracle.com> References: <6CCC190A-B7CB-44B8-8611-2CC387214FF8@oracle.com> <4fbdac44-eb48-9bd6-9fd6-b79a6982a3b6@redhat.com> <02CE223D-5D11-431A-98EA-9AD1C2233540@oracle.com> <50b4ac68-7eaa-db72-4a98-d54945fc9502@oracle.com> Message-ID: Hi David - I do understand your point. And in the long run, discussions will happen either way. I appreciated getting these smaller shared code changes discussed here esp. where Kim provided feedback to separate the os+cpu specific changes to their folder. It's all a learning opportunity for us. Thanks, -Monica -----Original Message----- From: David Holmes Sent: Wednesday, July 15, 2020 8:33 PM To: Monica Beckwith ; Kim Barrett ; Andrew Haley Cc: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers ; openjdk-aarch64 Subject: Re: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ Hi Monica, On 16/07/2020 1:47 am, Monica Beckwith wrote: > Hello everyone - > > Here's some background on this and similar RFRs that we are sending out ahead of the `repo-aarch64-port` tagged RFRs: > > - we are sending these right now to encourage discussions around the changes that we had initially guarded by appropriate ifdefs since we were modifying shared code for the default use-case (such as having GCC specific macros for aarch64). Pushing general cleanups is fine. But no change that adds an ifdef for WIN64 or the VS toolchain to the existing Aarch64 code, can be considered a general cleanup as it obviously exists purely to support the Windows-aarch64 port. All such issues should be marked for repo-aarch64-port and pushed to the staging repo. Once the port JEP has been targeted they will then become part of the single changeset that implements the JEP. Thanks, David ----- > - for this particular one, I too thought that dropping > __PRETTY_FUNCTION__ was a better option. (So, thank you both for > suggesting that) > - there are just 2 more cleanups to `cpu/aarch64/*` where MSVC keywords or macro names are employed, and I was hoping to send those out shortly. > > So, @Andrew Haley, let us know if we should stop and wait for all > existing cleanups to get pushed to tip. Or if we should send out the > last 2 (as mentioned above) and then sync and start pushing our > Windows + AArch64 specific changes to `repo-aarch64-port.` > > -Monica > > > > -----Original Message----- > From: Kim Barrett > Sent: Wednesday, July 15, 2020 5:48 AM > To: Andrew Haley > Cc: Monica Beckwith ; > aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > ; openjdk-aarch64 > > Subject: Re: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC > doesn't support __PRETTY_FUNCTION__ > >> On Jul 15, 2020, at 4:24 AM, Andrew Haley wrote: >> >> On 15/07/2020 00:18, Kim Barrett wrote: >>> Of course, this is currently the only use of __PRETTY_FUNCTION__ in >>> all of HotSpot, so that might be considered excessive overhead. But >>> if we had such a macro it would simplify (and so perhaps encourage) >>> the use of this feature. >> >> I don't think we need __PRETTY_FUNCTION__ here. Anyway, I'm leaning >> towards David Holmes' position that this is AArch64/Windows specific, > > Eliminating the only use of __PRETTY_FUNCTION__ also seems like a good solution, and doesn?t seem aarch64/windows-specific to me. > > From david.holmes at oracle.com Thu Jul 16 06:39:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jul 2020 16:39:27 +1000 Subject: RFR 8247808: Move JVMTI strong oops to OopStorage In-Reply-To: <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> References: <890246ae-2d56-95ff-c360-dd66532579a8@oracle.com> <5051e29d-f519-f270-3a55-b8d2d0a02854@oracle.com> <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> Message-ID: <82b9d699-42b0-a0ad-f1b9-62241f8754f4@oracle.com> Hi Coleen, On 16/07/2020 1:38 am, coleen.phillimore at oracle.com wrote: > > Hi, This patch has been reviewed and I was waiting for the ability to > define different OopStorages, but I'd like to fix that in a further > change after the GC changes have been agreed upon and reviewed.? Adding > a new JVMTI OopStorage in the new mechanism is a smaller change. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev This all looks okay to me. I think you missed updating share/gc/shared/genCollectedHeap.hpp to delete GCH_PS_jvmti_oops_do, Thanks, David ----- > Retested with tier1-3. > > Thanks, > Coleen > > > > On 6/18/20 3:48 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 6/18/20 3:58 AM, Thomas Schatzl wrote: >>> Hi, >>> >>> On 18.06.20 03:09, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 6/17/20 7:49 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 18/06/2020 7:25 am, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Remove JVMTI oops_do calls from JVMTI and GCs >>>>>> >>>>>> Tested with tier1-3, also built shenandoah to verify shenandoah >>>>>> changes. >>>>>> >>> [...] >>>> >>>> Kim noticed that G1 and ParallelGC should be processing these roots >>>> in parallel (with many threads, since OopStorage has that support) >>>> and he's going to or has filed a bug to fix it. As we add more >>>> things to OopStorage (see upcoming RFRs), this will become important. >>>> >>> >>> I do not know which exact roots you want to move into OopStorage, but >>> I would like to mention this concern: with moving everything into a >>> single OopStorage (i.e. vm_globals in this case), I am worried that >>> every time important information about the source for these gets lost. >>> >>> Which makes it hard to understand from where these oops came from >>> when there is a performance problem in the "VM Globals" bucket. >> Hi Thomas, >> >> I understand this concern.? On the GC list there is a discussion about >> having the ability to create different strong OopStorages, changing >> the OopStorage code to process these roots and report statistics in >> parallel (and/or concurrent), and not having to cascade the code >> through all the GCs. >> >> I'm going to hold this change until this discussion is complete and >> move the JVMTI and services/management oops_do oops into a different >> OopStorage that can make use of this.? Then you'll have your >> statistics and we won't have classes needing traversal with oops_do. >> >> Thanks, >> Coleen >> >>> >>> This may not apply to JVMTI oops, but others may occasionally have a >>> significant amount of oops where it would be very interesting to know >>> from where a particular slowdown comes from. >>> >>> So I would prefer keep some accounting here. >>> >>> Thanks, >>> ? Thomas >> > From aph at redhat.com Thu Jul 16 08:46:52 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Jul 2020 09:46:52 +0100 Subject: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ In-Reply-To: References: <6CCC190A-B7CB-44B8-8611-2CC387214FF8@oracle.com> <4fbdac44-eb48-9bd6-9fd6-b79a6982a3b6@redhat.com> <02CE223D-5D11-431A-98EA-9AD1C2233540@oracle.com> <50b4ac68-7eaa-db72-4a98-d54945fc9502@oracle.com> Message-ID: <74a09d14-29b0-f8b8-eaa5-7f8cbc8c2fb6@redhat.com> On 16/07/2020 06:34, Monica Beckwith wrote: > I do understand your point. And in the long run, discussions will happen either way. I appreciated getting these smaller shared code changes discussed here esp. where Kim provided feedback to separate the os+cpu specific changes to their folder. It's all a learning opportunity for us. Yes, we should discuss shared changes here to get feedback. But let's push to aarch64-port/jdk-windows. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleen.phillimore at oracle.com Thu Jul 16 13:25:46 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 16 Jul 2020 09:25:46 -0400 Subject: RFR 8247808: Move JVMTI strong oops to OopStorage In-Reply-To: <82b9d699-42b0-a0ad-f1b9-62241f8754f4@oracle.com> References: <890246ae-2d56-95ff-c360-dd66532579a8@oracle.com> <5051e29d-f519-f270-3a55-b8d2d0a02854@oracle.com> <14670943-33c3-952c-3091-40afc21ecda4@oracle.com> <82b9d699-42b0-a0ad-f1b9-62241f8754f4@oracle.com> Message-ID: <7e3f5365-b585-6a49-e9da-203e1bff88b5@oracle.com> Thank you for the review. On 7/16/20 2:39 AM, David Holmes wrote: > Hi Coleen, > > On 16/07/2020 1:38 am, coleen.phillimore at oracle.com wrote: >> >> Hi, This patch has been reviewed and I was waiting for the ability to >> define different OopStorages, but I'd like to fix that in a further >> change after the GC changes have been agreed upon and reviewed.? >> Adding a new JVMTI OopStorage in the new mechanism is a smaller change. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev > > This all looks okay to me. > > I think you missed updating > > share/gc/shared/genCollectedHeap.hpp > > to delete > > GCH_PS_jvmti_oops_do, I did miss that.? Looks like someone forgot to remove GCH_PS_FlatProfiler_oops_do also. Thanks, Coleen > > Thanks, > David > ----- > >> Retested with tier1-3. >> >> Thanks, >> Coleen >> >> >> >> On 6/18/20 3:48 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 6/18/20 3:58 AM, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On 18.06.20 03:09, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 6/17/20 7:49 PM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 18/06/2020 7:25 am, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Remove JVMTI oops_do calls from JVMTI and GCs >>>>>>> >>>>>>> Tested with tier1-3, also built shenandoah to verify shenandoah >>>>>>> changes. >>>>>>> >>>> [...] >>>>> >>>>> Kim noticed that G1 and ParallelGC should be processing these >>>>> roots in parallel (with many threads, since OopStorage has that >>>>> support) and he's going to or has filed a bug to fix it. As we add >>>>> more things to OopStorage (see upcoming RFRs), this will become >>>>> important. >>>>> >>>> >>>> I do not know which exact roots you want to move into OopStorage, >>>> but I would like to mention this concern: with moving everything >>>> into a single OopStorage (i.e. vm_globals in this case), I am >>>> worried that every time important information about the source for >>>> these gets lost. >>>> >>>> Which makes it hard to understand from where these oops came from >>>> when there is a performance problem in the "VM Globals" bucket. >>> Hi Thomas, >>> >>> I understand this concern.? On the GC list there is a discussion >>> about having the ability to create different strong OopStorages, >>> changing the OopStorage code to process these roots and report >>> statistics in parallel (and/or concurrent), and not having to >>> cascade the code through all the GCs. >>> >>> I'm going to hold this change until this discussion is complete and >>> move the JVMTI and services/management oops_do oops into a different >>> OopStorage that can make use of this. Then you'll have your >>> statistics and we won't have classes needing traversal with oops_do. >>> >>> Thanks, >>> Coleen >>> >>>> >>>> This may not apply to JVMTI oops, but others may occasionally have >>>> a significant amount of oops where it would be very interesting to >>>> know from where a particular slowdown comes from. >>>> >>>> So I would prefer keep some accounting here. >>>> >>>> Thanks, >>>> ? Thomas >>> >> From coleen.phillimore at oracle.com Thu Jul 16 15:01:41 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 16 Jul 2020 11:01:41 -0400 Subject: RFR 8247878: Move Management strong oops to OopStorage Message-ID: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> Summary: Use OopStorage for strong oops stored with memory and thread sampling and dumping, and remove oops_do and GC calls. These use OopStorageSet::vm_global()? OopStorage for now.? I'll change the thread sampling oops to use a new OopStorage once the GC code is changed to nicely allow additional oop storages.? The memory pool oops are never deleted once created, so they should stay in vm_global() oop storage. Tested with tiers 1-3 (tiers 4-6 with other changes) and javax/management tests.? I timed the tests to see if there was any noticeable performance difference, and there was not. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8247878.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8247878 Thanks, Coleen From patric.hedlin at oracle.com Thu Jul 16 15:55:25 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Thu, 16 Jul 2020 17:55:25 +0200 Subject: RFR(S): 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: References: <3df3dab6-aa2f-bbbc-d231-6cda8f2a0ff7@oracle.com> Message-ID: <371f2774-b203-17c4-cece-31d4505b9ee1@oracle.com> Thanks for reviewing Vladimir. /Patric On 2020-07-15 19:12, Vladimir Kozlov wrote: > +1 > > Thanks, > Vladimir K > > On 7/7/20 6:59 AM, Nils Eliasson wrote: >> Hi Patric, >> >> Your change looks good. >> >> Best regards, >> Nils >> >> On 2020-07-07 13:00, Patric Hedlin wrote: >>> Dear all, >>> >>> I would like to ask for help to review the following change/update: >>> >>> Issue:? https://bugs.openjdk.java.net/browse/JDK-8248901 >>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8248901/ >>> >>> >>> Current definition(s) of is_simm() and friends are not robust over >>> inputs. Both min and max values are undefined for width > 32 (and >>> width < 0). >>> No is_uimm() is currently provided (added). Several definitions are >>> not used (cleanup). >>> >>> NOTE: Adding currently unused is_simm9() and is_uimm12(), required >>> by JDK-8247766. >>> >>> >>> Testing: hs-tier1-3 >>> >>> >>> Best regards, >>> Patric From Monica.Beckwith at microsoft.com Thu Jul 16 19:39:47 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Thu, 16 Jul 2020 19:39:47 +0000 Subject: RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC Message-ID: These changes are concerning specific macro names or keywords used by MSVC. E.g. `mvn,` `DIFFERENCE` and `far.` We are proposing to change those in the shared code. JBS: https://bugs.openjdk.java.net/browse/JDK-8248663 Webrev: https://cr.openjdk.java.net/~mbeckwit/8248663/webrev.00/ Thanks, Monica From Nikola.Grcevski at microsoft.com Thu Jul 16 21:31:58 2020 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Thu, 16 Jul 2020 21:31:58 +0000 Subject: Scoping the stack allocation prototype for C2 Message-ID: Hello hotspot-dev, We recently posted a proposal [1] to implement stack allocation in C2 on the hotspot-compiler dev mailing list. Vladimir Ivanov [2] asked that we broaden the discussion by posting here as it is more than a compiler optimization! That is, enabling object allocations on thread stacks will impact other JVM subsystems now and in future designs. If the proposal moves forward the current webrev [3] would need to be reviewed by multiple groups. This is a clear sign the wider OpenJDK community needs to provide input. An example of this proposal impacting future work, is Project Loom. Allocating objects on the stack would have to be limited in some scenarios. The implementation of stack allocated objects referencing other stack allocated objects would need to be changed *or* how Project Loom handles copying stacks would have to be modified. While all the various solutions for Project Loom would be a net win at the end, they all come with drawbacks and possible losses in performance compared to our current measured performance improvements. These decisions would need to be discussed at length to decide what was best for Hotspot and the OpenJDK community. The benefits of allocating objects on the stack, based on our proposal [1], need to be weighed against the costs on current and future features in components that will be impacted. These decisions will need to be discussed at length to decide what was best for Hotspot and the OpenJDK community. We are optimistic that this work can provide benefits to the JVM without restricting future designs to heavily. We are looking forward to receiving all feedback on this proposal. Thanks! Nikola and Charlie [1] https://github.com/microsoft/openjdk-proposals/blob/master/stack_allocation/Stack_Allocation_JEP.md [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-July/038969.html [3] https://cr.openjdk.java.net/~adityam/charlie/stack_alloc/ From Monica.Beckwith at microsoft.com Thu Jul 16 23:25:26 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Thu, 16 Jul 2020 23:25:26 +0000 Subject: RFR/Feedback(XS) 8248668: AArch64: Avoid MIN/MAX macros when using MSVC Message-ID: On Windows, we employ min/max as macros ??, hence we have made a few changes to appropriate shared sources: JBS: https://bugs.openjdk.java.net/browse/JDK-8248668 Webrev: http://cr.openjdk.java.net/~mbeckwit/8248668/webrev.00/ Regards, Monica From david.holmes at oracle.com Fri Jul 17 04:13:42 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jul 2020 14:13:42 +1000 Subject: RFR 8247878: Move Management strong oops to OopStorage In-Reply-To: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> References: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> Message-ID: <3cc4ef8a-0b3d-3827-1385-a93aed40d786@oracle.com> Hi Coleen, On 17/07/2020 1:01 am, coleen.phillimore at oracle.com wrote: > Summary: Use OopStorage for strong oops stored with memory and thread > sampling and dumping, and remove oops_do and GC calls. > > These use OopStorageSet::vm_global()? OopStorage for now.? I'll change > the thread sampling oops to use a new OopStorage once the GC code is > changed to nicely allow additional oop storages.? The memory pool oops > are never deleted once created, so they should stay in vm_global() oop > storage. > > Tested with tiers 1-3 (tiers 4-6 with other changes) and > javax/management tests.? I timed the tests to see if there was any > noticeable performance difference, and there was not. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8247878.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8247878 Overall the bulk of the changes look good - lots of red! :) I'm unsure about defining AtomicOopHandle. I think the memory ordering operations may be better kept in the code paths that use the OopHandle. The name doesn't convey what this actually does in terms of the release-set and resolve-acquire, and I can't think of a good name that would do so**. If you do want to keep it then I think there should be a non-acquire version of resolve as not all accesses require acquire semantics. Looking at memoryManager.cpp (but the same applies to memoryPool.cpp): 56 bool MemoryManager::is_manager(instanceHandle mh) const { 57 return mh() == _memory_mgr_obj.resolve_acquire(); 58 } This doesn't have acquire semantics currently and doesn't need it. 122 // The lock has done an acquire, so the load can't float above it, but 123 // we need to do a load_acquire as above. 124 mgr_obj = _memory_mgr_obj.resolve_acquire(); The original code and comment is wrong - this doesn't need acquire as the lock already handles that. If another thread has set the mgr object then it did so holding the lock that the current thread now owns, which means the other thread had to have released the lock first, hence when the current thread acquired the lock, all stores in relation to the mgr object are already guaranteed to be visible. ** Perhaps the OopHandle constructor, and resolve method should take an optional memory order Decorator parameter? --- Should we introduce a naming convention to help distinguish an oop variable from an oopHandle? You seem to have adopted the convention that _foo is the oopHandle and foo is the oop. But should we use foo_h as we do (sometimes at least) for other handles? (I'm not generally fond of encoding types in variable names but when handles and their contents can be accessed in the same code, it does make things clearer.) Thanks, David ----- > Thanks, > Coleen > > > From kim.barrett at oracle.com Fri Jul 17 09:02:34 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 17 Jul 2020 05:02:34 -0400 Subject: RFR 8247878: Move Management strong oops to OopStorage In-Reply-To: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> References: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> Message-ID: > On Jul 16, 2020, at 11:01 AM, coleen.phillimore at oracle.com wrote: > > Summary: Use OopStorage for strong oops stored with memory and thread sampling and dumping, and remove oops_do and GC calls. > > These use OopStorageSet::vm_global() OopStorage for now. I'll change the thread sampling oops to use a new OopStorage once the GC code is changed to nicely allow additional oop storages. The memory pool oops are never deleted once created, so they should stay in vm_global() oop storage. > > Tested with tiers 1-3 (tiers 4-6 with other changes) and javax/management tests. I timed the tests to see if there was any noticeable performance difference, and there was not. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8247878.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8247878 > > Thanks, > Coleen ------------------------------------------------------------------------------ src/hotspot/share/oops/oopHandle.inline.hpp 50 if (peek() != NULL) { Adding that seems like an unrelated change, and it's not clear to me why this is being done. ------------------------------------------------------------------------------ src/hotspot/share/services/lowMemoryDetector.cpp 299 if (_sensor_obj.peek() != NULL) { 300 InstanceKlass* sensorKlass = Management::sun_management_Sensor_klass(CHECK); 301 Handle sensor_h(THREAD, _sensor_obj.resolve()); I see no reason for a peek operation here, and think it just makes the code harder to understand. Just unconditionally resolve the sensor. Similarly here: 364 if (_sensor_obj.peek() != NULL) { 365 InstanceKlass* sensorKlass = Management::sun_management_Sensor_klass(CHECK); 366 Handle sensor(THREAD, _sensor_obj.resolve()); ------------------------------------------------------------------------------ src/hotspot/share/services/memoryManager.cpp 136 _memory_mgr_obj = AtomicOopHandle(OopStorageSet::vm_global(), mgr_obj); There is a race here. The handle constructor allocates the oopstorage entry and then does a release_store of the value into it. After (in source order) the handle is constructed, it is copied into _memory_mgr_obj, which is just a copy-assign of the oop* from oopstorage. There's nothing to prevent that copy-assign from being reordered before the store of the value into the oopstorage, either by the compiler or the hardware. The _obj in _memory_mgr_obj is being read without locking and may be written by another thread, so should itself be appropriate atomic. It's not clear what the semantics of this new kind of handle are supposed to be, but I think as used for _memory_mgr_obj there are problems. The same is true for _memory_pool_obj. I think the atomicity here is in the wrong place. The pointee of the oop* doesn't need atomic access, the oop* itself does. At least I think so; both _memory_mgr_obj and _memory_pool_obj are lazily assigned on first use and never change after that, right? One way to do that would be that the type of _memory_mgr_obj is `oop* volatile`, and is initialized as oop* oop_ptr = ... allocate oopstorage entry ... NativeAccess<>::oop_store(oop_ptr, value); Atomic::release_store(&_memory_mgr_obj, oop_ptr); Alternatively, use volatile OopHandle _memory_mgr_obj; Atomic::release_store(&_memory_mgr_obj, OopHandle(...)); and teach Atomic how to deal with OopHandle by defining a PrimitiveConversions::Translator for it. The declaration would be volatile OopHandle _memory_mgr_obj; and accesses would be Atomic::load_acquire(&_memory_mgr_obj).resolve(); And AtomicOopHandle isn't useful and should be discarded. ------------------------------------------------------------------------------ From thomas.schatzl at oracle.com Fri Jul 17 09:47:46 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 17 Jul 2020 11:47:46 +0200 Subject: RFR/Feedback(XS) 8248668: AArch64: Avoid MIN/MAX macros when using MSVC In-Reply-To: References: Message-ID: <1759d457-3045-9b2c-4c3b-54f30e09efc2@oracle.com> Hi, On 17.07.20 01:25, Monica Beckwith wrote: > On Windows, we employ min/max as macros ??, hence we have made a few changes to appropriate shared sources: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248668 > Webrev: http://cr.openjdk.java.net/~mbeckwit/8248668/webrev.00/ > > Regards, > Monica > lgtm. Thomas From coleen.phillimore at oracle.com Fri Jul 17 14:37:30 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Jul 2020 10:37:30 -0400 Subject: RFR 8247878: Move Management strong oops to OopStorage In-Reply-To: <3cc4ef8a-0b3d-3827-1385-a93aed40d786@oracle.com> References: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> <3cc4ef8a-0b3d-3827-1385-a93aed40d786@oracle.com> Message-ID: <6d4718e7-a040-8d3b-07b7-4e5d4f98e63f@oracle.com> Hi David, thank you for reviewing this. On 7/17/20 12:13 AM, David Holmes wrote: > Hi Coleen, > > On 17/07/2020 1:01 am, coleen.phillimore at oracle.com wrote: >> Summary: Use OopStorage for strong oops stored with memory and thread >> sampling and dumping, and remove oops_do and GC calls. >> >> These use OopStorageSet::vm_global()? OopStorage for now.? I'll >> change the thread sampling oops to use a new OopStorage once the GC >> code is changed to nicely allow additional oop storages.? The memory >> pool oops are never deleted once created, so they should stay in >> vm_global() oop storage. >> >> Tested with tiers 1-3 (tiers 4-6 with other changes) and >> javax/management tests.? I timed the tests to see if there was any >> noticeable performance difference, and there was not. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8247878.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8247878 > > Overall the bulk of the changes look good - lots of red! :) Yup! > > I'm unsure about defining AtomicOopHandle. I think the memory ordering > operations may be better kept in the code paths that use the > OopHandle. The name doesn't convey what this actually does in terms of > the release-set and resolve-acquire, and I can't think of a good name > that would do so**. If you do want to keep it then I think there > should be a non-acquire version of resolve as not all accesses require > acquire semantics. Looking at memoryManager.cpp (but the same applies > to memoryPool.cpp): I do want to keep the separate type because it's sort of inconvient to declare the underlying oop in the OopHandle as volatile or whatever we're going to do to replace volatile.? Plus a separate type allows the compiler to give an error if the access rules are broken.? Scattering these varying accesses around the vm with reasoning makes the code too complicated.? Kim and I came up with the name AtomicOopHandle since it uses the same mechanism as the underlying MO_ACQUIRE/MO_RELEASE semantics. > > ? 56 bool MemoryManager::is_manager(instanceHandle mh) const { > ? 57?? return mh() == _memory_mgr_obj.resolve_acquire(); > ? 58 } > > This doesn't have acquire semantics currently and doesn't need it. > > ?122?????? // The lock has done an acquire, so the load can't float > above it, but > ?123?????? // we need to do a load_acquire as above. > ?124?????? mgr_obj = _memory_mgr_obj.resolve_acquire(); Yes, this used to just have Atomic::load() and not acquire.? I didn't really see any reason to optimize and break the consistency in order to do a plain resolve().? I could add it, it just seems not useful. > > The original code and comment is wrong - this doesn't need acquire as > the lock already handles that. If another thread has set the mgr > object then it did so holding the lock that the current thread now > owns, which means the other thread had to have released the lock > first, hence when the current thread acquired the lock, all stores in > relation to the mgr object are already guaranteed to be visible. Yes, true.? I can fix the comment or remove it since using OopHandle, there will be a load that cannot float. > > ** Perhaps the OopHandle constructor, and resolve method should take > an optional memory order Decorator parameter? We still need to redeclare the underlying oop* though. > > --- > > Should we introduce a naming convention to help distinguish an oop > variable from an oopHandle? You seem to have adopted the convention > that _foo is the oopHandle and foo is the oop. But should we use foo_h > as we do (sometimes at least) for other handles? (I'm not generally > fond of encoding types in variable names but when handles and their > contents can be accessed in the same code, it does make things clearer.) I want to vote no on that.? _foo is the OopHandle because that's how the field is declared.? The only place I did this was here: http://cr.openjdk.java.net/~coleenp/2020/8247878.01/webrev/src/hotspot/share/services/threadService.cpp.udiff.html I don't think it'll help to have _blocker_object_h distinguishible from blocker_object.? I think the code is somewhat clear that the field is assigned at the end. Thanks, Coleen > > Thanks, > David > ----- > >> Thanks, >> Coleen >> >> >> From coleen.phillimore at oracle.com Fri Jul 17 14:50:27 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Jul 2020 10:50:27 -0400 Subject: RFR 8247878: Move Management strong oops to OopStorage In-Reply-To: References: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> Message-ID: <35eaeb91-7b56-0074-b871-47f24998d31d@oracle.com> Hi Kim, Thank you for reviewing this. On 7/17/20 5:02 AM, Kim Barrett wrote: >> On Jul 16, 2020, at 11:01 AM, coleen.phillimore at oracle.com wrote: >> >> Summary: Use OopStorage for strong oops stored with memory and thread sampling and dumping, and remove oops_do and GC calls. >> >> These use OopStorageSet::vm_global() OopStorage for now. I'll change the thread sampling oops to use a new OopStorage once the GC code is changed to nicely allow additional oop storages. The memory pool oops are never deleted once created, so they should stay in vm_global() oop storage. >> >> Tested with tiers 1-3 (tiers 4-6 with other changes) and javax/management tests. I timed the tests to see if there was any noticeable performance difference, and there was not. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8247878.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8247878 >> >> Thanks, >> Coleen > ------------------------------------------------------------------------------ > src/hotspot/share/oops/oopHandle.inline.hpp > 50 if (peek() != NULL) { > > Adding that seems like an unrelated change, and it's not clear to me > why this is being done. This was to save null checks in all the callers, particularly here: ThreadSnapshot::~ThreadSnapshot() { + _blocker_object.release(OopStorageSet::vm_global()); + _blocker_object_owner.release(OopStorageSet::vm_global()); + _threadObj.release(OopStorageSet::vm_global()); + > > ------------------------------------------------------------------------------ > src/hotspot/share/services/lowMemoryDetector.cpp > 299 if (_sensor_obj.peek() != NULL) { > 300 InstanceKlass* sensorKlass = Management::sun_management_Sensor_klass(CHECK); > 301 Handle sensor_h(THREAD, _sensor_obj.resolve()); > > I see no reason for a peek operation here, and think it just makes the > code harder to understand. Just unconditionally resolve the sensor. > > Similarly here: > 364 if (_sensor_obj.peek() != NULL) { > 365 InstanceKlass* sensorKlass = Management::sun_management_Sensor_klass(CHECK); > 366 Handle sensor(THREAD, _sensor_obj.resolve()); I can move the NULL check down after the Handle.? I was mostly keeping the existing pattern. > > ------------------------------------------------------------------------------ > src/hotspot/share/services/memoryManager.cpp > 136 _memory_mgr_obj = AtomicOopHandle(OopStorageSet::vm_global(), mgr_obj); > > There is a race here. The handle constructor allocates the oopstorage > entry and then does a release_store of the value into it. After (in > source order) the handle is constructed, it is copied into > _memory_mgr_obj, which is just a copy-assign of the oop* from > oopstorage. There's nothing to prevent that copy-assign from being > reordered before the store of the value into the oopstorage, either by > the compiler or the hardware. Ok, I see that. > > The _obj in _memory_mgr_obj is being read without locking and may be > written by another thread, so should itself be appropriate atomic. > It's not clear what the semantics of this new kind of handle are > supposed to be, but I think as used for _memory_mgr_obj there are > problems. > > The same is true for _memory_pool_obj. > > I think the atomicity here is in the wrong place. The pointee of the > oop* doesn't need atomic access, the oop* itself does. At least I > think so; both _memory_mgr_obj and _memory_pool_obj are lazily > assigned on first use and never change after that, right? Yes.? volatile is in the wrong place. > > One way to do that would be that the type of _memory_mgr_obj is `oop* > volatile`, and is initialized as > > oop* oop_ptr = ... allocate oopstorage entry ... > NativeAccess<>::oop_store(oop_ptr, value); > Atomic::release_store(&_memory_mgr_obj, oop_ptr); > > Alternatively, use > > volatile OopHandle _memory_mgr_obj; > > Atomic::release_store(&_memory_mgr_obj, OopHandle(...)); > > and teach Atomic how to deal with OopHandle by defining a > PrimitiveConversions::Translator for it. > > The declaration would be > > volatile OopHandle _memory_mgr_obj; > > and accesses would be > > Atomic::load_acquire(&_memory_mgr_obj).resolve(); > > And AtomicOopHandle isn't useful and should be discarded. Ok, yes, this is exactly what I want.? And David will be happy because he didn't like AtomicOopHandle. Thanks for catching this and your help. Coleen > > ------------------------------------------------------------------------------ > From kim.barrett at oracle.com Fri Jul 17 17:44:16 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 17 Jul 2020 13:44:16 -0400 Subject: RFR/Feedback(XS) 8248668: AArch64: Avoid MIN/MAX macros when using MSVC In-Reply-To: References: Message-ID: <95EC79BD-A213-4ACD-B3B7-A8A112B2C2F7@oracle.com> > On Jul 16, 2020, at 7:25 PM, Monica Beckwith wrote: > > On Windows, we employ min/max as macros ??, hence we have made a few changes to appropriate shared sources: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248668 > Webrev: http://cr.openjdk.java.net/~mbeckwit/8248668/webrev.00/ > > Regards, > Monica Looks good. From sandhya.viswanathan at intel.com Fri Jul 17 18:32:04 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Fri, 17 Jul 2020 18:32:04 +0000 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): Hotspot and x86 backend changes Message-ID: Hi Vladimir and Coleen, We are getting ready to propose to target Vector API to JDK 16. Please find below the updated hotspot and x86 backend changes: Shared Hotspot: Full: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/hs_webrev/webrev.01/ Incremental: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/hs_webrev/webrev.00-webrev.01/ X86: Full: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.01/ Incremental: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00-webrev.01/ Older webrev links for your reference: Shared Hotspot: http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/ X86b backend: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ To get incremental webrev, I had to do some adjustments to these to be able to apply it to the jdk tip. Please let us know your feedback and if we have ok from you to propose to target to JDK 16. Best Regards, Sandhya -----Original Message----- From: Vladimir Kozlov Sent: Friday, May 01, 2020 6:05 PM To: Viswanathan, Sandhya ; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes On 5/1/20 5:55 PM, Viswanathan, Sandhya wrote: > Hi Vladimir, > > Thanks a lot for the feedback. > > We used an old existing separate branch to share the code for review and to track changes. > We didn?t know how to change the name of the branch from vector-unstable to vector-stable. Good to know that it does not mean that code is "unstable" ;) Katya filed today new bug [1]. Please look. Regards, Vladimir [1] https://bugs.openjdk.java.net/browse/JDK-8244269 > > Best Regards, > Sandhya > > -----Original Message----- > From: Vladimir Kozlov > Sent: Friday, May 01, 2020 5:32 PM > To: Viswanathan, Sandhya ; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev > Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes > > Changes seems fine. Nice work. > > Why it is called "vector-unstable branch"? > > Thanks, > Vladimir K > > On 4/3/20 5:16 PM, Viswanathan, Sandhya wrote: >> Hi, >> >> >> Following up on review requests of API [0], Java implementation [1] and >> >> General Hotspot changes[3] for Vector API, here's a request for review >> >> of x86 backend changes required for supporting the API: >> >> >> >> JEP: https://openjdk.java.net/jeps/338 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 >> >> Webrev:http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ >> >> >> >> Complete implementation resides in vector-unstable branch of >> >> panama/dev repository [3]. >> >> Looking forward to your feedback. >> >> Best Regards, >> Sandhya >> >> >> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >> >> >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html >> >> >> >> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html >> >> >> >> [3] https://openjdk.java.net/projects/panama/ >> >> $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable >> >> >> >> >> From coleen.phillimore at oracle.com Fri Jul 17 21:29:09 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Jul 2020 17:29:09 -0400 Subject: RFR 8247878: Move Management strong oops to OopStorage In-Reply-To: <35eaeb91-7b56-0074-b871-47f24998d31d@oracle.com> References: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> <35eaeb91-7b56-0074-b871-47f24998d31d@oracle.com> Message-ID: I've corrected this change with Kim's and David's feedback, and retested with tier1-3.? This is much better. incremental webrev at http://cr.openjdk.java.net/~coleenp/2020/8247878.02.incr/webrev full webrev at http://cr.openjdk.java.net/~coleenp/2020/8247878.02/webrev Thanks, Coleen On 7/17/20 10:50 AM, coleen.phillimore at oracle.com wrote: > > Hi Kim, Thank you for reviewing this. > > On 7/17/20 5:02 AM, Kim Barrett wrote: >>> On Jul 16, 2020, at 11:01 AM, coleen.phillimore at oracle.com wrote: >>> >>> Summary: Use OopStorage for strong oops stored with memory and >>> thread sampling and dumping, and remove oops_do and GC calls. >>> >>> These use OopStorageSet::vm_global()? OopStorage for now. I'll >>> change the thread sampling oops to use a new OopStorage once the GC >>> code is changed to nicely allow additional oop storages.? The memory >>> pool oops are never deleted once created, so they should stay in >>> vm_global() oop storage. >>> >>> Tested with tiers 1-3 (tiers 4-6 with other changes) and >>> javax/management tests.? I timed the tests to see if there was any >>> noticeable performance difference, and there was not. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8247878.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8247878 >>> >>> Thanks, >>> Coleen >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/oops/oopHandle.inline.hpp >> ?? 50?? if (peek() != NULL) { >> >> Adding that seems like an unrelated change, and it's not clear to me >> why this is being done. > > This was to save null checks in all the callers, particularly here: > > ?ThreadSnapshot::~ThreadSnapshot() { > + _blocker_object.release(OopStorageSet::vm_global()); > + _blocker_object_owner.release(OopStorageSet::vm_global()); > + _threadObj.release(OopStorageSet::vm_global()); > + > >> >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/services/lowMemoryDetector.cpp >> ? 299?? if (_sensor_obj.peek() != NULL) { >> ? 300???? InstanceKlass* sensorKlass = >> Management::sun_management_Sensor_klass(CHECK); >> ? 301???? Handle sensor_h(THREAD, _sensor_obj.resolve()); >> >> I see no reason for a peek operation here, and think it just makes the >> code harder to understand.? Just unconditionally resolve the sensor. >> >> Similarly here: >> ? 364?? if (_sensor_obj.peek() != NULL) { >> ? 365???? InstanceKlass* sensorKlass = >> Management::sun_management_Sensor_klass(CHECK); >> ? 366???? Handle sensor(THREAD, _sensor_obj.resolve()); > > I can move the NULL check down after the Handle.? I was mostly keeping > the existing pattern. >> >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/services/memoryManager.cpp >> ? 136?????? _memory_mgr_obj = >> AtomicOopHandle(OopStorageSet::vm_global(), mgr_obj); >> >> There is a race here. The handle constructor allocates the oopstorage >> entry and then does a release_store of the value into it. After (in >> source order) the handle is constructed, it is copied into >> _memory_mgr_obj, which is just a copy-assign of the oop* from >> oopstorage. There's nothing to prevent that copy-assign from being >> reordered before the store of the value into the oopstorage, either by >> the compiler or the hardware. > > Ok, I see that. >> >> The _obj in _memory_mgr_obj is being read without locking and may be >> written by another thread, so should itself be appropriate atomic. >> It's not clear what the semantics of this new kind of handle are >> supposed to be, but I think as used for _memory_mgr_obj there are >> problems. >> >> The same is true for _memory_pool_obj. >> >> I think the atomicity here is in the wrong place. The pointee of the >> oop* doesn't need atomic access, the oop* itself does.? At least I >> think so; both _memory_mgr_obj and _memory_pool_obj are lazily >> assigned on first use and never change after that, right? > > Yes.? volatile is in the wrong place. >> >> One way to do that would be that the type of _memory_mgr_obj is `oop* >> volatile`, and is initialized as >> >> ?? oop* oop_ptr = ... allocate oopstorage entry ... >> ?? NativeAccess<>::oop_store(oop_ptr, value); >> ?? Atomic::release_store(&_memory_mgr_obj, oop_ptr); >> >> Alternatively, use >> >> ?? volatile OopHandle _memory_mgr_obj; >> >> ?? Atomic::release_store(&_memory_mgr_obj, OopHandle(...)); >> >> and teach Atomic how to deal with OopHandle by defining a >> PrimitiveConversions::Translator for it. >> >> The declaration would be >> >> ?? volatile OopHandle _memory_mgr_obj; >> >> and accesses would be >> >> ?? Atomic::load_acquire(&_memory_mgr_obj).resolve(); >> >> And AtomicOopHandle isn't useful and should be discarded. > > Ok, yes, this is exactly what I want.? And David will be happy because > he didn't like AtomicOopHandle. > > Thanks for catching this and your help. > Coleen > >> >> ------------------------------------------------------------------------------ >> >> > From ningsheng.jian at arm.com Mon Jul 20 03:51:25 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Mon, 20 Jul 2020 11:51:25 +0800 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com> Message-ID: <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com> Hi Andrew and all, Since we are getting ready to propose Vector API target to JDK 16 [1]. I have regenerated webrev of aarch64 backend parts from panama repo, which has been rebased to jdk/jdk very recently, by: $ hg update vector-unstable && hg diff -r default > all.patch $ grep "diff -r" all.patch | grep -e "src/hotspot/cpu/aarch64" | awk '{print $4}' > aarch64_list $ ksh ./webrev.ksh -r default -o aarch64_webrev aarch64_list The new webrev: http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ Could you please help to take a look? Yang's previous webrevs can still be found at [2], with review comments addressed in the latest webrev above. [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2020-July/042427.html [2] http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/ Thanks, Ningsheng On 7/8/20 3:05 PM, Yang Zhang wrote: > Hi Andrew > > I have updated this patch. Could you please help to review it again? > In this patch, the following changes are made: > 1. Separate newly added NEON instructions to a new ad file > aarch64_neon.ad > 2. Add assembler tests for NEON instructions. Trailing spaces > in the python script are also removed. > > http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ > > Thanks, > Yang > > > -----Original Message----- > From: Andrew Haley > Sent: Tuesday, June 30, 2020 12:10 AM > To: Yang Zhang ; Viswanathan, Sandhya ; Paul Sandoz > Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes > > On 29/06/2020 08:48, Yang Zhang wrote: >> 1. Instructions that can be matched with NEON instructions directly. >> MulVB, SqrtVF and AbsV have been merged into jdk master already. >> >> 2. Instructions that jdk master has middle end support for, but they cannot be matched with NEON instructions directly. >> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. >> >> 3. Panama/Vector API specific instructions such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. >> These instructions cannot be moved into jdk master first because there isn't middle-end support. >> >> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send it again. > > Thank you *very* much for your hard work. Appreciated! > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From david.holmes at oracle.com Mon Jul 20 04:47:25 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Jul 2020 14:47:25 +1000 Subject: RFR 8247878: Move Management strong oops to OopStorage In-Reply-To: References: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> <35eaeb91-7b56-0074-b871-47f24998d31d@oracle.com> Message-ID: Hi Coleen, On 18/07/2020 7:29 am, coleen.phillimore at oracle.com wrote: > > I've corrected this change with Kim's and David's feedback, and retested > with tier1-3.? This is much better. Yes this is better. :) Thanks to Kim for clarifying the acquire/release issue. LGTM. Thanks, David ----- > incremental webrev at > http://cr.openjdk.java.net/~coleenp/2020/8247878.02.incr/webrev > full webrev at http://cr.openjdk.java.net/~coleenp/2020/8247878.02/webrev > > Thanks, > Coleen > > On 7/17/20 10:50 AM, coleen.phillimore at oracle.com wrote: >> >> Hi Kim, Thank you for reviewing this. >> >> On 7/17/20 5:02 AM, Kim Barrett wrote: >>>> On Jul 16, 2020, at 11:01 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> Summary: Use OopStorage for strong oops stored with memory and >>>> thread sampling and dumping, and remove oops_do and GC calls. >>>> >>>> These use OopStorageSet::vm_global()? OopStorage for now. I'll >>>> change the thread sampling oops to use a new OopStorage once the GC >>>> code is changed to nicely allow additional oop storages.? The memory >>>> pool oops are never deleted once created, so they should stay in >>>> vm_global() oop storage. >>>> >>>> Tested with tiers 1-3 (tiers 4-6 with other changes) and >>>> javax/management tests.? I timed the tests to see if there was any >>>> noticeable performance difference, and there was not. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8247878.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8247878 >>>> >>>> Thanks, >>>> Coleen >>> ------------------------------------------------------------------------------ >>> >>> src/hotspot/share/oops/oopHandle.inline.hpp >>> ?? 50?? if (peek() != NULL) { >>> >>> Adding that seems like an unrelated change, and it's not clear to me >>> why this is being done. >> >> This was to save null checks in all the callers, particularly here: >> >> ?ThreadSnapshot::~ThreadSnapshot() { >> + _blocker_object.release(OopStorageSet::vm_global()); >> + _blocker_object_owner.release(OopStorageSet::vm_global()); >> + _threadObj.release(OopStorageSet::vm_global()); >> + >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/hotspot/share/services/lowMemoryDetector.cpp >>> ? 299?? if (_sensor_obj.peek() != NULL) { >>> ? 300???? InstanceKlass* sensorKlass = >>> Management::sun_management_Sensor_klass(CHECK); >>> ? 301???? Handle sensor_h(THREAD, _sensor_obj.resolve()); >>> >>> I see no reason for a peek operation here, and think it just makes the >>> code harder to understand.? Just unconditionally resolve the sensor. >>> >>> Similarly here: >>> ? 364?? if (_sensor_obj.peek() != NULL) { >>> ? 365???? InstanceKlass* sensorKlass = >>> Management::sun_management_Sensor_klass(CHECK); >>> ? 366???? Handle sensor(THREAD, _sensor_obj.resolve()); >> >> I can move the NULL check down after the Handle.? I was mostly keeping >> the existing pattern. >>> >>> ------------------------------------------------------------------------------ >>> >>> src/hotspot/share/services/memoryManager.cpp >>> ? 136?????? _memory_mgr_obj = >>> AtomicOopHandle(OopStorageSet::vm_global(), mgr_obj); >>> >>> There is a race here. The handle constructor allocates the oopstorage >>> entry and then does a release_store of the value into it. After (in >>> source order) the handle is constructed, it is copied into >>> _memory_mgr_obj, which is just a copy-assign of the oop* from >>> oopstorage. There's nothing to prevent that copy-assign from being >>> reordered before the store of the value into the oopstorage, either by >>> the compiler or the hardware. >> >> Ok, I see that. >>> >>> The _obj in _memory_mgr_obj is being read without locking and may be >>> written by another thread, so should itself be appropriate atomic. >>> It's not clear what the semantics of this new kind of handle are >>> supposed to be, but I think as used for _memory_mgr_obj there are >>> problems. >>> >>> The same is true for _memory_pool_obj. >>> >>> I think the atomicity here is in the wrong place. The pointee of the >>> oop* doesn't need atomic access, the oop* itself does.? At least I >>> think so; both _memory_mgr_obj and _memory_pool_obj are lazily >>> assigned on first use and never change after that, right? >> >> Yes.? volatile is in the wrong place. >>> >>> One way to do that would be that the type of _memory_mgr_obj is `oop* >>> volatile`, and is initialized as >>> >>> ?? oop* oop_ptr = ... allocate oopstorage entry ... >>> ?? NativeAccess<>::oop_store(oop_ptr, value); >>> ?? Atomic::release_store(&_memory_mgr_obj, oop_ptr); >>> >>> Alternatively, use >>> >>> ?? volatile OopHandle _memory_mgr_obj; >>> >>> ?? Atomic::release_store(&_memory_mgr_obj, OopHandle(...)); >>> >>> and teach Atomic how to deal with OopHandle by defining a >>> PrimitiveConversions::Translator for it. >>> >>> The declaration would be >>> >>> ?? volatile OopHandle _memory_mgr_obj; >>> >>> and accesses would be >>> >>> ?? Atomic::load_acquire(&_memory_mgr_obj).resolve(); >>> >>> And AtomicOopHandle isn't useful and should be discarded. >> >> Ok, yes, this is exactly what I want.? And David will be happy because >> he didn't like AtomicOopHandle. >> >> Thanks for catching this and your help. >> Coleen >> >>> >>> ------------------------------------------------------------------------------ >>> >>> >> > From kim.barrett at oracle.com Mon Jul 20 05:25:13 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 20 Jul 2020 01:25:13 -0400 Subject: RFR 8247878: Move Management strong oops to OopStorage In-Reply-To: References: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> <35eaeb91-7b56-0074-b871-47f24998d31d@oracle.com> Message-ID: <78CB6EA3-AAFA-498F-827A-D3EE82883FC9@oracle.com> > On Jul 20, 2020, at 12:47 AM, David Holmes wrote: > > Hi Coleen, > > On 18/07/2020 7:29 am, coleen.phillimore at oracle.com wrote: >> I've corrected this change with Kim's and David's feedback, and retested with tier1-3. This is much better. > > Yes this is better. :) Thanks to Kim for clarifying the acquire/release issue. > > LGTM. > > Thanks, > David Looks good. From tobias.hartmann at oracle.com Mon Jul 20 07:46:34 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 20 Jul 2020 09:46:34 +0200 Subject: RFR(S): 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <3df3dab6-aa2f-bbbc-d231-6cda8f2a0ff7@oracle.com> References: <3df3dab6-aa2f-bbbc-d231-6cda8f2a0ff7@oracle.com> Message-ID: <91ddfdac-2ce4-637c-b68c-7e042d67483f@oracle.com> Hi Patric, looks good to me. Best regards, Tobias On 07.07.20 13:00, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8248901 > Webrev: http://cr.openjdk.java.net/~phedlin/tr8248901/ > > > Current definition(s) of is_simm() and friends are not robust over inputs. Both min and max values > are undefined for width > 32 (and width < 0). > No is_uimm() is currently provided (added). Several definitions are not used (cleanup). > > NOTE: Adding currently unused is_simm9() and is_uimm12(), required by JDK-8247766. > > > Testing: hs-tier1-3 > > > Best regards, > Patric From coleen.phillimore at oracle.com Mon Jul 20 11:01:53 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 20 Jul 2020 07:01:53 -0400 Subject: RFR 8247878: Move Management strong oops to OopStorage In-Reply-To: References: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> <35eaeb91-7b56-0074-b871-47f24998d31d@oracle.com> Message-ID: On 7/17/20 5:29 PM, coleen.phillimore at oracle.com wrote: > > I've corrected this change with Kim's and David's feedback, and > retested with tier1-3.? This is much better. Webrev 02 also contains the change to remove the load_acquire() and comment inside the Management_lock block.? Thanks David. Coleen > > incremental webrev at > http://cr.openjdk.java.net/~coleenp/2020/8247878.02.incr/webrev > full webrev at http://cr.openjdk.java.net/~coleenp/2020/8247878.02/webrev > > Thanks, > Coleen > > On 7/17/20 10:50 AM, coleen.phillimore at oracle.com wrote: >> >> Hi Kim, Thank you for reviewing this. >> >> On 7/17/20 5:02 AM, Kim Barrett wrote: >>>> On Jul 16, 2020, at 11:01 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> Summary: Use OopStorage for strong oops stored with memory and >>>> thread sampling and dumping, and remove oops_do and GC calls. >>>> >>>> These use OopStorageSet::vm_global()? OopStorage for now. I'll >>>> change the thread sampling oops to use a new OopStorage once the GC >>>> code is changed to nicely allow additional oop storages.? The >>>> memory pool oops are never deleted once created, so they should >>>> stay in vm_global() oop storage. >>>> >>>> Tested with tiers 1-3 (tiers 4-6 with other changes) and >>>> javax/management tests.? I timed the tests to see if there was any >>>> noticeable performance difference, and there was not. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8247878.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8247878 >>>> >>>> Thanks, >>>> Coleen >>> ------------------------------------------------------------------------------ >>> >>> src/hotspot/share/oops/oopHandle.inline.hpp >>> ?? 50?? if (peek() != NULL) { >>> >>> Adding that seems like an unrelated change, and it's not clear to me >>> why this is being done. >> >> This was to save null checks in all the callers, particularly here: >> >> ?ThreadSnapshot::~ThreadSnapshot() { >> + _blocker_object.release(OopStorageSet::vm_global()); >> + _blocker_object_owner.release(OopStorageSet::vm_global()); >> + _threadObj.release(OopStorageSet::vm_global()); >> + >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/hotspot/share/services/lowMemoryDetector.cpp >>> ? 299?? if (_sensor_obj.peek() != NULL) { >>> ? 300???? InstanceKlass* sensorKlass = >>> Management::sun_management_Sensor_klass(CHECK); >>> ? 301???? Handle sensor_h(THREAD, _sensor_obj.resolve()); >>> >>> I see no reason for a peek operation here, and think it just makes the >>> code harder to understand.? Just unconditionally resolve the sensor. >>> >>> Similarly here: >>> ? 364?? if (_sensor_obj.peek() != NULL) { >>> ? 365???? InstanceKlass* sensorKlass = >>> Management::sun_management_Sensor_klass(CHECK); >>> ? 366???? Handle sensor(THREAD, _sensor_obj.resolve()); >> >> I can move the NULL check down after the Handle.? I was mostly >> keeping the existing pattern. >>> >>> ------------------------------------------------------------------------------ >>> >>> src/hotspot/share/services/memoryManager.cpp >>> ? 136?????? _memory_mgr_obj = >>> AtomicOopHandle(OopStorageSet::vm_global(), mgr_obj); >>> >>> There is a race here. The handle constructor allocates the oopstorage >>> entry and then does a release_store of the value into it. After (in >>> source order) the handle is constructed, it is copied into >>> _memory_mgr_obj, which is just a copy-assign of the oop* from >>> oopstorage. There's nothing to prevent that copy-assign from being >>> reordered before the store of the value into the oopstorage, either by >>> the compiler or the hardware. >> >> Ok, I see that. >>> >>> The _obj in _memory_mgr_obj is being read without locking and may be >>> written by another thread, so should itself be appropriate atomic. >>> It's not clear what the semantics of this new kind of handle are >>> supposed to be, but I think as used for _memory_mgr_obj there are >>> problems. >>> >>> The same is true for _memory_pool_obj. >>> >>> I think the atomicity here is in the wrong place. The pointee of the >>> oop* doesn't need atomic access, the oop* itself does.? At least I >>> think so; both _memory_mgr_obj and _memory_pool_obj are lazily >>> assigned on first use and never change after that, right? >> >> Yes.? volatile is in the wrong place. >>> >>> One way to do that would be that the type of _memory_mgr_obj is `oop* >>> volatile`, and is initialized as >>> >>> ?? oop* oop_ptr = ... allocate oopstorage entry ... >>> ?? NativeAccess<>::oop_store(oop_ptr, value); >>> ?? Atomic::release_store(&_memory_mgr_obj, oop_ptr); >>> >>> Alternatively, use >>> >>> ?? volatile OopHandle _memory_mgr_obj; >>> >>> ?? Atomic::release_store(&_memory_mgr_obj, OopHandle(...)); >>> >>> and teach Atomic how to deal with OopHandle by defining a >>> PrimitiveConversions::Translator for it. >>> >>> The declaration would be >>> >>> ?? volatile OopHandle _memory_mgr_obj; >>> >>> and accesses would be >>> >>> ?? Atomic::load_acquire(&_memory_mgr_obj).resolve(); >>> >>> And AtomicOopHandle isn't useful and should be discarded. >> >> Ok, yes, this is exactly what I want.? And David will be happy >> because he didn't like AtomicOopHandle. >> >> Thanks for catching this and your help. >> Coleen >> >>> >>> ------------------------------------------------------------------------------ >>> >>> >> > From coleen.phillimore at oracle.com Mon Jul 20 11:33:26 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 20 Jul 2020 07:33:26 -0400 Subject: RFR 8247878: Move Management strong oops to OopStorage In-Reply-To: References: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> <35eaeb91-7b56-0074-b871-47f24998d31d@oracle.com> Message-ID: David, thank you for the review and help. Coleen On 7/20/20 12:47 AM, David Holmes wrote: > Hi Coleen, > > On 18/07/2020 7:29 am, coleen.phillimore at oracle.com wrote: >> >> I've corrected this change with Kim's and David's feedback, and >> retested with tier1-3.? This is much better. > > Yes this is better. :) Thanks to Kim for clarifying the > acquire/release issue. > > LGTM. > > Thanks, > David > ----- > >> incremental webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8247878.02.incr/webrev >> full webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8247878.02/webrev >> >> Thanks, >> Coleen >> >> On 7/17/20 10:50 AM, coleen.phillimore at oracle.com wrote: >>> >>> Hi Kim, Thank you for reviewing this. >>> >>> On 7/17/20 5:02 AM, Kim Barrett wrote: >>>>> On Jul 16, 2020, at 11:01 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Summary: Use OopStorage for strong oops stored with memory and >>>>> thread sampling and dumping, and remove oops_do and GC calls. >>>>> >>>>> These use OopStorageSet::vm_global()? OopStorage for now. I'll >>>>> change the thread sampling oops to use a new OopStorage once the >>>>> GC code is changed to nicely allow additional oop storages.? The >>>>> memory pool oops are never deleted once created, so they should >>>>> stay in vm_global() oop storage. >>>>> >>>>> Tested with tiers 1-3 (tiers 4-6 with other changes) and >>>>> javax/management tests.? I timed the tests to see if there was any >>>>> noticeable performance difference, and there was not. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8247878.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8247878 >>>>> >>>>> Thanks, >>>>> Coleen >>>> ------------------------------------------------------------------------------ >>>> >>>> src/hotspot/share/oops/oopHandle.inline.hpp >>>> ?? 50?? if (peek() != NULL) { >>>> >>>> Adding that seems like an unrelated change, and it's not clear to me >>>> why this is being done. >>> >>> This was to save null checks in all the callers, particularly here: >>> >>> ?ThreadSnapshot::~ThreadSnapshot() { >>> + _blocker_object.release(OopStorageSet::vm_global()); >>> + _blocker_object_owner.release(OopStorageSet::vm_global()); >>> + _threadObj.release(OopStorageSet::vm_global()); >>> + >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/hotspot/share/services/lowMemoryDetector.cpp >>>> ? 299?? if (_sensor_obj.peek() != NULL) { >>>> ? 300???? InstanceKlass* sensorKlass = >>>> Management::sun_management_Sensor_klass(CHECK); >>>> ? 301???? Handle sensor_h(THREAD, _sensor_obj.resolve()); >>>> >>>> I see no reason for a peek operation here, and think it just makes the >>>> code harder to understand.? Just unconditionally resolve the sensor. >>>> >>>> Similarly here: >>>> ? 364?? if (_sensor_obj.peek() != NULL) { >>>> ? 365???? InstanceKlass* sensorKlass = >>>> Management::sun_management_Sensor_klass(CHECK); >>>> ? 366???? Handle sensor(THREAD, _sensor_obj.resolve()); >>> >>> I can move the NULL check down after the Handle.? I was mostly >>> keeping the existing pattern. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/hotspot/share/services/memoryManager.cpp >>>> ? 136?????? _memory_mgr_obj = >>>> AtomicOopHandle(OopStorageSet::vm_global(), mgr_obj); >>>> >>>> There is a race here. The handle constructor allocates the oopstorage >>>> entry and then does a release_store of the value into it. After (in >>>> source order) the handle is constructed, it is copied into >>>> _memory_mgr_obj, which is just a copy-assign of the oop* from >>>> oopstorage. There's nothing to prevent that copy-assign from being >>>> reordered before the store of the value into the oopstorage, either by >>>> the compiler or the hardware. >>> >>> Ok, I see that. >>>> >>>> The _obj in _memory_mgr_obj is being read without locking and may be >>>> written by another thread, so should itself be appropriate atomic. >>>> It's not clear what the semantics of this new kind of handle are >>>> supposed to be, but I think as used for _memory_mgr_obj there are >>>> problems. >>>> >>>> The same is true for _memory_pool_obj. >>>> >>>> I think the atomicity here is in the wrong place. The pointee of the >>>> oop* doesn't need atomic access, the oop* itself does.? At least I >>>> think so; both _memory_mgr_obj and _memory_pool_obj are lazily >>>> assigned on first use and never change after that, right? >>> >>> Yes.? volatile is in the wrong place. >>>> >>>> One way to do that would be that the type of _memory_mgr_obj is `oop* >>>> volatile`, and is initialized as >>>> >>>> ?? oop* oop_ptr = ... allocate oopstorage entry ... >>>> ?? NativeAccess<>::oop_store(oop_ptr, value); >>>> ?? Atomic::release_store(&_memory_mgr_obj, oop_ptr); >>>> >>>> Alternatively, use >>>> >>>> ?? volatile OopHandle _memory_mgr_obj; >>>> >>>> ?? Atomic::release_store(&_memory_mgr_obj, OopHandle(...)); >>>> >>>> and teach Atomic how to deal with OopHandle by defining a >>>> PrimitiveConversions::Translator for it. >>>> >>>> The declaration would be >>>> >>>> ?? volatile OopHandle _memory_mgr_obj; >>>> >>>> and accesses would be >>>> >>>> ?? Atomic::load_acquire(&_memory_mgr_obj).resolve(); >>>> >>>> And AtomicOopHandle isn't useful and should be discarded. >>> >>> Ok, yes, this is exactly what I want.? And David will be happy >>> because he didn't like AtomicOopHandle. >>> >>> Thanks for catching this and your help. >>> Coleen >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>> >> From coleen.phillimore at oracle.com Mon Jul 20 11:33:48 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 20 Jul 2020 07:33:48 -0400 Subject: RFR 8247878: Move Management strong oops to OopStorage In-Reply-To: <78CB6EA3-AAFA-498F-827A-D3EE82883FC9@oracle.com> References: <05ce335a-d836-cf15-65b8-e015a5a93c30@oracle.com> <35eaeb91-7b56-0074-b871-47f24998d31d@oracle.com> <78CB6EA3-AAFA-498F-827A-D3EE82883FC9@oracle.com> Message-ID: <5d8f7e96-674a-4e4f-b5cb-f4054263ba65@oracle.com> Kim, Thank you for your help. Coleen On 7/20/20 1:25 AM, Kim Barrett wrote: >> On Jul 20, 2020, at 12:47 AM, David Holmes wrote: >> >> Hi Coleen, >> >> On 18/07/2020 7:29 am, coleen.phillimore at oracle.com wrote: >>> I've corrected this change with Kim's and David's feedback, and retested with tier1-3. This is much better. >> Yes this is better. :) Thanks to Kim for clarifying the acquire/release issue. >> >> LGTM. >> >> Thanks, >> David > Looks good. > > From beurba at microsoft.com Mon Jul 20 13:31:41 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Mon, 20 Jul 2020 13:31:41 +0000 Subject: RFR(XS) 8248671: AArch64: Remove unused variables In-Reply-To: References: <1c652b56-2476-ede0-47f8-13c4e99639d0@oracle.com>, Message-ID: Hello Andrew and David, is this fine to push? If yes, I need a someone to do that for me as I'm not a committer. Thank you, -Bernhard ________________________________________ From: Bernhard Urban-Forster Sent: Monday, July 13, 2020 16:03 To: David Holmes; aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: RE: RFR(XS) 8248671: AArch64: Remove unused variables Thank you for your review Andrew and David. Here is the webrev based on https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2F&data=02%7C01%7Cbeurba%40microsoft.com%7Ce351ec469c9e4d3811b308d82735964b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302458392009746&sdata=0bdkk1qjXh0nVQWUOavsNQdqIS%2BHdpQASr5ib3ZsyWs%3D&reserved=0: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8248671_hg%2F&data=02%7C01%7Cbeurba%40microsoft.com%7Ce351ec469c9e4d3811b308d82735964b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302458392009746&sdata=O2FLNRWUQ8%2BWa%2Bh1uHvn3SQYTUe6bo3qeUYiPvZz%2FAg%3D&reserved=0 Thanks, -Bernhard > -----Original Message----- > From: David Holmes > Sent: Monday, July 13, 2020 6:08 AM > To: Bernhard Urban-Forster ; aarch64-port- > dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(XS) 8248671: AArch64: Remove unused variables > > Hi Bernhard, > > On 10/07/2020 7:08 am, Bernhard Urban-Forster wrote: > > Hello everyone, > > > > > > please review this change: > > > > JBS: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > > .openjdk.java.net%2Fbrowse%2FJDK- > 8248671&data=02%7C01%7Cbeurba%40m > > > icrosoft.com%7Cfa08ce93e8d44b4f38a708d826e296ed%7C72f988bf86f141af > 91ab > > > 2d7cd011db47%7C1%7C0%7C637302101922573034&sdata=Bv6Fsw104 > ZizId5EdC > > %2BTnV8DrJCJyQzVk9ht6rWjLMw%3D&reserved=0 > > Webrev: > > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open > > jdk.java.net%2F~burban%2F8248671_unused- > vars%2F&data=02%7C01%7Cbeu > > > rba%40microsoft.com%7Cfa08ce93e8d44b4f38a708d826e296ed%7C72f988bf > 86f14 > > > 1af91ab2d7cd011db47%7C1%7C0%7C637302101922573034&sdata=X7 > 7Ri2iWLkm > > %2FOSmdP9HyEWEwMA7rO%2BM6oKVRAg4zHGQ%3D&reserved=0 > > > > We found this issue while bringing up Windows+AArch64 support for > HotSpot. The Microsoft toolchain (MSVC) seems to be slightly more pedantic > than GCC. > > Looks good and trivial. > > But could I request that webrevs/patches for mainline be generated against the > mainline hg repository rather than the git mirror. > > Thanks, > David > > > > > Thanks, > > -Bernhard > > From patric.hedlin at oracle.com Mon Jul 20 14:03:24 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Mon, 20 Jul 2020 16:03:24 +0200 Subject: RFR(S): 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <91ddfdac-2ce4-637c-b68c-7e042d67483f@oracle.com> References: <3df3dab6-aa2f-bbbc-d231-6cda8f2a0ff7@oracle.com> <91ddfdac-2ce4-637c-b68c-7e042d67483f@oracle.com> Message-ID: <378b61b1-06a6-82ca-9c5f-eb76e024292f@oracle.com> Thanks for reviewing Tobias. /Patric On 2020-07-20 09:46, Tobias Hartmann wrote: > Hi Patric, > > looks good to me. > > Best regards, > Tobias > > On 07.07.20 13:00, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8248901 >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8248901/ >> >> >> Current definition(s) of is_simm() and friends are not robust over inputs. Both min and max values >> are undefined for width > 32 (and width < 0). >> No is_uimm() is currently provided (added). Several definitions are not used (cleanup). >> >> NOTE: Adding currently unused is_simm9() and is_uimm12(), required by JDK-8247766. >> >> >> Testing: hs-tier1-3 >> >> >> Best regards, >> Patric From coleen.phillimore at oracle.com Mon Jul 20 14:18:13 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 20 Jul 2020 10:18:13 -0400 Subject: RFR (T) 8249760: Unnecessary #include oopStorageSet Message-ID: Summary: remove #include in favor of #include universe.hpp where needed. Tested with tier1 Oracle target list, and shenandoah build. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249760.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8249760 Thanks, Coleen From harold.seigel at oracle.com Mon Jul 20 14:28:16 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 20 Jul 2020 10:28:16 -0400 Subject: RFR (T) 8249760: Unnecessary #include oopStorageSet In-Reply-To: References: Message-ID: Hi Coleen, This looks good and trivial. Thanks, Harold On 7/20/2020 10:18 AM, coleen.phillimore at oracle.com wrote: > Summary: remove #include in favor of #include universe.hpp where needed. > > Tested with tier1 Oracle target list, and shenandoah build. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249760.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8249760 > > Thanks, > Coleen From coleen.phillimore at oracle.com Mon Jul 20 14:43:01 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 20 Jul 2020 10:43:01 -0400 Subject: RFR (T) 8249760: Unnecessary #include oopStorageSet In-Reply-To: References: Message-ID: <693935c4-f2da-9002-cd62-00a0a3fb2161@oracle.com> Thanks, Harold! Coleen On 7/20/20 10:28 AM, Harold Seigel wrote: > Hi Coleen, > > This looks good and trivial. > > Thanks, Harold > > On 7/20/2020 10:18 AM, coleen.phillimore at oracle.com wrote: >> Summary: remove #include in favor of #include universe.hpp where needed. >> >> Tested with tier1 Oracle target list, and shenandoah build. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8249760.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8249760 >> >> Thanks, >> Coleen From thomas.schatzl at oracle.com Mon Jul 20 14:49:47 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 20 Jul 2020 16:49:47 +0200 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> Message-ID: <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> Forwarding to hotspot-dev where it belongs after wrongly sending to hotspot-gc-dev. -------- Forwarded Message -------- Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints Date: Mon, 20 Jul 2020 12:07:38 +0200 From: Thomas Schatzl To: hotspot-dev at openjdk.java.net Hi all, can I get some reviews to handle'ize some raw oops in the MonitorInfo class? (Afaiu only) in LiveFrameStream::monitors_to_object_array() we try to allocate an objArray with raw oops held in the MonitorInfo class that are passed in a GrowableArray. This allocation can lead to a garbage collection, with the usual random crashes. This change changes the raw oops in MonitorInfo to Handles, and adds a few HandleMarks along the way to make these handles go away asap. This issue has been introduced in JDK-8140450: Implement Stack-Walking API in jdk9. The CR has been triaged as P3, but I would like to ask whether it might be good to increase its priority to P2 and apply for inclusion in 15. My arguments are as follows: - the original issue why I started looking at this were lots of seemingly random crashes (5 or 6 were reported and the change temporarily backed out for this reason) in tier8 with a g1 change that changed young gen sizing. These crashes including that young gen sizing change are all gone now with this bugfix. I.e. this suggests that so far we seem to have not encountered this issue more frequently due to pure luck wrt to generation sizing. - it affects all collectors (naturally). - there are quite a few user reported random crashes with IntelliJ and variants, which due to the nature of IDEs tending to retrieve stack traces fairly frequently would be more affected than usual. So I suspect at least some of them to be caused by this issue, these are the only raw oops I am aware of. My understanding of the cause and fix is fairly good, but I am no expert in this area, so I would like to defer to you about this suggestion. The change is imo important enough to be backported to 11 and 15 anyway, but the question is about the risk/reward tradeoff wrt to bringing it to 15 and not 15.0.1. CR: https://bugs.openjdk.java.net/browse/JDK-8249192 Webrev: http://cr.openjdk.java.net/~tschatzl/8249192/webrev/ Testing: tier1-5,tier8 (with some unrelated changes), 1800+ runs of the reproducer Thanks, Thomas From daniel.daugherty at oracle.com Mon Jul 20 15:06:42 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 20 Jul 2020 11:06:42 -0400 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> Message-ID: Just addressing one item for now: > The CR has been triaged as P3, but I would like to ask whether it might > be good to increase its priority to P2... The ILW set during triage is this: > ILW = HLM = P3 The Work around portion is "M", but I'm not aware of any work around other than rolling the dice again. If there is no work around, then that changes the Work around portion to "H" which makes this a P2. Misha, please chime in on this thread about this rationale for changing the priority from P3 -> P2. Thanks, in advance. Dan On 7/20/20 10:49 AM, Thomas Schatzl wrote: > Forwarding to hotspot-dev where it belongs after wrongly sending to > hotspot-gc-dev. > > > -------- Forwarded Message -------- > Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across > safepoints > Date: Mon, 20 Jul 2020 12:07:38 +0200 > From: Thomas Schatzl > To: hotspot-dev at openjdk.java.net > > Hi all, > > ? can I get some reviews to handle'ize some raw oops in the > MonitorInfo class? > > (Afaiu only) in LiveFrameStream::monitors_to_object_array() we try to > allocate an objArray with raw oops held in the MonitorInfo class that > are passed in a GrowableArray. This allocation can lead to a garbage > collection, with the usual random crashes. > > This change changes the raw oops in MonitorInfo to Handles, and adds a > few HandleMarks along the way to make these handles go away asap. > > This issue has been introduced in JDK-8140450: Implement Stack-Walking > API in jdk9. > > The CR has been triaged as P3, but I would like to ask whether it > might be good to increase its priority to P2 and apply for inclusion > in 15. My arguments are as follows: > > - the original issue why I started looking at this were lots of > seemingly random crashes (5 or 6 were reported and the change > temporarily backed out for this reason) in tier8 with a g1 change that > changed young gen sizing. These crashes including that young gen > sizing change are all gone now with this bugfix. > I.e. this suggests that so far we seem to have not encountered this > issue more frequently due to pure luck wrt to generation sizing. > > - it affects all collectors (naturally). > > - there are quite a few user reported random crashes with IntelliJ and > variants, which due to the nature of IDEs tending to retrieve stack > traces fairly frequently would be more affected than usual. So I > suspect at least some of them to be caused by this issue, these are > the only raw oops I am aware of. > > My understanding of the cause and fix is fairly good, but I am no > expert in this area, so I would like to defer to you about this > suggestion. The change is imo important enough to be backported to 11 > and 15 anyway, but the question is about the risk/reward tradeoff wrt > to bringing it to 15 and not 15.0.1. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8249192 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8249192/webrev/ > Testing: > tier1-5,tier8 (with some unrelated changes), 1800+ runs of the reproducer > > Thanks, > ? Thomas > From coleen.phillimore at oracle.com Mon Jul 20 20:53:57 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 20 Jul 2020 16:53:57 -0400 Subject: RFR (M) 8249768: Move static oops and NullPointerException oops from Universe into OopStorage Message-ID: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> Summary: Move static oops into OopStorage and make NPE oops an objArrayOop. I've broken up moving oops in Universe to OopStorage into several parts.? This change moves the global static oops.? These OopHandles are not released. This has been tested with tier1-3 and on also remote-build -b linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249768.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8249768 Thanks, Coleen From coleen.phillimore at oracle.com Mon Jul 20 21:07:49 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 20 Jul 2020 17:07:49 -0400 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> Message-ID: <2803699b-c0c9-64d2-c800-96ca1de96839@oracle.com> Hi, Thank you for finding this.? It doesn't fail with -XX:+CheckUnhandledOops unfortunately, probably because the oops aren't accessed after stored to the LiveFrameInfo array. Some if this change is a bit disturbing.? MonitorInfo is a ResourceObj and not a StackObj so it's unclear that it's always going to be used in the scope of the current thread.? Passing the Thread argument in makes it less clear and the TRAPS argument by convention means that an exception could be thrown.? I would rather see the MonitorInfo constructor defined in vframe.inline.hpp and call Thread::current() in the constructor.? Technically, MonitorInfo is used as a StackObj so I think that this is ok to make the oops into Handles. The additional HandleMarks and ResourceMarks look ok. I think this should be fixed in JDK 15, given how difficult this problem was to diagnose and severity of the failure. Thanks, Coleen On 7/20/20 10:49 AM, Thomas Schatzl wrote: > Forwarding to hotspot-dev where it belongs after wrongly sending to > hotspot-gc-dev. > > > -------- Forwarded Message -------- > Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across > safepoints > Date: Mon, 20 Jul 2020 12:07:38 +0200 > From: Thomas Schatzl > To: hotspot-dev at openjdk.java.net > > Hi all, > > ? can I get some reviews to handle'ize some raw oops in the > MonitorInfo class? > > (Afaiu only) in LiveFrameStream::monitors_to_object_array() we try to > allocate an objArray with raw oops held in the MonitorInfo class that > are passed in a GrowableArray. This allocation can lead to a garbage > collection, with the usual random crashes. > > This change changes the raw oops in MonitorInfo to Handles, and adds a > few HandleMarks along the way to make these handles go away asap. > > This issue has been introduced in JDK-8140450: Implement Stack-Walking > API in jdk9. > > The CR has been triaged as P3, but I would like to ask whether it > might be good to increase its priority to P2 and apply for inclusion > in 15. My arguments are as follows: > > - the original issue why I started looking at this were lots of > seemingly random crashes (5 or 6 were reported and the change > temporarily backed out for this reason) in tier8 with a g1 change that > changed young gen sizing. These crashes including that young gen > sizing change are all gone now with this bugfix. > I.e. this suggests that so far we seem to have not encountered this > issue more frequently due to pure luck wrt to generation sizing. > > - it affects all collectors (naturally). > > - there are quite a few user reported random crashes with IntelliJ and > variants, which due to the nature of IDEs tending to retrieve stack > traces fairly frequently would be more affected than usual. So I > suspect at least some of them to be caused by this issue, these are > the only raw oops I am aware of. > > My understanding of the cause and fix is fairly good, but I am no > expert in this area, so I would like to defer to you about this > suggestion. The change is imo important enough to be backported to 11 > and 15 anyway, but the question is about the risk/reward tradeoff wrt > to bringing it to 15 and not 15.0.1. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8249192 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8249192/webrev/ > Testing: > tier1-5,tier8 (with some unrelated changes), 1800+ runs of the reproducer > > Thanks, > ? Thomas > From david.holmes at oracle.com Tue Jul 21 01:29:37 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jul 2020 11:29:37 +1000 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> Message-ID: <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> Hi Thomas, On 21/07/2020 12:49 am, Thomas Schatzl wrote: > Forwarding to hotspot-dev where it belongs after wrongly sending to > hotspot-gc-dev. This touches serviceability code as well so cc'ing for good measure. Thanks for taking this one on as it wasn't actually a GC issue! > > -------- Forwarded Message -------- > Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across > safepoints > Date: Mon, 20 Jul 2020 12:07:38 +0200 > From: Thomas Schatzl > To: hotspot-dev at openjdk.java.net > > Hi all, > > ? can I get some reviews to handle'ize some raw oops in the MonitorInfo > class? > > (Afaiu only) in LiveFrameStream::monitors_to_object_array() we try to > allocate an objArray with raw oops held in the MonitorInfo class that > are passed in a GrowableArray. This allocation can lead to a garbage > collection, with the usual random crashes. Right - seems so obvious now. Took me a while to convince myself no such similar problem was lurking in the JVM TI code. > This change changes the raw oops in MonitorInfo to Handles, My main concern here was whether the MonitorInfo objects are thread confined. For the StackWalker API we are always dealing with the current thread so that is fine. For JVM TI, in mainline, we may be executing code in the calling thread or the target thread; and in older releases it will be the VMThread at a safepoint. But it seems that the MonitorInfo's are confined to whichever thread that is, and so Handle usage is safe. > and adds a few HandleMarks along the way to make these handles go away asap. That, and the ResourceMark changes, were a bit hard to follow. Basically a HandleMark is now present in the scope of, or just above, the call to monitors(). The need for the additional ResourceMarks is far from clear though. In particular I wonder if the RM introduced in Deoptimization::revoke_from_deopt_handler interacts with the special DeoptResourceMark in its caller Deoptimization::fetch_unroll_info_helper? (I have no idea what a DeoptResourceMark is.) > > This issue has been introduced in JDK-8140450: Implement Stack-Walking > API in jdk9. > > The CR has been triaged as P3, but I would like to ask whether it might > be good to increase its priority to P2 and apply for inclusion in 15. My > arguments are as follows: > > - the original issue why I started looking at this were lots of > seemingly random crashes (5 or 6 were reported and the change > temporarily backed out for this reason) in tier8 with a g1 change that > changed young gen sizing. These crashes including that young gen sizing > change are all gone now with this bugfix. > I.e. this suggests that so far we seem to have not encountered this > issue more frequently due to pure luck wrt to generation sizing. > > - it affects all collectors (naturally). > > - there are quite a few user reported random crashes with IntelliJ and > variants, which due to the nature of IDEs tending to retrieve stack > traces fairly frequently would be more affected than usual. So I suspect > at least some of them to be caused by this issue, these are the only raw > oops I am aware of. > > My understanding of the cause and fix is fairly good, but I am no expert > in this area, so I would like to defer to you about this suggestion. The > change is imo important enough to be backported to 11 and 15 anyway, but > the question is about the risk/reward tradeoff wrt to bringing it to 15 > and not 15.0.1. I'd classify this as a P2 without doubt. As Dan noted there is no workaround as such. > CR: > https://bugs.openjdk.java.net/browse/JDK-8249192 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8249192/webrev/ src/hotspot/share/runtime/deoptimization.cpp The code in collect_monitors takes the monitor owner oop and Handelises it to add to its own GrowableArray of Handles. Is it worth exposing the MonitorInfo owner() in Handle form to avoid this unwrapping and re-wrapping? src/hotspot/share/runtime/vframe.hpp I agree with Coleen that the MonitorInfo constructor should not take a Thread* but should itself materialize and use Thread::current(). Thanks, David ----- > Testing: > tier1-5,tier8 (with some unrelated changes), 1800+ runs of the reproducer > > Thanks, > ? Thomas > From david.holmes at oracle.com Tue Jul 21 02:25:38 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jul 2020 12:25:38 +1000 Subject: RFR(XS) 8248671: AArch64: Remove unused variables In-Reply-To: References: <1c652b56-2476-ede0-47f8-13c4e99639d0@oracle.com> < Message-ID: <5f10db6e-9d5d-ddc4-549b-03344174e364@oracle.com> Hi Bernhard, On 20/07/2020 11:31 pm, Bernhard Urban-Forster wrote: > Hello Andrew and David, > > is this fine to push? If yes, I need a someone to do that for me as I'm not a committer. Can you generate the final changeset please, with proper commit message [1] so that whomever sponsors this can do a direct "hg import". Thanks, David [1] http://openjdk.java.net/guide/producingChangeset.html > > Thank you, > -Bernhard > > ________________________________________ > From: Bernhard Urban-Forster > Sent: Monday, July 13, 2020 16:03 > To: David Holmes; aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Cc: openjdk-aarch64 > Subject: RE: RFR(XS) 8248671: AArch64: Remove unused variables > > Thank you for your review Andrew and David. > > Here is the webrev based on https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2F&data=02%7C01%7Cbeurba%40microsoft.com%7Ce351ec469c9e4d3811b308d82735964b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302458392009746&sdata=0bdkk1qjXh0nVQWUOavsNQdqIS%2BHdpQASr5ib3ZsyWs%3D&reserved=0: > > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8248671_hg%2F&data=02%7C01%7Cbeurba%40microsoft.com%7Ce351ec469c9e4d3811b308d82735964b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302458392009746&sdata=O2FLNRWUQ8%2BWa%2Bh1uHvn3SQYTUe6bo3qeUYiPvZz%2FAg%3D&reserved=0 > > > Thanks, > -Bernhard > >> -----Original Message----- >> From: David Holmes >> Sent: Monday, July 13, 2020 6:08 AM >> To: Bernhard Urban-Forster ; aarch64-port- >> dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-compiler- >> dev at openjdk.java.net >> Subject: Re: RFR(XS) 8248671: AArch64: Remove unused variables >> >> Hi Bernhard, >> >> On 10/07/2020 7:08 am, Bernhard Urban-Forster wrote: >>> Hello everyone, >>> >>> >>> please review this change: >>> >>> JBS: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs >>> .openjdk.java.net%2Fbrowse%2FJDK- >> 8248671&data=02%7C01%7Cbeurba%40m >>> >> icrosoft.com%7Cfa08ce93e8d44b4f38a708d826e296ed%7C72f988bf86f141af >> 91ab >>> >> 2d7cd011db47%7C1%7C0%7C637302101922573034&sdata=Bv6Fsw104 >> ZizId5EdC >>> %2BTnV8DrJCJyQzVk9ht6rWjLMw%3D&reserved=0 >>> Webrev: >>> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open >>> jdk.java.net%2F~burban%2F8248671_unused- >> vars%2F&data=02%7C01%7Cbeu >>> >> rba%40microsoft.com%7Cfa08ce93e8d44b4f38a708d826e296ed%7C72f988bf >> 86f14 >>> >> 1af91ab2d7cd011db47%7C1%7C0%7C637302101922573034&sdata=X7 >> 7Ri2iWLkm >>> %2FOSmdP9HyEWEwMA7rO%2BM6oKVRAg4zHGQ%3D&reserved=0 >>> >>> We found this issue while bringing up Windows+AArch64 support for >> HotSpot. The Microsoft toolchain (MSVC) seems to be slightly more pedantic >> than GCC. >> >> Looks good and trivial. >> >> But could I request that webrevs/patches for mainline be generated against the >> mainline hg repository rather than the git mirror. >> >> Thanks, >> David >> >>> >>> Thanks, >>> -Bernhard >>> From david.holmes at oracle.com Tue Jul 21 02:47:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jul 2020 12:47:24 +1000 Subject: RFR (M) 8249768: Move static oops and NullPointerException oops from Universe into OopStorage In-Reply-To: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> References: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> Message-ID: Hi Coleen, cc'ing serviceability due to SA changes. On 21/07/2020 6:53 am, coleen.phillimore at oracle.com wrote: > Summary: Move static oops into OopStorage and make NPE oops an objArrayOop. > > I've broken up moving oops in Universe to OopStorage into several > parts.? This change moves the global static oops.? These OopHandles are > not released. Overall looks good. But two things ... 1. naming ! // preallocated error objects (no backtrace) ! static OopHandle _out_of_memory_error; // array of preallocated error objects with backtrace ! static OopHandle _preallocated_out_of_memory_error_array; Both of these are pre-allocated arrays of OopHandles, differing only in whether the underlying OOME has a backtrace or not. I find the newly introduced _out_of_memory_error unclear in that regard. At a minimum could _out_of_memory_error become _out_of_memory_errors ? But ideally can we name these two arrays in a more distinguishable way? 2. SA You've simply deleted all the SA/vmstructs code that referenced the oops that are no longer present. Does the SA not care about these things and need access to them? (I don't know hence cc to serviceability folk.) Thanks, David ----- > This has been tested with tier1-3 and on also remote-build -b > linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249768.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8249768 > > Thanks, > Coleen From erik.osterlund at oracle.com Tue Jul 21 10:48:34 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 21 Jul 2020 12:48:34 +0200 Subject: Scoping the stack allocation prototype for C2 In-Reply-To: References: Message-ID: <0f5b426e-d4a1-9973-c2cb-d020839cd32b@oracle.com> Hi Nikola and Charlie, On 2020-07-16 23:31, Nikola Grcevski wrote: > Hello hotspot-dev, > > We recently posted a proposal [1] to implement stack allocation in C2 on the hotspot-compiler dev mailing list. > Vladimir Ivanov [2] asked that we broaden the discussion by posting here as it is more than a compiler optimization! > That is, enabling object allocations on thread stacks will impact other JVM subsystems now and in future designs. It sounds like the high level goal is not "allocate on the stack", but rather allocate and free objects more efficiently based on compile-time knowledge about their scoped lifetime. Allocating them on the stack is one way of achieving that. The memory is allocated and reclaimed as part of the frame. However, this scheme ties inherently tightly to the GC implementations. Custom GC-specific code is required to have GC barriers that were annotated in the C2 access API as IN_HEAP, to dynamically check if in fact the object is !IN_HEAP. This also comes with GC-specific barrier elision code that pattern matches accesses on known to be stack objects, removing their barriers, which looks quite hairy. Such code makes it increasingly painful to maintain the barriers when they need to change. Other than being a bit ugly and painful to maintain, some GCs might have a harder time dealing with this than others. == G1 == For G1 it is okay, as there are some suitable slow paths you can inject the stack object check into, before card table lookups are performed. == ParallelGC and SerialGC == Parallel and Serial do not have such a slow path to add the check to, and a new filter would have to be written that makes every IN_HEAP object write slightly slower, checking if it is not IN_HEAP really. That might still be a net performance win, but is a performance tax paid that I would associate with the choice of placing these objects in the stack. == ZGC == The ZGC IN_HEAP load barriers need oops to not be "bad". All the information required for the check is in the pointer itself (that is loaded). Stack pointers are not bad, because they can't have the reserved bad bits in their pointers. Therefore, I think everything will magically work well with ZGC... today. But we are designing new things that change the barriers, and it isn't entirely clear to me what the new constraints would mean. == Shenandoah == The IN_HEAP load barriers of Shenandoah need to check that the loaded reference is not in the collection set. This is done with a table lookup, that only works for IN_HEAP references. I think you would have to add an additional check if it is a stack object here. It seems like adding such code to a load barrier could be quite nasty. > If the proposal moves forward the current webrev [3] would need to be reviewed by multiple groups. This is a > clear sign the wider OpenJDK community needs to provide input. An example of this proposal impacting future > work, is Project Loom. Allocating objects on the stack would have to be limited in some scenarios. The implementation > of stack allocated objects referencing other stack allocated objects would need to be changed *or* how Project Loom > handles copying stacks would have to be modified. Ron wants yielding to be very fast. Therefore, the common case does not walk the stack that is being copied to perform any per-frame processing at all. Instead, the raw stack is copied for the best possible throughput. A lot of time was spent optimizing stack walking with crazy tricks, but raw copy still turned out ~10x faster IIRC. So I think Ron would be a bit sad if the yield has to perform any per-frame processing to sort out the stack objects. > While all the various solutions for Project Loom would be a net win at the end, they all come with drawbacks and > possible losses in performance compared to our current measured performance improvements. These decisions > would need to be discussed at length to decide what was best for Hotspot and the OpenJDK community. I think moving the storage of the objects to some stack-like TLAB in the Java heap should be seriously considered, as proposed by Vladimir Ivanov and Vladimir Kozlov. It can similarly provide optimized object allocation and freeing, based on compile-time knowledge about the scoped lifetime of objects. I see the following advantages: * No new GC-specific dynamic barrier code to check if IN_HEAP accesses are in fact not IN_HEAP. * Likely no impact or small impact on any upcoming projects, as the scoped objects are still regular IN_HEAP objects. * In particular, Loom gets no significant extra processing. * Nothing weird about using compressed oops. * Larger allocations can be scoped still; no need to worry about stacks growing too much. * No need for object migrations or special handling during deopt or when using stack walking APIs. When this was raised as an alternative in compiler-dev, Charlie had concerns that the nmethod entry would need a few more instructions to do something similar to stack banging to ensure that the IN_HEAP local object stack is large enough for the nmethod (obviously only applicable for nmethods that have such local objects). Similarly, there would be an extra decrement when leaving the nmethod. This makes it sound like storing the objects in the stack would have a performance edge, because you can elide the need for an extra object stack bang check and decrement from the entry/exit. But I think it should be stressed that this is not a free lunch; you get that performance edge by injecting dynamic stack object checks into GC barriers, with varying impact for different GCs, depending on how impacted they are by the existence of stack objects. For e.g. ParallelGC, that would likely imply an extra check for every IN_HEAP object write. It really is not obvious that the once per nmethod invocation cost of the object stack checks actually outweights the overhead of more expensive GC barriers. Since I can see so many advantages with this approach, and not really any disadvantages if done right, I wonder if there are any clear reasons not to build it in that (general) way instead.I am curious to hear your thoughts about this. If you agree this is probably a better way of achieving the same thing, then I have some ideas how best to implement it that we could discuss. But maybe we should settle on the direction first instead.Perhaps there are some nice quirks with stack allocations that still make them more desirable, even though I can not currently see it. Thanks, /Erik > The benefits of allocating objects on the stack, based on our proposal [1], need to be weighed against the costs on > current and future features in components that will be impacted. These decisions will need to be discussed at length > to decide what was best for Hotspot and the OpenJDK community. > > We are optimistic that this work can provide benefits to the JVM without restricting future designs to heavily. > > We are looking forward to receiving all feedback on this proposal. > > Thanks! > Nikola and Charlie > > [1] https://github.com/microsoft/openjdk-proposals/blob/master/stack_allocation/Stack_Allocation_JEP.md > [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-July/038969.html > [3] https://cr.openjdk.java.net/~adityam/charlie/stack_alloc/ From coleen.phillimore at oracle.com Tue Jul 21 14:19:18 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Jul 2020 10:19:18 -0400 Subject: RFR (M) 8249768: Move static oops and NullPointerException oops from Universe into OopStorage In-Reply-To: References: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> Message-ID: On 7/20/20 10:47 PM, David Holmes wrote: > Hi Coleen, > > cc'ing serviceability due to SA changes. > > On 21/07/2020 6:53 am, coleen.phillimore at oracle.com wrote: >> Summary: Move static oops into OopStorage and make NPE oops an >> objArrayOop. >> >> I've broken up moving oops in Universe to OopStorage into several >> parts.? This change moves the global static oops.? These OopHandles >> are not released. > > Overall looks good. But two things ... > > 1. naming > > !?? // preallocated error objects (no backtrace) > !?? static OopHandle??? _out_of_memory_error; > > ??? // array of preallocated error objects with backtrace > !?? static OopHandle???? _preallocated_out_of_memory_error_array; > > Both of these are pre-allocated arrays of OopHandles, differing only > in whether the underlying OOME has a backtrace or not. I find the > newly introduced _out_of_memory_error unclear in that regard. At a > minimum could _out_of_memory_error become _out_of_memory_errors ? But > ideally can we name these two arrays in a more distinguishable way? I put this code in functions next to each other because it was confusing.? The _out_of_memory_error array is really preallocated throwables, that are used to fill in the message for preallocated_out_of_memory_errors if there are enough of the latter left. I could rename _out_of_memory_error => _out_of_memory_error_throwables? ? > > 2. SA > > You've simply deleted all the SA/vmstructs code that referenced the > oops that are no longer present. Does the SA not care about these > things and need access to them? (I don't know hence cc to > serviceability folk.) Yes, the SA code was never used, so I deleted it.? SA might need in oop inspection to add walking Universe::vm_global() OopStorage area to find where oops come from if there's an error but there doesn't seem to be any other reason for SA to use these oops. Thanks, Coleen > > Thanks, > David > ----- > >> This has been tested with tier1-3 and on also remote-build -b >> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8249768.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8249768 >> >> Thanks, >> Coleen From beurba at microsoft.com Tue Jul 21 14:38:53 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Tue, 21 Jul 2020 14:38:53 +0000 Subject: RFR(XS) 8248671: AArch64: Remove unused variables In-Reply-To: <5f10db6e-9d5d-ddc4-549b-03344174e364@oracle.com> References: <1c652b56-2476-ede0-47f8-13c4e99639d0@oracle.com> < , <5f10db6e-9d5d-ddc4-549b-03344174e364@oracle.com> Message-ID: Hello David, here is a webrev with a proper mercurial changeset included: http://cr.openjdk.java.net/~burban/8248671_hg_export/ Thank you, -Bernhard ________________________________________ From: David Holmes Sent: Tuesday, July 21, 2020 04:25 To: Bernhard Urban-Forster; aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: RFR(XS) 8248671: AArch64: Remove unused variables Hi Bernhard, On 20/07/2020 11:31 pm, Bernhard Urban-Forster wrote: > Hello Andrew and David, > > is this fine to push? If yes, I need a someone to do that for me as I'm not a committer. Can you generate the final changeset please, with proper commit message [1] so that whomever sponsors this can do a direct "hg import". Thanks, David [1] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fguide%2FproducingChangeset.html&data=02%7C01%7Cbeurba%40microsoft.com%7C5826e4957e42479469ed08d82d1db4d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308952896746440&sdata=XTQJoOJnM3arad15ytcodu4%2BnPRXnYcSSVJnRz35ekk%3D&reserved=0 > > Thank you, > -Bernhard > > ________________________________________ > From: Bernhard Urban-Forster > Sent: Monday, July 13, 2020 16:03 > To: David Holmes; aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Cc: openjdk-aarch64 > Subject: RE: RFR(XS) 8248671: AArch64: Remove unused variables > > Thank you for your review Andrew and David. > > Here is the webrev based on https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C5826e4957e42479469ed08d82d1db4d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308952896746440&sdata=Ul6pqOngjqozX%2FYpZXH3TbjIw9O27jouN47NTLhvHp4%3D&reserved=0: > > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8248671_hg%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C5826e4957e42479469ed08d82d1db4d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308952896746440&sdata=pa6O7bS78Q3hOowXCmAAbRY%2BI4H%2Bnk7V%2BErM9q%2BCYWc%3D&reserved=0 > > > Thanks, > -Bernhard > >> -----Original Message----- >> From: David Holmes >> Sent: Monday, July 13, 2020 6:08 AM >> To: Bernhard Urban-Forster ; aarch64-port- >> dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-compiler- >> dev at openjdk.java.net >> Subject: Re: RFR(XS) 8248671: AArch64: Remove unused variables >> >> Hi Bernhard, >> >> On 10/07/2020 7:08 am, Bernhard Urban-Forster wrote: >>> Hello everyone, >>> >>> >>> please review this change: >>> >>> JBS: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs >>> .openjdk.java.net%2Fbrowse%2FJDK- >> 8248671&data=02%7C01%7Cbeurba%40m >>> >> icrosoft.com%7Cfa08ce93e8d44b4f38a708d826e296ed%7C72f988bf86f141af >> 91ab >>> >> 2d7cd011db47%7C1%7C0%7C637302101922573034&sdata=Bv6Fsw104 >> ZizId5EdC >>> %2BTnV8DrJCJyQzVk9ht6rWjLMw%3D&reserved=0 >>> Webrev: >>> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open >>> jdk.java.net%2F~burban%2F8248671_unused- >> vars%2F&data=02%7C01%7Cbeu >>> >> rba%40microsoft.com%7Cfa08ce93e8d44b4f38a708d826e296ed%7C72f988bf >> 86f14 >>> >> 1af91ab2d7cd011db47%7C1%7C0%7C637302101922573034&sdata=X7 >> 7Ri2iWLkm >>> %2FOSmdP9HyEWEwMA7rO%2BM6oKVRAg4zHGQ%3D&reserved=0 >>> >>> We found this issue while bringing up Windows+AArch64 support for >> HotSpot. The Microsoft toolchain (MSVC) seems to be slightly more pedantic >> than GCC. >> >> Looks good and trivial. >> >> But could I request that webrevs/patches for mainline be generated against the >> mainline hg repository rather than the git mirror. >> >> Thanks, >> David >> >>> >>> Thanks, >>> -Bernhard >>> From thomas.schatzl at oracle.com Tue Jul 21 18:00:11 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 21 Jul 2020 20:00:11 +0200 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> Message-ID: Hi Coleen and David, thanks for your reviews. On 21.07.20 03:29, David Holmes wrote: > Hi Thomas, > > On 21/07/2020 12:49 am, Thomas Schatzl wrote: >> Forwarding to hotspot-dev where it belongs after wrongly sending to >> hotspot-gc-dev. > > This touches serviceability code as well so cc'ing for good measure. > > Thanks for taking this one on as it wasn't actually a GC issue! I have been looking into strange G1 crashes with changed young gen sizing in tier8, which looked very similar to the crashes in that StackWalker/LocalsAndOperands.java test (thanks to Dean Long making us aware of these crashes). I guessed correctly in hindsight, that the main difference between C2 and Graal would be GC timing, so the problem could be related. Also we have some P2s for 15 with the same stack trace as in this reproducer and the mentioned tier8 (Kitchensink, 24h dacapo) failures that never reproduced... given that the issue reproduced much quicker in LocalsAndOperands (and given its source code gives a pretty narrow area where to look) it seemed easier to start with this one... >> >> -------- Forwarded Message -------- >> Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across >> safepoints >> Date: Mon, 20 Jul 2020 12:07:38 +0200 >> From: Thomas Schatzl >> To: hotspot-dev at openjdk.java.net >> >> Hi all, >> >> ?? can I get some reviews to handle'ize some raw oops in the >> MonitorInfo class? >> >> (Afaiu only) in LiveFrameStream::monitors_to_object_array() we try to >> allocate an objArray with raw oops held in the MonitorInfo class that >> are passed in a GrowableArray. This allocation can lead to a garbage >> collection, with the usual random crashes. > > Right - seems so obvious now. > > Took me a while to convince myself no such similar problem was lurking > in the JVM TI code. > >> This change changes the raw oops in MonitorInfo to Handles, > > My main concern here was whether the MonitorInfo objects are thread > confined. For the StackWalker API we are always dealing with the current > thread so that is fine. For JVM TI, in mainline, we may be executing > code in the calling thread or the target thread; and in older releases > it will be the VMThread at a safepoint. But it seems that the > MonitorInfo's are confined to whichever thread that is, and so Handle > usage is safe. > >> and adds a few HandleMarks along the way to make these handles go away >> asap. > > That, and the ResourceMark changes, were a bit hard to follow. Basically > a HandleMark is now present in the scope of, or just above, the call to > monitors(). The need for the additional ResourceMarks is far from clear > though. In particular I wonder if the RM introduced in > Deoptimization::revoke_from_deopt_handler interacts with the special > DeoptResourceMark in its caller > Deoptimization::fetch_unroll_info_helper? (I have no idea what a > DeoptResourceMark is.) The DeoptResourceMark in this case seems to act just like a regular ResourceMark, using the thread's resource area. Other than acting like a ResourceMark, the DeoptResourceMark only seems to be an indicator used in some asserts to verify that no further deoptimization is running. Looking at the called BiasedLocking::revoke_own_lock(), it adds its own (regular) ResourceMark quite early (further indicating that normal ResourceMarks and DeoptResourceMarks should be "compatible"), meaning that only any resource object allocated in the resource area between the added ResourceMark in Deoptimization::revoke_from_deopt_handler() and the existing one in BiasedLocking::revoke_own_lock() would have a different lifetime than before. There is no resource object allocation in there, actually the only thing that happens is unpacking the contents of the passed handle. The objects_to_revoke array in Deoptimization::revoke_from_deopt_handler does not escape the method too. I was much more worried about the caching of a GrowableArray in Thread::cached_monitor_info going on during biased locking... > >> >> This issue has been introduced in JDK-8140450: Implement Stack-Walking >> API in jdk9. >> >> The CR has been triaged as P3, but I would like to ask whether it >> might be good to increase its priority to P2 and apply for inclusion >> in 15. My arguments are as follows: >> >> - the original issue why I started looking at this were lots of >> seemingly random crashes (5 or 6 were reported and the change >> temporarily backed out for this reason) in tier8 with a g1 change that >> changed young gen sizing. These crashes including that young gen >> sizing change are all gone now with this bugfix. >> I.e. this suggests that so far we seem to have not encountered this >> issue more frequently due to pure luck wrt to generation sizing. >> >> - it affects all collectors (naturally). >> >> - there are quite a few user reported random crashes with IntelliJ and >> variants, which due to the nature of IDEs tending to retrieve stack >> traces fairly frequently would be more affected than usual. So I >> suspect at least some of them to be caused by this issue, these are >> the only raw oops I am aware of. >> >> My understanding of the cause and fix is fairly good, but I am no >> expert in this area, so I would like to defer to you about this >> suggestion. The change is imo important enough to be backported to 11 >> and 15 anyway, but the question is about the risk/reward tradeoff wrt >> to bringing it to 15 and not 15.0.1. > > I'd classify this as a P2 without doubt. As Dan noted there is no > workaround as such. > >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8249192 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8249192/webrev/ > > src/hotspot/share/runtime/deoptimization.cpp > > The code in collect_monitors takes the monitor owner oop and Handelises > it to add to its own GrowableArray of Handles. Is it worth exposing the > MonitorInfo owner() in Handle form to avoid this unwrapping and > re-wrapping? We talked a bit about this internally and came to the conclusion to initially provide a small fix for 15 and 16, and do that suggested refactoring in 16 only. > > src/hotspot/share/runtime/vframe.hpp > > I agree with Coleen that the MonitorInfo constructor should not take a > Thread* but should itself materialize and use Thread::current(). Fixed. New webrevs (jdk16): http://cr.openjdk.java.net/~tschatzl/8249192/webrev.0_to_1/ (diff) http://cr.openjdk.java.net/~tschatzl/8249192/webrev.1/ (full) jdk15: http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.1/ The only difference is that JDK-8247729 in 16 changed a ResourceMark rm; in jdk15 (jvmtiEnvBase.cpp:1029) from ResourceMark rm(current_thread); in jdk16 (jvmtiEnvBase.cpp:1008) which gives a merge error now. See also https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 . Started another tier1-5 run for jdk15; both versions passed 1.2k iterations of the LocalsAndOperands.java test again. Thanks, Thomas From luhenry at microsoft.com Tue Jul 21 19:17:37 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Tue, 21 Jul 2020 19:17:37 +0000 Subject: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper Message-ID: Hello, Simple code cleanup to use existing ATTRIBUTE_ALIGNED macro in src/hotspot/cpu/aarch64. JBS: https://bugs.openjdk.java.net/browse/JDK-8248682 Webrev: http://cr.openjdk.java.net/~burban/luhenry/8248682/webrev.00 Testing: jtreg:test/hotspot/jtreg:tier1, jtreg:test/jdk:tier1, jtreg:test/jdk:tier2, jtreg:test/langtools, on Windows-AArch64 and Linux-AArch64. Thank you, -- Ludovic From david.holmes at oracle.com Wed Jul 22 00:42:36 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jul 2020 10:42:36 +1000 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> Message-ID: Hi Thomas, I've looked at the incremental update and I am happy with that. I also, prompted by you mentioning it, took a deeper look at the biased-locking code to ensure it also keeps the MonitorInfo's thread-confined, and to see whether the handshake versions could themselves be susceptible to interference from safepoints (which they can't as far as I can determine). And that all seems fine. As per offline discussions I know that there has been an alternate proposal for a completely localized fix in the stackwalker code that simply retrieves the list of monitors, uses the length to create the array, then re-retrieves the list of monitors to populate the array (the length of which can't change as we are dealing with the current thread). My only concern with that approach is the performance impact if we have deep stacks with lots of monitors. There is a microbenchmark for StackWalker in the repo: open/test/micro/org/openjdk/bench/java/lang/StackWalkBench.java but it doesn't test anything to do with monitor usage. Thanks, David ----- On 22/07/2020 4:00 am, Thomas Schatzl wrote: > Hi Coleen and David, > > ? thanks for your reviews. > > On 21.07.20 03:29, David Holmes wrote: >> Hi Thomas, >> >> On 21/07/2020 12:49 am, Thomas Schatzl wrote: >>> Forwarding to hotspot-dev where it belongs after wrongly sending to >>> hotspot-gc-dev. >> >> This touches serviceability code as well so cc'ing for good measure. >> >> Thanks for taking this one on as it wasn't actually a GC issue! > > I have been looking into strange G1 crashes with changed young gen > sizing in tier8, which looked very similar to the crashes in that > StackWalker/LocalsAndOperands.java test (thanks to Dean Long making us > aware of these crashes). > I guessed correctly in hindsight, that the main difference between C2 > and Graal would be GC timing, so the problem could be related. Also we > have some P2s for 15 with the same stack trace as in this reproducer and > the mentioned tier8 (Kitchensink, 24h dacapo) failures that never > reproduced... given that the issue reproduced much quicker in > LocalsAndOperands (and given its source code gives a pretty narrow area > where to look) it seemed easier to start with this one... > >>> >>> -------- Forwarded Message -------- >>> Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across >>> safepoints >>> Date: Mon, 20 Jul 2020 12:07:38 +0200 >>> From: Thomas Schatzl >>> To: hotspot-dev at openjdk.java.net >>> >>> Hi all, >>> >>> ?? can I get some reviews to handle'ize some raw oops in the >>> MonitorInfo class? >>> >>> (Afaiu only) in LiveFrameStream::monitors_to_object_array() we try to >>> allocate an objArray with raw oops held in the MonitorInfo class that >>> are passed in a GrowableArray. This allocation can lead to a garbage >>> collection, with the usual random crashes. >> >> Right - seems so obvious now. >> >> Took me a while to convince myself no such similar problem was lurking >> in the JVM TI code. >> >>> This change changes the raw oops in MonitorInfo to Handles, >> >> My main concern here was whether the MonitorInfo objects are thread >> confined. For the StackWalker API we are always dealing with the >> current thread so that is fine. For JVM TI, in mainline, we may be >> executing code in the calling thread or the target thread; and in >> older releases it will be the VMThread at a safepoint. But it seems >> that the MonitorInfo's are confined to whichever thread that is, and >> so Handle usage is safe. > > >> >>> and adds a few HandleMarks along the way to make these handles go >>> away asap. >> >> That, and the ResourceMark changes, were a bit hard to follow. >> Basically a HandleMark is now present in the scope of, or just above, >> the call to monitors(). The need for the additional ResourceMarks is >> far from clear though. In particular I wonder if the RM introduced in >> Deoptimization::revoke_from_deopt_handler interacts with the special >> DeoptResourceMark in its caller >> Deoptimization::fetch_unroll_info_helper? (I have no idea what a >> DeoptResourceMark is.) > > The DeoptResourceMark in this case seems to act just like a regular > ResourceMark, using the thread's resource area. > > Other than acting like a ResourceMark, the DeoptResourceMark only seems > to be an indicator used in some asserts to verify that no further > deoptimization is running. > > Looking at the called BiasedLocking::revoke_own_lock(), it adds its own > (regular) ResourceMark quite early (further indicating that normal > ResourceMarks and DeoptResourceMarks should be "compatible"), meaning > that only any resource object allocated in the resource area between the > added ResourceMark in Deoptimization::revoke_from_deopt_handler() and > the existing one in BiasedLocking::revoke_own_lock() would have a > different lifetime than before. There is no resource object allocation > in there, actually the only thing that happens is unpacking the contents > of the passed handle. > > The objects_to_revoke array in Deoptimization::revoke_from_deopt_handler > does not escape the method too. > > I was much more worried about the caching of a > GrowableArray in Thread::cached_monitor_info going on > during biased locking... > >> >>> >>> This issue has been introduced in JDK-8140450: Implement >>> Stack-Walking API in jdk9. >>> >>> The CR has been triaged as P3, but I would like to ask whether it >>> might be good to increase its priority to P2 and apply for inclusion >>> in 15. My arguments are as follows: >>> >>> - the original issue why I started looking at this were lots of >>> seemingly random crashes (5 or 6 were reported and the change >>> temporarily backed out for this reason) in tier8 with a g1 change >>> that changed young gen sizing. These crashes including that young gen >>> sizing change are all gone now with this bugfix. >>> I.e. this suggests that so far we seem to have not encountered this >>> issue more frequently due to pure luck wrt to generation sizing. >>> >>> - it affects all collectors (naturally). >>> >>> - there are quite a few user reported random crashes with IntelliJ >>> and variants, which due to the nature of IDEs tending to retrieve >>> stack traces fairly frequently would be more affected than usual. So >>> I suspect at least some of them to be caused by this issue, these are >>> the only raw oops I am aware of. >>> >>> My understanding of the cause and fix is fairly good, but I am no >>> expert in this area, so I would like to defer to you about this >>> suggestion. The change is imo important enough to be backported to 11 >>> and 15 anyway, but the question is about the risk/reward tradeoff wrt >>> to bringing it to 15 and not 15.0.1. >> >> I'd classify this as a P2 without doubt. As Dan noted there is no >> workaround as such. >> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8249192 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8249192/webrev/ >> >> src/hotspot/share/runtime/deoptimization.cpp >> >> The code in collect_monitors takes the monitor owner oop and >> Handelises it to add to its own GrowableArray of Handles. Is it worth >> exposing the MonitorInfo owner() in Handle form to avoid this >> unwrapping and re-wrapping? > > We talked a bit about this internally and came to the conclusion to > initially provide a small fix for 15 and 16, and do that suggested > refactoring in 16 only. > >> >> src/hotspot/share/runtime/vframe.hpp >> >> I agree with Coleen that the MonitorInfo constructor should not take a >> Thread* but should itself materialize and use Thread::current(). > > Fixed. > > New webrevs (jdk16): > > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.0_to_1/ (diff) > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.1/ (full) > > jdk15: > > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.1/ > > The only difference is that JDK-8247729 in 16 changed a > > ResourceMark rm; > > in jdk15 (jvmtiEnvBase.cpp:1029) from > > ResourceMark rm(current_thread); > > in jdk16 (jvmtiEnvBase.cpp:1008) > > which gives a merge error now. See also > https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 . > > Started another tier1-5 run for jdk15; both versions passed 1.2k > iterations of the LocalsAndOperands.java test again. > > Thanks, > ? Thomas From serguei.spitsyn at oracle.com Wed Jul 22 02:13:51 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jul 2020 19:13:51 -0700 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> Message-ID: <893f862f-093a-5168-e554-1f4ffe129aea@oracle.com> Hi Thomas, The fix looks okay to me. The 15 fix is identical to 16. This file finally was not changed: src/hotspot/share/runtime/vframe_hp.cpp . Several files need a copyright comment update. What tests do you run? We need at least tier3 to make sure there are no regressions in the JVMTI and JDI tests. Thanks, Serguei On 7/21/20 11:00, Thomas Schatzl wrote: > Hi Coleen and David, > > ? thanks for your reviews. > > On 21.07.20 03:29, David Holmes wrote: >> Hi Thomas, >> >> On 21/07/2020 12:49 am, Thomas Schatzl wrote: >>> Forwarding to hotspot-dev where it belongs after wrongly sending to >>> hotspot-gc-dev. >> >> This touches serviceability code as well so cc'ing for good measure. >> >> Thanks for taking this one on as it wasn't actually a GC issue! > > I have been looking into strange G1 crashes with changed young gen > sizing in tier8, which looked very similar to the crashes in that > StackWalker/LocalsAndOperands.java test (thanks to Dean Long making us > aware of these crashes). > I guessed correctly in hindsight, that the main difference between C2 > and Graal would be GC timing, so the problem could be related. Also we > have some P2s for 15 with the same stack trace as in this reproducer > and the mentioned tier8 (Kitchensink, 24h dacapo) failures that never > reproduced... given that the issue reproduced much quicker in > LocalsAndOperands (and given its source code gives a pretty narrow > area where to look) it seemed easier to start with this one... > >>> >>> -------- Forwarded Message -------- >>> Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across >>> safepoints >>> Date: Mon, 20 Jul 2020 12:07:38 +0200 >>> From: Thomas Schatzl >>> To: hotspot-dev at openjdk.java.net >>> >>> Hi all, >>> >>> ?? can I get some reviews to handle'ize some raw oops in the >>> MonitorInfo class? >>> >>> (Afaiu only) in LiveFrameStream::monitors_to_object_array() we try >>> to allocate an objArray with raw oops held in the MonitorInfo class >>> that are passed in a GrowableArray. This allocation can lead to a >>> garbage collection, with the usual random crashes. >> >> Right - seems so obvious now. >> >> Took me a while to convince myself no such similar problem was >> lurking in the JVM TI code. >> >>> This change changes the raw oops in MonitorInfo to Handles, >> >> My main concern here was whether the MonitorInfo objects are thread >> confined. For the StackWalker API we are always dealing with the >> current thread so that is fine. For JVM TI, in mainline, we may be >> executing code in the calling thread or the target thread; and in >> older releases it will be the VMThread at a safepoint. But it seems >> that the MonitorInfo's are confined to whichever thread that is, and >> so Handle usage is safe. > > >> >>> and adds a few HandleMarks along the way to make these handles go >>> away asap. >> >> That, and the ResourceMark changes, were a bit hard to follow. >> Basically a HandleMark is now present in the scope of, or just above, >> the call to monitors(). The need for the additional ResourceMarks is >> far from clear though. In particular I wonder if the RM introduced in >> Deoptimization::revoke_from_deopt_handler interacts with the special >> DeoptResourceMark in its caller >> Deoptimization::fetch_unroll_info_helper? (I have no idea what a >> DeoptResourceMark is.) > > The DeoptResourceMark in this case seems to act just like a regular > ResourceMark, using the thread's resource area. > > Other than acting like a ResourceMark, the DeoptResourceMark only > seems to be an indicator used in some asserts to verify that no > further deoptimization is running. > > Looking at the called BiasedLocking::revoke_own_lock(), it adds its > own (regular) ResourceMark quite early (further indicating that normal > ResourceMarks and DeoptResourceMarks should be "compatible"), meaning > that only any resource object allocated in the resource area between > the added ResourceMark in Deoptimization::revoke_from_deopt_handler() > and the existing one in BiasedLocking::revoke_own_lock() would have a > different lifetime than before. There is no resource object allocation > in there, actually the only thing that happens is unpacking the > contents of the passed handle. > > The objects_to_revoke array in > Deoptimization::revoke_from_deopt_handler does not escape the method too. > > I was much more worried about the caching of a > GrowableArray in Thread::cached_monitor_info going on > during biased locking... > >> >>> >>> This issue has been introduced in JDK-8140450: Implement >>> Stack-Walking API in jdk9. >>> >>> The CR has been triaged as P3, but I would like to ask whether it >>> might be good to increase its priority to P2 and apply for inclusion >>> in 15. My arguments are as follows: >>> >>> - the original issue why I started looking at this were lots of >>> seemingly random crashes (5 or 6 were reported and the change >>> temporarily backed out for this reason) in tier8 with a g1 change >>> that changed young gen sizing. These crashes including that young >>> gen sizing change are all gone now with this bugfix. >>> I.e. this suggests that so far we seem to have not encountered this >>> issue more frequently due to pure luck wrt to generation sizing. >>> >>> - it affects all collectors (naturally). >>> >>> - there are quite a few user reported random crashes with IntelliJ >>> and variants, which due to the nature of IDEs tending to retrieve >>> stack traces fairly frequently would be more affected than usual. So >>> I suspect at least some of them to be caused by this issue, these >>> are the only raw oops I am aware of. >>> >>> My understanding of the cause and fix is fairly good, but I am no >>> expert in this area, so I would like to defer to you about this >>> suggestion. The change is imo important enough to be backported to >>> 11 and 15 anyway, but the question is about the risk/reward tradeoff >>> wrt to bringing it to 15 and not 15.0.1. >> >> I'd classify this as a P2 without doubt. As Dan noted there is no >> workaround as such. >> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8249192 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8249192/webrev/ >> >> src/hotspot/share/runtime/deoptimization.cpp >> >> The code in collect_monitors takes the monitor owner oop and >> Handelises it to add to its own GrowableArray of Handles. Is it worth >> exposing the MonitorInfo owner() in Handle form to avoid this >> unwrapping and re-wrapping? > > We talked a bit about this internally and came to the conclusion to > initially provide a small fix for 15 and 16, and do that suggested > refactoring in 16 only. > >> >> src/hotspot/share/runtime/vframe.hpp >> >> I agree with Coleen that the MonitorInfo constructor should not take >> a Thread* but should itself materialize and use Thread::current(). > > Fixed. > > New webrevs (jdk16): > > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.0_to_1/ (diff) > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.1/ (full) > > jdk15: > > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.1/ > > The only difference is that JDK-8247729 in 16 changed a > > ResourceMark rm; > > in jdk15 (jvmtiEnvBase.cpp:1029) from > > ResourceMark rm(current_thread); > > in jdk16 (jvmtiEnvBase.cpp:1008) > > which gives a merge error now. See also > https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 . > > Started another tier1-5 run for jdk15; both versions passed 1.2k > iterations of the LocalsAndOperands.java test again. > > Thanks, > ? Thomas From david.holmes at oracle.com Wed Jul 22 04:04:08 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jul 2020 14:04:08 +1000 Subject: RFR(XS) 8248671: AArch64: Remove unused variables In-Reply-To: References: <1c652b56-2476-ede0-47f8-13c4e99639d0@oracle.com> < <5f10db6e-9d5d-ddc4-549b-03344174e364@oracle.com> Message-ID: On 22/07/2020 12:38 am, Bernhard Urban-Forster wrote: > Hello David, > > here is a webrev with a proper mercurial changeset included: http://cr.openjdk.java.net/~burban/8248671_hg_export/ Pushed. Thanks, David ----- > Thank you, > -Bernhard > > ________________________________________ > From: David Holmes > Sent: Tuesday, July 21, 2020 04:25 > To: Bernhard Urban-Forster; aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Cc: openjdk-aarch64 > Subject: Re: RFR(XS) 8248671: AArch64: Remove unused variables > > Hi Bernhard, > > On 20/07/2020 11:31 pm, Bernhard Urban-Forster wrote: >> Hello Andrew and David, >> >> is this fine to push? If yes, I need a someone to do that for me as I'm not a committer. > > Can you generate the final changeset please, with proper commit message > [1] so that whomever sponsors this can do a direct "hg import". > > Thanks, > David > > [1] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fguide%2FproducingChangeset.html&data=02%7C01%7Cbeurba%40microsoft.com%7C5826e4957e42479469ed08d82d1db4d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308952896746440&sdata=XTQJoOJnM3arad15ytcodu4%2BnPRXnYcSSVJnRz35ekk%3D&reserved=0 > >> >> Thank you, >> -Bernhard >> >> ________________________________________ >> From: Bernhard Urban-Forster >> Sent: Monday, July 13, 2020 16:03 >> To: David Holmes; aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net >> Cc: openjdk-aarch64 >> Subject: RE: RFR(XS) 8248671: AArch64: Remove unused variables >> >> Thank you for your review Andrew and David. >> >> Here is the webrev based on https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C5826e4957e42479469ed08d82d1db4d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308952896746440&sdata=Ul6pqOngjqozX%2FYpZXH3TbjIw9O27jouN47NTLhvHp4%3D&reserved=0: >> >> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8248671_hg%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C5826e4957e42479469ed08d82d1db4d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308952896746440&sdata=pa6O7bS78Q3hOowXCmAAbRY%2BI4H%2Bnk7V%2BErM9q%2BCYWc%3D&reserved=0 >> >> >> Thanks, >> -Bernhard >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Monday, July 13, 2020 6:08 AM >>> To: Bernhard Urban-Forster ; aarch64-port- >>> dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-compiler- >>> dev at openjdk.java.net >>> Subject: Re: RFR(XS) 8248671: AArch64: Remove unused variables >>> >>> Hi Bernhard, >>> >>> On 10/07/2020 7:08 am, Bernhard Urban-Forster wrote: >>>> Hello everyone, >>>> >>>> >>>> please review this change: >>>> >>>> JBS: >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs >>>> .openjdk.java.net%2Fbrowse%2FJDK- >>> 8248671&data=02%7C01%7Cbeurba%40m >>>> >>> icrosoft.com%7Cfa08ce93e8d44b4f38a708d826e296ed%7C72f988bf86f141af >>> 91ab >>>> >>> 2d7cd011db47%7C1%7C0%7C637302101922573034&sdata=Bv6Fsw104 >>> ZizId5EdC >>>> %2BTnV8DrJCJyQzVk9ht6rWjLMw%3D&reserved=0 >>>> Webrev: >>>> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open >>>> jdk.java.net%2F~burban%2F8248671_unused- >>> vars%2F&data=02%7C01%7Cbeu >>>> >>> rba%40microsoft.com%7Cfa08ce93e8d44b4f38a708d826e296ed%7C72f988bf >>> 86f14 >>>> >>> 1af91ab2d7cd011db47%7C1%7C0%7C637302101922573034&sdata=X7 >>> 7Ri2iWLkm >>>> %2FOSmdP9HyEWEwMA7rO%2BM6oKVRAg4zHGQ%3D&reserved=0 >>>> >>>> We found this issue while bringing up Windows+AArch64 support for >>> HotSpot. The Microsoft toolchain (MSVC) seems to be slightly more pedantic >>> than GCC. >>> >>> Looks good and trivial. >>> >>> But could I request that webrevs/patches for mainline be generated against the >>> mainline hg repository rather than the git mirror. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> -Bernhard >>>> From david.holmes at oracle.com Wed Jul 22 04:32:11 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jul 2020 14:32:11 +1000 Subject: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper In-Reply-To: References: Message-ID: Hi Ludovic, On 22/07/2020 5:17 am, Ludovic Henry wrote: > Hello, > > Simple code cleanup to use existing ATTRIBUTE_ALIGNED macro in src/hotspot/cpu/aarch64. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248682 > Webrev: http://cr.openjdk.java.net/~burban/luhenry/8248682/webrev.00 That seems fine. Thanks, David ----- > Testing: jtreg:test/hotspot/jtreg:tier1, jtreg:test/jdk:tier1, jtreg:test/jdk:tier2, jtreg:test/langtools, on Windows-AArch64 and Linux-AArch64. > > Thank you, > > -- > Ludovic > From david.holmes at oracle.com Wed Jul 22 06:32:13 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jul 2020 16:32:13 +1000 Subject: RFR (M) 8249768: Move static oops and NullPointerException oops from Universe into OopStorage In-Reply-To: References: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> Message-ID: Hi Coleen, On 22/07/2020 12:19 am, coleen.phillimore at oracle.com wrote: > > > On 7/20/20 10:47 PM, David Holmes wrote: >> Hi Coleen, >> >> cc'ing serviceability due to SA changes. >> >> On 21/07/2020 6:53 am, coleen.phillimore at oracle.com wrote: >>> Summary: Move static oops into OopStorage and make NPE oops an >>> objArrayOop. >>> >>> I've broken up moving oops in Universe to OopStorage into several >>> parts.? This change moves the global static oops.? These OopHandles >>> are not released. >> >> Overall looks good. But two things ... >> >> 1. naming >> >> !?? // preallocated error objects (no backtrace) >> !?? static OopHandle??? _out_of_memory_error; >> >> ??? // array of preallocated error objects with backtrace >> !?? static OopHandle???? _preallocated_out_of_memory_error_array; >> >> Both of these are pre-allocated arrays of OopHandles, differing only >> in whether the underlying OOME has a backtrace or not. I find the >> newly introduced _out_of_memory_error unclear in that regard. At a >> minimum could _out_of_memory_error become _out_of_memory_errors ? But >> ideally can we name these two arrays in a more distinguishable way? > > I put this code in functions next to each other because it was > confusing.? The _out_of_memory_error array is really preallocated > throwables, that are used to fill in the message for > preallocated_out_of_memory_errors if there are enough of the latter left. > I could rename _out_of_memory_error => _out_of_memory_error_throwables ? That doesn't really help. As I said both of these variables are arrays of pre-allocated OOME instances (which are throwables) - the only difference is one set is single-use (as it can have its backtrace set) while the other is reusable. The existing variable _preallocated_out_of_memory_error_array tells you clearly it is an array of preallocated OOME instances (but doesn't saying anything about the backtrace or being single-use). The problem is that that is exactly what _out_of_memory_error is as well, but the name _out_of_memory_error doesn't convey that it is an array, nor that anything is pre-allocated (and also nothing about backtraces or re-usability). So given we now have two arrays of extremely similar things, it would be clearer to give these clearer names. If we want to keep the existing _preallocated_out_of_memory_error_array name, then the new array should indicate how it differs e.g. _reusable_preallocated_out_of_memory_error_array What do you think? I also spotted a minor nit: 187 oop Universe::system_thread_group() { return _system_thread_group.resolve(); } 188 void Universe::set_system_thread_group(oop group) { _system_thread_group = OopHandle(vm_global(), group); } Extra spaces after oop on L187. Thanks, David ----- >> >> 2. SA >> >> You've simply deleted all the SA/vmstructs code that referenced the >> oops that are no longer present. Does the SA not care about these >> things and need access to them? (I don't know hence cc to >> serviceability folk.) > > Yes, the SA code was never used, so I deleted it.? SA might need in oop > inspection to add walking Universe::vm_global() OopStorage area to find > where oops come from if there's an error but there doesn't seem to be > any other reason for SA to use these oops. > > Thanks, > Coleen > >> >> Thanks, >> David >> ----- >> >>> This has been tested with tier1-3 and on also remote-build -b >>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8249768.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8249768 >>> >>> Thanks, >>> Coleen > From thomas.schatzl at oracle.com Wed Jul 22 08:14:42 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 22 Jul 2020 10:14:42 +0200 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <893f862f-093a-5168-e554-1f4ffe129aea@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> <893f862f-093a-5168-e554-1f4ffe129aea@oracle.com> Message-ID: <07904b7e-8d40-8c9e-acc1-c713c1588b11@oracle.com> Hi Serguei, thanks for your review. On 22.07.20 04:13, serguei.spitsyn at oracle.com wrote: > Hi Thomas, > > The fix looks okay to me. > The 15 fix is identical to 16. no :) It is very subtle. As mentioned, in jvmtiEnvBase.cpp in the original code, in jdk15 we had: line 1029: ResourceMark rm; in jdk16: line 1008: ResourceMark rm(current_thread); Both lines were ultimately removed with this recent change, but still cause merge errors if you port the patch from one version to the other. Sorry if that has been confusing. > > This file finally was not changed: > src/hotspot/share/runtime/vframe_hp.cpp . This is an artifact of webrev in conjunction with mq because the original change had some modifications which were retracted in the -1 webrev there. There will not be any change in any push for that file. > Several files need a copyright comment update. Provided new webrevs with only comment updates below. Did not do new testing just for these comment updates though. > > What tests do you run? > We need at least tier3 to make sure there are no regressions in the > JVMTI and JDI tests. The jdk15 .1 patch has been tested with 1.2k of that LocalsAndOperands test with the options that originally reproduced it in 1/100 cases. hs-tier1-5, no failures at all. jdk16 has had testing with the .0 patch doing 1.8k of LocalsAndOperands.java, tier1-5, and tier8 with JDK-8249676 reinstated that earlier caused lots of issues there (and none without). Since there has been no substantial change in how the patch works, only some refactoring, so I think these are still valid. See the internal comments in the CR for links. New webrevs: jdk15: http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2/ (full) http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.1_to_2/ (diff) jdk16: http://cr.openjdk.java.net/~tschatzl/8249192/webrev.2/ (full) http://cr.openjdk.java.net/~tschatzl/8249192/webrev.1_to_2/ (diff) Thanks, Thomas From thomas.schatzl at oracle.com Wed Jul 22 08:21:46 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 22 Jul 2020 10:21:46 +0200 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> Message-ID: <5c33af91-446a-89ba-1a99-30c79cf2f1d9@oracle.com> Hi, On 22.07.20 02:42, David Holmes wrote: > Hi Thomas, > > I've looked at the incremental update and I am happy with that. In the response to Serguei's review there were some comment updates and new webrevs. > > I also, prompted by you mentioning it, took a deeper look at the > biased-locking code to ensure it also keeps the MonitorInfo's > thread-confined, and to see whether the handshake versions could > themselves be susceptible to interference from safepoints (which they > can't as far as I can determine). And that all seems fine. Thanks for looking at this again in more detail. I couldn't spot problems either, but this is not code I am proficient with. > As per offline discussions I know that there has been an alternate > proposal for a completely localized fix in the stackwalker code that > simply retrieves the list of monitors, uses the length to create the > array, then re-retrieves the list of monitors to populate the array (the > length of which can't change as we are dealing with the current thread). > My only concern with that approach is the performance impact if we have > deep stacks with lots of monitors. There is a microbenchmark for > StackWalker in the repo: > > open/test/micro/org/openjdk/bench/java/lang/StackWalkBench.java > > but it doesn't test anything to do with monitor usage. Ultimately I am good with either change, as long as it's being fixed. I initially thought about this solution too, but had the same concerns. Stacks can be really deep particularly with some frameworks (maybe not fully materialized) but idk the actual impact of doing the walk twice. Potentially you could have different fixes for different versions. Thanks, Thomas From beurba at microsoft.com Wed Jul 22 09:28:23 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Wed, 22 Jul 2020 09:28:23 +0000 Subject: RFR(XS) 8248666: AArch64: Use THREAD_LOCAL instead of __thread Message-ID: Hi all, a trivial code cleanup to use an existing macro in the AArch64 backend. JBS: https://bugs.openjdk.java.net/browse/JDK-8248666 Webrev: http://cr.openjdk.java.net/~burban/8248666/ Thank you, -Bernhard From coleen.phillimore at oracle.com Wed Jul 22 11:50:50 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Jul 2020 07:50:50 -0400 Subject: RFR (M) 8249768: Move static oops and NullPointerException oops from Universe into OopStorage In-Reply-To: References: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> Message-ID: <16751a08-b686-9d4d-8a51-05db656b1249@oracle.com> On 7/22/20 2:32 AM, David Holmes wrote: > Hi Coleen, > > On 22/07/2020 12:19 am, coleen.phillimore at oracle.com wrote: >> >> >> On 7/20/20 10:47 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> cc'ing serviceability due to SA changes. >>> >>> On 21/07/2020 6:53 am, coleen.phillimore at oracle.com wrote: >>>> Summary: Move static oops into OopStorage and make NPE oops an >>>> objArrayOop. >>>> >>>> I've broken up moving oops in Universe to OopStorage into several >>>> parts.? This change moves the global static oops. These OopHandles >>>> are not released. >>> >>> Overall looks good. But two things ... >>> >>> 1. naming >>> >>> !?? // preallocated error objects (no backtrace) >>> !?? static OopHandle??? _out_of_memory_error; >>> >>> ??? // array of preallocated error objects with backtrace >>> !?? static OopHandle _preallocated_out_of_memory_error_array; >>> >>> Both of these are pre-allocated arrays of OopHandles, differing only >>> in whether the underlying OOME has a backtrace or not. I find the >>> newly introduced _out_of_memory_error unclear in that regard. At a >>> minimum could _out_of_memory_error become _out_of_memory_errors ? >>> But ideally can we name these two arrays in a more distinguishable way? >> >> I put this code in functions next to each other because it was >> confusing.? The _out_of_memory_error array is really preallocated >> throwables, that are used to fill in the message for >> preallocated_out_of_memory_errors if there are enough of the latter >> left. >> I could rename _out_of_memory_error => >> _out_of_memory_error_throwables? ? > > That doesn't really help. As I said both of these variables are arrays > of pre-allocated OOME instances (which are throwables) - the only > difference is one set is single-use (as it can have its backtrace set) > while the other is reusable. The existing variable > > _preallocated_out_of_memory_error_array > > tells you clearly it is an array of preallocated OOME instances (but > doesn't saying anything about the backtrace or being single-use). The > problem is that that is exactly what _out_of_memory_error is as well, > but the name _out_of_memory_error doesn't convey that it is an array, > nor that anything is pre-allocated (and also nothing about backtraces > or re-usability). So given we now have two arrays of extremely similar > things, it would be clearer to give these clearer names. If we want to > keep the existing > > _preallocated_out_of_memory_error_array > > name, then the new array should indicate how it differs e.g. > > _reusable_preallocated_out_of_memory_error_array > What do you think? This confuses me more than the code does.? Which array is this? This is a terrible name for whichever one it is (I guess the original _out_of_memory_error).? I don't think it's interesting to have the name _array in it, but being plural does tell you what it is, like _out_of_memory_errors.? The implementation is a bit weird and some long name isn't going to help anyone.? The abstraction that this is _out_of_memory_errors is all anyone outside this implementation needs to know. > > I also spotted a minor nit: > > ?187 oop????? Universe::system_thread_group()????????? { return > _system_thread_group.resolve(); } > ?188 void Universe::set_system_thread_group(oop group) { > _system_thread_group = OopHandle(vm_global(), group); } > > Extra spaces after oop on L187. Ok I'll fix the spacing. Thanks, Coleen > > Thanks, > David > ----- > >>> >>> 2. SA >>> >>> You've simply deleted all the SA/vmstructs code that referenced the >>> oops that are no longer present. Does the SA not care about these >>> things and need access to them? (I don't know hence cc to >>> serviceability folk.) >> >> Yes, the SA code was never used, so I deleted it.? SA might need in >> oop inspection to add walking Universe::vm_global() OopStorage area >> to find where oops come from if there's an error but there doesn't >> seem to be any other reason for SA to use these oops. >> >> Thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> This has been tested with tier1-3 and on also remote-build -b >>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8249768.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8249768 >>>> >>>> Thanks, >>>> Coleen >> From coleen.phillimore at oracle.com Wed Jul 22 12:11:47 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Jul 2020 08:11:47 -0400 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <5c33af91-446a-89ba-1a99-30c79cf2f1d9@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> <5c33af91-446a-89ba-1a99-30c79cf2f1d9@oracle.com> Message-ID: <22541ed5-f9c1-7a71-0a9a-8e66a00b6c96@oracle.com> On 7/22/20 4:21 AM, Thomas Schatzl wrote: > Hi, > > On 22.07.20 02:42, David Holmes wrote: >> Hi Thomas, >> >> I've looked at the incremental update and I am happy with that. > > In the response to Serguei's review there were some comment updates > and new webrevs. > >> >> I also, prompted by you mentioning it, took a deeper look at the >> biased-locking code to ensure it also keeps the MonitorInfo's >> thread-confined, and to see whether the handshake versions could >> themselves be susceptible to interference from safepoints (which they >> can't as far as I can determine). And that all seems fine. > > Thanks for looking at this again in more detail. I couldn't spot > problems either, but this is not code I am proficient with. > >> As per offline discussions I know that there has been an alternate >> proposal for a completely localized fix in the stackwalker code that >> simply retrieves the list of monitors, uses the length to create the >> array, then re-retrieves the list of monitors to populate the array >> (the length of which can't change as we are dealing with the current >> thread). My only concern with that approach is the performance impact >> if we have deep stacks with lots of monitors. There is a >> microbenchmark for StackWalker in the repo: >> >> open/test/micro/org/openjdk/bench/java/lang/StackWalkBench.java >> >> but it doesn't test anything to do with monitor usage. > > Ultimately I am good with either change, as long as it's being fixed. > I initially thought about this solution too, but had the same > concerns. Stacks can be really deep particularly with some frameworks > (maybe not fully materialized) but idk the actual impact of doing the > walk twice. > > Potentially you could have different fixes for different versions. Yes.? These patches look good to me for JDK 15 and 16.? We'll open an RFE to consider the alternate patch after more performance testing for future versions, but this fixes the problem and will not be difficult to backport to JDK 11. Thank you! Coleen > > Thanks, > ? Thomas From david.holmes at oracle.com Wed Jul 22 12:31:40 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jul 2020 22:31:40 +1000 Subject: RFR(XS) 8248666: AArch64: Use THREAD_LOCAL instead of __thread In-Reply-To: References: Message-ID: <41e2b25a-9393-9cef-ac02-0a7273a7fc39@oracle.com> Looks good to me. Thanks, David On 22/07/2020 7:28 pm, Bernhard Urban-Forster wrote: > Hi all, > > a trivial code cleanup to use an existing macro in the AArch64 backend. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248666 > Webrev: http://cr.openjdk.java.net/~burban/8248666/ > > > Thank you, > -Bernhard > From david.holmes at oracle.com Wed Jul 22 12:42:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jul 2020 22:42:29 +1000 Subject: RFR (M) 8249768: Move static oops and NullPointerException oops from Universe into OopStorage In-Reply-To: <16751a08-b686-9d4d-8a51-05db656b1249@oracle.com> References: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> <16751a08-b686-9d4d-8a51-05db656b1249@oracle.com> Message-ID: On 22/07/2020 9:50 pm, coleen.phillimore at oracle.com wrote: > On 7/22/20 2:32 AM, David Holmes wrote: >> Hi Coleen, >> >> On 22/07/2020 12:19 am, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 7/20/20 10:47 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> cc'ing serviceability due to SA changes. >>>> >>>> On 21/07/2020 6:53 am, coleen.phillimore at oracle.com wrote: >>>>> Summary: Move static oops into OopStorage and make NPE oops an >>>>> objArrayOop. >>>>> >>>>> I've broken up moving oops in Universe to OopStorage into several >>>>> parts.? This change moves the global static oops. These OopHandles >>>>> are not released. >>>> >>>> Overall looks good. But two things ... >>>> >>>> 1. naming >>>> >>>> !?? // preallocated error objects (no backtrace) >>>> !?? static OopHandle??? _out_of_memory_error; >>>> >>>> ??? // array of preallocated error objects with backtrace >>>> !?? static OopHandle _preallocated_out_of_memory_error_array; >>>> >>>> Both of these are pre-allocated arrays of OopHandles, differing only >>>> in whether the underlying OOME has a backtrace or not. I find the >>>> newly introduced _out_of_memory_error unclear in that regard. At a >>>> minimum could _out_of_memory_error become _out_of_memory_errors ? >>>> But ideally can we name these two arrays in a more distinguishable way? >>> >>> I put this code in functions next to each other because it was >>> confusing.? The _out_of_memory_error array is really preallocated >>> throwables, that are used to fill in the message for >>> preallocated_out_of_memory_errors if there are enough of the latter >>> left. >>> I could rename _out_of_memory_error => >>> _out_of_memory_error_throwables? ? >> >> That doesn't really help. As I said both of these variables are arrays >> of pre-allocated OOME instances (which are throwables) - the only >> difference is one set is single-use (as it can have its backtrace set) >> while the other is reusable. The existing variable >> >> _preallocated_out_of_memory_error_array >> >> tells you clearly it is an array of preallocated OOME instances (but >> doesn't saying anything about the backtrace or being single-use). The >> problem is that that is exactly what _out_of_memory_error is as well, >> but the name _out_of_memory_error doesn't convey that it is an array, >> nor that anything is pre-allocated (and also nothing about backtraces >> or re-usability). So given we now have two arrays of extremely similar >> things, it would be clearer to give these clearer names. If we want to >> keep the existing >> >> _preallocated_out_of_memory_error_array >> >> name, then the new array should indicate how it differs e.g. >> >> _reusable_preallocated_out_of_memory_error_array >> What do you think? > > This confuses me more than the code does.? Which array is this? This is > a terrible name for whichever one it is (I guess the original > _out_of_memory_error).? I don't think it's interesting to have the name > _array in it, but being plural does tell you what it is, like > _out_of_memory_errors. Yes at least being plural is essential to realize it is actually an array. >? The implementation is a bit weird and some long > name isn't going to help anyone.? The abstraction that this is > _out_of_memory_errors is all anyone outside this implementation needs to > know. My point, which is obviously not getting across, is that you now have two arrays of these out-of-memory-errors that are almost identical, except one is used for one purpose and one used for another, but the variable names don't give you any clue about this. But lets' just add the 's' and move on. :) Cheers, David ----- >> >> I also spotted a minor nit: >> >> ?187 oop????? Universe::system_thread_group()????????? { return >> _system_thread_group.resolve(); } >> ?188 void Universe::set_system_thread_group(oop group) { >> _system_thread_group = OopHandle(vm_global(), group); } >> >> Extra spaces after oop on L187. > > Ok I'll fix the spacing. > Thanks, > Coleen >> >> Thanks, >> David >> ----- >> >>>> >>>> 2. SA >>>> >>>> You've simply deleted all the SA/vmstructs code that referenced the >>>> oops that are no longer present. Does the SA not care about these >>>> things and need access to them? (I don't know hence cc to >>>> serviceability folk.) >>> >>> Yes, the SA code was never used, so I deleted it.? SA might need in >>> oop inspection to add walking Universe::vm_global() OopStorage area >>> to find where oops come from if there's an error but there doesn't >>> seem to be any other reason for SA to use these oops. >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> This has been tested with tier1-3 and on also remote-build -b >>>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8249768.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8249768 >>>>> >>>>> Thanks, >>>>> Coleen >>> > From erik.osterlund at oracle.com Wed Jul 22 12:44:07 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 22 Jul 2020 14:44:07 +0200 Subject: RFR (M) 8249768: Move static oops and NullPointerException oops from Universe into OopStorage In-Reply-To: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> References: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> Message-ID: Hi Coleen, This looks good to me. It's still a bit shady to me that assignment of OopHandles overwrites the oop*, potentially causing memory leaks (the previous oop* is not released). Therefore, it is implied that setters are only used once, to store a new handle over an uninitialized handle. But we can fix the safety of this in another patch. Thanks, /Erik On 2020-07-20 22:53, coleen.phillimore at oracle.com wrote: > Summary: Move static oops into OopStorage and make NPE oops an > objArrayOop. > > I've broken up moving oops in Universe to OopStorage into several > parts.? This change moves the global static oops.? These OopHandles > are not released. > > This has been tested with tier1-3 and on also remote-build -b > linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249768.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8249768 > > Thanks, > Coleen From beurba at microsoft.com Wed Jul 22 13:06:56 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Wed, 22 Jul 2020 13:06:56 +0000 Subject: RFR(XS) 8248666: AArch64: Use THREAD_LOCAL instead of __thread In-Reply-To: <41e2b25a-9393-9cef-ac02-0a7273a7fc39@oracle.com> References: , <41e2b25a-9393-9cef-ac02-0a7273a7fc39@oracle.com> Message-ID: Thank you for the review David. I have updated the "Reviewed-by: " line in the commit message accordingly. Thanks, -Bernhard ________________________________________ From: David Holmes Sent: Wednesday, July 22, 2020 14:31 To: Bernhard Urban-Forster; hotspot-dev Source Developers; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: RFR(XS) 8248666: AArch64: Use THREAD_LOCAL instead of __thread Looks good to me. Thanks, David On 22/07/2020 7:28 pm, Bernhard Urban-Forster wrote: > Hi all, > > a trivial code cleanup to use an existing macro in the AArch64 backend. > > JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248666&data=02%7C01%7Cbeurba%40microsoft.com%7C3619bc11c2fe472c8ae508d82e3b3ba7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637310179223842396&sdata=Yi3n710V9VuSNNInQQsWUu8GJG0Er2k1a4pGVSwSJt4%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8248666%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C3619bc11c2fe472c8ae508d82e3b3ba7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637310179223842396&sdata=qpbIVYGHZo%2BWw1T9Cy7XIvbj137bAAnYgV7V91xqv0E%3D&reserved=0 > > > Thank you, > -Bernhard > From coleen.phillimore at oracle.com Wed Jul 22 13:13:41 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Jul 2020 09:13:41 -0400 Subject: RFR (M) 8249768: Move static oops and NullPointerException oops from Universe into OopStorage In-Reply-To: References: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> <16751a08-b686-9d4d-8a51-05db656b1249@oracle.com> Message-ID: <939f3762-758c-7af1-1edb-d33b89e2fa9e@oracle.com> On 7/22/20 8:42 AM, David Holmes wrote: > On 22/07/2020 9:50 pm, coleen.phillimore at oracle.com wrote: >> On 7/22/20 2:32 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 22/07/2020 12:19 am, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 7/20/20 10:47 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> cc'ing serviceability due to SA changes. >>>>> >>>>> On 21/07/2020 6:53 am, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Move static oops into OopStorage and make NPE oops an >>>>>> objArrayOop. >>>>>> >>>>>> I've broken up moving oops in Universe to OopStorage into several >>>>>> parts.? This change moves the global static oops. These >>>>>> OopHandles are not released. >>>>> >>>>> Overall looks good. But two things ... >>>>> >>>>> 1. naming >>>>> >>>>> !?? // preallocated error objects (no backtrace) >>>>> !?? static OopHandle??? _out_of_memory_error; >>>>> >>>>> ??? // array of preallocated error objects with backtrace >>>>> !?? static OopHandle _preallocated_out_of_memory_error_array; >>>>> >>>>> Both of these are pre-allocated arrays of OopHandles, differing >>>>> only in whether the underlying OOME has a backtrace or not. I find >>>>> the newly introduced _out_of_memory_error unclear in that regard. >>>>> At a minimum could _out_of_memory_error become >>>>> _out_of_memory_errors ? But ideally can we name these two arrays >>>>> in a more distinguishable way? >>>> >>>> I put this code in functions next to each other because it was >>>> confusing.? The _out_of_memory_error array is really preallocated >>>> throwables, that are used to fill in the message for >>>> preallocated_out_of_memory_errors if there are enough of the latter >>>> left. >>>> I could rename _out_of_memory_error => >>>> _out_of_memory_error_throwables? ? >>> >>> That doesn't really help. As I said both of these variables are >>> arrays of pre-allocated OOME instances (which are throwables) - the >>> only difference is one set is single-use (as it can have its >>> backtrace set) while the other is reusable. The existing variable >>> >>> _preallocated_out_of_memory_error_array >>> >>> tells you clearly it is an array of preallocated OOME instances (but >>> doesn't saying anything about the backtrace or being single-use). >>> The problem is that that is exactly what _out_of_memory_error is as >>> well, but the name _out_of_memory_error doesn't convey that it is an >>> array, nor that anything is pre-allocated (and also nothing about >>> backtraces or re-usability). So given we now have two arrays of >>> extremely similar things, it would be clearer to give these clearer >>> names. If we want to keep the existing >>> >>> _preallocated_out_of_memory_error_array >>> >>> name, then the new array should indicate how it differs e.g. >>> >>> _reusable_preallocated_out_of_memory_error_array >>> What do you think? >> >> This confuses me more than the code does.? Which array is this? This >> is a terrible name for whichever one it is (I guess the original >> _out_of_memory_error).? I don't think it's interesting to have the >> name _array in it, but being plural does tell you what it is, like >> _out_of_memory_errors. > > Yes at least being plural is essential to realize it is actually an > array. > >> ? The implementation is a bit weird and some long name isn't going to >> help anyone.? The abstraction that this is _out_of_memory_errors is >> all anyone outside this implementation needs to know. > > My point, which is obviously not getting across, is that you now have > two arrays of these out-of-memory-errors that are almost identical, > except one is used for one purpose and one used for another, but the > variable names don't give you any clue about this. I actually understand this, but the suggested names don't help.? You really need to look at the code and the comments in universe.hpp to see the distinction. I don't think we can provide more illumination with long names.? Since I moved the functions next to each other, it makes more sense when one reads it. > > But lets' just add the 's' and move on. :) Thanks,? I added the 's' and fixed the formatting.? Thank you for reviewing this. Coleen > > Cheers, > David > ----- > >>> >>> I also spotted a minor nit: >>> >>> ?187 oop????? Universe::system_thread_group()????????? { return >>> _system_thread_group.resolve(); } >>> ?188 void Universe::set_system_thread_group(oop group) { >>> _system_thread_group = OopHandle(vm_global(), group); } >>> >>> Extra spaces after oop on L187. >> >> Ok I'll fix the spacing. >> Thanks, >> Coleen >>> >>> Thanks, >>> David >>> ----- >>> >>>>> >>>>> 2. SA >>>>> >>>>> You've simply deleted all the SA/vmstructs code that referenced >>>>> the oops that are no longer present. Does the SA not care about >>>>> these things and need access to them? (I don't know hence cc to >>>>> serviceability folk.) >>>> >>>> Yes, the SA code was never used, so I deleted it.? SA might need in >>>> oop inspection to add walking Universe::vm_global() OopStorage area >>>> to find where oops come from if there's an error but there doesn't >>>> seem to be any other reason for SA to use these oops. >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> This has been tested with tier1-3 and on also remote-build -b >>>>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2020/8249768.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8249768 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> From coleen.phillimore at oracle.com Wed Jul 22 13:16:16 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Jul 2020 09:16:16 -0400 Subject: RFR (M) 8249768: Move static oops and NullPointerException oops from Universe into OopStorage In-Reply-To: References: <9fb1860f-06cf-9347-27d7-16205c86c326@oracle.com> Message-ID: <4c59962c-1315-28c0-4763-43bd0b78ce97@oracle.com> On 7/22/20 8:44 AM, Erik ?sterlund wrote: > Hi Coleen, > > This looks good to me. It's still a bit shady to me that assignment of > OopHandles overwrites the oop*, potentially causing memory leaks (the > previous oop* is not released). > Therefore, it is implied that setters are only used once, to store a > new handle over an uninitialized handle. But we can fix the safety of > this in another patch. Thank you, Erik, and thank you for suggesting an assert in the assignment operator.? These assignments do not hit that assert but there were others that did, so I have a separate patch that I'm working on.? See https://bugs.openjdk.java.net/browse/JDK-8249822 Thank you for reviewing this. Coleen > > Thanks, > /Erik > > On 2020-07-20 22:53, coleen.phillimore at oracle.com wrote: >> Summary: Move static oops into OopStorage and make NPE oops an >> objArrayOop. >> >> I've broken up moving oops in Universe to OopStorage into several >> parts.? This change moves the global static oops.? These OopHandles >> are not released. >> >> This has been tested with tier1-3 and on also remote-build -b >> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8249768.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8249768 >> >> Thanks, >> Coleen > From daniel.daugherty at oracle.com Wed Jul 22 14:25:42 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Jul 2020 10:25:42 -0400 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <22541ed5-f9c1-7a71-0a9a-8e66a00b6c96@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> <5c33af91-446a-89ba-1a99-30c79cf2f1d9@oracle.com> <22541ed5-f9c1-7a71-0a9a-8e66a00b6c96@oracle.com> Message-ID: On 7/22/20 8:11 AM, coleen.phillimore at oracle.com wrote: > > > On 7/22/20 4:21 AM, Thomas Schatzl wrote: >> Hi, >> >> On 22.07.20 02:42, David Holmes wrote: >>> Hi Thomas, >>> >>> I've looked at the incremental update and I am happy with that. >> >> In the response to Serguei's review there were some comment updates >> and new webrevs. >> >>> >>> I also, prompted by you mentioning it, took a deeper look at the >>> biased-locking code to ensure it also keeps the MonitorInfo's >>> thread-confined, and to see whether the handshake versions could >>> themselves be susceptible to interference from safepoints (which >>> they can't as far as I can determine). And that all seems fine. >> >> Thanks for looking at this again in more detail. I couldn't spot >> problems either, but this is not code I am proficient with. >> >>> As per offline discussions I know that there has been an alternate >>> proposal for a completely localized fix in the stackwalker code that >>> simply retrieves the list of monitors, uses the length to create the >>> array, then re-retrieves the list of monitors to populate the array >>> (the length of which can't change as we are dealing with the current >>> thread). My only concern with that approach is the performance >>> impact if we have deep stacks with lots of monitors. There is a >>> microbenchmark for StackWalker in the repo: >>> >>> open/test/micro/org/openjdk/bench/java/lang/StackWalkBench.java >>> >>> but it doesn't test anything to do with monitor usage. >> >> Ultimately I am good with either change, as long as it's being fixed. >> I initially thought about this solution too, but had the same >> concerns. Stacks can be really deep particularly with some frameworks >> (maybe not fully materialized) but idk the actual impact of doing the >> walk twice. >> >> Potentially you could have different fixes for different versions. > > Yes.? These patches look good to me for JDK 15 and 16.? We'll open an > RFE to consider the alternate patch after more performance testing for > future versions, but this fixes the problem and will not be difficult > to backport to JDK 11. Coleen, So it looks like you, David and Serguei are comfortable with the larger patch for both JDK15 and JDK16. That's good news! It's also good news that you think this not be difficult to backport to JDK11. For a post RDP2 push to JDK15, the bug's "Fix in Release" value will have to be changed to 15 and a request for approval made. I've attached Mark R's email about the process. Follow the links and submit the approval requests. As for the alternate fix, I only came up with it as a lower risk alternative that could be pushed this late in the JDK15 cycle and would be easy to push to JDK11u-oracle. Right now it appears that we won't need it, but just in case we get push back on JDK15 approval, I'll finish the due diligence testing. Thomas, thanks for tackling this issue and for your patience in the review process. Also, thanks for the GC debugging patch! Dan > > Thank you! > Coleen >> >> Thanks, >> ? Thomas > -------------- next part -------------- An embedded message was scrubbed... From: mark.reinhold at oracle.com Subject: JDK 15 is now in Rampdown Phase Two Date: Thu, 16 Jul 2020 09:14:15 -0700 (PDT) Size: 4521 URL: From daniel.daugherty at oracle.com Wed Jul 22 17:04:30 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Jul 2020 13:04:30 -0400 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <07904b7e-8d40-8c9e-acc1-c713c1588b11@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> <893f862f-093a-5168-e554-1f4ffe129aea@oracle.com> <07904b7e-8d40-8c9e-acc1-c713c1588b11@oracle.com> Message-ID: > jdk15: > > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2/ (full) src/hotspot/share/prims/jvmtiEnvBase.cpp ??? old L1029: ????? ResourceMark rm; ??????? It's not clear (to me anyway) why this ResourceMark is removed. ??????? Update: I saw the discussion of "ResourceMark rm" in JDK15 versus ??????? "ResourceMark rm(current_thread)" in JDK16, but that doesn't tell ??????? me why it was necessary to remove that ResourceMark. src/hotspot/share/prims/stackwalk.cpp ??? L291: ??? ResourceMark rm; ??? L292: ??? HandleMark hm; ??????? Since there's a TRAPS parameter, these should be 'rm(THREAD)' and ??????? 'hm(THREAD)'. src/hotspot/share/runtime/biasedLocking.cpp ??? No comments. src/hotspot/share/runtime/deoptimization.cpp ??? No comments. src/hotspot/share/runtime/vframe.cpp ??? L461: ? _lock? = lock; ??????? nit - extra space before '='. src/hotspot/share/runtime/vframe.hpp ??? L32: #include "runtime/handles.inline.hpp" ??????? nit - new include is out of order; should be after frame.hpp. src/hotspot/share/runtime/vframeArray.cpp ??? No comments. src/hotspot/share/runtime/vframe_hp.cpp ??? Skipped - no changes. src/hotspot/share/services/threadService.cpp ??? No comments. > jdk16: > > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.2/ (full) Same comments as for the JDK15 version. I also compared the two patches using jfilemerge. Most of what I have above are nits so I'm good with both of these patches. I also looked for lifetime issues with the new ResourceMarks and HandleMarks, but I don't see any issues. Dan On 7/22/20 4:14 AM, Thomas Schatzl wrote: > Hi Serguei, > > ? thanks for your review. > > On 22.07.20 04:13, serguei.spitsyn at oracle.com wrote: >> Hi Thomas, >> >> The fix looks okay to me. >> The 15 fix is identical to 16. > > ? no :) It is very subtle. As mentioned, in jvmtiEnvBase.cpp in the > original code, in jdk15 we had: > > line 1029:?????? ResourceMark rm; > > in jdk16: > > line 1008:?????? ResourceMark rm(current_thread); > > Both lines were ultimately removed with this recent change, but still > cause merge errors if you port the patch from one version to the other. > Sorry if that has been confusing. > >> >> This file finally was not changed: >> src/hotspot/share/runtime/vframe_hp.cpp . > > This is an artifact of webrev in conjunction with mq because the > original change had some modifications which were retracted in the -1 > webrev there. There will not be any change in any push for that file. > >> Several files need a copyright comment update. > > Provided new webrevs with only comment updates below. Did not do new > testing just for these comment updates though. > >> >> What tests do you run? >> We need at least tier3 to make sure there are no regressions in the >> JVMTI and JDI tests. > > The jdk15 .1 patch has been tested with 1.2k of that LocalsAndOperands > test with the options that originally reproduced it in 1/100 cases. > > hs-tier1-5, no failures at all. > > jdk16 has had testing with the .0 patch doing 1.8k of > LocalsAndOperands.java, tier1-5, and tier8 with JDK-8249676 reinstated > that earlier caused lots of issues there (and none without). > Since there has been no substantial change in how the patch works, > only some refactoring, so I think these are still valid. > > See the internal comments in the CR for links. > > New webrevs: > > jdk15: > > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2/ (full) > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.1_to_2/ (diff) > > jdk16: > > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.2/ (full) > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.1_to_2/ (diff) > > Thanks, > ? Thomas From coleen.phillimore at oracle.com Wed Jul 22 20:55:30 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Jul 2020 16:55:30 -0400 Subject: RFR (S) 8249822: SymbolPropertyTable creates an extra OopHandle per entry Message-ID: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> Summary: Add an assert to OopHandle assigment operator to catch leaking OopHandles, and fix code accordingly. There are some jvmtiRedefineClasses.cpp changes here - basically, I moved the RedefineVerifyMark and comments into jvmtiRedefineClasses.cpp because I needed a Handle. Ran tier1-6 tests and tier1 on all Oracle platforms. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249822.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8249822 Thanks, Coleen From vladimir.x.ivanov at oracle.com Wed Jul 22 21:36:52 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 23 Jul 2020 00:36:52 +0300 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com> <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com> Message-ID: <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com> > http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ FTR there's one more aarch64-specific change in shared code to enable aarch64_neon.ad processing: diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk b/make/hotspot/gensrc/GensrcAdlc.gmk --- a/make/hotspot/gensrc/GensrcAdlc.gmk +++ b/make/hotspot/gensrc/GensrcAdlc.gmk @@ -129,6 +129,12 @@ $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad \ ))) + ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64) + AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, $(AD_SRC_ROOTS), \ + $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \ + ))) + endif + ifeq ($(call check-jvm-feature, shenandoahgc), true) AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, $(AD_SRC_ROOTS), \ $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad \ Best regards, Vladimir Ivanov > On 7/8/20 3:05 PM, Yang Zhang wrote: >> Hi Andrew >> >> I have updated this patch. Could you please help to review it again? >> In this patch, the following changes are made: >> 1. Separate newly added NEON instructions to a new ad file >> ??? aarch64_neon.ad >> 2. Add assembler tests for NEON instructions. Trailing spaces >> ??? in the python script are also removed. >> >> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ >> >> >> Thanks, >> Yang >> >> >> -----Original Message----- >> From: Andrew Haley >> Sent: Tuesday, June 30, 2020 12:10 AM >> To: Yang Zhang ; Viswanathan, Sandhya >> ; Paul Sandoz >> Cc: nd ; hotspot-compiler-dev at openjdk.java.net; >> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; >> aarch64-port-dev at openjdk.java.net >> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of >> Vector API (Incubator): AArch64 backend changes >> >> On 29/06/2020 08:48, Yang Zhang wrote: >>> 1. Instructions that can be matched with NEON instructions directly. >>> MulVB, SqrtVF and AbsV have been merged into jdk master already. >>> >>> 2. Instructions that jdk master has middle end support for, but they >>> cannot be matched with NEON instructions directly. >>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These >>> new instructions can be moved into jdk master first, but for >>> auto-vectorization, the performance might not get improved. >>> >>> 3. Panama/Vector API specific? instructions such as Load/StoreVector >>> ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend >>> etc. >>> These instructions cannot be moved into jdk master first because >>> there isn't middle-end support. >>> >>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also >>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is >>> ready, I will send it again. >> >> Thank you *very* much for your hard work. Appreciated! >> >> -- >> Andrew Haley? (he/him) >> Java Platform Lead Engineer >> Red Hat UK Ltd. https://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> > From kim.barrett at oracle.com Wed Jul 22 21:54:29 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 22 Jul 2020 17:54:29 -0400 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> Message-ID: <03A2E317-DE27-4E27-AB49-BA8DA6D143FA@oracle.com> > On Jul 11, 2020, at 10:56 AM, Kim Barrett wrote: > >> On Jun 23, 2020, at 3:32 PM, Kim Barrett wrote: >> >> Please review / comment on this proposed update to the HotSpot Style >> Guide. This is part of the work for JDK-8208089: JEP 347: Adopt C++14 >> Language Features in the JDK. >> >> [?] Once >> reviewed, the finished text can be used to update the wiki, unless we >> decide it should be homed somewhere else. > > There has recently been a lot of discussion about where this and > somewhat similar documents should reside. Most of that has been about > a Java Style Guide, which has somewhat different issues than this one. > (The HotSpot Style Guide is very focused in scope, and is unlikely to > have much, if any, influence on usage by the wider C++ community.) > > Proposed homes include: > > - Remain in the OpenJDK wiki. > - Use an informational JEP. > - Move to the new Developer's Guide. > - Move to the JDK repository. > > For some of the discussion, see comments in JDK-8208089, as well as > the recent thread on the jdk-dev mailing list: > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004443.html > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004461.html > > Based on that discussion, I'm planning to move it to the JDK > repository, in jdk/jdk/doc. That is already a place for > developer-focused documentation; it's the home of building.{md,html}, > testing.{md,html}, and ide.{md,html}. I think this style guide fits > well with that collection. > > I think the other two wiki pages associated with the current wiki > HotSpot Style Guide would similarly fit well there, and I suggest we > move them as well. > > Comments? I made a few formatting tweaks to account for using the approved markdown processor (pandoc, via make update-build-docs); I'd been using a different processor, and noticed some problems with the generated html when I switched to using pandoc. I've also moved the files to jdk/jdk/doc. Reducing the heading "depths" made pandoc generate a nice TOC at the beginning. I removed the "===" separators, because pandoc wasn't producing a horizontal line separator for them, unlike the previous (extended) processor. There were some naked URLs that needed to be surrounded by <> to be autolinked by pandoc, unlike the previous (extended) processor. New webrev: full: https://cr.openjdk.java.net/~kbarrett/8247976/hotspot-style.03/ incr: https://cr.openjdk.java.net/~kbarrett/8247976/hotspot-style.03.inc/ The diffs for the incremental .html aren't particularly interesting, since different markdown processors were used to generate them. I'm intending to leave the move of the other two related wiki pages to later. Hopefully this is the last of this round of edits, though I'm expecting there will soon be a number of requests for further changes from this "baseline". From david.holmes at oracle.com Wed Jul 22 23:26:01 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jul 2020 09:26:01 +1000 Subject: Fwd: jdk/submit maintenance, July 23rd - July 27th In-Reply-To: <8754038A-93DA-40AC-9AAA-5AEBA5A59A1D@ORACLE.COM> References: <8754038A-93DA-40AC-9AAA-5AEBA5A59A1D@ORACLE.COM> Message-ID: <70d10304-2341-54fe-49f5-532811476e4c@oracle.com> Just in case people don't see the jdk-dev email. David ----- -------- Forwarded Message -------- Subject: jdk/submit maintenance, July 23rd - July 27th Date: Wed, 22 Jul 2020 15:26:30 -0400 From: Stanislav Smirnov To: jdk-dev Hello, A planned maintenance will happen this week, July 23rd - 27th. jdk/submit builds will not be available starting tomorrow (Thursday 23rd) at 10am PT / 17:00 GMT. The system should be back online by 10am PT / 17:00 GMT, July 27th. Best regards, Stanislav Smirnov From serguei.spitsyn at oracle.com Thu Jul 23 00:53:49 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jul 2020 17:53:49 -0700 Subject: RFR (S) 8249822: SymbolPropertyTable creates an extra OopHandle per entry In-Reply-To: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> References: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> Message-ID: Hi Coleen, The fix looks good to me. On 7/22/20 13:55, coleen.phillimore at oracle.com wrote: > Summary: Add an assert to OopHandle assigment operator to catch > leaking OopHandles, and fix code accordingly. > > There are some jvmtiRedefineClasses.cpp changes here - basically, I > moved the RedefineVerifyMark and comments into > jvmtiRedefineClasses.cpp because I needed a Handle. I think, the jvmtiRedefineClasses.cpp is a better place for the RedefineVerifyMark. But could you, please, explain a little bit more why this move was necessary? Why Handle can not be used in the jvmtiThreadState.cpp? Thanks, Serguei > Ran tier1-6 tests and tier1 on all Oracle platforms. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249822.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8249822 > > Thanks, > Coleen From david.holmes at oracle.com Thu Jul 23 01:47:51 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jul 2020 11:47:51 +1000 Subject: Fwd: Re: jdk/submit maintenance, July 23rd - July 27th In-Reply-To: <335D0317-7810-46F1-82B7-BE9268887A83@ORACLE.COM> References: <335D0317-7810-46F1-82B7-BE9268887A83@ORACLE.COM> Message-ID: -------- Forwarded Message -------- Subject: Re: jdk/submit maintenance, July 23rd - July 27th Date: Wed, 22 Jul 2020 21:39:40 -0400 From: Stanislav Smirnov To: jdk-dev Hello, Due to circumstances beyond our control the planned maintenance is called off. This means, that jdk/submit will continue to work. Best regards, Stanislav Smirnov > On Jul 22, 2020, at 3:26 PM, Stanislav Smirnov wrote: > > Hello, > > A planned maintenance will happen this week, July 23rd - 27th. > jdk/submit builds will not be available starting tomorrow (Thursday 23rd) at 10am PT / 17:00 GMT. > > The system should be back online by 10am PT / 17:00 GMT, July 27th. > > Best regards, > Stanislav Smirnov From david.holmes at oracle.com Thu Jul 23 04:51:57 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jul 2020 14:51:57 +1000 Subject: RFR(XS) 8248666: AArch64: Use THREAD_LOCAL instead of __thread In-Reply-To: References: <41e2b25a-9393-9cef-ac02-0a7273a7fc39@oracle.com> Message-ID: On 22/07/2020 11:06 pm, Bernhard Urban-Forster wrote: > Thank you for the review David. I have updated the "Reviewed-by: " line in the commit message accordingly. Changeset pushed. Now you have two sponsored changes in the JDK project you should request Author status in that project [1]. Then you won't need the "Contributed-by" line in the changeset comment. Cheers, David ----- [1] http://openjdk.java.net/projects/#project-author > > Thanks, > -Bernhard > > ________________________________________ > From: David Holmes > Sent: Wednesday, July 22, 2020 14:31 > To: Bernhard Urban-Forster; hotspot-dev Source Developers; aarch64-port-dev at openjdk.java.net > Cc: openjdk-aarch64 > Subject: Re: RFR(XS) 8248666: AArch64: Use THREAD_LOCAL instead of __thread > > Looks good to me. > > Thanks, > David > > On 22/07/2020 7:28 pm, Bernhard Urban-Forster wrote: >> Hi all, >> >> a trivial code cleanup to use an existing macro in the AArch64 backend. >> >> JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248666&data=02%7C01%7Cbeurba%40microsoft.com%7C3619bc11c2fe472c8ae508d82e3b3ba7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637310179223842396&sdata=Yi3n710V9VuSNNInQQsWUu8GJG0Er2k1a4pGVSwSJt4%3D&reserved=0 >> Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8248666%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C3619bc11c2fe472c8ae508d82e3b3ba7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637310179223842396&sdata=qpbIVYGHZo%2BWw1T9Cy7XIvbj137bAAnYgV7V91xqv0E%3D&reserved=0 >> >> >> Thank you, >> -Bernhard >> From kim.barrett at oracle.com Thu Jul 23 07:27:19 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2020 03:27:19 -0400 Subject: RFR: 8247908: Replace IsRegisteredEnum with std::is_enum Message-ID: <91E5EC84-21B9-4C75-9736-F1F706802502@oracle.com> Please review this change which removes our IsRegisteredEnum type trait and its uses, instead using the std::is_enum<> type trait. CR: https://bugs.openjdk.java.net/browse/JDK-8247908 Webrev: https://cr.openjdk.java.net/~kbarrett/8247908/open.00/ Testing: mach5 tier1 From kim.barrett at oracle.com Thu Jul 23 07:29:55 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2020 03:29:55 -0400 Subject: RFR: 8249944: Move and improve the AllStatic class Message-ID: <11775927-A3D9-4DCC-934E-92CCCD0FA009@oracle.com> Please review this change to the AllStatic base class, making it entirely standalone by using C++11 deleted functions to poison the constructor and destructor. To do so we also need to globally disable the Visual Studio C4624 warning: "'derived class' : destructor was implicitly defined as deleted because a base class destructor is inaccessible or deleted." Yes, we know that will happen; that's entirely the point of such an idiom, and this warning is entirely useless. The AllStatic class has also been extracted into its own file, so that potential users don't need to drag in all of allocation.hpp just to obtain this simple base class. I've also made allocation.hpp #include this new file, for backward compatibility. I've not searched for and updated files that could now just #include the new file rather than allocation.hpp; that can be done incrementally during the normal course of maintenance. CR: https://bugs.openjdk.java.net/browse/JDK-8249944 Webrev: https://cr.openjdk.java.net/~kbarrett/8249944/open.00/ Testing: mach5 tier1 From kim.barrett at oracle.com Thu Jul 23 07:31:34 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2020 03:31:34 -0400 Subject: RFR: 8249945: Improve ARRAY_SIZE() Message-ID: Please review this reimplementation of the ARRAY_SIZE() macro. The new implementation rejects pointer types instead of quietly returning the wrong value; see the CR for more details. CR: https://bugs.openjdk.java.net/browse/JDK-8249945 Webrev: https://cr.openjdk.java.net/~kbarrett/8249945/open.00/ Testing: mach5 tier1 From thomas.stuefe at gmail.com Thu Jul 23 07:36:37 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Jul 2020 09:36:37 +0200 Subject: RFR: 8249944: Move and improve the AllStatic class In-Reply-To: <11775927-A3D9-4DCC-934E-92CCCD0FA009@oracle.com> References: <11775927-A3D9-4DCC-934E-92CCCD0FA009@oracle.com> Message-ID: Hi Kim, this is great. It allows for many subsequent removals of allocation.hpp. When should we use AllStatic, when real C++ namespaces? Patch looks good to me. Cheers, Thomas On Thu, Jul 23, 2020 at 9:30 AM Kim Barrett wrote: > Please review this change to the AllStatic base class, making it > entirely standalone by using C++11 deleted functions to poison the > constructor and destructor. > > To do so we also need to globally disable the Visual Studio C4624 > warning: "'derived class' : destructor was implicitly defined as > deleted because a base class destructor is inaccessible or deleted." > Yes, we know that will happen; that's entirely the point of such an > idiom, and this warning is entirely useless. > > The AllStatic class has also been extracted into its own file, so that > potential users don't need to drag in all of allocation.hpp just to > obtain this simple base class. I've also made allocation.hpp #include > this new file, for backward compatibility. I've not searched for and > updated files that could now just #include the new file rather than > allocation.hpp; that can be done incrementally during the normal > course of maintenance. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8249944 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8249944/open.00/ > > Testing: > mach5 tier1 > > From david.holmes at oracle.com Thu Jul 23 07:41:16 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jul 2020 17:41:16 +1000 Subject: RFR: 8247908: Replace IsRegisteredEnum with std::is_enum In-Reply-To: <91E5EC84-21B9-4C75-9736-F1F706802502@oracle.com> References: <91E5EC84-21B9-4C75-9736-F1F706802502@oracle.com> Message-ID: Looks good! Thanks Kim! David ----- On 23/07/2020 5:27 pm, Kim Barrett wrote: > Please review this change which removes our IsRegisteredEnum type > trait and its uses, instead using the std::is_enum<> type trait. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8247908 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8247908/open.00/ > > Testing: > mach5 tier1 > From david.holmes at oracle.com Thu Jul 23 07:43:19 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jul 2020 17:43:19 +1000 Subject: RFR: 8249944: Move and improve the AllStatic class In-Reply-To: <11775927-A3D9-4DCC-934E-92CCCD0FA009@oracle.com> References: <11775927-A3D9-4DCC-934E-92CCCD0FA009@oracle.com> Message-ID: <58422db7-adfb-3747-6209-caad34c650d5@oracle.com> Looks good! Thanks Kim! David ----- On 23/07/2020 5:29 pm, Kim Barrett wrote: > Please review this change to the AllStatic base class, making it > entirely standalone by using C++11 deleted functions to poison the > constructor and destructor. > > To do so we also need to globally disable the Visual Studio C4624 > warning: "'derived class' : destructor was implicitly defined as > deleted because a base class destructor is inaccessible or deleted." > Yes, we know that will happen; that's entirely the point of such an > idiom, and this warning is entirely useless. > > The AllStatic class has also been extracted into its own file, so that > potential users don't need to drag in all of allocation.hpp just to > obtain this simple base class. I've also made allocation.hpp #include > this new file, for backward compatibility. I've not searched for and > updated files that could now just #include the new file rather than > allocation.hpp; that can be done incrementally during the normal > course of maintenance. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8249944 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8249944/open.00/ > > Testing: > mach5 tier1 > From thomas.schatzl at oracle.com Thu Jul 23 08:02:09 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 23 Jul 2020 10:02:09 +0200 Subject: RFR: 8247908: Replace IsRegisteredEnum with std::is_enum In-Reply-To: <91E5EC84-21B9-4C75-9736-F1F706802502@oracle.com> References: <91E5EC84-21B9-4C75-9736-F1F706802502@oracle.com> Message-ID: <7e264d06-fcf0-0a62-07ae-9e3a08467a36@oracle.com> Hi, On 23.07.20 09:27, Kim Barrett wrote: > Please review this change which removes our IsRegisteredEnum type > trait and its uses, instead using the std::is_enum<> type trait. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8247908 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8247908/open.00/ > > Testing: > mach5 tier1 > lgtm. Thomas From thomas.schatzl at oracle.com Thu Jul 23 08:42:47 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 23 Jul 2020 10:42:47 +0200 Subject: RFR: 8249945: Improve ARRAY_SIZE() In-Reply-To: References: Message-ID: <918ca550-0958-0cd1-d471-c525a98cb606@oracle.com> Hi, On 23.07.20 09:31, Kim Barrett wrote: > Please review this reimplementation of the ARRAY_SIZE() macro. The > new implementation rejects pointer types instead of quietly returning > the wrong value; see the CR for more details. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8249945 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8249945/open.00/ > > Testing: > mach5 tier1 > lgtm. Fwiw, in JIRA, for regular bugs/enhancements, markdown is disabled in the descriptions afaik, so the tags you added there are kind of out of place. They only work in JEPs. Thanks, Thomas From kim.barrett at oracle.com Thu Jul 23 09:33:04 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2020 05:33:04 -0400 Subject: RFR: 8249944: Move and improve the AllStatic class In-Reply-To: References: <11775927-A3D9-4DCC-934E-92CCCD0FA009@oracle.com> Message-ID: > On Jul 23, 2020, at 3:36 AM, Thomas St?fe wrote: > > Hi Kim, > > this is great. It allows for many subsequent removals of allocation.hpp. Thanks. That?s the idea. > When should we use AllStatic, when real C++ namespaces? That?s discussed in the new improved HotSpot Style Guide (JDK-8247976). > Patch looks good to me. Thanks. From kim.barrett at oracle.com Thu Jul 23 09:33:23 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2020 05:33:23 -0400 Subject: RFR: 8249944: Move and improve the AllStatic class In-Reply-To: <58422db7-adfb-3747-6209-caad34c650d5@oracle.com> References: <11775927-A3D9-4DCC-934E-92CCCD0FA009@oracle.com> <58422db7-adfb-3747-6209-caad34c650d5@oracle.com> Message-ID: > On Jul 23, 2020, at 3:43 AM, David Holmes wrote: > > Looks good! Thanks. > > Thanks Kim! > > David > ----- > > On 23/07/2020 5:29 pm, Kim Barrett wrote: >> Please review this change to the AllStatic base class, making it >> entirely standalone by using C++11 deleted functions to poison the >> constructor and destructor. >> To do so we also need to globally disable the Visual Studio C4624 >> warning: "'derived class' : destructor was implicitly defined as >> deleted because a base class destructor is inaccessible or deleted." >> Yes, we know that will happen; that's entirely the point of such an >> idiom, and this warning is entirely useless. >> The AllStatic class has also been extracted into its own file, so that >> potential users don't need to drag in all of allocation.hpp just to >> obtain this simple base class. I've also made allocation.hpp #include >> this new file, for backward compatibility. I've not searched for and >> updated files that could now just #include the new file rather than >> allocation.hpp; that can be done incrementally during the normal >> course of maintenance. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8249944 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8249944/open.00/ >> Testing: >> mach5 tier1 From kim.barrett at oracle.com Thu Jul 23 09:33:56 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2020 05:33:56 -0400 Subject: RFR: 8247908: Replace IsRegisteredEnum with std::is_enum In-Reply-To: References: <91E5EC84-21B9-4C75-9736-F1F706802502@oracle.com> Message-ID: <42358049-02FB-48C7-90D0-F0753ACAC9A9@oracle.com> > On Jul 23, 2020, at 3:41 AM, David Holmes wrote: > > Looks good! Thanks. > > Thanks Kim! > > David > ----- > > On 23/07/2020 5:27 pm, Kim Barrett wrote: >> Please review this change which removes our IsRegisteredEnum type >> trait and its uses, instead using the std::is_enum<> type trait. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8247908 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8247908/open.00/ >> Testing: >> mach5 tier1 From kim.barrett at oracle.com Thu Jul 23 09:34:06 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2020 05:34:06 -0400 Subject: RFR: 8247908: Replace IsRegisteredEnum with std::is_enum In-Reply-To: <7e264d06-fcf0-0a62-07ae-9e3a08467a36@oracle.com> References: <91E5EC84-21B9-4C75-9736-F1F706802502@oracle.com> <7e264d06-fcf0-0a62-07ae-9e3a08467a36@oracle.com> Message-ID: > On Jul 23, 2020, at 4:02 AM, Thomas Schatzl wrote: > > Hi, > > On 23.07.20 09:27, Kim Barrett wrote: >> Please review this change which removes our IsRegisteredEnum type >> trait and its uses, instead using the std::is_enum<> type trait. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8247908 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8247908/open.00/ >> Testing: >> mach5 tier1 > > lgtm. > > Thomas Thanks. From kim.barrett at oracle.com Thu Jul 23 09:36:19 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2020 05:36:19 -0400 Subject: RFR: 8249945: Improve ARRAY_SIZE() In-Reply-To: <918ca550-0958-0cd1-d471-c525a98cb606@oracle.com> References: <918ca550-0958-0cd1-d471-c525a98cb606@oracle.com> Message-ID: <0160EE99-32CD-46B5-AE46-66073F703394@oracle.com> > On Jul 23, 2020, at 4:42 AM, Thomas Schatzl wrote: > > Hi, > > On 23.07.20 09:31, Kim Barrett wrote: >> Please review this reimplementation of the ARRAY_SIZE() macro. The >> new implementation rejects pointer types instead of quietly returning >> the wrong value; see the CR for more details. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8249945 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8249945/open.00/ >> Testing: >> mach5 tier1 > > lgtm. Thanks. > Fwiw, in JIRA, for regular bugs/enhancements, markdown is disabled in the descriptions afaik, so the tags you added there are kind of out of place. They only work in JEPs. Yeah, I noticed that later. I left the tags anyway because I think they make the text a bit clearer by being explicit about what?s example code and what?s description / commentary. From thomas.schatzl at oracle.com Thu Jul 23 09:39:59 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 23 Jul 2020 11:39:59 +0200 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> <893f862f-093a-5168-e554-1f4ffe129aea@oracle.com> <07904b7e-8d40-8c9e-acc1-c713c1588b11@oracle.com> Message-ID: <4ad72264-2269-fcc1-b2fc-0568a993ca7d@oracle.com> Hi Dan and Serguei, thanks for your reviews. On 22.07.20 19:04, Daniel D. Daugherty wrote: >> jdk15: >> >> http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2/ (full) > > src/hotspot/share/prims/jvmtiEnvBase.cpp > ??? old L1029: ????? ResourceMark rm; > ??????? It's not clear (to me anyway) why this ResourceMark is removed. > > ??????? Update: I saw the discussion of "ResourceMark rm" in JDK15 versus > ??????? "ResourceMark rm(current_thread)" in JDK16, but that doesn't tell > ??????? me why it was necessary to remove that ResourceMark. The method that is guarded by this ResourceMark contains the necessary ResourceMark itself, so I removed it. > > src/hotspot/share/prims/stackwalk.cpp > ??? L291: ??? ResourceMark rm; > ??? L292: ??? HandleMark hm; > ??????? Since there's a TRAPS parameter, these should be 'rm(THREAD)' and > ??????? 'hm(THREAD)'. > > src/hotspot/share/runtime/biasedLocking.cpp > ??? No comments. > > src/hotspot/share/runtime/deoptimization.cpp > ??? No comments. > > src/hotspot/share/runtime/vframe.cpp > ??? L461: ? _lock? = lock; > ??????? nit - extra space before '='. > > src/hotspot/share/runtime/vframe.hpp > ??? L32: #include "runtime/handles.inline.hpp" > ??????? nit - new include is out of order; should be after frame.hpp. > > src/hotspot/share/runtime/vframeArray.cpp > ??? No comments. > > src/hotspot/share/runtime/vframe_hp.cpp > ??? Skipped - no changes. > > src/hotspot/share/services/threadService.cpp > ??? No comments. > All fixed, and incorporating Serguei's changes in the other email as well. jdk16: http://cr.openjdk.java.net/~tschatzl/8249192/webrev.3/ (full) http://cr.openjdk.java.net/~tschatzl/8249192/webrev.2_to_3/ (diff) jdk15: http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.3/ (full) http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2_to_3/ (diff) Note that the jdk15 change will only go into 15.0.2 as discussion with the release team showed that the change is too risky for earlier releases. See the relevant CR comment for details. Thanks, Thomas From thomas.stuefe at gmail.com Thu Jul 23 09:41:43 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Jul 2020 11:41:43 +0200 Subject: RFR: 8249944: Move and improve the AllStatic class In-Reply-To: References: <11775927-A3D9-4DCC-934E-92CCCD0FA009@oracle.com> Message-ID: On Thu, Jul 23, 2020 at 11:33 AM Kim Barrett wrote: > > On Jul 23, 2020, at 3:36 AM, Thomas St?fe > wrote: > > > > Hi Kim, > > > > this is great. It allows for many subsequent removals of allocation.hpp. > > Thanks. That?s the idea. > > > When should we use AllStatic, when real C++ namespaces? > > That?s discussed in the new improved HotSpot Style Guide (JDK-8247976). > > Thank you. I missed that mail thread when hotspot-dev went silent. I'll take my question there. ..Thomas > > Patch looks good to me. > > Thanks. > > From kim.barrett at oracle.com Thu Jul 23 09:44:41 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2020 05:44:41 -0400 Subject: RFR: 8249944: Move and improve the AllStatic class In-Reply-To: References: <11775927-A3D9-4DCC-934E-92CCCD0FA009@oracle.com> Message-ID: > On Jul 23, 2020, at 5:41 AM, Thomas St?fe wrote: > > > > On Thu, Jul 23, 2020 at 11:33 AM Kim Barrett wrote: > > On Jul 23, 2020, at 3:36 AM, Thomas St?fe wrote: > > > > Hi Kim, > > > > this is great. It allows for many subsequent removals of allocation.hpp. > > Thanks. That?s the idea. > > > When should we use AllStatic, when real C++ namespaces? > > That?s discussed in the new improved HotSpot Style Guide (JDK-8247976). > > > Thank you. I missed that mail thread when hotspot-dev went silent. I'll take my question there. Oh, that?s really unfortunate that the hotspot-dev outage happened then. > > ..Thomas > > > Patch looks good to me. > > Thanks. From thomas.stuefe at gmail.com Thu Jul 23 11:00:26 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Jul 2020 13:00:26 +0200 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption Message-ID: (note: original mail was lost to us because of the hotspot-dev outage, so I am answering to what I read in the ML archive: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/042247.html ) Hi Kim, Thank you for your work, this is a good and clean read! And I also think this was long overdue. I'd like to make an argument for using namespaces though. You write: Avoid using namespaces. HotSpot code normally uses "all static" classes rather than namespaces for grouping. An "all static" class is not instantiable, has only static members, and is normally derived (possibly indirectly) from the helper class `AllStatic`. Benefits of using such classes include: * Provides access control for members, which is unavailable with namespaces. * Avoids ADL (Argument Dependent Lookup). * Closed for additional members. Namespaces allow names to be added in multiple contexts, making it harder to see the complete API. Namespaces should be used only in cases where one of those "benefits" is actually a hindrance. I think "avoid" is a bit harsh; I think we should use them more. Often they would be a cleaner solution than using static class methods. The points 1 and 3 you list are exactly the reason why I sometimes prefer them. I do not like access control via C++ public/private membership as a way to define subsystem APIs, because it does not easily allow to split an API in public and internal parts across multiple headers. Within a sub system, I'd like to keep public headers - those to be consumed by code outside my subsystem - clean and the interfaces in them narrow. They should pull as little additional headers as possible. But AllStatic forces me to expose implementation details in headers. So implementation details creep into headers which should be clean of them. This can be seen in the hotspot in many places, e.g. in os_linux.hpp: of the 370 lines of code in the os::Linux class, 150 are private or protected members which really have no place in an outside interface (even worse in this case, they leak into the "os" API too). Exposing these details makes an interface convoluted. It is difficult to see the real external interface with all the private chaff sprinkled in, which often interleaves the public APIs. In that sense, "making it harder to see the complete API" as you put it is actually an advantage, since it allows me to only see the public API. And the lack of C++ access control forces the developer to split off private APIs from public ones. It pulls in unnecessary headers which are needed for the private implementation. This quickly leads to a "big ball of includes". That to me is a real gripe. It also tempts programmers to "just make it quickly public", to expose a private API to fix something where it may have been nicer to keep the interface narrow and find a different solution. So I think AllStatic is not conducive to clean interface design. With namespaces, OTOH, one can separate the public API from private APIs by moving them into different headers. So, I could have two headers, one "subsystem.hpp" for external consumption and one "subsystem_internals.hpp" for the subsystem itself. The former can be very brief, only includes whatever is needed for the interface prototypes. The latter can include whatever it wants since it is only ever seen by the subsystem implementation itself. As for class os and "os::" and "os::" in particular, here we include the nested "namespaces" directly into the middle of class os. I think these are ugly crutches and can cause confusion. For instance, one always has to remember that os_xxx.hpp files are not "real" headers, e.g. should not include any other headers. os and os:: etc could be defined a lot cleaner with nested namespaces. Therefore I suggest we allow namespaces. Maybe agree on a convention of how to use them. THanks, Thomas From coleen.phillimore at oracle.com Thu Jul 23 11:36:20 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 23 Jul 2020 07:36:20 -0400 Subject: RFR (S) 8249822: SymbolPropertyTable creates an extra OopHandle per entry In-Reply-To: References: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> Message-ID: <2e00b001-0749-8680-71e9-a7396f9bb48b@oracle.com> On 7/22/20 8:53 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > The fix looks good to me. Thank you for looking at this Serguei. > > > On 7/22/20 13:55, coleen.phillimore at oracle.com wrote: >> Summary: Add an assert to OopHandle assigment operator to catch >> leaking OopHandles, and fix code accordingly. >> >> There are some jvmtiRedefineClasses.cpp changes here - basically, I >> moved the RedefineVerifyMark and comments into >> jvmtiRedefineClasses.cpp because I needed a Handle. > > I think, the jvmtiRedefineClasses.cpp is a better place for the > RedefineVerifyMark. > But could you, please, explain a little bit more why this move was > necessary? > Why Handle can not be used in the jvmtiThreadState.cpp? I did have a patch where I moved the constructor and destructor in jvmtiThreadState.cpp but thought it made more sense just to move the whole class since nothing else would ever use it.?? I couldn't put the code change in jvmtiThreadState.hpp in place because I'd need to include handles.inline.hpp there.? It seems like jvmtiRedefineClasses.cpp already included all the files it needed, so that's where I moved it. Thanks, Coleen > > Thanks, > Serguei > > >> Ran tier1-6 tests and tier1 on all Oracle platforms. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8249822.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8249822 >> >> Thanks, >> Coleen > From david.holmes at oracle.com Thu Jul 23 12:05:53 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jul 2020 22:05:53 +1000 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <4ad72264-2269-fcc1-b2fc-0568a993ca7d@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> <893f862f-093a-5168-e554-1f4ffe129aea@oracle.com> <07904b7e-8d40-8c9e-acc1-c713c1588b11@oracle.com> <4ad72264-2269-fcc1-b2fc-0568a993ca7d@oracle.com> Message-ID: <1a148b15-ddf6-51b1-1b60-87528f101559@oracle.com> Hi Thomas, Incrementals looks good to me. Thanks, David ----- On 23/07/2020 7:39 pm, Thomas Schatzl wrote: > Hi Dan and Serguei, > > ? thanks for your reviews. > > On 22.07.20 19:04, Daniel D. Daugherty wrote: >>> jdk15: >>> >>> http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2/ (full) >> >> src/hotspot/share/prims/jvmtiEnvBase.cpp >> ???? old L1029: ????? ResourceMark rm; >> ???????? It's not clear (to me anyway) why this ResourceMark is removed. >> >> ???????? Update: I saw the discussion of "ResourceMark rm" in JDK15 >> versus >> ???????? "ResourceMark rm(current_thread)" in JDK16, but that doesn't >> tell >> ???????? me why it was necessary to remove that ResourceMark. > > The method that is guarded by this ResourceMark contains the necessary > ResourceMark itself, so I removed it. > >> >> src/hotspot/share/prims/stackwalk.cpp >> ???? L291: ??? ResourceMark rm; >> ???? L292: ??? HandleMark hm; >> ???????? Since there's a TRAPS parameter, these should be 'rm(THREAD)' >> and >> ???????? 'hm(THREAD)'. >> >> src/hotspot/share/runtime/biasedLocking.cpp >> ???? No comments. >> >> src/hotspot/share/runtime/deoptimization.cpp >> ???? No comments. >> >> src/hotspot/share/runtime/vframe.cpp >> ???? L461: ? _lock? = lock; >> ???????? nit - extra space before '='. >> >> src/hotspot/share/runtime/vframe.hpp >> ???? L32: #include "runtime/handles.inline.hpp" >> ???????? nit - new include is out of order; should be after frame.hpp. >> >> src/hotspot/share/runtime/vframeArray.cpp >> ???? No comments. >> >> src/hotspot/share/runtime/vframe_hp.cpp >> ???? Skipped - no changes. >> >> src/hotspot/share/services/threadService.cpp >> ???? No comments. >> > > All fixed, and incorporating Serguei's changes in the other email as well. > > jdk16: > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.3/ (full) > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.2_to_3/ (diff) > > jdk15: > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.3/ (full) > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2_to_3/ (diff) > > Note that the jdk15 change will only go into 15.0.2 as discussion with > the release team showed that the change is too risky for earlier > releases. See the relevant CR comment for details. > > Thanks, > ? Thomas > From erik.osterlund at oracle.com Thu Jul 23 14:40:55 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 23 Jul 2020 16:40:55 +0200 Subject: RFR (S) 8249822: SymbolPropertyTable creates an extra OopHandle per entry In-Reply-To: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> References: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> Message-ID: Hi Coleen, Looks good. One thing though: in the replace() function, assert that the obj_ptr != NULL instead of silently doing nothing. Don't need another webrev. Thanks, /Erik On 2020-07-22 22:55, coleen.phillimore at oracle.com wrote: > Summary: Add an assert to OopHandle assigment operator to catch > leaking OopHandles, and fix code accordingly. > > There are some jvmtiRedefineClasses.cpp changes here - basically, I > moved the RedefineVerifyMark and comments into > jvmtiRedefineClasses.cpp because I needed a Handle. > > Ran tier1-6 tests and tier1 on all Oracle platforms. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249822.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8249822 > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Jul 23 14:46:07 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 23 Jul 2020 10:46:07 -0400 Subject: RFR (S) 8249822: SymbolPropertyTable creates an extra OopHandle per entry In-Reply-To: References: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> Message-ID: Thanks Erik. I added the assert to replace() and reran tier1 and 3 tests. Coleen On 7/23/20 10:40 AM, Erik ?sterlund wrote: > Hi Coleen, > > Looks good. One thing though: in the replace() function, assert that > the obj_ptr != NULL instead of silently doing nothing. > > Don't need another webrev. > > Thanks, > /Erik > > On 2020-07-22 22:55, coleen.phillimore at oracle.com wrote: >> Summary: Add an assert to OopHandle assigment operator to catch >> leaking OopHandles, and fix code accordingly. >> >> There are some jvmtiRedefineClasses.cpp changes here - basically, I >> moved the RedefineVerifyMark and comments into >> jvmtiRedefineClasses.cpp because I needed a Handle. >> >> Ran tier1-6 tests and tier1 on all Oracle platforms. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8249822.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8249822 >> >> Thanks, >> Coleen > From lois.foltan at oracle.com Thu Jul 23 15:09:56 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 23 Jul 2020 11:09:56 -0400 Subject: RFR: 8249945: Improve ARRAY_SIZE() In-Reply-To: References: Message-ID: <35330f4c-55be-588c-ab78-d37ffd4c75f7@oracle.com> On 7/23/2020 3:31 AM, Kim Barrett wrote: > Please review this reimplementation of the ARRAY_SIZE() macro. The > new implementation rejects pointer types instead of quietly returning > the wrong value; see the CR for more details. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8249945 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8249945/open.00/ > > Testing: > mach5 tier1 > Hi Kim, Looks good.? For my own understanding, is there any value in adding a "const" in front of T in the template?? Such as template char (&array_size_impl(const T (&)[N]))[N]; Thanks, Lois From daniel.daugherty at oracle.com Thu Jul 23 15:35:57 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 23 Jul 2020 11:35:57 -0400 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <4ad72264-2269-fcc1-b2fc-0568a993ca7d@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> <893f862f-093a-5168-e554-1f4ffe129aea@oracle.com> <07904b7e-8d40-8c9e-acc1-c713c1588b11@oracle.com> <4ad72264-2269-fcc1-b2fc-0568a993ca7d@oracle.com> Message-ID: <87846f7d-c213-733a-9a6f-96e5d02df247@oracle.com> > jdk16: > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.2_to_3/ (diff) > > jdk15: > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2_to_3/ (diff) The delta webrevs look just fine. Dan On 7/23/20 5:39 AM, Thomas Schatzl wrote: > Hi Dan and Serguei, > > ? thanks for your reviews. > > On 22.07.20 19:04, Daniel D. Daugherty wrote: >>> jdk15: >>> >>> http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2/ (full) >> >> src/hotspot/share/prims/jvmtiEnvBase.cpp >> ???? old L1029: ????? ResourceMark rm; >> ???????? It's not clear (to me anyway) why this ResourceMark is removed. >> >> ???????? Update: I saw the discussion of "ResourceMark rm" in JDK15 >> versus >> ???????? "ResourceMark rm(current_thread)" in JDK16, but that doesn't >> tell >> ???????? me why it was necessary to remove that ResourceMark. > > The method that is guarded by this ResourceMark contains the necessary > ResourceMark itself, so I removed it. > >> >> src/hotspot/share/prims/stackwalk.cpp >> ???? L291: ??? ResourceMark rm; >> ???? L292: ??? HandleMark hm; >> ???????? Since there's a TRAPS parameter, these should be >> 'rm(THREAD)' and >> ???????? 'hm(THREAD)'. >> >> src/hotspot/share/runtime/biasedLocking.cpp >> ???? No comments. >> >> src/hotspot/share/runtime/deoptimization.cpp >> ???? No comments. >> >> src/hotspot/share/runtime/vframe.cpp >> ???? L461: ? _lock? = lock; >> ???????? nit - extra space before '='. >> >> src/hotspot/share/runtime/vframe.hpp >> ???? L32: #include "runtime/handles.inline.hpp" >> ???????? nit - new include is out of order; should be after frame.hpp. >> >> src/hotspot/share/runtime/vframeArray.cpp >> ???? No comments. >> >> src/hotspot/share/runtime/vframe_hp.cpp >> ???? Skipped - no changes. >> >> src/hotspot/share/services/threadService.cpp >> ???? No comments. >> > > All fixed, and incorporating Serguei's changes in the other email as > well. > > jdk16: > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.3/ (full) > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.2_to_3/ (diff) > > jdk15: > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.3/ (full) > http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2_to_3/ (diff) > > Note that the jdk15 change will only go into 15.0.2 as discussion with > the release team showed that the change is too risky for earlier > releases. See the relevant CR comment for details. > > Thanks, > ? Thomas > From coleen.phillimore at oracle.com Thu Jul 23 16:58:53 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 23 Jul 2020 12:58:53 -0400 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code Message-ID: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> See bug for more details.? I've been running into these names a lot lately.?? Many of these names are in JVMTI. Tested with tier1 on all Oracle platforms and built on non-Oracle platforms. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8250042 Thanks, Coleen From serguei.spitsyn at oracle.com Thu Jul 23 19:18:57 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jul 2020 12:18:57 -0700 Subject: RFR (S) 8249822: SymbolPropertyTable creates an extra OopHandle per entry In-Reply-To: <2e00b001-0749-8680-71e9-a7396f9bb48b@oracle.com> References: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> <2e00b001-0749-8680-71e9-a7396f9bb48b@oracle.com> Message-ID: Thank you for answering my question, Coleen! Serguei On 7/23/20 04:36, coleen.phillimore at oracle.com wrote: > > > On 7/22/20 8:53 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> The fix looks good to me. > > Thank you for looking at this Serguei. >> >> >> On 7/22/20 13:55, coleen.phillimore at oracle.com wrote: >>> Summary: Add an assert to OopHandle assigment operator to catch >>> leaking OopHandles, and fix code accordingly. >>> >>> There are some jvmtiRedefineClasses.cpp changes here - basically, I >>> moved the RedefineVerifyMark and comments into >>> jvmtiRedefineClasses.cpp because I needed a Handle. >> >> I think, the jvmtiRedefineClasses.cpp is a better place for the >> RedefineVerifyMark. >> But could you, please, explain a little bit more why this move was >> necessary? >> Why Handle can not be used in the jvmtiThreadState.cpp? > > I did have a patch where I moved the constructor and destructor in > jvmtiThreadState.cpp but thought it made more sense just to move the > whole class since nothing else would ever use it.?? I couldn't put the > code change in jvmtiThreadState.hpp in place because I'd need to > include handles.inline.hpp there.? It seems like > jvmtiRedefineClasses.cpp already included all the files it needed, so > that's where I moved it. > > Thanks, > Coleen > > >> >> Thanks, >> Serguei >> >> >>> Ran tier1-6 tests and tier1 on all Oracle platforms. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8249822.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8249822 >>> >>> Thanks, >>> Coleen >> > From serguei.spitsyn at oracle.com Thu Jul 23 19:22:55 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jul 2020 12:22:55 -0700 Subject: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <87846f7d-c213-733a-9a6f-96e5d02df247@oracle.com> References: <3f838c8a-6e70-cd94-1753-8abe269b7cdf@oracle.com> <528ade6c-059a-d9af-b0c7-74d7ac31b29a@oracle.com> <14512a57-8d4d-5199-ed16-743b5da8a10d@oracle.com> <893f862f-093a-5168-e554-1f4ffe129aea@oracle.com> <07904b7e-8d40-8c9e-acc1-c713c1588b11@oracle.com> <4ad72264-2269-fcc1-b2fc-0568a993ca7d@oracle.com> <87846f7d-c213-733a-9a6f-96e5d02df247@oracle.com> Message-ID: <00d2c4b4-f3fa-97ee-92be-b311738daac0@oracle.com> LGTM++ Thanks, Serguei On 7/23/20 08:35, Daniel D. Daugherty wrote: >> jdk16: >> http://cr.openjdk.java.net/~tschatzl/8249192/webrev.2_to_3/ (diff) >> >> jdk15: >> http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2_to_3/ (diff) > > The delta webrevs look just fine. > > Dan > > > On 7/23/20 5:39 AM, Thomas Schatzl wrote: >> Hi Dan and Serguei, >> >> ? thanks for your reviews. >> >> On 22.07.20 19:04, Daniel D. Daugherty wrote: >>>> jdk15: >>>> >>>> http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2/ (full) >>> >>> src/hotspot/share/prims/jvmtiEnvBase.cpp >>> ???? old L1029: ????? ResourceMark rm; >>> ???????? It's not clear (to me anyway) why this ResourceMark is >>> removed. >>> >>> ???????? Update: I saw the discussion of "ResourceMark rm" in JDK15 >>> versus >>> ???????? "ResourceMark rm(current_thread)" in JDK16, but that >>> doesn't tell >>> ???????? me why it was necessary to remove that ResourceMark. >> >> The method that is guarded by this ResourceMark contains the >> necessary ResourceMark itself, so I removed it. >> >>> >>> src/hotspot/share/prims/stackwalk.cpp >>> ???? L291: ??? ResourceMark rm; >>> ???? L292: ??? HandleMark hm; >>> ???????? Since there's a TRAPS parameter, these should be >>> 'rm(THREAD)' and >>> ???????? 'hm(THREAD)'. >>> >>> src/hotspot/share/runtime/biasedLocking.cpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/deoptimization.cpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/vframe.cpp >>> ???? L461: ? _lock? = lock; >>> ???????? nit - extra space before '='. >>> >>> src/hotspot/share/runtime/vframe.hpp >>> ???? L32: #include "runtime/handles.inline.hpp" >>> ???????? nit - new include is out of order; should be after frame.hpp. >>> >>> src/hotspot/share/runtime/vframeArray.cpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/vframe_hp.cpp >>> ???? Skipped - no changes. >>> >>> src/hotspot/share/services/threadService.cpp >>> ???? No comments. >>> >> >> All fixed, and incorporating Serguei's changes in the other email as >> well. >> >> jdk16: >> http://cr.openjdk.java.net/~tschatzl/8249192/webrev.3/ (full) >> http://cr.openjdk.java.net/~tschatzl/8249192/webrev.2_to_3/ (diff) >> >> jdk15: >> http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.3/ (full) >> http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2_to_3/ (diff) >> >> Note that the jdk15 change will only go into 15.0.2 as discussion >> with the release team showed that the change is too risky for earlier >> releases. See the relevant CR comment for details. >> >> Thanks, >> ? Thomas >> > From coleen.phillimore at oracle.com Thu Jul 23 19:25:02 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 23 Jul 2020 15:25:02 -0400 Subject: RFR (S) 8249822: SymbolPropertyTable creates an extra OopHandle per entry In-Reply-To: References: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> <2e00b001-0749-8680-71e9-a7396f9bb48b@oracle.com> Message-ID: Thanks Serguei! Coleen On 7/23/20 3:18 PM, serguei.spitsyn at oracle.com wrote: > Thank you for answering my question, Coleen! > Serguei > > > On 7/23/20 04:36, coleen.phillimore at oracle.com wrote: >> >> >> On 7/22/20 8:53 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> The fix looks good to me. >> >> Thank you for looking at this Serguei. >>> >>> >>> On 7/22/20 13:55, coleen.phillimore at oracle.com wrote: >>>> Summary: Add an assert to OopHandle assigment operator to catch >>>> leaking OopHandles, and fix code accordingly. >>>> >>>> There are some jvmtiRedefineClasses.cpp changes here - basically, I >>>> moved the RedefineVerifyMark and comments into >>>> jvmtiRedefineClasses.cpp because I needed a Handle. >>> >>> I think, the jvmtiRedefineClasses.cpp is a better place for the >>> RedefineVerifyMark. >>> But could you, please, explain a little bit more why this move was >>> necessary? >>> Why Handle can not be used in the jvmtiThreadState.cpp? >> >> I did have a patch where I moved the constructor and destructor in >> jvmtiThreadState.cpp but thought it made more sense just to move the >> whole class since nothing else would ever use it.?? I couldn't put >> the code change in jvmtiThreadState.hpp in place because I'd need to >> include handles.inline.hpp there.? It seems like >> jvmtiRedefineClasses.cpp already included all the files it needed, so >> that's where I moved it. >> >> Thanks, >> Coleen >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>>> Ran tier1-6 tests and tier1 on all Oracle platforms. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8249822.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8249822 >>>> >>>> Thanks, >>>> Coleen >>> >> > From kim.barrett at oracle.com Thu Jul 23 19:45:09 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2020 15:45:09 -0400 Subject: RFR: 8249945: Improve ARRAY_SIZE() In-Reply-To: <35330f4c-55be-588c-ab78-d37ffd4c75f7@oracle.com> References: <35330f4c-55be-588c-ab78-d37ffd4c75f7@oracle.com> Message-ID: <44922743-4762-4178-BFDD-A16221F2CE9F@oracle.com> > On Jul 23, 2020, at 11:09 AM, Lois Foltan wrote: > > On 7/23/2020 3:31 AM, Kim Barrett wrote: >> Please review this reimplementation of the ARRAY_SIZE() macro. The >> new implementation rejects pointer types instead of quietly returning >> the wrong value; see the CR for more details. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8249945 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8249945/open.00/ >> >> Testing: >> mach5 tier1 >> > > Hi Kim, > > Looks good. Thanks. > For my own understanding, is there any value in adding a "const" in front of T in the template? Such as > > template char (&array_size_impl(const T (&)[N]))[N]; > > Thanks, > Lois I think it doesn?t matter; if the argument is const, the deduced T will be const qualified. But we don?t care about the details of the deduced T at all. The last of the new gtest checks uses a const array argument. From lois.foltan at oracle.com Thu Jul 23 20:46:01 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 23 Jul 2020 16:46:01 -0400 Subject: RFR: 8249945: Improve ARRAY_SIZE() In-Reply-To: <44922743-4762-4178-BFDD-A16221F2CE9F@oracle.com> References: <35330f4c-55be-588c-ab78-d37ffd4c75f7@oracle.com> <44922743-4762-4178-BFDD-A16221F2CE9F@oracle.com> Message-ID: <83b0011c-53c3-f551-ba0c-d42fdda95d5e@oracle.com> On 7/23/2020 3:45 PM, Kim Barrett wrote: >> On Jul 23, 2020, at 11:09 AM, Lois Foltan wrote: >> >> On 7/23/2020 3:31 AM, Kim Barrett wrote: >>> Please review this reimplementation of the ARRAY_SIZE() macro. The >>> new implementation rejects pointer types instead of quietly returning >>> the wrong value; see the CR for more details. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8249945 >>> >>> Webrev: >>> https://cr.openjdk.java.net/~kbarrett/8249945/open.00/ >>> >>> Testing: >>> mach5 tier1 >>> >> Hi Kim, >> >> Looks good. > Thanks. > >> For my own understanding, is there any value in adding a "const" in front of T in the template? Such as >> >> template char (&array_size_impl(const T (&)[N]))[N]; >> >> Thanks, >> Lois > I think it doesn?t matter; if the argument is const, the deduced T will be const qualified. But we don?t care > about the details of the deduced T at all. The last of the new gtest checks uses a const array argument. > Ok, thanks for the explanation! Lois From Monica.Beckwith at microsoft.com Thu Jul 23 21:05:43 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Thu, 23 Jul 2020 21:05:43 +0000 Subject: RFR/Feedback(XS) 8248668: AArch64: Avoid MIN/MAX macros when using MSVC In-Reply-To: <95EC79BD-A213-4ACD-B3B7-A8A112B2C2F7@oracle.com> References: <95EC79BD-A213-4ACD-B3B7-A8A112B2C2F7@oracle.com> Message-ID: Thanks, Thomas and Kim, I have added you both in the 'reviewed-by' field and here's the new webrev: http://cr.openjdk.java.net/~mbeckwit/8248668/webrev.01/ I am also linking the bug id here again (sorry that our mail client obfuscates links): https://bugs.openjdk.java.net/browse/JDK-8248668. Can someone please help push it? Regards, Monica -----Original Message----- From: Kim Barrett Sent: Friday, July 17, 2020 12:44 PM To: Monica Beckwith Cc: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers ; openjdk-aarch64 Subject: Re: RFR/Feedback(XS) 8248668: AArch64: Avoid MIN/MAX macros when using MSVC > On Jul 16, 2020, at 7:25 PM, Monica Beckwith wrote: > > On Windows, we employ min/max as macros ??, hence we have made a few changes to appropriate shared sources: > > JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248668&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C565ae080eb8b45304a9108d82a790df5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637306046696535165&sdata=fYB0i9oIVspGlFwehtcRP5a9raDvYoy7nL5dAJ0yej0%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~mbeckwit%2F8248668%2Fwebrev.00%2F&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C565ae080eb8b45304a9108d82a790df5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637306046696535165&sdata=g6SakFcYU3bSBE5WY6v%2F4j1mm5Ec12H1DhjZ%2BPR%2B1ao%3D&reserved=0 > > Regards, > Monica Looks good. From chris.plummer at oracle.com Thu Jul 23 22:29:33 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 23 Jul 2020 15:29:33 -0700 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> Message-ID: <93edcee0-5d38-81f2-fe04-4d9585eb3d30@oracle.com> Hi Coleen, The JVMTI changes look fine, although I wonder why in jvmtiEnter.xsl you did the rename to "checked_method" instead of just "method". Was there a conflict in some cases? thanks, Chris On 7/23/20 9:58 AM, coleen.phillimore at oracle.com wrote: > See bug for more details.? I've been running into these names a lot > lately.?? Many of these names are in JVMTI. > > Tested with tier1 on all Oracle platforms and built on non-Oracle > platforms. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8250042 > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Jul 23 23:17:09 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 23 Jul 2020 19:17:09 -0400 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: <93edcee0-5d38-81f2-fe04-4d9585eb3d30@oracle.com> References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> <93edcee0-5d38-81f2-fe04-4d9585eb3d30@oracle.com> Message-ID: <4b3cc2f6-3729-77f3-51c6-48dee05de036@oracle.com> On 7/23/20 6:29 PM, Chris Plummer wrote: > Hi Coleen, > > The JVMTI changes look fine, although I wonder why in jvmtiEnter.xsl > you did the rename to "checked_method" instead of just "method". Was > there a conflict in some cases? Yes it was quite painful.? The jvmti.xml spec has jmethodID parameters to be named "method" and I didn't want to change that. ??????? ????????? ??????????? ????????????? The method in which to set the breakpoint ??????????? I picked checked_method because you get it by calling this below and the alternative "m" I think was used somewhere else (or not descriptive at all). +? ? Method* checked_method = Method::checked_resolve_jmethod_id( Thanks, Coleen > > thanks, > > Chris > > On 7/23/20 9:58 AM, coleen.phillimore at oracle.com wrote: >> See bug for more details.? I've been running into these names a lot >> lately.?? Many of these names are in JVMTI. >> >> Tested with tier1 on all Oracle platforms and built on non-Oracle >> platforms. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8250042 >> >> Thanks, >> Coleen > > From chris.plummer at oracle.com Thu Jul 23 23:48:43 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 23 Jul 2020 16:48:43 -0700 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: <4b3cc2f6-3729-77f3-51c6-48dee05de036@oracle.com> References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> <93edcee0-5d38-81f2-fe04-4d9585eb3d30@oracle.com> <4b3cc2f6-3729-77f3-51c6-48dee05de036@oracle.com> Message-ID: <8572e90b-3b95-3cef-ae4c-819703a015da@oracle.com> On 7/23/20 4:17 PM, coleen.phillimore at oracle.com wrote: > > > On 7/23/20 6:29 PM, Chris Plummer wrote: >> Hi Coleen, >> >> The JVMTI changes look fine, although I wonder why in jvmtiEnter.xsl >> you did the rename to "checked_method" instead of just "method". Was >> there a conflict in some cases? > > Yes it was quite painful.? The jvmti.xml spec has jmethodID parameters > to be named "method" and I didn't want to change that. > > ??????? > ????????? > ??????????? > ????????????? The method in which to set the breakpoint > ??????????? > > I picked checked_method because you get it by calling this below and > the alternative "m" I think was used somewhere else (or not > descriptive at all). > > +? ? Method* checked_method = > Method::checked_resolve_jmethod_id( > Ah, so this is the case of having to deal with a jmethodID and a Method* in the same scope. I think this is fine, although it would be nice if Serguei also gave his blessing. thanks, Chris > Thanks, > Coleen >> >> thanks, >> >> Chris >> >> On 7/23/20 9:58 AM, coleen.phillimore at oracle.com wrote: >>> See bug for more details.? I've been running into these names a lot >>> lately.?? Many of these names are in JVMTI. >>> >>> Tested with tier1 on all Oracle platforms and built on non-Oracle >>> platforms. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8250042 >>> >>> Thanks, >>> Coleen >> >> > From david.holmes at oracle.com Fri Jul 24 04:35:52 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jul 2020 14:35:52 +1000 Subject: RFR: 8249945: Improve ARRAY_SIZE() In-Reply-To: References: Message-ID: <146c2e95-e012-52d8-f8ac-706f78178f31@oracle.com> This looks good to me too (once Kim explained to me how to parse the template declaration :) ). Thanks, David On 23/07/2020 5:31 pm, Kim Barrett wrote: > Please review this reimplementation of the ARRAY_SIZE() macro. The > new implementation rejects pointer types instead of quietly returning > the wrong value; see the CR for more details. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8249945 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8249945/open.00/ > > Testing: > mach5 tier1 > From david.holmes at oracle.com Fri Jul 24 05:01:21 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jul 2020 15:01:21 +1000 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> Message-ID: <6f973a0a-cf55-e1ab-8de3-b57f68dbd2cf@oracle.com> Hi Coleen, On 24/07/2020 2:58 am, coleen.phillimore at oracle.com wrote: > See bug for more details.? I've been running into these names a lot > lately.?? Many of these names are in JVMTI. > > Tested with tier1 on all Oracle platforms and built on non-Oracle > platforms. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8250042 src/hotspot/cpu/*/*.ad These still refer to "method oop" and method_oop in a number of places. src/hotspot/share/adlc/adlparse.cpp + frame->_interpreter_method_oop_reg = parse_one_arg("method reg entry"); I guess I'm not understanding the scope of this renaming - why is _interpreter_method_oop_reg not renamed as well? Should this (and other uses) be parsed as method-(oop-reg) rather than (method-oop)-reg? Otherwise all okay. Thanks, David > Thanks, > Coleen From david.holmes at oracle.com Fri Jul 24 05:41:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jul 2020 15:41:29 +1000 Subject: RFR (S) 8249822: SymbolPropertyTable creates an extra OopHandle per entry In-Reply-To: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> References: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> Message-ID: On 23/07/2020 6:55 am, coleen.phillimore at oracle.com wrote: > Summary: Add an assert to OopHandle assigment operator to catch leaking > OopHandles, and fix code accordingly. > > There are some jvmtiRedefineClasses.cpp changes here - basically, I > moved the RedefineVerifyMark and comments into jvmtiRedefineClasses.cpp > because I needed a Handle. > > Ran tier1-6 tests and tier1 on all Oracle platforms. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249822.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8249822 This all seems okay. A couple of minor nits src/hotspot/share/oops/klass.cpp + void Klass::replace_java_mirror(oop mirror) { _java_mirror.replace(mirror); } Writing this all in one line is inconsistent with surrounding style. --- 1226 // a) A reference to the class being redefined (_the_class) and a 1230 // b) The _java_mirror field from _the_class is copied to the There's an extra space before b) on line 1230. Thanks, David ----- > Thanks, > Coleen From thomas.schatzl at oracle.com Fri Jul 24 07:52:19 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 24 Jul 2020 09:52:19 +0200 Subject: RFR/Feedback(XS) 8248668: AArch64: Avoid MIN/MAX macros when using MSVC In-Reply-To: References: <95EC79BD-A213-4ACD-B3B7-A8A112B2C2F7@oracle.com> Message-ID: <1b7d0dad-0349-0ba7-cd93-3aac4657f10a@oracle.com> Hi Monica, On 23.07.20 23:05, Monica Beckwith wrote: > Thanks, Thomas and Kim, I have added you both in the 'reviewed-by' field and here's the new webrev: http://cr.openjdk.java.net/~mbeckwit/8248668/webrev.01/ > I am also linking the bug id here again (sorry that our mail client obfuscates links): https://bugs.openjdk.java.net/browse/JDK-8248668. > > Can someone please help push it? > I'll push it. Thanks, Thomas From kim.barrett at oracle.com Fri Jul 24 09:37:03 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 24 Jul 2020 05:37:03 -0400 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: References: Message-ID: <08BD40C5-D074-40F2-9C22-D36EB362D6FA@oracle.com> > On Jul 23, 2020, at 7:00 AM, Thomas St?fe wrote: > > (note: original mail was lost to us because of the hotspot-dev outage, so I am answering to what I read in the ML archive: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/042247.html ) Drat! That was exceptionally bad outage timing for this project. > Hi Kim, > > Thank you for your work, this is a good and clean read! And I also think this was long overdue. Thanks. > I'd like to make an argument for using namespaces though. You write: [?] With this update to the Style Guide I've been mostly trying to maintain the status quo (though with more explanation in some cases) for existing usage. In this round I'm trying to limit changes to (1) an initial set of modifications describing C++11/14 usage, (2) re-homing the document, and (3) describing a process for updating it (which has been sorely lacking). As you read through this thread you'll have seen several places where a desire for some change is noted but is not being addressed in this set of changes. I'd like to do the same for namespaces. I'd be happy to see a discussion about the use of namespaces once some version of this document is in its new home and includes the initial C++14 stuff. From kim.barrett at oracle.com Fri Jul 24 11:26:50 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 24 Jul 2020 07:26:50 -0400 Subject: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper In-Reply-To: References: Message-ID: > On Jul 21, 2020, at 3:17 PM, Ludovic Henry wrote: > > Hello, > > Simple code cleanup to use existing ATTRIBUTE_ALIGNED macro in src/hotspot/cpu/aarch64. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248682 > Webrev: http://cr.openjdk.java.net/~burban/luhenry/8248682/webrev.00 > > Testing: jtreg:test/hotspot/jtreg:tier1, jtreg:test/jdk:tier1, jtreg:test/jdk:tier2, jtreg:test/langtools, on Windows-AArch64 and Linux-AArch64. > > Thank you, > > -- > Ludovic Looks good. From coleen.phillimore at oracle.com Fri Jul 24 11:44:17 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 24 Jul 2020 07:44:17 -0400 Subject: RFR (S) 8249822: SymbolPropertyTable creates an extra OopHandle per entry In-Reply-To: References: <84643f6c-0e05-061e-b6e3-a38d09ed973a@oracle.com> Message-ID: On 7/24/20 1:41 AM, David Holmes wrote: > On 23/07/2020 6:55 am, coleen.phillimore at oracle.com wrote: >> Summary: Add an assert to OopHandle assigment operator to catch >> leaking OopHandles, and fix code accordingly. >> >> There are some jvmtiRedefineClasses.cpp changes here - basically, I >> moved the RedefineVerifyMark and comments into >> jvmtiRedefineClasses.cpp because I needed a Handle. >> >> Ran tier1-6 tests and tier1 on all Oracle platforms. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8249822.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8249822 > > This all seems okay. A couple of minor nits > > src/hotspot/share/oops/klass.cpp > > + void Klass::replace_java_mirror(oop mirror) { > _java_mirror.replace(mirror); } > > Writing this all in one line is inconsistent with surrounding style. I was going to fix the java_mirror_no_keepalive() to match this style, but I've fixed this one instead. > > --- > > 1226 //? a) A reference to the class being redefined (_the_class) and a > 1230 //?? b) The _java_mirror field from _the_class is copied to the > > There's an extra space before b) on line 1230. Wow. fixed. Thanks for reviewing this! Coleen > > Thanks, > David > ----- > > >> Thanks, >> Coleen From thomas.schatzl at oracle.com Fri Jul 24 12:01:50 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 24 Jul 2020 14:01:50 +0200 Subject: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper In-Reply-To: References: Message-ID: <0707d751-da96-b316-fa52-b8159d2c5314@oracle.com> Hi, On 21.07.20 21:17, Ludovic Henry wrote: > Hello, > > Simple code cleanup to use existing ATTRIBUTE_ALIGNED macro in src/hotspot/cpu/aarch64. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248682 > Webrev: http://cr.openjdk.java.net/~burban/luhenry/8248682/webrev.00 > > Testing: jtreg:test/hotspot/jtreg:tier1, jtreg:test/jdk:tier1, jtreg:test/jdk:tier2, jtreg:test/langtools, on Windows-AArch64 and Linux-AArch64. > > Thank you, > > -- > Ludovic > lgtm. Thomas From coleen.phillimore at oracle.com Fri Jul 24 12:23:38 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 24 Jul 2020 08:23:38 -0400 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: <6f973a0a-cf55-e1ab-8de3-b57f68dbd2cf@oracle.com> References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> <6f973a0a-cf55-e1ab-8de3-b57f68dbd2cf@oracle.com> Message-ID: Thanks for looking at this. On 7/24/20 1:01 AM, David Holmes wrote: > Hi Coleen, > > On 24/07/2020 2:58 am, coleen.phillimore at oracle.com wrote: >> See bug for more details.? I've been running into these names a lot >> lately.?? Many of these names are in JVMTI. >> >> Tested with tier1 on all Oracle platforms and built on non-Oracle >> platforms. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8250042 > > src/hotspot/cpu/*/*.ad > > These still refer to "method oop" and method_oop in a number of places. Yes, I only replaced method_oop in the shared code and not in the AD code.? method_oop can be the name of a parameter and using "sed" to change it to "method" doesn't work.?? Somebody who understands this code and looks at it will have to make the rest of the changes. What I did was replace "method oop" with "method" and "methodOop" with "method" in all the sources.? I replaced "method_oop" with "method" or "checked_method" in the shared sources. > > src/hotspot/share/adlc/adlparse.cpp > > +? frame->_interpreter_method_oop_reg = parse_one_arg("method reg > entry"); > > I guess I'm not understanding the scope of this renaming - why is > _interpreter_method_oop_reg not renamed as well? Should this (and > other uses) be parsed as method-(oop-reg) rather than (method-oop)-reg? I don't know this code, so I'd rather not change any more of it. The comment makes sense changed, even though the variable name still refers to method_oop. Thanks, Coleen > > Otherwise all okay. > > Thanks, > David > >> Thanks, >> Coleen From coleen.phillimore at oracle.com Fri Jul 24 13:10:24 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 24 Jul 2020 09:10:24 -0400 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> <6f973a0a-cf55-e1ab-8de3-b57f68dbd2cf@oracle.com> Message-ID: I can also replace method_oop with method_ptr in the CPU ad files, and this seems to build but now someone who knows the compiler area needs to comment; this was supposed to be trivial... :)? But it still is really trivial to look at. I left interpreter_method_oop_reg and compiler_method_oop_reg and friends in opto/matcher.cpp for someone else. incremental webrev at http://cr.openjdk.java.net/~coleenp/2020/8250042.02.incr/webrev full webrev at http://cr.openjdk.java.net/~coleenp/2020/8250042.02/webrev Thanks, Coleen On 7/24/20 8:23 AM, coleen.phillimore at oracle.com wrote: > > Thanks for looking at this. > > On 7/24/20 1:01 AM, David Holmes wrote: >> Hi Coleen, >> >> On 24/07/2020 2:58 am, coleen.phillimore at oracle.com wrote: >>> See bug for more details.? I've been running into these names a lot >>> lately.?? Many of these names are in JVMTI. >>> >>> Tested with tier1 on all Oracle platforms and built on non-Oracle >>> platforms. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8250042 >> >> src/hotspot/cpu/*/*.ad >> >> These still refer to "method oop" and method_oop in a number of places. > > Yes, I only replaced method_oop in the shared code and not in the AD > code.? method_oop can be the name of a parameter and using "sed" to > change it to "method" doesn't work.?? Somebody who understands this > code and looks at it will have to make the rest of the changes. > > What I did was replace "method oop" with "method" and "methodOop" with > "method" in all the sources.? I replaced "method_oop" with "method" or > "checked_method" in the shared sources. > >> >> src/hotspot/share/adlc/adlparse.cpp >> >> +? frame->_interpreter_method_oop_reg = parse_one_arg("method reg >> entry"); >> >> I guess I'm not understanding the scope of this renaming - why is >> _interpreter_method_oop_reg not renamed as well? Should this (and >> other uses) be parsed as method-(oop-reg) rather than (method-oop)-reg? > > I don't know this code, so I'd rather not change any more of it. The > comment makes sense changed, even though the variable name still > refers to method_oop. > > Thanks, > Coleen >> >> Otherwise all okay. >> >> Thanks, >> David >> >>> Thanks, >>> Coleen > From thomas.stuefe at gmail.com Fri Jul 24 15:03:57 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 24 Jul 2020 17:03:57 +0200 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: <08BD40C5-D074-40F2-9C22-D36EB362D6FA@oracle.com> References: <08BD40C5-D074-40F2-9C22-D36EB362D6FA@oracle.com> Message-ID: Hi Kim, Okay, i understand. I?ll wait until we are at the right stage for discussing these changes. Thank you, Thomas On Fri 24. Jul 2020 at 11:42, Kim Barrett wrote: > > On Jul 23, 2020, at 7:00 AM, Thomas St?fe > wrote: > > > > (note: original mail was lost to us because of the hotspot-dev outage, > so I am answering to what I read in the ML archive: > https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/042247.html > ) > > Drat! That was exceptionally bad outage timing for this project. > > > Hi Kim, > > > > Thank you for your work, this is a good and clean read! And I also think > this was long overdue. > > Thanks. > > > I'd like to make an argument for using namespaces though. You write: [?] > > With this update to the Style Guide I've been mostly trying to > maintain the status quo (though with more explanation in some cases) > for existing usage. In this round I'm trying to limit changes to > > (1) an initial set of modifications describing C++11/14 usage, > (2) re-homing the document, and > (3) describing a process for updating it (which has been sorely lacking). > > As you read through this thread you'll have seen several places where > a desire for some change is noted but is not being addressed in this > set of changes. I'd like to do the same for namespaces. I'd be happy > to see a discussion about the use of namespaces once some version of > this document is in its new home and includes the initial C++14 stuff. > > > From Monica.Beckwith at microsoft.com Fri Jul 24 15:09:59 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Fri, 24 Jul 2020 15:09:59 +0000 Subject: RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC In-Reply-To: References: Message-ID: Hello all - could I please get feedback on the following changes? Copying clean links here again: JBS: https://bugs.openjdk.java.net/browse/JDK-8248663 Webrev: https://cr.openjdk.java.net/~mbeckwit/8248663/webrev.00/ Thanks, Monica -----Original Message----- From: Monica Beckwith Sent: Thursday, July 16, 2020 2:40 PM To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers Cc: openjdk-aarch64 Subject: RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC These changes are concerning specific macro names or keywords used by MSVC. E.g. `mvn,` `DIFFERENCE` and `far.` We are proposing to change those in the shared code. JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248663&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C35f78927e915431fbf4d08d829bfff9d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305251886976662&sdata=jGxT7lMPEEg7iJPgoflgEByvHnuZEof%2BBqPrGfQhulg%3D&reserved=0 Webrev: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~mbeckwit%2F8248663%2Fwebrev.00%2F&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C35f78927e915431fbf4d08d829bfff9d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305251886976662&sdata=28VwNHmLsoJcJRJ1OjBNH154%2BRB4QADUJHGz2Eh5M%2Bk%3D&reserved=0 Thanks, Monica From derekw at marvell.com Fri Jul 24 15:26:56 2020 From: derekw at marvell.com (Derek White) Date: Fri, 24 Jul 2020 15:26:56 +0000 Subject: RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC In-Reply-To: References: Message-ID: Hi Monica, Looks good! Style comment - I'm not sure if the comments about MSVC in c2_MacroAssembler_aarch64.cpp and macroAssembler_aarch64.hpp are strictly necessary, but I don't have a strong opinion. - Derek -----Original Message----- From: aarch64-port-dev On Behalf Of Monica Beckwith Sent: Friday, July 24, 2020 11:10 AM To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers Cc: openjdk-aarch64 Subject: [EXT] Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC External Email ---------------------------------------------------------------------- Hello all - could I please get feedback on the following changes? Copying clean links here again: JBS: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8248663&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=VRH-lUr10_r9nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc&s=-1BKo7dfMxAqI0c80NeOgXxY4Kig4HV6N_342REuHTc&e= Webrev: https://urldefense.proofpoint.com/v2/url?u=https-3A__cr.openjdk.java.net_-7Embeckwit_8248663_webrev.00_&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=VRH-lUr10_r9nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc&s=FDH2O5mbnaWupPL9AiRQqpDl1glFLtf1vP02BQvfmXM&e= Thanks, Monica -----Original Message----- From: Monica Beckwith Sent: Thursday, July 16, 2020 2:40 PM To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers Cc: openjdk-aarch64 Subject: RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC These changes are concerning specific macro names or keywords used by MSVC. E.g. `mvn,` `DIFFERENCE` and `far.` We are proposing to change those in the shared code. JBS: https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fbugs.openjdk.java.net-252Fbrowse-252FJDK-2D8248663-26amp-3Bdata-3D02-257C01-257CMonica.Beckwith-2540microsoft.com-257C35f78927e915431fbf4d08d829bfff9d-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637305251886976662-26amp-3Bsdata-3DjGxT7lMPEEg7iJPgoflgEByvHnuZEof-252BBqPrGfQhulg-253D-26amp-3Breserved-3D0&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=VRH-lUr10_r9nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc&s=6CkQlp-iwC2nuFgVxfwZjp0Kf9x-WqzQG-ksCF6H3eo&e= Webrev: https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-3A-252F-252Fcr.openjdk.java.net-252F-7Embeckwit-252F8248663-252Fwebrev.00-252F-26amp-3Bdata-3D02-257C01-257CMonica.Beckwith-2540microsoft.com-257C35f78927e915431fbf4d08d829bfff9d-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637305251886976662-26amp-3Bsdata-3D28VwNHmLsoJcJRJ1OjBNH154-252BRB4QADUJHGz2Eh5M-252Bk-253D-26amp-3Breserved-3D0&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=VRH-lUr10_r9nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc&s=FIrIXam-q51NnhIUlid_07RYh5O2xdtG6MHz_uSxCro&e= Thanks, Monica From ningsheng.jian at arm.com Thu Jul 23 08:02:47 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Thu, 23 Jul 2020 16:02:47 +0800 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com> <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com> <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com> Message-ID: Hi Vladimir, Thanks for pointing out this. Yes, I missed that change in shared code. I've regenerated the webrev, with GensrcAdlc.gmk file change included: http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ Also add build-dev. Thanks, Ningsheng On 7/23/20 5:36 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ > > > FTR there's one more aarch64-specific change in shared code to enable > aarch64_neon.ad processing: > > diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk > b/make/hotspot/gensrc/GensrcAdlc.gmk > --- a/make/hotspot/gensrc/GensrcAdlc.gmk > +++ b/make/hotspot/gensrc/GensrcAdlc.gmk > @@ -129,6 +129,12 @@ > > $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad > \ > ???? ))) > > +? ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64) > +??? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, > $(AD_SRC_ROOTS), \ > + $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \ > +??? ))) > +? endif > + > ?? ifeq ($(call check-jvm-feature, shenandoahgc), true) > ???? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, > $(AD_SRC_ROOTS), \ > > $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad > \ > > Best regards, > Vladimir Ivanov > >> On 7/8/20 3:05 PM, Yang Zhang wrote: >>> Hi Andrew >>> >>> I have updated this patch. Could you please help to review it again? >>> In this patch, the following changes are made: >>> 1. Separate newly added NEON instructions to a new ad file >>> ??? aarch64_neon.ad >>> 2. Add assembler tests for NEON instructions. Trailing spaces >>> ??? in the python script are also removed. >>> >>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ >>> >>> >>> Thanks, >>> Yang >>> >>> >>> -----Original Message----- >>> From: Andrew Haley >>> Sent: Tuesday, June 30, 2020 12:10 AM >>> To: Yang Zhang ; Viswanathan, Sandhya >>> ; Paul Sandoz >>> Cc: nd ; hotspot-compiler-dev at openjdk.java.net; >>> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; >>> aarch64-port-dev at openjdk.java.net >>> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of >>> Vector API (Incubator): AArch64 backend changes >>> >>> On 29/06/2020 08:48, Yang Zhang wrote: >>>> 1. Instructions that can be matched with NEON instructions directly. >>>> MulVB, SqrtVF and AbsV have been merged into jdk master already. >>>> >>>> 2. Instructions that jdk master has middle end support for, but they >>>> cannot be matched with NEON instructions directly. >>>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These >>>> new instructions can be moved into jdk master first, but for >>>> auto-vectorization, the performance might not get improved. >>>> >>>> 3. Panama/Vector API specific? instructions such as Load/StoreVector >>>> ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend >>>> etc. >>>> These instructions cannot be moved into jdk master first because >>>> there isn't middle-end support. >>>> >>>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also >>>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is >>>> ready, I will send it again. >>> >>> Thank you *very* much for your hard work. Appreciated! >>> >>> -- >>> Andrew Haley? (he/him) >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. https://keybase.io/andrewhaley >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>> >> From erik.joelsson at oracle.com Thu Jul 23 13:06:22 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 Jul 2020 06:06:22 -0700 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com> <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com> <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com> Message-ID: <2bc029fc-2823-18ac-9aa0-1a8edd7f9094@oracle.com> Hello Ningsheng, Build change looks good. /Erik On 2020-07-23 01:02, Ningsheng Jian wrote: > Hi Vladimir, > > Thanks for pointing out this. Yes, I missed that change in shared > code. I've regenerated the webrev, with GensrcAdlc.gmk file change > included: > > http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ > > > Also add build-dev. > > Thanks, > Ningsheng > > On 7/23/20 5:36 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ >> >> >> >> FTR there's one more aarch64-specific change in shared code to enable >> aarch64_neon.ad processing: >> >> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk >> b/make/hotspot/gensrc/GensrcAdlc.gmk >> --- a/make/hotspot/gensrc/GensrcAdlc.gmk >> +++ b/make/hotspot/gensrc/GensrcAdlc.gmk >> @@ -129,6 +129,12 @@ >> >> $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad >> \ >> ????? ))) >> >> +? ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64) >> +??? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, >> $(AD_SRC_ROOTS), \ >> + $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \ >> +??? ))) >> +? endif >> + >> ??? ifeq ($(call check-jvm-feature, shenandoahgc), true) >> ????? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, >> $(AD_SRC_ROOTS), \ >> >> $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad >> \ >> >> Best regards, >> Vladimir Ivanov >> >>> On 7/8/20 3:05 PM, Yang Zhang wrote: >>>> Hi Andrew >>>> >>>> I have updated this patch. Could you please help to review it again? >>>> In this patch, the following changes are made: >>>> 1. Separate newly added NEON instructions to a new ad file >>>> ??? aarch64_neon.ad >>>> 2. Add assembler tests for NEON instructions. Trailing spaces >>>> ??? in the python script are also removed. >>>> >>>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ >>>> >>>> >>>> Thanks, >>>> Yang >>>> >>>> >>>> -----Original Message----- >>>> From: Andrew Haley >>>> Sent: Tuesday, June 30, 2020 12:10 AM >>>> To: Yang Zhang ; Viswanathan, Sandhya >>>> ; Paul Sandoz >>>> Cc: nd ; hotspot-compiler-dev at openjdk.java.net; >>>> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; >>>> aarch64-port-dev at openjdk.java.net >>>> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of >>>> Vector API (Incubator): AArch64 backend changes >>>> >>>> On 29/06/2020 08:48, Yang Zhang wrote: >>>>> 1. Instructions that can be matched with NEON instructions directly. >>>>> MulVB, SqrtVF and AbsV have been merged into jdk master already. >>>>> >>>>> 2. Instructions that jdk master has middle end support for, but >>>>> they cannot be matched with NEON instructions directly. >>>>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These >>>>> new instructions can be moved into jdk master first, but for >>>>> auto-vectorization, the performance might not get improved. >>>>> >>>>> 3. Panama/Vector API specific? instructions such as >>>>> Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, >>>>> MaxV/MinV, VectorBlend etc. >>>>> These instructions cannot be moved into jdk master first because >>>>> there isn't middle-end support. >>>>> >>>>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also >>>>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is >>>>> ready, I will send it again. >>>> >>>> Thank you *very* much for your hard work. Appreciated! >>>> >>>> -- >>>> Andrew Haley? (he/him) >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. >>>> https://keybase.io/andrewhaley >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>> >>> > From serguei.spitsyn at oracle.com Fri Jul 24 20:28:18 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Jul 2020 13:28:18 -0700 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> <6f973a0a-cf55-e1ab-8de3-b57f68dbd2cf@oracle.com> Message-ID: <60098204-b23d-7da6-908f-80f3d40c2ebc@oracle.com> Hi Coleen, The fix looks good to me. I've more focused on the serviceability related update. Thank you for taking care about it! Thanks, Serguei On 7/24/20 06:10, coleen.phillimore at oracle.com wrote: > > I can also replace method_oop with method_ptr in the CPU ad files, and > this seems to build but now someone who knows the compiler area needs > to comment; this was supposed to be trivial... :)? But it still is > really trivial to look at. > > I left interpreter_method_oop_reg and compiler_method_oop_reg and > friends in opto/matcher.cpp for someone else. > > incremental webrev at > http://cr.openjdk.java.net/~coleenp/2020/8250042.02.incr/webrev > full webrev at http://cr.openjdk.java.net/~coleenp/2020/8250042.02/webrev > > Thanks, > Coleen > > > On 7/24/20 8:23 AM, coleen.phillimore at oracle.com wrote: >> >> Thanks for looking at this. >> >> On 7/24/20 1:01 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 24/07/2020 2:58 am, coleen.phillimore at oracle.com wrote: >>>> See bug for more details.? I've been running into these names a lot >>>> lately.?? Many of these names are in JVMTI. >>>> >>>> Tested with tier1 on all Oracle platforms and built on non-Oracle >>>> platforms. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8250042 >>> >>> src/hotspot/cpu/*/*.ad >>> >>> These still refer to "method oop" and method_oop in a number of places. >> >> Yes, I only replaced method_oop in the shared code and not in the AD >> code.? method_oop can be the name of a parameter and using "sed" to >> change it to "method" doesn't work.?? Somebody who understands this >> code and looks at it will have to make the rest of the changes. >> >> What I did was replace "method oop" with "method" and "methodOop" >> with "method" in all the sources.? I replaced "method_oop" with >> "method" or "checked_method" in the shared sources. >> >>> >>> src/hotspot/share/adlc/adlparse.cpp >>> >>> +? frame->_interpreter_method_oop_reg = parse_one_arg("method reg >>> entry"); >>> >>> I guess I'm not understanding the scope of this renaming - why is >>> _interpreter_method_oop_reg not renamed as well? Should this (and >>> other uses) be parsed as method-(oop-reg) rather than (method-oop)-reg? >> >> I don't know this code, so I'd rather not change any more of it. The >> comment makes sense changed, even though the variable name still >> refers to method_oop. >> >> Thanks, >> Coleen >>> >>> Otherwise all okay. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >> > From coleen.phillimore at oracle.com Fri Jul 24 22:20:23 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 24 Jul 2020 18:20:23 -0400 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: <60098204-b23d-7da6-908f-80f3d40c2ebc@oracle.com> References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> <6f973a0a-cf55-e1ab-8de3-b57f68dbd2cf@oracle.com> <60098204-b23d-7da6-908f-80f3d40c2ebc@oracle.com> Message-ID: <4232a089-3984-7feb-d2eb-46f1551ee0ab@oracle.com> On 7/24/20 4:28 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > The fix looks good to me. > I've more focused on the serviceability related update. > Thank you for taking care about it! Thank you for reviewing it!? Most of the name changes were in jvmti.? Hope it's cleaner to work on now. Coleen > > Thanks, > Serguei > > > On 7/24/20 06:10, coleen.phillimore at oracle.com wrote: >> >> I can also replace method_oop with method_ptr in the CPU ad files, >> and this seems to build but now someone who knows the compiler area >> needs to comment; this was supposed to be trivial... :)? But it still >> is really trivial to look at. >> >> I left interpreter_method_oop_reg and compiler_method_oop_reg and >> friends in opto/matcher.cpp for someone else. >> >> incremental webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8250042.02.incr/webrev >> full webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8250042.02/webrev >> >> Thanks, >> Coleen >> >> >> On 7/24/20 8:23 AM, coleen.phillimore at oracle.com wrote: >>> >>> Thanks for looking at this. >>> >>> On 7/24/20 1:01 AM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 24/07/2020 2:58 am, coleen.phillimore at oracle.com wrote: >>>>> See bug for more details.? I've been running into these names a >>>>> lot lately.?? Many of these names are in JVMTI. >>>>> >>>>> Tested with tier1 on all Oracle platforms and built on non-Oracle >>>>> platforms. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8250042 >>>> >>>> src/hotspot/cpu/*/*.ad >>>> >>>> These still refer to "method oop" and method_oop in a number of >>>> places. >>> >>> Yes, I only replaced method_oop in the shared code and not in the AD >>> code.? method_oop can be the name of a parameter and using "sed" to >>> change it to "method" doesn't work.?? Somebody who understands this >>> code and looks at it will have to make the rest of the changes. >>> >>> What I did was replace "method oop" with "method" and "methodOop" >>> with "method" in all the sources.? I replaced "method_oop" with >>> "method" or "checked_method" in the shared sources. >>> >>>> >>>> src/hotspot/share/adlc/adlparse.cpp >>>> >>>> +? frame->_interpreter_method_oop_reg = parse_one_arg("method reg >>>> entry"); >>>> >>>> I guess I'm not understanding the scope of this renaming - why is >>>> _interpreter_method_oop_reg not renamed as well? Should this (and >>>> other uses) be parsed as method-(oop-reg) rather than >>>> (method-oop)-reg? >>> >>> I don't know this code, so I'd rather not change any more of it. The >>> comment makes sense changed, even though the variable name still >>> refers to method_oop. >>> >>> Thanks, >>> Coleen >>>> >>>> Otherwise all okay. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Coleen >>> >> > From david.holmes at oracle.com Fri Jul 24 23:44:05 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 Jul 2020 09:44:05 +1000 Subject: RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC In-Reply-To: References: Message-ID: On 25/07/2020 1:26 am, Derek White wrote: > Hi Monica, > > Looks good! > > Style comment - I'm not sure if the comments about MSVC in c2_MacroAssembler_aarch64.cpp and macroAssembler_aarch64.hpp are strictly necessary, but I don't have a strong opinion. Agreed. Such comments explain a change but then lose all context. Thanks, David > - Derek > > -----Original Message----- > From: aarch64-port-dev On Behalf Of Monica Beckwith > Sent: Friday, July 24, 2020 11:10 AM > To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > Cc: openjdk-aarch64 > Subject: [EXT] Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC > > External Email > > ---------------------------------------------------------------------- > Hello all - could I please get feedback on the following changes? > > Copying clean links here again: > JBS: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8248663&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=VRH-lUr10_r9nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc&s=-1BKo7dfMxAqI0c80NeOgXxY4Kig4HV6N_342REuHTc&e= > Webrev: https://urldefense.proofpoint.com/v2/url?u=https-3A__cr.openjdk.java.net_-7Embeckwit_8248663_webrev.00_&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=VRH-lUr10_r9nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc&s=FDH2O5mbnaWupPL9AiRQqpDl1glFLtf1vP02BQvfmXM&e= > > Thanks, > Monica > > > -----Original Message----- > From: Monica Beckwith > Sent: Thursday, July 16, 2020 2:40 PM > To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > Cc: openjdk-aarch64 > Subject: RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC > > These changes are concerning specific macro names or keywords used by MSVC. E.g. `mvn,` `DIFFERENCE` and `far.` We are proposing to change those in the shared code. > > JBS: https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fbugs.openjdk.java.net-252Fbrowse-252FJDK-2D8248663-26amp-3Bdata-3D02-257C01-257CMonica.Beckwith-2540microsoft.com-257C35f78927e915431fbf4d08d829bfff9d-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637305251886976662-26amp-3Bsdata-3DjGxT7lMPEEg7iJPgoflgEByvHnuZEof-252BBqPrGfQhulg-253D-26amp-3Breserved-3D0&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=VRH-lUr10_r9nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc&s=6CkQlp-iwC2nuFgVxfwZjp0Kf9x-WqzQG-ksCF6H3eo&e= > Webrev: https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-3A-252F-252Fcr.openjdk.java.net-252F-7Embeckwit-252F8248663-252Fwebrev.00-252F-26amp-3Bdata-3D02-257C01-257CMonica.Beckwith-2540microsoft.com-257C35f78927e915431fbf4d08d829bfff9d-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637305251886976662-26amp-3Bsdata-3D28VwNHmLsoJcJRJ1OjBNH154-252BRB4QADUJHGz2Eh5M-252Bk-253D-26amp-3Breserved-3D0&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=VRH-lUr10_r9nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc&s=FIrIXam-q51NnhIUlid_07RYh5O2xdtG6MHz_uSxCro&e= > > Thanks, > Monica > From vladimir.kozlov at oracle.com Fri Jul 24 23:49:48 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jul 2020 16:49:48 -0700 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: <03A2E317-DE27-4E27-AB49-BA8DA6D143FA@oracle.com> References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> <03A2E317-DE27-4E27-AB49-BA8DA6D143FA@oracle.com> Message-ID: Thank you, Kim for very nice work. I agree to have it in jdk/jdk/doc which we can always reference and people can see. And also track all changes. *Structure and Formatting* I think ordering of sectin should by importance: naming rules and commenting are more important then spacing: . Factoring and Class Design . Files . Naming . Commenting . Macros . Whitespace . Miscellaneous May be next should be split into sub-paragraphs instead of one long paragraph: . Use bool for boolean values. - Do not use ints or pointers as (implicit) booleans with &&, ||, if, while. - Instead, compare explicitly, i.e. if (x != 0) or if (ptr != nullptr), etc. - Do not use declarations in condition forms, i.e. don't use if (T v = value) { ... }. *Use of C++ Features* I think enum, thread_local, nullptr, could be subsection of some new section which explicitly unite them. At first I mistakenly saw them as subsections of *C++ Standard Library* section. You did not say anything about preferable way of fields initialization in constructors to verify initialization order during compilation. We did refactoring before but new code may not follow it. What about C++ pragmas? Example of "new code should use integral constants"? I wish to see more embedded examples in this document but they can be added later. Thanks, Vladimir On 7/22/20 2:54 PM, Kim Barrett wrote: >> On Jul 11, 2020, at 10:56 AM, Kim Barrett wrote: >> >>> On Jun 23, 2020, at 3:32 PM, Kim Barrett wrote: >>> >>> Please review / comment on this proposed update to the HotSpot Style >>> Guide. This is part of the work for JDK-8208089: JEP 347: Adopt C++14 >>> Language Features in the JDK. >>> >>> [?] Once >>> reviewed, the finished text can be used to update the wiki, unless we >>> decide it should be homed somewhere else. >> >> There has recently been a lot of discussion about where this and >> somewhat similar documents should reside. Most of that has been about >> a Java Style Guide, which has somewhat different issues than this one. >> (The HotSpot Style Guide is very focused in scope, and is unlikely to >> have much, if any, influence on usage by the wider C++ community.) >> >> Proposed homes include: >> >> - Remain in the OpenJDK wiki. >> - Use an informational JEP. >> - Move to the new Developer's Guide. >> - Move to the JDK repository. >> >> For some of the discussion, see comments in JDK-8208089, as well as >> the recent thread on the jdk-dev mailing list: >> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004443.html >> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004461.html >> >> Based on that discussion, I'm planning to move it to the JDK >> repository, in jdk/jdk/doc. That is already a place for >> developer-focused documentation; it's the home of building.{md,html}, >> testing.{md,html}, and ide.{md,html}. I think this style guide fits >> well with that collection. >> >> I think the other two wiki pages associated with the current wiki >> HotSpot Style Guide would similarly fit well there, and I suggest we >> move them as well. >> >> Comments? > > I made a few formatting tweaks to account for using the approved > markdown processor (pandoc, via make update-build-docs); I'd been > using a different processor, and noticed some problems with the > generated html when I switched to using pandoc. > > I've also moved the files to jdk/jdk/doc. > > Reducing the heading "depths" made pandoc generate a nice TOC at the beginning. > > I removed the "===" separators, because pandoc wasn't producing a > horizontal line separator for them, unlike the previous (extended) > processor. > > There were some naked URLs that needed to be surrounded by <> to be > autolinked by pandoc, unlike the previous (extended) processor. > > New webrev: > full: https://cr.openjdk.java.net/~kbarrett/8247976/hotspot-style.03/ > incr: https://cr.openjdk.java.net/~kbarrett/8247976/hotspot-style.03.inc/ > > The diffs for the incremental .html aren't particularly interesting, > since different markdown processors were used to generate them. > > I'm intending to leave the move of the other two related wiki pages to later. > > Hopefully this is the last of this round of edits, though I'm > expecting there will soon be a number of requests for further changes > from this "baseline". > From kim.barrett at oracle.com Sat Jul 25 20:50:55 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 25 Jul 2020 16:50:55 -0400 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> <03A2E317-DE27-4E27-AB49-BA8DA6D143FA@oracle.com> Message-ID: <6F371114-F3A4-4016-8BD4-8C205BD10FED@oracle.com> > On Jul 24, 2020, at 7:49 PM, Vladimir Kozlov wrote: > > Thank you, Kim for very nice work. > > I agree to have it in jdk/jdk/doc which we can always reference and people can see. And also track all changes. Thanks. > *Structure and Formatting* > > I think ordering of sectin should by importance: naming rules and commenting are more important then spacing: Your suggested ordering seems better; done. > May be next should be split into sub-paragraphs instead of one long paragraph: > > . Use bool for boolean values. [?] I've reworded this and broken it up into a main bullet and sub-bullets. > *Use of C++ Features* > > I think enum, thread_local, nullptr, could be subsection of some new section which explicitly unite them. > At first I mistakenly saw them as subsections of *C++ Standard Library* section. I can see how that confusion could arise. I don't think those features need a new subsection (I'm not sure what I would call such anyway), as they really only differ from many of the others at the same level by using C++ identifiers or other syntax in the heading, and perhaps being a bit smaller in size. What I've done is reorder things so there are other, more obviously not Standard Library, subsections immediately following the Standard Library subsection. > You did not say anything about preferable way of fields initialization in constructors to verify initialization order during compilation. We did refactoring before but new code may not follow it. Preferring constructors use ctor-initializers would be a new guideline that would be good to have. But the work we did a while ago to ensure ctor-initializers are, and remain in, the proper order is enforced by having also enabled -Wreorder. I've added to my list a TODO item to follow up in this area. > What about C++ pragmas? Guidance on pragma and attribute usage would be another new guideline that would be good to have. I've added to my list a TODO item to follow up in this area. > Example of "new code should use integral constants"? > > I wish to see more embedded examples in this document but they can be added later. I?m leaving additional examples for future work. From david.holmes at oracle.com Mon Jul 27 01:26:31 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jul 2020 11:26:31 +1000 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> <6f973a0a-cf55-e1ab-8de3-b57f68dbd2cf@oracle.com> Message-ID: <8eab1729-9a35-8c79-65cf-e67a098965d5@oracle.com> Hi Coleen, On 24/07/2020 11:10 pm, coleen.phillimore at oracle.com wrote: > > I can also replace method_oop with method_ptr in the CPU ad files, and > this seems to build but now someone who knows the compiler area needs to > comment; this was supposed to be trivial... :)? But it still is really > trivial to look at. method_ptr works for me. Changes seem fine. > I left interpreter_method_oop_reg and compiler_method_oop_reg and > friends in opto/matcher.cpp for someone else. Okay. Hopefully someone will pick it up. Thanks, David ----- > incremental webrev at > http://cr.openjdk.java.net/~coleenp/2020/8250042.02.incr/webrev > full webrev at http://cr.openjdk.java.net/~coleenp/2020/8250042.02/webrev > > Thanks, > Coleen > > > On 7/24/20 8:23 AM, coleen.phillimore at oracle.com wrote: >> >> Thanks for looking at this. >> >> On 7/24/20 1:01 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 24/07/2020 2:58 am, coleen.phillimore at oracle.com wrote: >>>> See bug for more details.? I've been running into these names a lot >>>> lately.?? Many of these names are in JVMTI. >>>> >>>> Tested with tier1 on all Oracle platforms and built on non-Oracle >>>> platforms. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8250042 >>> >>> src/hotspot/cpu/*/*.ad >>> >>> These still refer to "method oop" and method_oop in a number of places. >> >> Yes, I only replaced method_oop in the shared code and not in the AD >> code.? method_oop can be the name of a parameter and using "sed" to >> change it to "method" doesn't work.?? Somebody who understands this >> code and looks at it will have to make the rest of the changes. >> >> What I did was replace "method oop" with "method" and "methodOop" with >> "method" in all the sources.? I replaced "method_oop" with "method" or >> "checked_method" in the shared sources. >> >>> >>> src/hotspot/share/adlc/adlparse.cpp >>> >>> +? frame->_interpreter_method_oop_reg = parse_one_arg("method reg >>> entry"); >>> >>> I guess I'm not understanding the scope of this renaming - why is >>> _interpreter_method_oop_reg not renamed as well? Should this (and >>> other uses) be parsed as method-(oop-reg) rather than (method-oop)-reg? >> >> I don't know this code, so I'd rather not change any more of it. The >> comment makes sense changed, even though the variable name still >> refers to method_oop. >> >> Thanks, >> Coleen >>> >>> Otherwise all okay. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >> > From ningsheng.jian at arm.com Mon Jul 27 01:58:38 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Mon, 27 Jul 2020 09:58:38 +0800 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <2bc029fc-2823-18ac-9aa0-1a8edd7f9094@oracle.com> References: <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com> <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com> <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com> <2bc029fc-2823-18ac-9aa0-1a8edd7f9094@oracle.com> Message-ID: <942c4be0-4f5d-acd6-86ae-e6769215ca37@arm.com> Thank you Erik! Regards, Ningsheng On 7/23/20 9:06 PM, Erik Joelsson wrote: > Hello Ningsheng, > > Build change looks good. > > /Erik > > On 2020-07-23 01:02, Ningsheng Jian wrote: >> Hi Vladimir, >> >> Thanks for pointing out this. Yes, I missed that change in shared >> code. I've regenerated the webrev, with GensrcAdlc.gmk file change >> included: >> >> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ >> >> >> Also add build-dev. >> >> Thanks, >> Ningsheng >> >> On 7/23/20 5:36 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ >>> >>> >>> >>> >>> FTR there's one more aarch64-specific change in shared code to enable >>> aarch64_neon.ad processing: >>> >>> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk >>> b/make/hotspot/gensrc/GensrcAdlc.gmk >>> --- a/make/hotspot/gensrc/GensrcAdlc.gmk >>> +++ b/make/hotspot/gensrc/GensrcAdlc.gmk >>> @@ -129,6 +129,12 @@ >>> >>> $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad >>> \ >>> ????? ))) >>> >>> +? ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64) >>> +??? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, >>> $(AD_SRC_ROOTS), \ >>> + $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \ >>> +??? ))) >>> +? endif >>> + >>> ??? ifeq ($(call check-jvm-feature, shenandoahgc), true) >>> ????? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, >>> $(AD_SRC_ROOTS), \ >>> >>> $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad >>> \ >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>> On 7/8/20 3:05 PM, Yang Zhang wrote: >>>>> Hi Andrew >>>>> >>>>> I have updated this patch. Could you please help to review it again? >>>>> In this patch, the following changes are made: >>>>> 1. Separate newly added NEON instructions to a new ad file >>>>> ??? aarch64_neon.ad >>>>> 2. Add assembler tests for NEON instructions. Trailing spaces >>>>> ??? in the python script are also removed. >>>>> >>>>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ >>>>> >>>>> >>>>> Thanks, >>>>> Yang >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Andrew Haley >>>>> Sent: Tuesday, June 30, 2020 12:10 AM >>>>> To: Yang Zhang ; Viswanathan, Sandhya >>>>> ; Paul Sandoz >>>>> Cc: nd ; hotspot-compiler-dev at openjdk.java.net; >>>>> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; >>>>> aarch64-port-dev at openjdk.java.net >>>>> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of >>>>> Vector API (Incubator): AArch64 backend changes >>>>> >>>>> On 29/06/2020 08:48, Yang Zhang wrote: >>>>>> 1. Instructions that can be matched with NEON instructions directly. >>>>>> MulVB, SqrtVF and AbsV have been merged into jdk master already. >>>>>> >>>>>> 2. Instructions that jdk master has middle end support for, but >>>>>> they cannot be matched with NEON instructions directly. >>>>>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These >>>>>> new instructions can be moved into jdk master first, but for >>>>>> auto-vectorization, the performance might not get improved. >>>>>> >>>>>> 3. Panama/Vector API specific? instructions such as >>>>>> Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, >>>>>> MaxV/MinV, VectorBlend etc. >>>>>> These instructions cannot be moved into jdk master first because >>>>>> there isn't middle-end support. >>>>>> >>>>>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also >>>>>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is >>>>>> ready, I will send it again. >>>>> >>>>> Thank you *very* much for your hard work. Appreciated! >>>>> >>>>> -- >>>>> Andrew Haley? (he/him) >>>>> Java Platform Lead Engineer >>>>> Red Hat UK Ltd. >>>>> https://keybase.io/andrewhaley >>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>>> >>>> >> From kim.barrett at oracle.com Mon Jul 27 05:47:57 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jul 2020 01:47:57 -0400 Subject: Result: New HotSpot Group Member: Stefan Johansson Message-ID: <0CA9FD9A-90EB-4932-B02C-777853A9BB67@oracle.com> The vote for Stefan Johansson [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 (There was also one invalid vote, cast by someone who is not a HotSpot Group Member.) According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Kim Barrett [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-July/042364.html From coleen.phillimore at oracle.com Mon Jul 27 13:05:40 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Jul 2020 09:05:40 -0400 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle Message-ID: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> Summary: Use synchronization to reference the _reference_pending_list with OopHandle Tested with tier1-6 with 100% passed (no other existing test failures!) open webrev at http://cr.openjdk.java.net/~coleenp/2020/8250589.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8250589 Thanks, Coleen From shade at redhat.com Mon Jul 27 13:21:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 Jul 2020 15:21:06 +0200 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> Message-ID: <4f390eb8-b5df-3a50-0583-a5e94686f79a@redhat.com> On 7/27/20 3:05 PM, coleen.phillimore at oracle.com wrote: > Summary: Use synchronization to reference the _reference_pending_list > with OopHandle > > Tested with tier1-6 with 100% passed (no other existing test failures!) > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8250589.01/webrev Looks okay, modulo these: *) I don't see a reason to put a comment to the otherwise generic method like this: 67 inline oop xchg(oop new_value); // needed for reference_pending_list *) The change below implicitly tests for NULL now? Seems like _reference_pending_list.peek() would be more efficient here, as it would not ask GC to keep the oop alive (especially when it is guaranteed to be already alive, right?). bool Universe::has_reference_pending_list() { assert_pll_ownership(); - return _reference_pending_list != NULL; + return _reference_pending_list.resolve(); } -- Thanks, -Aleksey From david.holmes at oracle.com Mon Jul 27 13:24:05 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jul 2020 23:24:05 +1000 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> Message-ID: Hi Coleen, On 27/07/2020 11:05 pm, coleen.phillimore at oracle.com wrote: > Summary: Use synchronization to reference the _reference_pending_list > with OopHandle Why isn't ownership of the Heap_lock sufficient for the synchronization any more? Thanks, David (and apologies as I'm done for the day so won't see your response till morning.) > Tested with tier1-6 with 100% passed (no other existing test failures!) > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8250589.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8250589 > > Thanks, > Coleen From coleen.phillimore at oracle.com Mon Jul 27 14:10:00 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Jul 2020 10:10:00 -0400 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> Message-ID: <1af7ad14-eb78-aca4-275c-44f5ba133a21@oracle.com> On 7/27/20 9:24 AM, David Holmes wrote: > Hi Coleen, > > On 27/07/2020 11:05 pm, coleen.phillimore at oracle.com wrote: >> Summary: Use synchronization to reference the _reference_pending_list >> with OopHandle > > Why isn't ownership of the Heap_lock sufficient for the > synchronization any more? Multiple GC threads synchronize on this value, when one holds the Heap_lock: ? // Reference pending list manipulation.? Access is protected by ? // Heap_lock.? The getter, setter and predicate require the caller ? // owns the lock.? Swap is used by parallel non-concurrent reference ? // processing threads, where some higher level controller owns ? // Heap_lock, so requires the lock is locked, but not necessarily by ? // the current thread. The comment is in the header file, explaining this. Thanks, Coleen > > Thanks, > David > > (and apologies as I'm done for the day so won't see your response till > morning.) > >> Tested with tier1-6 with 100% passed (no other existing test failures!) >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8250589.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8250589 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Mon Jul 27 14:10:43 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Jul 2020 10:10:43 -0400 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: <4f390eb8-b5df-3a50-0583-a5e94686f79a@redhat.com> References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> <4f390eb8-b5df-3a50-0583-a5e94686f79a@redhat.com> Message-ID: <92a4e6c6-c1cb-ba43-0982-6f87c8060d8e@oracle.com> On 7/27/20 9:21 AM, Aleksey Shipilev wrote: > On 7/27/20 3:05 PM, coleen.phillimore at oracle.com wrote: >> Summary: Use synchronization to reference the _reference_pending_list >> with OopHandle >> >> Tested with tier1-6 with 100% passed (no other existing test failures!) >> >> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8250589.01/webrev > Looks okay, modulo these: > > *) I don't see a reason to put a comment to the otherwise generic method like this: > > 67 inline oop xchg(oop new_value); // needed for reference_pending_list Ok, yes, I agree.? I'll remove it. > > *) The change below implicitly tests for NULL now? Seems like _reference_pending_list.peek() would > be more efficient here, as it would not ask GC to keep the oop alive (especially when it is > guaranteed to be already alive, right?). > > bool Universe::has_reference_pending_list() { > assert_pll_ownership(); > - return _reference_pending_list != NULL; > + return _reference_pending_list.resolve(); > } > This can be peek().? I'll change it. Thank you for reviewing this! Coleen From kim.barrett at oracle.com Mon Jul 27 17:08:37 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jul 2020 13:08:37 -0400 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: <92a4e6c6-c1cb-ba43-0982-6f87c8060d8e@oracle.com> References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> <4f390eb8-b5df-3a50-0583-a5e94686f79a@redhat.com> <92a4e6c6-c1cb-ba43-0982-6f87c8060d8e@oracle.com> Message-ID: <49EFF212-57D8-441E-9B14-CA79FFED93C4@oracle.com> > On Jul 27, 2020, at 10:10 AM, coleen.phillimore at oracle.com wrote: > On 7/27/20 9:21 AM, Aleksey Shipilev wrote: >> On 7/27/20 3:05 PM, coleen.phillimore at oracle.com wrote: >> *) The change below implicitly tests for NULL now? Seems like _reference_pending_list.peek() would >> be more efficient here, as it would not ask GC to keep the oop alive (especially when it is >> guaranteed to be already alive, right?). >> >> bool Universe::has_reference_pending_list() { >> assert_pll_ownership(); >> - return _reference_pending_list != NULL; >> + return _reference_pending_list.resolve(); >> } >> > This can be peek(). I'll change it. HotSpot Style Guide says not to use implicit conversions to bool. The ?!= NULL? was intentional and should be retained. From coleen.phillimore at oracle.com Mon Jul 27 17:28:25 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Jul 2020 13:28:25 -0400 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: <49EFF212-57D8-441E-9B14-CA79FFED93C4@oracle.com> References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> <4f390eb8-b5df-3a50-0583-a5e94686f79a@redhat.com> <92a4e6c6-c1cb-ba43-0982-6f87c8060d8e@oracle.com> <49EFF212-57D8-441E-9B14-CA79FFED93C4@oracle.com> Message-ID: <1b4e24e1-46f8-bf9b-17ec-6ca359f8f4e7@oracle.com> On 7/27/20 1:08 PM, Kim Barrett wrote: >> On Jul 27, 2020, at 10:10 AM, coleen.phillimore at oracle.com wrote: >> On 7/27/20 9:21 AM, Aleksey Shipilev wrote: >>> On 7/27/20 3:05 PM, coleen.phillimore at oracle.com wrote: >>> *) The change below implicitly tests for NULL now? Seems like _reference_pending_list.peek() would >>> be more efficient here, as it would not ask GC to keep the oop alive (especially when it is >>> guaranteed to be already alive, right?). >>> >>> bool Universe::has_reference_pending_list() { >>> assert_pll_ownership(); >>> - return _reference_pending_list != NULL; >>> + return _reference_pending_list.resolve(); >>> } >>> >> This can be peek(). I'll change it. > HotSpot Style Guide says not to use implicit conversions to bool. > The ?!= NULL? was intentional and should be retained. > Yes, thanks for catching that. Coleen From vladimir.kozlov at oracle.com Mon Jul 27 17:29:14 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jul 2020 10:29:14 -0700 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: <6F371114-F3A4-4016-8BD4-8C205BD10FED@oracle.com> References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> <03A2E317-DE27-4E27-AB49-BA8DA6D143FA@oracle.com> <6F371114-F3A4-4016-8BD4-8C205BD10FED@oracle.com> Message-ID: <46395675-d124-1efb-60e4-52dbd7dbaec6@oracle.com> On 7/25/20 1:50 PM, Kim Barrett wrote: >> On Jul 24, 2020, at 7:49 PM, Vladimir Kozlov wrote: >> >> Thank you, Kim for very nice work. >> >> I agree to have it in jdk/jdk/doc which we can always reference and people can see. And also track all changes. > > Thanks. > >> *Structure and Formatting* >> >> I think ordering of sectin should by importance: naming rules and commenting are more important then spacing: > > Your suggested ordering seems better; done. > >> May be next should be split into sub-paragraphs instead of one long paragraph: >> >> . Use bool for boolean values. [?] > > I've reworded this and broken it up into a main bullet and sub-bullets. > >> *Use of C++ Features* >> >> I think enum, thread_local, nullptr, could be subsection of some new section which explicitly unite them. >> At first I mistakenly saw them as subsections of *C++ Standard Library* section. > > I can see how that confusion could arise. I don't think those > features need a new subsection (I'm not sure what I would call such > anyway), as they really only differ from many of the others at the > same level by using C++ identifiers or other syntax in the heading, > and perhaps being a bit smaller in size. What I've done is reorder > things so there are other, more obviously not Standard Library, > subsections immediately following the Standard Library subsection. Yes, the reordering is fine too. > >> You did not say anything about preferable way of fields initialization in constructors to verify initialization order during compilation. We did refactoring before but new code may not follow it. > > Preferring constructors use ctor-initializers would be a new guideline > that would be good to have. But the work we did a while ago to ensure > ctor-initializers are, and remain in, the proper order is enforced by > having also enabled -Wreorder. I've added to my list a TODO item to > follow up in this area. > >> What about C++ pragmas? > > Guidance on pragma and attribute usage would be another new guideline > that would be good to have. I've added to my list a TODO item to > follow up in this area. > >> Example of "new code should use integral constants"? >> >> I wish to see more embedded examples in this document but they can be added later. > > I?m leaving additional examples for future work. Good. Yes, I agree that above things can be done after this initial work. Thanks, Vladimir From Charlie.Gracie at microsoft.com Mon Jul 27 19:24:19 2020 From: Charlie.Gracie at microsoft.com (Charlie Gracie) Date: Mon, 27 Jul 2020 19:24:19 +0000 Subject: Scoping the stack allocation prototype for C2 Message-ID: <96CC71B1-5FD1-4D6B-B3D1-ABC9C08E076D@microsoft.com> Hi Erik, > It sounds like the high level goal is not "allocate on the stack", but rather allocate and free objects > more efficiently based on compile-time knowledge about their scoped lifetime. Yes, you are correct. That is the best way to describe our high-level goal. > Since I can see so many advantages with this approach, and not really any disadvantages if done right, > I wonder if there are any clear reasons not to build it in that (general) way instead.I am curious to hear > your thoughts about this. > > If you agree this is probably a better way of achieving the same thing, then I have some ideas how > best to implement it that we could discuss. > But maybe we should settle on the direction first instead.Perhaps there are some nice quirks with > stack allocations that still make them more desirable, even though I can not currently see it. You have made excellent points about the pros and cons of both solutions, along with Vladimir and others. Taking all this information into account, we agree that the zone-based approach would satisfy our high-level goals without as many limitations as the stack based approach. > If you agree this is probably a better way of achieving the same thing, > then I have some ideas how best to implement it that we could discuss. We would appreciate hearing your ideas about how to best implement the zone-based solution. We are especially interested in your thoughts on how to get started with acquiring a zone and managing it. Having some guidance on the starting the zone-based approach would help us a lot. Thanks again for your insightful comments, Charlie & Nikola From david.holmes at oracle.com Mon Jul 27 23:06:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jul 2020 09:06:48 +1000 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: <1af7ad14-eb78-aca4-275c-44f5ba133a21@oracle.com> References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> <1af7ad14-eb78-aca4-275c-44f5ba133a21@oracle.com> Message-ID: <28799dd1-03ac-9076-66f5-d24922133e96@oracle.com> On 28/07/2020 12:10 am, coleen.phillimore at oracle.com wrote: > > > On 7/27/20 9:24 AM, David Holmes wrote: >> Hi Coleen, >> >> On 27/07/2020 11:05 pm, coleen.phillimore at oracle.com wrote: >>> Summary: Use synchronization to reference the _reference_pending_list >>> with OopHandle >> >> Why isn't ownership of the Heap_lock sufficient for the >> synchronization any more? > > Multiple GC threads synchronize on this value, when one holds the > Heap_lock: > > ? // Reference pending list manipulation.? Access is protected by > ? // Heap_lock.? The getter, setter and predicate require the caller > ? // owns the lock.? Swap is used by parallel non-concurrent reference > ? // processing threads, where some higher level controller owns > ? // Heap_lock, so requires the lock is locked, but not necessarily by > ? // the current thread. > > The comment is in the header file, explaining this. Sorry I completely fixated on the lock assertion and missed the fact the current code still does Atomic::xchg. The new code just internalises that in the OopHandle logic. (that will teach me to take too quick a look late at night) Kim and Aleksey already pointed out the only things I was going to point out. Looks good. Thanks, David > Thanks, > Coleen > >> >> Thanks, >> David >> >> (and apologies as I'm done for the day so won't see your response till >> morning.) >> >>> Tested with tier1-6 with 100% passed (no other existing test failures!) >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8250589.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8250589 >>> >>> Thanks, >>> Coleen > From kim.barrett at oracle.com Mon Jul 27 23:41:27 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jul 2020 19:41:27 -0400 Subject: RFC: 8247976: Update HotSpot Style Guide for C++14 adoption In-Reply-To: <46395675-d124-1efb-60e4-52dbd7dbaec6@oracle.com> References: <8973C296-B60B-4FAB-90F1-2474F4F19B23@oracle.com> <8FE9EBA7-FD0D-46AB-9C99-351D9A02885B@oracle.com> <03A2E317-DE27-4E27-AB49-BA8DA6D143FA@oracle.com> <6F371114-F3A4-4016-8BD4-8C205BD10FED@oracle.com> <46395675-d124-1efb-60e4-52dbd7dbaec6@oracle.com> Message-ID: <96B5D370-E113-4219-8F34-52FC4A681F65@oracle.com> > On Jul 27, 2020, at 1:29 PM, Vladimir Kozlov wrote: > > On 7/25/20 1:50 PM, Kim Barrett wrote: >>> On Jul 24, 2020, at 7:49 PM, Vladimir Kozlov wrote: >>> >>> Thank you, Kim for very nice work. >>> >>> I agree to have it in jdk/jdk/doc which we can always reference and people can see. And also track all changes. >> Thanks. >>> *Structure and Formatting* >>> >>> I think ordering of sectin should by importance: naming rules and commenting are more important then spacing: >> Your suggested ordering seems better; done. >>> May be next should be split into sub-paragraphs instead of one long paragraph: >>> >>> . Use bool for boolean values. [?] >> I've reworded this and broken it up into a main bullet and sub-bullets. >>> *Use of C++ Features* >>> >>> I think enum, thread_local, nullptr, could be subsection of some new section which explicitly unite them. >>> At first I mistakenly saw them as subsections of *C++ Standard Library* section. >> I can see how that confusion could arise. I don't think those >> features need a new subsection (I'm not sure what I would call such >> anyway), as they really only differ from many of the others at the >> same level by using C++ identifiers or other syntax in the heading, >> and perhaps being a bit smaller in size. What I've done is reorder >> things so there are other, more obviously not Standard Library, >> subsections immediately following the Standard Library subsection. > > Yes, the reordering is fine too. > >>> You did not say anything about preferable way of fields initialization in constructors to verify initialization order during compilation. We did refactoring before but new code may not follow it. >> Preferring constructors use ctor-initializers would be a new guideline >> that would be good to have. But the work we did a while ago to ensure >> ctor-initializers are, and remain in, the proper order is enforced by >> having also enabled -Wreorder. I've added to my list a TODO item to >> follow up in this area. >>> What about C++ pragmas? >> Guidance on pragma and attribute usage would be another new guideline >> that would be good to have. I've added to my list a TODO item to >> follow up in this area. >>> Example of "new code should use integral constants"? >>> >>> I wish to see more embedded examples in this document but they can be added later. >> I?m leaving additional examples for future work. > > Good. Yes, I agree that above things can be done after this initial work. > > Thanks, > Vladimir Thanks. From christian.hagedorn at oracle.com Tue Jul 28 07:31:41 2020 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Tue, 28 Jul 2020 09:31:41 +0200 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> <6f973a0a-cf55-e1ab-8de3-b57f68dbd2cf@oracle.com> Message-ID: <8c737ff0-7a62-d18d-78b2-b415802ebbdb@oracle.com> Hi Coleen On 24.07.20 15:10, coleen.phillimore at oracle.com wrote: > incremental webrev at > http://cr.openjdk.java.net/~coleenp/2020/8250042.02.incr/webrev > full webrev at http://cr.openjdk.java.net/~coleenp/2020/8250042.02/webrev Thanks for cleaning this up! The compiler changes look good to me. Just a minor comment (no new webrev required): - arm.ad:8873 & x86_32.ad:13321: There is an extra whitespace before ")" Best regards, Christian > Thanks, > Coleen > > > On 7/24/20 8:23 AM, coleen.phillimore at oracle.com wrote: >> >> Thanks for looking at this. >> >> On 7/24/20 1:01 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 24/07/2020 2:58 am, coleen.phillimore at oracle.com wrote: >>>> See bug for more details.? I've been running into these names a lot >>>> lately.?? Many of these names are in JVMTI. >>>> >>>> Tested with tier1 on all Oracle platforms and built on non-Oracle >>>> platforms. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8250042 >>> >>> src/hotspot/cpu/*/*.ad >>> >>> These still refer to "method oop" and method_oop in a number of places. >> >> Yes, I only replaced method_oop in the shared code and not in the AD >> code.? method_oop can be the name of a parameter and using "sed" to >> change it to "method" doesn't work.?? Somebody who understands this >> code and looks at it will have to make the rest of the changes. >> >> What I did was replace "method oop" with "method" and "methodOop" with >> "method" in all the sources.? I replaced "method_oop" with "method" or >> "checked_method" in the shared sources. >> >>> >>> src/hotspot/share/adlc/adlparse.cpp >>> >>> +? frame->_interpreter_method_oop_reg = parse_one_arg("method reg >>> entry"); >>> >>> I guess I'm not understanding the scope of this renaming - why is >>> _interpreter_method_oop_reg not renamed as well? Should this (and >>> other uses) be parsed as method-(oop-reg) rather than (method-oop)-reg? >> >> I don't know this code, so I'd rather not change any more of it. The >> comment makes sense changed, even though the variable name still >> refers to method_oop. >> >> Thanks, >> Coleen >>> >>> Otherwise all okay. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >> > From erik.osterlund at oracle.com Tue Jul 28 07:35:38 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 28 Jul 2020 09:35:38 +0200 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> Message-ID: <5c50dc61-f2b2-89a8-0d4b-bdfaff2c79f2@oracle.com> Looks good. Thanks, /Erik On 2020-07-27 15:05, coleen.phillimore at oracle.com wrote: > Summary: Use synchronization to reference the _reference_pending_list > with OopHandle > > Tested with tier1-6 with 100% passed (no other existing test failures!) > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8250589.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8250589 > > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Jul 28 11:20:50 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Jul 2020 07:20:50 -0400 Subject: RFR (T) 8250042: Clean up methodOop and method_oop names from the code In-Reply-To: <8c737ff0-7a62-d18d-78b2-b415802ebbdb@oracle.com> References: <85efc3ab-abbf-c5f2-9b7b-47fa516d9a2d@oracle.com> <6f973a0a-cf55-e1ab-8de3-b57f68dbd2cf@oracle.com> <8c737ff0-7a62-d18d-78b2-b415802ebbdb@oracle.com> Message-ID: <460241cc-7b49-b793-fa50-c12898d4b332@oracle.com> Hi, Thank you for reviewing the compiler changes. On 7/28/20 3:31 AM, Christian Hagedorn wrote: > Hi Coleen > > On 24.07.20 15:10, coleen.phillimore at oracle.com wrote: >> incremental webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8250042.02.incr/webrev >> full webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8250042.02/webrev > > Thanks for cleaning this up! The compiler changes look good to me. > > Just a minor comment (no new webrev required): > - arm.ad:8873 & x86_32.ad:13321: There is an extra whitespace before ")" Fixed! Thanks, Coleen > > Best regards, > Christian > >> Thanks, >> Coleen >> >> >> On 7/24/20 8:23 AM, coleen.phillimore at oracle.com wrote: >>> >>> Thanks for looking at this. >>> >>> On 7/24/20 1:01 AM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 24/07/2020 2:58 am, coleen.phillimore at oracle.com wrote: >>>>> See bug for more details.? I've been running into these names a >>>>> lot lately.?? Many of these names are in JVMTI. >>>>> >>>>> Tested with tier1 on all Oracle platforms and built on non-Oracle >>>>> platforms. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8250042 >>>> >>>> src/hotspot/cpu/*/*.ad >>>> >>>> These still refer to "method oop" and method_oop in a number of >>>> places. >>> >>> Yes, I only replaced method_oop in the shared code and not in the AD >>> code.? method_oop can be the name of a parameter and using "sed" to >>> change it to "method" doesn't work.?? Somebody who understands this >>> code and looks at it will have to make the rest of the changes. >>> >>> What I did was replace "method oop" with "method" and "methodOop" >>> with "method" in all the sources.? I replaced "method_oop" with >>> "method" or "checked_method" in the shared sources. >>> >>>> >>>> src/hotspot/share/adlc/adlparse.cpp >>>> >>>> +? frame->_interpreter_method_oop_reg = parse_one_arg("method reg >>>> entry"); >>>> >>>> I guess I'm not understanding the scope of this renaming - why is >>>> _interpreter_method_oop_reg not renamed as well? Should this (and >>>> other uses) be parsed as method-(oop-reg) rather than >>>> (method-oop)-reg? >>> >>> I don't know this code, so I'd rather not change any more of it. The >>> comment makes sense changed, even though the variable name still >>> refers to method_oop. >>> >>> Thanks, >>> Coleen >>>> >>>> Otherwise all okay. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Coleen >>> >> From coleen.phillimore at oracle.com Tue Jul 28 11:25:39 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Jul 2020 07:25:39 -0400 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: <5c50dc61-f2b2-89a8-0d4b-bdfaff2c79f2@oracle.com> References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> <5c50dc61-f2b2-89a8-0d4b-bdfaff2c79f2@oracle.com> Message-ID: <4f06989f-dde3-faa3-5928-084e871f83b9@oracle.com> Thanks Erik! Coleen On 7/28/20 3:35 AM, Erik ?sterlund wrote: > Looks good. > > Thanks, > /Erik > > On 2020-07-27 15:05, coleen.phillimore at oracle.com wrote: >> Summary: Use synchronization to reference the _reference_pending_list >> with OopHandle >> >> Tested with tier1-6 with 100% passed (no other existing test failures!) >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8250589.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8250589 >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Tue Jul 28 11:26:11 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Jul 2020 07:26:11 -0400 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: <28799dd1-03ac-9076-66f5-d24922133e96@oracle.com> References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> <1af7ad14-eb78-aca4-275c-44f5ba133a21@oracle.com> <28799dd1-03ac-9076-66f5-d24922133e96@oracle.com> Message-ID: <832989dd-4100-3abc-8123-7d4d62288733@oracle.com> Thanks David, Coleen On 7/27/20 7:06 PM, David Holmes wrote: > On 28/07/2020 12:10 am, coleen.phillimore at oracle.com wrote: >> >> >> On 7/27/20 9:24 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 27/07/2020 11:05 pm, coleen.phillimore at oracle.com wrote: >>>> Summary: Use synchronization to reference the >>>> _reference_pending_list with OopHandle >>> >>> Why isn't ownership of the Heap_lock sufficient for the >>> synchronization any more? >> >> Multiple GC threads synchronize on this value, when one holds the >> Heap_lock: >> >> ?? // Reference pending list manipulation.? Access is protected by >> ?? // Heap_lock.? The getter, setter and predicate require the caller >> ?? // owns the lock.? Swap is used by parallel non-concurrent reference >> ?? // processing threads, where some higher level controller owns >> ?? // Heap_lock, so requires the lock is locked, but not necessarily by >> ?? // the current thread. >> >> The comment is in the header file, explaining this. > > Sorry I completely fixated on the lock assertion and missed the fact > the current code still does Atomic::xchg. The new code just > internalises that in the OopHandle logic. (that will teach me to take > too quick a look late at night) > > Kim and Aleksey already pointed out the only things I was going to > point out. > > Looks good. > > Thanks, > David > >> Thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>> (and apologies as I'm done for the day so won't see your response >>> till morning.) >>> >>>> Tested with tier1-6 with 100% passed (no other existing test >>>> failures!) >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8250589.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8250589 >>>> >>>> Thanks, >>>> Coleen >> From kim.barrett at oracle.com Tue Jul 28 12:18:39 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Jul 2020 08:18:39 -0400 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: <1b4e24e1-46f8-bf9b-17ec-6ca359f8f4e7@oracle.com> References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> <4f390eb8-b5df-3a50-0583-a5e94686f79a@redhat.com> <92a4e6c6-c1cb-ba43-0982-6f87c8060d8e@oracle.com> <49EFF212-57D8-441E-9B14-CA79FFED93C4@oracle.com> <1b4e24e1-46f8-bf9b-17ec-6ca359f8f4e7@oracle.com> Message-ID: > On Jul 27, 2020, at 1:28 PM, coleen.phillimore at oracle.com wrote: > > > > On 7/27/20 1:08 PM, Kim Barrett wrote: >>> On Jul 27, 2020, at 10:10 AM, coleen.phillimore at oracle.com wrote: >>> On 7/27/20 9:21 AM, Aleksey Shipilev wrote: >>>> On 7/27/20 3:05 PM, coleen.phillimore at oracle.com wrote: >>>> *) The change below implicitly tests for NULL now? Seems like _reference_pending_list.peek() would >>>> be more efficient here, as it would not ask GC to keep the oop alive (especially when it is >>>> guaranteed to be already alive, right?). >>>> >>>> bool Universe::has_reference_pending_list() { >>>> assert_pll_ownership(); >>>> - return _reference_pending_list != NULL; >>>> + return _reference_pending_list.resolve(); >>>> } >>>> >>> This can be peek(). I'll change it. >> HotSpot Style Guide says not to use implicit conversions to bool. >> The ?!= NULL? was intentional and should be retained. >> > Yes, thanks for catching that. > Coleen Change is good with that fixed and the changes Aleksey suggested. From coleen.phillimore at oracle.com Tue Jul 28 12:24:51 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Jul 2020 08:24:51 -0400 Subject: RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle In-Reply-To: References: <82041da2-4a9d-455a-3c4b-e95deec30d4c@oracle.com> <4f390eb8-b5df-3a50-0583-a5e94686f79a@redhat.com> <92a4e6c6-c1cb-ba43-0982-6f87c8060d8e@oracle.com> <49EFF212-57D8-441E-9B14-CA79FFED93C4@oracle.com> <1b4e24e1-46f8-bf9b-17ec-6ca359f8f4e7@oracle.com> Message-ID: <6c829745-878a-aa46-633a-a69be52621f1@oracle.com> On 7/28/20 8:18 AM, Kim Barrett wrote: >> On Jul 27, 2020, at 1:28 PM, coleen.phillimore at oracle.com wrote: >> >> >> >> On 7/27/20 1:08 PM, Kim Barrett wrote: >>>> On Jul 27, 2020, at 10:10 AM, coleen.phillimore at oracle.com wrote: >>>> On 7/27/20 9:21 AM, Aleksey Shipilev wrote: >>>>> On 7/27/20 3:05 PM, coleen.phillimore at oracle.com wrote: >>>>> *) The change below implicitly tests for NULL now? Seems like _reference_pending_list.peek() would >>>>> be more efficient here, as it would not ask GC to keep the oop alive (especially when it is >>>>> guaranteed to be already alive, right?). >>>>> >>>>> bool Universe::has_reference_pending_list() { >>>>> assert_pll_ownership(); >>>>> - return _reference_pending_list != NULL; >>>>> + return _reference_pending_list.resolve(); >>>>> } >>>>> >>>> This can be peek(). I'll change it. >>> HotSpot Style Guide says not to use implicit conversions to bool. >>> The ?!= NULL? was intentional and should be retained. >>> >> Yes, thanks for catching that. >> Coleen > Change is good with that fixed and the changes Aleksey suggested. Thanks Kim, Coleen > From kim.barrett at oracle.com Tue Jul 28 12:34:28 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Jul 2020 08:34:28 -0400 Subject: RFR: 8250652: Add logical operations on types Message-ID: <7B7D96F2-212F-4842-A4A9-F2F2C1B521C5@oracle.com> Please review this change which adds metafunctions for performing logical operations on types. These are based on facilities provided by C++17, but which can be useful before we are using that version of the language standard. (I already have some in-development changes that use some of them.) I've not provided stand-ins for the associated template variables, since template variables are not yet on the list approved for use in HotSpot. They can easily be added later if desired. CR: https://bugs.openjdk.java.net/browse/JDK-8250652 Webrev: https://cr.openjdk.java.net/~kbarrett/8250652/open.00/ Testing: tier1 From neugens at redhat.com Tue Jul 28 12:55:28 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 28 Jul 2020 14:55:28 +0200 Subject: RFR: 8250670: TestJFRIntrinsic.java should be run with and without JFR to check the intrinsic properly Message-ID: Hi all, We noticed an interesting thing with TestJFRIntrinsic.java, if I understood the test correctly, it wants to check the behavior of the getEventWriter intrinsic, however it doesn't really do this, since JFR is always disabled when the test starts, the instance is always null. I changed the test slightly, first of all it's run twice now (actually 4 times, since it was already run twice before with different values of the TieredStopAtLevel option), one with and one without JFR, I also check that for the given combinations we get something resembling meaningful results. Here's the webrev: http://cr.openjdk.java.net/~neugens/8250670/ Any comments? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From erik.osterlund at oracle.com Tue Jul 28 13:52:52 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 28 Jul 2020 15:52:52 +0200 Subject: RFR: 8250652: Add logical operations on types In-Reply-To: <7B7D96F2-212F-4842-A4A9-F2F2C1B521C5@oracle.com> References: <7B7D96F2-212F-4842-A4A9-F2F2C1B521C5@oracle.com> Message-ID: Hi Kim, Looks good. Thanks, /Erik On 2020-07-28 14:34, Kim Barrett wrote: > Please review this change which adds metafunctions for performing > logical operations on types. These are based on facilities provided > by C++17, but which can be useful before we are using that version of > the language standard. (I already have some in-development changes > that use some of them.) > > I've not provided stand-ins for the associated template variables, > since template variables are not yet on the list approved for use in > HotSpot. They can easily be added later if desired. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8250652 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8250652/open.00/ > > Testing: > tier1 > > From igor.ignatyev at oracle.com Tue Jul 28 14:51:45 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 28 Jul 2020 07:51:45 -0700 Subject: [15] RFR(T) : 8250688 : missed open parenthesis for GTEST_FRAMEWORK_SRC var in Main.gmk Message-ID: <4B6D79EE-CC50-4089-BE5D-80393DAB424C@oracle.com> > 1 files changed, 1 insertions(+), 1 deletions(-) Hi all, could you please review the one-liner which fixes the typo introduced by 8245610? patch: > diff -r 31a8f79a7dfe make/Main.gmk > --- a/make/Main.gmk Tue Jul 28 10:32:57 2020 -0400 > +++ b/make/Main.gmk Tue Jul 28 07:50:42 2020 -0700 > @@ -664,7 +664,7 @@ > DEPS := build-test-hotspot-jtreg-graal, \ > )) > > -ifneq ($GTEST_FRAMEWORK_SRC), ) > +ifneq ($(GTEST_FRAMEWORK_SRC), ) > $(eval $(call SetupTarget, test-image-hotspot-gtest, \ > MAKEFILE := hotspot/test/GtestImage, \ > DEPS := hotspot, \ > JBS: https://bugs.openjdk.java.net/browse/JDK-8250688 8245610: https://bugs.openjdk.java.net/browse/JDK-8245610 Thanks, -- Igor From kim.barrett at oracle.com Tue Jul 28 14:53:03 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Jul 2020 10:53:03 -0400 Subject: RFR: 8250652: Add logical operations on types In-Reply-To: References: <7B7D96F2-212F-4842-A4A9-F2F2C1B521C5@oracle.com> Message-ID: <96B1A046-0D2C-4ED0-9AFD-0AA9A14CA388@oracle.com> > On Jul 28, 2020, at 9:52 AM, Erik ?sterlund wrote: > > Hi Kim, > > Looks good. Thanks. > Thanks, > /Erik > > On 2020-07-28 14:34, Kim Barrett wrote: >> Please review this change which adds metafunctions for performing >> logical operations on types. These are based on facilities provided >> by C++17, but which can be useful before we are using that version of >> the language standard. (I already have some in-development changes >> that use some of them.) >> >> I've not provided stand-ins for the associated template variables, >> since template variables are not yet on the list approved for use in >> HotSpot. They can easily be added later if desired. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8250652 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8250652/open.00/ >> >> Testing: >> tier1 From erik.joelsson at oracle.com Tue Jul 28 15:15:37 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 Jul 2020 08:15:37 -0700 Subject: [15] RFR(T) : 8250688 : missed open parenthesis for GTEST_FRAMEWORK_SRC var in Main.gmk In-Reply-To: <4B6D79EE-CC50-4089-BE5D-80393DAB424C@oracle.com> References: <4B6D79EE-CC50-4089-BE5D-80393DAB424C@oracle.com> Message-ID: <176753d7-469d-a17c-a37e-62226d1a2b18@oracle.com> Looks good. /Erik On 2020-07-28 07:51, Igor Ignatyev wrote: >> 1 files changed, 1 insertions(+), 1 deletions(-) > Hi all, > > could you please review the one-liner which fixes the typo introduced by 8245610? > > patch: >> diff -r 31a8f79a7dfe make/Main.gmk >> --- a/make/Main.gmk Tue Jul 28 10:32:57 2020 -0400 >> +++ b/make/Main.gmk Tue Jul 28 07:50:42 2020 -0700 >> @@ -664,7 +664,7 @@ >> DEPS := build-test-hotspot-jtreg-graal, \ >> )) >> >> -ifneq ($GTEST_FRAMEWORK_SRC), ) >> +ifneq ($(GTEST_FRAMEWORK_SRC), ) >> $(eval $(call SetupTarget, test-image-hotspot-gtest, \ >> MAKEFILE := hotspot/test/GtestImage, \ >> DEPS := hotspot, \ >> > > JBS: https://bugs.openjdk.java.net/browse/JDK-8250688 > 8245610: https://bugs.openjdk.java.net/browse/JDK-8245610 > > Thanks, > -- Igor From igor.ignatyev at oracle.com Tue Jul 28 16:10:55 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 28 Jul 2020 09:10:55 -0700 Subject: [15] RFR(T) : 8250688 : missed open parenthesis for GTEST_FRAMEWORK_SRC var in Main.gmk In-Reply-To: <176753d7-469d-a17c-a37e-62226d1a2b18@oracle.com> References: <4B6D79EE-CC50-4089-BE5D-80393DAB424C@oracle.com> <176753d7-469d-a17c-a37e-62226d1a2b18@oracle.com> Message-ID: <374945A4-CF5C-43A0-9AE3-EEEF0637EBD5@oracle.com> thanks Erik, pushed to jdk15. -- Igor > On Jul 28, 2020, at 8:15 AM, Erik Joelsson wrote: > > Looks good. > > /Erik > > On 2020-07-28 07:51, Igor Ignatyev wrote: >>> 1 files changed, 1 insertions(+), 1 deletions(-) >> Hi all, >> >> could you please review the one-liner which fixes the typo introduced by 8245610? >> >> patch: >>> diff -r 31a8f79a7dfe make/Main.gmk >>> --- a/make/Main.gmk Tue Jul 28 10:32:57 2020 -0400 >>> +++ b/make/Main.gmk Tue Jul 28 07:50:42 2020 -0700 >>> @@ -664,7 +664,7 @@ >>> DEPS := build-test-hotspot-jtreg-graal, \ >>> )) >>> -ifneq ($GTEST_FRAMEWORK_SRC), ) >>> +ifneq ($(GTEST_FRAMEWORK_SRC), ) >>> $(eval $(call SetupTarget, test-image-hotspot-gtest, \ >>> MAKEFILE := hotspot/test/GtestImage, \ >>> DEPS := hotspot, \ >>> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8250688 >> 8245610: https://bugs.openjdk.java.net/browse/JDK-8245610 >> >> Thanks, >> -- Igor From luhenry at microsoft.com Tue Jul 28 16:25:14 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Tue, 28 Jul 2020 16:25:14 +0000 Subject: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper In-Reply-To: <0707d751-da96-b316-fa52-b8159d2c5314@oracle.com> References: , <0707d751-da96-b316-fa52-b8159d2c5314@oracle.com> Message-ID: Hi Thomas, Kim, David, Could one of you please sponsor the change and merge it into jdk/jdk? Let me know of anything you need me to do to get it merged. Thank you Ludovic ________________________________________ From: hotspot-dev on behalf of Thomas Schatzl Sent: Friday, July 24, 2020 05:01 To: hotspot-dev at openjdk.java.net Subject: Re: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper Hi, On 21.07.20 21:17, Ludovic Henry wrote: > Hello, > > Simple code cleanup to use existing ATTRIBUTE_ALIGNED macro in src/hotspot/cpu/aarch64. > > JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248682&data=02%7C01%7Cluhenry%40microsoft.com%7C03b4e13002874e86ab2108d82fc96177%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637311889252388951&sdata=6%2FzjhW9W07c9xy0hrPUZ3KboLPPWbR4f6w7gapF7RBs%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fluhenry%2F8248682%2Fwebrev.00&data=02%7C01%7Cluhenry%40microsoft.com%7C03b4e13002874e86ab2108d82fc96177%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637311889252388951&sdata=b%2BV7Cy1uy5XADX8%2BGmynD1IHmZ%2FO34gDtEuAQ%2BD4DfE%3D&reserved=0 > > Testing: jtreg:test/hotspot/jtreg:tier1, jtreg:test/jdk:tier1, jtreg:test/jdk:tier2, jtreg:test/langtools, on Windows-AArch64 and Linux-AArch64. > > Thank you, > > -- > Ludovic > lgtm. Thomas From vladimir.x.ivanov at oracle.com Tue Jul 28 22:09:54 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Jul 2020 01:09:54 +0300 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): Hotspot and x86 backend changes In-Reply-To: References: Message-ID: > Shared Hotspot: > Full: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/hs_webrev/webrev.01/ > Incremental: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/hs_webrev/webrev.00-webrev.01/ FTR here are the latest changes in HotSpot shared code: http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01 Incremental changes: http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00 Best regards, Vladimir Ivanov > Older webrev links for your reference: > Shared Hotspot: http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/ From vladimir.x.ivanov at oracle.com Tue Jul 28 22:29:41 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Jul 2020 01:29:41 +0300 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes In-Reply-To: References: Message-ID: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> Hi, Thanks for the feedback on webrev.00, Remi, Coleen, Vladimir K., and Ekaterina! Here are the latest changes for Vector API support in HotSpot shared code: http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01 Incremental changes (diff against webrev.00): http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00 I decided to post it here and not initiate a new round of reviews because the changes are mostly limited to minor cleanups / simple bug fixes. Detailed summary: - rebased to jdk/jdk tip; - got rid of NotV, VLShiftV, VRShiftV, VURShiftV nodes; - restore lazy cleanup logic during incremental inlining (see needs_cleanup in compile.cpp); - got rid of x86-specific changes in shared code; - fix for 8244867 [1]; - fix Graal test failure: enumerate VectorSupport intrinsics in CheckGraalIntrinsics - numerous minor cleanups Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/dcfc7b6e8977 http://jbs.oracle.com/browse/JDK-8244867 8244867: 2 vector api tests crash with assert(is_reference_type(basic_type())) failed: wrong type Summary: Adding safety checks to prevent intrinsification if class arguments of non-primitive types are uninitialized. On 04.04.2020 02:12, Vladimir Ivanov wrote: > Hi, > > Following up on review requests of API [0] and Java implementation [1] > for Vector API (JEP 338 [2]), here's a request for review of general > HotSpot changes (in shared code) required for supporting the API: > > > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/all.00-03/ > > > (First of all, to set proper expectations: since the JEP is still in > Candidate state, the intention is to initiate preliminary round(s) of > review to inform the community and gather feedback before sending out > final/official RFRs once the JEP is Targeted to a release.) > > Vector API (being developed in Project Panama [3]) relies on JVM support > to utilize optimal vector hardware instructions at runtime. It interacts > with JVM through intrinsics (declared in > jdk.internal.vm.vector.VectorSupport [4]) which expose vector operations > support in C2 JIT-compiler. > > As Paul wrote earlier: "A vector intrinsic is an internal low-level > vector operation. The last argument to the intrinsic is fall back > behavior in Java, implementing the scalar operation over the number of > elements held by the vector.? Thus, If the intrinsic is not supported in > C2 for the other arguments then the Java implementation is executed (the > Java implementation is always executed when running in the interpreter > or for C1)." > > The rest of JVM support is about aggressively optimizing vector boxes to > minimize (ideally eliminate) the overhead of boxing for vector values. > It's a stop-the-gap solution for vector box elimination problem until > inline classes arrive. Vector classes are value-based and in the longer > term will be migrated to inline classes once the support becomes available. > > Vector API talk from JVMLS'18 [5] contains brief overview of JVM > implementation and some details. > > Complete implementation resides in vector-unstable branch of panama/dev > repository [6]. > > Now to gory details (the patch is split in multiple "sub-webrevs"): > > =========================================================== > > (1) > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/00.backend.shared/ > > > Ideal vector nodes for new operations introduced by Vector API. > > (Platform-specific back end support will be posted for review separately). > > =========================================================== > > (2) > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/ > > > JVM Java interface (VectorSupport) and intrinsic support in C2. > > Vector instances are initially represented as VectorBox macro nodes and > "unboxing" is represented by VectorUnbox node. It simplifies vector box > elimination analysis and the nodes are expanded later right before EA pass. > > Vectors have 2-level on-heap representation: for the vector value > primitive array is used as a backing storage and it is encapsulated in a > typed wrapper (e.g., Int256Vector - vector of 8 ints - contains a int[8] > instance which is used to store vector value). > > Unless VectorBox node goes away, it needs to be expanded into an > allocation eventually, but it is a pure node and doesn't have any JVM > state associated with it. The problem is solved by keeping JVM state > separately in a VectorBoxAllocate node associated with VectorBox node > and use it during expansion. > > Also, to simplify vector box elimination, inlining of vector reboxing > calls (VectorSupport::maybeRebox) is delayed until the analysis is over. > > =========================================================== > > (3) > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/02.vbox_elimination/ > > > Vector box elimination analysis implementation. (Brief overview: slides > #36-42 [5].) > > The main part is devoted to scalarization across safepoints and > rematerialization support during deoptimization. In C2-generated code > vector operations work with raw vector values which live in registers or > spilled on the stack and it allows to avoid boxing/unboxing when a > vector value is alive across a safepoint. As with other values, there's > just a location of the vector value at the safepoint and vector type > information recorded in the relevant nmethod metadata and all the > heavy-lifting happens only when rematerialization takes place. > > The analysis preserves object identity invariants except during > aggressive reboxing (guarded by -XX:+EnableAggressiveReboxing). > > (Aggressive reboxing is crucial for cases when vectors "escape": it > allocates a fresh instance at every escape point thus enabling original > instance to go away.) > > =========================================================== > > (4) > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/03.module.hotspot/ > > > HotSpot changes for jdk.incubator.vector module. Vector support is > makred experimental and turned off by default. JEP 338 proposes the API > to be released as an incubator module, so a user has to specify > "--add-module jdk.incubator.vector" on the command line to be able to > use it. > When user does that, JVM automatically enables Vector API support. > It improves usability (user doesn't need to separately "open" the API > and enable JVM support) while minimizing risks of destabilitzation from > new code when the API is not used. > > > That's it! Will be happy to answer any questions. > > And thanks in advance for any feedback! > > Best regards, > Vladimir Ivanov > > [0] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html > > > [1] > https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041228.html > > [2] https://openjdk.java.net/jeps/338 > > [3] https://openjdk.java.net/projects/panama/ > > [4] > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java.html > > > [5] http://cr.openjdk.java.net/~vlivanov/talks/2018_JVMLS_VectorAPI.pdf > > [6] http://hg.openjdk.java.net/panama/dev/shortlog/92bbd44386e9 > > ??? $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable From richard.reingruber at sap.com Wed Jul 29 07:51:43 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 29 Jul 2020 07:51:43 +0000 Subject: Scoping the stack allocation prototype for C2 In-Reply-To: <96CC71B1-5FD1-4D6B-B3D1-ABC9C08E076D@microsoft.com> References: <96CC71B1-5FD1-4D6B-B3D1-ABC9C08E076D@microsoft.com> Message-ID: Hi, an even simpler optimization could be to find allocations that don't escape a loop body, schedule them into a dominating region and reuse the allocated bytes in the loop body. This would be possible without special allocation zones/buffers. At first glance this seems to be comparatively simple, but still effective. Again a lot would depend on inlining: will hot allocations be compiled together with their loop? And I'd think that there have to be hot allocations in the benchmark for stack allocation to be beneficial. If they are not hot then young gen allocation/reclamation are probably good enough. Maybe the allocation could even be undone after the loop if there was no escaping allocation in the loop. I guess this is the downside: no implicit free when the compiled method returns. Best regards, Richard. -----Original Message----- From: hotspot-dev On Behalf Of Charlie Gracie Sent: Montag, 27. Juli 2020 21:24 To: Erik ?sterlund ; Nikola Grcevski ; hotspot-dev Source Developers Subject: Re: Re: Scoping the stack allocation prototype for C2 Hi Erik, > It sounds like the high level goal is not "allocate on the stack", but rather allocate and free objects > more efficiently based on compile-time knowledge about their scoped lifetime. Yes, you are correct. That is the best way to describe our high-level goal. > Since I can see so many advantages with this approach, and not really any disadvantages if done right, > I wonder if there are any clear reasons not to build it in that (general) way instead.I am curious to hear > your thoughts about this. > > If you agree this is probably a better way of achieving the same thing, then I have some ideas how > best to implement it that we could discuss. > But maybe we should settle on the direction first instead.Perhaps there are some nice quirks with > stack allocations that still make them more desirable, even though I can not currently see it. You have made excellent points about the pros and cons of both solutions, along with Vladimir and others. Taking all this information into account, we agree that the zone-based approach would satisfy our high-level goals without as many limitations as the stack based approach. > If you agree this is probably a better way of achieving the same thing, > then I have some ideas how best to implement it that we could discuss. We would appreciate hearing your ideas about how to best implement the zone-based solution. We are especially interested in your thoughts on how to get started with acquiring a zone and managing it. Having some guidance on the starting the zone-based approach would help us a lot. Thanks again for your insightful comments, Charlie & Nikola From david.holmes at oracle.com Wed Jul 29 09:33:52 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jul 2020 19:33:52 +1000 Subject: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper In-Reply-To: References: <0707d751-da96-b316-fa52-b8159d2c5314@oracle.com> Message-ID: <88772db0-5a88-16df-8c91-52d97a583c0d@oracle.com> Hi Ludovic, I will sponsor this one too (13 hours from now) unless someone gets there first. Cheers, David On 29/07/2020 2:25 am, Ludovic Henry wrote: > Hi Thomas, Kim, David, > > Could one of you please sponsor the change and merge it into jdk/jdk? Let me know of anything you need me to do to get it merged. > > Thank you > Ludovic > > ________________________________________ > From: hotspot-dev on behalf of Thomas Schatzl > Sent: Friday, July 24, 2020 05:01 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper > > Hi, > > On 21.07.20 21:17, Ludovic Henry wrote: >> Hello, >> >> Simple code cleanup to use existing ATTRIBUTE_ALIGNED macro in src/hotspot/cpu/aarch64. >> >> JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248682&data=02%7C01%7Cluhenry%40microsoft.com%7C03b4e13002874e86ab2108d82fc96177%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637311889252388951&sdata=6%2FzjhW9W07c9xy0hrPUZ3KboLPPWbR4f6w7gapF7RBs%3D&reserved=0 >> Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fluhenry%2F8248682%2Fwebrev.00&data=02%7C01%7Cluhenry%40microsoft.com%7C03b4e13002874e86ab2108d82fc96177%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637311889252388951&sdata=b%2BV7Cy1uy5XADX8%2BGmynD1IHmZ%2FO34gDtEuAQ%2BD4DfE%3D&reserved=0 >> >> Testing: jtreg:test/hotspot/jtreg:tier1, jtreg:test/jdk:tier1, jtreg:test/jdk:tier2, jtreg:test/langtools, on Windows-AArch64 and Linux-AArch64. >> >> Thank you, >> >> -- >> Ludovic >> > > lgtm. > > Thomas > From aph at redhat.com Wed Jul 29 11:44:50 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Jul 2020 12:44:50 +0100 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com> <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com> Message-ID: <852a3a09-a627-c0fc-89c6-8c8100ae17f5@redhat.com> On 20/07/2020 04:51, Ningsheng Jian wrote: > Since we are getting ready to propose Vector API target to JDK 16 [1]. I > have regenerated webrev of aarch64 backend parts from panama repo, which > has been rebased to jdk/jdk very recently, by: > > $ hg update vector-unstable && hg diff -r default > all.patch > $ grep "diff -r" all.patch | grep -e "src/hotspot/cpu/aarch64" | awk > '{print $4}' > aarch64_list > $ ksh ./webrev.ksh -r default -o aarch64_webrev aarch64_list > > The new webrev: > http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ > > Could you please help to take a look? OK, thanks. It all looks fine. Sorry for the delay. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From luhenry at microsoft.com Wed Jul 29 13:49:40 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Wed, 29 Jul 2020 13:49:40 +0000 Subject: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper In-Reply-To: <88772db0-5a88-16df-8c91-52d97a583c0d@oracle.com> References: <0707d751-da96-b316-fa52-b8159d2c5314@oracle.com> , <88772db0-5a88-16df-8c91-52d97a583c0d@oracle.com> Message-ID: Hi David, Thank you, greatly appreciated! ________________________________________ From: David Holmes Sent: Wednesday, July 29, 2020 02:33 To: Ludovic Henry; Thomas Schatzl; hotspot-dev at openjdk.java.net Subject: Re: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper Hi Ludovic, I will sponsor this one too (13 hours from now) unless someone gets there first. Cheers, David On 29/07/2020 2:25 am, Ludovic Henry wrote: > Hi Thomas, Kim, David, > > Could one of you please sponsor the change and merge it into jdk/jdk? Let me know of anything you need me to do to get it merged. > > Thank you > Ludovic > > ________________________________________ > From: hotspot-dev on behalf of Thomas Schatzl > Sent: Friday, July 24, 2020 05:01 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper > > Hi, > > On 21.07.20 21:17, Ludovic Henry wrote: >> Hello, >> >> Simple code cleanup to use existing ATTRIBUTE_ALIGNED macro in src/hotspot/cpu/aarch64. >> >> JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248682&data=02%7C01%7Cluhenry%40microsoft.com%7C17347e036dd248d28ce308d833a288df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316120459818538&sdata=gmIJxBY7%2Bv%2FnroYGanqd20Of0rJCQhL5ENYAiCDX8mw%3D&reserved=0 >> Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fluhenry%2F8248682%2Fwebrev.00&data=02%7C01%7Cluhenry%40microsoft.com%7C17347e036dd248d28ce308d833a288df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316120459818538&sdata=6PPEWUB4%2Fe0exWCNu1DLi0hyUiLeipY340O5lYY4FWU%3D&reserved=0 >> >> Testing: jtreg:test/hotspot/jtreg:tier1, jtreg:test/jdk:tier1, jtreg:test/jdk:tier2, jtreg:test/langtools, on Windows-AArch64 and Linux-AArch64. >> >> Thank you, >> >> -- >> Ludovic >> > > lgtm. > > Thomas > From coleen.phillimore at oracle.com Wed Jul 29 15:54:03 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Jul 2020 11:54:03 -0400 Subject: RFR 8249837: Avoid direct or implicit Thread::current() calls when we already have a current thread variable Message-ID: <3fa4d408-7096-d405-1f1a-98329a21d77d@oracle.com> Summary: Add current thread and/or moved HandleMark to the scope that it is needed This patch removes HandleMarks from the GC code.? I added a NoHandleMark to these places and found the locations in the verification code that needs the HandleMarks, and moved them there. Tested with tier1-6 with no failures. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249837.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8249837 Thanks, Coleen From coleen.phillimore at oracle.com Wed Jul 29 16:13:09 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Jul 2020 12:13:09 -0400 Subject: RFR 8249837: Avoid direct or implicit Thread::current() calls when we already have a current thread variable In-Reply-To: <3fa4d408-7096-d405-1f1a-98329a21d77d@oracle.com> References: <3fa4d408-7096-d405-1f1a-98329a21d77d@oracle.com> Message-ID: On 7/29/20 11:54 AM, coleen.phillimore at oracle.com wrote: > Summary: Add current thread and/or moved HandleMark to the scope that > it is needed > > This patch removes HandleMarks from the GC code.? I added a > NoHandleMark to these places and found the locations in the > verification code that needs the HandleMarks, and moved them there. Also Universe::verify() already has a HandleMark, so these are removed from the GC code also. > > Tested with tier1-6 with no failures. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249837.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8249837 > > Thanks, > Coleen From vladimir.kozlov at oracle.com Wed Jul 29 17:00:10 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jul 2020 10:00:10 -0700 Subject: RFR 8249837: Avoid direct or implicit Thread::current() calls when we already have a current thread variable In-Reply-To: <3fa4d408-7096-d405-1f1a-98329a21d77d@oracle.com> References: <3fa4d408-7096-d405-1f1a-98329a21d77d@oracle.com> Message-ID: <662892e6-f63a-7089-604b-764f0fdc6e6b@oracle.com> Compiler and jvmci code change slooks good. Thanks, Vladimir K On 7/29/20 8:54 AM, coleen.phillimore at oracle.com wrote: > Summary: Add current thread and/or moved HandleMark to the scope that it is needed > > This patch removes HandleMarks from the GC code.? I added a NoHandleMark to these places and found the locations in the > verification code that needs the HandleMarks, and moved them there. > > Tested with tier1-6 with no failures. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249837.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8249837 > > Thanks, > Coleen From hohensee at amazon.com Wed Jul 29 17:37:07 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 29 Jul 2020 17:37:07 +0000 Subject: FW: [Mach5] mach5-one-phh-JDK-8215624-1-20200729-1619-13017115: FAILED Message-ID: <724611F1-3AA3-4E3D-8878-BF2D8381799B@amazon.com> Hi, Can someone tell me what the below error message means? I?ve successfully done multiple slowdebug builds on my Mac. Thanks, Paul From: on behalf of "do-not-reply at oracle.com" Reply-To: "mach5_admin_ww_grp at oracle.com" Date: Wednesday, July 29, 2020 at 10:24 AM To: "Hohensee, Paul" Subject: [Mach5] mach5-one-phh-JDK-8215624-1-20200729-1619-13017115: FAILED Job: mach5-one-phh-JDK-8215624-1-20200729-1619-13017115 BuildId: 2020-07-29-1618311.hohensee.source No failed tests Tasks Summary * NA: 0 * HARNESS_ERROR: 0 * FAILED: 1 * PASSED: 102 * NOTHING_TO_RUN: 0 * UNABLE_TO_RUN: 0 * KILLED: 0 * EXECUTED_WITH_FAILURE: 0 Build 1 Failed * macosx-x64-open-debug-macosx-x64-build-14 SOURCE_MASTER REASON_SLAVE_RE...d: a new agent registered at the same address From sandhya.viswanathan at intel.com Wed Jul 29 18:19:14 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Wed, 29 Jul 2020 18:19:14 +0000 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes In-Reply-To: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> References: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> Message-ID: Hi, Likewise, the corresponding x86 backend changes since first review are also only minor cleanups and simple bug fixes: X86: Full: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.01/ Incremental: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00-webrev.01/ Summary: - rebased to jdk/jdk tip; - backend changes related to removal of NotV, VLShiftV, VRShiftV, VURShiftV nodes; - vector insert bug fix - some minor cleanups Older webrev links for your reference: X86b backend: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ Best Regards, Sandhya -----Original Message----- From: Vladimir Ivanov Sent: Tuesday, July 28, 2020 3:30 PM To: hotspot-dev ; hotspot compiler Cc: Viswanathan, Sandhya ; panama-dev Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes Hi, Thanks for the feedback on webrev.00, Remi, Coleen, Vladimir K., and Ekaterina! Here are the latest changes for Vector API support in HotSpot shared code: http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01 Incremental changes (diff against webrev.00): http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00 I decided to post it here and not initiate a new round of reviews because the changes are mostly limited to minor cleanups / simple bug fixes. Detailed summary: - rebased to jdk/jdk tip; - got rid of NotV, VLShiftV, VRShiftV, VURShiftV nodes; - restore lazy cleanup logic during incremental inlining (see needs_cleanup in compile.cpp); - got rid of x86-specific changes in shared code; - fix for 8244867 [1]; - fix Graal test failure: enumerate VectorSupport intrinsics in CheckGraalIntrinsics - numerous minor cleanups Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/dcfc7b6e8977 http://jbs.oracle.com/browse/JDK-8244867 8244867: 2 vector api tests crash with assert(is_reference_type(basic_type())) failed: wrong type Summary: Adding safety checks to prevent intrinsification if class arguments of non-primitive types are uninitialized. On 04.04.2020 02:12, Vladimir Ivanov wrote: > Hi, > > Following up on review requests of API [0] and Java implementation [1] > for Vector API (JEP 338 [2]), here's a request for review of general > HotSpot changes (in shared code) required for supporting the API: > > > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar > ed/webrev.00/all.00-03/ > > > (First of all, to set proper expectations: since the JEP is still in > Candidate state, the intention is to initiate preliminary round(s) of > review to inform the community and gather feedback before sending out > final/official RFRs once the JEP is Targeted to a release.) > > Vector API (being developed in Project Panama [3]) relies on JVM > support to utilize optimal vector hardware instructions at runtime. It > interacts with JVM through intrinsics (declared in > jdk.internal.vm.vector.VectorSupport [4]) which expose vector > operations support in C2 JIT-compiler. > > As Paul wrote earlier: "A vector intrinsic is an internal low-level > vector operation. The last argument to the intrinsic is fall back > behavior in Java, implementing the scalar operation over the number of > elements held by the vector.? Thus, If the intrinsic is not supported > in > C2 for the other arguments then the Java implementation is executed > (the Java implementation is always executed when running in the > interpreter or for C1)." > > The rest of JVM support is about aggressively optimizing vector boxes > to minimize (ideally eliminate) the overhead of boxing for vector values. > It's a stop-the-gap solution for vector box elimination problem until > inline classes arrive. Vector classes are value-based and in the > longer term will be migrated to inline classes once the support becomes available. > > Vector API talk from JVMLS'18 [5] contains brief overview of JVM > implementation and some details. > > Complete implementation resides in vector-unstable branch of > panama/dev repository [6]. > > Now to gory details (the patch is split in multiple "sub-webrevs"): > > =========================================================== > > (1) > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar > ed/webrev.00/00.backend.shared/ > > > Ideal vector nodes for new operations introduced by Vector API. > > (Platform-specific back end support will be posted for review separately). > > =========================================================== > > (2) > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar > ed/webrev.00/01.intrinsics/ > > > JVM Java interface (VectorSupport) and intrinsic support in C2. > > Vector instances are initially represented as VectorBox macro nodes > and "unboxing" is represented by VectorUnbox node. It simplifies > vector box elimination analysis and the nodes are expanded later right before EA pass. > > Vectors have 2-level on-heap representation: for the vector value > primitive array is used as a backing storage and it is encapsulated in > a typed wrapper (e.g., Int256Vector - vector of 8 ints - contains a > int[8] instance which is used to store vector value). > > Unless VectorBox node goes away, it needs to be expanded into an > allocation eventually, but it is a pure node and doesn't have any JVM > state associated with it. The problem is solved by keeping JVM state > separately in a VectorBoxAllocate node associated with VectorBox node > and use it during expansion. > > Also, to simplify vector box elimination, inlining of vector reboxing > calls (VectorSupport::maybeRebox) is delayed until the analysis is over. > > =========================================================== > > (3) > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar > ed/webrev.00/02.vbox_elimination/ > > > Vector box elimination analysis implementation. (Brief overview: > slides > #36-42 [5].) > > The main part is devoted to scalarization across safepoints and > rematerialization support during deoptimization. In C2-generated code > vector operations work with raw vector values which live in registers > or spilled on the stack and it allows to avoid boxing/unboxing when a > vector value is alive across a safepoint. As with other values, > there's just a location of the vector value at the safepoint and > vector type information recorded in the relevant nmethod metadata and > all the heavy-lifting happens only when rematerialization takes place. > > The analysis preserves object identity invariants except during > aggressive reboxing (guarded by -XX:+EnableAggressiveReboxing). > > (Aggressive reboxing is crucial for cases when vectors "escape": it > allocates a fresh instance at every escape point thus enabling > original instance to go away.) > > =========================================================== > > (4) > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar > ed/webrev.00/03.module.hotspot/ > > > HotSpot changes for jdk.incubator.vector module. Vector support is > makred experimental and turned off by default. JEP 338 proposes the > API to be released as an incubator module, so a user has to specify > "--add-module jdk.incubator.vector" on the command line to be able to > use it. > When user does that, JVM automatically enables Vector API support. > It improves usability (user doesn't need to separately "open" the API > and enable JVM support) while minimizing risks of destabilitzation > from new code when the API is not used. > > > That's it! Will be happy to answer any questions. > > And thanks in advance for any feedback! > > Best regards, > Vladimir Ivanov > > [0] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/06534 > 5.html > > > [1] > https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041228. > html > > [2] https://openjdk.java.net/jeps/338 > > [3] https://openjdk.java.net/projects/panama/ > > [4] > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar > ed/webrev.00/01.intrinsics/src/java.base/share/classes/jdk/internal/vm > /vector/VectorSupport.java.html > > > [5] > http://cr.openjdk.java.net/~vlivanov/talks/2018_JVMLS_VectorAPI.pdf > > [6] http://hg.openjdk.java.net/panama/dev/shortlog/92bbd44386e9 > > ??? $ hg clone http://hg.openjdk.java.net/panama/dev/ -b > vector-unstable From coleen.phillimore at oracle.com Wed Jul 29 18:28:23 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Jul 2020 14:28:23 -0400 Subject: RFR 8249837: Avoid direct or implicit Thread::current() calls when we already have a current thread variable In-Reply-To: <662892e6-f63a-7089-604b-764f0fdc6e6b@oracle.com> References: <3fa4d408-7096-d405-1f1a-98329a21d77d@oracle.com> <662892e6-f63a-7089-604b-764f0fdc6e6b@oracle.com> Message-ID: <6a0c7fb3-b3ea-1f7c-0943-6d36916ee25a@oracle.com> Thank you Vladimir! Coleen On 7/29/20 1:00 PM, Vladimir Kozlov wrote: > Compiler and jvmci code change slooks good. > > Thanks, > Vladimir K > > On 7/29/20 8:54 AM, coleen.phillimore at oracle.com wrote: >> Summary: Add current thread and/or moved HandleMark to the scope that >> it is needed >> >> This patch removes HandleMarks from the GC code.? I added a >> NoHandleMark to these places and found the locations in the >> verification code that needs the HandleMarks, and moved them there. >> >> Tested with tier1-6 with no failures. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8249837.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8249837 >> >> Thanks, >> Coleen From hohensee at amazon.com Wed Jul 29 19:28:04 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 29 Jul 2020 19:28:04 +0000 Subject: [Mach5] mach5-one-phh-JDK-8215624-1-20200729-1619-13017115: FAILED In-Reply-To: <724611F1-3AA3-4E3D-8878-BF2D8381799B@amazon.com> References: <724611F1-3AA3-4E3D-8878-BF2D8381799B@amazon.com> Message-ID: <96D7F248-8182-468C-AB55-17438E4E422B@amazon.com> I did a rerun and the problem went away. Must have been an infrastructure problem. Lesson learned. ?On 7/29/20, 10:41 AM, "hotspot-dev on behalf of Hohensee, Paul" wrote: Hi, Can someone tell me what the below error message means? I?ve successfully done multiple slowdebug builds on my Mac. Thanks, Paul From: on behalf of "do-not-reply at oracle.com" Reply-To: "mach5_admin_ww_grp at oracle.com" Date: Wednesday, July 29, 2020 at 10:24 AM To: "Hohensee, Paul" Subject: [Mach5] mach5-one-phh-JDK-8215624-1-20200729-1619-13017115: FAILED Job: mach5-one-phh-JDK-8215624-1-20200729-1619-13017115 BuildId: 2020-07-29-1618311.hohensee.source No failed tests Tasks Summary * NA: 0 * HARNESS_ERROR: 0 * FAILED: 1 * PASSED: 102 * NOTHING_TO_RUN: 0 * UNABLE_TO_RUN: 0 * KILLED: 0 * EXECUTED_WITH_FAILURE: 0 Build 1 Failed * macosx-x64-open-debug-macosx-x64-build-14 SOURCE_MASTER REASON_SLAVE_RE...d: a new agent registered at the same address From david.holmes at oracle.com Thu Jul 30 00:34:01 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2020 10:34:01 +1000 Subject: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper In-Reply-To: <88772db0-5a88-16df-8c91-52d97a583c0d@oracle.com> References: <0707d751-da96-b316-fa52-b8159d2c5314@oracle.com> <88772db0-5a88-16df-8c91-52d97a583c0d@oracle.com> Message-ID: <098a71da-97c5-aa82-509e-8c7e2c8bc7a7@oracle.com> Pushed. David On 29/07/2020 7:33 pm, David Holmes wrote: > Hi Ludovic, > > I will sponsor this one too (13 hours from now) unless someone gets > there first. > > Cheers, > David > > On 29/07/2020 2:25 am, Ludovic Henry wrote: >> Hi Thomas, Kim, David, >> >> Could one of you please sponsor the change and merge it into jdk/jdk? >> Let me know of anything you need me to do to get it merged. >> >> Thank you >> Ludovic >> >> ________________________________________ >> From: hotspot-dev on behalf of >> Thomas Schatzl >> Sent: Friday, July 24, 2020 05:01 >> To: hotspot-dev at openjdk.java.net >> Subject: Re: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper >> >> Hi, >> >> On 21.07.20 21:17, Ludovic Henry wrote: >>> Hello, >>> >>> Simple code cleanup to use existing ATTRIBUTE_ALIGNED macro in >>> src/hotspot/cpu/aarch64. >>> >>> JBS: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248682&data=02%7C01%7Cluhenry%40microsoft.com%7C03b4e13002874e86ab2108d82fc96177%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637311889252388951&sdata=6%2FzjhW9W07c9xy0hrPUZ3KboLPPWbR4f6w7gapF7RBs%3D&reserved=0 >>> >>> Webrev: >>> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fluhenry%2F8248682%2Fwebrev.00&data=02%7C01%7Cluhenry%40microsoft.com%7C03b4e13002874e86ab2108d82fc96177%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637311889252388951&sdata=b%2BV7Cy1uy5XADX8%2BGmynD1IHmZ%2FO34gDtEuAQ%2BD4DfE%3D&reserved=0 >>> >>> >>> Testing: jtreg:test/hotspot/jtreg:tier1, jtreg:test/jdk:tier1, >>> jtreg:test/jdk:tier2, jtreg:test/langtools, on Windows-AArch64 and >>> Linux-AArch64. >>> >>> Thank you, >>> >>> -- >>> Ludovic >>> >> >> ??? lgtm. >> >> Thomas >> From luhenry at microsoft.com Thu Jul 30 01:29:10 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Thu, 30 Jul 2020 01:29:10 +0000 Subject: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper In-Reply-To: <098a71da-97c5-aa82-509e-8c7e2c8bc7a7@oracle.com> References: <0707d751-da96-b316-fa52-b8159d2c5314@oracle.com> <88772db0-5a88-16df-8c91-52d97a583c0d@oracle.com> <098a71da-97c5-aa82-509e-8c7e2c8bc7a7@oracle.com> Message-ID: Perfect, thank you! -----Original Message----- From: David Holmes Sent: Wednesday, July 29, 2020 5:34 PM To: Ludovic Henry ; Thomas Schatzl ; hotspot-dev at openjdk.java.net Subject: Re: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper Pushed. David On 29/07/2020 7:33 pm, David Holmes wrote: > Hi Ludovic, > > I will sponsor this one too (13 hours from now) unless someone gets > there first. > > Cheers, > David > > On 29/07/2020 2:25 am, Ludovic Henry wrote: >> Hi Thomas, Kim, David, >> >> Could one of you please sponsor the change and merge it into jdk/jdk? >> Let me know of anything you need me to do to get it merged. >> >> Thank you >> Ludovic >> >> ________________________________________ >> From: hotspot-dev on behalf of >> Thomas Schatzl >> Sent: Friday, July 24, 2020 05:01 >> To: hotspot-dev at openjdk.java.net >> Subject: Re: RFR[XXS]: 8248682: AArch64: Use ATTRIBUTE_ALIGNED helper >> >> Hi, >> >> On 21.07.20 21:17, Ludovic Henry wrote: >>> Hello, >>> >>> Simple code cleanup to use existing ATTRIBUTE_ALIGNED macro in >>> src/hotspot/cpu/aarch64. >>> >>> JBS: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248682&data=02%7C01%7Cluhenry%40microsoft.com%7Ce3ab57eefb9442f8fb4508d8342047c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316660533925286&sdata=Q9bvhb%2FyPrZtpEmylCp%2BeKO2Z9zy7laVJdtmeg%2B4UIE%3D&reserved=0 >>> >>> Webrev: >>> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fluhenry%2F8248682%2Fwebrev.00&data=02%7C01%7Cluhenry%40microsoft.com%7Ce3ab57eefb9442f8fb4508d8342047c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316660533925286&sdata=OQQDY8sQPCFt8q6fhCUBX5jzy5N3zoCHqCxQ2ZA1yBo%3D&reserved=0 >>> >>> >>> Testing: jtreg:test/hotspot/jtreg:tier1, jtreg:test/jdk:tier1, >>> jtreg:test/jdk:tier2, jtreg:test/langtools, on Windows-AArch64 and >>> Linux-AArch64. >>> >>> Thank you, >>> >>> -- >>> Ludovic >>> >> >> ??? lgtm. >> >> Thomas >> From ningsheng.jian at arm.com Thu Jul 30 01:53:07 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Thu, 30 Jul 2020 09:53:07 +0800 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <852a3a09-a627-c0fc-89c6-8c8100ae17f5@redhat.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com> <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com> <852a3a09-a627-c0fc-89c6-8c8100ae17f5@redhat.com> Message-ID: <564c8283-0c8f-9487-af3c-c971fa6b736d@arm.com> On 7/29/20 7:44 PM, Andrew Haley wrote: > On 20/07/2020 04:51, Ningsheng Jian wrote: >> Since we are getting ready to propose Vector API target to JDK 16 [1]. I >> have regenerated webrev of aarch64 backend parts from panama repo, which >> has been rebased to jdk/jdk very recently, by: >> >> $ hg update vector-unstable && hg diff -r default > all.patch >> $ grep "diff -r" all.patch | grep -e "src/hotspot/cpu/aarch64" | awk >> '{print $4}' > aarch64_list >> $ ksh ./webrev.ksh -r default -o aarch64_webrev aarch64_list >> >> The new webrev: >> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ >> >> Could you please help to take a look? > > OK, thanks. It all looks fine. Sorry for the delay. > Thank you Andrew! Regards, Ningsheng From david.holmes at oracle.com Thu Jul 30 05:06:43 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2020 15:06:43 +1000 Subject: [Mach5] mach5-one-phh-JDK-8215624-1-20200729-1619-13017115: FAILED In-Reply-To: <96D7F248-8182-468C-AB55-17438E4E422B@amazon.com> References: <724611F1-3AA3-4E3D-8878-BF2D8381799B@amazon.com> <96D7F248-8182-468C-AB55-17438E4E422B@amazon.com> Message-ID: <3761d51c-53ab-8504-4d19-346562b217a4@oracle.com> On 30/07/2020 5:28 am, Hohensee, Paul wrote: > I did a rerun and the problem went away. Must have been an infrastructure problem. Lesson learned. Yep infra issue. David > ?On 7/29/20, 10:41 AM, "hotspot-dev on behalf of Hohensee, Paul" wrote: > > Hi, > > Can someone tell me what the below error message means? I?ve successfully done multiple slowdebug builds on my Mac. > > Thanks, > Paul > > From: on behalf of "do-not-reply at oracle.com" > Reply-To: "mach5_admin_ww_grp at oracle.com" > Date: Wednesday, July 29, 2020 at 10:24 AM > To: "Hohensee, Paul" > Subject: [Mach5] mach5-one-phh-JDK-8215624-1-20200729-1619-13017115: FAILED > Job: mach5-one-phh-JDK-8215624-1-20200729-1619-13017115 > BuildId: 2020-07-29-1618311.hohensee.source > No failed tests > Tasks Summary > > * NA: 0 > * HARNESS_ERROR: 0 > * FAILED: 1 > * PASSED: 102 > * NOTHING_TO_RUN: 0 > * UNABLE_TO_RUN: 0 > * KILLED: 0 > * EXECUTED_WITH_FAILURE: 0 > > Build > 1 Failed > > * macosx-x64-open-debug-macosx-x64-build-14 SOURCE_MASTER REASON_SLAVE_RE...d: a new agent registered at the same address > From david.holmes at oracle.com Thu Jul 30 06:24:38 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2020 16:24:38 +1000 Subject: RFR 8249837: Avoid direct or implicit Thread::current() calls when we already have a current thread variable In-Reply-To: <3fa4d408-7096-d405-1f1a-98329a21d77d@oracle.com> References: <3fa4d408-7096-d405-1f1a-98329a21d77d@oracle.com> Message-ID: <3ebad2bb-7323-ba25-b0d1-b82e42dfd640@oracle.com> Hi Coleen, Thanks for taking on this one. :) On 30/07/2020 1:54 am, coleen.phillimore at oracle.com wrote: > Summary: Add current thread and/or moved HandleMark to the scope that it > is needed > > This patch removes HandleMarks from the GC code.? I added a NoHandleMark > to these places and found the locations in the verification code that > needs the HandleMarks, and moved them there. Sounds good. I looked at all the other changes and they all seemed fine too. Thanks, David > Tested with tier1-6 with no failures. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8249837.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8249837 > > Thanks, > Coleen From neugens at redhat.com Thu Jul 30 10:53:31 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 30 Jul 2020 12:53:31 +0200 Subject: RFR: 8250670: TestJFRIntrinsic.java should be run with and without JFR to check the intrinsic properly In-Reply-To: References: Message-ID: CC'ing hotspot-jfr-dev as it may be a better place to discuss this patch. On Tue, Jul 28, 2020 at 2:55 PM Mario Torre wrote: > > Hi all, > > We noticed an interesting thing with TestJFRIntrinsic.java, if I > understood the test correctly, it wants to check the behavior of the > getEventWriter intrinsic, however it doesn't really do this, since JFR > is always disabled when the test starts, the instance is always null. > > I changed the test slightly, first of all it's run twice now (actually > 4 times, since it was already run twice before with different values > of the TieredStopAtLevel option), one with and one without JFR, I also > check that for the given combinations we get something resembling > meaningful results. > > Here's the webrev: > > http://cr.openjdk.java.net/~neugens/8250670/ > > Any comments? > > Cheers, > Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From erik.gahlin at oracle.com Thu Jul 30 12:27:38 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 30 Jul 2020 14:27:38 +0200 Subject: RFR: 8250670: TestJFRIntrinsic.java should be run with and without JFR to check the intrinsic properly In-Reply-To: References: Message-ID: Hi Mario, There is a test that checks the functionality. See TestGetEventWriter. Maybe it can be improved so it also checks the disabled case as well? We could probably run TestJFRIntrinsic.java with JFR enabled, but not sure we need to run all four cases? Thanks Erik > On 30 Jul 2020, at 12:53, Mario Torre wrote: > > CC'ing hotspot-jfr-dev as it may be a better place to discuss this patch. > > On Tue, Jul 28, 2020 at 2:55 PM Mario Torre wrote: >> >> Hi all, >> >> We noticed an interesting thing with TestJFRIntrinsic.java, if I >> understood the test correctly, it wants to check the behavior of the >> getEventWriter intrinsic, however it doesn't really do this, since JFR >> is always disabled when the test starts, the instance is always null. >> >> I changed the test slightly, first of all it's run twice now (actually >> 4 times, since it was already run twice before with different values >> of the TieredStopAtLevel option), one with and one without JFR, I also >> check that for the given combinations we get something resembling >> meaningful results. >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~neugens/8250670/ >> >> Any comments? >> >> Cheers, >> Mario > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > From neugens at redhat.com Thu Jul 30 12:43:03 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 30 Jul 2020 14:43:03 +0200 Subject: RFR: 8250670: TestJFRIntrinsic.java should be run with and without JFR to check the intrinsic properly In-Reply-To: References: Message-ID: On Thu, Jul 30, 2020 at 2:27 PM Erik Gahlin wrote: > > Hi Mario, Hi Erik, > There is a test that checks the functionality. See TestGetEventWriter. Maybe it can be improved so it also checks the disabled case as well? Ok, I'll check this out too. > We could probably run TestJFRIntrinsic.java with JFR enabled, but not sure we need to run all four cases? I'm not sure what would be the purpose of this test however. I thought that running the test with and without JFR would give us an indication if the intrinsic works, but I think we still want to test both "all compiled" and fully tiered? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From beurba at microsoft.com Thu Jul 30 12:59:58 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Thu, 30 Jul 2020 12:59:58 +0000 Subject: RFR(XXS) 8250824: AArch64: follow up for JDK-8248414 Message-ID: Hi all, the original change [1] missed to update an assert. JBS: https://bugs.openjdk.java.net/browse/JDK-8250824 Webrev: http://cr.openjdk.java.net/~burban/8250824/ Thank you, -Bernhard [1] https://hg.openjdk.java.net/jdk/jdk/rev/d352e5db468c From beurba at microsoft.com Thu Jul 30 13:11:37 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Thu, 30 Jul 2020 13:11:37 +0000 Subject: RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply Message-ID: Hi all, this is a small fixup: the declaration of `strength_reduce_multiply` uses a `jint` for the parameter `constant` [1], but some backends were using `int` instead. JBS: https://bugs.openjdk.java.net/browse/JDK-8248816 Webrev: http://cr.openjdk.java.net/~burban/8248816/ Thank you, -Bernhard [1] https://hg.openjdk.java.net/jdk/jdk/file/8f7ede592c28/src/hotspot/share/c1/c1_LIRGenerator.hpp#l343 From coleen.phillimore at oracle.com Thu Jul 30 14:03:23 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 30 Jul 2020 10:03:23 -0400 Subject: RFR 8249837: Avoid direct or implicit Thread::current() calls when we already have a current thread variable In-Reply-To: <3ebad2bb-7323-ba25-b0d1-b82e42dfd640@oracle.com> References: <3fa4d408-7096-d405-1f1a-98329a21d77d@oracle.com> <3ebad2bb-7323-ba25-b0d1-b82e42dfd640@oracle.com> Message-ID: Thanks for the review, David. Coleen On 7/30/20 2:24 AM, David Holmes wrote: > Hi Coleen, > > Thanks for taking on this one. :) > > On 30/07/2020 1:54 am, coleen.phillimore at oracle.com wrote: >> Summary: Add current thread and/or moved HandleMark to the scope that >> it is needed >> >> This patch removes HandleMarks from the GC code.? I added a >> NoHandleMark to these places and found the locations in the >> verification code that needs the HandleMarks, and moved them there. > > Sounds good. > > I looked at all the other changes and they all seemed fine too. > > Thanks, > David > >> Tested with tier1-6 with no failures. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8249837.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8249837 >> >> Thanks, >> Coleen From aph at redhat.com Thu Jul 30 17:14:19 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Jul 2020 18:14:19 +0100 Subject: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply In-Reply-To: References: Message-ID: On 30/07/2020 14:11, Bernhard Urban-Forster wrote: > Hi all, > > this is a small fixup: the declaration of `strength_reduce_multiply` uses a `jint` for the parameter `constant` [1], but some backends were using `int` instead. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248816 > Webrev: http://cr.openjdk.java.net/~burban/8248816/ OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From beurba at microsoft.com Fri Jul 31 09:26:01 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Fri, 31 Jul 2020 09:26:01 +0000 Subject: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply In-Reply-To: References: , Message-ID: Thank you for the review Andrew. I've updated the Reviewed-By line in the Webrev: http://cr.openjdk.java.net/~burban/8248816/ -Bernhard ________________________________________ From: Andrew Haley Sent: Thursday, July 30, 2020 19:14 To: Bernhard Urban-Forster; hotspot-dev Source Developers; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply On 30/07/2020 14:11, Bernhard Urban-Forster wrote: > Hi all, > > this is a small fixup: the declaration of `strength_reduce_multiply` uses a `jint` for the parameter `constant` [1], but some backends were using `int` instead. > > JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248816&data=02%7C01%7Cbeurba%40microsoft.com%7C5527aeead1ce44e1b67e08d834ac03c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317260684765118&sdata=28A9Rb7tzDC0rGgUJM6hQglZxzRmKBPtqEnXEbWYxWM%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8248816%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C5527aeead1ce44e1b67e08d834ac03c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317260684765118&sdata=trUG1lHI%2F4CONPNFZQfZAai336f6vGfmsvbX5QTMLMs%3D&reserved=0 OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7Cbeurba%40microsoft.com%7C5527aeead1ce44e1b67e08d834ac03c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317260684765118&sdata=NYh2gNU6IIcZa4NW8eP173%2FoXpstoVF%2B02dFZsYTFzY%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Nikola.Grcevski at microsoft.com Fri Jul 31 13:43:35 2020 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Fri, 31 Jul 2020 13:43:35 +0000 Subject: Scoping the stack allocation prototype for C2 In-Reply-To: References: <96CC71B1-5FD1-4D6B-B3D1-ABC9C08E076D@microsoft.com> Message-ID: Hi Richard, Thanks for your suggestion. We have started looking at this and once we have the allocation hoisting prototype ready, we'll measure it against what we get with the stack allocation patch. Once we have some results we'll share them here. We are open to more suggestions from you or anyone else in the community. Thanks, Nikola and Charlie -----Original Message----- From: Reingruber, Richard Sent: July 29, 2020 3:52 AM To: Charlie Gracie ; Erik ?sterlund ; Nikola Grcevski ; hotspot-dev Source Developers Subject: RE: Re: Scoping the stack allocation prototype for C2 Hi, an even simpler optimization could be to find allocations that don't escape a loop body, schedule them into a dominating region and reuse the allocated bytes in the loop body. This would be possible without special allocation zones/buffers. At first glance this seems to be comparatively simple, but still effective. Again a lot would depend on inlining: will hot allocations be compiled together with their loop? And I'd think that there have to be hot allocations in the benchmark for stack allocation to be beneficial. If they are not hot then young gen allocation/reclamation are probably good enough. Maybe the allocation could even be undone after the loop if there was no escaping allocation in the loop. I guess this is the downside: no implicit free when the compiled method returns. Best regards, Richard. -----Original Message----- From: hotspot-dev On Behalf Of Charlie Gracie Sent: Montag, 27. Juli 2020 21:24 To: Erik ?sterlund ; Nikola Grcevski ; hotspot-dev Source Developers Subject: Re: Re: Scoping the stack allocation prototype for C2 Hi Erik, > It sounds like the high level goal is not "allocate on the stack", but > rather allocate and free objects more efficiently based on compile-time knowledge about their scoped lifetime. Yes, you are correct. That is the best way to describe our high-level goal. > Since I can see so many advantages with this approach, and not really > any disadvantages if done right, I wonder if there are any clear > reasons not to build it in that (general) way instead.I am curious to hear your thoughts about this. > > If you agree this is probably a better way of achieving the same > thing, then I have some ideas how best to implement it that we could discuss. > But maybe we should settle on the direction first instead.Perhaps > there are some nice quirks with stack allocations that still make them more desirable, even though I can not currently see it. You have made excellent points about the pros and cons of both solutions, along with Vladimir and others. Taking all this information into account, we agree that the zone-based approach would satisfy our high-level goals without as many limitations as the stack based approach. > If you agree this is probably a better way of achieving the same > thing, then I have some ideas how best to implement it that we could discuss. We would appreciate hearing your ideas about how to best implement the zone-based solution. We are especially interested in your thoughts on how to get started with acquiring a zone and managing it. Having some guidance on the starting the zone-based approach would help us a lot. Thanks again for your insightful comments, Charlie & Nikola From coleen.phillimore at oracle.com Fri Jul 31 14:16:22 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 31 Jul 2020 10:16:22 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage Message-ID: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> Summary: Add a weak OopStorage for JFR and move the oops there. Remove GC code to process oops. Tested with tier1,5, and 6.? Built with shenandoah. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8235573 Thanks, Coleen From richard.reingruber at sap.com Fri Jul 31 15:09:03 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 31 Jul 2020 15:09:03 +0000 Subject: Scoping the stack allocation prototype for C2 In-Reply-To: References: <96CC71B1-5FD1-4D6B-B3D1-ABC9C08E076D@microsoft.com> Message-ID: Hi Nikola, hi Charlie, thanks for spending the effort and doing the experiment. Actually I think it's fun to do :) Hoisting allocations probably won't be as effective as stack allocation, but doing it for ArgEscape allocations, too, (if feasable) will likely help. Thanks, Richard. -----Original Message----- From: Nikola Grcevski Sent: Freitag, 31. Juli 2020 15:44 To: Reingruber, Richard ; Charlie Gracie ; Erik ?sterlund ; hotspot-dev Source Developers Subject: RE: Re: Scoping the stack allocation prototype for C2 Hi Richard, Thanks for your suggestion. We have started looking at this and once we have the allocation hoisting prototype ready, we'll measure it against what we get with the stack allocation patch. Once we have some results we'll share them here. We are open to more suggestions from you or anyone else in the community. Thanks, Nikola and Charlie -----Original Message----- From: Reingruber, Richard Sent: July 29, 2020 3:52 AM To: Charlie Gracie ; Erik ?sterlund ; Nikola Grcevski ; hotspot-dev Source Developers Subject: RE: Re: Scoping the stack allocation prototype for C2 Hi, an even simpler optimization could be to find allocations that don't escape a loop body, schedule them into a dominating region and reuse the allocated bytes in the loop body. This would be possible without special allocation zones/buffers. At first glance this seems to be comparatively simple, but still effective. Again a lot would depend on inlining: will hot allocations be compiled together with their loop? And I'd think that there have to be hot allocations in the benchmark for stack allocation to be beneficial. If they are not hot then young gen allocation/reclamation are probably good enough. Maybe the allocation could even be undone after the loop if there was no escaping allocation in the loop. I guess this is the downside: no implicit free when the compiled method returns. Best regards, Richard. -----Original Message----- From: hotspot-dev On Behalf Of Charlie Gracie Sent: Montag, 27. Juli 2020 21:24 To: Erik ?sterlund ; Nikola Grcevski ; hotspot-dev Source Developers Subject: Re: Re: Scoping the stack allocation prototype for C2 Hi Erik, > It sounds like the high level goal is not "allocate on the stack", but > rather allocate and free objects more efficiently based on compile-time knowledge about their scoped lifetime. Yes, you are correct. That is the best way to describe our high-level goal. > Since I can see so many advantages with this approach, and not really > any disadvantages if done right, I wonder if there are any clear > reasons not to build it in that (general) way instead.I am curious to hear your thoughts about this. > > If you agree this is probably a better way of achieving the same > thing, then I have some ideas how best to implement it that we could discuss. > But maybe we should settle on the direction first instead.Perhaps > there are some nice quirks with stack allocations that still make them more desirable, even though I can not currently see it. You have made excellent points about the pros and cons of both solutions, along with Vladimir and others. Taking all this information into account, we agree that the zone-based approach would satisfy our high-level goals without as many limitations as the stack based approach. > If you agree this is probably a better way of achieving the same > thing, then I have some ideas how best to implement it that we could discuss. We would appreciate hearing your ideas about how to best implement the zone-based solution. We are especially interested in your thoughts on how to get started with acquiring a zone and managing it. Having some guidance on the starting the zone-based approach would help us a lot. Thanks again for your insightful comments, Charlie & Nikola From coleen.phillimore at oracle.com Fri Jul 31 15:43:25 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 31 Jul 2020 11:43:25 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> Message-ID: Markus contributed a better incremental patch on top of this, please review tested 02 patch instead. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.02/webrev Thanks, Coleen On 7/31/20 10:16 AM, coleen.phillimore at oracle.com wrote: > Summary: Add a weak OopStorage for JFR and move the oops there. Remove > GC code to process oops. > > Tested with tier1,5, and 6.? Built with shenandoah. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8235573 > > Thanks, > Coleen From markus.gronlund at oracle.com Fri Jul 31 16:50:36 2020 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 31 Jul 2020 09:50:36 -0700 (PDT) Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> Message-ID: <389643e8-44c3-4392-97a5-039208fad122@default> Hi Coleen, Looks good. Thank you for the work done and also for incorporating my modifications. I have one open question about the naming of the OopStorage instance: OopStorageSet::create_weak("JFR Old Object Samples"); I named it like this because it describes what it represents from a JFR perspective. I have also seen other OopStorage names that encode the term "Weak" into the actual name, so I am trying to understand how this will be used. My guess is that it is to distinguish between the different oop storages and their types as part of logging (GC logging?). If the logging expects or prefers the oop storage type to be encoded into the name, then maybe it should instead be called "Weak JFR Old Object Samples"? Thanks Markus -----Original Message----- From: Coleen Phillimore Sent: den 31 juli 2020 17:43 To: hotspot-dev developers ; hotspot-jfr-dev at openjdk.java.net Subject: Re: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage Markus contributed a better incremental patch on top of this, please review tested 02 patch instead. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.02/webrev Thanks, Coleen On 7/31/20 10:16 AM, coleen.phillimore at oracle.com wrote: > Summary: Add a weak OopStorage for JFR and move the oops there. Remove > GC code to process oops. > > Tested with tier1,5, and 6.? Built with shenandoah. > > open webrev at > http://cr.openjdk.java.net/~coleenp/2020/8235573.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8235573 > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Jul 31 17:45:14 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 31 Jul 2020 13:45:14 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: <389643e8-44c3-4392-97a5-039208fad122@default> References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> <389643e8-44c3-4392-97a5-039208fad122@default> Message-ID: <1ab50af9-f271-0e3c-a050-9e572d58c4f5@oracle.com> Hi Markus,? Thank you for your help! On 7/31/20 12:50 PM, Markus Gronlund wrote: > Hi Coleen, > > Looks good. > > Thank you for the work done and also for incorporating my modifications. > > I have one open question about the naming of the OopStorage instance: > > OopStorageSet::create_weak("JFR Old Object Samples"); > > I named it like this because it describes what it represents from a JFR perspective. I have also seen other OopStorage names that encode the term "Weak" into the actual name, so I am trying to understand how this will be used. My guess is that it is to distinguish between the different oop storages and their types as part of logging (GC logging?). If the logging expects or prefers the oop storage type to be encoded into the name, then maybe it should instead be called "Weak JFR Old Object Samples"? Honestly, I don't know.? I see that the name field is used for logging.? Maybe including "Weak" in the name would be good because then looking at the GC logs wouldn't be confusing (ie. why is this OopStorage being processed with the other weak ones?).? I think I should add Weak to the name unless anyone screams. Thanks, Coleen > > Thanks > Markus > > > -----Original Message----- > From: Coleen Phillimore > Sent: den 31 juli 2020 17:43 > To: hotspot-dev developers ; hotspot-jfr-dev at openjdk.java.net > Subject: Re: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage > > > Markus contributed a better incremental patch on top of this, please review tested 02 patch instead. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.02/webrev > > Thanks, > Coleen > > On 7/31/20 10:16 AM, coleen.phillimore at oracle.com wrote: >> Summary: Add a weak OopStorage for JFR and move the oops there. Remove >> GC code to process oops. >> >> Tested with tier1,5, and 6.? Built with shenandoah. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8235573.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8235573 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Fri Jul 31 19:38:09 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 31 Jul 2020 15:38:09 -0400 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes In-Reply-To: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> References: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> Message-ID: <9c538834-903b-5431-bb43-908b58a1b70a@oracle.com> The runtime code still looks good to me. Coleen On 7/28/20 6:29 PM, Vladimir Ivanov wrote: > Hi, > > Thanks for the feedback on webrev.00, Remi, Coleen, Vladimir K., and > Ekaterina! > > Here are the latest changes for Vector API support in HotSpot shared > code: > > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01 > > > Incremental changes (diff against webrev.00): > > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00 > > > I decided to post it here and not initiate a new round of reviews > because the changes are mostly limited to minor cleanups / simple bug > fixes. > > Detailed summary: > ? - rebased to jdk/jdk tip; > ? - got rid of NotV, VLShiftV, VRShiftV, VURShiftV nodes; > ? - restore lazy cleanup logic during incremental inlining (see > needs_cleanup in compile.cpp); > ? - got rid of x86-specific changes in shared code; > ? - fix for 8244867 [1]; > ? - fix Graal test failure: enumerate VectorSupport intrinsics in > CheckGraalIntrinsics > ? - numerous minor cleanups > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/panama/dev/rev/dcfc7b6e8977 > ??? http://jbs.oracle.com/browse/JDK-8244867 > ??? 8244867: 2 vector api tests crash with > assert(is_reference_type(basic_type())) failed: wrong type > Summary: Adding safety checks to prevent intrinsification if class > arguments of non-primitive types are uninitialized. > > On 04.04.2020 02:12, Vladimir Ivanov wrote: >> Hi, >> >> Following up on review requests of API [0] and Java implementation >> [1] for Vector API (JEP 338 [2]), here's a request for review of >> general HotSpot changes (in shared code) required for supporting the >> API: >> >> >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/all.00-03/ >> >> >> (First of all, to set proper expectations: since the JEP is still in >> Candidate state, the intention is to initiate preliminary round(s) of >> review to inform the community and gather feedback before sending out >> final/official RFRs once the JEP is Targeted to a release.) >> >> Vector API (being developed in Project Panama [3]) relies on JVM >> support to utilize optimal vector hardware instructions at runtime. >> It interacts with JVM through intrinsics (declared in >> jdk.internal.vm.vector.VectorSupport [4]) which expose vector >> operations support in C2 JIT-compiler. >> >> As Paul wrote earlier: "A vector intrinsic is an internal low-level >> vector operation. The last argument to the intrinsic is fall back >> behavior in Java, implementing the scalar operation over the number >> of elements held by the vector.? Thus, If the intrinsic is not >> supported in C2 for the other arguments then the Java implementation >> is executed (the Java implementation is always executed when running >> in the interpreter or for C1)." >> >> The rest of JVM support is about aggressively optimizing vector boxes >> to minimize (ideally eliminate) the overhead of boxing for vector >> values. >> It's a stop-the-gap solution for vector box elimination problem until >> inline classes arrive. Vector classes are value-based and in the >> longer term will be migrated to inline classes once the support >> becomes available. >> >> Vector API talk from JVMLS'18 [5] contains brief overview of JVM >> implementation and some details. >> >> Complete implementation resides in vector-unstable branch of >> panama/dev repository [6]. >> >> Now to gory details (the patch is split in multiple "sub-webrevs"): >> >> =========================================================== >> >> (1) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/00.backend.shared/ >> >> >> Ideal vector nodes for new operations introduced by Vector API. >> >> (Platform-specific back end support will be posted for review >> separately). >> >> =========================================================== >> >> (2) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/ >> >> >> JVM Java interface (VectorSupport) and intrinsic support in C2. >> >> Vector instances are initially represented as VectorBox macro nodes >> and "unboxing" is represented by VectorUnbox node. It simplifies >> vector box elimination analysis and the nodes are expanded later >> right before EA pass. >> >> Vectors have 2-level on-heap representation: for the vector value >> primitive array is used as a backing storage and it is encapsulated >> in a typed wrapper (e.g., Int256Vector - vector of 8 ints - contains >> a int[8] instance which is used to store vector value). >> >> Unless VectorBox node goes away, it needs to be expanded into an >> allocation eventually, but it is a pure node and doesn't have any JVM >> state associated with it. The problem is solved by keeping JVM state >> separately in a VectorBoxAllocate node associated with VectorBox node >> and use it during expansion. >> >> Also, to simplify vector box elimination, inlining of vector reboxing >> calls (VectorSupport::maybeRebox) is delayed until the analysis is over. >> >> =========================================================== >> >> (3) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/02.vbox_elimination/ >> >> >> Vector box elimination analysis implementation. (Brief overview: >> slides #36-42 [5].) >> >> The main part is devoted to scalarization across safepoints and >> rematerialization support during deoptimization. In C2-generated code >> vector operations work with raw vector values which live in registers >> or spilled on the stack and it allows to avoid boxing/unboxing when a >> vector value is alive across a safepoint. As with other values, >> there's just a location of the vector value at the safepoint and >> vector type information recorded in the relevant nmethod metadata and >> all the heavy-lifting happens only when rematerialization takes place. >> >> The analysis preserves object identity invariants except during >> aggressive reboxing (guarded by -XX:+EnableAggressiveReboxing). >> >> (Aggressive reboxing is crucial for cases when vectors "escape": it >> allocates a fresh instance at every escape point thus enabling >> original instance to go away.) >> >> =========================================================== >> >> (4) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/03.module.hotspot/ >> >> >> HotSpot changes for jdk.incubator.vector module. Vector support is >> makred experimental and turned off by default. JEP 338 proposes the >> API to be released as an incubator module, so a user has to specify >> "--add-module jdk.incubator.vector" on the command line to be able to >> use it. >> When user does that, JVM automatically enables Vector API support. >> It improves usability (user doesn't need to separately "open" the API >> and enable JVM support) while minimizing risks of destabilitzation >> from new code when the API is not used. >> >> >> That's it! Will be happy to answer any questions. >> >> And thanks in advance for any feedback! >> >> Best regards, >> Vladimir Ivanov >> >> [0] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >> >> >> [1] >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041228.html >> >> [2] https://openjdk.java.net/jeps/338 >> >> [3] https://openjdk.java.net/projects/panama/ >> >> [4] >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java.html >> >> >> [5] http://cr.openjdk.java.net/~vlivanov/talks/2018_JVMLS_VectorAPI.pdf >> >> [6] http://hg.openjdk.java.net/panama/dev/shortlog/92bbd44386e9 >> >> ???? $ hg clone http://hg.openjdk.java.net/panama/dev/ -b >> vector-unstable