From bmcwhirt at redhat.com Wed May 1 14:21:18 2019 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Wed, 1 May 2019 10:21:18 -0400 Subject: Opensource, Community, Governance Message-ID: Howdy-- Since contributing to GraalVM/SubstrateVM for a while, I've come up with some questions and concerns around the project. Just hoping to start a conversation to ease my mind and perhaps address them. I understand GraalVM is under an opensource license. That much is obvious. I do not necessarily understand the governance model, which is concerning. Recently a series of architectural changes/choices have been made, seemingly unilaterally, and without consultation to the downstream community: - JNI over the C-ish "porting" of the JDK (removes DCE opportunities) - The fallback mode of native-image for Helidon - The tight intertwinglyness of compressed pointers and isolates - The lazy class initiatialization changes - the LLVM effort Red Hat has been investing in GraalVM through direct upstream contributions and of course our Quarkus project. Given that, we still seem to be held back at the gates, having our changes and issues addressed through the largess of Oracle, instead of as an open, community-governed opensource project. It appears, as an outsider, that significant decisions and conversations are occurring behind the corporate veil of Oracle, and not within the sight or influence of the non-Oracle stakeholders. Is there any route for a non-Oracle contributor to become a "core committer"? Is there any route for a non-Oracle contributor to be informed of and contribute to the short- or long-term roadmaps for GraalVM? Are there plans or goals to apply a more open governance model to the project, placing stakeholders on equal footing? Thanks, Bob From christian.wimmer at oracle.com Wed May 1 17:30:18 2019 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Wed, 1 May 2019 10:30:18 -0700 Subject: Opensource, Community, Governance In-Reply-To: References: Message-ID: <1ee090bc-7f95-9a8e-763b-169c886de744@oracle.com> Hi Bob, Some answers to your Native Image related technical points: > - JNI over the C-ish "porting" of the JDK (removes DCE opportunities) We see this as the only feasible way to have a maintainable and stable Native Image code base that works across multiple platforms (Linux, MacOS, Windows) and JDK versions (8, 11, latest). We also think that it is not going to impact the startup time and memory footprint of native images, but implementation is not complete enough yet to show this. > - The fallback mode of native-image for Helidon The fallback mode is not implemented for technical reasons, but only for legal reasons. Especially, it has nothing to do with Helidon (or any other concrete application that supports Native Image). > - The tight intertwinglyness of compressed pointers and isolates This is a technical necessity: compressed pointers can only be used when references within the image heap are relative to the heap base - which is exactly what isolates provide. The support for isolates is a (positive) side effect of compressed pointers. > - The lazy class initiatialization changes Based on our experience and feedback from early adopters (and all the effort you did for Quarkus was an important feedback for us too), it became clear that the default needs to be "initialize classes at run time". This is what Java developers are used to, and no application will work out-of-the-box if you change this. A lot of libraries and frameworks of course want to take advantage of class initialization at build time. We envision that libraries will ship with the appropriate configuration, i.e., that Quarkus will ship with the configuration that most classes are initialized at build time. I'm sorry that we rushed out these changes, but we felt that the time window for a change like that was closing rapidly. > - the LLVM effort I don't understand your concern here. What can be negative about supporting more platforms via LLVM? -Christian From bmcwhirt at redhat.com Wed May 1 17:39:15 2019 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Wed, 1 May 2019 13:39:15 -0400 Subject: Opensource, Community, Governance In-Reply-To: <1ee090bc-7f95-9a8e-763b-169c886de744@oracle.com> References: <1ee090bc-7f95-9a8e-763b-169c886de744@oracle.com> Message-ID: On Wed, May 1, 2019 at 1:31 PM Christian Wimmer wrote: > Hi Bob, > > Some answers to your Native Image related technical points: > > > - JNI over the C-ish "porting" of the JDK (removes DCE opportunities) > > We see this as the only feasible way to have a maintainable and stable > Native Image code base that works across multiple platforms (Linux, > MacOS, Windows) and JDK versions (8, 11, latest). > > We also think that it is not going to impact the startup time and memory > footprint of native images, but implementation is not complete enough > yet to show this. > Implicitly libjava.so will be included in its entirety, yes, since DCE can't see beyond the C calls and eliminate from there. > > > - The fallback mode of native-image for Helidon > > The fallback mode is not implemented for technical reasons, but only for > legal reasons. Especially, it has nothing to do with Helidon (or any > other concrete application that supports Native Image). > I dunno that I understand "legal" reasons. Would you mind elaborating? > > > - The tight intertwinglyness of compressed pointers and isolates > > This is a technical necessity: compressed pointers can only be used when > references within the image heap are relative to the heap base - which > is exactly what isolates provide. The support for isolates is a > (positive) side effect of compressed pointers. > Compressed pointers could also be useful without multiple isolates, though, no? I know Jason Greene was submitted some heap-copying optimizations which could've been used with compressed pointers, but without isolates. For our serverless or microservice or high-density-containers-on-a-pod use-cases, multiple isolates seems... un-needed. But having compressed pointers is still desirable. > > > - The lazy class initiatialization changes > > Based on our experience and feedback from early adopters (and all the > effort you did for Quarkus was an important feedback for us too), it > became clear that the default needs to be "initialize classes at run > time". This is what Java developers are used to, and no application will > work out-of-the-box if you change this. A lot of libraries and > frameworks of course want to take advantage of class initialization at > build time. We envision that libraries will ship with the appropriate > configuration, i.e., that Quarkus will ship with the configuration that > most classes are initialized at build time. > > I'm sorry that we rushed out these changes, but we felt that the time > window for a change like that was closing rapidly. > Sure, but open discussion would've been beneficial prior to the action being taken. > > > - the LLVM effort > > I don't understand your concern here. What can be negative about > supporting more platforms via LLVM? > I'm not *opposed* to the LLVM effort, don't get me wrong. But as I'm working on vanilla AArch64, I'm left wondering if the path I'm taking will end up being orphaned in favor of the LLVM strategy. Am I wasting my time? Should I be working with Johan on the LLVM stuff?I have no idea. It all boils back down to open communication and project governance, of which I'm still not feeling super re-assured about. -Bob > > -Christian > > From christian.wimmer at oracle.com Wed May 1 18:13:08 2019 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Wed, 1 May 2019 11:13:08 -0700 Subject: Opensource, Community, Governance In-Reply-To: References: <1ee090bc-7f95-9a8e-763b-169c886de744@oracle.com> Message-ID: <887ccb09-46c9-b012-e216-72049c2600d2@oracle.com> On 5/1/19 10:39, Bob McWhirter wrote: > > > On Wed, May 1, 2019 at 1:31 PM Christian Wimmer > > wrote: > > Hi Bob, > > Some answers to your Native Image related technical points: > > >? ? ?- JNI over the C-ish "porting" of the JDK (removes DCE > opportunities) > > We see this as the only feasible way to have a maintainable and stable > Native Image code base that works across multiple platforms (Linux, > MacOS, Windows) and JDK versions (8, 11, latest). > > We also think that it is not going to impact the startup time and > memory > footprint of native images, but implementation is not complete enough > yet to show this. > > > Implicitly libjava.so will be included in its entirety, yes, since DCE > can't see beyond the C calls and eliminate from there. Probably. That is only 230 KByte. Note that we still have DCE on the Java side, i.e., Java methods accessed from native code are only going to be included when they are necessary. > >? ? ?- The fallback mode of native-image for Helidon > > The fallback mode is not implemented for technical reasons, but only > for > legal reasons. Especially, it has nothing to do with Helidon (or any > other concrete application that supports Native Image). > > > I dunno that I understand "legal" reasons. Would you mind elaborating? Sorry, I cannot comment more on this. > >? ? ?- The tight intertwinglyness of compressed pointers and isolates > > This is a technical necessity: compressed pointers can only be used > when > references within the image heap are relative to the heap base - which > is exactly what isolates provide. The support for isolates is a > (positive) side effect of compressed pointers. > > > Compressed pointers could also be useful without multiple isolates, > though, no? Yes. But compressed pointers requires pointers that are relative to the image heap. So you should see things the other way round: compressed pointers provide the basis for multiple isolates, i.e., support for multiple isolates is just a small extension of all the code that was necessary for compressed pointers. > I know Jason Greene was submitted some heap-copying optimizations which > could've been used with compressed pointers, but without isolates. > > For our serverless or microservice or high-density-containers-on-a-pod > use-cases, multiple isolates seems... un-needed. > > But having compressed pointers is still desirable. > > > >? ? ?- The lazy class initiatialization changes > > Based on our experience and feedback from early adopters (and all the > effort you did for Quarkus was an important feedback for us too), it > became clear that the default needs to be "initialize classes at run > time". This is what Java developers are used to, and no application > will > work out-of-the-box if you change this. A lot of libraries and > frameworks of course want to take advantage of class initialization at > build time. We envision that libraries will ship with the appropriate > configuration, i.e., that Quarkus will ship with the configuration that > most classes are initialized at build time. > > I'm sorry that we rushed out these changes, but we felt that the time > window for a change like that was closing rapidly. > > > Sure, but open discussion would've been beneficial prior to the action > being taken. Yes, I hope we can improve that in the future. > >? ? ?- the LLVM effort > > I don't understand your concern here. What can be negative about > supporting more platforms via LLVM? > > > I'm not *opposed* to the LLVM effort, don't get me wrong. But as I'm > working on vanilla AArch64, I'm left wondering if the path I'm taking > will end up being orphaned in favor of the LLVM strategy. Am I wasting > my time? Should I be working with Johan on the LLVM stuff?I have no idea. No, native AArch64 support is still necessary for GraalVM. LLVM complicates the build process, greatly increases compile times, and will most likely never reach the peak performance of a native backend. All of that is acceptable if you want to quickly support a new architecture, or if you have company requirements that applications must ship with LLVM bitcode (Apple has such requirements for their app store). -Christian > It all boils back down to open communication and project governance, of > which I'm still not feeling super re-assured about. > > -Bob > > > -Christian > From bmcwhirt at redhat.com Wed May 1 18:32:29 2019 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Wed, 1 May 2019 14:32:29 -0400 Subject: Opensource, Community, Governance In-Reply-To: <887ccb09-46c9-b012-e216-72049c2600d2@oracle.com> References: <1ee090bc-7f95-9a8e-763b-169c886de744@oracle.com> <887ccb09-46c9-b012-e216-72049c2600d2@oracle.com> Message-ID: On Wed, May 1, 2019 at 2:13 PM Christian Wimmer wrote: > > On 5/1/19 10:39, Bob McWhirter wrote: > > > > > > On Wed, May 1, 2019 at 1:31 PM Christian Wimmer > > > > wrote: > > > > Hi Bob, > > > > Some answers to your Native Image related technical points: > > > > > - JNI over the C-ish "porting" of the JDK (removes DCE > > opportunities) > > > > We see this as the only feasible way to have a maintainable and > stable > > Native Image code base that works across multiple platforms (Linux, > > MacOS, Windows) and JDK versions (8, 11, latest). > > > > We also think that it is not going to impact the startup time and > > memory > > footprint of native images, but implementation is not complete enough > > yet to show this. > > > > > > Implicitly libjava.so will be included in its entirety, yes, since DCE > > can't see beyond the C calls and eliminate from there. > > Probably. That is only 230 KByte. Note that we still have DCE on the > Java side, i.e., Java methods accessed from native code are only going > to be included when they are necessary. > > > > - The fallback mode of native-image for Helidon > > > > The fallback mode is not implemented for technical reasons, but only > > for > > legal reasons. Especially, it has nothing to do with Helidon (or any > > other concrete application that supports Native Image). > > > > > > I dunno that I understand "legal" reasons. Would you mind elaborating? > > Sorry, I cannot comment more on this. > > > > - The tight intertwinglyness of compressed pointers and > isolates > > > > This is a technical necessity: compressed pointers can only be used > > when > > references within the image heap are relative to the heap base - > which > > is exactly what isolates provide. The support for isolates is a > > (positive) side effect of compressed pointers. > > > > > > Compressed pointers could also be useful without multiple isolates, > > though, no? > > Yes. But compressed pointers requires pointers that are relative to the > image heap. So you should see things the other way round: compressed > pointers provide the basis for multiple isolates, i.e., support for > multiple isolates is just a small extension of all the code that was > necessary for compressed pointers. > > > I know Jason Greene was submitted some heap-copying optimizations which > > could've been used with compressed pointers, but without isolates. > > > > For our serverless or microservice or high-density-containers-on-a-pod > > use-cases, multiple isolates seems... un-needed. > > > > But having compressed pointers is still desirable. > > > > > > > - The lazy class initiatialization changes > > > > Based on our experience and feedback from early adopters (and all the > > effort you did for Quarkus was an important feedback for us too), it > > became clear that the default needs to be "initialize classes at run > > time". This is what Java developers are used to, and no application > > will > > work out-of-the-box if you change this. A lot of libraries and > > frameworks of course want to take advantage of class initialization > at > > build time. We envision that libraries will ship with the appropriate > > configuration, i.e., that Quarkus will ship with the configuration > that > > most classes are initialized at build time. > > > > I'm sorry that we rushed out these changes, but we felt that the time > > window for a change like that was closing rapidly. > > > > > > Sure, but open discussion would've been beneficial prior to the action > > being taken. > > Yes, I hope we can improve that in the future. > I think that's the primary crux of the matter. There's obviously style and other gate checks on the code. A process, if you will. There's not just hope that the code is well-formatted and non-buggy. Is the GraalVM project willing to go beyond "hope" for improved communication and actually instill a governance process that is open and transparent? We are downstream, so decisions made without involvement somewhat remove control of our own destiny from us. Which is discomforting. Right or wrong, there's feelings that while there are N things we feel non-involved with, there are N*M more that we're not even aware of that will probably ultimately affect us (and all other downstream consumers). And we don't want to be caught unawares. Particularly since we are contributing both upstream and to the general ecosystem, we feel we have at least some standing in being concerned. > > > > - the LLVM effort > > > > I don't understand your concern here. What can be negative about > > supporting more platforms via LLVM? > > > > > > I'm not *opposed* to the LLVM effort, don't get me wrong. But as I'm > > working on vanilla AArch64, I'm left wondering if the path I'm taking > > will end up being orphaned in favor of the LLVM strategy. Am I wasting > > my time? Should I be working with Johan on the LLVM stuff?I have no idea. > > No, native AArch64 support is still necessary for GraalVM. LLVM > complicates the build process, greatly increases compile times, and will > most likely never reach the peak performance of a native backend. All of > that is acceptable if you want to quickly support a new architecture, or > if you have company requirements that applications must ship with LLVM > bitcode (Apple has such requirements for their app store). > Thanks, that's good to know. -Bob > > -Christian > > > > It all boils back down to open communication and project governance, of > > which I'm still not feeling super re-assured about. > > > > -Bob > > > > > > -Christian > > > From tom.rodriguez at oracle.com Thu May 2 00:44:38 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 May 2019 17:44:38 -0700 Subject: RFR(S) 8218700: infinite loop in HotSpotJVMCIMetaAccessContext.fromClass after OutOfMemoryError In-Reply-To: <53bcf718-e543-d40c-5486-58b98f66bcee@oracle.com> References: <53bcf718-e543-d40c-5486-58b98f66bcee@oracle.com> Message-ID: You'll need to update your webrev after Vladimir's push. This code has moved into HotSpootJVMCIRuntime.java. Maybe WeakReferenceHolder instead of WeakTypeRef? It needs a comment explaining that we're intentionally avoiding the use of ClassValue.remove as well. Shouldn't the ref field be volatile? ClassValue includes some barrier semantics and the new code needs similar guarantees. tom dean.long at oracle.com wrote on 4/26/19 12:09 PM: > https://bugs.openjdk.java.net/browse/JDK-8218700 > http://cr.openjdk.java.net/~dlong/8218700/webrev.2/ > > If we throw an OutOfMemoryError in the right place (see JDK-8222941), > HotSpotJVMCIMetaAccessContext.fromClass can go into an infinite loop > calling ClassValue.remove.? To work around the problem, reset the value > in a mutable cell instead of calling remove. > > dl From dean.long at oracle.com Fri May 3 06:47:29 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 2 May 2019 23:47:29 -0700 Subject: RFR(S) 8218700: infinite loop in HotSpotJVMCIMetaAccessContext.fromClass after OutOfMemoryError In-Reply-To: References: <53bcf718-e543-d40c-5486-58b98f66bcee@oracle.com> Message-ID: <1e91a8e6-16bc-2ae0-8aaf-830e1c6b450a@oracle.com> On 5/1/19 5:44 PM, Tom Rodriguez wrote: > You'll need to update your webrev after Vladimir's push.? This code > has moved into HotSpootJVMCIRuntime.java. > Here's the updated version: http://cr.openjdk.java.net/~dlong/8218700/webrev.3/ > Maybe WeakReferenceHolder instead of WeakTypeRef?? It needs a comment > explaining that we're intentionally avoiding the use of > ClassValue.remove as well.? Shouldn't the ref field be volatile? > ClassValue includes some barrier semantics and the new code needs > similar guarantees. > I went ahead and made it volatile, but I don't understand what guarantee was missing, and what problem we want to eliminate, unless it is to reduce the possibility of duplicates.? But the fix for JDK-8201248 assumes that duplicates are possible, so I wasn't worried about that. dl > tom > > dean.long at oracle.com wrote on 4/26/19 12:09 PM: >> https://bugs.openjdk.java.net/browse/JDK-8218700 >> http://cr.openjdk.java.net/~dlong/8218700/webrev.2/ >> >> If we throw an OutOfMemoryError in the right place (see JDK-8222941), >> HotSpotJVMCIMetaAccessContext.fromClass can go into an infinite loop >> calling ClassValue.remove.? To work around the problem, reset the >> value in a mutable cell instead of calling remove. >> >> dl From tom.rodriguez at oracle.com Fri May 3 17:45:02 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 3 May 2019 10:45:02 -0700 Subject: RFR(S) 8218700: infinite loop in HotSpotJVMCIMetaAccessContext.fromClass after OutOfMemoryError In-Reply-To: <1e91a8e6-16bc-2ae0-8aaf-830e1c6b450a@oracle.com> References: <53bcf718-e543-d40c-5486-58b98f66bcee@oracle.com> <1e91a8e6-16bc-2ae0-8aaf-830e1c6b450a@oracle.com> Message-ID: <3d15e9f0-8717-ac82-678d-2139dcfec7f8@oracle.com> dean.long at oracle.com wrote on 5/2/19 11:47 PM: > On 5/1/19 5:44 PM, Tom Rodriguez wrote: >> You'll need to update your webrev after Vladimir's push.? This code >> has moved into HotSpootJVMCIRuntime.java. >> > > Here's the updated version: > > http://cr.openjdk.java.net/~dlong/8218700/webrev.3/ Looks good to me. > >> Maybe WeakReferenceHolder instead of WeakTypeRef?? It needs a comment >> explaining that we're intentionally avoiding the use of >> ClassValue.remove as well.? Shouldn't the ref field be volatile? >> ClassValue includes some barrier semantics and the new code needs >> similar guarantees. >> > > I went ahead and made it volatile, but I don't understand what guarantee > was missing, and what problem we want to eliminate, unless it is to > reduce the possibility of duplicates.? But the fix for JDK-8201248 > assumes that duplicates are possible, so I wasn't worried about that. We're publishing a mutable locally created object to other threads so it seems like we need some sort of ordering barrier when we do so. Presumably the ClassValue would normally provide some ordering though it's a little unclear from the javadoc if it makes any such guarantees. Is the extra volatile unneeded? tom > > dl > >> tom >> >> dean.long at oracle.com wrote on 4/26/19 12:09 PM: >>> https://bugs.openjdk.java.net/browse/JDK-8218700 >>> http://cr.openjdk.java.net/~dlong/8218700/webrev.2/ >>> >>> If we throw an OutOfMemoryError in the right place (see JDK-8222941), >>> HotSpotJVMCIMetaAccessContext.fromClass can go into an infinite loop >>> calling ClassValue.remove.? To work around the problem, reset the >>> value in a mutable cell instead of calling remove. >>> >>> dl > From dean.long at oracle.com Fri May 3 18:55:18 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 3 May 2019 11:55:18 -0700 Subject: RFR(S) 8218700: infinite loop in HotSpotJVMCIMetaAccessContext.fromClass after OutOfMemoryError In-Reply-To: <3d15e9f0-8717-ac82-678d-2139dcfec7f8@oracle.com> References: <53bcf718-e543-d40c-5486-58b98f66bcee@oracle.com> <1e91a8e6-16bc-2ae0-8aaf-830e1c6b450a@oracle.com> <3d15e9f0-8717-ac82-678d-2139dcfec7f8@oracle.com> Message-ID: <415627e2-165c-14a0-a069-2e01de5574d4@oracle.com> On 5/3/19 10:45 AM, Tom Rodriguez wrote: > > > dean.long at oracle.com wrote on 5/2/19 11:47 PM: >> On 5/1/19 5:44 PM, Tom Rodriguez wrote: >>> You'll need to update your webrev after Vladimir's push.? This code >>> has moved into HotSpootJVMCIRuntime.java. >>> >> >> Here's the updated version: >> >> http://cr.openjdk.java.net/~dlong/8218700/webrev.3/ > > Looks good to me. Thanks for the review. > >> >>> Maybe WeakReferenceHolder instead of WeakTypeRef?? It needs a >>> comment explaining that we're intentionally avoiding the use of >>> ClassValue.remove as well. Shouldn't the ref field be volatile? >>> ClassValue includes some barrier semantics and the new code needs >>> similar guarantees. >>> >> >> I went ahead and made it volatile, but I don't understand what >> guarantee was missing, and what problem we want to eliminate, unless >> it is to reduce the possibility of duplicates.? But the fix for >> JDK-8201248 assumes that duplicates are possible, so I wasn't worried >> about that. > > We're publishing a mutable locally created object to other threads so > it seems like we need some sort of ordering barrier when we do so. > Presumably the ClassValue would normally provide some ordering though > it's a little unclear from the javadoc if it makes any such > guarantees. Is the extra volatile unneeded? > ClassValue uses volatile internally so that an unsynchronized read sees the latest version.? Using a volatile here should help in a similar way, but I believe there is still a race that allows duplicates if the weak reference gets cleared by GC.? To prevent all duplicates I think we would need both volatile and more synchronization. dl > tom > >> >> dl >> >>> tom >>> >>> dean.long at oracle.com wrote on 4/26/19 12:09 PM: >>>> https://bugs.openjdk.java.net/browse/JDK-8218700 >>>> http://cr.openjdk.java.net/~dlong/8218700/webrev.2/ >>>> >>>> If we throw an OutOfMemoryError in the right place (see >>>> JDK-8222941), HotSpotJVMCIMetaAccessContext.fromClass can go into >>>> an infinite loop calling ClassValue.remove.? To work around the >>>> problem, reset the value in a mutable cell instead of calling remove. >>>> >>>> dl >> From jesper.wilhelmsson at oracle.com Sat May 4 01:13:04 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Sat, 4 May 2019 03:13:04 +0200 Subject: RFR: JDK-8222665 - Update Graal Message-ID: <74DF69E0-2792-492E-99DC-BEA707375BBB@oracle.com> Hi, Please review the patch to integrate recent Graal changes into OpenJDK. Graal tip to integrate: 556bed673d5bccbed227e2e108dc36eaf00239eb Bug: https://bugs.openjdk.java.net/browse/JDK-8222665 Webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/ This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. Thanks, /Jesper From vladimir.kozlov at oracle.com Sat May 4 02:04:57 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 3 May 2019 19:04:57 -0700 Subject: RFR: JDK-8222665 - Update Graal In-Reply-To: <74DF69E0-2792-492E-99DC-BEA707375BBB@oracle.com> References: <74DF69E0-2792-492E-99DC-BEA707375BBB@oracle.com> Message-ID: <998bc1f0-ba55-6c06-21ed-349267a8271f@oracle.com> This is too old Graal's tip. You need at least take a29972bd6677f2e8165438caf1073ff596b95f26 to get next changes and to avoid rollback needed changes listed in overwrite file. Otherwise you will get tests failures. my changes: [GR-14499] Update jdk9 version of GraalServices.java and Dean's: [GR-15582] Replace getCompilationLevelAdjustment with excludeFromJVMCICompilation after JDK-8219403. Vladimir On 5/3/19 6:13 PM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review the patch to integrate recent Graal changes into OpenJDK. > Graal tip to integrate: 556bed673d5bccbed227e2e108dc36eaf00239eb > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222665 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/ > > This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. > > Thanks, > /Jesper > From jesper.wilhelmsson at oracle.com Sat May 4 02:15:58 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Sat, 4 May 2019 04:15:58 +0200 Subject: RFR: JDK-8222665 - Update Graal In-Reply-To: <998bc1f0-ba55-6c06-21ed-349267a8271f@oracle.com> References: <74DF69E0-2792-492E-99DC-BEA707375BBB@oracle.com> <998bc1f0-ba55-6c06-21ed-349267a8271f@oracle.com> Message-ID: <5C486583-81AC-4372-8B5A-8A7B369E8BCE@oracle.com> Ok, then I withdraw this RFR and we need to wait until we have a more recent clean Graal nightly. Thanks, /Jesper > On 4 May 2019, at 04:04, Vladimir Kozlov wrote: > > This is too old Graal's tip. > > You need at least take a29972bd6677f2e8165438caf1073ff596b95f26 to get next changes and to avoid rollback needed changes listed in overwrite file. Otherwise you will get tests failures. > > my changes: [GR-14499] Update jdk9 version of GraalServices.java > and Dean's: [GR-15582] Replace getCompilationLevelAdjustment with excludeFromJVMCICompilation after JDK-8219403. > > Vladimir > > On 5/3/19 6:13 PM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> Please review the patch to integrate recent Graal changes into OpenJDK. >> Graal tip to integrate: 556bed673d5bccbed227e2e108dc36eaf00239eb >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222665 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/ >> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >> Thanks, >> /Jesper From xiaoming.gu at gmail.com Mon May 6 02:39:00 2019 From: xiaoming.gu at gmail.com (xiaoming gu) Date: Mon, 6 May 2019 10:39:00 +0800 Subject: When will we have a new RC based on 8u212? Message-ID: Hi folks, 8u212 got released weeks ago. But the latest RC16 is still based on 8u202. I'm wondering when we will have a new RC based on 8u212. Thanks, Xiaoming From doug.simon at oracle.com Mon May 6 06:19:16 2019 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 6 May 2019 08:19:16 +0200 Subject: When will we have a new RC based on 8u212? In-Reply-To: References: Message-ID: <78859DD4-717F-44A0-91F2-66795E8375F1@oracle.com> There should be another release based on 8u212 within a week. -Doug > On 6 May 2019, at 04:39, xiaoming gu wrote: > > Hi folks, > > 8u212 got released weeks ago. But the latest RC16 is still based on 8u202. > I'm wondering when we will have a new RC based on 8u212. > > Thanks, > Xiaoming From Pengfei.Li at arm.com Mon May 6 10:41:00 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 6 May 2019 10:41:00 +0000 Subject: RFR(trivial): 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher In-Reply-To: <803B96E9-8EDD-4469-9137-63451E825724@oracle.com> References: <803B96E9-8EDD-4469-9137-63451E825724@oracle.com> Message-ID: Thanks Igor. Do I need another reviewer for this trivial change? // Also cc graal-dev list -- Thanks, Pengfei > > Looks good to me. > > // moved to hotspot compiler list > > ? Igor > > > On May 4, 2019, at 6:32 PM, Pengfei Li (Arm Technology China) > wrote: > > > > Hi, > > > > Please help review this trivial change on GraalUnitTestLauncher. > > > > Webrev: http://cr.openjdk.java.net/~pli/rfr/8223054/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223054 > > > > Current graal unit test in jtreg requires junit-4.12.jar as a dependency. In > GraalUnitTestLauncher.java, we put the path of this file into graalJarsCP and > concat it with existing classpath. But existing classpath may contain another > version of junit with which the jtreg tool is built. (According to OpenJDK > "Building jtreg" webpage[1], the recommended version of Junit to build jtreg > is junit-4.10). > > > > In this patch, graalJarsCP is put before existing classpath returned by > System.getProperty() when generating the new classpath string to avoid > incompatibility issues. Jteg graal unit test cases passed after this change. > > > > [1] https://openjdk.java.net/jtreg/build.html > > > > -- > > Thanks, > > Pengfei > > From xiaoming.gu at gmail.com Mon May 6 14:00:01 2019 From: xiaoming.gu at gmail.com (xiaoming gu) Date: Mon, 6 May 2019 22:00:01 +0800 Subject: When will we have a new RC based on 8u212? In-Reply-To: <78859DD4-717F-44A0-91F2-66795E8375F1@oracle.com> References: <78859DD4-717F-44A0-91F2-66795E8375F1@oracle.com> Message-ID: Awesome. Many thanks. On Mon, May 6, 2019 at 2:19 PM Doug Simon wrote: > There should be another release based on 8u212 within a week. > > -Doug > > > On 6 May 2019, at 04:39, xiaoming gu wrote: > > > > Hi folks, > > > > 8u212 got released weeks ago. But the latest RC16 is still based on > 8u202. > > I'm wondering when we will have a new RC based on 8u212. > > > > Thanks, > > Xiaoming > > From jesper.wilhelmsson at oracle.com Mon May 6 14:18:16 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 6 May 2019 16:18:16 +0200 Subject: RFR: JDK-8222665 - Update Graal Message-ID: Hi, Please review the patch to integrate recent Graal changes into OpenJDK. Graal tip to integrate: 88c3adb11b1bc10f6443435685b65227e7584b43 Bug: https://bugs.openjdk.java.net/browse/JDK-8222665 Webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/ This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. Thanks, /Jesper From vladimir.kozlov at oracle.com Mon May 6 18:11:38 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 May 2019 11:11:38 -0700 Subject: RFR: JDK-8222665 - Update Graal In-Reply-To: References: Message-ID: <5ff3bca1-2ca5-24d4-976a-0d3ffdcaa874@oracle.com> It seems webrev is wrong. Jesper, is it possible you sent old webrev? I looked on patch (from submitted test job) and it seems correct. For example, from next changes [1] it correctly updated only Copyright year in JDK (in JDK it was old 2018). But webrev shows reversed changes [2]. The patch does not have IsGraalPredicate.java changes. But webrev has it with reversed changes again [3]. The same for GraalServices.java file changes. No changes in patch but reverse changes in webrev. Thanks, Vladimir [1] https://github.com/oracle/graal/commit/4fa819e120212393122b55e2c95e9de7c6101ccf#diff-3f2f58ebefeb6c5489c4d264ec8ae502 [2] http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java.udiff.html [3] http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/IsGraalPredicate.java.udiff.html On 5/6/19 7:18 AM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review the patch to integrate recent Graal changes into OpenJDK. > Graal tip to integrate: 88c3adb11b1bc10f6443435685b65227e7584b43 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222665 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/ > > This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. > > Thanks, > /Jesper > From jesper.wilhelmsson at oracle.com Mon May 6 18:32:37 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 6 May 2019 20:32:37 +0200 Subject: RFR: JDK-8222665 - Update Graal In-Reply-To: <5ff3bca1-2ca5-24d4-976a-0d3ffdcaa874@oracle.com> References: <5ff3bca1-2ca5-24d4-976a-0d3ffdcaa874@oracle.com> Message-ID: Sorry! I forgot to remove the old one so the script automatically created webrev.01 but still linked to the old in the email. Current webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.01/ /Jesper > On 6 May 2019, at 20:11, Vladimir Kozlov wrote: > > It seems webrev is wrong. Jesper, is it possible you sent old webrev? > > I looked on patch (from submitted test job) and it seems correct. For example, from next changes [1] it correctly updated only Copyright year in JDK (in JDK it was old 2018). > But webrev shows reversed changes [2]. > > The patch does not have IsGraalPredicate.java changes. But webrev has it with reversed changes again [3]. > > The same for GraalServices.java file changes. No changes in patch but reverse changes in webrev. > > Thanks, > Vladimir > > [1] https://github.com/oracle/graal/commit/4fa819e120212393122b55e2c95e9de7c6101ccf#diff-3f2f58ebefeb6c5489c4d264ec8ae502 > > [2] http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java.udiff.html > > [3] http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/IsGraalPredicate.java.udiff.html > > On 5/6/19 7:18 AM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> Please review the patch to integrate recent Graal changes into OpenJDK. >> Graal tip to integrate: 88c3adb11b1bc10f6443435685b65227e7584b43 > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222665 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/ >> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >> Thanks, >> /Jesper From vladimir.kozlov at oracle.com Mon May 6 18:43:39 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 May 2019 11:43:39 -0700 Subject: RFR: JDK-8222665 - Update Graal In-Reply-To: References: <5ff3bca1-2ca5-24d4-976a-0d3ffdcaa874@oracle.com> Message-ID: Yes, this one looks good! And testing seems fine - most failures are timeouts due to Graal runs with -Xcomp -XX:-TieredCompilation which is known issue 8222524. Thanks, Vladimir On 5/6/19 11:32 AM, jesper.wilhelmsson at oracle.com wrote: > Sorry! ?I forgot to remove the old one so the script automatically created webrev.01 but still linked to the old in the > email. > > Current webrev: > http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.01/ > > /Jesper > >> On 6 May 2019, at 20:11, Vladimir Kozlov > wrote: >> >> It seems webrev is wrong. Jesper, is it possible you sent old webrev? >> >> I looked on patch (from submitted test job) and it seems correct. For example, from next changes [1] it correctly >> updated only Copyright year in JDK (in JDK it was old 2018). >> But webrev shows reversed changes [2]. >> >> The patch does not have IsGraalPredicate.java changes. But webrev has it with reversed changes again [3]. >> >> The same for GraalServices.java file changes. No changes in patch but reverse changes in webrev. >> >> Thanks, >> Vladimir >> >> [1] https://github.com/oracle/graal/commit/4fa819e120212393122b55e2c95e9de7c6101ccf#diff-3f2f58ebefeb6c5489c4d264ec8ae502 >> >> [2] >> http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java.udiff.html >> >> [3] >> http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/IsGraalPredicate.java.udiff.html >> >> On 5/6/19 7:18 AM, jesper.wilhelmsson at oracle.com wrote: >>> Hi, >>> Please review the patch to integrate recent Graal changes into OpenJDK. >>> Graal tip to integrate: 88c3adb11b1bc10f6443435685b65227e7584b43 > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222665 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/ >>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>> Thanks, >>> /Jesper > From dean.long at oracle.com Mon May 6 18:45:33 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 6 May 2019 11:45:33 -0700 Subject: RFR(trivial): 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher In-Reply-To: References: <803B96E9-8EDD-4469-9137-63451E825724@oracle.com> Message-ID: Looks good (and trivial) to me. dl On 5/6/19 3:41 AM, Pengfei Li (Arm Technology China) wrote: > Thanks Igor. Do I need another reviewer for this trivial change? > > // Also cc graal-dev list > > -- > Thanks, > Pengfei > >> Looks good to me. >> >> // moved to hotspot compiler list >> >> ? Igor >> >>> On May 4, 2019, at 6:32 PM, Pengfei Li (Arm Technology China) >> wrote: >>> Hi, >>> >>> Please help review this trivial change on GraalUnitTestLauncher. >>> >>> Webrev: http://cr.openjdk.java.net/~pli/rfr/8223054/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223054 >>> >>> Current graal unit test in jtreg requires junit-4.12.jar as a dependency. In >> GraalUnitTestLauncher.java, we put the path of this file into graalJarsCP and >> concat it with existing classpath. But existing classpath may contain another >> version of junit with which the jtreg tool is built. (According to OpenJDK >> "Building jtreg" webpage[1], the recommended version of Junit to build jtreg >> is junit-4.10). >>> In this patch, graalJarsCP is put before existing classpath returned by >> System.getProperty() when generating the new classpath string to avoid >> incompatibility issues. Jteg graal unit test cases passed after this change. >>> [1] https://openjdk.java.net/jtreg/build.html >>> >>> -- >>> Thanks, >>> Pengfei >>> From jesper.wilhelmsson at oracle.com Mon May 6 19:19:55 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 6 May 2019 21:19:55 +0200 Subject: RFR: JDK-8222665 - Update Graal In-Reply-To: References: <5ff3bca1-2ca5-24d4-976a-0d3ffdcaa874@oracle.com> Message-ID: <6D547293-39BD-4652-8DD4-6F59D41C0C35@oracle.com> Thanks Vladimir! What about the overwritten diff? Should it be applied? /Jesper > On 6 May 2019, at 20:43, Vladimir Kozlov wrote: > > Yes, this one looks good! And testing seems fine - most failures are timeouts due to Graal runs with -Xcomp -XX:-TieredCompilation which is known issue 8222524. > > Thanks, > Vladimir > > On 5/6/19 11:32 AM, jesper.wilhelmsson at oracle.com wrote: >> Sorry! I forgot to remove the old one so the script automatically created webrev.01 but still linked to the old in the email. >> Current webrev: >> http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.01/ >> /Jesper >>> On 6 May 2019, at 20:11, Vladimir Kozlov > wrote: >>> >>> It seems webrev is wrong. Jesper, is it possible you sent old webrev? >>> >>> I looked on patch (from submitted test job) and it seems correct. For example, from next changes [1] it correctly updated only Copyright year in JDK (in JDK it was old 2018). >>> But webrev shows reversed changes [2]. >>> >>> The patch does not have IsGraalPredicate.java changes. But webrev has it with reversed changes again [3]. >>> >>> The same for GraalServices.java file changes. No changes in patch but reverse changes in webrev. >>> >>> Thanks, >>> Vladimir >>> >>> [1] https://github.com/oracle/graal/commit/4fa819e120212393122b55e2c95e9de7c6101ccf#diff-3f2f58ebefeb6c5489c4d264ec8ae502 >>> >>> [2] http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java.udiff.html >>> >>> [3] http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/IsGraalPredicate.java.udiff.html >>> >>> On 5/6/19 7:18 AM, jesper.wilhelmsson at oracle.com wrote: >>>> Hi, >>>> Please review the patch to integrate recent Graal changes into OpenJDK. >>>> Graal tip to integrate: 88c3adb11b1bc10f6443435685b65227e7584b43 > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222665 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/ >>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>>> Thanks, >>>> /Jesper From vladimir.kozlov at oracle.com Mon May 6 19:43:00 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 May 2019 12:43:00 -0700 Subject: RFR: JDK-8222665 - Update Graal In-Reply-To: <6D547293-39BD-4652-8DD4-6F59D41C0C35@oracle.com> References: <5ff3bca1-2ca5-24d4-976a-0d3ffdcaa874@oracle.com> <6D547293-39BD-4652-8DD4-6F59D41C0C35@oracle.com> Message-ID: On 5/6/19 12:19 PM, jesper.wilhelmsson at oracle.com wrote: > Thanks Vladimir! > > What about the overwritten diff? Should it be applied? No need to apply. The overwritten diffs were pushed into Graal master and your last changes have them. I verified it. Thanks, Vladimir > /Jesper > >> On 6 May 2019, at 20:43, Vladimir Kozlov wrote: >> >> Yes, this one looks good! And testing seems fine - most failures are timeouts due to Graal runs with -Xcomp -XX:-TieredCompilation which is known issue 8222524. >> >> Thanks, >> Vladimir >> >> On 5/6/19 11:32 AM, jesper.wilhelmsson at oracle.com wrote: >>> Sorry! I forgot to remove the old one so the script automatically created webrev.01 but still linked to the old in the email. >>> Current webrev: >>> http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.01/ >>> /Jesper >>>> On 6 May 2019, at 20:11, Vladimir Kozlov > wrote: >>>> >>>> It seems webrev is wrong. Jesper, is it possible you sent old webrev? >>>> >>>> I looked on patch (from submitted test job) and it seems correct. For example, from next changes [1] it correctly updated only Copyright year in JDK (in JDK it was old 2018). >>>> But webrev shows reversed changes [2]. >>>> >>>> The patch does not have IsGraalPredicate.java changes. But webrev has it with reversed changes again [3]. >>>> >>>> The same for GraalServices.java file changes. No changes in patch but reverse changes in webrev. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> [1] https://github.com/oracle/graal/commit/4fa819e120212393122b55e2c95e9de7c6101ccf#diff-3f2f58ebefeb6c5489c4d264ec8ae502 >>>> >>>> [2] http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java.udiff.html >>>> >>>> [3] http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/IsGraalPredicate.java.udiff.html >>>> >>>> On 5/6/19 7:18 AM, jesper.wilhelmsson at oracle.com wrote: >>>>> Hi, >>>>> Please review the patch to integrate recent Graal changes into OpenJDK. >>>>> Graal tip to integrate: 88c3adb11b1bc10f6443435685b65227e7584b43 > >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222665 >>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/ >>>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>>>> Thanks, >>>>> /Jesper > From jesper.wilhelmsson at oracle.com Mon May 6 19:48:29 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 6 May 2019 21:48:29 +0200 Subject: RFR: JDK-8222665 - Update Graal In-Reply-To: References: <5ff3bca1-2ca5-24d4-976a-0d3ffdcaa874@oracle.com> <6D547293-39BD-4652-8DD4-6F59D41C0C35@oracle.com> Message-ID: Thank you! /Jesper > On 6 May 2019, at 21:43, Vladimir Kozlov wrote: > > On 5/6/19 12:19 PM, jesper.wilhelmsson at oracle.com wrote: >> Thanks Vladimir! >> What about the overwritten diff? Should it be applied? > > No need to apply. The overwritten diffs were pushed into Graal master and your last changes have them. I verified it. > > Thanks, > Vladimir > >> /Jesper >>> On 6 May 2019, at 20:43, Vladimir Kozlov wrote: >>> >>> Yes, this one looks good! And testing seems fine - most failures are timeouts due to Graal runs with -Xcomp -XX:-TieredCompilation which is known issue 8222524. >>> >>> Thanks, >>> Vladimir >>> >>> On 5/6/19 11:32 AM, jesper.wilhelmsson at oracle.com wrote: >>>> Sorry! I forgot to remove the old one so the script automatically created webrev.01 but still linked to the old in the email. >>>> Current webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.01/ >>>> /Jesper >>>>> On 6 May 2019, at 20:11, Vladimir Kozlov > wrote: >>>>> >>>>> It seems webrev is wrong. Jesper, is it possible you sent old webrev? >>>>> >>>>> I looked on patch (from submitted test job) and it seems correct. For example, from next changes [1] it correctly updated only Copyright year in JDK (in JDK it was old 2018). >>>>> But webrev shows reversed changes [2]. >>>>> >>>>> The patch does not have IsGraalPredicate.java changes. But webrev has it with reversed changes again [3]. >>>>> >>>>> The same for GraalServices.java file changes. No changes in patch but reverse changes in webrev. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> [1] https://github.com/oracle/graal/commit/4fa819e120212393122b55e2c95e9de7c6101ccf#diff-3f2f58ebefeb6c5489c4d264ec8ae502 >>>>> >>>>> [2] http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java.udiff.html >>>>> >>>>> [3] http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/IsGraalPredicate.java.udiff.html >>>>> >>>>> On 5/6/19 7:18 AM, jesper.wilhelmsson at oracle.com wrote: >>>>>> Hi, >>>>>> Please review the patch to integrate recent Graal changes into OpenJDK. >>>>>> Graal tip to integrate: 88c3adb11b1bc10f6443435685b65227e7584b43 > >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222665 >>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8222665/webrev.00/ >>>>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>>>>> Thanks, >>>>>> /Jesper From vladimir.kozlov at oracle.com Mon May 6 21:34:25 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 May 2019 14:34:25 -0700 Subject: RFR(S) 8218700: infinite loop in HotSpotJVMCIMetaAccessContext.fromClass after OutOfMemoryError In-Reply-To: <415627e2-165c-14a0-a069-2e01de5574d4@oracle.com> References: <53bcf718-e543-d40c-5486-58b98f66bcee@oracle.com> <1e91a8e6-16bc-2ae0-8aaf-830e1c6b450a@oracle.com> <3d15e9f0-8717-ac82-678d-2139dcfec7f8@oracle.com> <415627e2-165c-14a0-a069-2e01de5574d4@oracle.com> Message-ID: <0817ed0f-a912-4ffc-6a4a-6623802b28ec@oracle.com> Looks good to me too. Thanks Vladimir On 5/3/19 11:55 AM, dean.long at oracle.com wrote: > On 5/3/19 10:45 AM, Tom Rodriguez wrote: >> >> >> dean.long at oracle.com wrote on 5/2/19 11:47 PM: >>> On 5/1/19 5:44 PM, Tom Rodriguez wrote: >>>> You'll need to update your webrev after Vladimir's push.? This code has moved into HotSpootJVMCIRuntime.java. >>>> >>> >>> Here's the updated version: >>> >>> http://cr.openjdk.java.net/~dlong/8218700/webrev.3/ >> >> Looks good to me. > > Thanks for the review. > >> >>> >>>> Maybe WeakReferenceHolder instead of WeakTypeRef?? It needs a comment explaining that we're intentionally avoiding >>>> the use of ClassValue.remove as well. Shouldn't the ref field be volatile? ClassValue includes some barrier >>>> semantics and the new code needs similar guarantees. >>>> >>> >>> I went ahead and made it volatile, but I don't understand what guarantee was missing, and what problem we want to >>> eliminate, unless it is to reduce the possibility of duplicates.? But the fix for JDK-8201248 assumes that duplicates >>> are possible, so I wasn't worried about that. >> >> We're publishing a mutable locally created object to other threads so it seems like we need some sort of ordering >> barrier when we do so. Presumably the ClassValue would normally provide some ordering though it's a little unclear >> from the javadoc if it makes any such guarantees. Is the extra volatile unneeded? >> > > ClassValue uses volatile internally so that an unsynchronized read sees the latest version.? Using a volatile here > should help in a similar way, but I believe there is still a race that allows duplicates if the weak reference gets > cleared by GC.? To prevent all duplicates I think we would need both volatile and more synchronization. > > dl > >> tom >> >>> >>> dl >>> >>>> tom >>>> >>>> dean.long at oracle.com wrote on 4/26/19 12:09 PM: >>>>> https://bugs.openjdk.java.net/browse/JDK-8218700 >>>>> http://cr.openjdk.java.net/~dlong/8218700/webrev.2/ >>>>> >>>>> If we throw an OutOfMemoryError in the right place (see JDK-8222941), HotSpotJVMCIMetaAccessContext.fromClass can >>>>> go into an infinite loop calling ClassValue.remove.? To work around the problem, reset the value in a mutable cell >>>>> instead of calling remove. >>>>> >>>>> dl >>> > From dean.long at oracle.com Tue May 7 03:28:37 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 6 May 2019 20:28:37 -0700 Subject: RFR(S) 8218700: infinite loop in HotSpotJVMCIMetaAccessContext.fromClass after OutOfMemoryError In-Reply-To: <0817ed0f-a912-4ffc-6a4a-6623802b28ec@oracle.com> References: <53bcf718-e543-d40c-5486-58b98f66bcee@oracle.com> <1e91a8e6-16bc-2ae0-8aaf-830e1c6b450a@oracle.com> <3d15e9f0-8717-ac82-678d-2139dcfec7f8@oracle.com> <415627e2-165c-14a0-a069-2e01de5574d4@oracle.com> <0817ed0f-a912-4ffc-6a4a-6623802b28ec@oracle.com> Message-ID: Thanks Vladimir. dl On 5/6/19 2:34 PM, Vladimir Kozlov wrote: > Looks good to me too. > > Thanks > Vladimir > > On 5/3/19 11:55 AM, dean.long at oracle.com wrote: >> On 5/3/19 10:45 AM, Tom Rodriguez wrote: >>> >>> >>> dean.long at oracle.com wrote on 5/2/19 11:47 PM: >>>> On 5/1/19 5:44 PM, Tom Rodriguez wrote: >>>>> You'll need to update your webrev after Vladimir's push.? This >>>>> code has moved into HotSpootJVMCIRuntime.java. >>>>> >>>> >>>> Here's the updated version: >>>> >>>> http://cr.openjdk.java.net/~dlong/8218700/webrev.3/ >>> >>> Looks good to me. >> >> Thanks for the review. >> >>> >>>> >>>>> Maybe WeakReferenceHolder instead of WeakTypeRef?? It needs a >>>>> comment explaining that we're intentionally avoiding the use of >>>>> ClassValue.remove as well. Shouldn't the ref field be volatile? >>>>> ClassValue includes some barrier semantics and the new code needs >>>>> similar guarantees. >>>>> >>>> >>>> I went ahead and made it volatile, but I don't understand what >>>> guarantee was missing, and what problem we want to eliminate, >>>> unless it is to reduce the possibility of duplicates.? But the fix >>>> for JDK-8201248 assumes that duplicates are possible, so I wasn't >>>> worried about that. >>> >>> We're publishing a mutable locally created object to other threads >>> so it seems like we need some sort of ordering barrier when we do >>> so. Presumably the ClassValue would normally provide some ordering >>> though it's a little unclear from the javadoc if it makes any such >>> guarantees. Is the extra volatile unneeded? >>> >> >> ClassValue uses volatile internally so that an unsynchronized read >> sees the latest version.? Using a volatile here should help in a >> similar way, but I believe there is still a race that allows >> duplicates if the weak reference gets cleared by GC.? To prevent all >> duplicates I think we would need both volatile and more synchronization. >> >> dl >> >>> tom >>> >>>> >>>> dl >>>> >>>>> tom >>>>> >>>>> dean.long at oracle.com wrote on 4/26/19 12:09 PM: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8218700 >>>>>> http://cr.openjdk.java.net/~dlong/8218700/webrev.2/ >>>>>> >>>>>> If we throw an OutOfMemoryError in the right place (see >>>>>> JDK-8222941), HotSpotJVMCIMetaAccessContext.fromClass can go into >>>>>> an infinite loop calling ClassValue.remove. To work around the >>>>>> problem, reset the value in a mutable cell instead of calling >>>>>> remove. >>>>>> >>>>>> dl >>>> >> From Pengfei.Li at arm.com Wed May 8 10:15:21 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Wed, 8 May 2019 10:15:21 +0000 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled Message-ID: Hi, Could anyone help review this patch (tiny change on 75 test files)? Webrev: http://cr.openjdk.java.net/~pli/rfr/8223427/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8223427 JVMCI compiler supports only a few OpenJDK GCs (only Serial, Parallel, ParallelOld and G1). In current jtreg cases, when Graal is enabled, other GC test cases are skipped except Shenandoah. We should add "!vm.graal.enabled" together with the "@requires vm.gc.Shenandoah" annotation in gc test cases to skip Shenandoah as well. -- Thanks, Pengfei From shade at redhat.com Wed May 8 11:16:23 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 May 2019 13:16:23 +0200 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled In-Reply-To: References: Message-ID: On 5/8/19 12:15 PM, Pengfei Li (Arm Technology China) wrote: > Could anyone help review this patch (tiny change on 75 test files)? > > Webrev: http://cr.openjdk.java.net/~pli/rfr/8223427/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8223427 Looks good. We already have a few tests that do "@requires vm.gc.Shenandoah & !vm.graal.enabled". -Aleksey From Pengfei.Li at arm.com Thu May 9 05:34:03 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 9 May 2019 05:34:03 +0000 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled In-Reply-To: References: Message-ID: Thanks Aleksey. Is it required to have another reviewer for this change? -- Thanks, Pengfei > > Could anyone help review this patch (tiny change on 75 test files)? > > > > Webrev: http://cr.openjdk.java.net/~pli/rfr/8223427/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223427 > > Looks good. > > We already have a few tests that do "@requires vm.gc.Shenandoah > & !vm.graal.enabled". > > -Aleksey From shade at redhat.com Thu May 9 07:29:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 9 May 2019 09:29:57 +0200 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled In-Reply-To: References: Message-ID: <29c11b50-5d85-a68b-573d-2e5116c4a2da@redhat.com> Seeing that it is trivial and only affects Shenandoah tests, I'd say one review is enough. Do you need a sponsor to push? -Aleksey On 5/9/19 7:34 AM, Pengfei Li (Arm Technology China) wrote: > Thanks Aleksey. Is it required to have another reviewer for this change? > > -- > Thanks, > Pengfei > >>> Could anyone help review this patch (tiny change on 75 test files)? >>> >>> Webrev: http://cr.openjdk.java.net/~pli/rfr/8223427/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223427 From Pengfei.Li at arm.com Thu May 9 07:33:24 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 9 May 2019 07:33:24 +0000 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled In-Reply-To: <29c11b50-5d85-a68b-573d-2e5116c4a2da@redhat.com> References: <29c11b50-5d85-a68b-573d-2e5116c4a2da@redhat.com> Message-ID: Hi Aleksey, > Seeing that it is trivial and only affects Shenandoah tests, I'd say one review is > enough. > > Do you need a sponsor to push? Yes, I would be happy if you could help to push. -- Thanks, Pengfei From shade at redhat.com Thu May 9 08:09:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 9 May 2019 10:09:08 +0200 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled In-Reply-To: References: <29c11b50-5d85-a68b-573d-2e5116c4a2da@redhat.com> Message-ID: On 5/9/19 9:33 AM, Pengfei Li (Arm Technology China) wrote: > Hi Aleksey, > >> Seeing that it is trivial and only affects Shenandoah tests, I'd say one review is >> enough. >> >> Do you need a sponsor to push? > > Yes, I would be happy if you could help to push. There: http://hg.openjdk.java.net/jdk/jdk/rev/206afa6372ae -Aleksey From kuaiwei.kw at alibaba-inc.com Mon May 13 11:57:56 2019 From: kuaiwei.kw at alibaba-inc.com (Kuai Wei) Date: Mon, 13 May 2019 19:57:56 +0800 Subject: =?UTF-8?B?Y2FuIGdyYWFsIHVucm9sbCBsb29wIHdpdGggbW9yZSBibG9ja3M=?= Message-ID: <52c4e99e-7652-4041-acba-9020a0fe35ea.kuaiwei.kw@alibaba-inc.com> Hello, Recently I checked loop unroll optimization in Graal compiler. I found it has a strict check to limit unroll loop with 1 or 2 blocks. In LoopTransformations.java: public static boolean isUnrollableLoop(LoopEx loop) { ... if (loopBegin.isMainLoop() || loopBegin.isSimpleLoop()) { // Flow-less loops to partial unroll for now. 3 blocks corresponds to an if that either // exits or continues the loop. There might be fixed and floating work within the loop // as well. if (loop.loop().getBlocks().size() < 3) { return true; } condition.getDebug().log(DebugContext.VERBOSE_LEVEL, "isUnrollableLoop %s too large to unroll %s ", loopBegin, loop.loop().getBlocks().size()); } I'm wondering why Graal has this limit. It will block many loops to be unrolled. Could we increase the block size here? Thanks, Kuai Wei From gilles.m.duboscq at oracle.com Mon May 13 12:37:17 2019 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Mon, 13 May 2019 14:37:17 +0200 Subject: can graal unroll loop with more blocks In-Reply-To: <52c4e99e-7652-4041-acba-9020a0fe35ea.kuaiwei.kw@alibaba-inc.com> References: <52c4e99e-7652-4041-acba-9020a0fe35ea.kuaiwei.kw@alibaba-inc.com> Message-ID: Hi Kuai, You can not safely change that limit there: this is not a heuristic but a necessary check because the code behind this transformation will produce incorrect results with more blocks. It would be not be very hard to change this limit to be about the loop having a single loop exit. But with multiple loop exits it would be a much larger change. Gilles On 13/05/2019 13:57, Kuai Wei wrote: > > Hello, > > Recently I checked loop unroll optimization in Graal compiler. I found it has a strict check to limit unroll loop with 1 or 2 blocks. > In LoopTransformations.java: > > public static boolean isUnrollableLoop(LoopEx loop) { > ... > if (loopBegin.isMainLoop() || loopBegin.isSimpleLoop()) { > // Flow-less loops to partial unroll for now. 3 blocks corresponds to an if that either > // exits or continues the loop. There might be fixed and floating work within the loop > // as well. > if (loop.loop().getBlocks().size() < 3) { > return true; > } > condition.getDebug().log(DebugContext.VERBOSE_LEVEL, "isUnrollableLoop %s too large to unroll %s ", loopBegin, loop.loop().getBlocks().size()); > } > > I'm wondering why Graal has this limit. It will block many loops to be unrolled. Could we increase the block size here? > > Thanks, > Kuai Wei > From jesper.wilhelmsson at oracle.com Tue May 14 00:19:01 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 14 May 2019 02:19:01 +0200 Subject: RFR: JDK-8223346 - Update Graal Message-ID: Hi, Please review the patch to integrate recent Graal changes into OpenJDK. Graal tip to integrate: 6a18d9ddacd8eecb0ae4877f687e171889939c0d Bug: https://bugs.openjdk.java.net/browse/JDK-8223346 Webrev: http://cr.openjdk.java.net/~jwilhelm/8223346/webrev.00/ This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. Thanks, /Jesper From kuaiwei.kw at alibaba-inc.com Tue May 14 02:55:15 2019 From: kuaiwei.kw at alibaba-inc.com (Kuai Wei) Date: Tue, 14 May 2019 10:55:15 +0800 Subject: =?UTF-8?B?UmU6IGNhbiBncmFhbCB1bnJvbGwgbG9vcCB3aXRoIG1vcmUgYmxvY2tz?= In-Reply-To: References: <52c4e99e-7652-4041-acba-9020a0fe35ea.kuaiwei.kw@alibaba-inc.com>, Message-ID: <33b68a5b-4a40-441b-ad98-286a621becb4.kuaiwei.kw@alibaba-inc.com> Hi Gilles, Thanks for your help. My understanding is if loop has single exit, it's an unroll candidate. I will investigate if we can apply the new rule. Is there other check we need care? Best Regards, Kuai Wei ------------------------------------------------------------------ From:Gilles Duboscq Send Time:2019?5?13?(???) 20:37 To:graal-dev Subject:Re: can graal unroll loop with more blocks Hi Kuai, You can not safely change that limit there: this is not a heuristic but a necessary check because the code behind this transformation will produce incorrect results with more blocks. It would be not be very hard to change this limit to be about the loop having a single loop exit. But with multiple loop exits it would be a much larger change. Gilles On 13/05/2019 13:57, Kuai Wei wrote: > > Hello, > > Recently I checked loop unroll optimization in Graal compiler. I found it has a strict check to limit unroll loop with 1 or 2 blocks. > In LoopTransformations.java: > > public static boolean isUnrollableLoop(LoopEx loop) { > ... > if (loopBegin.isMainLoop() || loopBegin.isSimpleLoop()) { > // Flow-less loops to partial unroll for now. 3 blocks corresponds to an if that either > // exits or continues the loop. There might be fixed and floating work within the loop > // as well. > if (loop.loop().getBlocks().size() < 3) { > return true; > } > condition.getDebug().log(DebugContext.VERBOSE_LEVEL, "isUnrollableLoop %s too large to unroll %s ", loopBegin, loop.loop().getBlocks().size()); > } > > I'm wondering why Graal has this limit. It will block many loops to be unrolled. Could we increase the block size here? > > Thanks, > Kuai Wei > From vladimir.kozlov at oracle.com Tue May 14 19:32:13 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 May 2019 12:32:13 -0700 Subject: RFR: JDK-8223346 - Update Graal In-Reply-To: References: Message-ID: Changes seems fine but I am not comfortable about tests results. There are a lot of timeouts again but there are many graalunit tests failures. This time you have to apply overwritten diffs after merge (if we decide to push it) - these changes are not in Graal master repo yet. Thanks, Vladimir On 5/13/19 5:19 PM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review the patch to integrate recent Graal changes into OpenJDK. > Graal tip to integrate: 6a18d9ddacd8eecb0ae4877f687e171889939c0d > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223346 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8223346/webrev.00/ > > This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. > > Thanks, > /Jesper > From dean.long at oracle.com Tue May 14 21:03:28 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 14 May 2019 14:03:28 -0700 Subject: RFR: JDK-8223346 - Update Graal In-Reply-To: References: Message-ID: I suggest doing the tiers 1-4 testing separate from the tier5+ testing, to reduce noise. There is a fix for CheckGraalIntrinsics coming to upstream Graal. When Jesper merges the overwritten changes, he could include that fix as well, so that compiler/graalunit/HotspotTest.java passes. The HeapMonitorStatArrayCorrectnessTest failure should have been fixed by JDK-8223441, unless Jesper's test repo is out of date. dl On 5/14/19 12:32 PM, Vladimir Kozlov wrote: > Changes seems fine but I am not comfortable about tests results. There > are a lot of timeouts again but there are many graalunit tests failures. > > This time you have to apply overwritten diffs after merge (if we > decide to push it) - these changes are not in Graal master repo yet. > > Thanks, > Vladimir > > On 5/13/19 5:19 PM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> >> Please review the patch to integrate recent Graal changes into OpenJDK. >> Graal tip to integrate: 6a18d9ddacd8eecb0ae4877f687e171889939c0d >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223346 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223346/webrev.00/ >> >> This integration did overwrite changes already in place in OpenJDK. >> The diff has been attached to the umbrella bug. >> >> Thanks, >> /Jesper >> From jesper.wilhelmsson at oracle.com Tue May 14 21:40:39 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 14 May 2019 23:40:39 +0200 Subject: RFR: JDK-8223346 - Update Graal In-Reply-To: References: Message-ID: <507D457E-C328-4337-968E-80036650FDE3@oracle.com> Dean, Please attach the diff you want me to add to the bug. JDK-8223441 is in there. <> Thanks, /Jesper > On 14 May 2019, at 23:03, dean.long at oracle.com wrote: > > I suggest doing the tiers 1-4 testing separate from the tier5+ testing, to reduce noise. > > There is a fix for CheckGraalIntrinsics coming to upstream Graal. When Jesper merges the overwritten changes, he could include that fix as well, so that compiler/graalunit/HotspotTest.java passes. > > The HeapMonitorStatArrayCorrectnessTest failure should have been fixed by JDK-8223441, unless Jesper's test repo is out of date. > > dl > <> > On 5/14/19 12:32 PM, Vladimir Kozlov wrote: >> Changes seems fine but I am not comfortable about tests results. There are a lot of timeouts again but there are many graalunit tests failures. >> >> This time you have to apply overwritten diffs after merge (if we decide to push it) - these changes are not in Graal master repo yet. >> >> Thanks, >> Vladimir >> >> On 5/13/19 5:19 PM, jesper.wilhelmsson at oracle.com wrote: >>> Hi, >>> >>> Please review the patch to integrate recent Graal changes into OpenJDK. >>> Graal tip to integrate: 6a18d9ddacd8eecb0ae4877f687e171889939c0d >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223346 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223346/webrev.00/ >>> >>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>> >>> Thanks, >>> /Jesper >>> > From doug.simon at oracle.com Thu May 16 17:03:14 2019 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 May 2019 19:03:14 +0200 Subject: JVMCI 20-b01 released Message-ID: This is the first JVMCI release for GraalVM 20 development. Note that it also bumps the required JDK 8 JVMCI minimum required version for Graal to jvmci-19-b01. The latter introduce the following JVMCI API: HotSpotJVMCIRuntime.writeDebugOutput HotSpotJVMCIRuntime.isCurrentThreadAttached HotSpotJVMCIRuntime.attachCurrentThread HotSpotJVMCIRuntime.detachCurrentThread Other changes since jvmci-0.59 include: ? Renamed labsjdk to oraclejdk-jvmci ? The openjdk-jvmci builds no longer include libfreetype (https://github.com/oracle/graal/issues/1269 ) ? GR-15805: DebuggerException: Can't attach symbolicator to the process (JDK-8160376). ? GR-15776: Improve chaining exceptions during translation. ? GR-15651: Add resizing support to JVMCI counters. ? GR-15679: Missing pending exception check in c2v_resolveTypeInPool(). ? GR-15650: Add missing exception check in native code. ? GR-15654: Precompiled headers fix. ? GR-15494: Synchronize JDK 13 JVMCI HotSpot changes. ? GR-15510: Use suite attributes for specifying jvmci version. ? GR-15386: Fix writing to HotSpot's log stream from unattached thread and make it public API. ? GR-15375: Merge jdk8u212-b04. ? GR-15205: Fix support for balanced attach/detach in JVMCI shared library. ? GR-15272: Update the nmethod mirror slot before notifying the GC. The binaries are available on OTN and on GitHub . -Doug From jesper.wilhelmsson at oracle.com Thu May 16 20:08:01 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 16 May 2019 22:08:01 +0200 Subject: RFR: JDK-8223346 - Update Graal In-Reply-To: <507D457E-C328-4337-968E-80036650FDE3@oracle.com> References: <507D457E-C328-4337-968E-80036650FDE3@oracle.com> Message-ID: <9CB307E3-F31F-4349-932E-E52DE0773FA5@oracle.com> New webrev with overwritten and the extra Graal change applied: http://cr.openjdk.java.net/~jwilhelm/8223346/webrev.01/ /Jesper > On 14 May 2019, at 23:40, jesper.wilhelmsson at oracle.com wrote: > > Dean, > > Please attach the diff you want me to add to the bug. > JDK-8223441 is in there. <> > > Thanks, > /Jesper > >> On 14 May 2019, at 23:03, dean.long at oracle.com wrote: >> >> I suggest doing the tiers 1-4 testing separate from the tier5+ testing, to reduce noise. >> >> There is a fix for CheckGraalIntrinsics coming to upstream Graal. When Jesper merges the overwritten changes, he could include that fix as well, so that compiler/graalunit/HotspotTest.java passes. >> >> The HeapMonitorStatArrayCorrectnessTest failure should have been fixed by JDK-8223441, unless Jesper's test repo is out of date. >> >> dl >> <> >> On 5/14/19 12:32 PM, Vladimir Kozlov wrote: >>> Changes seems fine but I am not comfortable about tests results. There are a lot of timeouts again but there are many graalunit tests failures. >>> >>> This time you have to apply overwritten diffs after merge (if we decide to push it) - these changes are not in Graal master repo yet. >>> >>> Thanks, >>> Vladimir >>> >>> On 5/13/19 5:19 PM, jesper.wilhelmsson at oracle.com wrote: >>>> Hi, >>>> >>>> Please review the patch to integrate recent Graal changes into OpenJDK. >>>> Graal tip to integrate: 6a18d9ddacd8eecb0ae4877f687e171889939c0d >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223346 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223346/webrev.00/ >>>> >>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>>> >>>> Thanks, >>>> /Jesper >>>> >> > From vladimir.kozlov at oracle.com Thu May 16 20:09:31 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 May 2019 13:09:31 -0700 Subject: RFR: JDK-8223346 - Update Graal In-Reply-To: <9CB307E3-F31F-4349-932E-E52DE0773FA5@oracle.com> References: <507D457E-C328-4337-968E-80036650FDE3@oracle.com> <9CB307E3-F31F-4349-932E-E52DE0773FA5@oracle.com> Message-ID: Looks good. Thanks Vladimir > On May 16, 2019, at 1:08 PM, jesper.wilhelmsson at oracle.com wrote: > > New webrev with overwritten and the extra Graal change applied: > > http://cr.openjdk.java.net/~jwilhelm/8223346/webrev.01/ > > /Jesper > > >> On 14 May 2019, at 23:40, jesper.wilhelmsson at oracle.com wrote: >> >> Dean, >> >> Please attach the diff you want me to add to the bug. >> JDK-8223441 is in there. >> >> Thanks, >> /Jesper >> >>> On 14 May 2019, at 23:03, dean.long at oracle.com wrote: >>> >>> I suggest doing the tiers 1-4 testing separate from the tier5+ testing, to reduce noise. >>> >>> There is a fix for CheckGraalIntrinsics coming to upstream Graal. When Jesper merges the overwritten changes, he could include that fix as well, so that compiler/graalunit/HotspotTest.java passes. >>> >>> The HeapMonitorStatArrayCorrectnessTest failure should have been fixed by JDK-8223441, unless Jesper's test repo is out of date. >>> >>> dl >>> >>>> On 5/14/19 12:32 PM, Vladimir Kozlov wrote: >>>> Changes seems fine but I am not comfortable about tests results. There are a lot of timeouts again but there are many graalunit tests failures. >>>> >>>> This time you have to apply overwritten diffs after merge (if we decide to push it) - these changes are not in Graal master repo yet. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> On 5/13/19 5:19 PM, jesper.wilhelmsson at oracle.com wrote: >>>>> Hi, >>>>> >>>>> Please review the patch to integrate recent Graal changes into OpenJDK. >>>>> Graal tip to integrate: 6a18d9ddacd8eecb0ae4877f687e171889939c0d >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223346 >>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223346/webrev.00/ >>>>> >>>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>>>> >>>>> Thanks, >>>>> /Jesper >>>>> >>> >> > From jesper.wilhelmsson at oracle.com Thu May 16 22:40:31 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 17 May 2019 00:40:31 +0200 Subject: RFR: JDK-8223346 - Update Graal In-Reply-To: References: <507D457E-C328-4337-968E-80036650FDE3@oracle.com> <9CB307E3-F31F-4349-932E-E52DE0773FA5@oracle.com> Message-ID: Thanks Vladimir! /Jesper > On 16 May 2019, at 22:09, Vladimir Kozlov wrote: > > Looks good. > > Thanks > Vladimir > > On May 16, 2019, at 1:08 PM, jesper.wilhelmsson at oracle.com wrote: > >> New webrev with overwritten and the extra Graal change applied: >> >> http://cr.openjdk.java.net/~jwilhelm/8223346/webrev.01/ >> >> /Jesper >> >> >>> On 14 May 2019, at 23:40, jesper.wilhelmsson at oracle.com wrote: >>> >>> Dean, >>> >>> Please attach the diff you want me to add to the bug. >>> JDK-8223441 is in there. <> >>> >>> Thanks, >>> /Jesper >>> >>>> On 14 May 2019, at 23:03, dean.long at oracle.com wrote: >>>> >>>> I suggest doing the tiers 1-4 testing separate from the tier5+ testing, to reduce noise. >>>> >>>> There is a fix for CheckGraalIntrinsics coming to upstream Graal. When Jesper merges the overwritten changes, he could include that fix as well, so that compiler/graalunit/HotspotTest.java passes. >>>> >>>> The HeapMonitorStatArrayCorrectnessTest failure should have been fixed by JDK-8223441, unless Jesper's test repo is out of date. >>>> >>>> dl >>>> <> >>>> On 5/14/19 12:32 PM, Vladimir Kozlov wrote: >>>>> Changes seems fine but I am not comfortable about tests results. There are a lot of timeouts again but there are many graalunit tests failures. >>>>> >>>>> This time you have to apply overwritten diffs after merge (if we decide to push it) - these changes are not in Graal master repo yet. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 5/13/19 5:19 PM, jesper.wilhelmsson at oracle.com wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the patch to integrate recent Graal changes into OpenJDK. >>>>>> Graal tip to integrate: 6a18d9ddacd8eecb0ae4877f687e171889939c0d >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223346 >>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223346/webrev.00/ >>>>>> >>>>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>>>>> >>>>>> Thanks, >>>>>> /Jesper >>>>>> >>>> >>> >> From gilles.m.duboscq at oracle.com Mon May 20 17:03:44 2019 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Mon, 20 May 2019 19:03:44 +0200 Subject: can graal unroll loop with more blocks In-Reply-To: <33b68a5b-4a40-441b-ad98-286a621becb4.kuaiwei.kw@alibaba-inc.com> References: <52c4e99e-7652-4041-acba-9020a0fe35ea.kuaiwei.kw@alibaba-inc.com> <33b68a5b-4a40-441b-ad98-286a621becb4.kuaiwei.kw@alibaba-inc.com> Message-ID: Hi Kuai, I don't think you need other checks but some of the unrolling code might need to be updated to deal with the new shapes. Maybe things around `LoopTransformations#insertPrePostLoops`. Having assertions enabled should already catch some of the issues if there are any. Gilles On 14/05/2019 04:55, Kuai Wei wrote: > Hi Gilles, > > ? ?Thanks for your help. My understanding is if loop has single exit, it's an unroll candidate. I will investigate if we can apply the new rule. Is there other check we need care? > > Best Regards, > Kuai Wei > > ------------------------------------------------------------------ > From:Gilles Duboscq > Send Time:2019?5?13?(???) 20:37 > To:graal-dev > Subject:Re: can graal unroll loop with more blocks > > Hi?Kuai, > > You?can?not?safely?change?that?limit?there:?this?is?not?a?heuristic?but?a?necessary?check?because?the?code?behind?this?transformation?will?produce?incorrect?results?with?more?blocks. > > It?would?be?not?be?very?hard?to?change?this?limit?to?be?about?the?loop?having?a?single?loop?exit.?But?with?multiple?loop?exits?it?would?be?a?much?larger?change. > > ??Gilles > > > On?13/05/2019?13:57,?Kuai?Wei?wrote: > > > >?Hello, > > > >????Recently?I?checked?loop?unroll?optimization?in?Graal?compiler.?I?found?it?has?a?strict?check?to?limit?unroll?loop?with?1?or?2?blocks. > >?In??LoopTransformations.java: > > > >?public?static?boolean?isUnrollableLoop(LoopEx?loop)?{ > >????... > >????if?(loopBegin.isMainLoop()?||?loopBegin.isSimpleLoop())?{ > >??????????????//?Flow-less?loops?to?partial?unroll?for?now.?3?blocks?corresponds?to?an?if?that?either > >??????????????//?exits?or?continues?the?loop.?There?might?be?fixed?and?floating?work?within?the?loop > >??????????????//?as?well. > >??????????????if?(loop.loop().getBlocks().size()? >??????????????????return?true; > >??????????????} > >??????????????condition.getDebug().log(DebugContext.VERBOSE_LEVEL,?"isUnrollableLoop?%s?too?large?to?unroll?%s?",?loopBegin,?loop.loop().getBlocks().size()); > >?????} > > > >?I'm?wondering?why?Graal?has?this?limit.?It?will?block?many?loops?to?be?unrolled.?Could?we?increase?the?block?size?here? > > > >?Thanks, > >?Kuai?Wei > > > From bmcwhirt at redhat.com Wed May 22 18:20:58 2019 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Wed, 22 May 2019 14:20:58 -0400 Subject: JDK11 & Polyglot Message-ID: With the new JDK11 changes, at one point I could build polyglot/libpolyglot with JDK11. Currently, though, I'm hitting: [polyglot:96956] image: 3,838.67 ms Fatal error: com.oracle.svm.core.util.VMError$HostedError: com.oracle.svm.core.util.UserError$UserException: Static field or an object referenced from a static field changed during native image generation? object:com.oracle.truffle.api=true of class: java.util.concurrent.ConcurrentHashMap$Node reachable through: object: [Ljava.util.concurrent.ConcurrentHashMap$Node;@bdedfe2 of class: java.util.concurrent.ConcurrentHashMap$Node[] object: {com.oracle.truffle.api.dsl=true, com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, com.oracle.truffle.api=true} of class: java.util.concurrent.ConcurrentHashMap object: java.lang.WeakPairMap$Pair$Weak at 195d71ba={com.oracle.truffle.api.dsl=true, com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, com.oracle.truffle.api=true} of class: java.util.concurrent.ConcurrentHashMap$Node object: [Ljava.util.concurrent.ConcurrentHashMap$Node;@400328da of class: java.util.concurrent.ConcurrentHashMap$Node[] object: {java.lang.WeakPairMap$Pair$Weak at 1f98c4db={com.sun.proxy.jdk.proxy2=false}, java.lang.WeakPairMap$Pair$Weak at 64fcd13f={org.graalvm.word.impl=false}, java.lang.WeakPairMap$Pair$Weak at 195d71ba={com.oracle.truffle.api.dsl=true, com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, com.oracle.truffle.api=true}, java.lang.WeakPairMap$Pair$Weak at 27421acb={jdk.vm.ci.aarch64=false, jdk.vm.ci.meta=false, jdk.vm.ci.code.site=false, jdk.vm.ci.services=false, jdk.vm.ci.code=false, jdk.vm.ci.common=false, jdk.vm.ci.hotspot=false, jdk.vm.ci.runtime=false, jdk.vm.ci.amd64=false}, java.lang.WeakPairMap$Pair$Weak at 40620d6e={com.sun.proxy.jdk.proxy1=false}, java.lang.WeakPairMap$Pair$Weak at 40620d6e={jdk.internal.vm.annotation=false, jdk.internal=false, jdk.internal.reflect=false}, java.lang.WeakPairMap$Pair$Weak at 59e8f104={org.graalvm.nativeimage.c.constant=true}, java.lang.WeakPairMap$Pair$Weak at c2fcfe1={org.graalvm.compiler.graph=true, org.graalvm.compiler.core.match=true}, java.lang.WeakPairMap$Pair$Weak at 1365b46a={jdk.vm.ci.aarch64=true, jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, java.lang.WeakPairMap$Pair$Weak at 7d268756={jdk.vm.ci.common=false}, java.lang.WeakPairMap$Pair$Weak at 1fc86ed8={jdk.vm.ci.aarch64=true, jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, java.lang.WeakPairMap$Pair$Weak at 1a0690f3={java.util=true, java.nio=true, jdk.internal.misc=true, jdk.internal.logger=true, java.lang=true, java.lang.ref=true, jdk.internal.vm.annotation=true, java.net=true, java.lang.invoke=true, jdk.internal.ref=true, jdk.internal.module=true, jdk.internal.reflect=true}, java.lang.WeakPairMap$Pair$Weak at 61628517={org.graalvm.nativeimage.impl=true, org.graalvm.polyglot=true}, java.lang.WeakPairMap$Pair$Weak at 34a5bbf2={org.graalvm.compiler.debug=true, org.graalvm.compiler.nodes=true}, java.lang.WeakPairMap$Pair$Weak at 21d705a9={com.oracle.truffle.api.impl=true, com.oracle.truffle.polyglot=true}, java.lang.WeakPairMap$Pair$Weak at 13e7a139={jdk.vm.ci.aarch64=true, jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}} of class: java.util.concurrent.ConcurrentHashMap object: java.lang.WeakPairMap at 6bb0d5ff of class: java.lang.WeakPairMap root: null at com.oracle.svm.core.util.VMError.shouldNotReachHere(VMError.java:70) at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:646) at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$0(NativeImageGenerator.java:449) at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1407) at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020) at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177) Caused by: com.oracle.svm.core.util.UserError$UserException: Static field or an object referenced from a static field changed during native image generation? object:com.oracle.truffle.api=true of class: java.util.concurrent.ConcurrentHashMap$Node reachable through: object: [Ljava.util.concurrent.ConcurrentHashMap$Node;@bdedfe2 of class: java.util.concurrent.ConcurrentHashMap$Node[] object: {com.oracle.truffle.api.dsl=true, com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, com.oracle.truffle.api=true} of class: java.util.concurrent.ConcurrentHashMap object: java.lang.WeakPairMap$Pair$Weak at 195d71ba={com.oracle.truffle.api.dsl=true, com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, com.oracle.truffle.api=true} of class: java.util.concurrent.ConcurrentHashMap$Node object: [Ljava.util.concurrent.ConcurrentHashMap$Node;@400328da of class: java.util.concurrent.ConcurrentHashMap$Node[] object: {java.lang.WeakPairMap$Pair$Weak at 1f98c4db={com.sun.proxy.jdk.proxy2=false}, java.lang.WeakPairMap$Pair$Weak at 64fcd13f={org.graalvm.word.impl=false}, java.lang.WeakPairMap$Pair$Weak at 195d71ba={com.oracle.truffle.api.dsl=true, com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, com.oracle.truffle.api=true}, java.lang.WeakPairMap$Pair$Weak at 27421acb={jdk.vm.ci.aarch64=false, jdk.vm.ci.meta=false, jdk.vm.ci.code.site=false, jdk.vm.ci.services=false, jdk.vm.ci.code=false, jdk.vm.ci.common=false, jdk.vm.ci.hotspot=false, jdk.vm.ci.runtime=false, jdk.vm.ci.amd64=false}, java.lang.WeakPairMap$Pair$Weak at 40620d6e={com.sun.proxy.jdk.proxy1=false}, java.lang.WeakPairMap$Pair$Weak at 40620d6e={jdk.internal.vm.annotation=false, jdk.internal=false, jdk.internal.reflect=false}, java.lang.WeakPairMap$Pair$Weak at 59e8f104={org.graalvm.nativeimage.c.constant=true}, java.lang.WeakPairMap$Pair$Weak at c2fcfe1={org.graalvm.compiler.graph=true, org.graalvm.compiler.core.match=true}, java.lang.WeakPairMap$Pair$Weak at 1365b46a={jdk.vm.ci.aarch64=true, jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, java.lang.WeakPairMap$Pair$Weak at 7d268756={jdk.vm.ci.common=false}, java.lang.WeakPairMap$Pair$Weak at 1fc86ed8={jdk.vm.ci.aarch64=true, jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, java.lang.WeakPairMap$Pair$Weak at 1a0690f3={java.util=true, java.nio=true, jdk.internal.misc=true, jdk.internal.logger=true, java.lang=true, java.lang.ref=true, jdk.internal.vm.annotation=true, java.net=true, java.lang.invoke=true, jdk.internal.ref=true, jdk.internal.module=true, jdk.internal.reflect=true}, java.lang.WeakPairMap$Pair$Weak at 61628517={org.graalvm.nativeimage.impl=true, org.graalvm.polyglot=true}, java.lang.WeakPairMap$Pair$Weak at 34a5bbf2={org.graalvm.compiler.debug=true, org.graalvm.compiler.nodes=true}, java.lang.WeakPairMap$Pair$Weak at 21d705a9={com.oracle.truffle.api.impl=true, com.oracle.truffle.polyglot=true}, java.lang.WeakPairMap$Pair$Weak at 13e7a139={jdk.vm.ci.aarch64=true, jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}} of class: java.util.concurrent.ConcurrentHashMap object: java.lang.WeakPairMap at 6bb0d5ff of class: java.lang.WeakPairMap root: null at com.oracle.svm.core.util.UserError.abort(UserError.java:65) at com.oracle.svm.hosted.image.NativeImageHeap.verifyTargetDidNotChange(NativeImageHeap.java:558) at com.oracle.svm.hosted.image.NativeImageHeap.writeReference(NativeImageHeap.java:595) at com.oracle.svm.hosted.image.NativeImageHeap.write(NativeImageHeap.java:584) at com.oracle.svm.hosted.image.NativeImageHeap.writeConstant(NativeImageHeap.java:621) at com.oracle.svm.hosted.image.NativeImageHeap.writeObject(NativeImageHeap.java:874) at com.oracle.svm.hosted.image.NativeImageHeap.writeHeap(NativeImageHeap.java:290) at com.oracle.svm.hosted.image.NativeBootImage.build(NativeBootImage.java:458) at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:635) ... 7 more Error: Image build request failed with exit status 1 Which when I add debug, can shuffle around and point to ObjectIdentifier or TimerKeyImpl or a variety of other classes. I sense that it might be the transient static boolean COMPACT_STRINGS on String.class ultimately causing it, but that's not necessarily a warranted opinion. It always seems to be a String problem, and COMPACT_STRINGS is designated as set by the JVM at runtime, not to the true that appears in the source. Anyone have a thought or a pointer on what might've changed in the past 3 weeks, or if I'm completely off base and would be willing to point me in a more useful direction. Thanks, -Bob From adinn at redhat.com Thu May 23 09:01:53 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 23 May 2019 10:01:53 +0100 Subject: JDK11 & Polyglot In-Reply-To: References: Message-ID: On 22/05/2019 19:20, Bob McWhirter wrote: > With the new JDK11 changes, at one point I could build polyglot/libpolyglot > with JDK11. > > Currently, though, I'm hitting: > . . . > I sense that it might be the transient static boolean COMPACT_STRINGS on > String.class ultimately causing it, but that's not necessarily a warranted > opinion. It always seems to be a String problem, and COMPACT_STRINGS is > designated as set by the JVM at runtime, not to the true that appears in > the source. I'm not sure how this could be the issue. I say that because I do understand what goes on with this field in the JVM. Here is the context: During JVM startup various Java classes are constructed 'by hand' i.e. the bytecodes are loaded the JVM-internal metadata model for the class is created (C++ object InstanceKlass plus auxiliary objects like Symbol. method etc) the JVM-heap allocated Class is created the Class's method is run This is done in a very specific sequence starting with some Exception classes that have no dependencies on supers or linked classes and proceeding to classes like String, Thread, ThreadGroup etc. At certain points during this process a run may require creating certain linked Class instances (most obviously supers but also classes referenced from the method) and this will initiate the above steps recursively. So, the explicit hand initialization sequence only defines a nominal load+init order. Recursive dependency chasing means that the actual load order may be different. Now as for class String: very early on in this init sequence String gets explicitly loaded. It is one of many classes whose static fields need to be initialized specially to accord with HW, OS or user config setting -- String.COMPACT_STRINGS is one such example. In most normal cases where runtime-specific settings need to be detected the code calls native methods from code to read them. However, for a few of these early-load classes the methods instead initialize to a dummy and the C++ code that hand-loads the class then overwrites the correct values into the static field slots immediately after the load and init of the class has completed. So, in the case of String field COMPACT_STRINGS will be updated by the JVM immediately after running its method. I don't really see how this can make any difference visible to the Graal native image generator. The change to COMPACT_STRINGS wil have happened long before any of the Graal NativeImageGenerator code could even have started running (indeed well before the JVM runtime code like ForkJoinPool that drives the native image process is loaded). So, sorry Bob, but I think you are probably barking up the wrong tree here. > Anyone have a thought or a pointer on what might've changed in the past 3 > weeks, or if I'm completely off base and would be willing to point me in a > more useful direction. Looking at recent changes sounds to me like the best approach. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From bmcwhirt at redhat.com Thu May 23 10:36:46 2019 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Thu, 23 May 2019 06:36:46 -0400 Subject: JDK11 & Polyglot In-Reply-To: References: Message-ID: Thanks Andrew! I?ll continue to poke around. When I was getting the ObjectIdentifier variant there simple aren?t many statics available. There?s a none-static stringForm field of type String. Maybe I?m just misunderstanding the error message also. Time to git log. Bob On Thu, May 23, 2019 at 5:02 AM Andrew Dinn wrote: > On 22/05/2019 19:20, Bob McWhirter wrote: > > With the new JDK11 changes, at one point I could build > polyglot/libpolyglot > > with JDK11. > > > > Currently, though, I'm hitting: > > . . . > > I sense that it might be the transient static boolean COMPACT_STRINGS on > > String.class ultimately causing it, but that's not necessarily a > warranted > > opinion. It always seems to be a String problem, and COMPACT_STRINGS is > > designated as set by the JVM at runtime, not to the true that appears in > > the source. > > I'm not sure how this could be the issue. I say that because I do > understand what goes on with this field in the JVM. Here is the context: > > During JVM startup various Java classes are constructed 'by hand' i.e. > > the bytecodes are loaded > the JVM-internal metadata model for the class is created > (C++ object InstanceKlass plus auxiliary objects like Symbol. method > etc) > the JVM-heap allocated Class is created > the Class's method is run > > This is done in a very specific sequence starting with some Exception > classes that have no dependencies on supers or linked classes and > proceeding to classes like String, Thread, ThreadGroup etc. > > At certain points during this process a run may require > creating certain linked Class instances (most obviously supers but > also classes referenced from the method) and this will initiate > the above steps recursively. So, the explicit hand initialization > sequence only defines a nominal load+init order. Recursive dependency > chasing means that the actual load order may be different. > > Now as for class String: very early on in this init sequence String gets > explicitly loaded. It is one of many classes whose static fields need to > be initialized specially to accord with HW, OS or user config setting -- > String.COMPACT_STRINGS is one such example. In most normal cases where > runtime-specific settings need to be detected the code calls > native methods from code to read them. However, for a few of > these early-load classes the methods instead initialize to a > dummy and the C++ code that hand-loads the class then overwrites the > correct values into the static field slots immediately after the load > and init of the class has completed. > > So, in the case of String field COMPACT_STRINGS will be updated by the > JVM immediately after running its method. I don't really see > how this can make any difference visible to the Graal native image > generator. The change to COMPACT_STRINGS wil have happened long before > any of the Graal NativeImageGenerator code could even have started > running (indeed well before the JVM runtime code like ForkJoinPool that > drives the native image process is loaded). So, sorry Bob, but I think > you are probably barking up the wrong tree here. > > > Anyone have a thought or a pointer on what might've changed in the past 3 > > weeks, or if I'm completely off base and would be willing to point me in > a > > more useful direction. > Looking at recent changes sounds to me like the best approach. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From bmcwhirt at redhat.com Thu May 23 13:19:42 2019 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Thu, 23 May 2019 09:19:42 -0400 Subject: JDK11 & Polyglot In-Reply-To: References: Message-ID: Seems like an intermittent/transient failure, as this morning it all built cleanly. Good times. -Bob On Thu, May 23, 2019 at 6:36 AM Bob McWhirter wrote: > Thanks Andrew! > > I?ll continue to poke around. When I was getting the ObjectIdentifier > variant there simple aren?t many statics available. There?s a none-static > stringForm field of type String. Maybe I?m just misunderstanding the error > message also. > > Time to git log. > > Bob > > On Thu, May 23, 2019 at 5:02 AM Andrew Dinn wrote: > >> On 22/05/2019 19:20, Bob McWhirter wrote: >> > With the new JDK11 changes, at one point I could build >> polyglot/libpolyglot >> > with JDK11. >> > >> > Currently, though, I'm hitting: >> > . . . >> > I sense that it might be the transient static boolean COMPACT_STRINGS on >> > String.class ultimately causing it, but that's not necessarily a >> warranted >> > opinion. It always seems to be a String problem, and COMPACT_STRINGS is >> > designated as set by the JVM at runtime, not to the true that appears in >> > the source. >> >> I'm not sure how this could be the issue. I say that because I do >> understand what goes on with this field in the JVM. Here is the context: >> >> During JVM startup various Java classes are constructed 'by hand' i.e. >> >> the bytecodes are loaded >> the JVM-internal metadata model for the class is created >> (C++ object InstanceKlass plus auxiliary objects like Symbol. method >> etc) >> the JVM-heap allocated Class is created >> the Class's method is run >> >> This is done in a very specific sequence starting with some Exception >> classes that have no dependencies on supers or linked classes and >> proceeding to classes like String, Thread, ThreadGroup etc. >> >> At certain points during this process a run may require >> creating certain linked Class instances (most obviously supers but >> also classes referenced from the method) and this will initiate >> the above steps recursively. So, the explicit hand initialization >> sequence only defines a nominal load+init order. Recursive dependency >> chasing means that the actual load order may be different. >> >> Now as for class String: very early on in this init sequence String gets >> explicitly loaded. It is one of many classes whose static fields need to >> be initialized specially to accord with HW, OS or user config setting -- >> String.COMPACT_STRINGS is one such example. In most normal cases where >> runtime-specific settings need to be detected the code calls >> native methods from code to read them. However, for a few of >> these early-load classes the methods instead initialize to a >> dummy and the C++ code that hand-loads the class then overwrites the >> correct values into the static field slots immediately after the load >> and init of the class has completed. >> >> So, in the case of String field COMPACT_STRINGS will be updated by the >> JVM immediately after running its method. I don't really see >> how this can make any difference visible to the Graal native image >> generator. The change to COMPACT_STRINGS wil have happened long before >> any of the Graal NativeImageGenerator code could even have started >> running (indeed well before the JVM runtime code like ForkJoinPool that >> drives the native image process is loaded). So, sorry Bob, but I think >> you are probably barking up the wrong tree here. >> >> > Anyone have a thought or a pointer on what might've changed in the past >> 3 >> > weeks, or if I'm completely off base and would be willing to point me >> in a >> > more useful direction. >> Looking at recent changes sounds to me like the best approach. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >> > From bmcwhirt at redhat.com Thu May 23 15:55:25 2019 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Thu, 23 May 2019 11:55:25 -0400 Subject: JDK11 & Polyglot In-Reply-To: References: Message-ID: Progress... maybe? In Module$ReflectionData /** * A module (1st key) exports or opens a package to another module * (2nd key). The map value is a map of package name to a boolean * that indicates if the package is opened. */ static final WeakPairMap> exports = new WeakPairMap<>(); Ultimately used by Module.isReflectivelyExportedOrOpen(...): private boolean isReflectivelyExportedOrOpen(String pn, Module other, boolean open) { // exported or open to all modules Map exports = ReflectionData.exports.get(this, EVERYONE_MODULE); Is the source of things-changing-while-writing-the-heap. Not sure how to fix, or if there is a way to whitelist/ignore this. I do have an inbound PR to push in a moment helping fix the debug reason trace, to avoid the "root=null" in the current master#HEAD. Caused by: com.oracle.svm.core.util.UserError$UserException: Static field or an object referenced from a static field changed during native image generation? object:com.oracle.truffle.api=true of class: java.util.concurrent.ConcurrentHashMap$Node reachable through: object: [Ljava.util.concurrent.ConcurrentHashMap$Node;@3cb34219 of class: java.util.concurrent.ConcurrentHashMap$Node[] object: {com.oracle.truffle.api.dsl=true, com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, com.oracle.truffle.api=true} of class: java.util.concurrent.ConcurrentHashMap object: java.lang.WeakPairMap$Pair$Weak at 248dd9c1={com.oracle.truffle.api.dsl=true, com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, com.oracle.truffle.api=true} of class: java.util.concurrent.ConcurrentHashMap$Node object: java.lang.WeakPairMap$Pair$Weak at 40620d6e={jdk.internal.vm.annotation=false, jdk.internal=false, jdk.internal.reflect=false} of class: java.util.concurrent.ConcurrentHashMap$Node object: java.lang.WeakPairMap$Pair$Weak at 40620d6e={com.sun.proxy.jdk.proxy1=false} of class: java.util.concurrent.ConcurrentHashMap$Node object: [Ljava.util.concurrent.ConcurrentHashMap$Node;@6e0bf27b of class: java.util.concurrent.ConcurrentHashMap$Node[] object: {java.lang.WeakPairMap$Pair$Weak at 64486d2a={org.graalvm.nativeimage.c.constant=true}, java.lang.WeakPairMap$Pair$Weak at 708aa969={jdk.vm.ci.aarch64=true, jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, java.lang.WeakPairMap$Pair$Weak at 6f715c77={jdk.vm.ci.common=false}, java.lang.WeakPairMap$Pair$Weak at 40620d6e={com.sun.proxy.jdk.proxy1=false}, java.lang.WeakPairMap$Pair$Weak at 40620d6e={jdk.internal.vm.annotation=false, jdk.internal=false, jdk.internal.reflect=false}, java.lang.WeakPairMap$Pair$Weak at 248dd9c1={com.oracle.truffle.api.dsl=true, com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, com.oracle.truffle.api=true}, java.lang.WeakPairMap$Pair$Weak at 7c968d5b={org.graalvm.compiler.debug=true, org.graalvm.compiler.nodes=true}, java.lang.WeakPairMap$Pair$Weak at 5ba3fc8d={jdk.vm.ci.aarch64=true, jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, java.lang.WeakPairMap$Pair$Weak at 6112b142={com.oracle.truffle.api.impl=true, com.oracle.truffle.polyglot=true}, java.lang.WeakPairMap$Pair$Weak at 3909e5d8={org.graalvm.compiler.graph=true, org.graalvm.compiler.core.match=true}, java.lang.WeakPairMap$Pair$Weak at 49834cb1={jdk.vm.ci.aarch64=true, jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, java.lang.WeakPairMap$Pair$Weak at 2cc8e91b={org.graalvm.word.impl=false}, java.lang.WeakPairMap$Pair$Weak at 1a0690f3={java.util=true, java.nio=true, jdk.internal.misc=true, jdk.internal.logger=true, java.lang=true, java.lang.ref=true, jdk.internal.vm.annotation=true, java.net=true, java.lang.invoke=true, jdk.internal.ref=true, jdk.internal.module=true, jdk.internal.reflect=true}, java.lang.WeakPairMap$Pair$Weak at 17197c41={com.sun.proxy.jdk.proxy2=false}, java.lang.WeakPairMap$Pair$Weak at 21d705a9={org.graalvm.nativeimage.impl=true, org.graalvm.polyglot=true}, java.lang.WeakPairMap$Pair$Weak at 3515c1ea={jdk.vm.ci.aarch64=false, jdk.vm.ci.meta=false, jdk.vm.ci.code.site=false, jdk.vm.ci.services=false, jdk.vm.ci.code=false, jdk.vm.ci.common=false, jdk.vm.ci.hotspot=false, jdk.vm.ci.runtime=false, jdk.vm.ci.amd64=false}} of class: java.util.concurrent.ConcurrentHashMap object: java.lang.WeakPairMap at 3b3c322f of class: java.lang.WeakPairMap root: java.lang.Module.isReflectivelyExportedOrOpen(String, Module, boolean) On Thu, May 23, 2019 at 9:19 AM Bob McWhirter wrote: > Seems like an intermittent/transient failure, as this morning it all built > cleanly. > > Good times. > > -Bob > > On Thu, May 23, 2019 at 6:36 AM Bob McWhirter wrote: > >> Thanks Andrew! >> >> I?ll continue to poke around. When I was getting the ObjectIdentifier >> variant there simple aren?t many statics available. There?s a none-static >> stringForm field of type String. Maybe I?m just misunderstanding the error >> message also. >> >> Time to git log. >> >> Bob >> >> On Thu, May 23, 2019 at 5:02 AM Andrew Dinn wrote: >> >>> On 22/05/2019 19:20, Bob McWhirter wrote: >>> > With the new JDK11 changes, at one point I could build >>> polyglot/libpolyglot >>> > with JDK11. >>> > >>> > Currently, though, I'm hitting: >>> > . . . >>> > I sense that it might be the transient static boolean COMPACT_STRINGS >>> on >>> > String.class ultimately causing it, but that's not necessarily a >>> warranted >>> > opinion. It always seems to be a String problem, and COMPACT_STRINGS >>> is >>> > designated as set by the JVM at runtime, not to the true that appears >>> in >>> > the source. >>> >>> I'm not sure how this could be the issue. I say that because I do >>> understand what goes on with this field in the JVM. Here is the context: >>> >>> During JVM startup various Java classes are constructed 'by hand' i.e. >>> >>> the bytecodes are loaded >>> the JVM-internal metadata model for the class is created >>> (C++ object InstanceKlass plus auxiliary objects like Symbol. method >>> etc) >>> the JVM-heap allocated Class is created >>> the Class's method is run >>> >>> This is done in a very specific sequence starting with some Exception >>> classes that have no dependencies on supers or linked classes and >>> proceeding to classes like String, Thread, ThreadGroup etc. >>> >>> At certain points during this process a run may require >>> creating certain linked Class instances (most obviously supers but >>> also classes referenced from the method) and this will initiate >>> the above steps recursively. So, the explicit hand initialization >>> sequence only defines a nominal load+init order. Recursive dependency >>> chasing means that the actual load order may be different. >>> >>> Now as for class String: very early on in this init sequence String gets >>> explicitly loaded. It is one of many classes whose static fields need to >>> be initialized specially to accord with HW, OS or user config setting -- >>> String.COMPACT_STRINGS is one such example. In most normal cases where >>> runtime-specific settings need to be detected the code calls >>> native methods from code to read them. However, for a few of >>> these early-load classes the methods instead initialize to a >>> dummy and the C++ code that hand-loads the class then overwrites the >>> correct values into the static field slots immediately after the load >>> and init of the class has completed. >>> >>> So, in the case of String field COMPACT_STRINGS will be updated by the >>> JVM immediately after running its method. I don't really see >>> how this can make any difference visible to the Graal native image >>> generator. The change to COMPACT_STRINGS wil have happened long before >>> any of the Graal NativeImageGenerator code could even have started >>> running (indeed well before the JVM runtime code like ForkJoinPool that >>> drives the native image process is loaded). So, sorry Bob, but I think >>> you are probably barking up the wrong tree here. >>> >>> > Anyone have a thought or a pointer on what might've changed in the >>> past 3 >>> > weeks, or if I'm completely off base and would be willing to point me >>> in a >>> > more useful direction. >>> Looking at recent changes sounds to me like the best approach. >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Senior Principal Software Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >>> >> From bmcwhirt at redhat.com Thu May 23 17:39:52 2019 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Thu, 23 May 2019 13:39:52 -0400 Subject: JDK11 & Polyglot In-Reply-To: References: Message-ID: And my "solution": https://github.com/oracle/graal/pull/1326 On Thu, May 23, 2019 at 11:55 AM Bob McWhirter wrote: > Progress... maybe? > > In Module$ReflectionData > > /** > * A module (1st key) exports or opens a package to another module > * (2nd key). The map value is a map of package name to a boolean > * that indicates if the package is opened. > */ > static final WeakPairMap> exports = > new WeakPairMap<>(); > > > Ultimately used by Module.isReflectivelyExportedOrOpen(...): > > private boolean isReflectivelyExportedOrOpen(String pn, Module other, boolean open) { > // exported or open to all modules > Map exports = ReflectionData.exports.get(this, EVERYONE_MODULE); > > > > Is the source of things-changing-while-writing-the-heap. > > Not sure how to fix, or if there is a way to whitelist/ignore this. > > I do have an inbound PR to push in a moment helping fix the debug reason > trace, to avoid the "root=null" in the current master#HEAD. > > Caused by: com.oracle.svm.core.util.UserError$UserException: Static field > or an object referenced from a static field changed during native image > generation? > object:com.oracle.truffle.api=true of class: > java.util.concurrent.ConcurrentHashMap$Node > reachable through: > object: [Ljava.util.concurrent.ConcurrentHashMap$Node;@3cb34219 of > class: java.util.concurrent.ConcurrentHashMap$Node[] > object: {com.oracle.truffle.api.dsl=true, > com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, > com.oracle.truffle.api=true} of class: > java.util.concurrent.ConcurrentHashMap > object: java.lang.WeakPairMap$Pair$Weak at 248dd9c1={com.oracle.truffle.api.dsl=true, > com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, > com.oracle.truffle.api=true} of class: > java.util.concurrent.ConcurrentHashMap$Node > object: java.lang.WeakPairMap$Pair$Weak at 40620d6e={jdk.internal.vm.annotation=false, > jdk.internal=false, jdk.internal.reflect=false} of class: > java.util.concurrent.ConcurrentHashMap$Node > object: java.lang.WeakPairMap$Pair$Weak at 40620d6e={com.sun.proxy.jdk.proxy1=false} > of class: java.util.concurrent.ConcurrentHashMap$Node > object: [Ljava.util.concurrent.ConcurrentHashMap$Node;@6e0bf27b of > class: java.util.concurrent.ConcurrentHashMap$Node[] > object: {java.lang.WeakPairMap$Pair$Weak at 64486d2a={org.graalvm.nativeimage.c.constant=true}, > java.lang.WeakPairMap$Pair$Weak at 708aa969={jdk.vm.ci.aarch64=true, > jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, > jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, > jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, > jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, > jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, > jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, > java.lang.WeakPairMap$Pair$Weak at 6f715c77={jdk.vm.ci.common=false}, > java.lang.WeakPairMap$Pair$Weak at 40620d6e={com.sun.proxy.jdk.proxy1=false}, > java.lang.WeakPairMap$Pair$Weak at 40620d6e={jdk.internal.vm.annotation=false, > jdk.internal=false, jdk.internal.reflect=false}, > java.lang.WeakPairMap$Pair$Weak at 248dd9c1={com.oracle.truffle.api.dsl=true, > com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, > com.oracle.truffle.api=true}, java.lang.WeakPairMap$Pair$Weak at 7c968d5b={org.graalvm.compiler.debug=true, > org.graalvm.compiler.nodes=true}, java.lang.WeakPairMap$Pair$Weak at 5ba3fc8d={jdk.vm.ci.aarch64=true, > jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, > jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, > jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, > jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, > jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, > jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, > java.lang.WeakPairMap$Pair$Weak at 6112b142={com.oracle.truffle.api.impl=true, > com.oracle.truffle.polyglot=true}, java.lang.WeakPairMap$Pair$Weak at 3909e5d8={org.graalvm.compiler.graph=true, > org.graalvm.compiler.core.match=true}, > java.lang.WeakPairMap$Pair$Weak at 49834cb1={jdk.vm.ci.aarch64=true, > jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, > jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, > jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, > jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, > jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, > jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, > java.lang.WeakPairMap$Pair$Weak at 2cc8e91b={org.graalvm.word.impl=false}, > java.lang.WeakPairMap$Pair$Weak at 1a0690f3={java.util=true, java.nio=true, > jdk.internal.misc=true, jdk.internal.logger=true, java.lang=true, > java.lang.ref=true, jdk.internal.vm.annotation=true, java.net=true, > java.lang.invoke=true, jdk.internal.ref=true, jdk.internal.module=true, > jdk.internal.reflect=true}, java.lang.WeakPairMap$Pair$Weak at 17197c41={com.sun.proxy.jdk.proxy2=false}, > java.lang.WeakPairMap$Pair$Weak at 21d705a9={org.graalvm.nativeimage.impl=true, > org.graalvm.polyglot=true}, java.lang.WeakPairMap$Pair$Weak at 3515c1ea={jdk.vm.ci.aarch64=false, > jdk.vm.ci.meta=false, jdk.vm.ci.code.site=false, jdk.vm.ci.services=false, > jdk.vm.ci.code=false, jdk.vm.ci.common=false, jdk.vm.ci.hotspot=false, > jdk.vm.ci.runtime=false, jdk.vm.ci.amd64=false}} of class: > java.util.concurrent.ConcurrentHashMap > object: java.lang.WeakPairMap at 3b3c322f of class: > java.lang.WeakPairMap > root: java.lang.Module.isReflectivelyExportedOrOpen(String, Module, > boolean) > > > > On Thu, May 23, 2019 at 9:19 AM Bob McWhirter wrote: > >> Seems like an intermittent/transient failure, as this morning it all >> built cleanly. >> >> Good times. >> >> -Bob >> >> On Thu, May 23, 2019 at 6:36 AM Bob McWhirter >> wrote: >> >>> Thanks Andrew! >>> >>> I?ll continue to poke around. When I was getting the ObjectIdentifier >>> variant there simple aren?t many statics available. There?s a none-static >>> stringForm field of type String. Maybe I?m just misunderstanding the error >>> message also. >>> >>> Time to git log. >>> >>> Bob >>> >>> On Thu, May 23, 2019 at 5:02 AM Andrew Dinn wrote: >>> >>>> On 22/05/2019 19:20, Bob McWhirter wrote: >>>> > With the new JDK11 changes, at one point I could build >>>> polyglot/libpolyglot >>>> > with JDK11. >>>> > >>>> > Currently, though, I'm hitting: >>>> > . . . >>>> > I sense that it might be the transient static boolean COMPACT_STRINGS >>>> on >>>> > String.class ultimately causing it, but that's not necessarily a >>>> warranted >>>> > opinion. It always seems to be a String problem, and COMPACT_STRINGS >>>> is >>>> > designated as set by the JVM at runtime, not to the true that appears >>>> in >>>> > the source. >>>> >>>> I'm not sure how this could be the issue. I say that because I do >>>> understand what goes on with this field in the JVM. Here is the context: >>>> >>>> During JVM startup various Java classes are constructed 'by hand' i.e. >>>> >>>> the bytecodes are loaded >>>> the JVM-internal metadata model for the class is created >>>> (C++ object InstanceKlass plus auxiliary objects like Symbol. method >>>> etc) >>>> the JVM-heap allocated Class is created >>>> the Class's method is run >>>> >>>> This is done in a very specific sequence starting with some Exception >>>> classes that have no dependencies on supers or linked classes and >>>> proceeding to classes like String, Thread, ThreadGroup etc. >>>> >>>> At certain points during this process a run may require >>>> creating certain linked Class instances (most obviously supers but >>>> also classes referenced from the method) and this will initiate >>>> the above steps recursively. So, the explicit hand initialization >>>> sequence only defines a nominal load+init order. Recursive dependency >>>> chasing means that the actual load order may be different. >>>> >>>> Now as for class String: very early on in this init sequence String gets >>>> explicitly loaded. It is one of many classes whose static fields need to >>>> be initialized specially to accord with HW, OS or user config setting -- >>>> String.COMPACT_STRINGS is one such example. In most normal cases where >>>> runtime-specific settings need to be detected the code calls >>>> native methods from code to read them. However, for a few of >>>> these early-load classes the methods instead initialize to a >>>> dummy and the C++ code that hand-loads the class then overwrites the >>>> correct values into the static field slots immediately after the load >>>> and init of the class has completed. >>>> >>>> So, in the case of String field COMPACT_STRINGS will be updated by the >>>> JVM immediately after running its method. I don't really see >>>> how this can make any difference visible to the Graal native image >>>> generator. The change to COMPACT_STRINGS wil have happened long before >>>> any of the Graal NativeImageGenerator code could even have started >>>> running (indeed well before the JVM runtime code like ForkJoinPool that >>>> drives the native image process is loaded). So, sorry Bob, but I think >>>> you are probably barking up the wrong tree here. >>>> >>>> > Anyone have a thought or a pointer on what might've changed in the >>>> past 3 >>>> > weeks, or if I'm completely off base and would be willing to point me >>>> in a >>>> > more useful direction. >>>> Looking at recent changes sounds to me like the best approach. >>>> >>>> regards, >>>> >>>> >>>> Andrew Dinn >>>> ----------- >>>> Senior Principal Software Engineer >>>> Red Hat UK Ltd >>>> Registered in England and Wales under Company Registration No. 03798903 >>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >>>> >>> From david.lloyd at redhat.com Thu May 23 19:17:57 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 23 May 2019 14:17:57 -0500 Subject: JDK11 & Polyglot In-Reply-To: References: Message-ID: I think that if/when JPMS support comes in, it'll probably substitute all these classes away with native image focused versions, similarly perhaps to how classes are done. So IMO this kind of fix is just fine. On Thu, May 23, 2019 at 12:41 PM Bob McWhirter wrote: > > And my "solution": > > https://github.com/oracle/graal/pull/1326 > > On Thu, May 23, 2019 at 11:55 AM Bob McWhirter wrote: > > > Progress... maybe? > > > > In Module$ReflectionData > > > > /** > > * A module (1st key) exports or opens a package to another module > > * (2nd key). The map value is a map of package name to a boolean > > * that indicates if the package is opened. > > */ > > static final WeakPairMap> exports = > > new WeakPairMap<>(); > > > > > > Ultimately used by Module.isReflectivelyExportedOrOpen(...): > > > > private boolean isReflectivelyExportedOrOpen(String pn, Module other, boolean open) { > > // exported or open to all modules > > Map exports = ReflectionData.exports.get(this, EVERYONE_MODULE); > > > > > > > > Is the source of things-changing-while-writing-the-heap. > > > > Not sure how to fix, or if there is a way to whitelist/ignore this. > > > > I do have an inbound PR to push in a moment helping fix the debug reason > > trace, to avoid the "root=null" in the current master#HEAD. > > > > Caused by: com.oracle.svm.core.util.UserError$UserException: Static field > > or an object referenced from a static field changed during native image > > generation? > > object:com.oracle.truffle.api=true of class: > > java.util.concurrent.ConcurrentHashMap$Node > > reachable through: > > object: [Ljava.util.concurrent.ConcurrentHashMap$Node;@3cb34219 of > > class: java.util.concurrent.ConcurrentHashMap$Node[] > > object: {com.oracle.truffle.api.dsl=true, > > com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, > > com.oracle.truffle.api=true} of class: > > java.util.concurrent.ConcurrentHashMap > > object: java.lang.WeakPairMap$Pair$Weak at 248dd9c1={com.oracle.truffle.api.dsl=true, > > com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, > > com.oracle.truffle.api=true} of class: > > java.util.concurrent.ConcurrentHashMap$Node > > object: java.lang.WeakPairMap$Pair$Weak at 40620d6e={jdk.internal.vm.annotation=false, > > jdk.internal=false, jdk.internal.reflect=false} of class: > > java.util.concurrent.ConcurrentHashMap$Node > > object: java.lang.WeakPairMap$Pair$Weak at 40620d6e={com.sun.proxy.jdk.proxy1=false} > > of class: java.util.concurrent.ConcurrentHashMap$Node > > object: [Ljava.util.concurrent.ConcurrentHashMap$Node;@6e0bf27b of > > class: java.util.concurrent.ConcurrentHashMap$Node[] > > object: {java.lang.WeakPairMap$Pair$Weak at 64486d2a={org.graalvm.nativeimage.c.constant=true}, > > java.lang.WeakPairMap$Pair$Weak at 708aa969={jdk.vm.ci.aarch64=true, > > jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, > > jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, > > jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, > > jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, > > jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, > > jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, > > java.lang.WeakPairMap$Pair$Weak at 6f715c77={jdk.vm.ci.common=false}, > > java.lang.WeakPairMap$Pair$Weak at 40620d6e={com.sun.proxy.jdk.proxy1=false}, > > java.lang.WeakPairMap$Pair$Weak at 40620d6e={jdk.internal.vm.annotation=false, > > jdk.internal=false, jdk.internal.reflect=false}, > > java.lang.WeakPairMap$Pair$Weak at 248dd9c1={com.oracle.truffle.api.dsl=true, > > com.oracle.truffle.api.library=true, com.oracle.truffle.api.nodes=true, > > com.oracle.truffle.api=true}, java.lang.WeakPairMap$Pair$Weak at 7c968d5b={org.graalvm.compiler.debug=true, > > org.graalvm.compiler.nodes=true}, java.lang.WeakPairMap$Pair$Weak at 5ba3fc8d={jdk.vm.ci.aarch64=true, > > jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, > > jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, > > jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, > > jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, > > jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, > > jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, > > java.lang.WeakPairMap$Pair$Weak at 6112b142={com.oracle.truffle.api.impl=true, > > com.oracle.truffle.polyglot=true}, java.lang.WeakPairMap$Pair$Weak at 3909e5d8={org.graalvm.compiler.graph=true, > > org.graalvm.compiler.core.match=true}, > > java.lang.WeakPairMap$Pair$Weak at 49834cb1={jdk.vm.ci.aarch64=true, > > jdk.vm.ci.services=true, jdk.vm.ci.common=true, jdk.vm.ci.code=true, > > jdk.vm.ci.hotspot.aarch64=true, jdk.vm.ci.runtime=true, > > jdk.vm.ci.hotspot.sparc=true, jdk.vm.ci.code.stack=true, > > jdk.vm.ci.hotspot.amd64=true, jdk.vm.ci.meta=true, > > jdk.vm.ci.code.site=true, jdk.vm.ci.sparc=true, jdk.vm.ci.hotspot=true, > > jdk.vm.ci.services.internal=true, jdk.vm.ci.amd64=true}, > > java.lang.WeakPairMap$Pair$Weak at 2cc8e91b={org.graalvm.word.impl=false}, > > java.lang.WeakPairMap$Pair$Weak at 1a0690f3={java.util=true, java.nio=true, > > jdk.internal.misc=true, jdk.internal.logger=true, java.lang=true, > > java.lang.ref=true, jdk.internal.vm.annotation=true, java.net=true, > > java.lang.invoke=true, jdk.internal.ref=true, jdk.internal.module=true, > > jdk.internal.reflect=true}, java.lang.WeakPairMap$Pair$Weak at 17197c41={com.sun.proxy.jdk.proxy2=false}, > > java.lang.WeakPairMap$Pair$Weak at 21d705a9={org.graalvm.nativeimage.impl=true, > > org.graalvm.polyglot=true}, java.lang.WeakPairMap$Pair$Weak at 3515c1ea={jdk.vm.ci.aarch64=false, > > jdk.vm.ci.meta=false, jdk.vm.ci.code.site=false, jdk.vm.ci.services=false, > > jdk.vm.ci.code=false, jdk.vm.ci.common=false, jdk.vm.ci.hotspot=false, > > jdk.vm.ci.runtime=false, jdk.vm.ci.amd64=false}} of class: > > java.util.concurrent.ConcurrentHashMap > > object: java.lang.WeakPairMap at 3b3c322f of class: > > java.lang.WeakPairMap > > root: java.lang.Module.isReflectivelyExportedOrOpen(String, Module, > > boolean) > > > > > > > > On Thu, May 23, 2019 at 9:19 AM Bob McWhirter wrote: > > > >> Seems like an intermittent/transient failure, as this morning it all > >> built cleanly. > >> > >> Good times. > >> > >> -Bob > >> > >> On Thu, May 23, 2019 at 6:36 AM Bob McWhirter > >> wrote: > >> > >>> Thanks Andrew! > >>> > >>> I?ll continue to poke around. When I was getting the ObjectIdentifier > >>> variant there simple aren?t many statics available. There?s a none-static > >>> stringForm field of type String. Maybe I?m just misunderstanding the error > >>> message also. > >>> > >>> Time to git log. > >>> > >>> Bob > >>> > >>> On Thu, May 23, 2019 at 5:02 AM Andrew Dinn wrote: > >>> > >>>> On 22/05/2019 19:20, Bob McWhirter wrote: > >>>> > With the new JDK11 changes, at one point I could build > >>>> polyglot/libpolyglot > >>>> > with JDK11. > >>>> > > >>>> > Currently, though, I'm hitting: > >>>> > . . . > >>>> > I sense that it might be the transient static boolean COMPACT_STRINGS > >>>> on > >>>> > String.class ultimately causing it, but that's not necessarily a > >>>> warranted > >>>> > opinion. It always seems to be a String problem, and COMPACT_STRINGS > >>>> is > >>>> > designated as set by the JVM at runtime, not to the true that appears > >>>> in > >>>> > the source. > >>>> > >>>> I'm not sure how this could be the issue. I say that because I do > >>>> understand what goes on with this field in the JVM. Here is the context: > >>>> > >>>> During JVM startup various Java classes are constructed 'by hand' i.e. > >>>> > >>>> the bytecodes are loaded > >>>> the JVM-internal metadata model for the class is created > >>>> (C++ object InstanceKlass plus auxiliary objects like Symbol. method > >>>> etc) > >>>> the JVM-heap allocated Class is created > >>>> the Class's method is run > >>>> > >>>> This is done in a very specific sequence starting with some Exception > >>>> classes that have no dependencies on supers or linked classes and > >>>> proceeding to classes like String, Thread, ThreadGroup etc. > >>>> > >>>> At certain points during this process a run may require > >>>> creating certain linked Class instances (most obviously supers but > >>>> also classes referenced from the method) and this will initiate > >>>> the above steps recursively. So, the explicit hand initialization > >>>> sequence only defines a nominal load+init order. Recursive dependency > >>>> chasing means that the actual load order may be different. > >>>> > >>>> Now as for class String: very early on in this init sequence String gets > >>>> explicitly loaded. It is one of many classes whose static fields need to > >>>> be initialized specially to accord with HW, OS or user config setting -- > >>>> String.COMPACT_STRINGS is one such example. In most normal cases where > >>>> runtime-specific settings need to be detected the code calls > >>>> native methods from code to read them. However, for a few of > >>>> these early-load classes the methods instead initialize to a > >>>> dummy and the C++ code that hand-loads the class then overwrites the > >>>> correct values into the static field slots immediately after the load > >>>> and init of the class has completed. > >>>> > >>>> So, in the case of String field COMPACT_STRINGS will be updated by the > >>>> JVM immediately after running its method. I don't really see > >>>> how this can make any difference visible to the Graal native image > >>>> generator. The change to COMPACT_STRINGS wil have happened long before > >>>> any of the Graal NativeImageGenerator code could even have started > >>>> running (indeed well before the JVM runtime code like ForkJoinPool that > >>>> drives the native image process is loaded). So, sorry Bob, but I think > >>>> you are probably barking up the wrong tree here. > >>>> > >>>> > Anyone have a thought or a pointer on what might've changed in the > >>>> past 3 > >>>> > weeks, or if I'm completely off base and would be willing to point me > >>>> in a > >>>> > more useful direction. > >>>> Looking at recent changes sounds to me like the best approach. > >>>> > >>>> regards, > >>>> > >>>> > >>>> Andrew Dinn > >>>> ----------- > >>>> Senior Principal Software Engineer > >>>> Red Hat UK Ltd > >>>> Registered in England and Wales under Company Registration No. 03798903 > >>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > >>>> > >>> -- - DML From adinn at redhat.com Fri May 24 09:48:18 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 May 2019 10:48:18 +0100 Subject: JDK11 & Polyglot In-Reply-To: References: Message-ID: <81322734-1f9a-1e8c-4e53-ff80b897c8cb@redhat.com> On 23/05/2019 20:17, David Lloyd wrote: > I think that if/when JPMS support comes in, it'll probably substitute > all these classes away with native image focused versions, similarly > perhaps to how classes are done. So IMO this kind of fix is just > fine. Yeah, I believe the WeakPairMap is needed because on the JVM modules may get garbage collected when their component classes are unloaded -- we don't want the map to end up keeping the modules alive. When full support for Modules is added to the native image generator the set of modules ought not be able to fluctuate (class unloading ain't a thing in native). So, there will be no need to employ weak references in whatever proxy is employed for the module linkage map. Your current fix looks fine as a temporary hack. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From java at rkive.org Sun May 26 22:21:23 2019 From: java at rkive.org (Carl M) Date: Sun, 26 May 2019 18:21:23 -0400 (EDT) Subject: Graal generated assembly much larger than C2 Message-ID: <1164656357.1022332.1558909283616@email.ionos.com> Hi, I am new to trying out Graal, and found that it was much slower for a trivial benchmark I wrote. I was surprised that it was about 40% slower, so I dumped the assembly and found it was much larger for the Graal version. I collected a dump of the assembly, but I am not much of a compiler person so I don't know what to do with it. Is this the right list to see if there is something wrong? Assembly of each compiler (and JVM flags): https://gist.github.com/carl-mastrangelo/5fe2f1f744c05ca20242cad9b5f7fb26 Source code inner loop: https://github.com/carl-mastrangelo/perfmark/blob/b266d9494054b5a2d09bc62f7b234d693e2d5173/java9/src/main/java/io/perfmark/java9/VarHandleMarkHolder.java#L129 From thomas.wuerthinger at oracle.com Mon May 27 13:09:18 2019 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 27 May 2019 15:09:18 +0200 Subject: Graal generated assembly much larger than C2 In-Reply-To: <1164656357.1022332.1558909283616@email.ionos.com> References: <1164656357.1022332.1558909283616@email.ionos.com> Message-ID: <866599BC-D573-4624-8943-89B81FDD0FB9@oracle.com> Hi Carl, Can you further reduce this test case to one VarHandle#setOpaque call? It is likely that there is a wrong intrinsification of either VarHandle#setOpaque, VarHandle#setRelease, or VarHandle#storeStoreFence. Not much to do for the compiler overall here as the code only consists of special case intrinsics. Also, does this also run on the latest JDK13 EA? The version of the compiler in JDK11 is not the latest one. - thomas > On 27 May 2019, at 00:21, Carl M wrote: > > Hi, > > I am new to trying out Graal, and found that it was much slower for > a trivial benchmark I wrote. I was surprised that it was about 40% > slower, so I dumped the assembly and found it was much larger for > the Graal version. I collected a dump of the assembly, but I am not > much of a compiler person so I don't know what to do with it. > > Is this the right list to see if there is something wrong? > > > Assembly of each compiler (and JVM flags): > https://gist.github.com/carl-mastrangelo/5fe2f1f744c05ca20242cad9b5f7fb26 > > > Source code inner loop: > https://github.com/carl-mastrangelo/perfmark/blob/b266d9494054b5a2d09bc62f7b234d693e2d5173/java9/src/main/java/io/perfmark/java9/VarHandleMarkHolder.java#L129 From java at rkive.org Mon May 27 19:45:59 2019 From: java at rkive.org (Carl M) Date: Mon, 27 May 2019 15:45:59 -0400 (EDT) Subject: Graal generated assembly much larger than C2 In-Reply-To: <866599BC-D573-4624-8943-89B81FDD0FB9@oracle.com> References: <1164656357.1022332.1558909283616@email.ionos.com> <866599BC-D573-4624-8943-89B81FDD0FB9@oracle.com> Message-ID: <997558440.1058157.1558986359910@email.ionos.com> Hi Thomas, I retried using 13-ea+22 (previously 11.0.2) and found that while the generated code is smaller, a lot of the Flags I passed don't seem to work anymore. The bytecode is not interleaved in the generated assembly any more (I don't know which flag sets this) and the -XX:PrintAssemblyOptions=intel flag no longer seems to work. I also tried this on a non-Graal benchmark run, and it had the same problem. Perhaps something wrong in 13? The code that was produced was a little smaller (364 -> 346 bytes). The generated (un-annotated assembly) is here: https://gist.github.com/carl-mastrangelo/7f1def204ae5d6e76268cc42b8c1af45 I haven't tried limiting the benchmark to just setOpaque, since I can't see the bytecode interleaved (to confirm it's doing what I think it is). > On May 27, 2019 at 9:09 AM Thomas Wuerthinger wrote: > > > Hi Carl, > > Can you further reduce this test case to one VarHandle#setOpaque call? > > It is likely that there is a wrong intrinsification of either VarHandle#setOpaque, VarHandle#setRelease, or VarHandle#storeStoreFence. Not much to do for the compiler overall here as the code only consists of special case intrinsics. > > Also, does this also run on the latest JDK13 EA? The version of the compiler in JDK11 is not the latest one. > > > * thomas > > > > On 27 May 2019, at 00:21, Carl M wrote: > > > > Hi, > > > > I am new to trying out Graal, and found that it was much slower for > > a trivial benchmark I wrote. I was surprised that it was about 40% > > slower, so I dumped the assembly and found it was much larger for > > the Graal version. I collected a dump of the assembly, but I am not > > much of a compiler person so I don't know what to do with it. > > > > Is this the right list to see if there is something wrong? > > > > > > Assembly of each compiler (and JVM flags): > > https://gist.github.com/carl-mastrangelo/5fe2f1f744c05ca20242cad9b5f7fb26 > > > > > > Source code inner loop: > > https://github.com/carl-mastrangelo/perfmark/blob/b266d9494054b5a2d09bc62f7b234d693e2d5173/java9/src/main/java/io/perfmark/java9/VarHandleMarkHolder.java#L129 From tobias.hartmann at oracle.com Tue May 28 07:26:02 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 May 2019 09:26:02 +0200 Subject: Graal generated assembly much larger than C2 In-Reply-To: <997558440.1058157.1558986359910@email.ionos.com> References: <1164656357.1022332.1558909283616@email.ionos.com> <866599BC-D573-4624-8943-89B81FDD0FB9@oracle.com> <997558440.1058157.1558986359910@email.ionos.com> Message-ID: <38b2f828-e198-d803-d95f-2c29224c1111@oracle.com> Hi Carl, On 27.05.19 21:45, Carl M wrote: > I retried using 13-ea+22 (previously 11.0.2) and found that while the generated code is smaller, a lot of the Flags I passed don't seem to work anymore. The bytecode is not interleaved in the generated assembly any more (I don't know which flag sets this) and the -XX:PrintAssemblyOptions=intel flag no longer seems to work. I also tried this on a non-Graal benchmark run, and it had the same problem. Perhaps something wrong in 13? This sounds like the following bug which is not yet fixed in any EA build: https://bugs.openjdk.java.net/browse/JDK-8224672 The problem was introduced in JDK 13 build 22. Best regards, Tobias From dean.long at oracle.com Wed May 29 00:31:14 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 28 May 2019 17:31:14 -0700 Subject: RFR(XS) 8224931: disable JAOTC invokedynamic support until 8223533 is fixed Message-ID: https://bugs.openjdk.java.net/browse/JDK-8224931 http://cr.openjdk.java.net/~dlong/8224931/webrev/ Disable JAOTC invokedynamic support temporarily.? Register a plugin that always returns false for supportsDynamicInvoke(), which causes the parser to insert deoptimize nodes. dl From vladimir.kozlov at oracle.com Wed May 29 00:58:44 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 May 2019 17:58:44 -0700 Subject: RFR(XS) 8224931: disable JAOTC invokedynamic support until 8223533 is fixed In-Reply-To: References: Message-ID: <7100BBCD-EE5A-472C-A9CB-F16196C2B038@oracle.com> Good. Thanks Vladimir > On May 28, 2019, at 5:31 PM, dean.long at oracle.com wrote: > > https://bugs.openjdk.java.net/browse/JDK-8224931 > http://cr.openjdk.java.net/~dlong/8224931/webrev/ > > Disable JAOTC invokedynamic support temporarily. Register a plugin that always returns false for supportsDynamicInvoke(), which causes the parser to insert deoptimize nodes. > > dl From dean.long at oracle.com Wed May 29 05:28:32 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 28 May 2019 22:28:32 -0700 Subject: RFR(XS) 8224931: disable JAOTC invokedynamic support until 8223533 is fixed In-Reply-To: <7100BBCD-EE5A-472C-A9CB-F16196C2B038@oracle.com> References: <7100BBCD-EE5A-472C-A9CB-F16196C2B038@oracle.com> Message-ID: Thanks Vladimir. dl On 5/28/19 5:58 PM, Vladimir Kozlov wrote: > Good. > > Thanks > Vladimir > >> On May 28, 2019, at 5:31 PM, dean.long at oracle.com wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8224931 >> http://cr.openjdk.java.net/~dlong/8224931/webrev/ >> >> Disable JAOTC invokedynamic support temporarily. Register a plugin that always returns false for supportsDynamicInvoke(), which causes the parser to insert deoptimize nodes. >> >> dl From tom.rodriguez at oracle.com Wed May 29 18:59:17 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 29 May 2019 11:59:17 -0700 Subject: RFR(XS) 8224931: disable JAOTC invokedynamic support until 8223533 is fixed In-Reply-To: References: Message-ID: <54ae61a3-059a-0975-4b53-2b55ca36e36d@oracle.com> Looks good. tom dean.long at oracle.com wrote on 5/28/19 5:31 PM: > https://bugs.openjdk.java.net/browse/JDK-8224931 > http://cr.openjdk.java.net/~dlong/8224931/webrev/ > > Disable JAOTC invokedynamic support temporarily.? Register a plugin that > always returns false for supportsDynamicInvoke(), which causes the > parser to insert deoptimize nodes. > > dl From dean.long at oracle.com Wed May 29 20:10:34 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 29 May 2019 13:10:34 -0700 Subject: RFR(XS) 8224931: disable JAOTC invokedynamic support until 8223533 is fixed In-Reply-To: <54ae61a3-059a-0975-4b53-2b55ca36e36d@oracle.com> References: <54ae61a3-059a-0975-4b53-2b55ca36e36d@oracle.com> Message-ID: Thanks Tom. dl On 5/29/19 11:59 AM, Tom Rodriguez wrote: > Looks good. > > tom > > dean.long at oracle.com wrote on 5/28/19 5:31 PM: >> https://bugs.openjdk.java.net/browse/JDK-8224931 >> http://cr.openjdk.java.net/~dlong/8224931/webrev/ >> >> Disable JAOTC invokedynamic support temporarily.? Register a plugin >> that always returns false for supportsDynamicInvoke(), which causes >> the parser to insert deoptimize nodes. >> >> dl