From gromero at linux.vnet.ibm.com Thu Feb 1 02:47:19 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 1 Feb 2018 00:47:19 -0200 Subject: POWER9: Is there a way to improve the random number generation on PPC64? In-Reply-To: <038634915096437494c1b3aa92e70e9b@sap.com> References: <5A1887FF.1030406@linux.vnet.ibm.com> <5A1EB043.2000101@linux.vnet.ibm.com> <5A21CD41.2000805@linux.vnet.ibm.com> <5A25D921.8040808@linux.vnet.ibm.com> <5A268B0F.3090902@linux.vnet.ibm.com> <5A715845.1080509@linux.vnet.ibm.com> <038634915096437494c1b3aa92e70e9b@sap.com> Message-ID: <5A727FB7.5060906@linux.vnet.ibm.com> Hi Martin, On 01/31/2018 12:00 PM, Doerr, Martin wrote: > I think lir_random needs to be modelled as LIR_Op0 (i.e. 0 input operands) like e.g. lir_get_thread. Modeling as a LIR_Op0 fixed the error [1]. I'll prepare a final version, do a few more tests, and start a discussion about using 'darn' for SecureRandom on POWER9 on the security ML as Volker suggested. Thanks a lot, Martin. Best regards, Gustavo [1] http://cr.openjdk.java.net/~gromero/misc/darn_C1_v2.patch From christoph.langer at sap.com Thu Feb 1 09:11:25 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Feb 2018 09:11:25 +0000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification Message-ID: <7155df04e4fc446b9a3494d321ca947a@sap.com> Hi, please review a fix for the os::javaTimeNanos method on AIX. It implements the information we got from the AIX documentation and from the IBM folks regarding the behavior of mread_real_time on Pase. Bug: https://bugs.openjdk.java.net/browse/JDK-8196565 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196565.0/ Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Thu Feb 1 09:27:03 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 1 Feb 2018 09:27:03 +0000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: <7155df04e4fc446b9a3494d321ca947a@sap.com> References: <7155df04e4fc446b9a3494d321ca947a@sap.com> Message-ID: <65e91da8ee2a45c48e46f6efef414a55@sap.com> Hi Christoph, maybe it would be better to check the return code of time_base_to_time, the doc at https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.basetrf2/read_real_time.htm says : "The time_base_to_time subroutine returns 0 if the conversion to real time is successful (or not necessary), otherwise -1 is returned." So errors might (at least in theory) occur . (otherwise it looks good to me, not a Reviewer however) Best regards, Matthias From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Langer, Christoph Sent: Donnerstag, 1. Februar 2018 10:11 To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification Hi, please review a fix for the os::javaTimeNanos method on AIX. It implements the information we got from the AIX documentation and from the IBM folks regarding the behavior of mread_real_time on Pase. Bug: https://bugs.openjdk.java.net/browse/JDK-8196565 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196565.0/ Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Feb 1 10:59:10 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Feb 2018 10:59:10 +0000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: <65e91da8ee2a45c48e46f6efef414a55@sap.com> References: <7155df04e4fc446b9a3494d321ca947a@sap.com> <65e91da8ee2a45c48e46f6efef414a55@sap.com> Message-ID: <39e9cba4bbc14898b23fb92cd17c7c57@sap.com> Hi Matthias, thanks for looking at this. I updated my coding (webrev in place) to add back the assertion and I also updated the CAS coding to the one that's used on other platforms such as Solaris and BSD/MacOS. Best regards Christoph From: Baesken, Matthias Sent: Donnerstag, 1. Februar 2018 10:27 To: Langer, Christoph ; hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification Hi Christoph, maybe it would be better to check the return code of time_base_to_time, the doc at https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.basetrf2/read_real_time.htm says : "The time_base_to_time subroutine returns 0 if the conversion to real time is successful (or not necessary), otherwise -1 is returned." So errors might (at least in theory) occur . (otherwise it looks good to me, not a Reviewer however) Best regards, Matthias From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Langer, Christoph Sent: Donnerstag, 1. Februar 2018 10:11 To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification Hi, please review a fix for the os::javaTimeNanos method on AIX. It implements the information we got from the AIX documentation and from the IBM folks regarding the behavior of mread_real_time on Pase. Bug: https://bugs.openjdk.java.net/browse/JDK-8196565 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196565.0/ Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Feb 1 11:10:03 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Feb 2018 21:10:03 +1000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: <7155df04e4fc446b9a3494d321ca947a@sap.com> References: <7155df04e4fc446b9a3494d321ca947a@sap.com> Message-ID: <935861c7-e9df-1025-8672-43fcc0dad3f1@oracle.com> Hi Christoph, On 1/02/2018 7:11 PM, Langer, Christoph wrote: > Hi, > > please review a fix for the os::javaTimeNanos method on AIX. > > It implements the information we got from the AIX documentation and from the IBM folks regarding the behavior of mread_real_time on Pase. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196565 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196565.0/ I took a look as I was curious :) I recognized the Solaris code for ensuring monotonic time. :) It all seems to do as you describe. One nit - instead of (1000 * 1000 * 1000) you can use: const jlong NANOSECS_PER_SEC = CONST64(1000000000); from ./hotspot/share/utilities/globalDefinitions.hpp Cheers, David > Thanks & Best regards > Christoph > From christoph.langer at sap.com Thu Feb 1 12:06:34 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Feb 2018 12:06:34 +0000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: <935861c7-e9df-1025-8672-43fcc0dad3f1@oracle.com> References: <7155df04e4fc446b9a3494d321ca947a@sap.com> <935861c7-e9df-1025-8672-43fcc0dad3f1@oracle.com> Message-ID: <017b0a74cd2a4bbb8680c6bce26d56fb@sap.com> Hi David, thanks for looking. I'll change my code to use that constant. One question, as I'm currently looking at the os timing functions: Do you know why in os_solaris.cpp, in os::getTimesSecs(), the process_real_time value is not taken from the result of times() but from getTimeNanos()? Otherwise getTimeSecs would be a good candidate to move to os_posix.cpp ... Best regards Christoph -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Donnerstag, 1. Februar 2018 12:10 To: Langer, Christoph ; hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification Hi Christoph, On 1/02/2018 7:11 PM, Langer, Christoph wrote: > Hi, > > please review a fix for the os::javaTimeNanos method on AIX. > > It implements the information we got from the AIX documentation and from the IBM folks regarding the behavior of mread_real_time on Pase. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196565 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196565.0/ I took a look as I was curious :) I recognized the Solaris code for ensuring monotonic time. :) It all seems to do as you describe. One nit - instead of (1000 * 1000 * 1000) you can use: const jlong NANOSECS_PER_SEC = CONST64(1000000000); from ./hotspot/share/utilities/globalDefinitions.hpp Cheers, David > Thanks & Best regards > Christoph > From david.holmes at oracle.com Thu Feb 1 13:17:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Feb 2018 23:17:02 +1000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: <017b0a74cd2a4bbb8680c6bce26d56fb@sap.com> References: <7155df04e4fc446b9a3494d321ca947a@sap.com> <935861c7-e9df-1025-8672-43fcc0dad3f1@oracle.com> <017b0a74cd2a4bbb8680c6bce26d56fb@sap.com> Message-ID: Hi Christoph, On 1/02/2018 10:06 PM, Langer, Christoph wrote: > Hi David, > > thanks for looking. I'll change my code to use that constant. > > One question, as I'm currently looking at the os timing functions: Do you know why in os_solaris.cpp, in os::getTimesSecs(), the process_real_time value is not taken from the result of times() but from getTimeNanos()? Otherwise getTimeSecs would be a good candidate to move to os_posix.cpp ... I can only guess that as per the comment the intent was to ensure that "process_real_time" was consistent with other views of time ie os::elapsedTime and os::elapsedCounter. The code was added by: https://bugs.openjdk.java.net/browse/JDK-6468292 but there are no enlightening comments in that regard. And I don't know if times() would be using a different timebase than gethrtime(). David ----- > Best regards > Christoph > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 1. Februar 2018 12:10 > To: Langer, Christoph ; hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification > > Hi Christoph, > > On 1/02/2018 7:11 PM, Langer, Christoph wrote: >> Hi, >> >> please review a fix for the os::javaTimeNanos method on AIX. >> >> It implements the information we got from the AIX documentation and from the IBM folks regarding the behavior of mread_real_time on Pase. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196565 >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196565.0/ > > I took a look as I was curious :) I recognized the Solaris code for > ensuring monotonic time. :) It all seems to do as you describe. > > One nit - instead of (1000 * 1000 * 1000) you can use: > > const jlong NANOSECS_PER_SEC = CONST64(1000000000); > > from ./hotspot/share/utilities/globalDefinitions.hpp > > Cheers, > David > >> Thanks & Best regards >> Christoph >> From raduandritoiu at gmail.com Thu Feb 1 13:34:17 2018 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Thu, 1 Feb 2018 15:34:17 +0200 Subject: Compile JRE for PPC 32 bit In-Reply-To: References: <20180125153449.GB4563@vimes> <9b6e853d-4f5c-e01a-1ec6-bd85031717c1@azul.com> Message-ID: Hello Adrian, Should jdk8u compile natively on x86 with "zero" jvm variant? I was trying to do that to see if the output may help me run the cross compile. Thank you, Radu On Mon, Jan 29, 2018 at 11:36 AM, Radu Andritoiu wrote: > Hello Anton, > > Glad to hear you have a PPC 32 port of jdk8. Does it have the fix for RMI > vulnerability (https://access.redhat.com/security/cve/cve-2017-3241). > I will tell this to my manager and ask what direction he wants to go. > > Thank you, > Radu > > > On Fri, Jan 26, 2018 at 6:44 PM, Anton Kozlov wrote: > >> Hi, All, >> >> sorry, completely overlooked the thread. >> >> On 25.01.2018 19:11, Volker Simonis wrote: >> > Azul is known to have a 32bit ppc port, but they havn't contributed it >> > to the OpenJDK yet. >> >> yes, Azul have ppc32 port of jdk8u, in SPE and FPU variants. >> >> Yes, we want to contribte the support to OpenJDK, but it complicated. >> To reveal source code we need to make up-port to current jdk development >> tree (11?) first, and it's heavy. >> >> We have no reasonable estimates when the up-port will be ready. This is >> also pulls us back from creating new Project, as it will be out of sync >> with development branch of OpenJDK. >> >> Thanks, >> Anton >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Feb 1 14:43:53 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Feb 2018 15:43:53 +0100 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: <7155df04e4fc446b9a3494d321ca947a@sap.com> References: <7155df04e4fc446b9a3494d321ca947a@sap.com> Message-ID: Hi Christoph, thanks for the fix! But please, could refrain from changing webrevs in place? At least if you change large portions of the diff? I was reviewing the old one while it changed under me, this was quite confusing. It also makes understanding the mail thread difficult. ------ Why do you not handle the return value of mread_real_time() like we did before on AIX? .. Oh, I read the IBM documentation now... What is this? Return Values The read_real_time subroutine returns RTC_POWER if the contents of the real-time clock are recorded in the timebasestruct, or returns RTC_POWER_PC if the content of the time base registers is recorded in the timebasestruct. It is assumed, though never explicitly stated, that a return value of RTC_POWER_PC means we need to convert the returned value with time_base_to_time(). But then it says: The time_base_to_time subroutine converts time base information to real time, if necessary. It is **suggested** that applications unconditionally call the time_base_to_time subroutine rather than conducting a check to see whether it is necessary. The second quote directly contradicts the first. Either I have to honor the return code of read_real_time() or I don't, in which case I have to always convert the result. I also like the "it is suggested" wording, like it is my choice :) Then they also never explain the return code of mread_real_time(), but we just assume the function works the same way as read_real_time() does, yes? IBM really has the worst manpages :) Sorry for the rant. But back to your change, we did handle the return code of mread_real_time() before, and arguably the coding before was more correct. Well, depending on how we feel about the suggestion :) So I am hesitant to throw that old coding out. Does your change work on older AIX releases and did you test on different Power platforms? Did we have an actual problem on AIX, or is this fix just for PASE? - I know mread_real_time() is supposed to return monotonic values on AIX, but I would feel better were we to assert the fact. - I would leave George's name out of the sources. - Small nit, could you rename max_nanos to something clearer, e.g. mread_last_value or similar? And maybe place it physically near that function? Ideally I would put it inside that function but I am not sure if the late initialization of then function-scope-static max_nanos would cause problems. Thanks! .. Best Regards, Thomas On Thu, Feb 1, 2018 at 10:11 AM, Langer, Christoph wrote: > Hi, > > please review a fix for the os::javaTimeNanos method on AIX. > > It implements the information we got from the AIX documentation and from > the IBM folks regarding the behavior of mread_real_time on Pase. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196565 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196565.0/ > > Thanks & Best regards > Christoph > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Thu Feb 1 16:16:59 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 1 Feb 2018 16:16:59 +0000 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 Message-ID: Hello , I enhanced the errno - to - error-text mappings in os.cpp for a few errnos we find on AIX 7.1 . Some of these added errnos are found as well on Linux (e.g. SLES 11 / 12 ). Could you please check and review ? ( btw. there is good cross platform info about the errnos at http://www.ioplex.com/~miallen/errcmp.html ) Bug : https://bugs.openjdk.java.net/browse/JDK-8196578 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Feb 1 17:37:34 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Feb 2018 18:37:34 +0100 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 In-Reply-To: References: Message-ID: Hi Matthias, This would probably better discussed in hotspot-runtime, no? The old error codes and their descriptions were Posix ( http://pubs.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html). I do not really like spamming a shared file with AIX specific errno codes. Can we move platform specific error codes to platform files? Eg by having a platform specific version pd_errno_to_string(), which has a first shot at translating errno values, and only if that one returns no result reverting back to the shared version? Small nit: - DEFINE_ENTRY(ESTALE, "Reserved") + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") I like the glibc text better, just "Stale file handle". NFS seems too specific, can handles for other remote file systems not get stale? Kind Regards, Thomas On Thu, Feb 1, 2018 at 5:16 PM, Baesken, Matthias wrote: > Hello , I enhanced the errno - to - error-text mappings in os.cpp > for a few errnos we find on AIX 7.1 . > Some of these added errnos are found as well on Linux (e.g. SLES 11 / 12 > ). > > Could you please check and review ? > > ( btw. there is good cross platform info about the errnos at > http://www.ioplex.com/~miallen/errcmp.html ) > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8196578 > > Webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ > > > > Best regards, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Feb 1 18:55:14 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Feb 2018 18:55:14 +0000 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 In-Reply-To: References: Message-ID: <25e023bc47914bc3b1c5009abc5b03d8@sap.com> Hi Matthias, the change looks good to me. You'll need a sponsor, though. Best regards Christoph From: Baesken, Matthias Sent: Donnerstag, 1. Februar 2018 17:17 To: 'hotspot-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net Cc: Langer, Christoph Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 Hello , I enhanced the errno - to - error-text mappings in os.cpp for a few errnos we find on AIX 7.1 . Some of these added errnos are found as well on Linux (e.g. SLES 11 / 12 ). Could you please check and review ? ( btw. there is good cross platform info about the errnos at http://www.ioplex.com/~miallen/errcmp.html ) Bug : https://bugs.openjdk.java.net/browse/JDK-8196578 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Feb 1 21:23:59 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Feb 2018 07:23:59 +1000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: References: <7155df04e4fc446b9a3494d321ca947a@sap.com> <935861c7-e9df-1025-8672-43fcc0dad3f1@oracle.com> <017b0a74cd2a4bbb8680c6bce26d56fb@sap.com> Message-ID: <70dfd204-db10-0cc9-f4ec-8f0e2992c26e@oracle.com> On 1/02/2018 11:17 PM, David Holmes wrote: > Hi Christoph, > > On 1/02/2018 10:06 PM, Langer, Christoph wrote: >> Hi David, >> >> thanks for looking. I'll change my code to use that constant. >> >> One question, as I'm currently looking at the os timing functions: Do >> you know why in os_solaris.cpp, in os::getTimesSecs(), the >> process_real_time value is not taken from the result of times() but >> from getTimeNanos()? Otherwise getTimeSecs would be a good candidate >> to move to os_posix.cpp ... > > I can only guess that as per the comment the intent was to ensure that > "process_real_time" was consistent with other views of time ie > os::elapsedTime and os::elapsedCounter. > > The code was added by: > > https://bugs.openjdk.java.net/browse/JDK-6468292 > > but there are no enlightening comments in that regard. And I don't know > if times() would be using a different timebase than gethrtime(). Actually I think it is also because the return value from times() may not be usable due to the potential overflow problem. This is true on other platforms too. Linux has an even bigger disclaimer: On Linux, the "arbitrary point in the past" from which the return value of times() is measured has varied across kernel versions. On Linux 2.4 and earlier this point is the moment the system was booted. Since Linux 2.6, this point is (2^32/HZ) - 300 (i.e., about 429 million) seconds before system boot time. This variability across kernel versions (and across UNIX implementations), combined with the fact that the returned value may overflow the range of clock_t, means that a portable application would be wise to avoid using this value. To measure changes in elapsed time, use gettimeofday(2) instead. -- David > David > ----- > >> Best regards >> Christoph >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 1. Februar 2018 12:10 >> To: Langer, Christoph ; >> hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Subject: Re: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos >> according to AIX/PASE specification >> >> Hi Christoph, >> >> On 1/02/2018 7:11 PM, Langer, Christoph wrote: >>> Hi, >>> >>> please review a fix for the os::javaTimeNanos method on AIX. >>> >>> It implements the information we got from the AIX documentation and >>> from the IBM folks regarding the behavior of mread_real_time on Pase. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196565 >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196565.0/ >> >> I took a look as I was curious :) I recognized the Solaris code for >> ensuring monotonic time. :) It all seems to do as you describe. >> >> One nit - instead of (1000 * 1000 * 1000) you can use: >> >> const jlong NANOSECS_PER_SEC????? = CONST64(1000000000); >> >> from ./hotspot/share/utilities/globalDefinitions.hpp >> >> Cheers, >> David >> >>> Thanks & Best regards >>> Christoph >>> From david.holmes at oracle.com Thu Feb 1 23:11:08 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Feb 2018 09:11:08 +1000 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 In-Reply-To: References: Message-ID: <0d2e9880-cb76-c24f-5185-d877cea8d0dc@oracle.com> +1 on moving to platform specific code. Thanks, David On 2/02/2018 3:37 AM, Thomas St?fe wrote: > Hi Matthias, > > This would probably better discussed in hotspot-runtime, no? > > The old error codes and their descriptions were Posix ( > http://pubs.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html). I do > not really like spamming a shared file with AIX specific errno codes. Can > we move platform specific error codes to platform files? Eg by having a > platform specific version pd_errno_to_string(), which has a first shot at > translating errno values, and only if that one returns no result reverting > back to the shared version? > > Small nit: > > - DEFINE_ENTRY(ESTALE, "Reserved") > + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") > > I like the glibc text better, just "Stale file handle". NFS seems too > specific, can handles for other remote file systems not get stale? > > Kind Regards, Thomas > > On Thu, Feb 1, 2018 at 5:16 PM, Baesken, Matthias > wrote: > >> Hello , I enhanced the errno - to - error-text mappings in os.cpp >> for a few errnos we find on AIX 7.1 . >> Some of these added errnos are found as well on Linux (e.g. SLES 11 / 12 >> ). >> >> Could you please check and review ? >> >> ( btw. there is good cross platform info about the errnos at >> http://www.ioplex.com/~miallen/errcmp.html ) >> >> Bug : >> >> https://bugs.openjdk.java.net/browse/JDK-8196578 >> >> Webrev : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ >> >> >> >> Best regards, Matthias >> From matthias.baesken at sap.com Fri Feb 2 08:02:42 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 2 Feb 2018 08:02:42 +0000 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 In-Reply-To: References: Message-ID: <93fc660476f1490da815cdfba98ff623@sap.com> * I do not really like spamming a shared file with AIX specific errno codes. Hi, I wrote ?for a few errnos ***we find*** on AIX 7.1? , not that they are AIX ***specific***. Checked the first few added ones : 1522 // some more errno numbers from AIX 7.1 (some are also supported on Linux) 1523 #ifdef ENOTBLK 1524 DEFINE_ENTRY(ENOTBLK, "Block device required") 1525 #endif 1526 #ifdef ECHRNG 1527 DEFINE_ENTRY(ECHRNG, "Channel number out of range") 1528 #endif 1529 #ifdef ELNRNG 1530 DEFINE_ENTRY(ELNRNG, "Link number out of range") 1531 #endif According to http://www.ioplex.com/~miallen/errcmp.html ENOTBLK ? found on AIX, Solaris, Linux, ? ECHRNG - found on AIX, Solaris, Linux ELNRNG - found on AIX, Solaris, Linux I would suggest to keep the multi-platform errnos in os.cpp just where they are . * Can we move platform specific error codes to platform files? Eg by having a platform specific version pd_errno_to_string(), * which has a first shot at translating errno values, and only if that one returns no result reverting back to the shared version? * Can go through the list of added errnos and check if there are really a few in that exist only on AIX. If there are a significant number we might do what you suggest , but for only a small number I wouldn?t do it. >Small nit: > >- DEFINE_ENTRY(ESTALE, "Reserved") >+ DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") > >I like the glibc text better, just "Stale file handle". NFS seems too specific, can handles for other remote file systems not get stale? That?s fine with me, I can change this to what you suggest. Best regards, Matthias From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Donnerstag, 1. Februar 2018 18:38 To: Baesken, Matthias Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 Hi Matthias, This would probably better discussed in hotspot-runtime, no? The old error codes and their descriptions were Posix (http://pubs.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html). I do not really like spamming a shared file with AIX specific errno codes. Can we move platform specific error codes to platform files? Eg by having a platform specific version pd_errno_to_string(), which has a first shot at translating errno values, and only if that one returns no result reverting back to the shared version? Small nit: - DEFINE_ENTRY(ESTALE, "Reserved") + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") I like the glibc text better, just "Stale file handle". NFS seems too specific, can handles for other remote file systems not get stale? Kind Regards, Thomas On Thu, Feb 1, 2018 at 5:16 PM, Baesken, Matthias > wrote: Hello , I enhanced the errno - to - error-text mappings in os.cpp for a few errnos we find on AIX 7.1 . Some of these added errnos are found as well on Linux (e.g. SLES 11 / 12 ). Could you please check and review ? ( btw. there is good cross platform info about the errnos at http://www.ioplex.com/~miallen/errcmp.html ) Bug : https://bugs.openjdk.java.net/browse/JDK-8196578 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri Feb 2 08:40:36 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 2 Feb 2018 09:40:36 +0100 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 In-Reply-To: <93fc660476f1490da815cdfba98ff623@sap.com> References: <93fc660476f1490da815cdfba98ff623@sap.com> Message-ID: On Fri, Feb 2, 2018 at 9:02 AM, Baesken, Matthias wrote: > > - I do not really like spamming a shared file with AIX specific errno > codes. > > > > Hi, I wrote ?for a few errnos ***we find*** on AIX 7.1? , not that > they are AIX ***specific***. > > Checked the first few added ones : > > > > 1522 // some more errno numbers from AIX 7.1 (some are also supported > on Linux) > > 1523 #ifdef ENOTBLK > > 1524 DEFINE_ENTRY(ENOTBLK, "Block device required") > > 1525 #endif > > 1526 #ifdef ECHRNG > > 1527 DEFINE_ENTRY(ECHRNG, "Channel number out of range") > > 1528 #endif > > 1529 #ifdef ELNRNG > > 1530 DEFINE_ENTRY(ELNRNG, "Link number out of range") > > 1531 #endif > > > > According to > > > > http://www.ioplex.com/~miallen/errcmp.html > > > > ENOTBLK ? found on AIX, Solaris, Linux, ? > > ECHRNG - found on AIX, Solaris, Linux > > ELNRNG - found on AIX, Solaris, Linux > > > The argument can easily made in the other direction. Checking the last n errno codes I see: AIX, MAC + #ifdef EPROCLIM AIX only + #ifdef ECORRUPT AIX only + #ifdef ESYSERROR AIX only + DEFINE_ENTRY(ESOFT, "I/O completed, but needs relocation") AIX, MAC + #ifdef ENOATTR AIX only + DEFINE_ENTRY(ESAD, "Security authentication denied") AIX only + #ifdef ENOTRUST ... > I would suggest to keep the multi-platform errnos in os.cpp just where > they are . > > > I am still not convinced and like my original suggestion better. Lets wait for others to chime in and see what the consensus is. Best Regards, Thomas > - Can we move platform specific error codes to platform files? Eg by > having a platform specific version pd_errno_to_string(), > - which has a first shot at translating errno values, and only if that > one returns no result reverting back to the shared version? > - > > > > Can go through the list of added errnos and check if there are really a > few in that exist only on AIX. > > If there are a significant number we might do what you suggest , but for > only a small number I wouldn?t do it. > > > > > > >Small nit: > > > > > >- DEFINE_ENTRY(ESTALE, "Reserved") > > >+ DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") > > > > > >I like the glibc text better, just "Stale file handle". NFS seems too > specific, can handles for other remote file systems not get stale? > > > > That?s fine with me, I can change this to what you suggest. > > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com] > *Sent:* Donnerstag, 1. Februar 2018 18:38 > *To:* Baesken, Matthias > *Cc:* hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > *Subject:* Re: RFR : 8196578 : enhance errno_to_string function in os.cpp > with some additional errno texts from AIX 7.1 > > > > Hi Matthias, > > > > This would probably better discussed in hotspot-runtime, no? > > > > The old error codes and their descriptions were Posix ( > http://pubs.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html). I > do not really like spamming a shared file with AIX specific errno codes. > Can we move platform specific error codes to platform files? Eg by having a > platform specific version pd_errno_to_string(), which has a first shot at > translating errno values, and only if that one returns no result reverting > back to the shared version? > > > > Small nit: > > > > - DEFINE_ENTRY(ESTALE, "Reserved") > > + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") > > > > I like the glibc text better, just "Stale file handle". NFS seems too > specific, can handles for other remote file systems not get stale? > > Kind Regards, Thomas > > > > On Thu, Feb 1, 2018 at 5:16 PM, Baesken, Matthias < > matthias.baesken at sap.com> wrote: > > Hello , I enhanced the errno - to - error-text mappings in os.cpp > for a few errnos we find on AIX 7.1 . > Some of these added errnos are found as well on Linux (e.g. SLES 11 / 12 > ). > > Could you please check and review ? > > ( btw. there is good cross platform info about the errnos at > http://www.ioplex.com/~miallen/errcmp.html ) > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8196578 > > Webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ > > > > Best regards, Matthias > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Feb 2 08:57:41 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Feb 2018 18:57:41 +1000 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 In-Reply-To: References: <93fc660476f1490da815cdfba98ff623@sap.com> Message-ID: While I did not do an exhaustive check of the existing codes even the ones under // The following enums are not defined on all platforms. are at least defined by POSIX (even if just listed as "Reserved"). So I am still reluctant to introduce OS specific codes into a shared file. Plus there's the problem of different OS having different meanings for the same error code - suggesting per-OS specialization might be useful (but tricky to implement). That said I have to re-question whether we should be maintaining this explicit string mapping table anyway? strerror() is not thread-safe but strerror_l() seems to be, or at worst we need buffer management with strerror_r(). I know this topic has arisen before ... Cheers, David On 2/02/2018 6:40 PM, Thomas St?fe wrote: > On Fri, Feb 2, 2018 at 9:02 AM, Baesken, Matthias > wrote: > >> >> - I do not really like spamming a shared file with AIX specific errno >> codes. >> >> >> >> Hi, I wrote ?for a few errnos ***we find*** on AIX 7.1? , not that >> they are AIX ***specific***. >> >> Checked the first few added ones : >> >> >> >> 1522 // some more errno numbers from AIX 7.1 (some are also supported >> on Linux) >> >> 1523 #ifdef ENOTBLK >> >> 1524 DEFINE_ENTRY(ENOTBLK, "Block device required") >> >> 1525 #endif >> >> 1526 #ifdef ECHRNG >> >> 1527 DEFINE_ENTRY(ECHRNG, "Channel number out of range") >> >> 1528 #endif >> >> 1529 #ifdef ELNRNG >> >> 1530 DEFINE_ENTRY(ELNRNG, "Link number out of range") >> >> 1531 #endif >> >> >> >> According to >> >> >> >> http://www.ioplex.com/~miallen/errcmp.html >> >> >> >> ENOTBLK ? found on AIX, Solaris, Linux, ? >> >> ECHRNG - found on AIX, Solaris, Linux >> >> ELNRNG - found on AIX, Solaris, Linux >> >> >> > > The argument can easily made in the other direction. Checking the last n > errno codes I see: > > AIX, MAC + #ifdef EPROCLIM > AIX only + #ifdef ECORRUPT > AIX only + #ifdef ESYSERROR > AIX only + DEFINE_ENTRY(ESOFT, "I/O completed, but needs relocation") > AIX, MAC + #ifdef ENOATTR > AIX only + DEFINE_ENTRY(ESAD, "Security authentication denied") > AIX only + #ifdef ENOTRUST > ... > > >> I would suggest to keep the multi-platform errnos in os.cpp just where >> they are . >> >> >> > > I am still not convinced and like my original suggestion better. Lets wait > for others to chime in and see what the consensus is. > > Best Regards, Thomas > > > > >> - Can we move platform specific error codes to platform files? Eg by >> having a platform specific version pd_errno_to_string(), >> - which has a first shot at translating errno values, and only if that >> one returns no result reverting back to the shared version? >> - >> >> >> >> Can go through the list of added errnos and check if there are really a >> few in that exist only on AIX. >> >> If there are a significant number we might do what you suggest , but for >> only a small number I wouldn?t do it. >> >> >> >> >> >>> Small nit: >> >>> >> >>> - DEFINE_ENTRY(ESTALE, "Reserved") >> >>> + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") >> >>> >> >>> I like the glibc text better, just "Stale file handle". NFS seems too >> specific, can handles for other remote file systems not get stale? >> >> >> >> That?s fine with me, I can change this to what you suggest. >> >> >> >> Best regards, Matthias >> >> >> >> >> >> *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> *Sent:* Donnerstag, 1. Februar 2018 18:38 >> *To:* Baesken, Matthias >> *Cc:* hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> *Subject:* Re: RFR : 8196578 : enhance errno_to_string function in os.cpp >> with some additional errno texts from AIX 7.1 >> >> >> >> Hi Matthias, >> >> >> >> This would probably better discussed in hotspot-runtime, no? >> >> >> >> The old error codes and their descriptions were Posix ( >> http://pubs.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html). I >> do not really like spamming a shared file with AIX specific errno codes. >> Can we move platform specific error codes to platform files? Eg by having a >> platform specific version pd_errno_to_string(), which has a first shot at >> translating errno values, and only if that one returns no result reverting >> back to the shared version? >> >> >> >> Small nit: >> >> >> >> - DEFINE_ENTRY(ESTALE, "Reserved") >> >> + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") >> >> >> >> I like the glibc text better, just "Stale file handle". NFS seems too >> specific, can handles for other remote file systems not get stale? >> >> Kind Regards, Thomas >> >> >> >> On Thu, Feb 1, 2018 at 5:16 PM, Baesken, Matthias < >> matthias.baesken at sap.com> wrote: >> >> Hello , I enhanced the errno - to - error-text mappings in os.cpp >> for a few errnos we find on AIX 7.1 . >> Some of these added errnos are found as well on Linux (e.g. SLES 11 / 12 >> ). >> >> Could you please check and review ? >> >> ( btw. there is good cross platform info about the errnos at >> http://www.ioplex.com/~miallen/errcmp.html ) >> >> Bug : >> >> https://bugs.openjdk.java.net/browse/JDK-8196578 >> >> Webrev : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ >> >> >> >> Best regards, Matthias >> >> >> From thomas.stuefe at gmail.com Fri Feb 2 09:20:12 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 2 Feb 2018 10:20:12 +0100 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 In-Reply-To: References: <93fc660476f1490da815cdfba98ff623@sap.com> Message-ID: On Fri, Feb 2, 2018 at 9:57 AM, David Holmes wrote: > While I did not do an exhaustive check of the existing codes even the ones > under > > // The following enums are not defined on all platforms. > > are at least defined by POSIX (even if just listed as "Reserved"). > > So I am still reluctant to introduce OS specific codes into a shared file. > Plus there's the problem of different OS having different meanings for the > same error code - suggesting per-OS specialization might be useful (but > tricky to implement). > > That said I have to re-question whether we should be maintaining this > explicit string mapping table anyway? strerror() is not thread-safe but > strerror_l() seems to be, or at worst we need buffer management with > strerror_r(). I know this topic has arisen before ... > > How about we build the string table dynamically at process start by iterating the first n errnos and calling strerror() :) Just kidding. Yes, I admit this table starts to feel weird. Original discussions were here: https://bugs.openjdk.java.net/browse/JDK-8148425 I originally just wanted a static translation of errno numbers to literalized errno constants (e.g. ETOOMANYREFS => "ETOOMANYREFS"), because in 99% of cases where we call os::strerror() we do this to print log output for developers, and as a developer I find "ETOOMANYREFS" far more succinct than whatever strerror() returns. This would also bypass any localization issues. If I see "ETOOMANYREFS" in a log file I immediately know this is an error code from the libc, and can look it up in the man page or google it. But when I read "Too many references: can't splice" - potentially in Portuguese :) - I would have to dig a bit until I find out what is actually happening. Of course, there are cases where we want the human readable, localized text, but those cases are rarer and could be rewritten to use strerror_r. Just my 5 cent. ..Thomas Cheers, > David > > On 2/02/2018 6:40 PM, Thomas St?fe wrote: > >> On Fri, Feb 2, 2018 at 9:02 AM, Baesken, Matthias < >> matthias.baesken at sap.com> >> wrote: >> >> >>> - I do not really like spamming a shared file with AIX specific errno >>> >>> codes. >>> >>> >>> >>> Hi, I wrote ?for a few errnos ***we find*** on AIX 7.1? , not that >>> they are AIX ***specific***. >>> >>> Checked the first few added ones : >>> >>> >>> >>> 1522 // some more errno numbers from AIX 7.1 (some are also supported >>> on Linux) >>> >>> 1523 #ifdef ENOTBLK >>> >>> 1524 DEFINE_ENTRY(ENOTBLK, "Block device required") >>> >>> 1525 #endif >>> >>> 1526 #ifdef ECHRNG >>> >>> 1527 DEFINE_ENTRY(ECHRNG, "Channel number out of range") >>> >>> 1528 #endif >>> >>> 1529 #ifdef ELNRNG >>> >>> 1530 DEFINE_ENTRY(ELNRNG, "Link number out of range") >>> >>> 1531 #endif >>> >>> >>> >>> According to >>> >>> >>> >>> http://www.ioplex.com/~miallen/errcmp.html >>> >>> >>> >>> ENOTBLK ? found on AIX, Solaris, Linux, ? >>> >>> ECHRNG - found on AIX, Solaris, Linux >>> >>> ELNRNG - found on AIX, Solaris, Linux >>> >>> >>> >>> >> The argument can easily made in the other direction. Checking the last n >> errno codes I see: >> >> AIX, MAC + #ifdef EPROCLIM >> AIX only + #ifdef ECORRUPT >> AIX only + #ifdef ESYSERROR >> AIX only + DEFINE_ENTRY(ESOFT, "I/O completed, but needs relocation") >> AIX, MAC + #ifdef ENOATTR >> AIX only + DEFINE_ENTRY(ESAD, "Security authentication denied") >> AIX only + #ifdef ENOTRUST >> ... >> >> >> I would suggest to keep the multi-platform errnos in os.cpp just where >>> they are . >>> >>> >>> >>> >> I am still not convinced and like my original suggestion better. Lets wait >> for others to chime in and see what the consensus is. >> >> Best Regards, Thomas >> >> >> >> >> - Can we move platform specific error codes to platform files? Eg by >>> having a platform specific version pd_errno_to_string(), >>> - which has a first shot at translating errno values, and only if >>> that >>> one returns no result reverting back to the shared version? >>> - >>> >>> >>> >>> Can go through the list of added errnos and check if there are really a >>> few in that exist only on AIX. >>> >>> If there are a significant number we might do what you suggest , but for >>> only a small number I wouldn?t do it. >>> >>> >>> >>> >>> >>> Small nit: >>>> >>> >>> >>>> >>> - DEFINE_ENTRY(ESTALE, "Reserved") >>>> >>> >>> + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") >>>> >>> >>> >>>> >>> I like the glibc text better, just "Stale file handle". NFS seems too >>>> >>> specific, can handles for other remote file systems not get stale? >>> >>> >>> >>> That?s fine with me, I can change this to what you suggest. >>> >>> >>> >>> Best regards, Matthias >>> >>> >>> >>> >>> >>> *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>> *Sent:* Donnerstag, 1. Februar 2018 18:38 >>> *To:* Baesken, Matthias >>> *Cc:* hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>> *Subject:* Re: RFR : 8196578 : enhance errno_to_string function in os.cpp >>> >>> with some additional errno texts from AIX 7.1 >>> >>> >>> >>> Hi Matthias, >>> >>> >>> >>> This would probably better discussed in hotspot-runtime, no? >>> >>> >>> >>> The old error codes and their descriptions were Posix ( >>> http://pubs.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html). I >>> do not really like spamming a shared file with AIX specific errno codes. >>> Can we move platform specific error codes to platform files? Eg by >>> having a >>> platform specific version pd_errno_to_string(), which has a first shot at >>> translating errno values, and only if that one returns no result >>> reverting >>> back to the shared version? >>> >>> >>> >>> Small nit: >>> >>> >>> >>> - DEFINE_ENTRY(ESTALE, "Reserved") >>> >>> + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") >>> >>> >>> >>> I like the glibc text better, just "Stale file handle". NFS seems too >>> specific, can handles for other remote file systems not get stale? >>> >>> Kind Regards, Thomas >>> >>> >>> >>> On Thu, Feb 1, 2018 at 5:16 PM, Baesken, Matthias < >>> matthias.baesken at sap.com> wrote: >>> >>> Hello , I enhanced the errno - to - error-text mappings in os.cpp >>> for a few errnos we find on AIX 7.1 . >>> Some of these added errnos are found as well on Linux (e.g. SLES 11 / 12 >>> ). >>> >>> Could you please check and review ? >>> >>> ( btw. there is good cross platform info about the errnos at >>> http://www.ioplex.com/~miallen/errcmp.html ) >>> >>> Bug : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8196578 >>> >>> Webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ >>> >>> >>> >>> Best regards, Matthias >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Feb 2 12:36:30 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 2 Feb 2018 12:36:30 +0000 Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX Message-ID: <3dc90a64d4a44c349283b91cf81123fc@sap.com> Hi, Arno has spotted an issue when printing hs_err files on AIX. This fix should still be done for JDK10. Please review and approve. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196678.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8196678 Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Feb 2 12:46:10 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 2 Feb 2018 12:46:10 +0000 Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX In-Reply-To: <3dc90a64d4a44c349283b91cf81123fc@sap.com> References: <3dc90a64d4a44c349283b91cf81123fc@sap.com> Message-ID: Hi again, Here is an updated webrev where we also corrected a wrong format specifier: http://cr.openjdk.java.net/~clanger/webrevs/8196678.1/ Thanks Christoph From: Langer, Christoph Sent: Freitag, 2. Februar 2018 13:36 To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Cc: Zeller, Arno Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX Hi, Arno has spotted an issue when printing hs_err files on AIX. This fix should still be done for JDK10. Please review and approve. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196678.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8196678 Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Feb 2 12:56:01 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 2 Feb 2018 12:56:01 +0000 Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX In-Reply-To: References: <3dc90a64d4a44c349283b91cf81123fc@sap.com> Message-ID: <8dad27e5f7b341f2b3c6b5e8b288c09e@sap.com> Looks good, and I would appreciate if this goes to 10. Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Langer, Christoph > Sent: Freitag, 2. Februar 2018 13:46 > To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in > os::print_memory_info on AIX > > Hi again, > > Here is an updated webrev where we also corrected a wrong format > specifier: > http://cr.openjdk.java.net/~clanger/webrevs/8196678.1/ > > Thanks > Christoph > > From: Langer, Christoph > Sent: Freitag, 2. Februar 2018 13:36 > To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Cc: Zeller, Arno > Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in > os::print_memory_info on AIX > > Hi, > > Arno has spotted an issue when printing hs_err files on AIX. This fix should > still be done for JDK10. Please review and approve. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196678.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8196678 > > Thanks > Christoph From david.holmes at oracle.com Fri Feb 2 13:17:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Feb 2018 23:17:32 +1000 Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX In-Reply-To: <3dc90a64d4a44c349283b91cf81123fc@sap.com> References: <3dc90a64d4a44c349283b91cf81123fc@sap.com> Message-ID: <66141985-7cf2-9c33-cab5-a0251aa9167f@oracle.com> Looks good. David On 2/02/2018 10:36 PM, Langer, Christoph wrote: > Hi, > > Arno has spotted an issue when printing hs_err files on AIX. This fix should still be done for JDK10. Please review and approve. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196678.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8196678 > > Thanks > Christoph > From david.holmes at oracle.com Fri Feb 2 13:19:56 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Feb 2018 23:19:56 +1000 Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX In-Reply-To: References: <3dc90a64d4a44c349283b91cf81123fc@sap.com> Message-ID: <1eb3f9c9-5fd9-15c0-1b55-fa134dea4d9a@oracle.com> On 2/02/2018 10:46 PM, Langer, Christoph wrote: > Hi again, > > Here is an updated webrev where we also corrected a wrong format specifier: > http://cr.openjdk.java.net/~clanger/webrevs/8196678.1/ ! st->print_cr("%% system asp used : %.2s", mi.pgsp_total ? (100.0f * (mi.pgsp_total - mi.pgsp_free) / mi.pgsp_total) : -1.0f); %s for a floating-point value ?? David > Thanks > Christoph > > From: Langer, Christoph > Sent: Freitag, 2. Februar 2018 13:36 > To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Cc: Zeller, Arno > Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX > > Hi, > > Arno has spotted an issue when printing hs_err files on AIX. This fix should still be done for JDK10. Please review and approve. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196678.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8196678 > > Thanks > Christoph > From christoph.langer at sap.com Fri Feb 2 13:23:54 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 2 Feb 2018 13:23:54 +0000 Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX In-Reply-To: <1eb3f9c9-5fd9-15c0-1b55-fa134dea4d9a@oracle.com> References: <3dc90a64d4a44c349283b91cf81123fc@sap.com> <1eb3f9c9-5fd9-15c0-1b55-fa134dea4d9a@oracle.com> Message-ID: <1eca086d5c9c4f7b9919ec0e388b7e78@sap.com> Thanks, David. Embarassing...I meant %.2f. Updated in place. Best regards Christoph -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Freitag, 2. Februar 2018 14:20 To: Langer, Christoph ; hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX On 2/02/2018 10:46 PM, Langer, Christoph wrote: > Hi again, > > Here is an updated webrev where we also corrected a wrong format specifier: > http://cr.openjdk.java.net/~clanger/webrevs/8196678.1/ ! st->print_cr("%% system asp used : %.2s", mi.pgsp_total ? (100.0f * (mi.pgsp_total - mi.pgsp_free) / mi.pgsp_total) : -1.0f); %s for a floating-point value ?? David > Thanks > Christoph > > From: Langer, Christoph > Sent: Freitag, 2. Februar 2018 13:36 > To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Cc: Zeller, Arno > Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX > > Hi, > > Arno has spotted an issue when printing hs_err files on AIX. This fix should still be done for JDK10. Please review and approve. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196678.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8196678 > > Thanks > Christoph > From david.holmes at oracle.com Fri Feb 2 13:31:45 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Feb 2018 23:31:45 +1000 Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX In-Reply-To: <1eca086d5c9c4f7b9919ec0e388b7e78@sap.com> References: <3dc90a64d4a44c349283b91cf81123fc@sap.com> <1eb3f9c9-5fd9-15c0-1b55-fa134dea4d9a@oracle.com> <1eca086d5c9c4f7b9919ec0e388b7e78@sap.com> Message-ID: On 2/02/2018 11:23 PM, Langer, Christoph wrote: > Thanks, David. > > Embarassing...I meant %.2f. Updated in place. That's better ;-) Cheers, David > Best regards > Christoph > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 2. Februar 2018 14:20 > To: Langer, Christoph ; hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX > > On 2/02/2018 10:46 PM, Langer, Christoph wrote: >> Hi again, >> >> Here is an updated webrev where we also corrected a wrong format specifier: >> http://cr.openjdk.java.net/~clanger/webrevs/8196678.1/ > > ! st->print_cr("%% system asp used : %.2s", > mi.pgsp_total ? (100.0f * (mi.pgsp_total - mi.pgsp_free) / > mi.pgsp_total) : -1.0f); > > %s for a floating-point value ?? > > David > >> Thanks >> Christoph >> >> From: Langer, Christoph >> Sent: Freitag, 2. Februar 2018 13:36 >> To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Cc: Zeller, Arno >> Subject: RFR(XS) JDK10: 8196678: avoid printing uninitialized buffer in os::print_memory_info on AIX >> >> Hi, >> >> Arno has spotted an issue when printing hs_err files on AIX. This fix should still be done for JDK10. Please review and approve. >> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196678.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196678 >> >> Thanks >> Christoph >> From christoph.langer at sap.com Fri Feb 2 14:16:35 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 2 Feb 2018 14:16:35 +0000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: References: <7155df04e4fc446b9a3494d321ca947a@sap.com> Message-ID: <46f140b3c50d4731a22f0cd97d07f16e@sap.com> Hi Thomas, thanks for the review. Here is an update: http://cr.openjdk.java.net/~clanger/webrevs/8196565.1/ > But please, could refrain from changing webrevs in place? At least if you > change large portions of the diff? I was reviewing the old one while it > changed under me, this was quite confusing. It also makes understanding the > mail thread difficult. Ok, sorry. This time I have an updated webrev in a new location ;-) > Why do you not handle the return value of mread_real_time() like we did > before on AIX? > > .. Oh, I read the IBM documentation now... What is this? > > Sorry for the rant. Yes, the IBM doc is a bit contradicting. Maybe you are right, we should do it like before for AIX... > But back to your change, we did handle the return code of > mread_real_time() before, and arguably the coding before was more > correct. Well, depending on how we feel about the suggestion :) So I am > hesitant to throw that old coding out. Does your change work on older AIX > releases and did you test on different Power platforms? Did we have an > actual problem on AIX, or is this fix just for PASE? The main motivation was to fix PASE and to get this aligned with OpenJDK. > - I know mread_real_time() is supposed to return monotonic values on AIX, > but I would feel better were we to assert the fact. Hm, the only thing way to assert monotonicity was to do CAS operations on AIX as well... We had some code like that in the SAP JVM before but I rather decided to throw it out there because I would like to trust mread_real_time specs for AIX. Additional CAS operations could mean a performance impact. > - I would leave George's name out of the sources. You're right - I did so already in my in-place update :) > - Small nit, could you rename max_nanos to something clearer, e.g. > mread_last_value or similar? And maybe place it physically near that > function? Ideally I would put it inside that function but I am not sure if the > late initialization of then function-scope-static max_nanos would cause > problems. I compared to the code for BSD and solaris and want to keep it similar. So I rename it to max_real_time. But I would like to keep the variable declaration in the beginning of the file where local variables are declared. I'm submitting the updated version of the code to our SAP JVM depot and then we'll get test results for various AIX and PASE runtimes and can see if we hit one of the asserts. Thanks and best regards Christoph From christoph.langer at sap.com Fri Feb 2 14:40:24 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 2 Feb 2018 14:40:24 +0000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: <46f140b3c50d4731a22f0cd97d07f16e@sap.com> References: <7155df04e4fc446b9a3494d321ca947a@sap.com> <46f140b3c50d4731a22f0cd97d07f16e@sap.com> Message-ID: Hi Thomas, sorry, I had to do one little in-place upgrade as I incorporated David's suggestion to use NANOSECS_PER_SEC instead of (1000 * 1000 * 1000)... Hope you weren't reviewing at that very moment ;-) Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 2. Februar 2018 15:17 > To: 'Thomas St?fe' > Cc: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to > AIX/PASE specification > > Hi Thomas, > > thanks for the review. > > Here is an update: http://cr.openjdk.java.net/~clanger/webrevs/8196565.1/ > > > But please, could refrain from changing webrevs in place? At least if you > > change large portions of the diff? I was reviewing the old one while it > > changed under me, this was quite confusing. It also makes understanding > the > > mail thread difficult. > > Ok, sorry. This time I have an updated webrev in a new location ;-) > > > Why do you not handle the return value of mread_real_time() like we did > > before on AIX? > > > > .. Oh, I read the IBM documentation now... What is this? > > > > Sorry for the rant. > > Yes, the IBM doc is a bit contradicting. Maybe you are right, we should do it > like before for AIX... > > > But back to your change, we did handle the return code of > > mread_real_time() before, and arguably the coding before was more > > correct. Well, depending on how we feel about the suggestion :) So I am > > hesitant to throw that old coding out. Does your change work on older AIX > > releases and did you test on different Power platforms? Did we have an > > actual problem on AIX, or is this fix just for PASE? > > The main motivation was to fix PASE and to get this aligned with OpenJDK. > > > - I know mread_real_time() is supposed to return monotonic values on > AIX, > > but I would feel better were we to assert the fact. > > Hm, the only thing way to assert monotonicity was to do CAS operations on > AIX as well... > We had some code like that in the SAP JVM before but I rather decided to > throw it out > there because I would like to trust mread_real_time specs for AIX. > Additional CAS operations could mean a performance impact. > > > - I would leave George's name out of the sources. > You're right - I did so already in my in-place update :) > > > - Small nit, could you rename max_nanos to something clearer, e.g. > > mread_last_value or similar? And maybe place it physically near that > > function? Ideally I would put it inside that function but I am not sure if the > > late initialization of then function-scope-static max_nanos would cause > > problems. > > I compared to the code for BSD and solaris and want to keep it similar. > So I rename it to max_real_time. But I would like to keep the variable > declaration in the beginning of the file where local variables are declared. > > I'm submitting the updated version of the code to our SAP JVM depot and > then we'll get test results for various AIX and PASE runtimes and can see if > we hit one of the asserts. > > Thanks and best regards > Christoph > From christoph.langer at sap.com Wed Feb 7 14:45:49 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 7 Feb 2018 14:45:49 +0000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: <46f140b3c50d4731a22f0cd97d07f16e@sap.com> References: <7155df04e4fc446b9a3494d321ca947a@sap.com> <46f140b3c50d4731a22f0cd97d07f16e@sap.com> Message-ID: <451f1e5f9a1847169eaf977c86bad571@sap.com> Hi Thomas, are you ok with the change as it is right now? http://cr.openjdk.java.net/~clanger/webrevs/8196565.1/ If yes, then I'd push it... Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 2. Februar 2018 15:17 > To: 'Thomas St?fe' > Cc: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to > AIX/PASE specification > > Hi Thomas, > > thanks for the review. > > Here is an update: http://cr.openjdk.java.net/~clanger/webrevs/8196565.1/ > > > But please, could refrain from changing webrevs in place? At least if you > > change large portions of the diff? I was reviewing the old one while it > > changed under me, this was quite confusing. It also makes understanding > the > > mail thread difficult. > > Ok, sorry. This time I have an updated webrev in a new location ;-) > > > Why do you not handle the return value of mread_real_time() like we did > > before on AIX? > > > > .. Oh, I read the IBM documentation now... What is this? > > > > Sorry for the rant. > > Yes, the IBM doc is a bit contradicting. Maybe you are right, we should do it > like before for AIX... > > > But back to your change, we did handle the return code of > > mread_real_time() before, and arguably the coding before was more > > correct. Well, depending on how we feel about the suggestion :) So I am > > hesitant to throw that old coding out. Does your change work on older AIX > > releases and did you test on different Power platforms? Did we have an > > actual problem on AIX, or is this fix just for PASE? > > The main motivation was to fix PASE and to get this aligned with OpenJDK. > > > - I know mread_real_time() is supposed to return monotonic values on > AIX, > > but I would feel better were we to assert the fact. > > Hm, the only thing way to assert monotonicity was to do CAS operations on > AIX as well... > We had some code like that in the SAP JVM before but I rather decided to > throw it out > there because I would like to trust mread_real_time specs for AIX. > Additional CAS operations could mean a performance impact. > > > - I would leave George's name out of the sources. > You're right - I did so already in my in-place update :) > > > - Small nit, could you rename max_nanos to something clearer, e.g. > > mread_last_value or similar? And maybe place it physically near that > > function? Ideally I would put it inside that function but I am not sure if the > > late initialization of then function-scope-static max_nanos would cause > > problems. > > I compared to the code for BSD and solaris and want to keep it similar. > So I rename it to max_real_time. But I would like to keep the variable > declaration in the beginning of the file where local variables are declared. > > I'm submitting the updated version of the code to our SAP JVM depot and > then we'll get test results for various AIX and PASE runtimes and can see if > we hit one of the asserts. > > Thanks and best regards > Christoph > From thomas.stuefe at gmail.com Wed Feb 7 14:53:05 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 7 Feb 2018 15:53:05 +0100 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: <451f1e5f9a1847169eaf977c86bad571@sap.com> References: <7155df04e4fc446b9a3494d321ca947a@sap.com> <46f140b3c50d4731a22f0cd97d07f16e@sap.com> <451f1e5f9a1847169eaf977c86bad571@sap.com> Message-ID: This looks fine. Yes, push it. ..Thomas On Wed, Feb 7, 2018 at 3:45 PM, Langer, Christoph wrote: > Hi Thomas, > > are you ok with the change as it is right now? > > http://cr.openjdk.java.net/~clanger/webrevs/8196565.1/ > > If yes, then I'd push it... > > Best regards > Christoph > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Freitag, 2. Februar 2018 15:17 > > To: 'Thomas St?fe' > > Cc: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > > dev at openjdk.java.net > > Subject: RE: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according > to > > AIX/PASE specification > > > > Hi Thomas, > > > > thanks for the review. > > > > Here is an update: http://cr.openjdk.java.net/~ > clanger/webrevs/8196565.1/ > > > > > But please, could refrain from changing webrevs in place? At least if > you > > > change large portions of the diff? I was reviewing the old one while it > > > changed under me, this was quite confusing. It also makes understanding > > the > > > mail thread difficult. > > > > Ok, sorry. This time I have an updated webrev in a new location ;-) > > > > > Why do you not handle the return value of mread_real_time() like we did > > > before on AIX? > > > > > > .. Oh, I read the IBM documentation now... What is this? > > > > > > Sorry for the rant. > > > > Yes, the IBM doc is a bit contradicting. Maybe you are right, we should > do it > > like before for AIX... > > > > > But back to your change, we did handle the return code of > > > mread_real_time() before, and arguably the coding before was more > > > correct. Well, depending on how we feel about the suggestion :) So I am > > > hesitant to throw that old coding out. Does your change work on older > AIX > > > releases and did you test on different Power platforms? Did we have an > > > actual problem on AIX, or is this fix just for PASE? > > > > The main motivation was to fix PASE and to get this aligned with OpenJDK. > > > > > - I know mread_real_time() is supposed to return monotonic values on > > AIX, > > > but I would feel better were we to assert the fact. > > > > Hm, the only thing way to assert monotonicity was to do CAS operations on > > AIX as well... > > We had some code like that in the SAP JVM before but I rather decided to > > throw it out > > there because I would like to trust mread_real_time specs for AIX. > > Additional CAS operations could mean a performance impact. > > > > > - I would leave George's name out of the sources. > > You're right - I did so already in my in-place update :) > > > > > - Small nit, could you rename max_nanos to something clearer, e.g. > > > mread_last_value or similar? And maybe place it physically near that > > > function? Ideally I would put it inside that function but I am not > sure if the > > > late initialization of then function-scope-static max_nanos would cause > > > problems. > > > > I compared to the code for BSD and solaris and want to keep it similar. > > So I rename it to max_real_time. But I would like to keep the variable > > declaration in the beginning of the file where local variables are > declared. > > > > I'm submitting the updated version of the code to our SAP JVM depot and > > then we'll get test results for various AIX and PASE runtimes and can > see if > > we hit one of the asserts. > > > > Thanks and best regards > > Christoph > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Feb 7 15:10:37 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 7 Feb 2018 15:10:37 +0000 Subject: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification In-Reply-To: References: <7155df04e4fc446b9a3494d321ca947a@sap.com> <46f140b3c50d4731a22f0cd97d07f16e@sap.com> <451f1e5f9a1847169eaf977c86bad571@sap.com> Message-ID: Thanks, done: http://hg.openjdk.java.net/jdk/hs/rev/45b6aae769cc I forgot to mention that I had added this code to the SAP JVM a few days ago and test showed no problems? From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Mittwoch, 7. Februar 2018 15:53 To: Langer, Christoph Cc: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification This looks fine. Yes, push it. ..Thomas On Wed, Feb 7, 2018 at 3:45 PM, Langer, Christoph > wrote: Hi Thomas, are you ok with the change as it is right now? http://cr.openjdk.java.net/~clanger/webrevs/8196565.1/ If yes, then I'd push it... Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 2. Februar 2018 15:17 > To: 'Thomas St?fe' > > Cc: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to > AIX/PASE specification > > Hi Thomas, > > thanks for the review. > > Here is an update: http://cr.openjdk.java.net/~clanger/webrevs/8196565.1/ > > > But please, could refrain from changing webrevs in place? At least if you > > change large portions of the diff? I was reviewing the old one while it > > changed under me, this was quite confusing. It also makes understanding > the > > mail thread difficult. > > Ok, sorry. This time I have an updated webrev in a new location ;-) > > > Why do you not handle the return value of mread_real_time() like we did > > before on AIX? > > > > .. Oh, I read the IBM documentation now... What is this? > > > > Sorry for the rant. > > Yes, the IBM doc is a bit contradicting. Maybe you are right, we should do it > like before for AIX... > > > But back to your change, we did handle the return code of > > mread_real_time() before, and arguably the coding before was more > > correct. Well, depending on how we feel about the suggestion :) So I am > > hesitant to throw that old coding out. Does your change work on older AIX > > releases and did you test on different Power platforms? Did we have an > > actual problem on AIX, or is this fix just for PASE? > > The main motivation was to fix PASE and to get this aligned with OpenJDK. > > > - I know mread_real_time() is supposed to return monotonic values on > AIX, > > but I would feel better were we to assert the fact. > > Hm, the only thing way to assert monotonicity was to do CAS operations on > AIX as well... > We had some code like that in the SAP JVM before but I rather decided to > throw it out > there because I would like to trust mread_real_time specs for AIX. > Additional CAS operations could mean a performance impact. > > > - I would leave George's name out of the sources. > You're right - I did so already in my in-place update :) > > > - Small nit, could you rename max_nanos to something clearer, e.g. > > mread_last_value or similar? And maybe place it physically near that > > function? Ideally I would put it inside that function but I am not sure if the > > late initialization of then function-scope-static max_nanos would cause > > problems. > > I compared to the code for BSD and solaris and want to keep it similar. > So I rename it to max_real_time. But I would like to keep the variable > declaration in the beginning of the file where local variables are declared. > > I'm submitting the updated version of the code to our SAP JVM depot and > then we'll get test results for various AIX and PASE runtimes and can see if > we hit one of the asserts. > > Thanks and best regards > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Feb 8 14:42:04 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 8 Feb 2018 15:42:04 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build Message-ID: Hi, may I please have reviews for this tiny fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ Thanks and Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Feb 8 14:49:13 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Feb 2018 14:49:13 +0000 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: <70b84988307847d888f514b5ef3ad776@sap.com> HI Thomas, looks good, thanks! Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > Sent: Donnerstag, 8. Februar 2018 15:42 > To: ppc-aix-port-dev at openjdk.java.net; build-dev dev at openjdk.java.net> > Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in > fastdebug build > > Hi, > > may I please have reviews for this tiny fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc- > overflow-in-fastdebug/webrev.00/webrev/ > > Thanks and Kind Regards, Thomas From matthias.baesken at sap.com Thu Feb 8 14:58:50 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 8 Feb 2018 14:58:50 +0000 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: <42c7d1d9fddc4136a4238daadc5a357f@sap.com> Hi Thomas , looks good to me ( not a Reviever however). Best Regards, Matthias From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe Sent: Donnerstag, 8. Februar 2018 15:42 To: ppc-aix-port-dev at openjdk.java.net; build-dev Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build Hi, may I please have reviews for this tiny fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ Thanks and Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Feb 8 17:09:03 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Feb 2018 09:09:03 -0800 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: Looks good, happy pushing without a sponsor! /Erik On 2018-02-08 06:42, Thomas St?fe wrote: > Hi, > > may I please have reviews for this tiny fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ > > Thanks and Kind Regards, Thomas From thomas.stuefe at gmail.com Thu Feb 8 17:11:28 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 8 Feb 2018 18:11:28 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: Hi Eric, On Thu, Feb 8, 2018 at 6:09 PM, Erik Joelsson wrote: > Looks good, happy pushing without a sponsor! > > /Erik > > Yes please, that would be nice! ..Thomas > > > On 2018-02-08 06:42, Thomas St?fe wrote: > >> Hi, >> >> may I please have reviews for this tiny fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc- >> overflow-in-fastdebug/webrev.00/webrev/ >> >> Thanks and Kind Regards, Thomas >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Feb 8 17:19:26 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 8 Feb 2018 18:19:26 +0100 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 In-Reply-To: References: <93fc660476f1490da815cdfba98ff623@sap.com> Message-ID: After discussing this off-line with Matthias and Goetz, I withdraw my opposition to this patch. Still not a big fan, but if everyone else (including David) is okay with this patch, I am too. Kind Regards, Thomas On Fri, Feb 2, 2018 at 10:20 AM, Thomas St?fe wrote: > > > On Fri, Feb 2, 2018 at 9:57 AM, David Holmes > wrote: > >> While I did not do an exhaustive check of the existing codes even the >> ones under >> >> // The following enums are not defined on all platforms. >> >> are at least defined by POSIX (even if just listed as "Reserved"). >> >> So I am still reluctant to introduce OS specific codes into a shared >> file. Plus there's the problem of different OS having different meanings >> for the same error code - suggesting per-OS specialization might be useful >> (but tricky to implement). >> >> That said I have to re-question whether we should be maintaining this >> explicit string mapping table anyway? strerror() is not thread-safe but >> strerror_l() seems to be, or at worst we need buffer management with >> strerror_r(). I know this topic has arisen before ... >> >> > How about we build the string table dynamically at process start by > iterating the first n errnos and calling strerror() :) Just kidding. > > Yes, I admit this table starts to feel weird. Original discussions were > here: https://bugs.openjdk.java.net/browse/JDK-8148425 > > I originally just wanted a static translation of errno numbers to > literalized errno constants (e.g. ETOOMANYREFS => "ETOOMANYREFS"), > because in 99% of cases where we call os::strerror() we do this to print > log output for developers, and as a developer I find "ETOOMANYREFS" far > more succinct than whatever strerror() returns. This would also bypass any > localization issues. If I see "ETOOMANYREFS" in a log file I immediately > know this is an error code from the libc, and can look it up in the man > page or google it. But when I read "Too many references: can't splice" - > potentially in Portuguese :) - I would have to dig a bit until I find out > what is actually happening. > > Of course, there are cases where we want the human readable, localized > text, but those cases are rarer and could be rewritten to use strerror_r. > > Just my 5 cent. > > ..Thomas > > Cheers, >> David >> >> On 2/02/2018 6:40 PM, Thomas St?fe wrote: >> >>> On Fri, Feb 2, 2018 at 9:02 AM, Baesken, Matthias < >>> matthias.baesken at sap.com> >>> wrote: >>> >>> >>>> - I do not really like spamming a shared file with AIX specific >>>> errno >>>> >>>> codes. >>>> >>>> >>>> >>>> Hi, I wrote ?for a few errnos ***we find*** on AIX 7.1? , not that >>>> they are AIX ***specific***. >>>> >>>> Checked the first few added ones : >>>> >>>> >>>> >>>> 1522 // some more errno numbers from AIX 7.1 (some are also >>>> supported >>>> on Linux) >>>> >>>> 1523 #ifdef ENOTBLK >>>> >>>> 1524 DEFINE_ENTRY(ENOTBLK, "Block device required") >>>> >>>> 1525 #endif >>>> >>>> 1526 #ifdef ECHRNG >>>> >>>> 1527 DEFINE_ENTRY(ECHRNG, "Channel number out of range") >>>> >>>> 1528 #endif >>>> >>>> 1529 #ifdef ELNRNG >>>> >>>> 1530 DEFINE_ENTRY(ELNRNG, "Link number out of range") >>>> >>>> 1531 #endif >>>> >>>> >>>> >>>> According to >>>> >>>> >>>> >>>> http://www.ioplex.com/~miallen/errcmp.html >>>> >>>> >>>> >>>> ENOTBLK ? found on AIX, Solaris, Linux, ? >>>> >>>> ECHRNG - found on AIX, Solaris, Linux >>>> >>>> ELNRNG - found on AIX, Solaris, Linux >>>> >>>> >>>> >>>> >>> The argument can easily made in the other direction. Checking the last n >>> errno codes I see: >>> >>> AIX, MAC + #ifdef EPROCLIM >>> AIX only + #ifdef ECORRUPT >>> AIX only + #ifdef ESYSERROR >>> AIX only + DEFINE_ENTRY(ESOFT, "I/O completed, but needs relocation") >>> AIX, MAC + #ifdef ENOATTR >>> AIX only + DEFINE_ENTRY(ESAD, "Security authentication denied") >>> AIX only + #ifdef ENOTRUST >>> ... >>> >>> >>> I would suggest to keep the multi-platform errnos in os.cpp just where >>>> they are . >>>> >>>> >>>> >>>> >>> I am still not convinced and like my original suggestion better. Lets >>> wait >>> for others to chime in and see what the consensus is. >>> >>> Best Regards, Thomas >>> >>> >>> >>> >>> - Can we move platform specific error codes to platform files? Eg by >>>> having a platform specific version pd_errno_to_string(), >>>> - which has a first shot at translating errno values, and only if >>>> that >>>> one returns no result reverting back to the shared version? >>>> - >>>> >>>> >>>> >>>> Can go through the list of added errnos and check if there are really a >>>> few in that exist only on AIX. >>>> >>>> If there are a significant number we might do what you suggest , but for >>>> only a small number I wouldn?t do it. >>>> >>>> >>>> >>>> >>>> >>>> Small nit: >>>>> >>>> >>>> >>>>> >>>> - DEFINE_ENTRY(ESTALE, "Reserved") >>>>> >>>> >>>> + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") >>>>> >>>> >>>> >>>>> >>>> I like the glibc text better, just "Stale file handle". NFS seems too >>>>> >>>> specific, can handles for other remote file systems not get stale? >>>> >>>> >>>> >>>> That?s fine with me, I can change this to what you suggest. >>>> >>>> >>>> >>>> Best regards, Matthias >>>> >>>> >>>> >>>> >>>> >>>> *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>>> *Sent:* Donnerstag, 1. Februar 2018 18:38 >>>> *To:* Baesken, Matthias >>>> *Cc:* hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>> *Subject:* Re: RFR : 8196578 : enhance errno_to_string function in >>>> os.cpp >>>> >>>> with some additional errno texts from AIX 7.1 >>>> >>>> >>>> >>>> Hi Matthias, >>>> >>>> >>>> >>>> This would probably better discussed in hotspot-runtime, no? >>>> >>>> >>>> >>>> The old error codes and their descriptions were Posix ( >>>> http://pubs.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html). >>>> I >>>> do not really like spamming a shared file with AIX specific errno codes. >>>> Can we move platform specific error codes to platform files? Eg by >>>> having a >>>> platform specific version pd_errno_to_string(), which has a first shot >>>> at >>>> translating errno values, and only if that one returns no result >>>> reverting >>>> back to the shared version? >>>> >>>> >>>> >>>> Small nit: >>>> >>>> >>>> >>>> - DEFINE_ENTRY(ESTALE, "Reserved") >>>> >>>> + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file handle") >>>> >>>> >>>> >>>> I like the glibc text better, just "Stale file handle". NFS seems too >>>> specific, can handles for other remote file systems not get stale? >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> >>>> On Thu, Feb 1, 2018 at 5:16 PM, Baesken, Matthias < >>>> matthias.baesken at sap.com> wrote: >>>> >>>> Hello , I enhanced the errno - to - error-text mappings in os.cpp >>>> for a few errnos we find on AIX 7.1 . >>>> Some of these added errnos are found as well on Linux (e.g. SLES 11 / >>>> 12 >>>> ). >>>> >>>> Could you please check and review ? >>>> >>>> ( btw. there is good cross platform info about the errnos at >>>> http://www.ioplex.com/~miallen/errcmp.html ) >>>> >>>> Bug : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8196578 >>>> >>>> Webrev : >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ >>>> >>>> >>>> >>>> Best regards, Matthias >>>> >>>> >>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Feb 8 17:19:55 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 8 Feb 2018 18:19:55 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: <42c7d1d9fddc4136a4238daadc5a357f@sap.com> References: <42c7d1d9fddc4136a4238daadc5a357f@sap.com> Message-ID: Thanks Matthias! On Thu, Feb 8, 2018 at 3:58 PM, Baesken, Matthias wrote: > Hi Thomas , looks good to me ( not a Reviever however). > > > > Best Regards, Matthias > > > > *From:* ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] > *On Behalf Of *Thomas St?fe > *Sent:* Donnerstag, 8. Februar 2018 15:42 > *To:* ppc-aix-port-dev at openjdk.java.net; build-dev < > build-dev at openjdk.java.net> > *Subject:* RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so > in fastdebug build > > > > Hi, > > > > may I please have reviews for this tiny fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ > 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ > > > > Thanks and Kind Regards, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Feb 8 17:20:02 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 8 Feb 2018 18:20:02 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: <70b84988307847d888f514b5ef3ad776@sap.com> References: <70b84988307847d888f514b5ef3ad776@sap.com> Message-ID: Thanks! On Thu, Feb 8, 2018 at 3:49 PM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > HI Thomas, > > looks good, thanks! > > Best regards, > Goetz. > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > > Sent: Donnerstag, 8. Februar 2018 15:42 > > To: ppc-aix-port-dev at openjdk.java.net; build-dev > dev at openjdk.java.net> > > Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in > > fastdebug build > > > > Hi, > > > > may I please have reviews for this tiny fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc- > > overflow-in-fastdebug/webrev.00/webrev/ > > > > Thanks and Kind Regards, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Feb 12 06:59:08 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Feb 2018 16:59:08 +1000 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 In-Reply-To: References: <93fc660476f1490da815cdfba98ff623@sap.com> Message-ID: <6fcb1c13-8ea8-8d8d-5f99-060575c7be48@oracle.com> On 9/02/2018 3:19 AM, Thomas St?fe wrote: > After discussing this off-line with Matthias and Goetz, I withdraw my > opposition to this patch. > > Still not a big fan, but if everyone else (including David) is okay with > this patch, I am too. I'm certainly not a fan of it - there are probably BSD, OS X and Solaris specific error codes that might be listed too. I'd prefer to see a RFE to rip this out completely (or deal with platform specific extensions). But until such a time I can grudgingly accept this patch. Cheers, David > Kind Regards, Thomas > > On Fri, Feb 2, 2018 at 10:20 AM, Thomas St?fe > wrote: > > > > On Fri, Feb 2, 2018 at 9:57 AM, David Holmes > > wrote: > > While I did not do an exhaustive check of the existing codes > even the ones under > > // The following enums are not defined on all platforms. > > are at least defined by POSIX (even if just listed as "Reserved"). > > So I am still reluctant to introduce OS specific codes into a > shared file. Plus there's the problem of different OS having > different meanings for the same error code - suggesting per-OS > specialization might be useful (but tricky to implement). > > That said I have to re-question whether we should be maintaining > this explicit string mapping table anyway? strerror() is not > thread-safe but strerror_l() seems to be, or at worst we need > buffer management with strerror_r(). I know this topic has > arisen before ... > > > How about we build the string table dynamically at process start by > iterating the first n errnos and calling strerror() :) Just kidding. > > Yes, I admit this table starts to feel weird. Original discussions > were here: https://bugs.openjdk.java.net/browse/JDK-8148425 > > > I originally just wanted a static translation of errno numbers to > literalized errno constants (e.g. ETOOMANYREFS => "ETOOMANYREFS"), > because in 99% of cases where we call os::strerror() we do this to > print log output for developers, and as a developer I find > "ETOOMANYREFS" far more succinct than whatever strerror() returns. > This would also bypass any localization issues. If I see > "ETOOMANYREFS" in a log file I immediately know this is an error > code from the libc, and can look it up in the man page or google it. > But when I read "Too many references: can't splice" - potentially in > Portuguese :) - I would have to dig a bit until I find out what is > actually happening. > > Of course, there are cases where we want the human readable, > localized text, but those cases are rarer and could be rewritten to > use strerror_r. > > Just my 5 cent. > > ..Thomas > > Cheers, > David > > On 2/02/2018 6:40 PM, Thomas St?fe wrote: > > On Fri, Feb 2, 2018 at 9:02 AM, Baesken, Matthias > > > wrote: > > > ? ? - I do not really like spamming a shared file with > AIX specific errno > > ? ? codes. > > > > Hi, I wrote? ?for a few errnos ***we find*** on AIX > 7.1?? ?,? not that > they are? AIX ***specific***. > > Checked the first few added ones : > > > > 1522? ? ?// some more errno numbers from AIX 7.1 (some > are also supported > on Linux) > > 1523? ? ?#ifdef ENOTBLK > > 1524? ? ?DEFINE_ENTRY(ENOTBLK, "Block device required") > > 1525? ? ?#endif > > 1526? ? ?#ifdef ECHRNG > > 1527? ? ?DEFINE_ENTRY(ECHRNG, "Channel number out of range") > > 1528? ? ?#endif > > 1529? ? ?#ifdef ELNRNG > > 1530? ? ?DEFINE_ENTRY(ELNRNG, "Link number out of range") > > 1531? ? ?#endif > > > > According to > > > > http://www.ioplex.com/~miallen/errcmp.html > > > > > ENOTBLK ? found on AIX, Solaris, Linux, ? > > ECHRNG? ?-? found on? AIX, Solaris, Linux > > ELNRNG? ?-? found on AIX, Solaris, Linux > > > > > The argument can easily made in the other direction. > Checking the last n > errno codes I see: > > AIX, MAC +? ? #ifdef EPROCLIM > AIX only +? ? #ifdef ECORRUPT > AIX only? +? ? #ifdef ESYSERROR > AIX only +? ? DEFINE_ENTRY(ESOFT, "I/O completed, but needs > relocation") > AIX, MAC +? ? #ifdef ENOATTR > AIX only +? ? DEFINE_ENTRY(ESAD, "Security authentication > denied") > AIX? only? +? ? #ifdef ENOTRUST > ... > > > I would suggest to keep the multi-platform? errnos in > os.cpp? just where > they are . > > > > > I am still not convinced and like my original suggestion > better. Lets wait > for others to chime in and see what the consensus is. > > Best Regards, Thomas > > > > > ? ? - Can we move platform specific error codes to > platform files? Eg by > ? ? having a platform specific version > pd_errno_to_string(), > ? ? - which has a first shot at translating errno > values, and only if that > ? ? one returns no result reverting back to the shared > version? > ? ? - > > > > Can go through the list of added? errnos and check if > there are really a > few in that exist only on AIX. > > If there are a significant number we might do what you > suggest , but for > only a small number I wouldn?t do it. > > > > > > Small nit: > > > > > - DEFINE_ENTRY(ESTALE, "Reserved") > > > + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS > file handle") > > > > > I like the glibc text better, just "Stale file > handle". NFS seems too > > specific, can handles for other remote file systems not > get stale? > > > > That?s fine with me, I can change this to what you suggest. > > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com > ] > *Sent:* Donnerstag, 1. Februar 2018 18:38 > *To:* Baesken, Matthias > > *Cc:* hotspot-dev at openjdk.java.net > ; > ppc-aix-port-dev at openjdk.java.net > > *Subject:* Re: RFR : 8196578 : enhance errno_to_string > function in os.cpp > > with some additional errno texts from AIX 7.1 > > > > Hi Matthias, > > > > This would probably better discussed in hotspot-runtime, no? > > > > The old error codes and their descriptions were Posix ( > http://pubs.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html > ). > I > do not really like spamming a shared file with AIX > specific errno codes. > Can we move platform specific error codes to platform > files? Eg by having a > platform specific version pd_errno_to_string(), which > has a first shot at > translating errno values, and only if that one returns > no result reverting > back to the shared version? > > > > Small nit: > > > > - DEFINE_ENTRY(ESTALE, "Reserved") > > + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file > handle") > > > > I like the glibc text better, just "Stale file handle". > NFS seems too > specific, can handles for other remote file systems not > get stale? > > Kind Regards, Thomas > > > > On Thu, Feb 1, 2018 at 5:16 PM, Baesken, Matthias < > matthias.baesken at sap.com > > wrote: > > Hello , I enhanced? the? errno - to -? error-text > mappings? ?in os.cpp > ? for a few errnos we find on AIX 7.1 . > Some of these added errnos are found as well on? Linux > (e.g. SLES 11 / 12 > ). > > Could you please check and review ? > > ( btw. there is good cross platform? info about the > errnos at > http://www.ioplex.com/~miallen/errcmp.html > ? ? ?) > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8196578 > > > Webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ > > > > > Best regards, Matthias > > > > > From thomas.stuefe at gmail.com Mon Feb 12 10:06:00 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 11:06:00 +0100 Subject: RFR : 8196578 : enhance errno_to_string function in os.cpp with some additional errno texts from AIX 7.1 In-Reply-To: <6fcb1c13-8ea8-8d8d-5f99-060575c7be48@oracle.com> References: <93fc660476f1490da815cdfba98ff623@sap.com> <6fcb1c13-8ea8-8d8d-5f99-060575c7be48@oracle.com> Message-ID: On Mon, Feb 12, 2018 at 7:59 AM, David Holmes wrote: > On 9/02/2018 3:19 AM, Thomas St?fe wrote: > >> After discussing this off-line with Matthias and Goetz, I withdraw my >> opposition to this patch. >> >> Still not a big fan, but if everyone else (including David) is okay with >> this patch, I am too. >> > > I'm certainly not a fan of it - there are probably BSD, OS X and Solaris > specific error codes that might be listed too. I'd prefer to see a RFE to > rip this out completely (or deal with platform specific extensions). But > until such a time I can grudgingly accept this patch. > > Thank you David. I agree, lets revisit this later with an RFE. ..Thomas > Cheers, > David > > Kind Regards, Thomas >> >> On Fri, Feb 2, 2018 at 10:20 AM, Thomas St?fe > > wrote: >> >> >> >> On Fri, Feb 2, 2018 at 9:57 AM, David Holmes >> > wrote: >> >> While I did not do an exhaustive check of the existing codes >> even the ones under >> >> // The following enums are not defined on all platforms. >> >> are at least defined by POSIX (even if just listed as "Reserved"). >> >> So I am still reluctant to introduce OS specific codes into a >> shared file. Plus there's the problem of different OS having >> different meanings for the same error code - suggesting per-OS >> specialization might be useful (but tricky to implement). >> >> That said I have to re-question whether we should be maintaining >> this explicit string mapping table anyway? strerror() is not >> thread-safe but strerror_l() seems to be, or at worst we need >> buffer management with strerror_r(). I know this topic has >> arisen before ... >> >> >> How about we build the string table dynamically at process start by >> iterating the first n errnos and calling strerror() :) Just kidding. >> >> Yes, I admit this table starts to feel weird. Original discussions >> were here: https://bugs.openjdk.java.net/browse/JDK-8148425 >> >> >> I originally just wanted a static translation of errno numbers to >> literalized errno constants (e.g. ETOOMANYREFS => "ETOOMANYREFS"), >> because in 99% of cases where we call os::strerror() we do this to >> print log output for developers, and as a developer I find >> "ETOOMANYREFS" far more succinct than whatever strerror() returns. >> This would also bypass any localization issues. If I see >> "ETOOMANYREFS" in a log file I immediately know this is an error >> code from the libc, and can look it up in the man page or google it. >> But when I read "Too many references: can't splice" - potentially in >> Portuguese :) - I would have to dig a bit until I find out what is >> actually happening. >> >> Of course, there are cases where we want the human readable, >> localized text, but those cases are rarer and could be rewritten to >> use strerror_r. >> >> Just my 5 cent. >> >> ..Thomas >> >> Cheers, >> David >> >> On 2/02/2018 6:40 PM, Thomas St?fe wrote: >> >> On Fri, Feb 2, 2018 at 9:02 AM, Baesken, Matthias >> > >> >> wrote: >> >> >> - I do not really like spamming a shared file with >> AIX specific errno >> >> codes. >> >> >> >> Hi, I wrote ?for a few errnos ***we find*** on AIX >> 7.1? , not that >> they are AIX ***specific***. >> >> Checked the first few added ones : >> >> >> >> 1522 // some more errno numbers from AIX 7.1 (some >> are also supported >> on Linux) >> >> 1523 #ifdef ENOTBLK >> >> 1524 DEFINE_ENTRY(ENOTBLK, "Block device required") >> >> 1525 #endif >> >> 1526 #ifdef ECHRNG >> >> 1527 DEFINE_ENTRY(ECHRNG, "Channel number out of >> range") >> >> 1528 #endif >> >> 1529 #ifdef ELNRNG >> >> 1530 DEFINE_ENTRY(ELNRNG, "Link number out of range") >> >> 1531 #endif >> >> >> >> According to >> >> >> >> http://www.ioplex.com/~miallen/errcmp.html >> >> >> >> >> ENOTBLK ? found on AIX, Solaris, Linux, ? >> >> ECHRNG - found on AIX, Solaris, Linux >> >> ELNRNG - found on AIX, Solaris, Linux >> >> >> >> >> The argument can easily made in the other direction. >> Checking the last n >> errno codes I see: >> >> AIX, MAC + #ifdef EPROCLIM >> AIX only + #ifdef ECORRUPT >> AIX only + #ifdef ESYSERROR >> AIX only + DEFINE_ENTRY(ESOFT, "I/O completed, but needs >> relocation") >> AIX, MAC + #ifdef ENOATTR >> AIX only + DEFINE_ENTRY(ESAD, "Security authentication >> denied") >> AIX only + #ifdef ENOTRUST >> ... >> >> >> I would suggest to keep the multi-platform errnos in >> os.cpp just where >> they are . >> >> >> >> >> I am still not convinced and like my original suggestion >> better. Lets wait >> for others to chime in and see what the consensus is. >> >> Best Regards, Thomas >> >> >> >> >> - Can we move platform specific error codes to >> platform files? Eg by >> having a platform specific version >> pd_errno_to_string(), >> - which has a first shot at translating errno >> values, and only if that >> one returns no result reverting back to the shared >> version? >> - >> >> >> >> Can go through the list of added errnos and check if >> there are really a >> few in that exist only on AIX. >> >> If there are a significant number we might do what you >> suggest , but for >> only a small number I wouldn?t do it. >> >> >> >> >> >> Small nit: >> >> >> >> >> - DEFINE_ENTRY(ESTALE, "Reserved") >> >> >> + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS >> file handle") >> >> >> >> >> I like the glibc text better, just "Stale file >> handle". NFS seems too >> >> specific, can handles for other remote file systems not >> get stale? >> >> >> >> That?s fine with me, I can change this to what you >> suggest. >> >> >> >> Best regards, Matthias >> >> >> >> >> >> *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com >> ] >> *Sent:* Donnerstag, 1. Februar 2018 18:38 >> *To:* Baesken, Matthias > > >> *Cc:* hotspot-dev at openjdk.java.net >> ; >> ppc-aix-port-dev at openjdk.java.net >> >> *Subject:* Re: RFR : 8196578 : enhance errno_to_string >> function in os.cpp >> >> with some additional errno texts from AIX 7.1 >> >> >> >> Hi Matthias, >> >> >> >> This would probably better discussed in hotspot-runtime, >> no? >> >> >> >> The old error codes and their descriptions were Posix ( >> http://pubs.opengroup.org/onli >> nepubs/000095399/basedefs/errno.h.html >> > inepubs/000095399/basedefs/errno.h.html>). >> I >> do not really like spamming a shared file with AIX >> specific errno codes. >> Can we move platform specific error codes to platform >> files? Eg by having a >> platform specific version pd_errno_to_string(), which >> has a first shot at >> translating errno values, and only if that one returns >> no result reverting >> back to the shared version? >> >> >> >> Small nit: >> >> >> >> - DEFINE_ENTRY(ESTALE, "Reserved") >> >> + DEFINE_ENTRY(ESTALE, "No filesystem / stale NFS file >> handle") >> >> >> >> I like the glibc text better, just "Stale file handle". >> NFS seems too >> specific, can handles for other remote file systems not >> get stale? >> >> Kind Regards, Thomas >> >> >> >> On Thu, Feb 1, 2018 at 5:16 PM, Baesken, Matthias < >> matthias.baesken at sap.com >> > wrote: >> >> Hello , I enhanced the errno - to - error-text >> mappings in os.cpp >> for a few errnos we find on AIX 7.1 . >> Some of these added errnos are found as well on Linux >> (e.g. SLES 11 / 12 >> ). >> >> Could you please check and review ? >> >> ( btw. there is good cross platform info about the >> errnos at >> http://www.ioplex.com/~miallen/errcmp.html >> ) >> >> Bug : >> >> https://bugs.openjdk.java.net/browse/JDK-8196578 >> >> >> Webrev : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8196578/ >> >> >> >> >> Best regards, Matthias >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Feb 12 14:32:41 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 15:32:41 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: Hi all, may I have a sponsor please? I am not sure whether I am allowed to push myself, and if yes, to which repository. I have three reviewers already. Thank you! Thomas On Thu, Feb 8, 2018 at 3:42 PM, Thomas St?fe wrote: > Hi, > > may I please have reviews for this tiny fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ > 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ > > Thanks and Kind Regards, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Feb 12 14:33:39 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 15:33:39 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: Please disregard my last mail, the change has just been pushed. Thanks, Thomas On Mon, Feb 12, 2018 at 3:32 PM, Thomas St?fe wrote: > Hi all, > > may I have a sponsor please? I am not sure whether I am allowed to push > myself, and if yes, to which repository. > > I have three reviewers already. > > Thank you! > > Thomas > > > On Thu, Feb 8, 2018 at 3:42 PM, Thomas St?fe > wrote: > >> Hi, >> >> may I please have reviews for this tiny fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 >> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488- >> aix-toc-overflow-in-fastdebug/webrev.00/webrev/ >> >> Thanks and Kind Regards, Thomas >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Mon Feb 12 15:41:37 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Feb 2018 16:41:37 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: On 2018-02-12 15:32, Thomas St?fe wrote: > Hi all, > > may I have a sponsor please? I am not sure whether I am allowed to push > myself, and if yes, to which repository. Since the removal of generated-configure.sh you don't need a sponsor just because you touch autoconf files. So for jdk/jdk, you're free to just push it. As far as I understand, you're also free to just push it to jdk/hs nowadays, if that were you want it to go, but someone from hotspot should probably confirm this. /Magnus > > I have three reviewers already. > > Thank you! > > Thomas > > > On Thu, Feb 8, 2018 at 3:42 PM, Thomas St?fe > wrote: > >> Hi, >> >> may I please have reviews for this tiny fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 >> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ >> 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ >> >> Thanks and Kind Regards, Thomas >> From thomas.stuefe at gmail.com Mon Feb 12 15:52:34 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 16:52:34 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: On Mon, Feb 12, 2018 at 4:41 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-02-12 15:32, Thomas St?fe wrote: > >> Hi all, >> >> may I have a sponsor please? I am not sure whether I am allowed to push >> myself, and if yes, to which repository. >> > > Since the removal of generated-configure.sh you don't need a sponsor just > because you touch autoconf files. So for jdk/jdk, you're free to just push > it. As far as I understand, you're also free to just push it to jdk/hs > nowadays, if that were you want it to go, but someone from hotspot should > probably confirm this. > > Ok. Nice to know. Thanks. ..Thomas > /Magnus > > > >> I have three reviewers already. >> >> Thank you! >> >> Thomas >> >> >> On Thu, Feb 8, 2018 at 3:42 PM, Thomas St?fe >> wrote: >> >> Hi, >>> >>> may I please have reviews for this tiny fix: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 >>> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ >>> 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ >>> >>> Thanks and Kind Regards, Thomas >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raduandritoiu at gmail.com Tue Feb 13 16:39:16 2018 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Tue, 13 Feb 2018 18:39:16 +0200 Subject: Compile JRE for PPC 32 bit In-Reply-To: References: <20180125153449.GB4563@vimes> <9b6e853d-4f5c-e01a-1ec6-bd85031717c1@azul.com> Message-ID: Hello, I am trying to to build a HEADLESS jre only. I observed that: - in the jdk solaris sources related to drawing the "HEADLESS" define is used a lot - when building "libawt.so" the flag -DHEADLESS has no mechanism to being set, so I presume that libawt.so will always be HEADFUL - when building "libawt_headless.so" and linking "libjawt.so", BUILD_HEADLESS_ONLY variable is used, but I do not see any mechanism to set it I am adding the parameter "--disable-headful" when running the "configure" script. And this does set: SUPPORT_HEADFUL:=no SUPPORT_HEADLESS:=yes BUILD_HEADLESS:=true but does nothing to set BUILD_HEADLESS_ONLY. Should I manually add BUILD_HEADLESS_ONLY variable in Awt2dLibraries.gmk and -DHEADLESS when compiling "libawt.so" ? Thank you, Radu On Thu, Feb 1, 2018 at 3:34 PM, Radu Andritoiu wrote: > Hello Adrian, > > Should jdk8u compile natively on x86 with "zero" jvm variant? > I was trying to do that to see if the output may help me run the cross > compile. > > Thank you, > Radu > > > On Mon, Jan 29, 2018 at 11:36 AM, Radu Andritoiu > wrote: > >> Hello Anton, >> >> Glad to hear you have a PPC 32 port of jdk8. Does it have the fix for >> RMI vulnerability (https://access.redhat.com/security/cve/cve-2017-3241 >> ). >> I will tell this to my manager and ask what direction he wants to go. >> >> Thank you, >> Radu >> >> >> On Fri, Jan 26, 2018 at 6:44 PM, Anton Kozlov wrote: >> >>> Hi, All, >>> >>> sorry, completely overlooked the thread. >>> >>> On 25.01.2018 19:11, Volker Simonis wrote: >>> > Azul is known to have a 32bit ppc port, but they havn't contributed it >>> > to the OpenJDK yet. >>> >>> yes, Azul have ppc32 port of jdk8u, in SPE and FPU variants. >>> >>> Yes, we want to contribte the support to OpenJDK, but it complicated. >>> To reveal source code we need to make up-port to current jdk development >>> tree (11?) first, and it's heavy. >>> >>> We have no reasonable estimates when the up-port will be ready. This is >>> also pulls us back from creating new Project, as it will be out of sync >>> with development branch of OpenJDK. >>> >>> Thanks, >>> Anton >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From glaubitz at physik.fu-berlin.de Tue Feb 13 18:26:13 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 13 Feb 2018 19:26:13 +0100 Subject: Compile JRE for PPC 32 bit In-Reply-To: References: <20180125153449.GB4563@vimes> <9b6e853d-4f5c-e01a-1ec6-bd85031717c1@azul.com> Message-ID: <6E6986CA-3D84-4881-B55C-272ECA1E016C@physik.fu-berlin.de> Hi Radu! I apologize for the late reply! Yes, the Zero variant should compile natively and also supports cross-builds. However, you will most likely need some patches to fix minor issues with Zero to get it to build in jdk8u. The situation is much better with jdk10 though where Zero builds fine on most architectures without needing any additional patches. Let me know if you run into a specific problem with jdk8u and I will help you. Adrian > On Feb 1, 2018, at 2:34 PM, Radu Andritoiu wrote: > > Hello Adrian, > > Should jdk8u compile natively on x86 with "zero" jvm variant? > I was trying to do that to see if the output may help me run the cross compile. > > Thank you, > Radu > > >> On Mon, Jan 29, 2018 at 11:36 AM, Radu Andritoiu wrote: >> Hello Anton, >> >> Glad to hear you have a PPC 32 port of jdk8. Does it have the fix for RMI vulnerability (https://access.redhat.com/security/cve/cve-2017-3241). >> I will tell this to my manager and ask what direction he wants to go. >> >> Thank you, >> Radu >> >> >>> On Fri, Jan 26, 2018 at 6:44 PM, Anton Kozlov wrote: >>> Hi, All, >>> >>> sorry, completely overlooked the thread. >>> >>> On 25.01.2018 19:11, Volker Simonis wrote: >>> > Azul is known to have a 32bit ppc port, but they havn't contributed it >>> > to the OpenJDK yet. >>> >>> yes, Azul have ppc32 port of jdk8u, in SPE and FPU variants. >>> >>> Yes, we want to contribte the support to OpenJDK, but it complicated. >>> To reveal source code we need to make up-port to current jdk development tree (11?) first, and it's heavy. >>> >>> We have no reasonable estimates when the up-port will be ready. This is also pulls us back from creating new Project, as it will be out of sync with development branch of OpenJDK. >>> >>> Thanks, >>> Anton >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raduandritoiu at gmail.com Tue Feb 13 21:16:52 2018 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Tue, 13 Feb 2018 23:16:52 +0200 Subject: Compile JRE for PPC 32 bit In-Reply-To: <6E6986CA-3D84-4881-B55C-272ECA1E016C@physik.fu-berlin.de> References: <20180125153449.GB4563@vimes> <9b6e853d-4f5c-e01a-1ec6-bd85031717c1@azul.com> <6E6986CA-3D84-4881-B55C-272ECA1E016C@physik.fu-berlin.de> Message-ID: Hello Adrian, I am almost done with compiling jdk8, so I try to succeed with this one rather than switching to jdk10. I managed to compile "hotspot" target, and now I am having some trouble with the "jdk" target: I need to compile a HEADLESS jre version only, because the machine it will run afterwards doesn't have X11. I observed that: - in the jdk code sources related to drawing, the "HEADLESS" define is used a lot - when building "libawt.so" the flag -DHEADLESS has no mechanism for being set, so I presume that libawt.so will always be HEADFUL - when building "libawt_headless.so" and linking "libjawt.so", BUILD_HEADLESS_ONLY variable is used, but I do not see any mechanism to set it I am adding the parameter "--disable-headful" when running the "configure" script. And this does set: SUPPORT_HEADFUL:=no SUPPORT_HEADLESS:=yes BUILD_HEADLESS:=true but does nothing to set BUILD_HEADLESS_ONLY. Should I manually add BUILD_HEADLESS_ONLY variable in Awt2dLibraries.gmk and -DHEADLESS when compiling "libawt.so" ? Thank you, Radu On Tue, Feb 13, 2018 at 8:26 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hi Radu! > > I apologize for the late reply! > > Yes, the Zero variant should compile natively and also supports > cross-builds. However, you will most likely need some patches to fix minor > issues with Zero to get it to build in jdk8u. > > The situation is much better with jdk10 though where Zero builds fine on > most architectures without needing any additional patches. > > Let me know if you run into a specific problem with jdk8u and I will help > you. > > Adrian > > On Feb 1, 2018, at 2:34 PM, Radu Andritoiu > wrote: > > Hello Adrian, > > Should jdk8u compile natively on x86 with "zero" jvm variant? > I was trying to do that to see if the output may help me run the cross > compile. > > Thank you, > Radu > > > On Mon, Jan 29, 2018 at 11:36 AM, Radu Andritoiu > wrote: > >> Hello Anton, >> >> Glad to hear you have a PPC 32 port of jdk8. Does it have the fix for >> RMI vulnerability (https://access.redhat.com/security/cve/cve-2017-3241 >> ). >> I will tell this to my manager and ask what direction he wants to go. >> >> Thank you, >> Radu >> >> >> On Fri, Jan 26, 2018 at 6:44 PM, Anton Kozlov wrote: >> >>> Hi, All, >>> >>> sorry, completely overlooked the thread. >>> >>> On 25.01.2018 19:11, Volker Simonis wrote: >>> > Azul is known to have a 32bit ppc port, but they havn't contributed it >>> > to the OpenJDK yet. >>> >>> yes, Azul have ppc32 port of jdk8u, in SPE and FPU variants. >>> >>> Yes, we want to contribte the support to OpenJDK, but it complicated. >>> To reveal source code we need to make up-port to current jdk development >>> tree (11?) first, and it's heavy. >>> >>> We have no reasonable estimates when the up-port will be ready. This is >>> also pulls us back from creating new Project, as it will be out of sync >>> with development branch of OpenJDK. >>> >>> Thanks, >>> Anton >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akozlov at azul.com Wed Feb 14 13:04:36 2018 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 14 Feb 2018 16:04:36 +0300 Subject: Compile JRE for PPC 32 bit In-Reply-To: References: <20180125153449.GB4563@vimes> <9b6e853d-4f5c-e01a-1ec6-bd85031717c1@azul.com> <6E6986CA-3D84-4881-B55C-272ECA1E016C@physik.fu-berlin.de> Message-ID: <1e8bbd1e-28f0-2467-18ab-a9c3df0164aa@azul.com> Hi Radu, from my experience, next is enough to get headless build: export BUILD_HEADLESS=true export BUILD_HEADLESS_ONLY=true add "-DHEADLESS=true" to CFLAGS ./configure --without-x --disable-headful Probably, some of these may be redundant... But I don't know any issues so far. Thanks, Anton On 14.02.2018 00:16, Radu Andritoiu wrote: > Hello Adrian, > > I am almost done with compiling jdk8, so I try to succeed with this one rather than switching to jdk10. > I managed to compile "hotspot" target, and now I am having some trouble with the "jdk" target: I need to compile a HEADLESS jre version only, because the machine it will run afterwards doesn't have X11. > > I observed that: > - in the jdk code sources related to drawing, the "HEADLESS" define is used a lot > - when building "libawt.so" the flag -DHEADLESS has no mechanism for being set, so I presume that libawt.so will always be HEADFUL > - when building "libawt_headless.so" and linking "libjawt.so", BUILD_HEADLESS_ONLY variable is used, but I do not see any mechanism to set it > > I am adding the parameter "--disable-headful" when running the "configure" script. > And this does set: > > SUPPORT_HEADFUL:=no > SUPPORT_HEADLESS:=yes > BUILD_HEADLESS:=true > > but does nothing to set BUILD_HEADLESS_ONLY. > > Should I manually add BUILD_HEADLESS_ONLY variable in Awt2dLibraries.gmk and -DHEADLESS when compiling "libawt.so" ? > > > Thank you, > Radu > > > On Tue, Feb 13, 2018 at 8:26 PM, John Paul Adrian Glaubitz > wrote: > > Hi Radu! > > I apologize for the late reply! > > Yes, the Zero variant should compile natively and also supports cross-builds. However, you will most likely need some patches to fix minor issues with Zero to get it to build in jdk8u. > > The situation is much better with jdk10 though where Zero builds fine on most architectures without needing any additional patches. > > Let me know if you run into a specific problem with jdk8u and I will help you. > > Adrian > > On Feb 1, 2018, at 2:34 PM, Radu Andritoiu > wrote: > >> Hello Adrian, >> >> Should jdk8u compile natively on x86 with "zero" jvm variant? >> I was trying to do that to see if the output may help me run the cross compile. >> >> Thank you, >> Radu >> >> >> On Mon, Jan 29, 2018 at 11:36 AM, Radu Andritoiu > wrote: >> >> Hello Anton, >> >> Glad to hear you have a PPC 32 port of jdk8. Does it have the fix for RMI vulnerability (https://access.redhat.com/security/cve/cve-2017-3241 ). >> I will tell this to my manager and ask what direction he wants to go. >> >> Thank you, >> Radu >> >> >> On Fri, Jan 26, 2018 at 6:44 PM, Anton Kozlov > wrote: >> >> Hi, All, >> >> sorry, completely overlooked the thread. >> >> On 25.01.2018 19:11, Volker Simonis wrote: >> > Azul is known to have a 32bit ppc port, but they havn't contributed it >> > to the OpenJDK yet. >> >> yes, Azul have ppc32 port of jdk8u, in SPE and FPU variants. >> >> Yes, we want to contribte the support to OpenJDK, but it complicated. >> To reveal source code we need to make up-port to current jdk development tree (11?) first, and it's heavy. >> >> We have no reasonable estimates when the up-port will be ready. This is also pulls us back from creating new Project, as it will be out of sync with development branch of OpenJDK. >> >> Thanks, >> Anton >> >> >> > From raduandritoiu at gmail.com Wed Feb 14 13:26:49 2018 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Wed, 14 Feb 2018 15:26:49 +0200 Subject: Compile JRE for PPC 32 bit In-Reply-To: <1e8bbd1e-28f0-2467-18ab-a9c3df0164aa@azul.com> References: <20180125153449.GB4563@vimes> <9b6e853d-4f5c-e01a-1ec6-bd85031717c1@azul.com> <6E6986CA-3D84-4881-B55C-272ECA1E016C@physik.fu-berlin.de> <1e8bbd1e-28f0-2467-18ab-a9c3df0164aa@azul.com> Message-ID: Hi Adrian, Thank you very much for the reply. I did the same thing, but added -DHEADLESS manually only where I needed it, not generally. It is great to know I can add it in general and not have any troubles. Thank you again, Radu On Wed, Feb 14, 2018 at 3:04 PM, Anton Kozlov wrote: > Hi Radu, > > from my experience, next is enough to get headless build: > > export BUILD_HEADLESS=true > export BUILD_HEADLESS_ONLY=true > add "-DHEADLESS=true" to CFLAGS > ./configure --without-x --disable-headful > > Probably, some of these may be redundant... But I don't know any issues so > far. > > Thanks, > Anton > > On 14.02.2018 00:16, Radu Andritoiu wrote: > > Hello Adrian, > > > > I am almost done with compiling jdk8, so I try to succeed with this one > rather than switching to jdk10. > > I managed to compile "hotspot" target, and now I am having some trouble > with the "jdk" target: I need to compile a HEADLESS jre version only, > because the machine it will run afterwards doesn't have X11. > > > > I observed that: > > - in the jdk code sources related to drawing, the "HEADLESS" define is > used a lot > > - when building "libawt.so" the flag -DHEADLESS has no mechanism for > being set, so I presume that libawt.so will always be HEADFUL > > - when building "libawt_headless.so" and linking "libjawt.so", > BUILD_HEADLESS_ONLY variable is used, but I do not see any mechanism to set > it > > > > I am adding the parameter "--disable-headful" when running the > "configure" script. > > And this does set: > > > > SUPPORT_HEADFUL:=no > > SUPPORT_HEADLESS:=yes > > BUILD_HEADLESS:=true > > > > but does nothing to set BUILD_HEADLESS_ONLY. > > > > Should I manually add BUILD_HEADLESS_ONLY variable in Awt2dLibraries.gmk > and -DHEADLESS when compiling "libawt.so" ? > > > > > > Thank you, > > Radu > > > > > > On Tue, Feb 13, 2018 at 8:26 PM, John Paul Adrian Glaubitz < > glaubitz at physik.fu-berlin.de > wrote: > > > > Hi Radu! > > > > I apologize for the late reply! > > > > Yes, the Zero variant should compile natively and also supports > cross-builds. However, you will most likely need some patches to fix minor > issues with Zero to get it to build in jdk8u. > > > > The situation is much better with jdk10 though where Zero builds > fine on most architectures without needing any additional patches. > > > > Let me know if you run into a specific problem with jdk8u and I will > help you. > > > > Adrian > > > > On Feb 1, 2018, at 2:34 PM, Radu Andritoiu > wrote: > > > >> Hello Adrian, > >> > >> Should jdk8u compile natively on x86 with "zero" jvm variant? > >> I was trying to do that to see if the output may help me run the > cross compile. > >> > >> Thank you, > >> Radu > >> > >> > >> On Mon, Jan 29, 2018 at 11:36 AM, Radu Andritoiu < > raduandritoiu at gmail.com > wrote: > >> > >> Hello Anton, > >> > >> Glad to hear you have a PPC 32 port of jdk8. Does it have the > fix for RMI vulnerability (https://access.redhat.com/ > security/cve/cve-2017-3241 security/cve/cve-2017-3241>). > >> I will tell this to my manager and ask what direction he wants > to go. > >> > >> Thank you, > >> Radu > >> > >> > >> On Fri, Jan 26, 2018 at 6:44 PM, Anton Kozlov > wrote: > >> > >> Hi, All, > >> > >> sorry, completely overlooked the thread. > >> > >> On 25.01.2018 19:11, Volker Simonis wrote: > >> > Azul is known to have a 32bit ppc port, but they havn't > contributed it > >> > to the OpenJDK yet. > >> > >> yes, Azul have ppc32 port of jdk8u, in SPE and FPU variants. > >> > >> Yes, we want to contribte the support to OpenJDK, but it > complicated. > >> To reveal source code we need to make up-port to current > jdk development tree (11?) first, and it's heavy. > >> > >> We have no reasonable estimates when the up-port will be > ready. This is also pulls us back from creating new Project, as it will be > out of sync with development branch of OpenJDK. > >> > >> Thanks, > >> Anton > >> > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raduandritoiu at gmail.com Wed Feb 14 16:40:48 2018 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Wed, 14 Feb 2018 18:40:48 +0200 Subject: Compile JRE for PPC 32 bit In-Reply-To: References: <20180125153449.GB4563@vimes> <9b6e853d-4f5c-e01a-1ec6-bd85031717c1@azul.com> <6E6986CA-3D84-4881-B55C-272ECA1E016C@physik.fu-berlin.de> <1e8bbd1e-28f0-2467-18ab-a9c3df0164aa@azul.com> Message-ID: Hi, Is it ok to disable "cups" ? I see I do not have it in the tool chain. Also is it ok to disable it from the configure script by adding "CUPS_NOT_NEEDED=yes" ? Thank you, Radu On Wed, Feb 14, 2018 at 3:26 PM, Radu Andritoiu wrote: > Hi Adrian, > > Thank you very much for the reply. > I did the same thing, but added -DHEADLESS manually only where I needed > it, not generally. > It is great to know I can add it in general and not have any troubles. > > > Thank you again, > Radu > > > On Wed, Feb 14, 2018 at 3:04 PM, Anton Kozlov wrote: > >> Hi Radu, >> >> from my experience, next is enough to get headless build: >> >> export BUILD_HEADLESS=true >> export BUILD_HEADLESS_ONLY=true >> add "-DHEADLESS=true" to CFLAGS >> ./configure --without-x --disable-headful >> >> Probably, some of these may be redundant... But I don't know any issues >> so far. >> >> Thanks, >> Anton >> >> On 14.02.2018 00:16, Radu Andritoiu wrote: >> > Hello Adrian, >> > >> > I am almost done with compiling jdk8, so I try to succeed with this one >> rather than switching to jdk10. >> > I managed to compile "hotspot" target, and now I am having some trouble >> with the "jdk" target: I need to compile a HEADLESS jre version only, >> because the machine it will run afterwards doesn't have X11. >> > >> > I observed that: >> > - in the jdk code sources related to drawing, the "HEADLESS" define is >> used a lot >> > - when building "libawt.so" the flag -DHEADLESS has no mechanism for >> being set, so I presume that libawt.so will always be HEADFUL >> > - when building "libawt_headless.so" and linking "libjawt.so", >> BUILD_HEADLESS_ONLY variable is used, but I do not see any mechanism to set >> it >> > >> > I am adding the parameter "--disable-headful" when running the >> "configure" script. >> > And this does set: >> > >> > SUPPORT_HEADFUL:=no >> > SUPPORT_HEADLESS:=yes >> > BUILD_HEADLESS:=true >> > >> > but does nothing to set BUILD_HEADLESS_ONLY. >> > >> > Should I manually add BUILD_HEADLESS_ONLY variable in >> Awt2dLibraries.gmk and -DHEADLESS when compiling "libawt.so" ? >> > >> > >> > Thank you, >> > Radu >> > >> > >> > On Tue, Feb 13, 2018 at 8:26 PM, John Paul Adrian Glaubitz < >> glaubitz at physik.fu-berlin.de > >> wrote: >> > >> > Hi Radu! >> > >> > I apologize for the late reply! >> > >> > Yes, the Zero variant should compile natively and also supports >> cross-builds. However, you will most likely need some patches to fix minor >> issues with Zero to get it to build in jdk8u. >> > >> > The situation is much better with jdk10 though where Zero builds >> fine on most architectures without needing any additional patches. >> > >> > Let me know if you run into a specific problem with jdk8u and I >> will help you. >> > >> > Adrian >> > >> > On Feb 1, 2018, at 2:34 PM, Radu Andritoiu > > wrote: >> > >> >> Hello Adrian, >> >> >> >> Should jdk8u compile natively on x86 with "zero" jvm variant? >> >> I was trying to do that to see if the output may help me run the >> cross compile. >> >> >> >> Thank you, >> >> Radu >> >> >> >> >> >> On Mon, Jan 29, 2018 at 11:36 AM, Radu Andritoiu < >> raduandritoiu at gmail.com > wrote: >> >> >> >> Hello Anton, >> >> >> >> Glad to hear you have a PPC 32 port of jdk8. Does it have the >> fix for RMI vulnerability (https://access.redhat.com/sec >> urity/cve/cve-2017-3241 > urity/cve/cve-2017-3241>). >> >> I will tell this to my manager and ask what direction he wants >> to go. >> >> >> >> Thank you, >> >> Radu >> >> >> >> >> >> On Fri, Jan 26, 2018 at 6:44 PM, Anton Kozlov < >> akozlov at azul.com > wrote: >> >> >> >> Hi, All, >> >> >> >> sorry, completely overlooked the thread. >> >> >> >> On 25.01.2018 19:11, Volker Simonis wrote: >> >> > Azul is known to have a 32bit ppc port, but they havn't >> contributed it >> >> > to the OpenJDK yet. >> >> >> >> yes, Azul have ppc32 port of jdk8u, in SPE and FPU >> variants. >> >> >> >> Yes, we want to contribte the support to OpenJDK, but it >> complicated. >> >> To reveal source code we need to make up-port to current >> jdk development tree (11?) first, and it's heavy. >> >> >> >> We have no reasonable estimates when the up-port will be >> ready. This is also pulls us back from creating new Project, as it will be >> out of sync with development branch of OpenJDK. >> >> >> >> Thanks, >> >> Anton >> >> >> >> >> >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akozlov at azul.com Wed Feb 14 16:51:15 2018 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 14 Feb 2018 19:51:15 +0300 Subject: Compile JRE for PPC 32 bit In-Reply-To: References: <20180125153449.GB4563@vimes> <9b6e853d-4f5c-e01a-1ec6-bd85031717c1@azul.com> <6E6986CA-3D84-4881-B55C-272ECA1E016C@physik.fu-berlin.de> <1e8bbd1e-28f0-2467-18ab-a9c3df0164aa@azul.com> Message-ID: Hi, On 14.02.2018 19:40, Radu Andritoiu wrote: > Is it ok to disable "cups" ? I see I do not have it in the tool chain. Let me cite Volker :) http://openjdk.5641.n7.nabble.com/Why-is-CUPS-required-td134487.html#a134707 > Also is it ok to disable it from the configure script by adding "CUPS_NOT_NEEDED=yes" ? I can't tell for sure. You can try and see what will happen. There are chances jdk is strongly wants cups on your platform (the link above) and will reject the value. Thanks, Anton