From HORII at jp.ibm.com Thu Sep 1 14:26:33 2016 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Thu, 1 Sep 2016 23:26:33 +0900 Subject: RFR(m): java.nio.Bits.unaligned() doesn't return true on ppc Message-ID: Dear all: Can I please request reviews for the following change? This change was created for JDK 8. Some open sources (such as Spark 2.0) check java.nio.Bits.unaligned() to recognize support of unaligned memory access in platform. Though ppc64 and ppc64le support it, unaligned() returns false. In JDK 9, this method returns unalignedAccess() of jdk.internal.misc.Unsafe that doesn't exist in JDK8. jira: https://bugs.openjdk.java.net/browse/JDK-8165231 webrev: http://cr.openjdk.java.net/~gromero/8165231/ (Due to my login issue to the cs.openjdk.java.net, Gustavo thankfully created this webrev.) Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Sep 1 15:06:04 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 1 Sep 2016 15:06:04 +0000 Subject: RFR(m): java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: References: Message-ID: <8ac308450e3c4a9d92346c16cae553ad@DEWDFE13DE14.global.corp.sap> Hi Hiroshi, thanks for providing a fix. The fix 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions was downported to 8, so I think your change is good. Best regards, Martin From: Hiroshi H Horii [mailto:HORII at jp.ibm.com] Sent: Donnerstag, 1. September 2016 16:27 To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Cc: Gustavo Bueno Romero ; Volker Simonis (volker.simonis at gmail.com) ; Doerr, Martin Subject: RFR(m): java.nio.Bits.unaligned() doesn't return true on ppc Dear all: Can I please request reviews for the following change? This change was created for JDK 8. Some open sources (such as Spark 2.0) check java.nio.Bits.unaligned() to recognize support of unaligned memory access in platform. Though ppc64 and ppc64le support it, unaligned() returns false. In JDK 9, this method returns unalignedAccess() of jdk.internal.misc.Unsafe that doesn't exist in JDK8. jira: https://bugs.openjdk.java.net/browse/JDK-8165231 webrev: http://cr.openjdk.java.net/~gromero/8165231/ (Due to my login issue to the cs.openjdk.java.net, Gustavo thankfully created this webrev.) Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Sep 13 08:37:08 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 13 Sep 2016 10:37:08 +0200 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc Message-ID: Hi Alan, Sean, can we please get a review for this rather trivial change? > jira: https://bugs.openjdk.java.net/browse/JDK-8165231 > webrev: http://cr.openjdk.java.net/~gromero/8165231/ As outlined in Hiroshi's initial mail, we can not simply downport the solution used in jdk9 for querying the unaligned access support in nio because of differences in Unsafe. So this is a jsk8u-only change. But I think it is simple enough and doesn't affect any other platform except ppc to justify it. As nobody from the ppc porting team is jdk8u reviewer, I kindly ask you for a review and the permission to integrate into jdk8u. Thanks a lot and best regards, Volker On Thu, Sep 1, 2016 at 5:06 PM, Doerr, Martin wrote: > Hi Hiroshi, > > > > thanks for providing a fix. > > > > The fix > > 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of > illegal instructions > > was downported to 8, so I think your change is good. > > > > Best regards, > > Martin > > > > > > From: Hiroshi H Horii [mailto:HORII at jp.ibm.com] > Sent: Donnerstag, 1. September 2016 16:27 > To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Cc: Gustavo Bueno Romero ; Volker Simonis > (volker.simonis at gmail.com) ; Doerr, Martin > > Subject: RFR(m): java.nio.Bits.unaligned() doesn't return true on ppc > > > > Dear all: > > Can I please request reviews for the following change? > This change was created for JDK 8. > > Some open sources (such as Spark 2.0) check java.nio.Bits.unaligned() > to recognize support of unaligned memory access in platform. > Though ppc64 and ppc64le support it, unaligned() returns false. > > In JDK 9, this method returns unalignedAccess() of jdk.internal.misc.Unsafe > that doesn't exist in JDK8. > > jira: https://bugs.openjdk.java.net/browse/JDK-8165231 > webrev: http://cr.openjdk.java.net/~gromero/8165231/ > (Due to my login issue to the cs.openjdk.java.net, Gustavo thankfully > created this webrev.) > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo From sean.coffey at oracle.com Tue Sep 13 10:35:16 2016 From: sean.coffey at oracle.com (Sean Coffey) Date: Tue, 13 Sep 2016 11:35:16 +0100 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: References: Message-ID: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> Hi Volker, The fix looks fine to me. Please add the '9-na' label to the bug report. Also add a suitable noreg- label. It would also be useful to link the issue to JDK-8158260 Approved for jdk8u-dev. regards, Sean. On 13/09/2016 09:37, Volker Simonis wrote: > Hi Alan, Sean, > > can we please get a review for this rather trivial change? > >> jira: https://bugs.openjdk.java.net/browse/JDK-8165231 >> webrev: http://cr.openjdk.java.net/~gromero/8165231/ > As outlined in Hiroshi's initial mail, we can not simply downport the > solution used in jdk9 for querying the unaligned access support in nio > because of differences in Unsafe. So this is a jsk8u-only change. But > I think it is simple enough and doesn't affect any other platform > except ppc to justify it. > > As nobody from the ppc porting team is jdk8u reviewer, I kindly ask > you for a review and the permission to integrate into jdk8u. > > Thanks a lot and best regards, > Volker > > > On Thu, Sep 1, 2016 at 5:06 PM, Doerr, Martin wrote: >> Hi Hiroshi, >> >> >> >> thanks for providing a fix. >> >> >> >> The fix >> >> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of >> illegal instructions >> >> was downported to 8, so I think your change is good. >> >> >> >> Best regards, >> >> Martin >> >> >> >> >> >> From: Hiroshi H Horii [mailto:HORII at jp.ibm.com] >> Sent: Donnerstag, 1. September 2016 16:27 >> To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Cc: Gustavo Bueno Romero ; Volker Simonis >> (volker.simonis at gmail.com) ; Doerr, Martin >> >> Subject: RFR(m): java.nio.Bits.unaligned() doesn't return true on ppc >> >> >> >> Dear all: >> >> Can I please request reviews for the following change? >> This change was created for JDK 8. >> >> Some open sources (such as Spark 2.0) check java.nio.Bits.unaligned() >> to recognize support of unaligned memory access in platform. >> Though ppc64 and ppc64le support it, unaligned() returns false. >> >> In JDK 9, this method returns unalignedAccess() of jdk.internal.misc.Unsafe >> that doesn't exist in JDK8. >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8165231 >> webrev: http://cr.openjdk.java.net/~gromero/8165231/ >> (Due to my login issue to the cs.openjdk.java.net, Gustavo thankfully >> created this webrev.) >> >> Regards, >> Hiroshi >> ----------------------- >> Hiroshi Horii, Ph.D. >> IBM Research - Tokyo From volker.simonis at gmail.com Tue Sep 13 12:09:39 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 13 Sep 2016 14:09:39 +0200 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> References: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> Message-ID: Hi Sean, thanks a lot for the fast response. I've updated the bug entry as requested and will push the change - maybe with the following potential improvement: @Hiroshi: also maybe not that performance relevant, I think we should we also fix sun/security/provider/ByteArrayAccess.java which contains the same construct: // Return whether this platform supports full speed int/long memory access // at unaligned addresses. // This code was copied from java.nio.Bits because there is no equivalent // public API. private static boolean unaligned() { String arch = java.security.AccessController.doPrivileged (new sun.security.action.GetPropertyAction("os.arch", "")); return arch.equals("i386") || arch.equals("x86") || arch.equals("amd64") || arch.equals("x86_64"); } Regards, Volker From sean.coffey at oracle.com Tue Sep 13 12:45:19 2016 From: sean.coffey at oracle.com (Sean Coffey) Date: Tue, 13 Sep 2016 13:45:19 +0100 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: References: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> Message-ID: <962ae958-5897-6e9b-eec3-33680358ad0b@oracle.com> Sounds good Volker. Good catch. regards, Sean. On 13/09/2016 13:09, Volker Simonis wrote: > Hi Sean, > > thanks a lot for the fast response. I've updated the bug entry as > requested and will push the change - maybe with the following > potential improvement: > > @Hiroshi: also maybe not that performance relevant, I think we should > we also fix sun/security/provider/ByteArrayAccess.java which contains > the same construct: > > // Return whether this platform supports full speed int/long memory access > // at unaligned addresses. > // This code was copied from java.nio.Bits because there is no equivalent > // public API. > private static boolean unaligned() { > String arch = java.security.AccessController.doPrivileged > (new sun.security.action.GetPropertyAction("os.arch", "")); > return arch.equals("i386") || arch.equals("x86") || arch.equals("amd64") > || arch.equals("x86_64"); > } > > Regards, > Volker From HORII at jp.ibm.com Thu Sep 15 06:08:41 2016 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Thu, 15 Sep 2016 15:08:41 +0900 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: <962ae958-5897-6e9b-eec3-33680358ad0b@oracle.com> References: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> <962ae958-5897-6e9b-eec3-33680358ad0b@oracle.com> Message-ID: Hi Volker, and Sean, Thank you for your comments and suggestion. I and Gustavo created a webrev that includes Bits and ByteArrayAccess. http://cr.openjdk.java.net/~gromero/8165231/02/ I believe there is no other similar methods in jdk. Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo From: Sean Coffey To: Volker Simonis Cc: "jdk8u-dev at openjdk.java.net" , Java Core Libs , Hiroshi H Horii/Japan/IBM at IBMJP, "ppc-aix-port-dev at openjdk.java.net" , Gustavo Bueno Romero , "Doerr, Martin" Date: 09/13/2016 21:46 Subject: Re: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc Sounds good Volker. Good catch. regards, Sean. On 13/09/2016 13:09, Volker Simonis wrote: > Hi Sean, > > thanks a lot for the fast response. I've updated the bug entry as > requested and will push the change - maybe with the following > potential improvement: > > @Hiroshi: also maybe not that performance relevant, I think we should > we also fix sun/security/provider/ByteArrayAccess.java which contains > the same construct: > > // Return whether this platform supports full speed int/long memory access > // at unaligned addresses. > // This code was copied from java.nio.Bits because there is no equivalent > // public API. > private static boolean unaligned() { > String arch = java.security.AccessController.doPrivileged > (new sun.security.action.GetPropertyAction("os.arch", "")); > return arch.equals("i386") || arch.equals("x86") || arch.equals("amd64") > || arch.equals("x86_64"); > } > > Regards, > Volker -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Sep 16 09:58:27 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 16 Sep 2016 09:58:27 +0000 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build Message-ID: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Hi, the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ Thanks Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Kumar Srinivasan > Sent: Montag, 12. September 2016 22:57 > To: core-libs-dev ; Mandy Chung > ; Chris Bensen > Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using > > Hello, > > I am sponsoring this changeset for Chris Bensen of the java packager > team, please review fix for the launcher to better locate java.home. > > http://cr.openjdk.java.net/~ksrini/8165524/ > > Thanks > Kumar From mandy.chung at oracle.com Fri Sep 16 17:31:10 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Sep 2016 10:31:10 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: <798C46FD-9A42-4DC2-AE6F-BE51FD636987@oracle.com> > On Sep 16, 2016, at 2:58 AM, Langer, Christoph wrote: > > Hi, > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. > > There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ This looks okay. It?d be good to consolidate the hotspot and awt code as a JVM entry point. But launcher would need to carry this copy since dladdr is called before libjvm.so is loaded. formatting nit: not align with lines above (4-space indentation) 55 } 56 return 0; Mandy From volker.simonis at gmail.com Fri Sep 16 17:34:07 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 16 Sep 2016 19:34:07 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: Hi Christoph, I think your change is fine as a quick-fix to fix the build. But you're completely right that this should be reworked in the long term. I hate to see that we now have the third version of these routines in the OpenJDK. Unfortunately a clean solution is not trivial. libjli is not linked against libjvm because libjli is actually used to load libjvm. So we can not put the dladdr routines for AIX there. But I think we should at least consolidate the two versions which will be in the class library after your change. Initially I intentionally put porting_aix.{c,h} into jdk/aix/porting with the intent to make it available to ALL jdk native libraries. Unfortunately, with the source code reorganization due to the modular changes, the common, top-level aix repository had to go away and the code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. With the reorganized, modularized source code layout and build system it is not possible to share code between modules. We somehow have to fix this although I currently don't know how. IF somebody has an idea, please let me know :) Regarding your change: - can you please move +#if defined(_AIX) +#include "java_md_aix.h" +#endif + from java_md_common.c to the end of java.base/unix/native/libjli/java_md.h. It will then be automatically included into java_md_common.c trough java.h which includes java_md.h Also, this version of dladdr is inherently not thread safe. I don't think that's a problem here, but it would be nice if you could quickly check if that's indeed true. Besides that, looks good. Thanks for fixing, Volker On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph wrote: > Hi, > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. > > There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > Thanks > Christoph > > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Kumar Srinivasan >> Sent: Montag, 12. September 2016 22:57 >> To: core-libs-dev ; Mandy Chung >> ; Chris Bensen >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >> >> Hello, >> >> I am sponsoring this changeset for Chris Bensen of the java packager >> team, please review fix for the launcher to better locate java.home. >> >> http://cr.openjdk.java.net/~ksrini/8165524/ >> >> Thanks >> Kumar > From chris.bensen at oracle.com Fri Sep 16 17:47:41 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Fri, 16 Sep 2016 10:47:41 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: <23CB8480-3742-4120-BEDA-9055155B31EE@oracle.com> I assume libjvm.so has access to dlopen and dlsym? Can the AIX implementation of dladdr live in libjli.so and libjvm.so load it from there? Chris > On Sep 16, 2016, at 10:34 AM, Volker Simonis wrote: > > Hi Christoph, > > I think your change is fine as a quick-fix to fix the build. But > you're completely right that this should be reworked in the long term. > I hate to see that we now have the third version of these routines in > the OpenJDK. Unfortunately a clean solution is not trivial. > > libjli is not linked against libjvm because libjli is actually used to > load libjvm. So we can not put the dladdr routines for AIX there. But > I think we should at least consolidate the two versions which will be > in the class library after your change. Initially I intentionally put > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > available to ALL jdk native libraries. > > Unfortunately, with the source code reorganization due to the modular > changes, the common, top-level aix repository had to go away and the > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > With the reorganized, modularized source code layout and build system > it is not possible to share code between modules. We somehow have to > fix this although I currently don't know how. IF somebody has an idea, > please let me know :) > > Regarding your change: > > - can you please move > > +#if defined(_AIX) > +#include "java_md_aix.h" > +#endif > + > > from java_md_common.c to the end of > java.base/unix/native/libjli/java_md.h. It will then be automatically > included into java_md_common.c trough java.h which includes java_md.h > > Also, this version of dladdr is inherently not thread safe. I don't > think that's a problem here, but it would be nice if you could quickly > check if that's indeed true. > > Besides that, looks good. > > Thanks for fixing, > Volker > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > wrote: >> Hi, >> >> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. >> >> There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >> >> Thanks >> Christoph >> >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >>> Of Kumar Srinivasan >>> Sent: Montag, 12. September 2016 22:57 >>> To: core-libs-dev ; Mandy Chung >>> ; Chris Bensen >>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>> >>> Hello, >>> >>> I am sponsoring this changeset for Chris Bensen of the java packager >>> team, please review fix for the launcher to better locate java.home. >>> >>> http://cr.openjdk.java.net/~ksrini/8165524/ >>> >>> Thanks >>> Kumar >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Sat Sep 17 15:11:04 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 17 Sep 2016 17:11:04 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <23CB8480-3742-4120-BEDA-9055155B31EE@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <23CB8480-3742-4120-BEDA-9055155B31EE@oracle.com> Message-ID: Not sure if that's a good idea. You can have a custom launcher which doesn't use libjli.so and I don't think we want to make libjvm.so dependent on libjli.so. On Fri, Sep 16, 2016 at 7:47 PM, Chris Bensen wrote: > I assume libjvm.so has access to dlopen and dlsym? Can the AIX > implementation of dladdr live in libjli.so and libjvm.so load it from there? > > Chris > > > On Sep 16, 2016, at 10:34 AM, Volker Simonis > wrote: > > Hi Christoph, > > I think your change is fine as a quick-fix to fix the build. But > you're completely right that this should be reworked in the long term. > I hate to see that we now have the third version of these routines in > the OpenJDK. Unfortunately a clean solution is not trivial. > > libjli is not linked against libjvm because libjli is actually used to > load libjvm. So we can not put the dladdr routines for AIX there. But > I think we should at least consolidate the two versions which will be > in the class library after your change. Initially I intentionally put > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > available to ALL jdk native libraries. > > Unfortunately, with the source code reorganization due to the modular > changes, the common, top-level aix repository had to go away and the > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > With the reorganized, modularized source code layout and build system > it is not possible to share code between modules. We somehow have to > fix this although I currently don't know how. IF somebody has an idea, > please let me know :) > > Regarding your change: > > - can you please move > > +#if defined(_AIX) > +#include "java_md_aix.h" > +#endif > + > > from java_md_common.c to the end of > java.base/unix/native/libjli/java_md.h. It will then be automatically > included into java_md_common.c trough java.h which includes java_md.h > > Also, this version of dladdr is inherently not thread safe. I don't > think that's a problem here, but it would be nice if you could quickly > check if that's indeed true. > > Besides that, looks good. > > Thanks for fixing, > Volker > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > wrote: > > Hi, > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX > build as function dladdr is not available on AIX. > > There already exist ports of that API in hotspot and awt. With the proposed > change I duplicate the awt port to libjli. This is maybe only a quick fix - > eventually we should think about consolidating and using the hotspot port in > all places by exporting it from libjvm.so for AIX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > Thanks > Christoph > > > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf > Of Kumar Srinivasan > Sent: Montag, 12. September 2016 22:57 > To: core-libs-dev ; Mandy Chung > ; Chris Bensen > Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using > > Hello, > > I am sponsoring this changeset for Chris Bensen of the java packager > team, please review fix for the launcher to better locate java.home. > > http://cr.openjdk.java.net/~ksrini/8165524/ > > Thanks > Kumar > > > From dmitry.samersoff at oracle.com Sat Sep 17 18:30:40 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 17 Sep 2016 21:30:40 +0300 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: <0b84a890-e6b0-8a85-c87c-7632fab2b6e1@oracle.com> Christoph, java_md_aix.c 32: missed comma after L_GETINFO Should you return an error from fill_dll_info rather than print it to stderr? -Dmitry On 2016-09-16 12:58, Langer, Christoph wrote: > Hi, > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. > > There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > Thanks > Christoph > > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Kumar Srinivasan >> Sent: Montag, 12. September 2016 22:57 >> To: core-libs-dev ; Mandy Chung >> ; Chris Bensen >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >> >> Hello, >> >> I am sponsoring this changeset for Chris Bensen of the java packager >> team, please review fix for the launcher to better locate java.home. >> >> http://cr.openjdk.java.net/~ksrini/8165524/ >> >> Thanks >> Kumar > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From christoph.langer at sap.com Mon Sep 19 08:44:38 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 19 Sep 2016 08:44:38 +0000 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: <117e635e0107427096606bd19906fe8b@DEWDFE13DE11.global.corp.sap> Hi all, thanks for your valuable input. So, since libjli.so can't use libjvm.so and its dladdr() port, there's no way around the libjli.so specific version of it. However, in libjli.so it is only used for resolving pathnames of the program, so the code can be very lean. Hence I completely reduced it to delivering the pathname of a module. And this code is not thread safe, as Volker mentioned. I would think/hope that a launcher would do its resolving work all in one thread and this should not be an issue. Maybe someone of the jli experts can confirm this or object against it. For now I would not spend more efforts in making this multi thread capable. As for the libawt version of dladdr(), this one should be removed and redirected to hotspot. I'll have a look at this when I find time. Please find a new webrev where I have addressed all findings and concerns - corrected spaces and indentation - removed the printf output in favor of handling the return code - only fill the info->dli_fname field - move conditional include to src/java.base/unix/native/libjli/java_md.h http://cr.openjdk.java.net/~clanger/webrevs/8166189.1/ Best regards Christoph > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Freitag, 16. September 2016 19:34 > To: Langer, Christoph > Cc: Kumar Srinivasan ; Mandy Chung > ; Chris Bensen ; > Thomas St?fe ; Lindenmaier, Goetz > ; core-libs-dev dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > Hi Christoph, > > I think your change is fine as a quick-fix to fix the build. But > you're completely right that this should be reworked in the long term. > I hate to see that we now have the third version of these routines in > the OpenJDK. Unfortunately a clean solution is not trivial. > > libjli is not linked against libjvm because libjli is actually used to > load libjvm. So we can not put the dladdr routines for AIX there. But > I think we should at least consolidate the two versions which will be > in the class library after your change. Initially I intentionally put > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > available to ALL jdk native libraries. > > Unfortunately, with the source code reorganization due to the modular > changes, the common, top-level aix repository had to go away and the > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > With the reorganized, modularized source code layout and build system > it is not possible to share code between modules. We somehow have to > fix this although I currently don't know how. IF somebody has an idea, > please let me know :) > > Regarding your change: > > - can you please move > > +#if defined(_AIX) > +#include "java_md_aix.h" > +#endif > + > > from java_md_common.c to the end of > java.base/unix/native/libjli/java_md.h. It will then be automatically > included into java_md_common.c trough java.h which includes java_md.h > > Also, this version of dladdr is inherently not thread safe. I don't > think that's a problem here, but it would be nice if you could quickly > check if that's indeed true. > > Besides that, looks good. > > Thanks for fixing, > Volker > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > wrote: > > Hi, > > > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX > build as function dladdr is not available on AIX. > > > > There already exist ports of that API in hotspot and awt. With the proposed > change I duplicate the awt port to libjli. This is maybe only a quick fix - > eventually we should think about consolidating and using the hotspot port in all > places by exporting it from libjvm.so for AIX. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > > > Thanks > > Christoph > > > > > >> -----Original Message----- > >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf > >> Of Kumar Srinivasan > >> Sent: Montag, 12. September 2016 22:57 > >> To: core-libs-dev ; Mandy Chung > >> ; Chris Bensen > >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using > >> > >> Hello, > >> > >> I am sponsoring this changeset for Chris Bensen of the java packager > >> team, please review fix for the launcher to better locate java.home. > >> > >> http://cr.openjdk.java.net/~ksrini/8165524/ > >> > >> Thanks > >> Kumar > > From goetz.lindenmaier at sap.com Mon Sep 19 09:09:42 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 19 Sep 2016 09:09:42 +0000 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <117e635e0107427096606bd19906fe8b@DEWDFE13DE11.global.corp.sap> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <117e635e0107427096606bd19906fe8b@DEWDFE13DE11.global.corp.sap> Message-ID: <9bcadb4ee1a843528829b9eee07bad97@DEWDFE13DE50.global.corp.sap> Hi Christoph, This looks good now. Please adapt the copyright year in java_md.h. I would appreciate this getting pushed to get our builds going again. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 19. September 2016 10:45 > To: Volker Simonis > Cc: Kumar Srinivasan ; Mandy Chung > ; Chris Bensen ; > Lindenmaier, Goetz ; core-libs-dev dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; Dmitry > Samersoff > Subject: RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > Hi all, > > thanks for your valuable input. > > So, since libjli.so can't use libjvm.so and its dladdr() port, there's no way > around the libjli.so specific version of it. However, in libjli.so it is only used for > resolving pathnames of the program, so the code can be very lean. Hence I > completely reduced it to delivering the pathname of a module. And this code > is not thread safe, as Volker mentioned. I would think/hope that a launcher > would do its resolving work all in one thread and this should not be an issue. > Maybe someone of the jli experts can confirm this or object against it. For > now I would not spend more efforts in making this multi thread capable. > > As for the libawt version of dladdr(), this one should be removed and > redirected to hotspot. I'll have a look at this when I find time. > > Please find a new webrev where I have addressed all findings and concerns > - corrected spaces and indentation > - removed the printf output in favor of handling the return code > - only fill the info->dli_fname field > - move conditional include to src/java.base/unix/native/libjli/java_md.h > > http://cr.openjdk.java.net/~clanger/webrevs/8166189.1/ > > Best regards > Christoph > > > -----Original Message----- > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > Sent: Freitag, 16. September 2016 19:34 > > To: Langer, Christoph > > Cc: Kumar Srinivasan ; Mandy Chung > > ; Chris Bensen ; > > Thomas St?fe ; Lindenmaier, Goetz > > ; core-libs-dev > dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net > > Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > > > Hi Christoph, > > > > I think your change is fine as a quick-fix to fix the build. But > > you're completely right that this should be reworked in the long term. > > I hate to see that we now have the third version of these routines in > > the OpenJDK. Unfortunately a clean solution is not trivial. > > > > libjli is not linked against libjvm because libjli is actually used to > > load libjvm. So we can not put the dladdr routines for AIX there. But > > I think we should at least consolidate the two versions which will be > > in the class library after your change. Initially I intentionally put > > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > > available to ALL jdk native libraries. > > > > Unfortunately, with the source code reorganization due to the modular > > changes, the common, top-level aix repository had to go away and the > > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > > With the reorganized, modularized source code layout and build system > > it is not possible to share code between modules. We somehow have to > > fix this although I currently don't know how. IF somebody has an idea, > > please let me know :) > > > > Regarding your change: > > > > - can you please move > > > > +#if defined(_AIX) > > +#include "java_md_aix.h" > > +#endif > > + > > > > from java_md_common.c to the end of > > java.base/unix/native/libjli/java_md.h. It will then be automatically > > included into java_md_common.c trough java.h which includes java_md.h > > > > Also, this version of dladdr is inherently not thread safe. I don't > > think that's a problem here, but it would be nice if you could quickly > > check if that's indeed true. > > > > Besides that, looks good. > > > > Thanks for fixing, > > Volker > > > > > > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > > wrote: > > > Hi, > > > > > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks > the AIX > > build as function dladdr is not available on AIX. > > > > > > There already exist ports of that API in hotspot and awt. With the > proposed > > change I duplicate the awt port to libjli. This is maybe only a quick fix - > > eventually we should think about consolidating and using the hotspot port > in all > > places by exporting it from libjvm.so for AIX. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > > > > > Thanks > > > Christoph > > > > > > > > >> -----Original Message----- > > >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] > On > > Behalf > > >> Of Kumar Srinivasan > > >> Sent: Montag, 12. September 2016 22:57 > > >> To: core-libs-dev ; Mandy Chung > > >> ; Chris Bensen > > > >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using > > >> > > >> Hello, > > >> > > >> I am sponsoring this changeset for Chris Bensen of the java packager > > >> team, please review fix for the launcher to better locate java.home. > > >> > > >> http://cr.openjdk.java.net/~ksrini/8165524/ > > >> > > >> Thanks > > >> Kumar > > > From christoph.langer at sap.com Tue Sep 20 06:53:37 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 20 Sep 2016 06:53:37 +0000 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <9bcadb4ee1a843528829b9eee07bad97@DEWDFE13DE50.global.corp.sap> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <117e635e0107427096606bd19906fe8b@DEWDFE13DE11.global.corp.sap> <9bcadb4ee1a843528829b9eee07bad97@DEWDFE13DE50.global.corp.sap> Message-ID: Hi all, hearing no objections and having the final ok from Goetz, I pushed the fix: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c709e74ffcf6 Best regards Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 19. September 2016 11:10 > To: Langer, Christoph ; Volker Simonis > > Cc: Kumar Srinivasan ; Mandy Chung > ; Chris Bensen ; core- > libs-dev ; ppc-aix-port-dev at openjdk.java.net; > Dmitry Samersoff > Subject: RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > Hi Christoph, > > This looks good now. Please adapt the copyright year in java_md.h. > I would appreciate this getting pushed to get our builds going again. > > Best regards, > Goetz. > > > > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Montag, 19. September 2016 10:45 > > To: Volker Simonis > > Cc: Kumar Srinivasan ; Mandy Chung > > ; Chris Bensen ; > > Lindenmaier, Goetz ; core-libs-dev > dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; Dmitry > > Samersoff > > Subject: RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > > > Hi all, > > > > thanks for your valuable input. > > > > So, since libjli.so can't use libjvm.so and its dladdr() port, there's no way > > around the libjli.so specific version of it. However, in libjli.so it is only used for > > resolving pathnames of the program, so the code can be very lean. Hence I > > completely reduced it to delivering the pathname of a module. And this code > > is not thread safe, as Volker mentioned. I would think/hope that a launcher > > would do its resolving work all in one thread and this should not be an issue. > > Maybe someone of the jli experts can confirm this or object against it. For > > now I would not spend more efforts in making this multi thread capable. > > > > As for the libawt version of dladdr(), this one should be removed and > > redirected to hotspot. I'll have a look at this when I find time. > > > > Please find a new webrev where I have addressed all findings and concerns > > - corrected spaces and indentation > > - removed the printf output in favor of handling the return code > > - only fill the info->dli_fname field > > - move conditional include to src/java.base/unix/native/libjli/java_md.h > > > > http://cr.openjdk.java.net/~clanger/webrevs/8166189.1/ > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > > Sent: Freitag, 16. September 2016 19:34 > > > To: Langer, Christoph > > > Cc: Kumar Srinivasan ; Mandy Chung > > > ; Chris Bensen ; > > > Thomas St?fe ; Lindenmaier, Goetz > > > ; core-libs-dev > > dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net > > > Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > > > > > Hi Christoph, > > > > > > I think your change is fine as a quick-fix to fix the build. But > > > you're completely right that this should be reworked in the long term. > > > I hate to see that we now have the third version of these routines in > > > the OpenJDK. Unfortunately a clean solution is not trivial. > > > > > > libjli is not linked against libjvm because libjli is actually used to > > > load libjvm. So we can not put the dladdr routines for AIX there. But > > > I think we should at least consolidate the two versions which will be > > > in the class library after your change. Initially I intentionally put > > > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > > > available to ALL jdk native libraries. > > > > > > Unfortunately, with the source code reorganization due to the modular > > > changes, the common, top-level aix repository had to go away and the > > > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > > > With the reorganized, modularized source code layout and build system > > > it is not possible to share code between modules. We somehow have to > > > fix this although I currently don't know how. IF somebody has an idea, > > > please let me know :) > > > > > > Regarding your change: > > > > > > - can you please move > > > > > > +#if defined(_AIX) > > > +#include "java_md_aix.h" > > > +#endif > > > + > > > > > > from java_md_common.c to the end of > > > java.base/unix/native/libjli/java_md.h. It will then be automatically > > > included into java_md_common.c trough java.h which includes java_md.h > > > > > > Also, this version of dladdr is inherently not thread safe. I don't > > > think that's a problem here, but it would be nice if you could quickly > > > check if that's indeed true. > > > > > > Besides that, looks good. > > > > > > Thanks for fixing, > > > Volker > > > > > > > > > > > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > > > wrote: > > > > Hi, > > > > > > > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks > > the AIX > > > build as function dladdr is not available on AIX. > > > > > > > > There already exist ports of that API in hotspot and awt. With the > > proposed > > > change I duplicate the awt port to libjli. This is maybe only a quick fix - > > > eventually we should think about consolidating and using the hotspot port > > in all > > > places by exporting it from libjvm.so for AIX. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > > > > > > > Thanks > > > > Christoph > > > > > > > > > > > >> -----Original Message----- > > > >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] > > On > > > Behalf > > > >> Of Kumar Srinivasan > > > >> Sent: Montag, 12. September 2016 22:57 > > > >> To: core-libs-dev ; Mandy Chung > > > >> ; Chris Bensen > > > > > >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using > > > >> > > > >> Hello, > > > >> > > > >> I am sponsoring this changeset for Chris Bensen of the java packager > > > >> team, please review fix for the launcher to better locate java.home. > > > >> > > > >> http://cr.openjdk.java.net/~ksrini/8165524/ > > > >> > > > >> Thanks > > > >> Kumar > > > > From kumar.x.srinivasan at oracle.com Wed Sep 21 13:38:05 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 21 Sep 2016 06:38:05 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: <57E28D3D.5040802@oracle.com> On 9/16/2016 10:34 AM, Volker Simonis wrote: > Hi Christoph, > > I think your change is fine as a quick-fix to fix the build. But > you're completely right that this should be reworked in the long term. > I hate to see that we now have the third version of these routines in > the OpenJDK. Unfortunately a clean solution is not trivial. > > libjli is not linked against libjvm because libjli is actually used to > load libjvm. So we can not put the dladdr routines for AIX there. But > I think we should at least consolidate the two versions which will be > in the class library after your change. Initially I intentionally put > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > available to ALL jdk native libraries. > > Unfortunately, with the source code reorganization due to the modular > changes, the common, top-level aix repository had to go away and the > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > With the reorganized, modularized source code layout and build system > it is not possible to share code between modules. We somehow have to > fix this although I currently don't know how. IF somebody has an idea, > please let me know :) Why doesn't AIX support a Standard C API that most other *nix based OS'es support ? Thanks Kumar > > Regarding your change: > > - can you please move > > +#if defined(_AIX) > +#include "java_md_aix.h" > +#endif > + > > from java_md_common.c to the end of > java.base/unix/native/libjli/java_md.h. It will then be automatically > included into java_md_common.c trough java.h which includes java_md.h > > Also, this version of dladdr is inherently not thread safe. I don't > think that's a problem here, but it would be nice if you could quickly > check if that's indeed true. > > Besides that, looks good. > > Thanks for fixing, > Volker > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > wrote: >> Hi, >> >> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. >> >> There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >> >> Thanks >> Christoph >> >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >>> Of Kumar Srinivasan >>> Sent: Montag, 12. September 2016 22:57 >>> To: core-libs-dev ; Mandy Chung >>> ; Chris Bensen >>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>> >>> Hello, >>> >>> I am sponsoring this changeset for Chris Bensen of the java packager >>> team, please review fix for the launcher to better locate java.home. >>> >>> http://cr.openjdk.java.net/~ksrini/8165524/ >>> >>> Thanks >>> Kumar From chris.bensen at oracle.com Wed Sep 21 17:10:48 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 21 Sep 2016 10:10:48 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <57E28D3D.5040802@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> Message-ID: > On Sep 21, 2016, at 6:38 AM, Kumar Srinivasan wrote: > > > On 9/16/2016 10:34 AM, Volker Simonis wrote: >> Hi Christoph, >> >> I think your change is fine as a quick-fix to fix the build. But >> you're completely right that this should be reworked in the long term. >> I hate to see that we now have the third version of these routines in >> the OpenJDK. Unfortunately a clean solution is not trivial. >> >> libjli is not linked against libjvm because libjli is actually used to >> load libjvm. So we can not put the dladdr routines for AIX there. But >> I think we should at least consolidate the two versions which will be >> in the class library after your change. Initially I intentionally put >> porting_aix.{c,h} into jdk/aix/porting with the intent to make it >> available to ALL jdk native libraries. >> >> Unfortunately, with the source code reorganization due to the modular >> changes, the common, top-level aix repository had to go away and the >> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. >> With the reorganized, modularized source code layout and build system >> it is not possible to share code between modules. We somehow have to >> fix this although I currently don't know how. IF somebody has an idea, >> please let me know :) > > Why doesn't AIX support a Standard C API that most other > *nix based OS'es support ? I was wondering the same thing. Chris > > Thanks > > Kumar > >> >> Regarding your change: >> >> - can you please move >> >> +#if defined(_AIX) >> +#include "java_md_aix.h" >> +#endif >> + >> >> from java_md_common.c to the end of >> java.base/unix/native/libjli/java_md.h. It will then be automatically >> included into java_md_common.c trough java.h which includes java_md.h >> >> Also, this version of dladdr is inherently not thread safe. I don't >> think that's a problem here, but it would be nice if you could quickly >> check if that's indeed true. >> >> Besides that, looks good. >> >> Thanks for fixing, >> Volker >> >> >> >> >> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph >> wrote: >>> Hi, >>> >>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. >>> >>> There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >>> >>> Thanks >>> Christoph >>> >>> >>>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >>>> Of Kumar Srinivasan >>>> Sent: Montag, 12. September 2016 22:57 >>>> To: core-libs-dev ; Mandy Chung >>>> ; Chris Bensen >>>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>>> >>>> Hello, >>>> >>>> I am sponsoring this changeset for Chris Bensen of the java packager >>>> team, please review fix for the launcher to better locate java.home. >>>> >>>> http://cr.openjdk.java.net/~ksrini/8165524/ >>>> >>>> Thanks >>>> Kumar > From thomas.stuefe at gmail.com Thu Sep 22 07:05:00 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Sep 2016 09:05:00 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <57E28D3D.5040802@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> Message-ID: Hi Kumar, > On 9/16/2016 10:34 AM, Volker Simonis wrote: > >> Hi Christoph, >> >> I think your change is fine as a quick-fix to fix the build. But >> you're completely right that this should be reworked in the long term. >> I hate to see that we now have the third version of these routines in >> the OpenJDK. Unfortunately a clean solution is not trivial. >> >> libjli is not linked against libjvm because libjli is actually used to >> load libjvm. So we can not put the dladdr routines for AIX there. But >> I think we should at least consolidate the two versions which will be >> in the class library after your change. Initially I intentionally put >> porting_aix.{c,h} into jdk/aix/porting with the intent to make it >> available to ALL jdk native libraries. >> >> Unfortunately, with the source code reorganization due to the modular >> changes, the common, top-level aix repository had to go away and the >> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. >> With the reorganized, modularized source code layout and build system >> it is not possible to share code between modules. We somehow have to >> fix this although I currently don't know how. IF somebody has an idea, >> please let me know :) >> > > Why doesn't AIX support a Standard C API that most other > *nix based OS'es support ? > > dladdr() is not Posix, hence it should not be used in code that wants to be portable across Unix systems. Afaik dladdr() is a propietary Solaris API that was adapted by the glibc and slowly spread over to some other Unices, but by no means all of them. dladdr makes a number of assumptions about the architecture: e.g. that a C function pointer points into the text segment of the binary instead of e.g. a PLT, or that a loaded binary is placed continuously in memory (we only have one dli_fbase in DL_info). So imho it makes sense to not make this a standard Posix API. We (SAP) implemented dladdr atop of loadquery(), and this kind of works, although we had to add some hacks to handle both real code addresses and C function pointers. So the code is there, it is "just" a question of where to place it. Kind Regards, Thomas Thanks > > Kumar > > > >> Regarding your change: >> >> - can you please move >> >> +#if defined(_AIX) >> +#include "java_md_aix.h" >> +#endif >> + >> >> from java_md_common.c to the end of >> java.base/unix/native/libjli/java_md.h. It will then be automatically >> included into java_md_common.c trough java.h which includes java_md.h >> >> Also, this version of dladdr is inherently not thread safe. I don't >> think that's a problem here, but it would be nice if you could quickly >> check if that's indeed true. >> >> Besides that, looks good. >> >> Thanks for fixing, >> Volker >> >> >> >> >> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph >> wrote: >> >>> Hi, >>> >>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the >>> AIX build as function dladdr is not available on AIX. >>> >>> There already exist ports of that API in hotspot and awt. With the >>> proposed change I duplicate the awt port to libjli. This is maybe only a >>> quick fix - eventually we should think about consolidating and using the >>> hotspot port in all places by exporting it from libjvm.so for AIX. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >>> >>> Thanks >>> Christoph >>> >>> >>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >>>> Behalf >>>> Of Kumar Srinivasan >>>> Sent: Montag, 12. September 2016 22:57 >>>> To: core-libs-dev ; Mandy Chung >>>> ; Chris Bensen >>>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>>> >>>> Hello, >>>> >>>> I am sponsoring this changeset for Chris Bensen of the java packager >>>> team, please review fix for the launcher to better locate java.home. >>>> >>>> http://cr.openjdk.java.net/~ksrini/8165524/ >>>> >>>> Thanks >>>> Kumar >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From HORIE at jp.ibm.com Mon Sep 26 07:37:24 2016 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Mon, 26 Sep 2016 16:37:24 +0900 Subject: RFR:8166684:implement intrinsic code with vector instructions for Unsafe.copyMemory() Message-ID: Dear all, Could I please request reviews for the following change? This change was created for JDK9. I added fixes to the intrinsic code for sun.misc.Unsafe.copyMemory() by using VSX. Since Spark often invokes Unsafe.copyMemory(), it is beneficial to use the vector instructions for these intrinsic code. jira: https://bugs.openjdk.java.net/browse/JDK-8166684 diff: (See attached file: unsafe-copymemory-openjdk9.diff) Best regards, -- Michihiro Horie, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unsafe-copymemory-openjdk9.diff Type: application/octet-stream Size: 2714 bytes Desc: not available URL: From martin.doerr at sap.com Mon Sep 26 09:53:02 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 26 Sep 2016 09:53:02 +0000 Subject: RFR:8166684:implement intrinsic code with vector instructions for Unsafe.copyMemory() In-Reply-To: References: Message-ID: <4c013cabdeeb476f97c427643aef7a1b@DEWDFE13DE14.global.corp.sap> Hi Michihiro, the initialization of tmp1 should be done outside of the loop. Beside that, the change looks good: http://cr.openjdk.java.net/~mdoerr/8166684_PPC64_unsafe_copymemory/webrev.00/ Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Montag, 26. September 2016 09:37 To: Doerr, Martin ; Simonis, Volker ; ppc-aix-port-dev at openjdk.java.net Cc: volker.simonis at gmail.com; Gustavo Romero ; Hiroshi H Horii Subject: RFR:8166684:implement intrinsic code with vector instructions for Unsafe.copyMemory() Dear all, Could I please request reviews for the following change? This change was created for JDK9. I added fixes to the intrinsic code for sun.misc.Unsafe.copyMemory() by using VSX. Since Spark often invokes Unsafe.copyMemory(), it is beneficial to use the vector instructions for these intrinsic code. jira: https://bugs.openjdk.java.net/browse/JDK-8166684 diff: (See attached file: unsafe-copymemory-openjdk9.diff) Best regards, -- Michihiro Horie, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Mon Sep 26 13:50:13 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 26 Sep 2016 13:50:13 +0000 Subject: RFR:8166684:implement intrinsic code with vector instructions for Unsafe.copyMemory() In-Reply-To: <4c013cabdeeb476f97c427643aef7a1b@DEWDFE13DE14.global.corp.sap> References: <4c013cabdeeb476f97c427643aef7a1b@DEWDFE13DE14.global.corp.sap> Message-ID: Hi, please post this RFR also to hotspot-compiler-dev. It must be reviewed on one of the official lists before it can be pushed. Ppc-aix-port-dev is only for communication about the port, not for reviews. Also I would appreciate if you could upload your webrevs yourselves. We are happy to help out in the beginning, and also with testing, reviewing and pushing, but making webrevs is a task I don't see on our side in the long term. Thanks and best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Montag, 26. September 2016 11:53 > To: Michihiro Horie ; Simonis, Volker > ; ppc-aix-port-dev at openjdk.java.net > Cc: Hiroshi H Horii ; Gustavo Romero > > Subject: RE: RFR:8166684:implement intrinsic code with vector instructions > for Unsafe.copyMemory() > > Hi Michihiro, > > > > the initialization of tmp1 should be done outside of the loop. Beside that, the > change looks good: > > http://cr.openjdk.java.net/~mdoerr/8166684_PPC64_unsafe_copymemory/ > webrev.00/ > /webrev.00/> > > > > Best regards, > > Martin > > > > > > From: Michihiro Horie [mailto:HORIE at jp.ibm.com] > Sent: Montag, 26. September 2016 09:37 > To: Doerr, Martin ; Simonis, Volker > ; ppc-aix-port-dev at openjdk.java.net > Cc: volker.simonis at gmail.com; Gustavo Romero > ; Hiroshi H Horii > Subject: RFR:8166684:implement intrinsic code with vector instructions for > Unsafe.copyMemory() > > > > Dear all, > > Could I please request reviews for the following change? > This change was created for JDK9. > > I added fixes to the intrinsic code for sun.misc.Unsafe.copyMemory() by > using VSX. > Since Spark often invokes Unsafe.copyMemory(), it is beneficial to use the > vector instructions for these intrinsic code. > > jira: https://bugs.openjdk.java.net/browse/JDK-8166684 > > diff: (See attached file: unsafe-copymemory-openjdk9.diff) > > Best regards, > -- > Michihiro Horie, > IBM Research - Tokyo From volker.simonis at gmail.com Mon Sep 26 15:00:20 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 26 Sep 2016 17:00:20 +0200 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: References: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> <962ae958-5897-6e9b-eec3-33680358ad0b@oracle.com> Message-ID: Hi, I've been a little busy with JavaOne but now I've finally pushed this change. Thanks to everybody, Volker On Thu, Sep 15, 2016 at 8:08 AM, Hiroshi H Horii wrote: > Hi Volker, and Sean, > > Thank you for your comments and suggestion. > > I and Gustavo created a webrev that includes Bits and ByteArrayAccess. > > http://cr.openjdk.java.net/~gromero/8165231/02/ > > I believe there is no other similar methods in jdk. > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > > > > From: Sean Coffey > To: Volker Simonis > Cc: "jdk8u-dev at openjdk.java.net" , Java > Core Libs , Hiroshi H Horii/Japan/IBM at IBMJP, > "ppc-aix-port-dev at openjdk.java.net" , > Gustavo Bueno Romero , "Doerr, Martin" > > Date: 09/13/2016 21:46 > Subject: Re: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() > doesn't return true on ppc > ________________________________ > > > > Sounds good Volker. Good catch. > > regards, > Sean. > > On 13/09/2016 13:09, Volker Simonis wrote: >> Hi Sean, >> >> thanks a lot for the fast response. I've updated the bug entry as >> requested and will push the change - maybe with the following >> potential improvement: >> >> @Hiroshi: also maybe not that performance relevant, I think we should >> we also fix sun/security/provider/ByteArrayAccess.java which contains >> the same construct: >> >> // Return whether this platform supports full speed int/long memory >> access >> // at unaligned addresses. >> // This code was copied from java.nio.Bits because there is no >> equivalent >> // public API. >> private static boolean unaligned() { >> String arch = java.security.AccessController.doPrivileged >> (new sun.security.action.GetPropertyAction("os.arch", "")); >> return arch.equals("i386") || arch.equals("x86") || >> arch.equals("amd64") >> || arch.equals("x86_64"); >> } >> >> Regards, >> Volker > > > > From kumar.x.srinivasan at oracle.com Wed Sep 28 13:03:22 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 28 Sep 2016 06:03:22 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> Message-ID: <57EBBF9A.6010103@oracle.com> Hello Thomas, Volker, > > Hi Kumar, > > > On 9/16/2016 10:34 AM, Volker Simonis wrote: > > Hi Christoph, > > I think your change is fine as a quick-fix to fix the build. But > you're completely right that this should be reworked in the > long term. > I hate to see that we now have the third version of these > routines in > the OpenJDK. Unfortunately a clean solution is not trivial. > > libjli is not linked against libjvm because libjli is actually > used to > load libjvm. So we can not put the dladdr routines for AIX > there. But > I think we should at least consolidate the two versions which > will be > in the class library after your change. Initially I > intentionally put > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > available to ALL jdk native libraries. > > Unfortunately, with the source code reorganization due to the > modular > changes, the common, top-level aix repository had to go away > and the > code was moved to > src/java.desktop/aix/native/libawt/porting_aix.c. > With the reorganized, modularized source code layout and build > system > it is not possible to share code between modules. We somehow > have to > fix this although I currently don't know how. IF somebody has > an idea, > please let me know :) > > > Why doesn't AIX support a Standard C API that most other > *nix based OS'es support ? > > > dladdr() is not Posix, hence it should not be used in code that wants > to be portable across Unix systems. Afaik dladdr() is a propietary > Solaris API that was adapted by the glibc and slowly spread over to > some other Unices, but by no means all of them. > dladdr makes a number of assumptions about the architecture: e.g. that > a C function pointer points into the text segment of the binary > instead of e.g. a PLT, or that a loaded binary is placed continuously > in memory (we only have one dli_fbase in DL_info). So imho it makes > sense to not make this a standard Posix API. > > We (SAP) implemented dladdr atop of loadquery(), and this kind of > works, although we had to add some hacks to handle both real code > addresses and C function pointers. So the code is there, it is "just" > a question of where to place it. I understand your desire to keep AIX pristine and clean, similarly, we should also keep OpenJDK sources clean, having 3 identical dladdr implementation, spread across the OpenJDK does not bode well. So, is it possible to park the sources in hotspot repo, and create a shared shared object, that can be suitably linked to the launchers, awt and hotspot to this library/object ? Thanks Kumar > Kind Regards, Thomas > > Thanks > > Kumar > > > > Regarding your change: > > - can you please move > > +#if defined(_AIX) > +#include "java_md_aix.h" > +#endif > + > > from java_md_common.c to the end of > java.base/unix/native/libjli/java_md.h. It will then be > automatically > included into java_md_common.c trough java.h which includes > java_md.h > > Also, this version of dladdr is inherently not thread safe. I > don't > think that's a problem here, but it would be nice if you could > quickly > check if that's indeed true. > > Besides that, looks good. > > Thanks for fixing, > Volker > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > > > wrote: > > Hi, > > the fix for > https://bugs.openjdk.java.net/browse/JDK-8165524 > breaks > the AIX build as function dladdr is not available on AIX. > > There already exist ports of that API in hotspot and awt. > With the proposed change I duplicate the awt port to > libjli. This is maybe only a quick fix - eventually we > should think about consolidating and using the hotspot > port in all places by exporting it from libjvm.so for AIX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > > Webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > > Thanks > Christoph > > > -----Original Message----- > From: core-libs-dev > [mailto:core-libs-dev-bounces at openjdk.java.net > ] On Behalf > Of Kumar Srinivasan > Sent: Montag, 12. September 2016 22:57 > To: core-libs-dev >; Mandy Chung > >; Chris Bensen > > > Subject: RFR: 8165524: Better detect JRE that Linux > JLI will be using > > Hello, > > I am sponsoring this changeset for Chris Bensen of the > java packager > team, please review fix for the launcher to better > locate java.home. > > http://cr.openjdk.java.net/~ksrini/8165524/ > > > Thanks > Kumar > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Sep 28 16:33:05 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 28 Sep 2016 18:33:05 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <57EBBF9A.6010103@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: On Wed, Sep 28, 2016 at 3:03 PM, Kumar Srinivasan wrote: > > Hello Thomas, Volker, > > > Hi Kumar, > >> >> On 9/16/2016 10:34 AM, Volker Simonis wrote: >>> >>> Hi Christoph, >>> >>> I think your change is fine as a quick-fix to fix the build. But >>> you're completely right that this should be reworked in the long term. >>> I hate to see that we now have the third version of these routines in >>> the OpenJDK. Unfortunately a clean solution is not trivial. >>> >>> libjli is not linked against libjvm because libjli is actually used to >>> load libjvm. So we can not put the dladdr routines for AIX there. But >>> I think we should at least consolidate the two versions which will be >>> in the class library after your change. Initially I intentionally put >>> porting_aix.{c,h} into jdk/aix/porting with the intent to make it >>> available to ALL jdk native libraries. >>> >>> Unfortunately, with the source code reorganization due to the modular >>> changes, the common, top-level aix repository had to go away and the >>> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. >>> With the reorganized, modularized source code layout and build system >>> it is not possible to share code between modules. We somehow have to >>> fix this although I currently don't know how. IF somebody has an idea, >>> please let me know :) >> >> >> Why doesn't AIX support a Standard C API that most other >> *nix based OS'es support ? >> > > dladdr() is not Posix, hence it should not be used in code that wants to be > portable across Unix systems. Afaik dladdr() is a propietary Solaris API > that was adapted by the glibc and slowly spread over to some other Unices, > but by no means all of them. > > dladdr makes a number of assumptions about the architecture: e.g. that a C > function pointer points into the text segment of the binary instead of e.g. > a PLT, or that a loaded binary is placed continuously in memory (we only > have one dli_fbase in DL_info). So imho it makes sense to not make this a > standard Posix API. > > We (SAP) implemented dladdr atop of loadquery(), and this kind of works, > although we had to add some hacks to handle both real code addresses and C > function pointers. So the code is there, it is "just" a question of where to > place it. > > > I understand your desire to keep AIX pristine and clean, similarly, > we should also keep OpenJDK sources clean, having 3 identical > dladdr implementation, spread across the OpenJDK does not > bode well. > > So, is it possible to park the sources in hotspot repo, and create a > shared shared object, that can be suitably linked to the launchers, > awt and hotspot to this library/object ? I don't think this can be easily done with the current build system. Remember for example that even such a sensitive part like jni.h is still duplicated between the hotspot and the jdk repository: hotspot/src/share/vm/prims/jni.h jdk/src/java.base/share/native/include/jni.h So before we envision a solution for the various dladdr implementations for AIX we should really come up with a general way to share code between hotspot and jdk. I've cc'ed build-dev because I think this is to a big part a build/infrastructure issue. If somebody has a good idea, please let me know :) Regards, Volker > > Thanks > Kumar > > > > > Kind Regards, Thomas > >> Thanks >> >> Kumar >> >> >>> >>> Regarding your change: >>> >>> - can you please move >>> >>> +#if defined(_AIX) >>> +#include "java_md_aix.h" >>> +#endif >>> + >>> >>> from java_md_common.c to the end of >>> java.base/unix/native/libjli/java_md.h. It will then be automatically >>> included into java_md_common.c trough java.h which includes java_md.h >>> >>> Also, this version of dladdr is inherently not thread safe. I don't >>> think that's a problem here, but it would be nice if you could quickly >>> check if that's indeed true. >>> >>> Besides that, looks good. >>> >>> Thanks for fixing, >>> Volker >>> >>> >>> >>> >>> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph >>> wrote: >>>> >>>> Hi, >>>> >>>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the >>>> AIX build as function dladdr is not available on AIX. >>>> >>>> There already exist ports of that API in hotspot and awt. With the >>>> proposed change I duplicate the awt port to libjli. This is maybe only a >>>> quick fix - eventually we should think about consolidating and using the >>>> hotspot port in all places by exporting it from libjvm.so for AIX. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >>>> >>>> Thanks >>>> Christoph >>>> >>>> >>>>> -----Original Message----- >>>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >>>>> Behalf >>>>> Of Kumar Srinivasan >>>>> Sent: Montag, 12. September 2016 22:57 >>>>> To: core-libs-dev ; Mandy Chung >>>>> ; Chris Bensen >>>>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>>>> >>>>> Hello, >>>>> >>>>> I am sponsoring this changeset for Chris Bensen of the java packager >>>>> team, please review fix for the launcher to better locate java.home. >>>>> >>>>> http://cr.openjdk.java.net/~ksrini/8165524/ >>>>> >>>>> Thanks >>>>> Kumar >> >> > > From kumar.x.srinivasan at oracle.com Wed Sep 28 17:13:51 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 28 Sep 2016 10:13:51 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <57EBBF9A.6010103@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: <57EBFA4F.9010401@oracle.com> One thing I missed to mention, the fix for 8165524 is primarily to assist the packager tool, which deploys client side/JavaFX based applications. If this tool is not relevant and does not exist on AIX. Then at a minimum the dladdr call can either be dynamically located/invoked using dlsym, or simply have the AIX version of dladdr return JNI_FALSE always, only for the launcher of course. Thanks Kumar > > Hello Thomas, Volker, > >> >> Hi Kumar, >> >> >> On 9/16/2016 10:34 AM, Volker Simonis wrote: >> >> Hi Christoph, >> >> I think your change is fine as a quick-fix to fix the build. But >> you're completely right that this should be reworked in the >> long term. >> I hate to see that we now have the third version of these >> routines in >> the OpenJDK. Unfortunately a clean solution is not trivial. >> >> libjli is not linked against libjvm because libjli is actually >> used to >> load libjvm. So we can not put the dladdr routines for AIX >> there. But >> I think we should at least consolidate the two versions which >> will be >> in the class library after your change. Initially I >> intentionally put >> porting_aix.{c,h} into jdk/aix/porting with the intent to >> make it >> available to ALL jdk native libraries. >> >> Unfortunately, with the source code reorganization due to the >> modular >> changes, the common, top-level aix repository had to go away >> and the >> code was moved to >> src/java.desktop/aix/native/libawt/porting_aix.c. >> With the reorganized, modularized source code layout and build >> system >> it is not possible to share code between modules. We somehow >> have to >> fix this although I currently don't know how. IF somebody has >> an idea, >> please let me know :) >> >> >> Why doesn't AIX support a Standard C API that most other >> *nix based OS'es support ? >> >> >> dladdr() is not Posix, hence it should not be used in code that wants >> to be portable across Unix systems. Afaik dladdr() is a propietary >> Solaris API that was adapted by the glibc and slowly spread over to >> some other Unices, but by no means all of them. >> dladdr makes a number of assumptions about the architecture: e.g. >> that a C function pointer points into the text segment of the binary >> instead of e.g. a PLT, or that a loaded binary is placed continuously >> in memory (we only have one dli_fbase in DL_info). So imho it makes >> sense to not make this a standard Posix API. >> >> We (SAP) implemented dladdr atop of loadquery(), and this kind of >> works, although we had to add some hacks to handle both real code >> addresses and C function pointers. So the code is there, it is "just" >> a question of where to place it. > > I understand your desire to keep AIX pristine and clean, similarly, > we should also keep OpenJDK sources clean, having 3 identical > dladdr implementation, spread across the OpenJDK does not > bode well. > > So, is it possible to park the sources in hotspot repo, and create a > shared shared object, that can be suitably linked to the launchers, > awt and hotspot to this library/object ? > > Thanks > Kumar > > > >> Kind Regards, Thomas >> >> Thanks >> >> Kumar >> >> >> >> Regarding your change: >> >> - can you please move >> >> +#if defined(_AIX) >> +#include "java_md_aix.h" >> +#endif >> + >> >> from java_md_common.c to the end of >> java.base/unix/native/libjli/java_md.h. It will then be >> automatically >> included into java_md_common.c trough java.h which includes >> java_md.h >> >> Also, this version of dladdr is inherently not thread safe. I >> don't >> think that's a problem here, but it would be nice if you could >> quickly >> check if that's indeed true. >> >> Besides that, looks good. >> >> Thanks for fixing, >> Volker >> >> >> >> >> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph >> > >> wrote: >> >> Hi, >> >> the fix for >> https://bugs.openjdk.java.net/browse/JDK-8165524 >> breaks >> the AIX build as function dladdr is not available on AIX. >> >> There already exist ports of that API in hotspot and awt. >> With the proposed change I duplicate the awt port to >> libjli. This is maybe only a quick fix - eventually we >> should think about consolidating and using the hotspot >> port in all places by exporting it from libjvm.so for AIX. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >> >> Webrev: >> http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >> >> >> Thanks >> Christoph >> >> >> -----Original Message----- >> From: core-libs-dev >> [mailto:core-libs-dev-bounces at openjdk.java.net >> ] On Behalf >> Of Kumar Srinivasan >> Sent: Montag, 12. September 2016 22:57 >> To: core-libs-dev > >; Mandy Chung >> > >; Chris Bensen >> > > >> Subject: RFR: 8165524: Better detect JRE that Linux >> JLI will be using >> >> Hello, >> >> I am sponsoring this changeset for Chris Bensen of the >> java packager >> team, please review fix for the launcher to better >> locate java.home. >> >> http://cr.openjdk.java.net/~ksrini/8165524/ >> >> >> Thanks >> Kumar >> >> >> > From thomas.stuefe at gmail.com Wed Sep 28 18:50:24 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 28 Sep 2016 20:50:24 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz wrote: > On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis > wrote: > > > > > I don't think this can be easily done with the current build system. > > Remember for example that even such a sensitive part like jni.h is > > still duplicated between the hotspot and the jdk repository: > > > > hotspot/src/share/vm/prims/jni.h > > jdk/src/java.base/share/native/include/jni.h > > > > It's one of the frustrating aspects of openjdk development that it's hard > to share C level infrastructure among different components. Components > sometimes grow their own local C infrastructure, but when another component > has the same problem, one often resorts to copy-paste as the most expedient > way to get code reuse. In part, the mercurial repo organization reinforces > this - there is one top-level repo with fan-out, but there is nothing at > the bottom with fan-in. > At SAP, we often solve this by moving code to the hotspot and exporting it from there, the hotspot being the central part which (almost) has to be loaded from the very beginning. I think we did this for dladdr() too. But that is an ugly hack too, because it bloats the hotspot and forces us to add -ljvm to a lot of makefiles or to resolve those functions dynamically. Another solution for us on AIX could be to put this stuff into an own library and provide it independently from the OpenJDK build system, just declare it to be a build dependency, similar to Apples JavaRuntimeServices. As we need dladdr() in both hotspot and JDK, maybe that would be the best option. > One code sharing mechanism that does get used is seen in > ClassLoader::load_zip_library() > where code from the jdk repo is packaged into a shared object and invoked > from hotspot, dynamically. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.bensen at oracle.com Wed Sep 28 18:54:17 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 28 Sep 2016 11:54:17 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> > On Sep 28, 2016, at 11:50 AM, Thomas St?fe wrote: > > > > On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz > wrote: > On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis > > wrote: > > > > > I don't think this can be easily done with the current build system. > > Remember for example that even such a sensitive part like jni.h is > > still duplicated between the hotspot and the jdk repository: > > > > hotspot/src/share/vm/prims/jni.h > > jdk/src/java.base/share/native/include/jni.h > > > > It's one of the frustrating aspects of openjdk development that it's hard > to share C level infrastructure among different components. Components > sometimes grow their own local C infrastructure, but when another component > has the same problem, one often resorts to copy-paste as the most expedient > way to get code reuse. In part, the mercurial repo organization reinforces > this - there is one top-level repo with fan-out, but there is nothing at > the bottom with fan-in. > > At SAP, we often solve this by moving code to the hotspot and exporting it from there, the hotspot being the central part which (almost) has to be loaded from the very beginning. I think we did this for dladdr() too. > > But that is an ugly hack too, because it bloats the hotspot and forces us to add -ljvm to a lot of makefiles or to resolve those functions dynamically. > > Another solution for us on AIX could be to put this stuff into an own library and provide it independently from the OpenJDK build system, just declare it to be a build dependency, similar to Apples JavaRuntimeServices. > > As we need dladdr() in both hotspot and JDK, maybe that would be the best option. That sounds like a reasonable solution to me. Chris > > > > One code sharing mechanism that does get used is seen in > ClassLoader::load_zip_library() > where code from the jdk repo is packaged into a shared object and invoked > from hotspot, dynamically. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Sep 28 18:56:05 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 28 Sep 2016 20:56:05 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <57EBBF9A.6010103@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: Hi Kumar, On Wed, Sep 28, 2016 at 3:03 PM, Kumar Srinivasan < kumar.x.srinivasan at oracle.com> wrote: > > Hello Thomas, Volker, > > > Hi Kumar, > > >> On 9/16/2016 10:34 AM, Volker Simonis wrote: >> >>> Hi Christoph, >>> >>> I think your change is fine as a quick-fix to fix the build. But >>> you're completely right that this should be reworked in the long term. >>> I hate to see that we now have the third version of these routines in >>> the OpenJDK. Unfortunately a clean solution is not trivial. >>> >>> libjli is not linked against libjvm because libjli is actually used to >>> load libjvm. So we can not put the dladdr routines for AIX there. But >>> I think we should at least consolidate the two versions which will be >>> in the class library after your change. Initially I intentionally put >>> porting_aix.{c,h} into jdk/aix/porting with the intent to make it >>> available to ALL jdk native libraries. >>> >>> Unfortunately, with the source code reorganization due to the modular >>> changes, the common, top-level aix repository had to go away and the >>> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. >>> With the reorganized, modularized source code layout and build system >>> it is not possible to share code between modules. We somehow have to >>> fix this although I currently don't know how. IF somebody has an idea, >>> please let me know :) >>> >> >> Why doesn't AIX support a Standard C API that most other >> *nix based OS'es support ? >> >> > dladdr() is not Posix, hence it should not be used in code that wants to > be portable across Unix systems. Afaik dladdr() is a propietary Solaris API > that was adapted by the glibc and slowly spread over to some other Unices, > but by no means all of them. > > dladdr makes a number of assumptions about the architecture: e.g. that a C > function pointer points into the text segment of the binary instead of e.g. > a PLT, or that a loaded binary is placed continuously in memory (we only > have one dli_fbase in DL_info). So imho it makes sense to not make this a > standard Posix API. > > We (SAP) implemented dladdr atop of loadquery(), and this kind of works, > although we had to add some hacks to handle both real code addresses and C > function pointers. So the code is there, it is "just" a question of where > to place it. > > > I understand your desire to keep AIX pristine and clean, similarly, > we should also keep OpenJDK sources clean, having 3 identical > dladdr implementation, spread across the OpenJDK does not > bode well. > > I'm not IBM :) and have therefore no strong emotions about keeping AIX pristine. I only did argue that dladdr() is not POSIX and therefore that it would have been nice if OpenJDK would have refrained from using this API (so much). Kind Regards, Thomas So, is it possible to park the sources in hotspot repo, and create a > shared shared object, that can be suitably linked to the launchers, > awt and hotspot to this library/object ? > > Thanks > Kumar > > > > > Kind Regards, Thomas > > Thanks >> >> Kumar >> >> >> >>> Regarding your change: >>> >>> - can you please move >>> >>> +#if defined(_AIX) >>> +#include "java_md_aix.h" >>> +#endif >>> + >>> >>> from java_md_common.c to the end of >>> java.base/unix/native/libjli/java_md.h. It will then be automatically >>> included into java_md_common.c trough java.h which includes java_md.h >>> >>> Also, this version of dladdr is inherently not thread safe. I don't >>> think that's a problem here, but it would be nice if you could quickly >>> check if that's indeed true. >>> >>> Besides that, looks good. >>> >>> Thanks for fixing, >>> Volker >>> >>> >>> >>> >>> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph >>> wrote: >>> >>>> Hi, >>>> >>>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks >>>> the AIX build as function dladdr is not available on AIX. >>>> >>>> There already exist ports of that API in hotspot and awt. With the >>>> proposed change I duplicate the awt port to libjli. This is maybe only a >>>> quick fix - eventually we should think about consolidating and using the >>>> hotspot port in all places by exporting it from libjvm.so for AIX. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >>>> >>>> Thanks >>>> Christoph >>>> >>>> >>>> -----Original Message----- >>>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] >>>>> On Behalf >>>>> Of Kumar Srinivasan >>>>> Sent: Montag, 12. September 2016 22:57 >>>>> To: core-libs-dev ; Mandy Chung >>>>> ; Chris Bensen >>>>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>>>> >>>>> Hello, >>>>> >>>>> I am sponsoring this changeset for Chris Bensen of the java packager >>>>> team, please review fix for the launcher to better locate java.home. >>>>> >>>>> http://cr.openjdk.java.net/~ksrini/8165524/ >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Sep 28 22:08:26 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Sep 2016 22:08:26 +0000 Subject: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c Message-ID: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> Hi, Please review: The file java.base/aix/native/libnio/ch/AixNativeThread.c does not differ significantly from java.base/unix/native/libnio/ch/NativeThread.c, except for 3 #include/#define statements as for any other distinct unix platform. So this should be consolidated. Bug: https://bugs.openjdk.java.net/browse/JDK-8166866 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166866.0/ Thanks & best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Sep 29 07:03:07 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 29 Sep 2016 09:03:07 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> Message-ID: On Wed, Sep 28, 2016 at 8:54 PM, Chris Bensen wrote: > > On Sep 28, 2016, at 11:50 AM, Thomas St?fe wrote: > > > > On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz > wrote: >> >> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis >> wrote: >> >> > >> > I don't think this can be easily done with the current build system. >> > Remember for example that even such a sensitive part like jni.h is >> > still duplicated between the hotspot and the jdk repository: >> > >> > hotspot/src/share/vm/prims/jni.h >> > jdk/src/java.base/share/native/include/jni.h >> > >> >> It's one of the frustrating aspects of openjdk development that it's hard >> to share C level infrastructure among different components. Components >> sometimes grow their own local C infrastructure, but when another >> component >> has the same problem, one often resorts to copy-paste as the most >> expedient >> way to get code reuse. In part, the mercurial repo organization >> reinforces >> this - there is one top-level repo with fan-out, but there is nothing at >> the bottom with fan-in. > > > At SAP, we often solve this by moving code to the hotspot and exporting it > from there, the hotspot being the central part which (almost) has to be > loaded from the very beginning. I think we did this for dladdr() too. > As I said before, this obviously can't work for libjli which is used to dynamically load the libjvm. > But that is an ugly hack too, because it bloats the hotspot and forces us to > add -ljvm to a lot of makefiles or to resolve those functions dynamically. > > Another solution for us on AIX could be to put this stuff into an own > library and provide it independently from the OpenJDK build system, just > declare it to be a build dependency, similar to Apples JavaRuntimeServices. > > As we need dladdr() in both hotspot and JDK, maybe that would be the best > option. > > > That sounds like a reasonable solution to me. > Sorry, but that doesn't sound like a solution to me at all. I think we should keep the OpenJDK sources self-contained. I don't want to depend on yet another non-standard, third party library which doesn't even exist now. The solution proposed by Martin could work, but it is not great from a software engineering perspective either because it doesn't allow sharing of header files. What would be actually needed would be a new top-level repository/directory (call it 'base' or 'porting' or whatsoever) which should be organized like for example jdk/java.base/src (i.e. have 'share/', 'unix/', 'windows/', etc. subdirectories. The artifacts from this new directory would be build as the very first step of the build process (if necessary) and the results, as well as the source directories themselves would have to be made available to all the other build steps (in particular to. hotspot and jdk). In fact I had implemented a similar solution for the jdk repository in order to stay with a single copy of dladdr on AIX (i.e. jdk/src/aix/porting). But this solution had to go away when the sources were modularized because the new schema doesn't allow sharing of files between modules anymore :( However, I'm not sure if we want to start such a project right now? > Chris > > > > >> >> One code sharing mechanism that does get used is seen in >> ClassLoader::load_zip_library() >> where code from the jdk repo is packaged into a shared object and invoked >> from hotspot, dynamically. > > > From volker.simonis at gmail.com Thu Sep 29 07:33:05 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 29 Sep 2016 09:33:05 +0200 Subject: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c In-Reply-To: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> References: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> Message-ID: Hi Christoph, looks good! Thanks for cleaning this up, Volker On Thu, Sep 29, 2016 at 12:08 AM, Langer, Christoph wrote: > Hi, > > > > Please review: The file java.base/aix/native/libnio/ch/AixNativeThread.c > does not differ significantly from > java.base/unix/native/libnio/ch/NativeThread.c, except for 3 > #include/#define statements as for any other distinct unix platform. So this > should be consolidated. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166866 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166866.0/ > > > > Thanks & best regards > > Christoph > > From chris.hegarty at oracle.com Thu Sep 29 08:27:13 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 29 Sep 2016 09:27:13 +0100 Subject: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c In-Reply-To: References: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> Message-ID: <21A77B03-59B6-45BB-A30D-7BA3F97B71B5@oracle.com> > On 29 Sep 2016, at 08:33, Volker Simonis wrote: > > Hi Christoph, > > looks good! +1. -Chris. > Thanks for cleaning this up, > Volker > > > On Thu, Sep 29, 2016 at 12:08 AM, Langer, Christoph > wrote: >> Hi, >> >> >> >> Please review: The file java.base/aix/native/libnio/ch/AixNativeThread.c >> does not differ significantly from >> java.base/unix/native/libnio/ch/NativeThread.c, except for 3 >> #include/#define statements as for any other distinct unix platform. So this >> should be consolidated. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166866 >> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166866.0/ >> >> >> >> Thanks & best regards >> >> Christoph >> >> From Alan.Bateman at oracle.com Thu Sep 29 08:42:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Sep 2016 09:42:53 +0100 Subject: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c In-Reply-To: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> References: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> Message-ID: <6fb8b93b-ac20-0ac0-1f6e-e84152658642@oracle.com> On 28/09/2016 23:08, Langer, Christoph wrote: > Hi, > > Please review: The file > java.base/aix/native/libnio/ch/AixNativeThread.c does not differ > significantly from java.base/unix/native/libnio/ch/NativeThread.c, > except for 3 #include/#define statements as for any other distinct > unix platform. So this should be consolidated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166866 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166866.0/ > > > this looks okay to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Sep 29 09:06:02 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 29 Sep 2016 11:06:02 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> Message-ID: <08b8536e-ce14-f0d5-295f-37df2286806f@oracle.com> Hello, From my point of view, now that I better understand what aix/porting actually was/is, I would say go for it. Put something together the way you would like it. I doubt there will ever be much code needed in this new entity so it can go in the top level repo without problems. There is already a common/src you can sort it into. I assume you will want to build a static lib that is easily picked up by other libraries and provide an include directory. Put a new makefile in /make that builds this, create a new top level target in /make/Main.gmk that calls it. Build it into /support/native/. Since this is only for AIX now, surround it with proper ifeqs. Doesn't really seem that complicated to me. :) Neither hotspot nor JDK is buildable on their own now, so there is no problem putting dependencies on either at the top level. /Erik On 2016-09-29 09:03, Volker Simonis wrote: > On Wed, Sep 28, 2016 at 8:54 PM, Chris Bensen wrote: >> On Sep 28, 2016, at 11:50 AM, Thomas St?fe wrote: >> >> >> >> On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz >> wrote: >>> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis >>> wrote: >>> >>>> I don't think this can be easily done with the current build system. >>>> Remember for example that even such a sensitive part like jni.h is >>>> still duplicated between the hotspot and the jdk repository: >>>> >>>> hotspot/src/share/vm/prims/jni.h >>>> jdk/src/java.base/share/native/include/jni.h >>>> >>> It's one of the frustrating aspects of openjdk development that it's hard >>> to share C level infrastructure among different components. Components >>> sometimes grow their own local C infrastructure, but when another >>> component >>> has the same problem, one often resorts to copy-paste as the most >>> expedient >>> way to get code reuse. In part, the mercurial repo organization >>> reinforces >>> this - there is one top-level repo with fan-out, but there is nothing at >>> the bottom with fan-in. >> >> At SAP, we often solve this by moving code to the hotspot and exporting it >> from there, the hotspot being the central part which (almost) has to be >> loaded from the very beginning. I think we did this for dladdr() too. >> > As I said before, this obviously can't work for libjli which is used > to dynamically load the libjvm. > >> But that is an ugly hack too, because it bloats the hotspot and forces us to >> add -ljvm to a lot of makefiles or to resolve those functions dynamically. >> >> Another solution for us on AIX could be to put this stuff into an own >> library and provide it independently from the OpenJDK build system, just >> declare it to be a build dependency, similar to Apples JavaRuntimeServices. >> >> As we need dladdr() in both hotspot and JDK, maybe that would be the best >> option. >> >> >> That sounds like a reasonable solution to me. >> > Sorry, but that doesn't sound like a solution to me at all. I think we > should keep the OpenJDK sources self-contained. I don't want to depend > on yet another non-standard, third party library which doesn't even > exist now. > > The solution proposed by Martin could work, but it is not great from a > software engineering perspective either because it doesn't allow > sharing of header files. > > What would be actually needed would be a new top-level > repository/directory (call it 'base' or 'porting' or whatsoever) which > should be organized like for example jdk/java.base/src (i.e. have > 'share/', 'unix/', 'windows/', etc. subdirectories. > > The artifacts from this new directory would be build as the very first > step of the build process (if necessary) and the results, as well as > the source directories themselves would have to be made available to > all the other build steps (in particular to. hotspot and jdk). In fact > I had implemented a similar solution for the jdk repository in order > to stay with a single copy of dladdr on AIX (i.e. > jdk/src/aix/porting). But this solution had to go away when the > sources were modularized because the new schema doesn't allow sharing > of files between modules anymore :( > > However, I'm not sure if we want to start such a project right now? > >> Chris >> >> >> >> >>> One code sharing mechanism that does get used is seen in >>> ClassLoader::load_zip_library() >>> where code from the jdk repo is packaged into a shared object and invoked >>> from hotspot, dynamically. >> >> From HORII at jp.ibm.com Thu Sep 29 12:00:27 2016 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Thu, 29 Sep 2016 21:00:27 +0900 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> <571A1FA3.9030006@oracle.com> <201604250709.u3P79jwN024101@d19av07.sagamino.japan.ibm.com> <1574d9e7-c9cd-b1e8-e9a1-d63630713724@oracle.com> <201605061011.u46ABZDR015108@d19av07.sagamino.japan.ibm.com> <848a70ad-00b3-b742-fa4e-87dc0124e0e3@oracle.com> <347b1733-fbbc-b65b-5417-7be52a0b5d68@oracle.com> <0e47ed4857d94f9bbd99b0738bf1708a@DEWDFE13DE14.global.corp.sap> Message-ID: Hi all, Can I please request reviews for a change for 8154736 that improve copy_to_survivor performance of ppc64 and aarch64? If possible, I would like to include this change into jdk9. 8154736 includes two changes, cmpxchg and copy_to_suvivor, and the former was resolved as 8155949. Now, I would like to ask a review for the remaining, copy_to_suvivor change. webrev: http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/ JIRA: https://bugs.openjdk.java.net/browse/JDK-8154736 I tested this change with SPECjbb2013. Also, I re-check that relaxed cmpxchg is available for changing forwarding pointers. However, because this change is sensitive, we need more reviews not only from compiler-dev, but also from gc-dev. Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo From: David Holmes To: "Doerr, Martin" , Hiroshi H Horii/Japan/IBM at IBMJP Cc: Tim Ellison , "ppc-aix-port-dev at openjdk.java.net" , "hotspot-gc-dev at openjdk.java.net" , "hotspot-runtime-dev at openjdk.java.net" Date: 05/10/2016 19:31 Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 On 10/05/2016 7:41 PM, Doerr, Martin wrote: > Hi David, > > thank you very much for testing the other platforms. > > Here's an updated webrev: > http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/ Thanks. Second test run on its way. David ----- > Best regards, > Martin > > -----Original Message----- > From: hotspot-runtime-dev [ mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David Holmes > Sent: Dienstag, 10. Mai 2016 11:11 > To: Hiroshi H Horii > Cc: Tim Ellison ; ppc-aix-port-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > > The fix seems incomplete for solaris: > > make/Main.gmk:232: recipe for target 'hotspot' failed > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp", > line 124: Error: Too many arguments in call to > "_Atomic_cmpxchg_long(long, volatile long*, long)". > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp", > line 128: Error: Too many arguments in call to > "_Atomic_cmpxchg_long(long, volatile long*, long)". > > David > > On 10/05/2016 5:34 PM, David Holmes wrote: >> Hi Hiroshi, >> >> On 6/05/2016 8:11 PM, Hiroshi H Horii wrote: >>> Hi David, >>> >>> Thank you for your comments. >>> >>> As Martin suggested me, I would like to separate this proposal to >>> - relaxing memory order of cmpxchg >>> - improvement of copy_to_survivior with relaxed cmpxchg >>> and discuss the former first. >>> >>> Martin thankfully created a new webrev that include a change of cmpxchg. >>> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.00/ >>> He has already tested it with AIX, linuxx86_64, linuxppc64le and >>> darwinintel64. >>> (Please tell me if I need to send a new mail for this PFR) >> >> Please do as it will be simpler to track that way. >> >>>> What I would prefer to see is an additional memory_order value (such as >>>> memory_order_ignored) which is the default for all methods declared to >>>> take a memory_order parameter. >>> >>> We added simple enum to specify memory order in atomic.hpp as follows. >>> >>> typedef enum cmpxchg_cmpxchg_memory_order { >>> memory_order_relaxed, >>> memory_order_conservative >>> } cmpxchg_memory_order; >>> >>> All of cmpxchg functions have an argument of cmpxchg_memory_order >>> with a default value memory_order_conservative that uses the same >>> semantics with the existing cmpxchg and requires no change for the >>> existing >>> callers. If you think "memory_order_ignored" is better than >>> "memory_order_conservative", I will be happy to modify this change. >>> (I just thought, "ignored" may resemble "relaxed" and may make >>> people who are familiar with C++11's memory semantics confused. >>> I would like to know thoughts of native speakers.) >> >> That is fine by me. I don't think "ignored" would be confused with >> "relaxed", but "conservative" is fine. >> >> I will run the patch through our internal build system while you prepare >> the updated RFR. My only concern is "unused argument" warnings from the >> compiler. :) >> >> We are quickly running into a hard deadline with Feature Complete >> however - possibly less than 24 hours - for hotspot changes. If this >> doesn't get in in time I will see if I can shepherd it through the >> approval process. >> >> Thanks, >> David >> >> >>> Regards, >>> Hiroshi >>> ----------------------- >>> Hiroshi Horii, Ph.D. >>> IBM Research - Tokyo >>> >>> >>> David Holmes wrote on 05/04/2016 14:55:29: >>> >>>> From: David Holmes >>>> To: Hiroshi H Horii/Japan/IBM at IBMJP >>>> Cc: hotspot-gc-dev at openjdk.java.net, hotspot-runtime- >>>> dev at openjdk.java.net, ppc-aix-port-dev at openjdk.java.net, Tim Ellison >>>> , Volker Simonis , >>>> "Doerr, Martin" , "Lindenmaier, Goetz" >>>> >>>> Date: 05/04/2016 14:57 >>>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and >>>> copy_to_survivor for ppc64 >>>> >>>> Hi Hiroshi, >>>> >>>> Sorry for the delay on getting back to this. >>>> >>>> On 25/04/2016 5:09 PM, Hiroshi H Horii wrote: >>>>> Hi David, >>>>> >>>>> Thank you for your comments and questions. >>>>> >>>>>> 1. Are the current cmpxchg semantics exactly the same as >>>>>> memory_order_seq_cst? >>>>> >>>>> This is very good question.. >>>>> >>>>> I guess, cmpxchg needs a more conservative constraint for memory >>> ordering >>>>> than C++11, to add sync after a compare-and-exchange operation. >>>>> >>>>> Could someone give comments or thoughts? >>>> >>>> I don't want to comment on the comparison with C++11. What I would >>>> prefer to see is an additional memory_order value (such as >>>> memory_order_ignored) which is the default for all methods declared to >>>> take a memory_order parameter. That way existing implementations are >>>> clearly ignoring the memory_order attribute and there is no potential >>>> for confusion as to whether the existing implementations equate to >>>> memory_order_seq_cst or not. >>>> >>>> That said, I'm not sure it makes sense to add the memory_order parameter >>>> to all methods with "cas" in their name, e.g. oopDesc::cas_set_mark, >>>> oopDesc::cas_forward_to, unless those methods can sensibly be called >>>> with any value for memory_order - which seems highly unlikely. Perhaps >>>> those methods should identify the weakest form of memory_order they >>>> support and that should be hard-wired into them? >>>> >>>> Thanks, >>>> David >>>> >>>>> memory_order_seq_cst is defined as >>>>> "Any operation with this memory order is both an acquire >>> operation and >>>>> a release operation, plus a single total order exists in which >>>> all >>>>> threads >>>>> observe all modifications (see below) in the same order." >>>>> (http://en.cppreference.com/w/cpp/atomic/memory_order) >>>>> >>>>> In my environment, g++ and xlc generate following assemblies on >>>> ppc64le. >>>>> (interestingly, they generates the same assemblies for any >>>> memory_order) >>>>> >>>>> g++ (4.9.2) >>>>> 100008a4: ac 04 00 7c sync >>>>> 100008a8: 28 50 20 7d lwarx r9,0,r10 >>>>> 100008ac: 00 18 09 7c cmpw r9,r3 >>>>> 100008b0: 0c 00 c2 40 bne- 100008bc >>>>> 100008b4: 2d 51 80 7c stwcx. r4,0,r10 >>>>> 100008b8: f0 ff c2 40 bne- 100008a8 >>>>> 100008bc: 2c 01 00 4c isync >>>>> >>>>> xlc (13.1.3) >>>>> 10000888: ac 04 00 7c sync >>>>> 1000088c: 28 28 c0 7c lwarx r6,0,r5 >>>>> 10000890: 40 00 26 7c cmpld r6,r0 >>>>> 10000894: 0c 00 82 40 bne 100008a0 >>>>> 10000898: 2d 29 80 7c stwcx. r4,0,r5 >>>>> 1000089c: f0 ff e2 40 bne+ 1000088c >>>>> 100008a0: 2c 01 00 4c isync >>>>> >>>>> On the other hand, the current OpenJDK generates following assemblies. >>>>> >>>>> 508: ac 04 00 7c sync >>>>> 50c: 00 00 5c e9 ld r10,0(r28) >>>>> 510: 00 50 3b 7c cmpd r27,r10 >>>>> 514: 1c 00 c2 40 bne- 530 >>>>> 518: a8 40 5c 7d ldarx r10,r28,r8 >>>>> 51c: 00 50 3b 7c cmpd r27,r10 >>>>> 520: 10 00 c2 40 bne- 530 >>>>> 524: ad 41 3c 7d stdcx. r9,r28,r8 >>>>> 528: f0 ff c2 40 bne- 518 >>>>> 52c: ac 04 00 7c sync >>>>> 530: 00 50 bb 7f ... >>>>> >>>>> Though we can ignore 50c-514 (because they are a duplicated guard >>>>> condition), >>>>> the last sync instruction (52c) makes cmpxchg more strict than >>>>> memory_order_seq_cst. >>>>> >>>>> In some cases, the last sync is necessary when this thread must be >>>> able >>>>> to read >>>>> all of the changes in the other threads while executing from 508 to >>>> 530 >>>>> (that processes compare-and-exchange). >>>>> >>>>>> 2. Has there been a discussion already, establishing that the >>>> modified >>>>>> GC code can indeed use memory_order_relaxed? Otherwise who is >>>>>> postulating that and based on what evidence? >>>>> >>>>> Volker and his colleagues have investigated the current GC codes >>>>> according to this. >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>> April/019079.html >>>>> However, I believe, we need comments of other GC experts to change >>>>> the shared codes. >>>>> >>>>> Regards, >>>>> Hiroshi >>>>> ----------------------- >>>>> Hiroshi Horii, Ph.D. >>>>> IBM Research - Tokyo >>>>> >>>>> >>>>> David Holmes wrote on 04/22/2016 21:57:07: >>>>> >>>>>> From: David Holmes >>>>>> To: Hiroshi H Horii/Japan/IBM at IBMJP, hotspot-runtime- >>>>>> dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net >>>>>> Cc: Tim Ellison , >>>>> ppc-aix-port-dev at openjdk.java.net >>>>>> Date: 04/22/2016 21:58 >>>>>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and >>>>>> copy_to_survivor for ppc64 >>>>>> >>>>>> Hi Hiroshi, >>>>>> >>>>>> Two initial questions: >>>>>> >>>>>> 1. Are the current cmpxchg semantics exactly the same as >>>>>> memory_order_seq_cst? >>>>>> >>>>>> 2. Has there been a discussion already, establishing that the >>>> modified >>>>>> GC code can indeed use memory_order_relaxed? Otherwise who is >>>>>> postulating that and based on what evidence? >>>>>> >>>>>> Missing memory barriers have caused very difficult to track down >>> bugs in >>>>>> the past - very rare race conditions. So any relaxation here has >>>> to be >>>>>> done with extreme confidence. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 22/04/2016 10:28 PM, Hiroshi H Horii wrote: >>>>>>> Dear all: >>>>>>> >>>>>>> Can I please request reviews for the following change? >>>>>>> >>>>>>> Code change: >>>>>>> >>> http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ >>>>>>> (I initially created and Martin enhanced so much) >>>>>>> >>>>>>> This change follows the discussion started from this mail. >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>>>> April/018960.html >>>>>>> >>>>>>> Description: >>>>>>> This change provides relaxed compare-and-exchange by introducing >>>>>>> similar semantics of C++ atomic memory operators, enum >>>> memory_order. >>>>>>> As described in atomic_linux_ppc.inline.hpp, the current >>>>> implementation of >>>>>>> cmpxchg is fence_cmpxchg_acquire. This implementation is useful for >>>>>>> general purposes because twice calls of sync before and after >>>>> cmpxchg will >>>>>>> provide strict consistency. However, they sometimes cause overheads >>>>>>> because >>>>>>> sync instructions are very expensive in the current POWER chip >>> design. >>>>>>> In addition, for the other platforms, such as aarch64, this strict >>>>>>> semantics >>>>>>> may cause some overheads (according to the Andrew's mail). >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>>>> April/019073.html >>>>>>> >>>>>>> With this change, callers can explicitly specify constraints of >>> memory >>>>>>> ordering >>>>>>> for cmpxchg with an additional parameter, memory_order order. >>>>>>> >>>>>>> typedef enum memory_order { >>>>>>> memory_order_relaxed, >>>>>>> memory_order_consume, >>>>>>> memory_order_acquire, >>>>>>> memory_order_release, >>>>>>> memory_order_acq_rel, >>>>>>> memory_order_seq_cst >>>>>>> } memory_order; >>>>>>> >>>>>>> Because the default value of the parameter is memory_order_seq_cst, >>>>>>> existing codes can use the same semantics of cmpxchg without any >>>>>>> modification. The relaxed cmpxchg is implemented only on ppc >>>>>>> in this changeset. Therefore, the behavior on the other platforms >>> will >>>>>>> not be changed with this changeset. >>>>>>> >>>>>>> In addition, with the new parameter of cmpxchg, this change >>>> improves >>>>>>> performance of copy_to_survivor in the parallel GC. >>>>>>> copy_to_survivor changes forward pointers by using cmpxchg. This >>>>>>> operation doesn't require any sync instructions. A pointer is >>> changed >>>>>>> at most once in a GC and when cmpxchg fails, the latest pointer is >>>>>>> available for the caller. cas_set_mark and cas_forward_to are >>> extended >>>>>>> with an additional memory_order parameter as cmpxchg and >>>>> copy_to_survivor >>>>>>> uses memory_order_relaxed to modify the forward pointers. >>>>>>> >>>>>>> Summary of source code changes: >>>>>>> >>>>>>> * src/share/vm/runtime/atomic.hpp >>>>>>> - Defines enum memory_order and adds a parameter to cmpxchg. >>>>>>> >>>>>>> * src/share/vm/runtime/atomic.cpp >>>>>>> * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp >>>>>>> * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp >>>>>>> * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp >>>>>>> * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp >>>>>>> * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp >>>>>>> * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp >>>>>>> * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp >>>>>>> * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp >>>>>>> * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp >>>>>>> - Added a parameter for each cmpxchg function to follow >>>>>>> the change of atomic.hpp. Their implementations are not >>>>> changed. >>>>>>> >>>>>>> * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp >>>>>>> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp >>>>>>> - Added a parameter for each cmpxchg function to follow >>>>>>> the change of atomic.hpp. In addition, implementations >>>>>>> are changed corresponding to the specified memory_order. >>>>>>> >>>>>>> * src/share/vm/oops/oop.hpp >>>>>>> * src/share/vm/oops/oop.inline.hpp >>>>>>> - Add a memory_order parameter to use relaxed cmpxchg in >>>>>>> cas_set_mark and cas_forward_to. >>>>>>> >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.cpp >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.inline.hpp >>>>>>> >>>>>>> Martin tested this changeset on linuxx86_64, linuxppc64le and >>>>>>> darwinintel64. >>>>>>> Though more time is needed to test on the other platform, we would >>>>> like to >>>>>>> ask >>>>>>> reviews and start discussion on this changeset. >>>>>>> I also tested this changeset with SPECjbb2013 and confirmed that gc >>>>> pause >>>>>>> time >>>>>>> is reduced. >>>>>>> >>>>>>> Regards, >>>>>>> Hiroshi >>>>>>> ----------------------- >>>>>>> Hiroshi Horii, Ph.D. >>>>>>> IBM Research - Tokyo >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Sep 29 13:07:42 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 29 Sep 2016 13:07:42 +0000 Subject: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c In-Reply-To: <6fb8b93b-ac20-0ac0-1f6e-e84152658642@oracle.com> References: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> <6fb8b93b-ac20-0ac0-1f6e-e84152658642@oracle.com> Message-ID: <70e5eb3a000f47578c301c6883f1c9a0@DEWDFE13DE11.global.corp.sap> Thanks, guys, for reviewing. I pushed it: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/91a5353ecbbb Best regards Christoph From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Donnerstag, 29. September 2016 10:43 To: Langer, Christoph ; nio-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c On 28/09/2016 23:08, Langer, Christoph wrote: Hi, Please review: The file java.base/aix/native/libnio/ch/AixNativeThread.c does not differ significantly from java.base/unix/native/libnio/ch/NativeThread.c, except for 3 #include/#define statements as for any other distinct unix platform. So this should be consolidated. Bug: https://bugs.openjdk.java.net/browse/JDK-8166866 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166866.0/ this looks okay to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From varming at gmail.com Thu Sep 29 14:47:29 2016 From: varming at gmail.com (Carsten Varming) Date: Thu, 29 Sep 2016 10:47:29 -0400 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> <571A1FA3.9030006@oracle.com> <201604250709.u3P79jwN024101@d19av07.sagamino.japan.ibm.com> <1574d9e7-c9cd-b1e8-e9a1-d63630713724@oracle.com> <201605061011.u46ABZDR015108@d19av07.sagamino.japan.ibm.com> <848a70ad-00b3-b742-fa4e-87dc0124e0e3@oracle.com> <347b1733-fbbc-b65b-5417-7be52a0b5d68@oracle.com> <0e47ed4857d94f9bbd99b0738bf1708a@DEWDFE13DE14.global.corp.sap> Message-ID: Dear Hiroshi, In hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:266 the log line reads data from the forwardee even when the CAS fails. I believe those reads will be unsafe without barriers after the copy of the content of the object. hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:288 same problem as in line 266 I would argue that the logging should only happen if the thread successfully copied the object and CAS failures should be logged separately without reading data from the forwardee. BTW, unrelated to your change: It seems like the logging in line 266 should be guarded by something like "if (log_develop_is_enabled(Trace, gc, scavenge)" like the logging in line 288. Carsten On Thu, Sep 29, 2016 at 8:00 AM, Hiroshi H Horii wrote: > Hi all, > > Can I please request reviews for a change for 8154736 that improve > copy_to_survivor performance of ppc64 and aarch64? > If possible, I would like to include this change into jdk9. > > 8154736 includes two changes, cmpxchg and copy_to_suvivor, and the former > was resolved as 8155949. > Now, I would like to ask a review for the remaining, copy_to_suvivor > change. > > webrev: > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/ > JIRA: https://bugs.openjdk.java.net/browse/JDK-8154736 > > I tested this change with SPECjbb2013. Also, I re-check that relaxed > cmpxchg is available for changing forwarding pointers. However, because > this change is sensitive, we need more reviews not only from compiler-dev, > but also from gc-dev. > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > > > > From: David Holmes > To: "Doerr, Martin" , Hiroshi H > Horii/Japan/IBM at IBMJP > Cc: Tim Ellison , > "ppc-aix-port-dev at openjdk.java.net" , > "hotspot-gc-dev at openjdk.java.net" , > "hotspot-runtime-dev at openjdk.java.net" > > Date: 05/10/2016 19:31 > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > > > On 10/05/2016 7:41 PM, Doerr, Martin wrote: > > Hi David, > > > > thank you very much for testing the other platforms. > > > > Here's an updated webrev: > > http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/ > > Thanks. Second test run on its way. > > David > ----- > > > Best regards, > > Martin > > > > -----Original Message----- > > From: hotspot-runtime-dev [ > mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David > Holmes > > Sent: Dienstag, 10. Mai 2016 11:11 > > To: Hiroshi H Horii > > Cc: Tim Ellison ; > ppc-aix-port-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > > > The fix seems incomplete for solaris: > > > > make/Main.gmk:232: recipe for target 'hotspot' failed > > > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/ > solaris_x86/vm/atomic_solaris_x86.inline.hpp", > > line 124: Error: Too many arguments in call to > > "_Atomic_cmpxchg_long(long, volatile long*, long)". > > > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/ > solaris_x86/vm/atomic_solaris_x86.inline.hpp", > > line 128: Error: Too many arguments in call to > > "_Atomic_cmpxchg_long(long, volatile long*, long)". > > > > David > > > > On 10/05/2016 5:34 PM, David Holmes wrote: > >> Hi Hiroshi, > >> > >> On 6/05/2016 8:11 PM, Hiroshi H Horii wrote: > >>> Hi David, > >>> > >>> Thank you for your comments. > >>> > >>> As Martin suggested me, I would like to separate this proposal to > >>> - relaxing memory order of cmpxchg > >>> - improvement of copy_to_survivior with relaxed cmpxchg > >>> and discuss the former first. > >>> > >>> Martin thankfully created a new webrev that include a change of > cmpxchg. > >>> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.00/ > >>> He has already tested it with AIX, linuxx86_64, linuxppc64le and > >>> darwinintel64. > >>> (Please tell me if I need to send a new mail for this PFR) > >> > >> Please do as it will be simpler to track that way. > >> > >>>> What I would prefer to see is an additional memory_order value (such > as > >>>> memory_order_ignored) which is the default for all methods declared > to > >>>> take a memory_order parameter. > >>> > >>> We added simple enum to specify memory order in atomic.hpp as follows. > >>> > >>> typedef enum cmpxchg_cmpxchg_memory_order { > >>> memory_order_relaxed, > >>> memory_order_conservative > >>> } cmpxchg_memory_order; > >>> > >>> All of cmpxchg functions have an argument of cmpxchg_memory_order > >>> with a default value memory_order_conservative that uses the same > >>> semantics with the existing cmpxchg and requires no change for the > >>> existing > >>> callers. If you think "memory_order_ignored" is better than > >>> "memory_order_conservative", I will be happy to modify this change. > >>> (I just thought, "ignored" may resemble "relaxed" and may make > >>> people who are familiar with C++11's memory semantics confused. > >>> I would like to know thoughts of native speakers.) > >> > >> That is fine by me. I don't think "ignored" would be confused with > >> "relaxed", but "conservative" is fine. > >> > >> I will run the patch through our internal build system while you > prepare > >> the updated RFR. My only concern is "unused argument" warnings from the > >> compiler. :) > >> > >> We are quickly running into a hard deadline with Feature Complete > >> however - possibly less than 24 hours - for hotspot changes. If this > >> doesn't get in in time I will see if I can shepherd it through the > >> approval process. > >> > >> Thanks, > >> David > >> > >> > >>> Regards, > >>> Hiroshi > >>> ----------------------- > >>> Hiroshi Horii, Ph.D. > >>> IBM Research - Tokyo > >>> > >>> > >>> David Holmes wrote on 05/04/2016 14:55:29: > >>> > >>>> From: David Holmes > >>>> To: Hiroshi H Horii/Japan/IBM at IBMJP > >>>> Cc: hotspot-gc-dev at openjdk.java.net, hotspot-runtime- > >>>> dev at openjdk.java.net, ppc-aix-port-dev at openjdk.java.net, Tim Ellison > >>>> , Volker Simonis , > >>>> "Doerr, Martin" , "Lindenmaier, Goetz" > >>>> > >>>> Date: 05/04/2016 14:57 > >>>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > >>>> copy_to_survivor for ppc64 > >>>> > >>>> Hi Hiroshi, > >>>> > >>>> Sorry for the delay on getting back to this. > >>>> > >>>> On 25/04/2016 5:09 PM, Hiroshi H Horii wrote: > >>>>> Hi David, > >>>>> > >>>>> Thank you for your comments and questions. > >>>>> > >>>>>> 1. Are the current cmpxchg semantics exactly the same as > >>>>>> memory_order_seq_cst? > >>>>> > >>>>> This is very good question.. > >>>>> > >>>>> I guess, cmpxchg needs a more conservative constraint for memory > >>> ordering > >>>>> than C++11, to add sync after a compare-and-exchange operation. > >>>>> > >>>>> Could someone give comments or thoughts? > >>>> > >>>> I don't want to comment on the comparison with C++11. What I would > >>>> prefer to see is an additional memory_order value (such as > >>>> memory_order_ignored) which is the default for all methods declared > to > >>>> take a memory_order parameter. That way existing implementations are > >>>> clearly ignoring the memory_order attribute and there is no potential > >>>> for confusion as to whether the existing implementations equate to > >>>> memory_order_seq_cst or not. > >>>> > >>>> That said, I'm not sure it makes sense to add the memory_order > parameter > >>>> to all methods with "cas" in their name, e.g. oopDesc::cas_set_mark, > >>>> oopDesc::cas_forward_to, unless those methods can sensibly be called > >>>> with any value for memory_order - which seems highly unlikely. > Perhaps > >>>> those methods should identify the weakest form of memory_order they > >>>> support and that should be hard-wired into them? > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> memory_order_seq_cst is defined as > >>>>> "Any operation with this memory order is both an acquire > >>> operation and > >>>>> a release operation, plus a single total order exists in which > >>>> all > >>>>> threads > >>>>> observe all modifications (see below) in the same order." > >>>>> (http://en.cppreference.com/w/cpp/atomic/memory_order) > >>>>> > >>>>> In my environment, g++ and xlc generate following assemblies on > >>>> ppc64le. > >>>>> (interestingly, they generates the same assemblies for any > >>>> memory_order) > >>>>> > >>>>> g++ (4.9.2) > >>>>> 100008a4: ac 04 00 7c sync > >>>>> 100008a8: 28 50 20 7d lwarx r9,0,r10 > >>>>> 100008ac: 00 18 09 7c cmpw r9,r3 > >>>>> 100008b0: 0c 00 c2 40 bne- 100008bc > >>>>> 100008b4: 2d 51 80 7c stwcx. r4,0,r10 > >>>>> 100008b8: f0 ff c2 40 bne- 100008a8 > >>>>> 100008bc: 2c 01 00 4c isync > >>>>> > >>>>> xlc (13.1.3) > >>>>> 10000888: ac 04 00 7c sync > >>>>> 1000088c: 28 28 c0 7c lwarx r6,0,r5 > >>>>> 10000890: 40 00 26 7c cmpld r6,r0 > >>>>> 10000894: 0c 00 82 40 bne 100008a0 > >>>>> 10000898: 2d 29 80 7c stwcx. r4,0,r5 > >>>>> 1000089c: f0 ff e2 40 bne+ 1000088c > >>>>> 100008a0: 2c 01 00 4c isync > >>>>> > >>>>> On the other hand, the current OpenJDK generates following > assemblies. > >>>>> > >>>>> 508: ac 04 00 7c sync > >>>>> 50c: 00 00 5c e9 ld r10,0(r28) > >>>>> 510: 00 50 3b 7c cmpd r27,r10 > >>>>> 514: 1c 00 c2 40 bne- 530 > >>>>> 518: a8 40 5c 7d ldarx r10,r28,r8 > >>>>> 51c: 00 50 3b 7c cmpd r27,r10 > >>>>> 520: 10 00 c2 40 bne- 530 > >>>>> 524: ad 41 3c 7d stdcx. r9,r28,r8 > >>>>> 528: f0 ff c2 40 bne- 518 > >>>>> 52c: ac 04 00 7c sync > >>>>> 530: 00 50 bb 7f ... > >>>>> > >>>>> Though we can ignore 50c-514 (because they are a duplicated guard > >>>>> condition), > >>>>> the last sync instruction (52c) makes cmpxchg more strict than > >>>>> memory_order_seq_cst. > >>>>> > >>>>> In some cases, the last sync is necessary when this thread must be > >>>> able > >>>>> to read > >>>>> all of the changes in the other threads while executing from 508 to > >>>> 530 > >>>>> (that processes compare-and-exchange). > >>>>> > >>>>>> 2. Has there been a discussion already, establishing that the > >>>> modified > >>>>>> GC code can indeed use memory_order_relaxed? Otherwise who is > >>>>>> postulating that and based on what evidence? > >>>>> > >>>>> Volker and his colleagues have investigated the current GC codes > >>>>> according to this. > >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > >>>> April/019079.html > >>>>> However, I believe, we need comments of other GC experts to change > >>>>> the shared codes. > >>>>> > >>>>> Regards, > >>>>> Hiroshi > >>>>> ----------------------- > >>>>> Hiroshi Horii, Ph.D. > >>>>> IBM Research - Tokyo > >>>>> > >>>>> > >>>>> David Holmes wrote on 04/22/2016 21:57:07: > >>>>> > >>>>>> From: David Holmes > >>>>>> To: Hiroshi H Horii/Japan/IBM at IBMJP, hotspot-runtime- > >>>>>> dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net > >>>>>> Cc: Tim Ellison , > >>>>> ppc-aix-port-dev at openjdk.java.net > >>>>>> Date: 04/22/2016 21:58 > >>>>>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > >>>>>> copy_to_survivor for ppc64 > >>>>>> > >>>>>> Hi Hiroshi, > >>>>>> > >>>>>> Two initial questions: > >>>>>> > >>>>>> 1. Are the current cmpxchg semantics exactly the same as > >>>>>> memory_order_seq_cst? > >>>>>> > >>>>>> 2. Has there been a discussion already, establishing that the > >>>> modified > >>>>>> GC code can indeed use memory_order_relaxed? Otherwise who is > >>>>>> postulating that and based on what evidence? > >>>>>> > >>>>>> Missing memory barriers have caused very difficult to track down > >>> bugs in > >>>>>> the past - very rare race conditions. So any relaxation here has > >>>> to be > >>>>>> done with extreme confidence. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>> On 22/04/2016 10:28 PM, Hiroshi H Horii wrote: > >>>>>>> Dear all: > >>>>>>> > >>>>>>> Can I please request reviews for the following change? > >>>>>>> > >>>>>>> Code change: > >>>>>>> > >>> http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ > >>>>>>> (I initially created and Martin enhanced so much) > >>>>>>> > >>>>>>> This change follows the discussion started from this mail. > >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > >>>>>> April/018960.html > >>>>>>> > >>>>>>> Description: > >>>>>>> This change provides relaxed compare-and-exchange by introducing > >>>>>>> similar semantics of C++ atomic memory operators, enum > >>>> memory_order. > >>>>>>> As described in atomic_linux_ppc.inline.hpp, the current > >>>>> implementation of > >>>>>>> cmpxchg is fence_cmpxchg_acquire. This implementation is useful > for > >>>>>>> general purposes because twice calls of sync before and after > >>>>> cmpxchg will > >>>>>>> provide strict consistency. However, they sometimes cause > overheads > >>>>>>> because > >>>>>>> sync instructions are very expensive in the current POWER chip > >>> design. > >>>>>>> In addition, for the other platforms, such as aarch64, this strict > >>>>>>> semantics > >>>>>>> may cause some overheads (according to the Andrew's mail). > >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > >>>>>> April/019073.html > >>>>>>> > >>>>>>> With this change, callers can explicitly specify constraints of > >>> memory > >>>>>>> ordering > >>>>>>> for cmpxchg with an additional parameter, memory_order order. > >>>>>>> > >>>>>>> typedef enum memory_order { > >>>>>>> memory_order_relaxed, > >>>>>>> memory_order_consume, > >>>>>>> memory_order_acquire, > >>>>>>> memory_order_release, > >>>>>>> memory_order_acq_rel, > >>>>>>> memory_order_seq_cst > >>>>>>> } memory_order; > >>>>>>> > >>>>>>> Because the default value of the parameter is > memory_order_seq_cst, > >>>>>>> existing codes can use the same semantics of cmpxchg without any > >>>>>>> modification. The relaxed cmpxchg is implemented only on ppc > >>>>>>> in this changeset. Therefore, the behavior on the other platforms > >>> will > >>>>>>> not be changed with this changeset. > >>>>>>> > >>>>>>> In addition, with the new parameter of cmpxchg, this change > >>>> improves > >>>>>>> performance of copy_to_survivor in the parallel GC. > >>>>>>> copy_to_survivor changes forward pointers by using cmpxchg. This > >>>>>>> operation doesn't require any sync instructions. A pointer is > >>> changed > >>>>>>> at most once in a GC and when cmpxchg fails, the latest pointer is > >>>>>>> available for the caller. cas_set_mark and cas_forward_to are > >>> extended > >>>>>>> with an additional memory_order parameter as cmpxchg and > >>>>> copy_to_survivor > >>>>>>> uses memory_order_relaxed to modify the forward pointers. > >>>>>>> > >>>>>>> Summary of source code changes: > >>>>>>> > >>>>>>> * src/share/vm/runtime/atomic.hpp > >>>>>>> - Defines enum memory_order and adds a parameter to cmpxchg. > >>>>>>> > >>>>>>> * src/share/vm/runtime/atomic.cpp > >>>>>>> * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp > >>>>>>> * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > >>>>>>> * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp > >>>>>>> * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp > >>>>>>> * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp > >>>>>>> * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > >>>>>>> * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp > >>>>>>> * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp > >>>>>>> * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp > >>>>>>> - Added a parameter for each cmpxchg function to follow > >>>>>>> the change of atomic.hpp. Their implementations are not > >>>>> changed. > >>>>>>> > >>>>>>> * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp > >>>>>>> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > >>>>>>> - Added a parameter for each cmpxchg function to follow > >>>>>>> the change of atomic.hpp. In addition, implementations > >>>>>>> are changed corresponding to the specified memory_order. > >>>>>>> > >>>>>>> * src/share/vm/oops/oop.hpp > >>>>>>> * src/share/vm/oops/oop.inline.hpp > >>>>>>> - Add a memory_order parameter to use relaxed cmpxchg in > >>>>>>> cas_set_mark and cas_forward_to. > >>>>>>> > >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.cpp > >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.inline.hpp > >>>>>>> > >>>>>>> Martin tested this changeset on linuxx86_64, linuxppc64le and > >>>>>>> darwinintel64. > >>>>>>> Though more time is needed to test on the other platform, we would > >>>>> like to > >>>>>>> ask > >>>>>>> reviews and start discussion on this changeset. > >>>>>>> I also tested this changeset with SPECjbb2013 and confirmed that > gc > >>>>> pause > >>>>>>> time > >>>>>>> is reduced. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Hiroshi > >>>>>>> ----------------------- > >>>>>>> Hiroshi Horii, Ph.D. > >>>>>>> IBM Research - Tokyo > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Burlison at oracle.com Thu Sep 29 14:54:28 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 29 Sep 2016 15:54:28 +0100 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> Message-ID: <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> On 29/09/2016 08:03, Volker Simonis wrote: > Sorry, but that doesn't sound like a solution to me at all. I think we > should keep the OpenJDK sources self-contained. I don't want to depend > on yet another non-standard, third party library which doesn't even > exist now. Unless I'm completely misunderstanding, that's not what is being proposed. What is being proposed is refactoring code that's currently duplicated across the JVM & JDK into a common library. Such a library would be a standard Java component, not non-standard and not third-party. I can't see what the problem is, to be honest. -- Alan Burlison -- From erik.joelsson at oracle.com Thu Sep 29 15:25:54 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 29 Sep 2016 17:25:54 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> Message-ID: On 2016-09-29 16:54, Alan Burlison wrote: > On 29/09/2016 08:03, Volker Simonis wrote: > >> Sorry, but that doesn't sound like a solution to me at all. I think we >> should keep the OpenJDK sources self-contained. I don't want to depend >> on yet another non-standard, third party library which doesn't even >> exist now. > > Unless I'm completely misunderstanding, that's not what is being > proposed. What is being proposed is refactoring code that's currently > duplicated across the JVM & JDK into a common library. Such a library > would be a standard Java component, not non-standard and not > third-party. I can't see what the problem is, to be honest. > Volker's comment above was directed at the suggestion of taking the problematic AIX specific code out of the OpenJDK repositories and create a separate library with a separate lifecycle somewhere else that OpenJDK for AIX would then need to depend on. Volker was instead proposing what you describe. /Erik From chris.bensen at oracle.com Thu Sep 29 15:47:41 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 29 Sep 2016 08:47:41 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> Message-ID: <98A61D7A-D64A-4BE7-BEB8-6927C31BCF50@oracle.com> A lot of ideas have been thrown around so solve the problem of duplicated code in this situation. And there are other cases that are nearly identical so we need a general solution. The fact is this code should be moved to a common location. Since OpenJDK depends on Posix, Windows API and a few other non standard things that are mostly standard such as dladdr, it has been suggested by me and others that a library that doesn?t depend on anything else be created containing these methods to backfill the API that OpenJDK depends on if that API is not present on that platform. If that is a library outside OpenJDK or inside I?m not sure if that matters. Fact is there should be a library that contains method such as dladdr in cases such as AIX that do not have that method. Personally I?m not sure if the hack implementation of dladdr for AIX should be located in OpenJDK. Chris > On Sep 29, 2016, at 8:25 AM, Erik Joelsson wrote: > > > > On 2016-09-29 16:54, Alan Burlison wrote: >> On 29/09/2016 08:03, Volker Simonis wrote: >> >>> Sorry, but that doesn't sound like a solution to me at all. I think we >>> should keep the OpenJDK sources self-contained. I don't want to depend >>> on yet another non-standard, third party library which doesn't even >>> exist now. >> >> Unless I'm completely misunderstanding, that's not what is being proposed. What is being proposed is refactoring code that's currently duplicated across the JVM & JDK into a common library. Such a library would be a standard Java component, not non-standard and not third-party. I can't see what the problem is, to be honest. >> > Volker's comment above was directed at the suggestion of taking the problematic AIX specific code out of the OpenJDK repositories and create a separate library with a separate lifecycle somewhere else that OpenJDK for AIX would then need to depend on. Volker was instead proposing what you describe. > > /Erik From volker.simonis at gmail.com Thu Sep 29 16:59:20 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 29 Sep 2016 18:59:20 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> Message-ID: On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson wrote: > > > On 2016-09-29 16:54, Alan Burlison wrote: >> >> On 29/09/2016 08:03, Volker Simonis wrote: >> >>> Sorry, but that doesn't sound like a solution to me at all. I think we >>> should keep the OpenJDK sources self-contained. I don't want to depend >>> on yet another non-standard, third party library which doesn't even >>> exist now. >> >> >> Unless I'm completely misunderstanding, that's not what is being proposed. >> What is being proposed is refactoring code that's currently duplicated >> across the JVM & JDK into a common library. Such a library would be a >> standard Java component, not non-standard and not third-party. I can't see >> what the problem is, to be honest. >> > Volker's comment above was directed at the suggestion of taking the > problematic AIX specific code out of the OpenJDK repositories and create a > separate library with a separate lifecycle somewhere else that OpenJDK for > AIX would then need to depend on. Volker was instead proposing what you > describe. > Thanks Erik, this is exactly what I meant :) And I think the solution you ssketched in your previous mail is the right way to address this problem. Regards, Volker > /Erik From Alan.Burlison at oracle.com Thu Sep 29 17:43:30 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 29 Sep 2016 18:43:30 +0100 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> Message-ID: <53928416-7072-eb17-4527-9b2252e3c080@oracle.com> On 29/09/2016 16:25, Erik Joelsson wrote: > Volker's comment above was directed at the suggestion of taking the > problematic AIX specific code out of the OpenJDK repositories and create > a separate library with a separate lifecycle somewhere else that OpenJDK > for AIX would then need to depend on. Volker was instead proposing what > you describe. Ah right, in which case we are in violent agreement ;-) -- Alan Burlison -- From kumar.x.srinivasan at oracle.com Thu Sep 29 17:48:59 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 29 Sep 2016 10:48:59 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <53928416-7072-eb17-4527-9b2252e3c080@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> <53928416-7072-eb17-4527-9b2252e3c080@oracle.com> Message-ID: <57ED540B.9010906@oracle.com> +1. Kumar > On 29/09/2016 16:25, Erik Joelsson wrote: > >> Volker's comment above was directed at the suggestion of taking the >> problematic AIX specific code out of the OpenJDK repositories and create >> a separate library with a separate lifecycle somewhere else that OpenJDK >> for AIX would then need to depend on. Volker was instead proposing what >> you describe. > > Ah right, in which case we are in violent agreement ;-) > From david.holmes at oracle.com Thu Sep 29 22:16:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Sep 2016 08:16:16 +1000 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> <571A1FA3.9030006@oracle.com> <201604250709.u3P79jwN024101@d19av07.sagamino.japan.ibm.com> <1574d9e7-c9cd-b1e8-e9a1-d63630713724@oracle.com> <201605061011.u46ABZDR015108@d19av07.sagamino.japan.ibm.com> <848a70ad-00b3-b742-fa4e-87dc0124e0e3@oracle.com> <347b1733-fbbc-b65b-5417-7be52a0b5d68@oracle.com> <0e47ed4857d94f9bbd99b0738bf1708a@DEWDFE13DE14.global.corp.sap> Message-ID: On 30/09/2016 12:47 AM, Carsten Varming wrote: > Dear Hiroshi, > > In hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:266 > the log line reads data from the forwardee even when the CAS fails. I > believe those reads will be unsafe without barriers after the copy of > the content of the object. I find it extremely hard to reason about a barrier-less cmpxchg in general. If you feel that the use of new_obj->size() is potentially unsafe then the fact we return new_obj means that any use of new_obj by the caller may also potentially be unsafe. David ----- > hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:288 same > problem as in line 266 > > I would argue that the logging should only happen if the thread > successfully copied the object and CAS failures should be logged > separately without reading data from the forwardee. > > BTW, unrelated to your change: It seems like the logging in line 266 > should be guarded by something like "if (log_develop_is_enabled(Trace, > gc, scavenge)" like the logging in line 288. > > Carsten > > On Thu, Sep 29, 2016 at 8:00 AM, Hiroshi H Horii > wrote: > > Hi all, > > Can I please request reviews for a change for 8154736 that improve > copy_to_survivor performance of ppc64 and aarch64? > If possible, I would like to include this change into jdk9. > > 8154736 includes two changes, cmpxchg and copy_to_suvivor, and the > former > was resolved as 8155949. > Now, I would like to ask a review for the remaining, copy_to_suvivor > change. > > webrev: > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/ > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8154736 > > > I tested this change with SPECjbb2013. Also, I re-check that relaxed > cmpxchg is available for changing forwarding pointers. However, because > this change is sensitive, we need more reviews not only from > compiler-dev, > but also from gc-dev. > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > > > > From: David Holmes > > To: "Doerr, Martin" >, Hiroshi H > Horii/Japan/IBM at IBMJP > Cc: Tim Ellison >, > "ppc-aix-port-dev at openjdk.java.net > " > >, > "hotspot-gc-dev at openjdk.java.net > " > >, > "hotspot-runtime-dev at openjdk.java.net > " > > > Date: 05/10/2016 19:31 > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > > > On 10/05/2016 7:41 PM, Doerr, Martin wrote: > > Hi David, > > > > thank you very much for testing the other platforms. > > > > Here's an updated webrev: > > http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/ > > > Thanks. Second test run on its way. > > David > ----- > > > Best regards, > > Martin > > > > -----Original Message----- > > From: hotspot-runtime-dev [ > mailto:hotspot-runtime-dev-bounces at openjdk.java.net > ] On Behalf Of > David > Holmes > > Sent: Dienstag, 10. Mai 2016 11:11 > > To: Hiroshi H Horii > > > Cc: Tim Ellison >; > ppc-aix-port-dev at openjdk.java.net > ; > hotspot-gc-dev at openjdk.java.net > ; > hotspot-runtime-dev at openjdk.java.net > > > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > > > The fix seems incomplete for solaris: > > > > make/Main.gmk:232: recipe for target 'hotspot' failed > > > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp", > > line 124: Error: Too many arguments in call to > > "_Atomic_cmpxchg_long(long, volatile long*, long)". > > > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp", > > line 128: Error: Too many arguments in call to > > "_Atomic_cmpxchg_long(long, volatile long*, long)". > > > > David > > > > On 10/05/2016 5:34 PM, David Holmes wrote: > >> Hi Hiroshi, > >> > >> On 6/05/2016 8:11 PM, Hiroshi H Horii wrote: > >>> Hi David, > >>> > >>> Thank you for your comments. > >>> > >>> As Martin suggested me, I would like to separate this proposal to > >>> - relaxing memory order of cmpxchg > >>> - improvement of copy_to_survivior with relaxed cmpxchg > >>> and discuss the former first. > >>> > >>> Martin thankfully created a new webrev that include a change of > cmpxchg. > >>> > http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.00/ > > >>> He has already tested it with AIX, linuxx86_64, linuxppc64le and > >>> darwinintel64. > >>> (Please tell me if I need to send a new mail for this PFR) > >> > >> Please do as it will be simpler to track that way. > >> > >>>> What I would prefer to see is an additional memory_order value > (such > as > >>>> memory_order_ignored) which is the default for all methods declared > to > >>>> take a memory_order parameter. > >>> > >>> We added simple enum to specify memory order in atomic.hpp as > follows. > >>> > >>> typedef enum cmpxchg_cmpxchg_memory_order { > >>> memory_order_relaxed, > >>> memory_order_conservative > >>> } cmpxchg_memory_order; > >>> > >>> All of cmpxchg functions have an argument of cmpxchg_memory_order > >>> with a default value memory_order_conservative that uses the same > >>> semantics with the existing cmpxchg and requires no change for the > >>> existing > >>> callers. If you think "memory_order_ignored" is better than > >>> "memory_order_conservative", I will be happy to modify this change. > >>> (I just thought, "ignored" may resemble "relaxed" and may make > >>> people who are familiar with C++11's memory semantics confused. > >>> I would like to know thoughts of native speakers.) > >> > >> That is fine by me. I don't think "ignored" would be confused with > >> "relaxed", but "conservative" is fine. > >> > >> I will run the patch through our internal build system while you > prepare > >> the updated RFR. My only concern is "unused argument" warnings > from the > >> compiler. :) > >> > >> We are quickly running into a hard deadline with Feature Complete > >> however - possibly less than 24 hours - for hotspot changes. If this > >> doesn't get in in time I will see if I can shepherd it through the > >> approval process. > >> > >> Thanks, > >> David > >> > >> > >>> Regards, > >>> Hiroshi > >>> ----------------------- > >>> Hiroshi Horii, Ph.D. > >>> IBM Research - Tokyo > >>> > >>> > >>> David Holmes > wrote on 05/04/2016 14:55:29: > >>> > >>>> From: David Holmes > > >>>> To: Hiroshi H Horii/Japan/IBM at IBMJP > >>>> Cc: hotspot-gc-dev at openjdk.java.net > , hotspot-runtime- > >>>> dev at openjdk.java.net , > ppc-aix-port-dev at openjdk.java.net > , Tim Ellison > >>>> >, > Volker Simonis >, > >>>> "Doerr, Martin" >, "Lindenmaier, Goetz" > >>>> > > >>>> Date: 05/04/2016 14:57 > >>>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > >>>> copy_to_survivor for ppc64 > >>>> > >>>> Hi Hiroshi, > >>>> > >>>> Sorry for the delay on getting back to this. > >>>> > >>>> On 25/04/2016 5:09 PM, Hiroshi H Horii wrote: > >>>>> Hi David, > >>>>> > >>>>> Thank you for your comments and questions. > >>>>> > >>>>>> 1. Are the current cmpxchg semantics exactly the same as > >>>>>> memory_order_seq_cst? > >>>>> > >>>>> This is very good question.. > >>>>> > >>>>> I guess, cmpxchg needs a more conservative constraint for memory > >>> ordering > >>>>> than C++11, to add sync after a compare-and-exchange operation. > >>>>> > >>>>> Could someone give comments or thoughts? > >>>> > >>>> I don't want to comment on the comparison with C++11. What I would > >>>> prefer to see is an additional memory_order value (such as > >>>> memory_order_ignored) which is the default for all methods declared > to > >>>> take a memory_order parameter. That way existing > implementations are > >>>> clearly ignoring the memory_order attribute and there is no > potential > >>>> for confusion as to whether the existing implementations equate to > >>>> memory_order_seq_cst or not. > >>>> > >>>> That said, I'm not sure it makes sense to add the memory_order > parameter > >>>> to all methods with "cas" in their name, e.g. > oopDesc::cas_set_mark, > >>>> oopDesc::cas_forward_to, unless those methods can sensibly be > called > >>>> with any value for memory_order - which seems highly unlikely. > Perhaps > >>>> those methods should identify the weakest form of memory_order they > >>>> support and that should be hard-wired into them? > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> memory_order_seq_cst is defined as > >>>>> "Any operation with this memory order is both an acquire > >>> operation and > >>>>> a release operation, plus a single total order exists in > which > >>>> all > >>>>> threads > >>>>> observe all modifications (see below) in the same order." > >>>>> (http://en.cppreference.com/w/cpp/atomic/memory_order > ) > >>>>> > >>>>> In my environment, g++ and xlc generate following assemblies on > >>>> ppc64le. > >>>>> (interestingly, they generates the same assemblies for any > >>>> memory_order) > >>>>> > >>>>> g++ (4.9.2) > >>>>> 100008a4: ac 04 00 7c sync > >>>>> 100008a8: 28 50 20 7d lwarx r9,0,r10 > >>>>> 100008ac: 00 18 09 7c cmpw r9,r3 > >>>>> 100008b0: 0c 00 c2 40 bne- 100008bc > >>>>> 100008b4: 2d 51 80 7c stwcx. r4,0,r10 > >>>>> 100008b8: f0 ff c2 40 bne- 100008a8 > >>>>> 100008bc: 2c 01 00 4c isync > >>>>> > >>>>> xlc (13.1.3) > >>>>> 10000888: ac 04 00 7c sync > >>>>> 1000088c: 28 28 c0 7c lwarx r6,0,r5 > >>>>> 10000890: 40 00 26 7c cmpld r6,r0 > >>>>> 10000894: 0c 00 82 40 bne 100008a0 > >>>>> 10000898: 2d 29 80 7c stwcx. r4,0,r5 > >>>>> 1000089c: f0 ff e2 40 bne+ 1000088c > >>>>> 100008a0: 2c 01 00 4c isync > >>>>> > >>>>> On the other hand, the current OpenJDK generates following > assemblies. > >>>>> > >>>>> 508: ac 04 00 7c sync > >>>>> 50c: 00 00 5c e9 ld r10,0(r28) > >>>>> 510: 00 50 3b 7c cmpd r27,r10 > >>>>> 514: 1c 00 c2 40 bne- 530 > >>>>> 518: a8 40 5c 7d ldarx r10,r28,r8 > >>>>> 51c: 00 50 3b 7c cmpd r27,r10 > >>>>> 520: 10 00 c2 40 bne- 530 > >>>>> 524: ad 41 3c 7d stdcx. r9,r28,r8 > >>>>> 528: f0 ff c2 40 bne- 518 > >>>>> 52c: ac 04 00 7c sync > >>>>> 530: 00 50 bb 7f ... > >>>>> > >>>>> Though we can ignore 50c-514 (because they are a duplicated guard > >>>>> condition), > >>>>> the last sync instruction (52c) makes cmpxchg more strict than > >>>>> memory_order_seq_cst. > >>>>> > >>>>> In some cases, the last sync is necessary when this thread must be > >>>> able > >>>>> to read > >>>>> all of the changes in the other threads while executing from > 508 to > >>>> 530 > >>>>> (that processes compare-and-exchange). > >>>>> > >>>>>> 2. Has there been a discussion already, establishing that the > >>>> modified > >>>>>> GC code can indeed use memory_order_relaxed? Otherwise who is > >>>>>> postulating that and based on what evidence? > >>>>> > >>>>> Volker and his colleagues have investigated the current GC codes > >>>>> according to this. > >>>>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > > >>>> April/019079.html > >>>>> However, I believe, we need comments of other GC experts to change > >>>>> the shared codes. > >>>>> > >>>>> Regards, > >>>>> Hiroshi > >>>>> ----------------------- > >>>>> Hiroshi Horii, Ph.D. > >>>>> IBM Research - Tokyo > >>>>> > >>>>> > >>>>> David Holmes > wrote on 04/22/2016 21:57:07: > >>>>> > >>>>>> From: David Holmes > > >>>>>> To: Hiroshi H Horii/Japan/IBM at IBMJP, hotspot-runtime- > >>>>>> dev at openjdk.java.net , > hotspot-gc-dev at openjdk.java.net > >>>>>> Cc: Tim Ellison >, > >>>>> ppc-aix-port-dev at openjdk.java.net > > >>>>>> Date: 04/22/2016 21:58 > >>>>>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > >>>>>> copy_to_survivor for ppc64 > >>>>>> > >>>>>> Hi Hiroshi, > >>>>>> > >>>>>> Two initial questions: > >>>>>> > >>>>>> 1. Are the current cmpxchg semantics exactly the same as > >>>>>> memory_order_seq_cst? > >>>>>> > >>>>>> 2. Has there been a discussion already, establishing that the > >>>> modified > >>>>>> GC code can indeed use memory_order_relaxed? Otherwise who is > >>>>>> postulating that and based on what evidence? > >>>>>> > >>>>>> Missing memory barriers have caused very difficult to track down > >>> bugs in > >>>>>> the past - very rare race conditions. So any relaxation here has > >>>> to be > >>>>>> done with extreme confidence. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>> On 22/04/2016 10:28 PM, Hiroshi H Horii wrote: > >>>>>>> Dear all: > >>>>>>> > >>>>>>> Can I please request reviews for the following change? > >>>>>>> > >>>>>>> Code change: > >>>>>>> > >>> > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ > > >>>>>>> (I initially created and Martin enhanced so much) > >>>>>>> > >>>>>>> This change follows the discussion started from this mail. > >>>>>>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > > >>>>>> April/018960.html > >>>>>>> > >>>>>>> Description: > >>>>>>> This change provides relaxed compare-and-exchange by introducing > >>>>>>> similar semantics of C++ atomic memory operators, enum > >>>> memory_order. > >>>>>>> As described in atomic_linux_ppc.inline.hpp, the current > >>>>> implementation of > >>>>>>> cmpxchg is fence_cmpxchg_acquire. This implementation is useful > for > >>>>>>> general purposes because twice calls of sync before and after > >>>>> cmpxchg will > >>>>>>> provide strict consistency. However, they sometimes cause > overheads > >>>>>>> because > >>>>>>> sync instructions are very expensive in the current POWER chip > >>> design. > >>>>>>> In addition, for the other platforms, such as aarch64, this > strict > >>>>>>> semantics > >>>>>>> may cause some overheads (according to the Andrew's mail). > >>>>>>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > > >>>>>> April/019073.html > >>>>>>> > >>>>>>> With this change, callers can explicitly specify constraints of > >>> memory > >>>>>>> ordering > >>>>>>> for cmpxchg with an additional parameter, memory_order order. > >>>>>>> > >>>>>>> typedef enum memory_order { > >>>>>>> memory_order_relaxed, > >>>>>>> memory_order_consume, > >>>>>>> memory_order_acquire, > >>>>>>> memory_order_release, > >>>>>>> memory_order_acq_rel, > >>>>>>> memory_order_seq_cst > >>>>>>> } memory_order; > >>>>>>> > >>>>>>> Because the default value of the parameter is > memory_order_seq_cst, > >>>>>>> existing codes can use the same semantics of cmpxchg without any > >>>>>>> modification. The relaxed cmpxchg is implemented only on ppc > >>>>>>> in this changeset. Therefore, the behavior on the other > platforms > >>> will > >>>>>>> not be changed with this changeset. > >>>>>>> > >>>>>>> In addition, with the new parameter of cmpxchg, this change > >>>> improves > >>>>>>> performance of copy_to_survivor in the parallel GC. > >>>>>>> copy_to_survivor changes forward pointers by using cmpxchg. This > >>>>>>> operation doesn't require any sync instructions. A pointer is > >>> changed > >>>>>>> at most once in a GC and when cmpxchg fails, the latest > pointer is > >>>>>>> available for the caller. cas_set_mark and cas_forward_to are > >>> extended > >>>>>>> with an additional memory_order parameter as cmpxchg and > >>>>> copy_to_survivor > >>>>>>> uses memory_order_relaxed to modify the forward pointers. > >>>>>>> > >>>>>>> Summary of source code changes: > >>>>>>> > >>>>>>> * src/share/vm/runtime/atomic.hpp > >>>>>>> - Defines enum memory_order and adds a parameter to > cmpxchg. > >>>>>>> > >>>>>>> * src/share/vm/runtime/atomic.cpp > >>>>>>> * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp > >>>>>>> * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > >>>>>>> * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp > >>>>>>> * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp > >>>>>>> * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp > >>>>>>> * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > >>>>>>> * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp > >>>>>>> * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp > >>>>>>> * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp > >>>>>>> - Added a parameter for each cmpxchg function to follow > >>>>>>> the change of atomic.hpp. Their implementations are not > >>>>> changed. > >>>>>>> > >>>>>>> * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp > >>>>>>> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > >>>>>>> - Added a parameter for each cmpxchg function to follow > >>>>>>> the change of atomic.hpp. In addition, implementations > >>>>>>> are changed corresponding to the specified > memory_order. > >>>>>>> > >>>>>>> * src/share/vm/oops/oop.hpp > >>>>>>> * src/share/vm/oops/oop.inline.hpp > >>>>>>> - Add a memory_order parameter to use relaxed cmpxchg in > >>>>>>> cas_set_mark and cas_forward_to. > >>>>>>> > >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.cpp > >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.inline.hpp > >>>>>>> > >>>>>>> Martin tested this changeset on linuxx86_64, linuxppc64le and > >>>>>>> darwinintel64. > >>>>>>> Though more time is needed to test on the other platform, we > would > >>>>> like to > >>>>>>> ask > >>>>>>> reviews and start discussion on this changeset. > >>>>>>> I also tested this changeset with SPECjbb2013 and confirmed that > gc > >>>>> pause > >>>>>>> time > >>>>>>> is reduced. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Hiroshi > >>>>>>> ----------------------- > >>>>>>> Hiroshi Horii, Ph.D. > >>>>>>> IBM Research - Tokyo > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > > > > > > From HORII at jp.ibm.com Fri Sep 30 10:17:05 2016 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Fri, 30 Sep 2016 10:17:05 +0000 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> <571A1FA3.9030006@oracle.com> <201604250709.u3P79jwN024101@d19av07.sagamino.japan.ibm.com> <1574d9e7-c9cd-b1e8-e9a1-d63630713724@oracle.com> <201605061011.u46ABZDR015108@d19av07.sagamino.japan.ibm.com> <848a70ad-00b3-b742-fa4e-87dc0124e0e3@oracle.com> <347b1733-fbbc-b65b-5417-7be52a0b5d68@oracle.com> <0e47ed4857d94f9bbd99b0738bf1708a@DEWDFE13DE14.global.corp.sap> Message-ID: Dear David, and Dan, Thank you for your comments. > In hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp: > 266 the log line reads data from the forwardee even when the CAS > fails. I believe those reads will be unsafe without barriers after > the copy of the content of the object. > hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:288 > same problem as in line 266 Can we use o->size() or new_obj_size instead of new_obj->size()? > If you feel that the use of new_obj->size() is potentially unsafe then > the fact we return new_obj means that any use of new_obj by the caller > may also potentially be unsafe. In my understanding, while copying objects to a survivor space, if a thread creates a new_obj and sets a pointer with CAS, the other threads can touch the new_obj after the thread calls push_contents(new_obj) (Line: 239). In push_contents, OrderAccess::release_store is called before pushing the object as a task into a deque of workstealing (taskqueue.inline.hpp). If the other thread reads the task, all of copy for new_obj is safe. Thank you for your helps again. I may be misunderstanding or missing something critical. Any comments and claims are always appreciated. Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo David Holmes wrote on 09/30/2016 07:16:16: > From: David Holmes > To: Carsten Varming , Hiroshi H Horii/Japan/IBM at IBMJP > Cc: Tim Ellison , "ppc-aix-port- > dev at openjdk.java.net" , "hotspot- > runtime-dev at openjdk.java.net" dev at openjdk.java.net>, "hotspot-gc-dev at openjdk.java.net" gc-dev at openjdk.java.net>, hotspot-compiler-dev dev-bounces at openjdk.java.net> > Date: 09/30/2016 07:17 > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > On 30/09/2016 12:47 AM, Carsten Varming wrote: > > Dear Hiroshi, > > > > In hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:266 > > the log line reads data from the forwardee even when the CAS fails. I > > believe those reads will be unsafe without barriers after the copy of > > the content of the object. > > I find it extremely hard to reason about a barrier-less cmpxchg in general. > > If you feel that the use of new_obj->size() is potentially unsafe then > the fact we return new_obj means that any use of new_obj by the caller > may also potentially be unsafe. > > David > ----- > > > hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:288 same > > problem as in line 266 > > > > I would argue that the logging should only happen if the thread > > successfully copied the object and CAS failures should be logged > > separately without reading data from the forwardee. > > > > BTW, unrelated to your change: It seems like the logging in line 266 > > should be guarded by something like "if (log_develop_is_enabled(Trace, > > gc, scavenge)" like the logging in line 288. > > > > Carsten > > > > On Thu, Sep 29, 2016 at 8:00 AM, Hiroshi H Horii > > wrote: > > > > Hi all, > > > > Can I please request reviews for a change for 8154736 that improve > > copy_to_survivor performance of ppc64 and aarch64? > > If possible, I would like to include this change into jdk9. > > > > 8154736 includes two changes, cmpxchg and copy_to_suvivor, and the > > former > > was resolved as 8155949. > > Now, I would like to ask a review for the remaining, copy_to_suvivor > > change. > > > > webrev: > > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/ > > < http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/> > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8154736 > > > > > > I tested this change with SPECjbb2013. Also, I re-check that relaxed > > cmpxchg is available for changing forwarding pointers. However, because > > this change is sensitive, we need more reviews not only from > > compiler-dev, > > but also from gc-dev. > > > > Regards, > > Hiroshi > > ----------------------- > > Hiroshi Horii, Ph.D. > > IBM Research - Tokyo > > > > > > > > > > From: David Holmes > > > > To: "Doerr, Martin" > >, Hiroshi H > > Horii/Japan/IBM at IBMJP > > Cc: Tim Ellison > >, > > "ppc-aix-port-dev at openjdk.java.net > > " > > > >, > > "hotspot-gc-dev at openjdk.java.net > > " > > > >, > > "hotspot-runtime-dev at openjdk.java.net > > " > > > > > > Date: 05/10/2016 19:31 > > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > > copy_to_survivor for ppc64 > > > > > > > > On 10/05/2016 7:41 PM, Doerr, Martin wrote: > > > Hi David, > > > > > > thank you very much for testing the other platforms. > > > > > > Here's an updated webrev: > > > http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/ > > > > > > Thanks. Second test run on its way. > > > > David > > ----- > > > > > Best regards, > > > Martin > > > > > > -----Original Message----- > > > From: hotspot-runtime-dev [ > > mailto:hotspot-runtime-dev-bounces at openjdk.java.net > > ] On Behalf Of > > David > > Holmes > > > Sent: Dienstag, 10. Mai 2016 11:11 > > > To: Hiroshi H Horii > > > > Cc: Tim Ellison > >; > > ppc-aix-port-dev at openjdk.java.net > > ; > > hotspot-gc-dev at openjdk.java.net > > ; > > hotspot-runtime-dev at openjdk.java.net > > > > > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > > copy_to_survivor for ppc64 > > > > > > The fix seems incomplete for solaris: > > > > > > make/Main.gmk:232: recipe for target 'hotspot' failed > > > > > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/ > solaris_x86/vm/atomic_solaris_x86.inline.hpp", > > > line 124: Error: Too many arguments in call to > > > "_Atomic_cmpxchg_long(long, volatile long*, long)". > > > > > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/ > solaris_x86/vm/atomic_solaris_x86.inline.hpp", > > > line 128: Error: Too many arguments in call to > > > "_Atomic_cmpxchg_long(long, volatile long*, long)". > > > > > > David > > > > > > On 10/05/2016 5:34 PM, David Holmes wrote: > > >> Hi Hiroshi, > > >> > > >> On 6/05/2016 8:11 PM, Hiroshi H Horii wrote: > > >>> Hi David, > > >>> > > >>> Thank you for your comments. > > >>> > > >>> As Martin suggested me, I would like to separate this proposal to > > >>> - relaxing memory order of cmpxchg > > >>> - improvement of copy_to_survivior with relaxed cmpxchg > > >>> and discuss the former first. > > >>> > > >>> Martin thankfully created a new webrev that include a change of > > cmpxchg. > > >>> > > http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.00/ > > > > >>> He has already tested it with AIX, linuxx86_64, linuxppc64le and > > >>> darwinintel64. > > >>> (Please tell me if I need to send a new mail for this PFR) > > >> > > >> Please do as it will be simpler to track that way. > > >> > > >>>> What I would prefer to see is an additional memory_order value > > (such > > as > > >>>> memory_order_ignored) which is the default for all methods declared > > to > > >>>> take a memory_order parameter. > > >>> > > >>> We added simple enum to specify memory order in atomic.hpp as > > follows. > > >>> > > >>> typedef enum cmpxchg_cmpxchg_memory_order { > > >>> memory_order_relaxed, > > >>> memory_order_conservative > > >>> } cmpxchg_memory_order; > > >>> > > >>> All of cmpxchg functions have an argument of cmpxchg_memory_order > > >>> with a default value memory_order_conservative that uses the same > > >>> semantics with the existing cmpxchg and requires no change for the > > >>> existing > > >>> callers. If you think "memory_order_ignored" is better than > > >>> "memory_order_conservative", I will be happy to modify this change. > > >>> (I just thought, "ignored" may resemble "relaxed" and may make > > >>> people who are familiar with C++11's memory semantics confused. > > >>> I would like to know thoughts of native speakers.) > > >> > > >> That is fine by me. I don't think "ignored" would be confused with > > >> "relaxed", but "conservative" is fine. > > >> > > >> I will run the patch through our internal build system while you > > prepare > > >> the updated RFR. My only concern is "unused argument" warnings > > from the > > >> compiler. :) > > >> > > >> We are quickly running into a hard deadline with Feature Complete > > >> however - possibly less than 24 hours - for hotspot changes. If this > > >> doesn't get in in time I will see if I can shepherd it through the > > >> approval process. > > >> > > >> Thanks, > > >> David > > >> > > >> > > >>> Regards, > > >>> Hiroshi > > >>> ----------------------- > > >>> Hiroshi Horii, Ph.D. > > >>> IBM Research - Tokyo > > >>> > > >>> > > >>> David Holmes > > wrote on 05/04/2016 14:55:29: > > >>> > > >>>> From: David Holmes > > > > >>>> To: Hiroshi H Horii/Japan/IBM at IBMJP > > >>>> Cc: hotspot-gc-dev at openjdk.java.net > > , hotspot-runtime- > > >>>> dev at openjdk.java.net , > > ppc-aix-port-dev at openjdk.java.net > > , Tim Ellison > > >>>> >, > > Volker Simonis > >, > > >>>> "Doerr, Martin" > >, "Lindenmaier, Goetz" > > >>>> > > > >>>> Date: 05/04/2016 14:57 > > >>>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > > >>>> copy_to_survivor for ppc64 > > >>>> > > >>>> Hi Hiroshi, > > >>>> > > >>>> Sorry for the delay on getting back to this. > > >>>> > > >>>> On 25/04/2016 5:09 PM, Hiroshi H Horii wrote: > > >>>>> Hi David, > > >>>>> > > >>>>> Thank you for your comments and questions. > > >>>>> > > >>>>>> 1. Are the current cmpxchg semantics exactly the same as > > >>>>>> memory_order_seq_cst? > > >>>>> > > >>>>> This is very good question.. > > >>>>> > > >>>>> I guess, cmpxchg needs a more conservative constraint for memory > > >>> ordering > > >>>>> than C++11, to add sync after a compare-and-exchange operation. > > >>>>> > > >>>>> Could someone give comments or thoughts? > > >>>> > > >>>> I don't want to comment on the comparison with C++11. What I would > > >>>> prefer to see is an additional memory_order value (such as > > >>>> memory_order_ignored) which is the default for all methods declared > > to > > >>>> take a memory_order parameter. That way existing > > implementations are > > >>>> clearly ignoring the memory_order attribute and there is no > > potential > > >>>> for confusion as to whether the existing implementations equate to > > >>>> memory_order_seq_cst or not. > > >>>> > > >>>> That said, I'm not sure it makes sense to add the memory_order > > parameter > > >>>> to all methods with "cas" in their name, e.g. > > oopDesc::cas_set_mark, > > >>>> oopDesc::cas_forward_to, unless those methods can sensibly be > > called > > >>>> with any value for memory_order - which seems highly unlikely. > > Perhaps > > >>>> those methods should identify the weakest form of memory_order they > > >>>> support and that should be hard-wired into them? > > >>>> > > >>>> Thanks, > > >>>> David > > >>>> > > >>>>> memory_order_seq_cst is defined as > > >>>>> "Any operation with this memory order is both an acquire > > >>> operation and > > >>>>> a release operation, plus a single total order exists in > > which > > >>>> all > > >>>>> threads > > >>>>> observe all modifications (see below) in the same order." > > >>>>> (http://en.cppreference.com/w/cpp/atomic/memory_order > > ) > > >>>>> > > >>>>> In my environment, g++ and xlc generate following assemblies on > > >>>> ppc64le. > > >>>>> (interestingly, they generates the same assemblies for any > > >>>> memory_order) > > >>>>> > > >>>>> g++ (4.9.2) > > >>>>> 100008a4: ac 04 00 7c sync > > >>>>> 100008a8: 28 50 20 7d lwarx r9,0,r10 > > >>>>> 100008ac: 00 18 09 7c cmpw r9,r3 > > >>>>> 100008b0: 0c 00 c2 40 bne- 100008bc > > >>>>> 100008b4: 2d 51 80 7c stwcx. r4,0,r10 > > >>>>> 100008b8: f0 ff c2 40 bne- 100008a8 > > >>>>> 100008bc: 2c 01 00 4c isync > > >>>>> > > >>>>> xlc (13.1.3) > > >>>>> 10000888: ac 04 00 7c sync > > >>>>> 1000088c: 28 28 c0 7c lwarx r6,0,r5 > > >>>>> 10000890: 40 00 26 7c cmpld r6,r0 > > >>>>> 10000894: 0c 00 82 40 bne 100008a0 > > >>>>> 10000898: 2d 29 80 7c stwcx. r4,0,r5 > > >>>>> 1000089c: f0 ff e2 40 bne+ 1000088c > > >>>>> 100008a0: 2c 01 00 4c isync > > >>>>> > > >>>>> On the other hand, the current OpenJDK generates following > > assemblies. > > >>>>> > > >>>>> 508: ac 04 00 7c sync > > >>>>> 50c: 00 00 5c e9 ld r10,0(r28) > > >>>>> 510: 00 50 3b 7c cmpd r27,r10 > > >>>>> 514: 1c 00 c2 40 bne- 530 > > >>>>> 518: a8 40 5c 7d ldarx r10,r28,r8 > > >>>>> 51c: 00 50 3b 7c cmpd r27,r10 > > >>>>> 520: 10 00 c2 40 bne- 530 > > >>>>> 524: ad 41 3c 7d stdcx. r9,r28,r8 > > >>>>> 528: f0 ff c2 40 bne- 518 > > >>>>> 52c: ac 04 00 7c sync > > >>>>> 530: 00 50 bb 7f ... > > >>>>> > > >>>>> Though we can ignore 50c-514 (because they are a duplicated guard > > >>>>> condition), > > >>>>> the last sync instruction (52c) makes cmpxchg more strict than > > >>>>> memory_order_seq_cst. > > >>>>> > > >>>>> In some cases, the last sync is necessary when this thread must be > > >>>> able > > >>>>> to read > > >>>>> all of the changes in the other threads while executing from > > 508 to > > >>>> 530 > > >>>>> (that processes compare-and-exchange). > > >>>>> > > >>>>>> 2. Has there been a discussion already, establishing that the > > >>>> modified > > >>>>>> GC code can indeed use memory_order_relaxed? Otherwise who is > > >>>>>> postulating that and based on what evidence? > > >>>>> > > >>>>> Volker and his colleagues have investigated the current GC codes > > >>>>> according to this. > > >>>>> > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > > > > >>>> April/019079.html > > >>>>> However, I believe, we need comments of other GC expertsto change > > >>>>> the shared codes. > > >>>>> > > >>>>> Regards, > > >>>>> Hiroshi > > >>>>> ----------------------- > > >>>>> Hiroshi Horii, Ph.D. > > >>>>> IBM Research - Tokyo > > >>>>> > > >>>>> > > >>>>> David Holmes > > wrote on 04/22/2016 21:57:07: > > >>>>> > > >>>>>> From: David Holmes > > > > >>>>>> To: Hiroshi H Horii/Japan/IBM at IBMJP, hotspot-runtime- > > >>>>>> dev at openjdk.java.net , > > hotspot-gc-dev at openjdk.java.net < mailto:hotspot-gc-dev at openjdk.java.net> > > >>>>>> Cc: Tim Ellison > >, > > >>>>> ppc-aix-port-dev at openjdk.java.net > > > > >>>>>> Date: 04/22/2016 21:58 > > >>>>>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > > >>>>>> copy_to_survivor for ppc64 > > >>>>>> > > >>>>>> Hi Hiroshi, > > >>>>>> > > >>>>>> Two initial questions: > > >>>>>> > > >>>>>> 1. Are the current cmpxchg semantics exactly the same as > > >>>>>> memory_order_seq_cst? > > >>>>>> > > >>>>>> 2. Has there been a discussion already, establishing that the > > >>>> modified > > >>>>>> GC code can indeed use memory_order_relaxed? Otherwise who is > > >>>>>> postulating that and based on what evidence? > > >>>>>> > > >>>>>> Missing memory barriers have caused very difficult to track down > > >>> bugs in > > >>>>>> the past - very rare race conditions. So any relaxation here has > > >>>> to be > > >>>>>> done with extreme confidence. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> David > > >>>>>> > > >>>>>> On 22/04/2016 10:28 PM, Hiroshi H Horii wrote: > > >>>>>>> Dear all: > > >>>>>>> > > >>>>>>> Can I please request reviews for the following change? > > >>>>>>> > > >>>>>>> Code change: > > >>>>>>> > > >>> > > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ > > < http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/> > > >>>>>>> (I initially created and Martin enhanced so much) > > >>>>>>> > > >>>>>>> This change follows the discussion started from this mail. > > >>>>>>> > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > > > > >>>>>> April/018960.html > > >>>>>>> > > >>>>>>> Description: > > >>>>>>> This change provides relaxed compare-and-exchange by introducing > > >>>>>>> similar semantics of C++ atomic memory operators, enum > > >>>> memory_order. > > >>>>>>> As described in atomic_linux_ppc.inline.hpp, the current > > >>>>> implementation of > > >>>>>>> cmpxchg is fence_cmpxchg_acquire. This implementation is useful > > for > > >>>>>>> general purposes because twice calls of sync before and after > > >>>>> cmpxchg will > > >>>>>>> provide strict consistency. However, they sometimes cause > > overheads > > >>>>>>> because > > >>>>>>> sync instructions are very expensive in the current POWER chip > > >>> design. > > >>>>>>> In addition, for the other platforms, such as aarch64, this > > strict > > >>>>>>> semantics > > >>>>>>> may cause some overheads (according to the Andrew's mail). > > >>>>>>> > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > > > > >>>>>> April/019073.html > > >>>>>>> > > >>>>>>> With this change, callers can explicitly specify constraints of > > >>> memory > > >>>>>>> ordering > > >>>>>>> for cmpxchg with an additional parameter, memory_order order. > > >>>>>>> > > >>>>>>> typedef enum memory_order { > > >>>>>>> memory_order_relaxed, > > >>>>>>> memory_order_consume, > > >>>>>>> memory_order_acquire, > > >>>>>>> memory_order_release, > > >>>>>>> memory_order_acq_rel, > > >>>>>>> memory_order_seq_cst > > >>>>>>> } memory_order; > > >>>>>>> > > >>>>>>> Because the default value of the parameter is > > memory_order_seq_cst, > > >>>>>>> existing codes can use the same semantics of cmpxchg without any > > >>>>>>> modification. The relaxed cmpxchg is implemented only on ppc > > >>>>>>> in this changeset. Therefore, the behavior on the other > > platforms > > >>> will > > >>>>>>> not be changed with this changeset. > > >>>>>>> > > >>>>>>> In addition, with the new parameter of cmpxchg, this change > > >>>> improves > > >>>>>>> performance of copy_to_survivor in the parallel GC. > > >>>>>>> copy_to_survivor changes forward pointers by using cmpxchg. This > > >>>>>>> operation doesn't require any sync instructions. A pointer is > > >>> changed > > >>>>>>> at most once in a GC and when cmpxchg fails, the latest > > pointer is > > >>>>>>> available for the caller. cas_set_mark and cas_forward_to are > > >>> extended > > >>>>>>> with an additional memory_order parameter as cmpxchg and > > >>>>> copy_to_survivor > > >>>>>>> uses memory_order_relaxed to modify the forward pointers. > > >>>>>>> > > >>>>>>> Summary of source code changes: > > >>>>>>> > > >>>>>>> * src/share/vm/runtime/atomic.hpp > > >>>>>>> - Defines enum memory_order and adds a parameter to > > cmpxchg. > > >>>>>>> > > >>>>>>> * src/share/vm/runtime/atomic.cpp > > >>>>>>> * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp > > >>>>>>> * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > > >>>>>>> * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp > > >>>>>>> * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp > > >>>>>>> * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp > > >>>>>>> * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > > >>>>>>> * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp > > >>>>>>> * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp > > >>>>>>> * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp > > >>>>>>> - Added a parameter for each cmpxchg function to follow > > >>>>>>> the change of atomic.hpp. Their implementations are not > > >>>>> changed. > > >>>>>>> > > >>>>>>> * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp > > >>>>>>> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > > >>>>>>> - Added a parameter for each cmpxchg function to follow > > >>>>>>> the change of atomic.hpp. In addition, implementations > > >>>>>>> are changed corresponding to the specified > > memory_order. > > >>>>>>> > > >>>>>>> * src/share/vm/oops/oop.hpp > > >>>>>>> * src/share/vm/oops/oop.inline.hpp > > >>>>>>> - Add a memory_order parameter to use relaxed cmpxchg in > > >>>>>>> cas_set_mark and cas_forward_to. > > >>>>>>> > > >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.cpp > > >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.inline.hpp > > >>>>>>> > > >>>>>>> Martin tested this changeset on linuxx86_64, linuxppc64le and > > >>>>>>> darwinintel64. > > >>>>>>> Though more time is needed to test on the other platform, we > > would > > >>>>> like to > > >>>>>>> ask > > >>>>>>> reviews and start discussion on this changeset. > > >>>>>>> I also tested this changeset with SPECjbb2013 and confirmed that > > gc > > >>>>> pause > > >>>>>>> time > > >>>>>>> is reduced. > > >>>>>>> > > >>>>>>> Regards, > > >>>>>>> Hiroshi > > >>>>>>> ----------------------- > > >>>>>>> Hiroshi Horii, Ph.D. > > >>>>>>> IBM Research - Tokyo > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Sep 30 11:12:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Sep 2016 21:12:27 +1000 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> <571A1FA3.9030006@oracle.com> <201604250709.u3P79jwN024101@d19av07.sagamino.japan.ibm.com> <1574d9e7-c9cd-b1e8-e9a1-d63630713724@oracle.com> <201605061011.u46ABZDR015108@d19av07.sagamino.japan.ibm.com> <848a70ad-00b3-b742-fa4e-87dc0124e0e3@oracle.com> <347b1733-fbbc-b65b-5417-7be52a0b5d68@oracle.com> <0e47ed4857d94f9bbd99b0738bf1708a@DEWDFE13DE14.global.corp.sap> Message-ID: <1e40040e-b494-6e1e-00a4-dc130954cebd@oracle.com> On 30/09/2016 8:17 PM, Hiroshi H Horii wrote: > Dear David, and Dan, > > Thank you for your comments. > >> In hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp: >> 266 the log line reads data from the forwardee even when the CAS >> fails. I believe those reads will be unsafe without barriers after >> the copy of the content of the object. >> hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:288 >> same problem as in line 266 > > Can we use o->size() or new_obj_size instead of new_obj->size()? > >> If you feel that the use of new_obj->size() is potentially unsafe then >> the fact we return new_obj means that any use of new_obj by the caller >> may also potentially be unsafe. > > In my understanding, while copying objects to a survivor space, if a > thread creates a new_obj and sets a pointer with CAS, the other threads > can touch the new_obj after the thread calls push_contents(new_obj) > (Line: 239). In push_contents, OrderAccess::release_store is called > before pushing the object as a task into a deque of workstealing > (taskqueue.inline.hpp). If the other thread reads the task, all of copy > for new_obj is safe. I'm not familiar with the larger picture of the GC protocols here, but just looking at this code fragment in isolation if the CAS fails we read o->forwardee() to set new_obj. That in itself is fine because we're reading the field that we were testing with the CAS. But we could then deference new_obj before the thread that won the CAS calls push_contents; and even if it is after push_contents we have not done an acquire to pair with the release-store in push_contents. So I'm really not seeing how we can use a barrier-less CAS here. David ----- > > Thank you for your helps again. I may be misunderstanding or missing > something critical. Any comments and claims are always appreciated. > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > > David Holmes wrote on 09/30/2016 07:16:16: > >> From: David Holmes >> To: Carsten Varming , Hiroshi H Horii/Japan/IBM at IBMJP >> Cc: Tim Ellison , "ppc-aix-port- >> dev at openjdk.java.net" , "hotspot- >> runtime-dev at openjdk.java.net" > dev at openjdk.java.net>, "hotspot-gc-dev at openjdk.java.net" > gc-dev at openjdk.java.net>, hotspot-compiler-dev > dev-bounces at openjdk.java.net> >> Date: 09/30/2016 07:17 >> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and >> copy_to_survivor for ppc64 >> >> On 30/09/2016 12:47 AM, Carsten Varming wrote: >> > Dear Hiroshi, >> > >> > In hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:266 >> > the log line reads data from the forwardee even when the CAS fails. I >> > believe those reads will be unsafe without barriers after the copy of >> > the content of the object. >> >> I find it extremely hard to reason about a barrier-less cmpxchg in > general. >> >> If you feel that the use of new_obj->size() is potentially unsafe then >> the fact we return new_obj means that any use of new_obj by the caller >> may also potentially be unsafe. >> >> David >> ----- >> >> > hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:288 same >> > problem as in line 266 >> > >> > I would argue that the logging should only happen if the thread >> > successfully copied the object and CAS failures should be logged >> > separately without reading data from the forwardee. >> > >> > BTW, unrelated to your change: It seems like the logging in line 266 >> > should be guarded by something like "if (log_develop_is_enabled(Trace, >> > gc, scavenge)" like the logging in line 288. >> > >> > Carsten >> > >> > On Thu, Sep 29, 2016 at 8:00 AM, Hiroshi H Horii > > > wrote: >> > >> > Hi all, >> > >> > Can I please request reviews for a change for 8154736 that improve >> > copy_to_survivor performance of ppc64 and aarch64? >> > If possible, I would like to include this change into jdk9. >> > >> > 8154736 includes two changes, cmpxchg and copy_to_suvivor, and the >> > former >> > was resolved as 8155949. >> > Now, I would like to ask a review for the remaining, copy_to_suvivor >> > change. >> > >> > webrev: >> > > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/ >> > > >> > JIRA: https://bugs.openjdk.java.net/browse/JDK-8154736 >> > >> > >> > I tested this change with SPECjbb2013. Also, I re-check that relaxed >> > cmpxchg is available for changing forwarding pointers. However, > because >> > this change is sensitive, we need more reviews not only from >> > compiler-dev, >> > but also from gc-dev. >> > >> > Regards, >> > Hiroshi >> > ----------------------- >> > Hiroshi Horii, Ph.D. >> > IBM Research - Tokyo >> > >> > >> > >> > >> > From: David Holmes > > > >> > To: "Doerr, Martin" > > >, Hiroshi H >> > Horii/Japan/IBM at IBMJP >> > Cc: Tim Ellison > > >, >> > "ppc-aix-port-dev at openjdk.java.net >> > " >> > > > >, >> > "hotspot-gc-dev at openjdk.java.net >> > " >> > > > >, >> > "hotspot-runtime-dev at openjdk.java.net >> > " >> > > > > >> > Date: 05/10/2016 19:31 >> > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and >> > copy_to_survivor for ppc64 >> > >> > >> > >> > On 10/05/2016 7:41 PM, Doerr, Martin wrote: >> > > Hi David, >> > > >> > > thank you very much for testing the other platforms. >> > > >> > > Here's an updated webrev: >> > > http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/ >> > >> > >> > Thanks. Second test run on its way. >> > >> > David >> > ----- >> > >> > > Best regards, >> > > Martin >> > > >> > > -----Original Message----- >> > > From: hotspot-runtime-dev [ >> > mailto:hotspot-runtime-dev-bounces at openjdk.java.net >> > ] On Behalf Of >> > David >> > Holmes >> > > Sent: Dienstag, 10. Mai 2016 11:11 >> > > To: Hiroshi H Horii > >> > > Cc: Tim Ellison > > >; >> > ppc-aix-port-dev at openjdk.java.net >> > ; >> > hotspot-gc-dev at openjdk.java.net >> > ; >> > hotspot-runtime-dev at openjdk.java.net >> > >> > > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and >> > copy_to_survivor for ppc64 >> > > >> > > The fix seems incomplete for solaris: >> > > >> > > make/Main.gmk:232: recipe for target 'hotspot' failed >> > > >> > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/ >> solaris_x86/vm/atomic_solaris_x86.inline.hpp", >> > > line 124: Error: Too many arguments in call to >> > > "_Atomic_cmpxchg_long(long, volatile long*, long)". >> > > >> > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/ >> solaris_x86/vm/atomic_solaris_x86.inline.hpp", >> > > line 128: Error: Too many arguments in call to >> > > "_Atomic_cmpxchg_long(long, volatile long*, long)". >> > > >> > > David >> > > >> > > On 10/05/2016 5:34 PM, David Holmes wrote: >> > >> Hi Hiroshi, >> > >> >> > >> On 6/05/2016 8:11 PM, Hiroshi H Horii wrote: >> > >>> Hi David, >> > >>> >> > >>> Thank you for your comments. >> > >>> >> > >>> As Martin suggested me, I would like to separate this > proposal to >> > >>> - relaxing memory order of cmpxchg >> > >>> - improvement of copy_to_survivior with relaxed cmpxchg >> > >>> and discuss the former first. >> > >>> >> > >>> Martin thankfully created a new webrev that include a change of >> > cmpxchg. >> > >>> >> > http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.00/ >> > >> > >>> He has already tested it with AIX, linuxx86_64, linuxppc64le and >> > >>> darwinintel64. >> > >>> (Please tell me if I need to send a new mail for this PFR) >> > >> >> > >> Please do as it will be simpler to track that way. >> > >> >> > >>>> What I would prefer to see is an additional memory_order value >> > (such >> > as >> > >>>> memory_order_ignored) which is the default for all methods > declared >> > to >> > >>>> take a memory_order parameter. >> > >>> >> > >>> We added simple enum to specify memory order in atomic.hpp as >> > follows. >> > >>> >> > >>> typedef enum cmpxchg_cmpxchg_memory_order { >> > >>> memory_order_relaxed, >> > >>> memory_order_conservative >> > >>> } cmpxchg_memory_order; >> > >>> >> > >>> All of cmpxchg functions have an argument of > cmpxchg_memory_order >> > >>> with a default value memory_order_conservative that uses the > same >> > >>> semantics with the existing cmpxchg and requires no change > for the >> > >>> existing >> > >>> callers. If you think "memory_order_ignored" is better than >> > >>> "memory_order_conservative", I will be happy to modify this > change. >> > >>> (I just thought, "ignored" may resemble "relaxed" and may make >> > >>> people who are familiar with C++11's memory semantics confused. >> > >>> I would like to know thoughts of native speakers.) >> > >> >> > >> That is fine by me. I don't think "ignored" would be confused > with >> > >> "relaxed", but "conservative" is fine. >> > >> >> > >> I will run the patch through our internal build system while you >> > prepare >> > >> the updated RFR. My only concern is "unused argument" warnings >> > from the >> > >> compiler. :) >> > >> >> > >> We are quickly running into a hard deadline with Feature Complete >> > >> however - possibly less than 24 hours - for hotspot changes. > If this >> > >> doesn't get in in time I will see if I can shepherd it > through the >> > >> approval process. >> > >> >> > >> Thanks, >> > >> David >> > >> >> > >> >> > >>> Regards, >> > >>> Hiroshi >> > >>> ----------------------- >> > >>> Hiroshi Horii, Ph.D. >> > >>> IBM Research - Tokyo >> > >>> >> > >>> >> > >>> David Holmes > > > wrote on 05/04/2016 14:55:29: >> > >>> >> > >>>> From: David Holmes > > > >> > >>>> To: Hiroshi H Horii/Japan/IBM at IBMJP >> > >>>> Cc: hotspot-gc-dev at openjdk.java.net >> > , hotspot-runtime- >> > >>>> dev at openjdk.java.net , >> > ppc-aix-port-dev at openjdk.java.net >> > , Tim Ellison >> > >>>> >, >> > Volker Simonis > > >, >> > >>>> "Doerr, Martin" > > >, "Lindenmaier, Goetz" >> > >>>> > >> > >>>> Date: 05/04/2016 14:57 >> > >>>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and >> > >>>> copy_to_survivor for ppc64 >> > >>>> >> > >>>> Hi Hiroshi, >> > >>>> >> > >>>> Sorry for the delay on getting back to this. >> > >>>> >> > >>>> On 25/04/2016 5:09 PM, Hiroshi H Horii wrote: >> > >>>>> Hi David, >> > >>>>> >> > >>>>> Thank you for your comments and questions. >> > >>>>> >> > >>>>>> 1. Are the current cmpxchg semantics exactly the same as >> > >>>>>> memory_order_seq_cst? >> > >>>>> >> > >>>>> This is very good question.. >> > >>>>> >> > >>>>> I guess, cmpxchg needs a more conservative constraint for > memory >> > >>> ordering >> > >>>>> than C++11, to add sync after a compare-and-exchange > operation. >> > >>>>> >> > >>>>> Could someone give comments or thoughts? >> > >>>> >> > >>>> I don't want to comment on the comparison with C++11. What > I would >> > >>>> prefer to see is an additional memory_order value (such as >> > >>>> memory_order_ignored) which is the default for all methods > declared >> > to >> > >>>> take a memory_order parameter. That way existing >> > implementations are >> > >>>> clearly ignoring the memory_order attribute and there is no >> > potential >> > >>>> for confusion as to whether the existing implementations > equate to >> > >>>> memory_order_seq_cst or not. >> > >>>> >> > >>>> That said, I'm not sure it makes sense to add the memory_order >> > parameter >> > >>>> to all methods with "cas" in their name, e.g. >> > oopDesc::cas_set_mark, >> > >>>> oopDesc::cas_forward_to, unless those methods can sensibly be >> > called >> > >>>> with any value for memory_order - which seems highly unlikely. >> > Perhaps >> > >>>> those methods should identify the weakest form of > memory_order they >> > >>>> support and that should be hard-wired into them? >> > >>>> >> > >>>> Thanks, >> > >>>> David >> > >>>> >> > >>>>> memory_order_seq_cst is defined as >> > >>>>> "Any operation with this memory order is both an acquire >> > >>> operation and >> > >>>>> a release operation, plus a single total order exists in >> > which >> > >>>> all >> > >>>>> threads >> > >>>>> observe all modifications (see below) in the same order." >> > >>>>> (http://en.cppreference.com/w/cpp/atomic/memory_order >> > ) >> > >>>>> >> > >>>>> In my environment, g++ and xlc generate following > assemblies on >> > >>>> ppc64le. >> > >>>>> (interestingly, they generates the same assemblies for any >> > >>>> memory_order) >> > >>>>> >> > >>>>> g++ (4.9.2) >> > >>>>> 100008a4: ac 04 00 7c sync >> > >>>>> 100008a8: 28 50 20 7d lwarx r9,0,r10 >> > >>>>> 100008ac: 00 18 09 7c cmpw r9,r3 >> > >>>>> 100008b0: 0c 00 c2 40 bne- 100008bc >> > >>>>> 100008b4: 2d 51 80 7c stwcx. r4,0,r10 >> > >>>>> 100008b8: f0 ff c2 40 bne- 100008a8 >> > >>>>> 100008bc: 2c 01 00 4c isync >> > >>>>> >> > >>>>> xlc (13.1.3) >> > >>>>> 10000888: ac 04 00 7c sync >> > >>>>> 1000088c: 28 28 c0 7c lwarx r6,0,r5 >> > >>>>> 10000890: 40 00 26 7c cmpld r6,r0 >> > >>>>> 10000894: 0c 00 82 40 bne 100008a0 >> > >>>>> 10000898: 2d 29 80 7c stwcx. r4,0,r5 >> > >>>>> 1000089c: f0 ff e2 40 bne+ 1000088c >> > >>>>> 100008a0: 2c 01 00 4c isync >> > >>>>> >> > >>>>> On the other hand, the current OpenJDK generates following >> > assemblies. >> > >>>>> >> > >>>>> 508: ac 04 00 7c sync >> > >>>>> 50c: 00 00 5c e9 ld r10,0(r28) >> > >>>>> 510: 00 50 3b 7c cmpd r27,r10 >> > >>>>> 514: 1c 00 c2 40 bne- 530 >> > >>>>> 518: a8 40 5c 7d ldarx r10,r28,r8 >> > >>>>> 51c: 00 50 3b 7c cmpd r27,r10 >> > >>>>> 520: 10 00 c2 40 bne- 530 >> > >>>>> 524: ad 41 3c 7d stdcx. r9,r28,r8 >> > >>>>> 528: f0 ff c2 40 bne- 518 >> > >>>>> 52c: ac 04 00 7c sync >> > >>>>> 530: 00 50 bb 7f ... >> > >>>>> >> > >>>>> Though we can ignore 50c-514 (because they are a > duplicated guard >> > >>>>> condition), >> > >>>>> the last sync instruction (52c) makes cmpxchg more strict than >> > >>>>> memory_order_seq_cst. >> > >>>>> >> > >>>>> In some cases, the last sync is necessary when this thread > must be >> > >>>> able >> > >>>>> to read >> > >>>>> all of the changes in the other threads while executing from >> > 508 to >> > >>>> 530 >> > >>>>> (that processes compare-and-exchange). >> > >>>>> >> > >>>>>> 2. Has there been a discussion already, establishing that the >> > >>>> modified >> > >>>>>> GC code can indeed use memory_order_relaxed? Otherwise who is >> > >>>>>> postulating that and based on what evidence? >> > >>>>> >> > >>>>> Volker and his colleagues have investigated the current GC > codes >> > >>>>> according to this. >> > >>>>> >> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >> > >> > >>>> April/019079.html >> > >>>>> However, I believe, we need comments of other GC expertsto > change >> > >>>>> the shared codes. >> > >>>>> >> > >>>>> Regards, >> > >>>>> Hiroshi >> > >>>>> ----------------------- >> > >>>>> Hiroshi Horii, Ph.D. >> > >>>>> IBM Research - Tokyo >> > >>>>> >> > >>>>> >> > >>>>> David Holmes > > > wrote on 04/22/2016 21:57:07: >> > >>>>> >> > >>>>>> From: David Holmes > > > >> > >>>>>> To: Hiroshi H Horii/Japan/IBM at IBMJP, hotspot-runtime- >> > >>>>>> dev at openjdk.java.net , >> > hotspot-gc-dev at openjdk.java.net > >> > >>>>>> Cc: Tim Ellison > > >, >> > >>>>> ppc-aix-port-dev at openjdk.java.net >> > >> > >>>>>> Date: 04/22/2016 21:58 >> > >>>>>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and >> > >>>>>> copy_to_survivor for ppc64 >> > >>>>>> >> > >>>>>> Hi Hiroshi, >> > >>>>>> >> > >>>>>> Two initial questions: >> > >>>>>> >> > >>>>>> 1. Are the current cmpxchg semantics exactly the same as >> > >>>>>> memory_order_seq_cst? >> > >>>>>> >> > >>>>>> 2. Has there been a discussion already, establishing that the >> > >>>> modified >> > >>>>>> GC code can indeed use memory_order_relaxed? Otherwise who is >> > >>>>>> postulating that and based on what evidence? >> > >>>>>> >> > >>>>>> Missing memory barriers have caused very difficult to > track down >> > >>> bugs in >> > >>>>>> the past - very rare race conditions. So any relaxation > here has >> > >>>> to be >> > >>>>>> done with extreme confidence. >> > >>>>>> >> > >>>>>> Thanks, >> > >>>>>> David >> > >>>>>> >> > >>>>>> On 22/04/2016 10:28 PM, Hiroshi H Horii wrote: >> > >>>>>>> Dear all: >> > >>>>>>> >> > >>>>>>> Can I please request reviews for the following change? >> > >>>>>>> >> > >>>>>>> Code change: >> > >>>>>>> >> > >>> >> > > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ >> > > >> > >>>>>>> (I initially created and Martin enhanced so much) >> > >>>>>>> >> > >>>>>>> This change follows the discussion started from this mail. >> > >>>>>>> >> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >> > >> > >>>>>> April/018960.html >> > >>>>>>> >> > >>>>>>> Description: >> > >>>>>>> This change provides relaxed compare-and-exchange by > introducing >> > >>>>>>> similar semantics of C++ atomic memory operators, enum >> > >>>> memory_order. >> > >>>>>>> As described in atomic_linux_ppc.inline.hpp, the current >> > >>>>> implementation of >> > >>>>>>> cmpxchg is fence_cmpxchg_acquire. This implementation is > useful >> > for >> > >>>>>>> general purposes because twice calls of sync before and > after >> > >>>>> cmpxchg will >> > >>>>>>> provide strict consistency. However, they sometimes cause >> > overheads >> > >>>>>>> because >> > >>>>>>> sync instructions are very expensive in the current > POWER chip >> > >>> design. >> > >>>>>>> In addition, for the other platforms, such as aarch64, this >> > strict >> > >>>>>>> semantics >> > >>>>>>> may cause some overheads (according to the Andrew's mail). >> > >>>>>>> >> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >> > >> > >>>>>> April/019073.html >> > >>>>>>> >> > >>>>>>> With this change, callers can explicitly specify > constraints of >> > >>> memory >> > >>>>>>> ordering >> > >>>>>>> for cmpxchg with an additional parameter, memory_order > order. >> > >>>>>>> >> > >>>>>>> typedef enum memory_order { >> > >>>>>>> memory_order_relaxed, >> > >>>>>>> memory_order_consume, >> > >>>>>>> memory_order_acquire, >> > >>>>>>> memory_order_release, >> > >>>>>>> memory_order_acq_rel, >> > >>>>>>> memory_order_seq_cst >> > >>>>>>> } memory_order; >> > >>>>>>> >> > >>>>>>> Because the default value of the parameter is >> > memory_order_seq_cst, >> > >>>>>>> existing codes can use the same semantics of cmpxchg > without any >> > >>>>>>> modification. The relaxed cmpxchg is implemented only on ppc >> > >>>>>>> in this changeset. Therefore, the behavior on the other >> > platforms >> > >>> will >> > >>>>>>> not be changed with this changeset. >> > >>>>>>> >> > >>>>>>> In addition, with the new parameter of cmpxchg, this change >> > >>>> improves >> > >>>>>>> performance of copy_to_survivor in the parallel GC. >> > >>>>>>> copy_to_survivor changes forward pointers by using > cmpxchg. This >> > >>>>>>> operation doesn't require any sync instructions. A > pointer is >> > >>> changed >> > >>>>>>> at most once in a GC and when cmpxchg fails, the latest >> > pointer is >> > >>>>>>> available for the caller. cas_set_mark and > cas_forward_to are >> > >>> extended >> > >>>>>>> with an additional memory_order parameter as cmpxchg and >> > >>>>> copy_to_survivor >> > >>>>>>> uses memory_order_relaxed to modify the forward pointers. >> > >>>>>>> >> > >>>>>>> Summary of source code changes: >> > >>>>>>> >> > >>>>>>> * src/share/vm/runtime/atomic.hpp >> > >>>>>>> - Defines enum memory_order and adds a parameter to >> > cmpxchg. >> > >>>>>>> >> > >>>>>>> * src/share/vm/runtime/atomic.cpp >> > >>>>>>> * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp >> > >>>>>>> * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp >> > >>>>>>> * > src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp >> > >>>>>>> * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp >> > >>>>>>> * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp >> > >>>>>>> * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp >> > >>>>>>> * > src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp >> > >>>>>>> * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp >> > >>>>>>> * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp >> > >>>>>>> - Added a parameter for each cmpxchg function to > follow >> > >>>>>>> the change of atomic.hpp. Their implementations > are not >> > >>>>> changed. >> > >>>>>>> >> > >>>>>>> * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp >> > >>>>>>> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp >> > >>>>>>> - Added a parameter for each cmpxchg function to > follow >> > >>>>>>> the change of atomic.hpp. In addition, > implementations >> > >>>>>>> are changed corresponding to the specified >> > memory_order. >> > >>>>>>> >> > >>>>>>> * src/share/vm/oops/oop.hpp >> > >>>>>>> * src/share/vm/oops/oop.inline.hpp >> > >>>>>>> - Add a memory_order parameter to use relaxed > cmpxchg in >> > >>>>>>> cas_set_mark and cas_forward_to. >> > >>>>>>> >> > >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.cpp >> > >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.inline.hpp >> > >>>>>>> >> > >>>>>>> Martin tested this changeset on linuxx86_64, > linuxppc64le and >> > >>>>>>> darwinintel64. >> > >>>>>>> Though more time is needed to test on the other platform, we >> > would >> > >>>>> like to >> > >>>>>>> ask >> > >>>>>>> reviews and start discussion on this changeset. >> > >>>>>>> I also tested this changeset with SPECjbb2013 and > confirmed that >> > gc >> > >>>>> pause >> > >>>>>>> time >> > >>>>>>> is reduced. >> > >>>>>>> >> > >>>>>>> Regards, >> > >>>>>>> Hiroshi >> > >>>>>>> ----------------------- >> > >>>>>>> Hiroshi Horii, Ph.D. >> > >>>>>>> IBM Research - Tokyo >> > >>>>>>> >> > >>>>>>> >> > >>>>>> >> > >>>>> >> > >>>> >> > >>> >> > >> > >> > >> > >> > >> > >> > From thomas.schatzl at oracle.com Fri Sep 30 12:02:31 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 30 Sep 2016 14:02:31 +0200 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <1e40040e-b494-6e1e-00a4-dc130954cebd@oracle.com> References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> <571A1FA3.9030006@oracle.com> <201604250709.u3P79jwN024101@d19av07.sagamino.japan.ibm.com> <1574d9e7-c9cd-b1e8-e9a1-d63630713724@oracle.com> <201605061011.u46ABZDR015108@d19av07.sagamino.japan.ibm.com> <848a70ad-00b3-b742-fa4e-87dc0124e0e3@oracle.com> <347b1733-fbbc-b65b-5417-7be52a0b5d68@oracle.com> <0e47ed4857d94f9bbd99b0738bf1708a@DEWDFE13DE14.global.corp.sap> <1e40040e-b494-6e1e-00a4-dc130954cebd@oracle.com> Message-ID: <1475236951.6301.72.camel@oracle.com> Hi, On Fri, 2016-09-30 at 21:12 +1000, David Holmes wrote: > On 30/09/2016 8:17 PM, Hiroshi H Horii wrote: > > > > Dear David, and Dan, > > > > Thank you for your comments. > > > > > > > > In > > > hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp: > > > 266 the log line reads data from the forwardee even when the CAS > > > fails. I believe those reads will be unsafe without barriers > > > after > > > the copy of the content of the object. > > > hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:28 > > > 8 > > > same problem as in line 266 > > Can we use o->size() or new_obj_size instead of new_obj->size()? They are not equivalent. Parallel GC and other collectors creatively reuse the "length" field of objArrays to indicate progress in the scanning them during GC. new_obj_size is the result of a call to o->size() (and the compiler may redo computations at any point), so has the same issue. > > > If you feel that the use of new_obj->size() is potentially unsafe > > > then > > > the fact we return new_obj means that any use of new_obj by the > > > caller > > > may also potentially be unsafe. > > In my understanding, while copying objects to a survivor space, if > > a thread creates a new_obj and sets a pointer with CAS, the other > > threads can touch the new_obj after the thread calls > > push_contents(new_obj) (Line: 239). In push_contents, > > OrderAccess::release_store is called before pushing the object as a > > task into a deque of workstealing (taskqueue.inline.hpp). If the > > other thread reads the task, all of copy for new_obj is safe. > I'm not familiar with the larger picture of the GC protocols here, > but just looking at this code fragment in isolation if the CAS fails > we read o->forwardee() to set new_obj. That in itself is fine because > we're reading the field that we were testing with the CAS. But we > could then deference new_obj before the thread that won the CAS calls > push_contents; and even if it is after push_contents we have not done > an acquire to pair with the release-store in push_contents. I think Hiroshi thinks that since the work stealing itself does a CAS with barrier after obtaining "new_obj" in the other thread, it should be safe (for other threads consuming an object on the task queue). > So I'm really not seeing how we can use a barrier-less CAS here. I also do not think it is safe as is - for example, at least PSPromotionManager::copy_and_push_safe_barrier() reads data from the returned new_obj (in another log message :)) regardless of failure. That method also reads the forwardee if forwarded, and then again uses object information in that same log message. A quick look did not show other issues, but don't count this as a review. Thanks, ? Thomas From HORIE at jp.ibm.com Fri Sep 30 13:30:36 2016 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Fri, 30 Sep 2016 13:30:36 +0000 Subject: RFR:8166684:implement intrinsic code with vector instructions for Unsafe.copyMemory() In-Reply-To: References: , <4c013cabdeeb476f97c427643aef7a1b@DEWDFE13DE14.global.corp.sap> Message-ID: An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Fri Sep 30 16:00:23 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 30 Sep 2016 16:00:23 +0000 Subject: RFR:8166684:implement intrinsic code with vector instructions for Unsafe.copyMemory() In-Reply-To: References: , <4c013cabdeeb476f97c427643aef7a1b@DEWDFE13DE14.global.corp.sap> Message-ID: <690881fb156d4d0a83dc31a01e50b4ec@DEWDFE13DE14.global.corp.sap> Hi Michihiro, thanks for contributing this change. Looks good, now. We will test it. We?ll push it if it gets approved and reviewed. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Freitag, 30. September 2016 15:31 To: Lindenmaier, Goetz Cc: gromero at linux.vnet.ibm.com; Hiroshi H Horii ; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RE: RFR:8166684:implement intrinsic code with vector instructions for Unsafe.copyMemory() Hi Goetz, Martin, Would you review this? The initialization of tmp1 is now outside the loop. JIRA: https://bugs.openjdk.java.net/browse/JDK-8166684 Webrev: http://cr.openjdk.java.net/~horii/8166684/webrev.01/ We created webrev by ourselves, and cced to hotspot-compiler-dev. Best regards, -- Michihiro, IBM Research - Tokyo ----- Original message ----- From: "Lindenmaier, Goetz" > To: "Doerr, Martin" >, Michihiro Horie/Japan/IBM at IBMJP, "Simonis, Volker" >, "ppc-aix-port-dev at openjdk.java.net" > Cc: Hiroshi H Horii/Japan/IBM at IBMJP, Gustavo Romero > Subject: RE: RFR:8166684:implement intrinsic code with vector instructions for Unsafe.copyMemory() Date: Mon, Sep 26, 2016 10:51 PM Hi, please post this RFR also to hotspot-compiler-dev. It must be reviewed on one of the official lists before it can be pushed. Ppc-aix-port-dev is only for communication about the port, not for reviews. Also I would appreciate if you could upload your webrevs yourselves. We are happy to help out in the beginning, and also with testing, reviewing and pushing, but making webrevs is a task I don't see on our side in the long term. Thanks and best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Montag, 26. September 2016 11:53 > To: Michihiro Horie >; Simonis, Volker > >; ppc-aix-port-dev at openjdk.java.net > Cc: Hiroshi H Horii >; Gustavo Romero > > > Subject: RE: RFR:8166684:implement intrinsic code with vector instructions > for Unsafe.copyMemory() > > Hi Michihiro, > > > > the initialization of tmp1 should be done outside of the loop. Beside that, the > change looks good: > > http://cr.openjdk.java.net/~mdoerr/8166684_PPC64_unsafe_copymemory/ > webrev.00/ > /webrev.00/> > > > > Best regards, > > Martin > > > > > > From: Michihiro Horie [mailto:HORIE at jp.ibm.com] > Sent: Montag, 26. September 2016 09:37 > To: Doerr, Martin >; Simonis, Volker > >; ppc-aix-port-dev at openjdk.java.net > Cc: volker.simonis at gmail.com; Gustavo Romero > >; Hiroshi H Horii > > Subject: RFR:8166684:implement intrinsic code with vector instructions for > Unsafe.copyMemory() > > > > Dear all, > > Could I please request reviews for the following change? > This change was created for JDK9. > > I added fixes to the intrinsic code for sun.misc.Unsafe.copyMemory() by > using VSX. > Since Spark often invokes Unsafe.copyMemory(), it is beneficial to use the > vector instructions for these intrinsic code. > > jira: https://bugs.openjdk.java.net/browse/JDK-8166684 > > diff: (See attached file: unsafe-copymemory-openjdk9.diff) > > Best regards, > -- > Michihiro Horie, > IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Wed Sep 28 17:33:07 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Sep 2016 17:33:07 -0000 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis wrote: > > I don't think this can be easily done with the current build system. > Remember for example that even such a sensitive part like jni.h is > still duplicated between the hotspot and the jdk repository: > > hotspot/src/share/vm/prims/jni.h > jdk/src/java.base/share/native/include/jni.h > It's one of the frustrating aspects of openjdk development that it's hard to share C level infrastructure among different components. Components sometimes grow their own local C infrastructure, but when another component has the same problem, one often resorts to copy-paste as the most expedient way to get code reuse. In part, the mercurial repo organization reinforces this - there is one top-level repo with fan-out, but there is nothing at the bottom with fan-in. One code sharing mechanism that does get used is seen in ClassLoader::load_zip_library() where code from the jdk repo is packaged into a shared object and invoked from hotspot, dynamically. -------------- next part -------------- An HTML attachment was scrubbed... URL: