From erik.joelsson at oracle.com Fri Feb 1 00:23:49 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 31 Jan 2019 16:23:49 -0800 Subject: RFR: JDK-8218177: Bump jib format_version to support new devkit archive layout Message-ID: With the new devkits I deployed recently (Oracle internal), the file layout changed as a top level directory inside the tar archive was introduced. This works in most cases, but there are certain situations where jib does not handle this well. This causes AOT testing on Linux to stop working with the run-test-prebuilt make target. This issue is being fixed in Jib, but to activate the fix a bump in the format_version is required. This patch does that, as well as adjusting to conform to the new behavior. Bug: https://bugs.openjdk.java.net/browse/JDK-8218177 Webrev: http://cr.openjdk.java.net/~erikj/8218177/webrev.01/ (note that the Jib fix is not yet live in production) /Erik From christian.tornqvist at oracle.com Fri Feb 1 00:32:12 2019 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 31 Jan 2019 16:32:12 -0800 Subject: RFR: JDK-8218177: Bump jib format_version to support new devkit archive layout In-Reply-To: References: Message-ID: <8CFBD180-8FFD-4EFB-BB2E-A6DA1EF89C11@oracle.com> Looks good. Thanks, Christian > On Jan 31, 2019, at 4:23 PM, Erik Joelsson wrote: > > With the new devkits I deployed recently (Oracle internal), the file layout changed as a top level directory inside the tar archive was introduced. This works in most cases, but there are certain situations where jib does not handle this well. This causes AOT testing on Linux to stop working with the run-test-prebuilt make target. > > This issue is being fixed in Jib, but to activate the fix a bump in the format_version is required. This patch does that, as well as adjusting to conform to the new behavior. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218177 > > Webrev: http://cr.openjdk.java.net/~erikj/8218177/webrev.01/ > > (note that the Jib fix is not yet live in production) > > /Erik > From tim.bell at oracle.com Fri Feb 1 00:35:35 2019 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 31 Jan 2019 16:35:35 -0800 Subject: RFR: JDK-8218177: Bump jib format_version to support new devkit archive layout In-Reply-To: References: Message-ID: <5C539457.8060600@oracle.com> Erik: > With the new devkits I deployed recently (Oracle internal), the file > layout changed as a top level directory inside the tar archive was > introduced. This works in most cases, but there are certain situations > where jib does not handle this well. This causes AOT testing on Linux to > stop working with the run-test-prebuilt make target. > > This issue is being fixed in Jib, but to activate the fix a bump in the > format_version is required. This patch does that, as well as adjusting > to conform to the new behavior. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218177 > > Webrev: http://cr.openjdk.java.net/~erikj/8218177/webrev.01/ > > (note that the Jib fix is not yet live in production) Looks good. Tim From david.holmes at oracle.com Fri Feb 1 04:23:46 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 14:23:46 +1000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: Hi Matthias, On 1/02/2019 12:50 am, Baesken, Matthias wrote: > Please review this small webrev . It contains a few changes for building hotspot on AIX with xlclang++ / xlc16 . > ( most likely switching to xlclang++ / xlc16 will be a must once we introduce C++11/14 features ) > > Some comments on the changes : > > > - porting_aix.cpp : workaround for demangle.h (does not work with xlclang++) Can't comment as I know nothing about it. > - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to assigning false to AllocateHeapAt which is a bad idea (and does not work with xlclang++) Good catch! > - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not have #error ... in this case Confused. Which other xlc compilers set __GNUC_ as you are changing this for all of them? Though to be honest I don't understand this whole section anyway - we have a lengthy comment saying why you can't necessarily assign NULL to an integer type and to use NULL_WORD instead but then it's defined as NULL anyway! I wonder if we used to have some other conditions there where it was something different? In any case having an if and else that do exactly the same thing seems rather pointless to me. Thanks, David > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8218136 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ > > > Thanks, Matthias > From alexander.matveev at oracle.com Fri Feb 1 04:22:58 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 31 Jan 2019 20:22:58 -0800 Subject: RFR: JDK-8217317 : Create jpackage native library for windows Message-ID: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - jpackage launcher will now build same as Linux and OS X using SetupBuildLauncher. - jpackage.dll was added based on Windows jpackage.exe launcher which will have icon swap and version swap functionality called via JNI. - Some code formatting, clean up and minor improvements where done to icon and version swap code. No functional changes. - Windows registry will be read and enumerated via JNI as well. - isDirectoryInExclusionPath() will use native path comparison, since paths in registry and temp folder returned by Java code can be in short or long format, thus simple string comparison will not work. - Windows Defender workaround warning will be checked for --build-root as well if it is set. - Removed extra escaping from JPackageHelper for Windows, otherwise tests fails due to incorrect escaping. Our launcher used CreateProcess to launch java.exe by passing args from main() to CreateProcess. This is why I think we required extra escaping. [1] https://bugs.openjdk.java.net/browse/JDK-8217317 [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ Thanks, Alexander From matthias.baesken at sap.com Fri Feb 1 08:14:19 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 1 Feb 2019 08:14:19 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: <747D25F3-C523-439F-93FD-E20C7BFCD6B7@oracle.com> References: <747D25F3-C523-439F-93FD-E20C7BFCD6B7@oracle.com> Message-ID: Hi Magnus , yes IBM offers now in xlc 16.1 both the legacy xlc and additionally the xlclang++ . Sooner or later we have to switch to xlclang++ , because the legacy xlc will most likely not be able to support everything from ?JEP 347: Adopt C++14 Language Features in HotSpot? . * It would be really nice if we could align the xlc options more closely to gcc/clang. In the long run this should be possible . Best regards, Matthias From: Magnus Ihse Bursie Sent: Donnerstag, 31. Januar 2019 21:19 To: Baesken, Matthias Cc: build-dev at openjdk.java.net Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX Ah, IBM is starting to use clang? That's nice! From what I understand after a quick search, this also means that gcc/clang options are available, and recommended [1] to use. It would be really nice if we could align the xlc options more closely to gcc/clang. /Magnus [1] https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/migrate/xlC_vs_xlclangpp.html 31 jan. 2019 kl. 15:50 skrev Baesken, Matthias >: Please review this small webrev . It contains a few changes for building hotspot on AIX with xlclang++ / xlc16 . ( most likely switching to xlclang++ / xlc16 will be a must once we introduce C++11/14 features ) Some comments on the changes : - porting_aix.cpp : workaround for demangle.h (does not work with xlclang++) - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to assigning false to AllocateHeapAt which is a bad idea (and does not work with xlclang++) - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not have #error ... in this case Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8218136 http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ Thanks, Matthias From andrew_m_leonard at uk.ibm.com Fri Feb 1 09:12:34 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 1 Feb 2019 09:12:34 +0000 Subject: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: Thanks Magnus, no hurry, next week will be fine. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Magnus Ihse Bursie To: Andrew Leonard Cc: David Holmes , build-dev at openjdk.java.net Date: 31/01/2019 20:10 Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX 31 jan. 2019 kl. 16:01 skrev Andrew Leonard : Hiya, I've created and tested a new webrev using lparstat and following your guidelines, webrev.01 is here: http://cr.openjdk.java.net/~aleonard/8217896/webrev.01/ If someone is happy to sponsor and review please? This looks good to me. I can sponsor, but won't have time to push it until tomorrow or after the weekend, so if anyone else wants to step in feel free to do so. :) /Magnus Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Magnus Ihse Bursie To: Andrew Leonard , David Holmes < david.holmes at oracle.com> Cc: build-dev at openjdk.java.net Date: 30/01/2019 17:16 Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX On 2019-01-30 17:37, Andrew Leonard wrote: > Thanks David, > I just found the reference you mention, it is a little vague, but says > maybe as you said. I've reworked and tested the following which seems > better: > NUM_CORES=`lparstat -m | grep -o "lcpu=[[0-9]]*" | cut -d "=" -f 2` > I'll create a new webrev with this. Note that you should use $GREP and $CUT; in theory we should also check for lparstat, but we've been sloppy with that for the other cpu checking methods so maybe we can be that for AIX here as well. /Magnus > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: David Holmes > To: Erik Joelsson , Andrew Leonard > , build-dev at openjdk.java.net > Date: 30/01/2019 02:25 > Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when > building on AIX > > > > On 30/01/2019 3:05 am, Erik Joelsson wrote: >> Hello, >> >> I'm OK with this, but since I can't verify it at all, I would be more >> comfortable if one of the other AIX users would review this as well. > Ditto. I did some googling on this and pmcycles is flagged as maybe > being deprecated in the future and may require privileges to execute. > lparstat -i seems to be more commonly used. > > David > ----- > >> /Erik >> >> On 2019-01-29 05:08, Andrew Leonard wrote: >>> Hi, >>> Please can I get a sponsor for this build performance enhancement on > AIX, >>> by better determining the number of LCPUs on smt AIX machines: >>> > https://cr.openjdk.java.net/~aleonard/8217896/webrev.00/ > >>> My testing shows up to 30% improved build times when leveraging the >>> available LCPUs. >>> Many thanks >>> Andrew >>> >>> Andrew Leonard >>> Java Runtimes Development >>> IBM Hursley >>> IBM United Kingdom Ltd >>> Phone internal: 245913, external: 01962 815913 >>> internet email: andrew_m_leonard at uk.ibm.com >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with > number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From matthias.baesken at sap.com Fri Feb 1 10:16:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 1 Feb 2019 10:16:08 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: > > Confused. Which other xlc compilers set __GNUC_ as you are changing this > for all of them? Though to be honest I don't understand this whole > section anyway - we have a lengthy comment saying why you can't > necessarily assign NULL to an integer type and to use NULL_WORD instead > but then it's defined as NULL anyway! I wonder if we used to have some > other conditions there where it was something different Hi David , not sure but I guess the #ifdef __GNUC__ came from linux/gcc and was copied to the aix / xlc file when the port was done back then . See : globalDefinitions_gcc.hpp 118#ifdef __GNUC__ 119 #ifdef _LP64 120 #define NULL_WORD 0L 121 #else 122 // Cast 0 to intptr_t rather than int32_t since they are not the same type 123 // on platforms such as Mac OS X. 124 #define NULL_WORD ((intptr_t)0) 125 #endif 126#else 127 #define NULL_WORD NULL 128#endif The NULL_WORD is mostly used in x86-only coding. But also used at some (but few) places in shared coding , like : intptr_t* addr; *addr = NULL_WORD; intptr_t _callee_registers[RegisterMap::reg_count]; _callee_registers[i] = src != NULL ? *src : NULL_WORD; > In any case having an if and else that do exactly the same thing seems rather > pointless to me. > Yes I agree , I think I remove the #ifdef ... #else and just define #define NULL_WORD NULL for AIX . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Freitag, 1. Februar 2019 05:24 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: 'build-dev at openjdk.java.net' > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > Hi Matthias, > > On 1/02/2019 12:50 am, Baesken, Matthias wrote: > > Please review this small webrev . It contains a few changes for building > hotspot on AIX with xlclang++ / xlc16 . > > ( most likely switching to xlclang++ / xlc16 will be a must once we > introduce C++11/14 features ) > > > > Some comments on the changes : > > > > > > - porting_aix.cpp : workaround for demangle.h (does not work with > xlclang++) > > Can't comment as I know nothing about it. > > > - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to > assigning false to AllocateHeapAt which is a bad idea (and does not work > with xlclang++) > > Good catch! > > > - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not > have #error ... in this case > > Confused. Which other xlc compilers set __GNUC_ as you are changing this > for all of them? Though to be honest I don't understand this whole > section anyway - we have a lengthy comment saying why you can't > necessarily assign NULL to an integer type and to use NULL_WORD instead > but then it's defined as NULL anyway! I wonder if we used to have some > other conditions there where it was something different? In any case > having an if and else that do exactly the same thing seems rather > pointless to me. > > Thanks, > David > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8218136 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ > > > > > > Thanks, Matthias > > From magnus.ihse.bursie at oracle.com Fri Feb 1 10:50:08 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Feb 2019 11:50:08 +0100 Subject: RFR: JDK-8218186 Clean up CLDR generation in build Message-ID: The CLDR data is, since Jigsaw, used in two different modules -- java.base and jdk.localedata. Unfortunately, the split between these two modules were not fully finished as part of the Jigsaw project. This patch aims to resolving most of this. The CLDRConverter build tool is now called from Gensrc-java.base and Gensrc-jdk.localedata, for their respective module. The calls have been updated to match modern build-infra standards. Also, the raw CLDR data was located mixed in with the Java source, in jdk.localedata. This patch also moves the data to make/data/cldr, to align with input data to all other build tools. Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Feb 1 11:39:26 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Feb 2019 12:39:26 +0100 Subject: RFR: JDK-8217317 : Create jpackage native library for windows In-Reply-To: References: Message-ID: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> Hi Alexander, On 2019-02-01 05:22, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - jpackage launcher will now build same as Linux and OS X using > SetupBuildLauncher. > - jpackage.dll was added based on Windows jpackage.exe launcher which > will have icon swap and version swap functionality called via JNI. > - Some code formatting, clean up and minor improvements where done to > icon and version swap code. No functional changes. > - Windows registry will be read and enumerated via JNI as well. > - isDirectoryInExclusionPath() will use native path comparison, since > paths in registry and temp folder returned by Java code can be in > short or long format, thus simple string comparison will not work. > - Windows Defender workaround warning will be checked for --build-root > as well if it is set. > - Removed extra escaping from JPackageHelper for Windows, otherwise > tests fails due to incorrect escaping. Our launcher used CreateProcess > to launch java.exe by passing args from main() to CreateProcess. This > is why I think we required extra escaping. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217317 > > [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ It basically looks good from a build perspective. There is one change I'd like to request, however, and that is that you place the source code according to the standard layout. This means moving the source files from src/jdk.jpackage/windows/native/jpackage to src/jdk.jpackage/windows/native/libjpackage. Also, when you do this, you don't need JPACKAGELIB_SRC; the location of the files will be determined by SetupJdkLibrary based on the name "jpackage" of the library. I'm also surprised to see that I can't find the removal of the old WinMain() method? /Magnus > > Thanks, > Alexander From magnus.ihse.bursie at oracle.com Fri Feb 1 11:41:53 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Feb 2019 12:41:53 +0100 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: On 2019-02-01 05:23, David Holmes wrote: > Hi Matthias, > > On 1/02/2019 12:50 am, Baesken, Matthias wrote: >> Please review? this small webrev? . It contains a few changes? for? >> building hotspot?? on AIX with xlclang++? / xlc16? . >> ( most likely switching to?? xlclang++? / xlc16??? will be a must >> once? we introduce C++11/14 features ) >> >> Some comments on the changes : >> >> >> - porting_aix.cpp? :? workaround for demangle.h (does not work with >> xlclang++) > > Can't comment as I know nothing about it. > >> - arguments.cpp/hpp? :? the UNSUPPORTED_OPTON macro lead? to >> assigning false to AllocateHeapAt which is a bad idea (and does not >> work with xlclang++) > > Good catch! > >> -?? globalDefinitions_xlc.hpp?? : xlclang++ sets?? __GNUC__ so we >> must not? have #error ... in this case > > Confused. Which other xlc compilers set __GNUC_ as you are changing > this for all of them? Unfortunately, I think __GNUC__ is set by many compilers who wish to express that (they believe) they are compatible with gcc (in one way or another). I'm pretty sure it's set by solstudio, for instance. And clang. But I might be wrong, and I might be thinking about some other gcc feature macro. /Magnus > Though to be honest I don't understand this whole section anyway - we > have a lengthy comment saying why you can't necessarily assign NULL to > an integer type and to use NULL_WORD instead but then it's defined as > NULL anyway! I wonder if we used to have some other conditions there > where it was something different? In any case having an if and else > that do exactly the same thing seems rather pointless to me. > > Thanks, > David >> >> >> >> Bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8218136 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ >> >> >> Thanks, Matthias >> From matthias.baesken at sap.com Fri Feb 1 12:36:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 1 Feb 2019 12:36:08 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ - adjusted globalDefinitions_xlc.hpp - fixed some copyright years Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Freitag, 1. Februar 2019 11:16 > To: 'David Holmes' ; 'hotspot- > dev at openjdk.java.net' > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > > > > Confused. Which other xlc compilers set __GNUC_ as you are changing this > > for all of them? Though to be honest I don't understand this whole > > section anyway - we have a lengthy comment saying why you can't > > necessarily assign NULL to an integer type and to use NULL_WORD instead > > but then it's defined as NULL anyway! I wonder if we used to have some > > other conditions there where it was something different > > Hi David , not sure but I guess the #ifdef __GNUC__ came from > linux/gcc and was copied to the aix / xlc file when the port was done back > then . > See : > > globalDefinitions_gcc.hpp > > 118#ifdef __GNUC__ > 119 #ifdef _LP64 > 120 #define NULL_WORD 0L > 121 #else > 122 // Cast 0 to intptr_t rather than int32_t since they are not the same > type > 123 // on platforms such as Mac OS X. > 124 #define NULL_WORD ((intptr_t)0) > 125 #endif > 126#else > 127 #define NULL_WORD NULL > 128#endif > > The NULL_WORD is mostly used in x86-only coding. But also used at some > (but few) places in shared coding , like : > > intptr_t* addr; > *addr = NULL_WORD; > > intptr_t _callee_registers[RegisterMap::reg_count]; > _callee_registers[i] = src != NULL ? *src : NULL_WORD; > > > > In any case having an if and else that do exactly the same thing seems > rather > > pointless to me. > > > > Yes I agree , I think I remove the #ifdef ... #else and just define #define > NULL_WORD NULL for AIX . > > Best regards, Matthias > > > > -----Original Message----- > > From: David Holmes > > Sent: Freitag, 1. Februar 2019 05:24 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' > > Cc: 'build-dev at openjdk.java.net' > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi Matthias, > > > > On 1/02/2019 12:50 am, Baesken, Matthias wrote: > > > Please review this small webrev . It contains a few changes for building > > hotspot on AIX with xlclang++ / xlc16 . > > > ( most likely switching to xlclang++ / xlc16 will be a must once we > > introduce C++11/14 features ) > > > > > > Some comments on the changes : > > > > > > > > > - porting_aix.cpp : workaround for demangle.h (does not work with > > xlclang++) > > > > Can't comment as I know nothing about it. > > > > > - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to > > assigning false to AllocateHeapAt which is a bad idea (and does not work > > with xlclang++) > > > > Good catch! > > > > > - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not > > have #error ... in this case > > > > Confused. Which other xlc compilers set __GNUC_ as you are changing this > > for all of them? Though to be honest I don't understand this whole > > section anyway - we have a lengthy comment saying why you can't > > necessarily assign NULL to an integer type and to use NULL_WORD instead > > but then it's defined as NULL anyway! I wonder if we used to have some > > other conditions there where it was something different? In any case > > having an if and else that do exactly the same thing seems rather > > pointless to me. > > > > Thanks, > > David > > > > > > > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8218136 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ > > > > > > > > > Thanks, Matthias > > > From david.holmes at oracle.com Fri Feb 1 12:49:22 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 22:49:22 +1000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: Hi Matthias, On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > - adjusted globalDefinitions_xlc.hpp I don't think it makes sense to keep the comment which was obviously copied from the gcc file: // On Linux NULL is defined as a special type '__null'. Assigning __null to // integer variable will cause gcc warning. Use NULL_WORD in places where a // pointer is stored as integer value. On some platforms, sizeof(intptr_t) > // sizeof(void*), so here we want something which is integer type, but has the // same size as a pointer. Rather something like: // Some platform/tool-chain combinations can't assign NULL to an integer // type so we define NULL_WORD to use in those contexts. For xlc they // are the same. Thanks, David > - fixed some copyright years > > > Best regards, Matthias > > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Freitag, 1. Februar 2019 11:16 >> To: 'David Holmes' ; 'hotspot- >> dev at openjdk.java.net' >> Cc: 'build-dev at openjdk.java.net' >> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >> xlc16 on AIX >> >>> >>> Confused. Which other xlc compilers set __GNUC_ as you are changing this >>> for all of them? Though to be honest I don't understand this whole >>> section anyway - we have a lengthy comment saying why you can't >>> necessarily assign NULL to an integer type and to use NULL_WORD instead >>> but then it's defined as NULL anyway! I wonder if we used to have some >>> other conditions there where it was something different >> >> Hi David , not sure but I guess the #ifdef __GNUC__ came from >> linux/gcc and was copied to the aix / xlc file when the port was done back >> then . >> See : >> >> globalDefinitions_gcc.hpp >> >> 118#ifdef __GNUC__ >> 119 #ifdef _LP64 >> 120 #define NULL_WORD 0L >> 121 #else >> 122 // Cast 0 to intptr_t rather than int32_t since they are not the same >> type >> 123 // on platforms such as Mac OS X. >> 124 #define NULL_WORD ((intptr_t)0) >> 125 #endif >> 126#else >> 127 #define NULL_WORD NULL >> 128#endif >> >> The NULL_WORD is mostly used in x86-only coding. But also used at some >> (but few) places in shared coding , like : >> >> intptr_t* addr; >> *addr = NULL_WORD; >> >> intptr_t _callee_registers[RegisterMap::reg_count]; >> _callee_registers[i] = src != NULL ? *src : NULL_WORD; >> >> >>> In any case having an if and else that do exactly the same thing seems >> rather >>> pointless to me. >>> >> >> Yes I agree , I think I remove the #ifdef ... #else and just define #define >> NULL_WORD NULL for AIX . >> >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Freitag, 1. Februar 2019 05:24 >>> To: Baesken, Matthias ; 'hotspot- >>> dev at openjdk.java.net' >>> Cc: 'build-dev at openjdk.java.net' >>> Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from >>> xlc16 on AIX >>> >>> Hi Matthias, >>> >>> On 1/02/2019 12:50 am, Baesken, Matthias wrote: >>>> Please review this small webrev . It contains a few changes for building >>> hotspot on AIX with xlclang++ / xlc16 . >>>> ( most likely switching to xlclang++ / xlc16 will be a must once we >>> introduce C++11/14 features ) >>>> >>>> Some comments on the changes : >>>> >>>> >>>> - porting_aix.cpp : workaround for demangle.h (does not work with >>> xlclang++) >>> >>> Can't comment as I know nothing about it. >>> >>>> - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to >>> assigning false to AllocateHeapAt which is a bad idea (and does not work >>> with xlclang++) >>> >>> Good catch! >>> >>>> - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not >>> have #error ... in this case >>> >>> Confused. Which other xlc compilers set __GNUC_ as you are changing this >>> for all of them? Though to be honest I don't understand this whole >>> section anyway - we have a lengthy comment saying why you can't >>> necessarily assign NULL to an integer type and to use NULL_WORD instead >>> but then it's defined as NULL anyway! I wonder if we used to have some >>> other conditions there where it was something different? In any case >>> having an if and else that do exactly the same thing seems rather >>> pointless to me. >>> >>> Thanks, >>> David >>>> >>>> >>>> >>>> Bug/webrev : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8218136 >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ >>>> >>>> >>>> Thanks, Matthias >>>> From naoto.sato at oracle.com Fri Feb 1 13:43:03 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 1 Feb 2019 05:43:03 -0800 Subject: RFR: JDK-8218186 Clean up CLDR generation in build In-Reply-To: References: Message-ID: Hi Magnus, I am assuming that the generated resource bundles are exactly the same as before this fix, correct? Naoto On 2/1/19 2:50 AM, Magnus Ihse Bursie wrote: > The CLDR data is, since Jigsaw, used in two different modules -- > java.base and jdk.localedata. Unfortunately, the split between these two > modules were not fully finished as part of the Jigsaw project. > > This patch aims to resolving most of this. The CLDRConverter build tool > is now called from Gensrc-java.base and Gensrc-jdk.localedata, for their > respective module. The calls have been updated to match modern > build-infra standards. > > Also, the raw CLDR data was located mixed in with the Java source, in > jdk.localedata. This patch also moves the data to make/data/cldr, to > align with input data to all other build tools. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 > > /Magnus From andrew_m_leonard at uk.ibm.com Fri Feb 1 13:44:35 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 1 Feb 2019 13:44:35 +0000 Subject: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: Thanks for merging Magnus, Cheers Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Magnus Ihse Bursie To: Andrew Leonard Cc: David Holmes , build-dev at openjdk.java.net Date: 31/01/2019 20:10 Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX 31 jan. 2019 kl. 16:01 skrev Andrew Leonard : Hiya, I've created and tested a new webrev using lparstat and following your guidelines, webrev.01 is here: http://cr.openjdk.java.net/~aleonard/8217896/webrev.01/ If someone is happy to sponsor and review please? This looks good to me. I can sponsor, but won't have time to push it until tomorrow or after the weekend, so if anyone else wants to step in feel free to do so. :) /Magnus Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Magnus Ihse Bursie To: Andrew Leonard , David Holmes < david.holmes at oracle.com> Cc: build-dev at openjdk.java.net Date: 30/01/2019 17:16 Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX On 2019-01-30 17:37, Andrew Leonard wrote: > Thanks David, > I just found the reference you mention, it is a little vague, but says > maybe as you said. I've reworked and tested the following which seems > better: > NUM_CORES=`lparstat -m | grep -o "lcpu=[[0-9]]*" | cut -d "=" -f 2` > I'll create a new webrev with this. Note that you should use $GREP and $CUT; in theory we should also check for lparstat, but we've been sloppy with that for the other cpu checking methods so maybe we can be that for AIX here as well. /Magnus > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: David Holmes > To: Erik Joelsson , Andrew Leonard > , build-dev at openjdk.java.net > Date: 30/01/2019 02:25 > Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when > building on AIX > > > > On 30/01/2019 3:05 am, Erik Joelsson wrote: >> Hello, >> >> I'm OK with this, but since I can't verify it at all, I would be more >> comfortable if one of the other AIX users would review this as well. > Ditto. I did some googling on this and pmcycles is flagged as maybe > being deprecated in the future and may require privileges to execute. > lparstat -i seems to be more commonly used. > > David > ----- > >> /Erik >> >> On 2019-01-29 05:08, Andrew Leonard wrote: >>> Hi, >>> Please can I get a sponsor for this build performance enhancement on > AIX, >>> by better determining the number of LCPUs on smt AIX machines: >>> > https://cr.openjdk.java.net/~aleonard/8217896/webrev.00/ > >>> My testing shows up to 30% improved build times when leveraging the >>> available LCPUs. >>> Many thanks >>> Andrew >>> >>> Andrew Leonard >>> Java Runtimes Development >>> IBM Hursley >>> IBM United Kingdom Ltd >>> Phone internal: 245913, external: 01962 815913 >>> internet email: andrew_m_leonard at uk.ibm.com >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with > number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From erik.joelsson at oracle.com Fri Feb 1 16:43:36 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Feb 2019 08:43:36 -0800 Subject: RFR: JDK-8218186 Clean up CLDR generation in build In-Reply-To: References: Message-ID: Looks good. /Erik On 2019-02-01 02:50, Magnus Ihse Bursie wrote: > The CLDR data is, since Jigsaw, used in two different modules -- > java.base and jdk.localedata. Unfortunately, the split between these > two modules were not fully finished as part of the Jigsaw project. > > This patch aims to resolving most of this. The CLDRConverter build > tool is now called from Gensrc-java.base and Gensrc-jdk.localedata, > for their respective module. The calls have been updated to match > modern build-infra standards. > > Also, the raw CLDR data was located mixed in with the Java source, in > jdk.localedata. This patch also moves the data to make/data/cldr, to > align with input data to all other build tools. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 > > /Magnus From erik.joelsson at oracle.com Fri Feb 1 17:40:19 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Feb 2019 09:40:19 -0800 Subject: RFR: JDK-8218198: Revert devkit change in JDK-8217910 for linux-x64 Message-ID: The devkit change for linux-x64 broke AOT testing. While a proper fix is worked on, we need to revert this change so normal testing past tier4 may proceed. The proper fix proved more difficult than expected. There is no need to back out the complete change. Only the usage of the new devkit for linux-x64 is causing trouble. Bug: https://bugs.openjdk.java.net/browse/JDK-8218198 Webrev: http://cr.openjdk.java.net/~erikj/8218198/webrev.01/ /Erik From tim.bell at oracle.com Fri Feb 1 18:02:50 2019 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 01 Feb 2019 10:02:50 -0800 Subject: RFR: JDK-8218198: Revert devkit change in JDK-8217910 for linux-x64 In-Reply-To: References: Message-ID: <5C5489CA.5020808@oracle.com> Erik: > The devkit change for linux-x64 broke AOT testing. While a proper fix is > worked on, we need to revert this change so normal testing past tier4 > may proceed. The proper fix proved more difficult than expected. > > There is no need to back out the complete change. Only the usage of the > new devkit for linux-x64 is causing trouble. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218198 > > Webrev: http://cr.openjdk.java.net/~erikj/8218198/webrev.01/ Looks good. Tim From alexander.matveev at oracle.com Fri Feb 1 22:38:08 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 1 Feb 2019 14:38:08 -0800 Subject: RFR: JDK-8217317 : Create jpackage native library for windows In-Reply-To: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> References: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> Message-ID: Hi Magnus, http://cr.openjdk.java.net/~almatvee/8217317/webrev.01/ Moved files to libjpackage and remove JPACKAGELIB_SRC. Old wmain() was in jpackage.cpp line 461. Thanks, Alexander On 2/1/2019 3:39 AM, Magnus Ihse Bursie wrote: > Hi Alexander, > > On 2019-02-01 05:22, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - jpackage launcher will now build same as Linux and OS X using >> SetupBuildLauncher. >> - jpackage.dll was added based on Windows jpackage.exe launcher which >> will have icon swap and version swap functionality called via JNI. >> - Some code formatting, clean up and minor improvements where done to >> icon and version swap code. No functional changes. >> - Windows registry will be read and enumerated via JNI as well. >> - isDirectoryInExclusionPath() will use native path comparison, since >> paths in registry and temp folder returned by Java code can be in >> short or long format, thus simple string comparison will not work. >> - Windows Defender workaround warning will be checked for >> --build-root as well if it is set. >> - Removed extra escaping from JPackageHelper for Windows, otherwise >> tests fails due to incorrect escaping. Our launcher used >> CreateProcess to launch java.exe by passing args from main() to >> CreateProcess. This is why I think we required extra escaping. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217317 >> >> [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ > It basically looks good from a build perspective. There is one change > I'd like to request, however, and that is that you place the source > code according to the standard layout. This means moving the source > files from src/jdk.jpackage/windows/native/jpackage to > src/jdk.jpackage/windows/native/libjpackage. Also, when you do this, > you don't need JPACKAGELIB_SRC; the location of the files will be > determined by SetupJdkLibrary based on the name "jpackage" of the > library. > > I'm also surprised to see that I can't find the removal of the old > WinMain() method? > > /Magnus > > >> >> Thanks, >> Alexander > From matthias.baesken at sap.com Mon Feb 4 11:36:13 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 4 Feb 2019 11:36:13 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: Hi David, I want to follow your suggestion ? . I adjusted the comment , see globalDefinitions_xlc.hpp . Additionally I removed a strange ifdef handling pre-xlc10 versions that are not useful today any more for OpenJDK ( we most likely cannot build jdk/jdk with xlc versions < 10). New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Freitag, 1. Februar 2019 13:49 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; > 'magnus.ihse.bursie at oracle.com' > Cc: 'build-dev at openjdk.java.net' > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > Hi Matthias, > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > - adjusted globalDefinitions_xlc.hpp > > I don't think it makes sense to keep the comment which was obviously > copied from the gcc file: > > // On Linux NULL is defined as a special type '__null'. Assigning > __null to > // integer variable will cause gcc warning. Use NULL_WORD in places > where a > // pointer is stored as integer value. On some platforms, > sizeof(intptr_t) > > // sizeof(void*), so here we want something which is integer type, > but has the > // same size as a pointer. > > Rather something like: > > // Some platform/tool-chain combinations can't assign NULL to an integer > // type so we define NULL_WORD to use in those contexts. For xlc they > // are the same. > > Thanks, > David > > From david.holmes at oracle.com Mon Feb 4 12:28:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Feb 2019 22:28:37 +1000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: <68040b37-1a3b-35e3-98cd-277f1a6421bf@oracle.com> Hi Matthias, On 4/02/2019 9:36 pm, Baesken, Matthias wrote: > Hi David, I want to follow your suggestion ? . > I adjusted the comment , see globalDefinitions_xlc.hpp . Looks good. Thanks. > Additionally I removed a strange ifdef handling pre-xlc10 versions that are not useful today any more for OpenJDK > ( we most likely cannot build jdk/jdk with xlc versions < 10). Can't comment on that bit. :) Cheers, David > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Freitag, 1. Februar 2019 13:49 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' ; >> 'magnus.ihse.bursie at oracle.com' >> Cc: 'build-dev at openjdk.java.net' >> Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from >> xlc16 on AIX >> >> Hi Matthias, >> >> On 1/02/2019 10:36 pm, Baesken, Matthias wrote: >>> New webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ >>> >>> - adjusted globalDefinitions_xlc.hpp >> >> I don't think it makes sense to keep the comment which was obviously >> copied from the gcc file: >> >> // On Linux NULL is defined as a special type '__null'. Assigning >> __null to >> // integer variable will cause gcc warning. Use NULL_WORD in places >> where a >> // pointer is stored as integer value. On some platforms, >> sizeof(intptr_t) > >> // sizeof(void*), so here we want something which is integer type, >> but has the >> // same size as a pointer. >> >> Rather something like: >> >> // Some platform/tool-chain combinations can't assign NULL to an integer >> // type so we define NULL_WORD to use in those contexts. For xlc they >> // are the same. >> >> Thanks, >> David >> >> > From erik.joelsson at oracle.com Tue Feb 5 00:24:11 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Feb 2019 16:24:11 -0800 Subject: RFR: JDK-8218177: Bump jib format_version to support new devkit archive layout In-Reply-To: References: Message-ID: This patch was a bit premature, but now with a proper fix in Jib, here is an updated version. It restores the use of the new devkit as well as changes some more instances of install_path to home_path. Webrev: http://cr.openjdk.java.net/~erikj/8218177/webrev.02/ /Erik On 2019-01-31 16:23, Erik Joelsson wrote: > With the new devkits I deployed recently (Oracle internal), the file > layout changed as a top level directory inside the tar archive was > introduced. This works in most cases, but there are certain situations > where jib does not handle this well. This causes AOT testing on Linux > to stop working with the run-test-prebuilt make target. > > This issue is being fixed in Jib, but to activate the fix a bump in > the format_version is required. This patch does that, as well as > adjusting to conform to the new behavior. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218177 > > Webrev: http://cr.openjdk.java.net/~erikj/8218177/webrev.01/ > > (note that the Jib fix is not yet live in production) > > /Erik > From erik.joelsson at oracle.com Tue Feb 5 00:36:44 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Feb 2019 16:36:44 -0800 Subject: RFR: JDK-8160926: FLAGS_COMPILER_CHECK_ARGUMENTS doesn't handle cross-compilation Message-ID: <281ffbd4-a025-a1f5-7b4a-8379bd20a954@oracle.com> Please review this fix for configure flags checking. The macros for checking compiler capabilities were not able to handle cross compilation very well. With this fix, they accept an optional PREFIX argument, instructing them to check the compiler with the given prefix (which is either empty or BUILD_). Using this, I have moved all calls to the macros into BUILD/TARGET specific macro bodies so that we correctly check both the build and target compilers for valid flags. I have verified by running cross compilation configurations of linux-aarch64 using both the same and different versions of GCC for build and target, and compared the output in both configure.log and the spec files. I've also run tier1 (equivalent to submission forest) and a? COMPARE_BUILD run on Oracle's main platforms as well. The change unfortunately required adding another prefix type format since our compiler/tool variables use /BUILD_ as prefix and the existing formats were TARGET_/BUILD_ and /OPENJDK_TARGET_. I think we could benefit greatly from unifying these. I've also touched some white space nearby my changes as well as fixed a trivial error message about "linker" not being found by quoting the LINKER_NAME assignment in toolchain.m4. Bug: https://bugs.openjdk.java.net/browse/JDK-8160926 Webrev: http://cr.openjdk.java.net/~erikj/8160926/webrev.01 /Erik From magnus.ihse.bursie at oracle.com Tue Feb 5 08:01:54 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Feb 2019 09:01:54 +0100 Subject: RFR: JDK-8218177: Bump jib format_version to support new devkit archive layout In-Reply-To: References: Message-ID: <2c0ab7a8-a946-b1d3-48cc-a886359c6388@oracle.com> On 2019-02-05 01:24, Erik Joelsson wrote: > This patch was a bit premature, but now with a proper fix in Jib, here > is an updated version. It restores the use of the new devkit as well > as changes some more instances of install_path to home_path. > > Webrev: http://cr.openjdk.java.net/~erikj/8218177/webrev.02/ Looks good to me. /Magnus > > /Erik > > > On 2019-01-31 16:23, Erik Joelsson wrote: >> With the new devkits I deployed recently (Oracle internal), the file >> layout changed as a top level directory inside the tar archive was >> introduced. This works in most cases, but there are certain >> situations where jib does not handle this well. This causes AOT >> testing on Linux to stop working with the run-test-prebuilt make target. >> >> This issue is being fixed in Jib, but to activate the fix a bump in >> the format_version is required. This patch does that, as well as >> adjusting to conform to the new behavior. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218177 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8218177/webrev.01/ >> >> (note that the Jib fix is not yet live in production) >> >> /Erik >> From magnus.ihse.bursie at oracle.com Tue Feb 5 08:05:37 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Feb 2019 09:05:37 +0100 Subject: RFR: JDK-8217317 : Create jpackage native library for windows In-Reply-To: References: <5ba0a754-bbeb-3aca-d574-f5274fd200e2@oracle.com> Message-ID: <36d29c57-34a1-5164-2d2d-4642a88000a2@oracle.com> On 2019-02-01 23:38, Alexander Matveev wrote: > Hi Magnus, > > http://cr.openjdk.java.net/~almatvee/8217317/webrev.01/ Looks great, thank you! I can't comment on the actual source code changes, so you'll need a thumbs up from someone in core libs as well. > > Moved files to libjpackage and remove JPACKAGELIB_SRC. > > Old wmain() was in jpackage.cpp line 461. Aha. :) I only knew about WinMain and main. You learn something every day. Thanks. /Magnus > > Thanks, > Alexander > > On 2/1/2019 3:39 AM, Magnus Ihse Bursie wrote: >> Hi Alexander, >> >> On 2019-02-01 05:22, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - jpackage launcher will now build same as Linux and OS X using >>> SetupBuildLauncher. >>> - jpackage.dll was added based on Windows jpackage.exe launcher >>> which will have icon swap and version swap functionality called via >>> JNI. >>> - Some code formatting, clean up and minor improvements where done >>> to icon and version swap code. No functional changes. >>> - Windows registry will be read and enumerated via JNI as well. >>> - isDirectoryInExclusionPath() will use native path comparison, >>> since paths in registry and temp folder returned by Java code can be >>> in short or long format, thus simple string comparison will not work. >>> - Windows Defender workaround warning will be checked for >>> --build-root as well if it is set. >>> - Removed extra escaping from JPackageHelper for Windows, otherwise >>> tests fails due to incorrect escaping. Our launcher used >>> CreateProcess to launch java.exe by passing args from main() to >>> CreateProcess. This is why I think we required extra escaping. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8217317 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ >> It basically looks good from a build perspective. There is one change >> I'd like to request, however, and that is that you place the source >> code according to the standard layout. This means moving the source >> files from src/jdk.jpackage/windows/native/jpackage to >> src/jdk.jpackage/windows/native/libjpackage. Also, when you do this, >> you don't need JPACKAGELIB_SRC; the location of the files will be >> determined by SetupJdkLibrary based on the name "jpackage" of the >> library. >> >> I'm also surprised to see that I can't find the removal of the old >> WinMain() method? >> >> /Magnus >> >> >>> >>> Thanks, >>> Alexander >> > From goetz.lindenmaier at sap.com Tue Feb 5 08:59:10 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Feb 2019 08:59:10 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: Hi Matthias, The demangle fix is kind of preliminary, but to get the compiler working it is acceptable to skip this code for now. The old xlc stuff is good to be removed. Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN altogether and replace its only use by USE_XLC_BUILTINS? Also, I think it makes sense to put #if __IBMCPP__ < 1000 #error "xlc < 10 not supported" #endif into the file. Probably we should even check for having at least xlc 12. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Montag, 4. Februar 2019 12:36 > To: David Holmes ; 'hotspot- > dev at openjdk.java.net' ; > 'magnus.ihse.bursie at oracle.com' > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > Hi David, I want to follow your suggestion ? . > I adjusted the comment , see globalDefinitions_xlc.hpp . > > Additionally I removed a strange ifdef handling pre-xlc10 versions that are > not useful today any more for OpenJDK > ( we most likely cannot build jdk/jdk with xlc versions < 10). > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > Best regards, Matthias > > > > > -----Original Message----- > > From: David Holmes > > Sent: Freitag, 1. Februar 2019 13:49 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' ; > > 'magnus.ihse.bursie at oracle.com' > > Cc: 'build-dev at openjdk.java.net' > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi Matthias, > > > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > > New webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > > > - adjusted globalDefinitions_xlc.hpp > > > > I don't think it makes sense to keep the comment which was obviously > > copied from the gcc file: > > > > // On Linux NULL is defined as a special type '__null'. Assigning > > __null to > > // integer variable will cause gcc warning. Use NULL_WORD in places > > where a > > // pointer is stored as integer value. On some platforms, > > sizeof(intptr_t) > > > // sizeof(void*), so here we want something which is integer type, > > but has the > > // same size as a pointer. > > > > Rather something like: > > > > // Some platform/tool-chain combinations can't assign NULL to an integer > > // type so we define NULL_WORD to use in those contexts. For xlc they > > // are the same. > > > > Thanks, > > David > > > > From magnus.ihse.bursie at oracle.com Tue Feb 5 09:12:50 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Feb 2019 10:12:50 +0100 Subject: RFR: JDK-8160926: FLAGS_COMPILER_CHECK_ARGUMENTS doesn't handle cross-compilation In-Reply-To: <281ffbd4-a025-a1f5-7b4a-8379bd20a954@oracle.com> References: <281ffbd4-a025-a1f5-7b4a-8379bd20a954@oracle.com> Message-ID: <210a91cc-b89f-63f9-2b2f-19b3aa9e1acb@oracle.com> On 2019-02-05 01:36, Erik Joelsson wrote: > Please review this fix for configure flags checking. The macros for > checking compiler capabilities were not able to handle cross > compilation very well. With this fix, they accept an optional PREFIX > argument, instructing them to check the compiler with the given prefix > (which is either empty or BUILD_). Using this, I have moved all calls > to the macros into BUILD/TARGET specific macro bodies so that we > correctly check both the build and target compilers for valid flags. > > I have verified by running cross compilation configurations of > linux-aarch64 using both the same and different versions of GCC for > build and target, and compared the output in both configure.log and > the spec files. I've also run tier1 (equivalent to submission forest) > and a? COMPARE_BUILD run on Oracle's main platforms as well. > > The change unfortunately required adding another prefix type format > since our compiler/tool variables use /BUILD_ as prefix and the > existing formats were TARGET_/BUILD_ and /OPENJDK_TARGET_. I > think we could benefit greatly from unifying these. > > I've also touched some white space nearby my changes as well as fixed > a trivial error message about "linker" not being found by quoting the > LINKER_NAME assignment in toolchain.m4. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160926 > > Webrev: http://cr.openjdk.java.net/~erikj/8160926/webrev.01 Looks good. Thanks for finally getting this fixed. A related problem, that perhaps should be fixed at the same time, is that we need to add -Werror to provoke an actual warning message that fails. This has been done manually in some (but not all) cases where we call FLAGS_COMPILER_CHECK_ARGUMENTS. It might depend on version of gcc, or what kind of options we are testing -- I don't remember the detail. But I think it would be safe, and prudent, to let FLAGS_COMPILER_CHECK_ARGUMENTS automatically add $CFLAGS_WARNINGS_ARE_ERRORS to the flag tested. (Assuming that the definition of CFLAGS_WARNINGS_ARE_ERRORS is available at the time of first call to FLAGS_COMPILER_CHECK_ARGUMENTS, but I think it is, or rather, should be.) /Magnus > /Erik > From magnus.ihse.bursie at oracle.com Tue Feb 5 09:57:06 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Feb 2019 10:57:06 +0100 Subject: RFR: JDK-8218186 Clean up CLDR generation in build In-Reply-To: References: Message-ID: On 2019-02-01 14:43, naoto.sato at oracle.com wrote: > Hi Magnus, > > I am assuming that the generated resource bundles are exactly the same > as before this fix, correct? Yes. I have verified this using the COMPARE_BUILD functionality. /Magnus > > Naoto > > On 2/1/19 2:50 AM, Magnus Ihse Bursie wrote: >> The CLDR data is, since Jigsaw, used in two different modules -- >> java.base and jdk.localedata. Unfortunately, the split between these >> two modules were not fully finished as part of the Jigsaw project. >> >> This patch aims to resolving most of this. The CLDRConverter build >> tool is now called from Gensrc-java.base and Gensrc-jdk.localedata, >> for their respective module. The calls have been updated to match >> modern build-infra standards. >> >> Also, the raw CLDR data was located mixed in with the Java source, in >> jdk.localedata. This patch also moves the data to make/data/cldr, to >> align with input data to all other build tools. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 >> >> /Magnus From magnus.ihse.bursie at oracle.com Tue Feb 5 14:49:54 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Feb 2019 15:49:54 +0100 Subject: RFR: JDK-8218431 Improved platform checking in makefiles Message-ID: <50535356-37f8-51b2-80be-d8bb8aaaaec1@oracle.com> To check for various aspects of the build or target platform, we do a lot of checks like: ?? ifeq ($(OPENJDK_BUILD_OS_ENV), windows.cygwin) ?????? ... The naming of those platform information variables is a bit unfortunate. Yes, we know we're building OpenJDK, so why the OPENJDK_ prefix? I've been wanting for a long time to do something about this odd prefix, and it became more urgent after the recent fix of JDK-8160926, which pushes the matter about unifying the naming of build/target variables. The solution in this patch is not to rename the variables per se, but to introduce an abstraction layer in terms of function calls for checking platform aspects. This *really* shines when it comes to testing for multiple platforms. Previously, we were required to resort to constructs such as: ?? ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) but this can now be expressed as: ?? ifeq ($(call isTargetOs, windows solaris), true) Or this (actually technically broken) horrible example: ?? ifneq (, $(findstring $(OPENJDK_TARGET_OS), linux macosx)) which I had to read three times before being sure that this was the correct way to replace it: ?? ifeq ($(call isTargetOs, linux macosx), true) Bug: https://bugs.openjdk.java.net/browse/JDK-8218431 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.01 /Magnus From tim.bell at oracle.com Tue Feb 5 14:59:34 2019 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 05 Feb 2019 06:59:34 -0800 Subject: RFR: JDK-8218177: Bump jib format_version to support new devkit archive layout In-Reply-To: <2c0ab7a8-a946-b1d3-48cc-a886359c6388@oracle.com> References: <2c0ab7a8-a946-b1d3-48cc-a886359c6388@oracle.com> Message-ID: <5C59A4D6.4030304@oracle.com> Erik: Looks good to me as well. Tim On 02/05/19 00:01, Magnus Ihse Bursie wrote: > On 2019-02-05 01:24, Erik Joelsson wrote: >> This patch was a bit premature, but now with a proper fix in Jib, here >> is an updated version. It restores the use of the new devkit as well >> as changes some more instances of install_path to home_path. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8218177/webrev.02/ > Looks good to me. > > /Magnus > >> >> /Erik >> >> >> On 2019-01-31 16:23, Erik Joelsson wrote: >>> With the new devkits I deployed recently (Oracle internal), the file >>> layout changed as a top level directory inside the tar archive was >>> introduced. This works in most cases, but there are certain >>> situations where jib does not handle this well. This causes AOT >>> testing on Linux to stop working with the run-test-prebuilt make target. >>> >>> This issue is being fixed in Jib, but to activate the fix a bump in >>> the format_version is required. This patch does that, as well as >>> adjusting to conform to the new behavior. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218177 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8218177/webrev.01/ >>> >>> (note that the Jib fix is not yet live in production) >>> >>> /Erik >>> > From magnus.ihse.bursie at oracle.com Tue Feb 5 15:28:58 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Feb 2019 16:28:58 +0100 Subject: RFR: JDK-8218431 Improved platform checking in makefiles In-Reply-To: <50535356-37f8-51b2-80be-d8bb8aaaaec1@oracle.com> References: <50535356-37f8-51b2-80be-d8bb8aaaaec1@oracle.com> Message-ID: <4a6a7d40-4b66-5367-c38b-6008ba6893a0@oracle.com> On 2019-02-05 15:49, Magnus Ihse Bursie wrote: > To check for various aspects of the build or target platform, we do a > lot of checks like: > ?? ifeq ($(OPENJDK_BUILD_OS_ENV), windows.cygwin) > ?????? ... > > The naming of those platform information variables is a bit > unfortunate. Yes, we know we're building OpenJDK, so why the OPENJDK_ > prefix? I've been wanting for a long time to do something about this > odd prefix, and it became more urgent after the recent fix of > JDK-8160926, which pushes the matter about unifying the naming of > build/target variables. > > The solution in this patch is not to rename the variables per se, but > to introduce an abstraction layer in terms of function calls for > checking platform aspects. > > This *really* shines when it comes to testing for multiple platforms. > Previously, we were required to resort to constructs such as: > > ?? ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) > > but this can now be expressed as: > > ?? ifeq ($(call isTargetOs, windows solaris), true) > > Or this (actually technically broken) horrible example: > > ?? ifneq (, $(findstring $(OPENJDK_TARGET_OS), linux macosx)) > > which I had to read three times before being sure that this was the > correct way to replace it: > > ?? ifeq ($(call isTargetOs, linux macosx), true) > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218431 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.01 ... and here's an updated version that fixes a typo: http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.02 /Magnus > > /Magnus > From naoto.sato at oracle.com Tue Feb 5 15:32:53 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 5 Feb 2019 07:32:53 -0800 Subject: RFR: JDK-8218186 Clean up CLDR generation in build In-Reply-To: References: Message-ID: Thanks, Magnus. The change looks good to me too. Naoto On 2/5/19 1:57 AM, Magnus Ihse Bursie wrote: > On 2019-02-01 14:43, naoto.sato at oracle.com wrote: >> Hi Magnus, >> >> I am assuming that the generated resource bundles are exactly the same >> as before this fix, correct? > > Yes. I have verified this using the COMPARE_BUILD functionality. > > /Magnus >> >> Naoto >> >> On 2/1/19 2:50 AM, Magnus Ihse Bursie wrote: >>> The CLDR data is, since Jigsaw, used in two different modules -- >>> java.base and jdk.localedata. Unfortunately, the split between these >>> two modules were not fully finished as part of the Jigsaw project. >>> >>> This patch aims to resolving most of this. The CLDRConverter build >>> tool is now called from Gensrc-java.base and Gensrc-jdk.localedata, >>> for their respective module. The calls have been updated to match >>> modern build-infra standards. >>> >>> Also, the raw CLDR data was located mixed in with the Java source, in >>> jdk.localedata. This patch also moves the data to make/data/cldr, to >>> align with input data to all other build tools. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 >>> >>> /Magnus > From matthias.baesken at sap.com Tue Feb 5 16:55:53 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 5 Feb 2019 16:55:53 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: Hi G?tz, new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ > The old xlc stuff is good to be removed. > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > altogether and replace its only use by USE_XLC_BUILTINS? > Done . > Also, I think it makes sense to put > #if __IBMCPP__ < 1000 > #error "xlc < 10 not supported" > #endif > into the file. > > Probably we should even check for having at least xlc 12. I added a check for xlc 12. Also slightly changed the check for AIX (_AIX macro) in globalDefinitions_xlc.hpp . > > The demangle fix is kind of preliminary, but to get the compiler > working it is acceptable to skip this code for now. > There might be a fix for xlc16 in the future but so far we have to live with it. Best regards, Matthias > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 5. Februar 2019 09:59 > To: Baesken, Matthias ; David Holmes > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > Hi Matthias, > > The demangle fix is kind of preliminary, but to get the compiler > working it is acceptable to skip this code for now. > > The old xlc stuff is good to be removed. > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > altogether and replace its only use by USE_XLC_BUILTINS? > > Also, I think it makes sense to put > #if __IBMCPP__ < 1000 > #error "xlc < 10 not supported" > #endif > into the file. > > Probably we should even check for having at least xlc 12. > > Best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Montag, 4. Februar 2019 12:36 > > To: David Holmes ; 'hotspot- > > dev at openjdk.java.net' ; > > 'magnus.ihse.bursie at oracle.com' > > Cc: 'build-dev at openjdk.java.net' > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi David, I want to follow your suggestion ? . > > I adjusted the comment , see globalDefinitions_xlc.hpp . > > > > Additionally I removed a strange ifdef handling pre-xlc10 versions that are > > not useful today any more for OpenJDK > > ( we most likely cannot build jdk/jdk with xlc versions < 10). > > > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > > > > Best regards, Matthias > > > > > > > > > -----Original Message----- > > > From: David Holmes > > > Sent: Freitag, 1. Februar 2019 13:49 > > > To: Baesken, Matthias ; 'hotspot- > > > dev at openjdk.java.net' ; > > > 'magnus.ihse.bursie at oracle.com' > > > Cc: 'build-dev at openjdk.java.net' > > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > > xlc16 on AIX > > > > > > Hi Matthias, > > > > > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > > > New webrev : > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > > > > > - adjusted globalDefinitions_xlc.hpp > > > > > > I don't think it makes sense to keep the comment which was obviously > > > copied from the gcc file: > > > > > > // On Linux NULL is defined as a special type '__null'. Assigning > > > __null to > > > // integer variable will cause gcc warning. Use NULL_WORD in places > > > where a > > > // pointer is stored as integer value. On some platforms, > > > sizeof(intptr_t) > > > > // sizeof(void*), so here we want something which is integer type, > > > but has the > > > // same size as a pointer. > > > > > > Rather something like: > > > > > > // Some platform/tool-chain combinations can't assign NULL to an integer > > > // type so we define NULL_WORD to use in those contexts. For xlc they > > > // are the same. > > > > > > Thanks, > > > David > > > > > > > From erik.joelsson at oracle.com Tue Feb 5 17:01:26 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Feb 2019 09:01:26 -0800 Subject: RFR: JDK-8218431 Improved platform checking in makefiles In-Reply-To: <4a6a7d40-4b66-5367-c38b-6008ba6893a0@oracle.com> References: <50535356-37f8-51b2-80be-d8bb8aaaaec1@oracle.com> <4a6a7d40-4b66-5367-c38b-6008ba6893a0@oracle.com> Message-ID: Looks good. I have read through all of them and it does not seem like you got any wrong. I note that you chose to express negatives as: ifneq (isTargetFoo, true) instead of: ifeq (isTargetFoo, false) I think I would have preferred the latter, given that the new macros return both true and false. I think true/false is more obvious to the eye than the sneaky 'n' in ifneq, but I don't have a strong opinion so this is fine too. /Erik On 2019-02-05 07:28, Magnus Ihse Bursie wrote: > On 2019-02-05 15:49, Magnus Ihse Bursie wrote: >> To check for various aspects of the build or target platform, we do a >> lot of checks like: >> ?? ifeq ($(OPENJDK_BUILD_OS_ENV), windows.cygwin) >> ?????? ... >> >> The naming of those platform information variables is a bit >> unfortunate. Yes, we know we're building OpenJDK, so why the OPENJDK_ >> prefix? I've been wanting for a long time to do something about this >> odd prefix, and it became more urgent after the recent fix of >> JDK-8160926, which pushes the matter about unifying the naming of >> build/target variables. >> >> The solution in this patch is not to rename the variables per se, but >> to introduce an abstraction layer in terms of function calls for >> checking platform aspects. >> >> This *really* shines when it comes to testing for multiple platforms. >> Previously, we were required to resort to constructs such as: >> >> ?? ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) >> >> but this can now be expressed as: >> >> ?? ifeq ($(call isTargetOs, windows solaris), true) >> >> Or this (actually technically broken) horrible example: >> >> ?? ifneq (, $(findstring $(OPENJDK_TARGET_OS), linux macosx)) >> >> which I had to read three times before being sure that this was the >> correct way to replace it: >> >> ?? ifeq ($(call isTargetOs, linux macosx), true) >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218431 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.01 > ... and here's an updated version that fixes a typo: > > http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.02 > > > /Magnus > >> >> /Magnus >> > From goetz.lindenmaier at sap.com Tue Feb 5 17:05:00 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Feb 2019 17:05:00 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: <59210a384d3b40f0936ede10b2d77886@sap.com> looks good, thanks for the adjustment! Best regards, Goetz. > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 5. Februar 2019 17:56 > To: Lindenmaier, Goetz ; David Holmes > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > Hi G?tz, new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ > > > > The old xlc stuff is good to be removed. > > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > > altogether and replace its only use by USE_XLC_BUILTINS? > > > > Done . > > > Also, I think it makes sense to put > > #if __IBMCPP__ < 1000 > > #error "xlc < 10 not supported" > > #endif > > into the file. > > > > Probably we should even check for having at least xlc 12. > > I added a check for xlc 12. > Also slightly changed the check for AIX (_AIX macro) in > globalDefinitions_xlc.hpp . > > > > > > The demangle fix is kind of preliminary, but to get the compiler > > working it is acceptable to skip this code for now. > > > > There might be a fix for xlc16 in the future but so far we have to live with it. > > > Best regards, Matthias > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Dienstag, 5. Februar 2019 09:59 > > To: Baesken, Matthias ; David Holmes > > ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > > > Cc: 'build-dev at openjdk.java.net' > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi Matthias, > > > > The demangle fix is kind of preliminary, but to get the compiler > > working it is acceptable to skip this code for now. > > > > The old xlc stuff is good to be removed. > > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > > altogether and replace its only use by USE_XLC_BUILTINS? > > > > Also, I think it makes sense to put > > #if __IBMCPP__ < 1000 > > #error "xlc < 10 not supported" > > #endif > > into the file. > > > > Probably we should even check for having at least xlc 12. > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf > > Of > > > Baesken, Matthias > > > Sent: Montag, 4. Februar 2019 12:36 > > > To: David Holmes ; 'hotspot- > > > dev at openjdk.java.net' ; > > > 'magnus.ihse.bursie at oracle.com' > > > Cc: 'build-dev at openjdk.java.net' > > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > > xlc16 on AIX > > > > > > Hi David, I want to follow your suggestion ? . > > > I adjusted the comment , see globalDefinitions_xlc.hpp . > > > > > > Additionally I removed a strange ifdef handling pre-xlc10 versions that are > > > not useful today any more for OpenJDK > > > ( we most likely cannot build jdk/jdk with xlc versions < 10). > > > > > > New webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > > > > > > > Best regards, Matthias > > > > > > > > > > > > > -----Original Message----- > > > > From: David Holmes > > > > Sent: Freitag, 1. Februar 2019 13:49 > > > > To: Baesken, Matthias ; 'hotspot- > > > > dev at openjdk.java.net' ; > > > > 'magnus.ihse.bursie at oracle.com' > > > > Cc: 'build-dev at openjdk.java.net' > > > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > > > xlc16 on AIX > > > > > > > > Hi Matthias, > > > > > > > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > > > > New webrev : > > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > > > > > > > - adjusted globalDefinitions_xlc.hpp > > > > > > > > I don't think it makes sense to keep the comment which was obviously > > > > copied from the gcc file: > > > > > > > > // On Linux NULL is defined as a special type '__null'. Assigning > > > > __null to > > > > // integer variable will cause gcc warning. Use NULL_WORD in places > > > > where a > > > > // pointer is stored as integer value. On some platforms, > > > > sizeof(intptr_t) > > > > > // sizeof(void*), so here we want something which is integer type, > > > > but has the > > > > // same size as a pointer. > > > > > > > > Rather something like: > > > > > > > > // Some platform/tool-chain combinations can't assign NULL to an integer > > > > // type so we define NULL_WORD to use in those contexts. For xlc they > > > > // are the same. > > > > > > > > Thanks, > > > > David > > > > > > > > > > > From magnus.ihse.bursie at oracle.com Tue Feb 5 17:31:25 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Feb 2019 18:31:25 +0100 Subject: RFR: JDK-8218431 Improved platform checking in makefiles In-Reply-To: References: <50535356-37f8-51b2-80be-d8bb8aaaaec1@oracle.com> <4a6a7d40-4b66-5367-c38b-6008ba6893a0@oracle.com> Message-ID: <105f425f-69c2-a03e-12f0-ebb51d6465c9@oracle.com> On 2019-02-05 18:01, Erik Joelsson wrote: > Looks good. I have read through all of them and it does not seem like > you got any wrong. > > I note that you chose to express negatives as: > > ifneq (isTargetFoo, true) > > instead of: > > ifeq (isTargetFoo, false) > > I think I would have preferred the latter, given that the new macros > return both true and false. I think true/false is more obvious to the > eye than the sneaky 'n' in ifneq, but I don't have a strong opinion so > this is fine too. I did consider this. I was on the verge of actually sending a question to the list, asking for input on this choice. My reasoning was I'm personally a bit blind to the "false" part, from all the years of focusing on the ifeq/ifneq, and that "ifeq foo, false" feels a bit like the newbie "if (mybool == false)" construct. But I also agree with your stance. As long as we agree to use one standard, I'll be happy to switch to "ifeq ... false". I think the important thing is just that we don't have to look out for both "ifneq ... true" and "ifeq ... false". /Magnus > > /Erik > > On 2019-02-05 07:28, Magnus Ihse Bursie wrote: >> On 2019-02-05 15:49, Magnus Ihse Bursie wrote: >>> To check for various aspects of the build or target platform, we do >>> a lot of checks like: >>> ?? ifeq ($(OPENJDK_BUILD_OS_ENV), windows.cygwin) >>> ?????? ... >>> >>> The naming of those platform information variables is a bit >>> unfortunate. Yes, we know we're building OpenJDK, so why the >>> OPENJDK_ prefix? I've been wanting for a long time to do something >>> about this odd prefix, and it became more urgent after the recent >>> fix of JDK-8160926, which pushes the matter about unifying the >>> naming of build/target variables. >>> >>> The solution in this patch is not to rename the variables per se, >>> but to introduce an abstraction layer in terms of function calls for >>> checking platform aspects. >>> >>> This *really* shines when it comes to testing for multiple >>> platforms. Previously, we were required to resort to constructs such >>> as: >>> >>> ?? ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) >>> >>> but this can now be expressed as: >>> >>> ?? ifeq ($(call isTargetOs, windows solaris), true) >>> >>> Or this (actually technically broken) horrible example: >>> >>> ?? ifneq (, $(findstring $(OPENJDK_TARGET_OS), linux macosx)) >>> >>> which I had to read three times before being sure that this was the >>> correct way to replace it: >>> >>> ?? ifeq ($(call isTargetOs, linux macosx), true) >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218431 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.01 >> ... and here's an updated version that fixes a typo: >> >> http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.02 >> >> >> /Magnus >> >>> >>> /Magnus >>> >> From erik.joelsson at oracle.com Tue Feb 5 17:55:55 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Feb 2019 09:55:55 -0800 Subject: RFR: JDK-8160926: FLAGS_COMPILER_CHECK_ARGUMENTS doesn't handle cross-compilation In-Reply-To: <210a91cc-b89f-63f9-2b2f-19b3aa9e1acb@oracle.com> References: <281ffbd4-a025-a1f5-7b4a-8379bd20a954@oracle.com> <210a91cc-b89f-63f9-2b2f-19b3aa9e1acb@oracle.com> Message-ID: <33340d43-ae8a-1dda-072b-7a094a079571@oracle.com> On 2019-02-05 01:12, Magnus Ihse Bursie wrote: > On 2019-02-05 01:36, Erik Joelsson wrote: >> Please review this fix for configure flags checking. The macros for >> checking compiler capabilities were not able to handle cross >> compilation very well. With this fix, they accept an optional PREFIX >> argument, instructing them to check the compiler with the given >> prefix (which is either empty or BUILD_). Using this, I have moved >> all calls to the macros into BUILD/TARGET specific macro bodies so >> that we correctly check both the build and target compilers for valid >> flags. >> >> I have verified by running cross compilation configurations of >> linux-aarch64 using both the same and different versions of GCC for >> build and target, and compared the output in both configure.log and >> the spec files. I've also run tier1 (equivalent to submission forest) >> and a? COMPARE_BUILD run on Oracle's main platforms as well. >> >> The change unfortunately required adding another prefix type format >> since our compiler/tool variables use /BUILD_ as prefix and >> the existing formats were TARGET_/BUILD_ and /OPENJDK_TARGET_. >> I think we could benefit greatly from unifying these. >> >> I've also touched some white space nearby my changes as well as fixed >> a trivial error message about "linker" not being found by quoting the >> LINKER_NAME assignment in toolchain.m4. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8160926 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8160926/webrev.01 > Looks good. Thanks for finally getting this fixed. > Thanks! > A related problem, that perhaps should be fixed at the same time, is > that we need to add -Werror to provoke an actual warning message that > fails. This has been done manually in some (but not all) cases where > we call FLAGS_COMPILER_CHECK_ARGUMENTS. It might depend on version of > gcc, or what kind of options we are testing -- I don't remember the > detail. But I think it would be safe, and prudent, to let > FLAGS_COMPILER_CHECK_ARGUMENTS automatically add > $CFLAGS_WARNINGS_ARE_ERRORS to the flag tested. (Assuming that the > definition of CFLAGS_WARNINGS_ARE_ERRORS is available at the time of > first call to FLAGS_COMPILER_CHECK_ARGUMENTS, but I think it is, or > rather, should be.) > I agree and I did react to this, but I don't really have the time to spend right now so will push this as is for now. /Erik > /Magnus > > >> /Erik >> > From magnus.ihse.bursie at oracle.com Tue Feb 5 18:27:01 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Feb 2019 19:27:01 +0100 Subject: RFR: JDK-8160926: FLAGS_COMPILER_CHECK_ARGUMENTS doesn't handle cross-compilation In-Reply-To: <33340d43-ae8a-1dda-072b-7a094a079571@oracle.com> References: <281ffbd4-a025-a1f5-7b4a-8379bd20a954@oracle.com> <210a91cc-b89f-63f9-2b2f-19b3aa9e1acb@oracle.com> <33340d43-ae8a-1dda-072b-7a094a079571@oracle.com> Message-ID: On 2019-02-05 18:55, Erik Joelsson wrote: > > On 2019-02-05 01:12, Magnus Ihse Bursie wrote: >> On 2019-02-05 01:36, Erik Joelsson wrote: >>> Please review this fix for configure flags checking. The macros for >>> checking compiler capabilities were not able to handle cross >>> compilation very well. With this fix, they accept an optional PREFIX >>> argument, instructing them to check the compiler with the given >>> prefix (which is either empty or BUILD_). Using this, I have moved >>> all calls to the macros into BUILD/TARGET specific macro bodies so >>> that we correctly check both the build and target compilers for >>> valid flags. >>> >>> I have verified by running cross compilation configurations of >>> linux-aarch64 using both the same and different versions of GCC for >>> build and target, and compared the output in both configure.log and >>> the spec files. I've also run tier1 (equivalent to submission >>> forest) and a? COMPARE_BUILD run on Oracle's main platforms as well. >>> >>> The change unfortunately required adding another prefix type format >>> since our compiler/tool variables use /BUILD_ as prefix and >>> the existing formats were TARGET_/BUILD_ and >>> /OPENJDK_TARGET_. I think we could benefit greatly from >>> unifying these. >>> >>> I've also touched some white space nearby my changes as well as >>> fixed a trivial error message about "linker" not being found by >>> quoting the LINKER_NAME assignment in toolchain.m4. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160926 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8160926/webrev.01 >> Looks good. Thanks for finally getting this fixed. >> > Thanks! >> A related problem, that perhaps should be fixed at the same time, is >> that we need to add -Werror to provoke an actual warning message that >> fails. This has been done manually in some (but not all) cases where >> we call FLAGS_COMPILER_CHECK_ARGUMENTS. It might depend on version of >> gcc, or what kind of options we are testing -- I don't remember the >> detail. But I think it would be safe, and prudent, to let >> FLAGS_COMPILER_CHECK_ARGUMENTS automatically add >> $CFLAGS_WARNINGS_ARE_ERRORS to the flag tested. (Assuming that the >> definition of CFLAGS_WARNINGS_ARE_ERRORS is available at the time of >> first call to FLAGS_COMPILER_CHECK_ARGUMENTS, but I think it is, or >> rather, should be.) >> > I agree and I did react to this, but I don't really have the time to > spend right now so will push this as is for now. Fair enough. Do you know if there's an open JBS issue on the problem? And if not, could you please file one? /Magnus > > /Erik > >> /Magnus >> >> >>> /Erik >>> >> From matthias.baesken at sap.com Wed Feb 6 08:05:41 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 6 Feb 2019 08:05:41 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: <59210a384d3b40f0936ede10b2d77886@sap.com> References: <59210a384d3b40f0936ede10b2d77886@sap.com> Message-ID: Thank's G?tz ! David + Magnus may I add you as reviewers ? Best regards, Matthias > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 5. Februar 2019 18:05 > To: Baesken, Matthias ; David Holmes > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > looks good, thanks for the adjustment! > > Best regards, > Goetz. > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Dienstag, 5. Februar 2019 17:56 > > To: Lindenmaier, Goetz ; David Holmes > > ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > > > Cc: 'build-dev at openjdk.java.net' > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi G?tz, new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ > > > > > > > The old xlc stuff is good to be removed. > > > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > > > altogether and replace its only use by USE_XLC_BUILTINS? > > > > > > > Done . > > > > > Also, I think it makes sense to put > > > #if __IBMCPP__ < 1000 > > > #error "xlc < 10 not supported" > > > #endif > > > into the file. > > > > > > Probably we should even check for having at least xlc 12. > > > > I added a check for xlc 12. > > Also slightly changed the check for AIX (_AIX macro) in > > globalDefinitions_xlc.hpp . > > > > > > > > > > The demangle fix is kind of preliminary, but to get the compiler > > > working it is acceptable to skip this code for now. > > > > > > > There might be a fix for xlc16 in the future but so far we have to live with > it. > > > > > > Best regards, Matthias > > > > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz > > > Sent: Dienstag, 5. Februar 2019 09:59 > > > To: Baesken, Matthias ; David Holmes > > > ; 'hotspot-dev at openjdk.java.net' > > > dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > > > > > Cc: 'build-dev at openjdk.java.net' > > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > > xlc16 on AIX > > > > > > Hi Matthias, > > > > > > The demangle fix is kind of preliminary, but to get the compiler > > > working it is acceptable to skip this code for now. > > > > > > The old xlc stuff is good to be removed. > > > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > > > altogether and replace its only use by USE_XLC_BUILTINS? > > > > > > Also, I think it makes sense to put > > > #if __IBMCPP__ < 1000 > > > #error "xlc < 10 not supported" > > > #endif > > > into the file. > > > > > > Probably we should even check for having at least xlc 12. > > > > > > Best regards, > > > Goetz. > > > > > > > -----Original Message----- > > > > From: hotspot-dev On > Behalf > > > Of > > > > Baesken, Matthias > > > > Sent: Montag, 4. Februar 2019 12:36 > > > > To: David Holmes ; 'hotspot- > > > > dev at openjdk.java.net' ; > > > > 'magnus.ihse.bursie at oracle.com' > > > > Cc: 'build-dev at openjdk.java.net' > > > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ > from > > > > xlc16 on AIX > > > > > > > > Hi David, I want to follow your suggestion ? . > > > > I adjusted the comment , see globalDefinitions_xlc.hpp . > > > > > > > > Additionally I removed a strange ifdef handling pre-xlc10 versions that > are > > > > not useful today any more for OpenJDK > > > > ( we most likely cannot build jdk/jdk with xlc versions < 10). > > > > > > > > New webrev : > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > > > > > > > > > > Best regards, Matthias > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: David Holmes > > > > > Sent: Freitag, 1. Februar 2019 13:49 > > > > > To: Baesken, Matthias ; 'hotspot- > > > > > dev at openjdk.java.net' ; > > > > > 'magnus.ihse.bursie at oracle.com' > > > > > Cc: 'build-dev at openjdk.java.net' > > > > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ > from > > > > > xlc16 on AIX > > > > > > > > > > Hi Matthias, > > > > > > > > > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > > > > > New webrev : > > > > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > > > > > > > > > - adjusted globalDefinitions_xlc.hpp > > > > > > > > > > I don't think it makes sense to keep the comment which was > obviously > > > > > copied from the gcc file: > > > > > > > > > > // On Linux NULL is defined as a special type '__null'. Assigning > > > > > __null to > > > > > // integer variable will cause gcc warning. Use NULL_WORD in places > > > > > where a > > > > > // pointer is stored as integer value. On some platforms, > > > > > sizeof(intptr_t) > > > > > > // sizeof(void*), so here we want something which is integer type, > > > > > but has the > > > > > // same size as a pointer. > > > > > > > > > > Rather something like: > > > > > > > > > > // Some platform/tool-chain combinations can't assign NULL to an > integer > > > > > // type so we define NULL_WORD to use in those contexts. For xlc > they > > > > > // are the same. > > > > > > > > > > Thanks, > > > > > David > > > > > > > > > > > > > > > > From david.holmes at oracle.com Wed Feb 6 11:55:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Feb 2019 21:55:35 +1000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: <59210a384d3b40f0936ede10b2d77886@sap.com> Message-ID: <80e7bfaa-a519-a865-da3e-6857a492fbdf@oracle.com> On 6/02/2019 6:05 pm, Baesken, Matthias wrote: > Thank's G?tz ! > > David + Magnus may I add you as reviewers ? Sure - though my review was only partial. You seem to have it all covered now. :) Thanks, David > Best regards, Matthias > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Dienstag, 5. Februar 2019 18:05 >> To: Baesken, Matthias ; David Holmes >> ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >> >> Cc: 'build-dev at openjdk.java.net' >> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >> xlc16 on AIX >> >> looks good, thanks for the adjustment! >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Dienstag, 5. Februar 2019 17:56 >>> To: Lindenmaier, Goetz ; David Holmes >>> ; 'hotspot-dev at openjdk.java.net' >> dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >>> >>> Cc: 'build-dev at openjdk.java.net' >>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >>> xlc16 on AIX >>> >>> Hi G?tz, new webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ >>> >>> >>>> The old xlc stuff is good to be removed. >>>> Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN >>>> altogether and replace its only use by USE_XLC_BUILTINS? >>>> >>> >>> Done . >>> >>>> Also, I think it makes sense to put >>>> #if __IBMCPP__ < 1000 >>>> #error "xlc < 10 not supported" >>>> #endif >>>> into the file. >>>> >>>> Probably we should even check for having at least xlc 12. >>> >>> I added a check for xlc 12. >>> Also slightly changed the check for AIX (_AIX macro) in >>> globalDefinitions_xlc.hpp . >>> >>> >>>> >>>> The demangle fix is kind of preliminary, but to get the compiler >>>> working it is acceptable to skip this code for now. >>>> >>> >>> There might be a fix for xlc16 in the future but so far we have to live with >> it. >>> >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: Lindenmaier, Goetz >>>> Sent: Dienstag, 5. Februar 2019 09:59 >>>> To: Baesken, Matthias ; David Holmes >>>> ; 'hotspot-dev at openjdk.java.net' >> >>> dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >>>> >>>> Cc: 'build-dev at openjdk.java.net' >>>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >>>> xlc16 on AIX >>>> >>>> Hi Matthias, >>>> >>>> The demangle fix is kind of preliminary, but to get the compiler >>>> working it is acceptable to skip this code for now. >>>> >>>> The old xlc stuff is good to be removed. >>>> Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN >>>> altogether and replace its only use by USE_XLC_BUILTINS? >>>> >>>> Also, I think it makes sense to put >>>> #if __IBMCPP__ < 1000 >>>> #error "xlc < 10 not supported" >>>> #endif >>>> into the file. >>>> >>>> Probably we should even check for having at least xlc 12. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev On >> Behalf >>>> Of >>>>> Baesken, Matthias >>>>> Sent: Montag, 4. Februar 2019 12:36 >>>>> To: David Holmes ; 'hotspot- >>>>> dev at openjdk.java.net' ; >>>>> 'magnus.ihse.bursie at oracle.com' >>>>> Cc: 'build-dev at openjdk.java.net' >>>>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ >> from >>>>> xlc16 on AIX >>>>> >>>>> Hi David, I want to follow your suggestion ? . >>>>> I adjusted the comment , see globalDefinitions_xlc.hpp . >>>>> >>>>> Additionally I removed a strange ifdef handling pre-xlc10 versions that >> are >>>>> not useful today any more for OpenJDK >>>>> ( we most likely cannot build jdk/jdk with xlc versions < 10). >>>>> >>>>> New webrev : >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ >>>>> >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes >>>>>> Sent: Freitag, 1. Februar 2019 13:49 >>>>>> To: Baesken, Matthias ; 'hotspot- >>>>>> dev at openjdk.java.net' ; >>>>>> 'magnus.ihse.bursie at oracle.com' >>>>>> Cc: 'build-dev at openjdk.java.net' >>>>>> Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ >> from >>>>>> xlc16 on AIX >>>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> On 1/02/2019 10:36 pm, Baesken, Matthias wrote: >>>>>>> New webrev : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ >>>>>>> >>>>>>> - adjusted globalDefinitions_xlc.hpp >>>>>> >>>>>> I don't think it makes sense to keep the comment which was >> obviously >>>>>> copied from the gcc file: >>>>>> >>>>>> // On Linux NULL is defined as a special type '__null'. Assigning >>>>>> __null to >>>>>> // integer variable will cause gcc warning. Use NULL_WORD in places >>>>>> where a >>>>>> // pointer is stored as integer value. On some platforms, >>>>>> sizeof(intptr_t) > >>>>>> // sizeof(void*), so here we want something which is integer type, >>>>>> but has the >>>>>> // same size as a pointer. >>>>>> >>>>>> Rather something like: >>>>>> >>>>>> // Some platform/tool-chain combinations can't assign NULL to an >> integer >>>>>> // type so we define NULL_WORD to use in those contexts. For xlc >> they >>>>>> // are the same. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Wed Feb 6 15:12:42 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 6 Feb 2019 16:12:42 +0100 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: <59210a384d3b40f0936ede10b2d77886@sap.com> Message-ID: On 2019-02-06 09:05, Baesken, Matthias wrote: > Thank's G?tz ! > > David + Magnus may I add you as reviewers ? Sure. /Magnus > > Best regards, Matthias > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Dienstag, 5. Februar 2019 18:05 >> To: Baesken, Matthias ; David Holmes >> ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >> >> Cc: 'build-dev at openjdk.java.net' >> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >> xlc16 on AIX >> >> looks good, thanks for the adjustment! >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Dienstag, 5. Februar 2019 17:56 >>> To: Lindenmaier, Goetz ; David Holmes >>> ; 'hotspot-dev at openjdk.java.net' >> dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >>> >>> Cc: 'build-dev at openjdk.java.net' >>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >>> xlc16 on AIX >>> >>> Hi G?tz, new webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ >>> >>> >>>> The old xlc stuff is good to be removed. >>>> Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN >>>> altogether and replace its only use by USE_XLC_BUILTINS? >>>> >>> Done . >>> >>>> Also, I think it makes sense to put >>>> #if __IBMCPP__ < 1000 >>>> #error "xlc < 10 not supported" >>>> #endif >>>> into the file. >>>> >>>> Probably we should even check for having at least xlc 12. >>> I added a check for xlc 12. >>> Also slightly changed the check for AIX (_AIX macro) in >>> globalDefinitions_xlc.hpp . >>> >>> >>>> The demangle fix is kind of preliminary, but to get the compiler >>>> working it is acceptable to skip this code for now. >>>> >>> There might be a fix for xlc16 in the future but so far we have to live with >> it. >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: Lindenmaier, Goetz >>>> Sent: Dienstag, 5. Februar 2019 09:59 >>>> To: Baesken, Matthias ; David Holmes >>>> ; 'hotspot-dev at openjdk.java.net' >> >>> dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >>>> >>>> Cc: 'build-dev at openjdk.java.net' >>>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >>>> xlc16 on AIX >>>> >>>> Hi Matthias, >>>> >>>> The demangle fix is kind of preliminary, but to get the compiler >>>> working it is acceptable to skip this code for now. >>>> >>>> The old xlc stuff is good to be removed. >>>> Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN >>>> altogether and replace its only use by USE_XLC_BUILTINS? >>>> >>>> Also, I think it makes sense to put >>>> #if __IBMCPP__ < 1000 >>>> #error "xlc < 10 not supported" >>>> #endif >>>> into the file. >>>> >>>> Probably we should even check for having at least xlc 12. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev On >> Behalf >>>> Of >>>>> Baesken, Matthias >>>>> Sent: Montag, 4. Februar 2019 12:36 >>>>> To: David Holmes ; 'hotspot- >>>>> dev at openjdk.java.net' ; >>>>> 'magnus.ihse.bursie at oracle.com' >>>>> Cc: 'build-dev at openjdk.java.net' >>>>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ >> from >>>>> xlc16 on AIX >>>>> >>>>> Hi David, I want to follow your suggestion ? . >>>>> I adjusted the comment , see globalDefinitions_xlc.hpp . >>>>> >>>>> Additionally I removed a strange ifdef handling pre-xlc10 versions that >> are >>>>> not useful today any more for OpenJDK >>>>> ( we most likely cannot build jdk/jdk with xlc versions < 10). >>>>> >>>>> New webrev : >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ >>>>> >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes >>>>>> Sent: Freitag, 1. Februar 2019 13:49 >>>>>> To: Baesken, Matthias ; 'hotspot- >>>>>> dev at openjdk.java.net' ; >>>>>> 'magnus.ihse.bursie at oracle.com' >>>>>> Cc: 'build-dev at openjdk.java.net' >>>>>> Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ >> from >>>>>> xlc16 on AIX >>>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> On 1/02/2019 10:36 pm, Baesken, Matthias wrote: >>>>>>> New webrev : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ >>>>>>> >>>>>>> - adjusted globalDefinitions_xlc.hpp >>>>>> I don't think it makes sense to keep the comment which was >> obviously >>>>>> copied from the gcc file: >>>>>> >>>>>> // On Linux NULL is defined as a special type '__null'. Assigning >>>>>> __null to >>>>>> // integer variable will cause gcc warning. Use NULL_WORD in places >>>>>> where a >>>>>> // pointer is stored as integer value. On some platforms, >>>>>> sizeof(intptr_t) > >>>>>> // sizeof(void*), so here we want something which is integer type, >>>>>> but has the >>>>>> // same size as a pointer. >>>>>> >>>>>> Rather something like: >>>>>> >>>>>> // Some platform/tool-chain combinations can't assign NULL to an >> integer >>>>>> // type so we define NULL_WORD to use in those contexts. For xlc >> they >>>>>> // are the same. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> From matthias.baesken at sap.com Wed Feb 6 15:17:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 6 Feb 2019 15:17:51 +0000 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings Message-ID: Hello, please review this small change . I noticed (when looking into AIX xlc16 / xlclang++) the following: in the case that clang is used for compilation, HOTSPOT_BUILD_COMPILER claims to be a gcc . This is a bit misleading. This change adjusts the setting for clang usage on AIX (for future usage with xlclang++) and macOSX. Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy Oracle / Sun Studio versions ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8218562 http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ Thanks, Matthias From magnus.ihse.bursie at oracle.com Wed Feb 6 15:39:58 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 6 Feb 2019 16:39:58 +0100 Subject: RFR: JDK-8218431 Improved platform checking in makefiles In-Reply-To: <105f425f-69c2-a03e-12f0-ebb51d6465c9@oracle.com> References: <50535356-37f8-51b2-80be-d8bb8aaaaec1@oracle.com> <4a6a7d40-4b66-5367-c38b-6008ba6893a0@oracle.com> <105f425f-69c2-a03e-12f0-ebb51d6465c9@oracle.com> Message-ID: <465b91b8-1624-2560-88e2-e9154a4effb1@oracle.com> On 2019-02-05 18:31, Magnus Ihse Bursie wrote: > > > On 2019-02-05 18:01, Erik Joelsson wrote: >> Looks good. I have read through all of them and it does not seem like >> you got any wrong. >> >> I note that you chose to express negatives as: >> >> ifneq (isTargetFoo, true) >> >> instead of: >> >> ifeq (isTargetFoo, false) >> >> I think I would have preferred the latter, given that the new macros >> return both true and false. I think true/false is more obvious to the >> eye than the sneaky 'n' in ifneq, but I don't have a strong opinion >> so this is fine too. > > I did consider this. I was on the verge of actually sending a question > to the list, asking for input on this choice. > > My reasoning was I'm personally a bit blind to the "false" part, from > all the years of focusing on the ifeq/ifneq, and that "ifeq foo, > false" feels a bit like the newbie "if (mybool == false)" construct. > > But I also agree with your stance. As long as we agree to use one > standard, I'll be happy to switch to "ifeq ... false". I think the > important thing is just that we don't have to look out for both "ifneq > ... true" and "ifeq ... false". Here is an updated webrev, that uses "ifeq" always (and tests for false instead): http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.03 I encountered one complicating issue. Statements such as this: ifneq ($(call isTargetOs, windows)+$(call isTargetCpu, x86_64), true+true) did not trivially allow themselves to be rewritten without ifneq. So I went ahead and fixed the two boolean operators And and Or, that I've been missing for a while. So, then I could rewrite it as: ifeq ($(call And, $(call isTargetOs, windows) $(call isTargetCpu, x86_64)), false) (I tried naming it "and" but it clashed with the GNU Make 4.0 $(and ...) function. (Which is not usable for us, since it considers "false" to be true.) I only used And, but created Or as well for completeness. /Magnus > > /Magnus >> >> /Erik >> >> On 2019-02-05 07:28, Magnus Ihse Bursie wrote: >>> On 2019-02-05 15:49, Magnus Ihse Bursie wrote: >>>> To check for various aspects of the build or target platform, we do >>>> a lot of checks like: >>>> ?? ifeq ($(OPENJDK_BUILD_OS_ENV), windows.cygwin) >>>> ?????? ... >>>> >>>> The naming of those platform information variables is a bit >>>> unfortunate. Yes, we know we're building OpenJDK, so why the >>>> OPENJDK_ prefix? I've been wanting for a long time to do something >>>> about this odd prefix, and it became more urgent after the recent >>>> fix of JDK-8160926, which pushes the matter about unifying the >>>> naming of build/target variables. >>>> >>>> The solution in this patch is not to rename the variables per se, >>>> but to introduce an abstraction layer in terms of function calls >>>> for checking platform aspects. >>>> >>>> This *really* shines when it comes to testing for multiple >>>> platforms. Previously, we were required to resort to constructs >>>> such as: >>>> >>>> ?? ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) >>>> >>>> but this can now be expressed as: >>>> >>>> ?? ifeq ($(call isTargetOs, windows solaris), true) >>>> >>>> Or this (actually technically broken) horrible example: >>>> >>>> ?? ifneq (, $(findstring $(OPENJDK_TARGET_OS), linux macosx)) >>>> >>>> which I had to read three times before being sure that this was the >>>> correct way to replace it: >>>> >>>> ?? ifeq ($(call isTargetOs, linux macosx), true) >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218431 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.01 >>> ... and here's an updated version that fixes a typo: >>> >>> http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.02 >>> >>> >>> /Magnus >>> >>>> >>>> /Magnus >>>> >>> > From magnus.ihse.bursie at oracle.com Wed Feb 6 16:38:11 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 6 Feb 2019 17:38:11 +0100 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: References: Message-ID: <9588d9f5-4207-b0c8-3793-d3b1643d6781@oracle.com> On 2019-02-06 16:17, Baesken, Matthias wrote: > Hello, please review this small change . > > I noticed (when looking into AIX xlc16 / xlclang++) the following: in the case that clang is used for compilation, HOTSPOT_BUILD_COMPILER claims to be a gcc . > This is a bit misleading. > This change adjusts the setting for clang usage on AIX (for future usage with xlclang++) and macOSX. > > Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy Oracle / Sun Studio versions ). > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8218562 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ Looks good to me. /Magnus > > > Thanks, Matthias From erik.joelsson at oracle.com Wed Feb 6 17:04:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 6 Feb 2019 09:04:48 -0800 Subject: RFR: JDK-8218431 Improved platform checking in makefiles In-Reply-To: <465b91b8-1624-2560-88e2-e9154a4effb1@oracle.com> References: <50535356-37f8-51b2-80be-d8bb8aaaaec1@oracle.com> <4a6a7d40-4b66-5367-c38b-6008ba6893a0@oracle.com> <105f425f-69c2-a03e-12f0-ebb51d6465c9@oracle.com> <465b91b8-1624-2560-88e2-e9154a4effb1@oracle.com> Message-ID: Thanks, looks good! /Erik On 2019-02-06 07:39, Magnus Ihse Bursie wrote: > > > On 2019-02-05 18:31, Magnus Ihse Bursie wrote: >> >> >> On 2019-02-05 18:01, Erik Joelsson wrote: >>> Looks good. I have read through all of them and it does not seem >>> like you got any wrong. >>> >>> I note that you chose to express negatives as: >>> >>> ifneq (isTargetFoo, true) >>> >>> instead of: >>> >>> ifeq (isTargetFoo, false) >>> >>> I think I would have preferred the latter, given that the new macros >>> return both true and false. I think true/false is more obvious to >>> the eye than the sneaky 'n' in ifneq, but I don't have a strong >>> opinion so this is fine too. >> >> I did consider this. I was on the verge of actually sending a >> question to the list, asking for input on this choice. >> >> My reasoning was I'm personally a bit blind to the "false" part, from >> all the years of focusing on the ifeq/ifneq, and that "ifeq foo, >> false" feels a bit like the newbie "if (mybool == false)" construct. >> >> But I also agree with your stance. As long as we agree to use one >> standard, I'll be happy to switch to "ifeq ... false". I think the >> important thing is just that we don't have to look out for both >> "ifneq ... true" and "ifeq ... false". > > Here is an updated webrev, that uses "ifeq" always (and tests for > false instead): > > http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.03 > > > I encountered one complicating issue. Statements such as this: > > ifneq ($(call isTargetOs, windows)+$(call isTargetCpu, x86_64), > true+true) > > did not trivially allow themselves to be rewritten without ifneq. So I > went ahead and fixed the two boolean operators And and Or, that I've > been missing for a while. So, then I could rewrite it as: > > ifeq ($(call And, $(call isTargetOs, windows) $(call isTargetCpu, > x86_64)), false) > > (I tried naming it "and" but it clashed with the GNU Make 4.0 $(and > ...) function. (Which is not usable for us, since it considers "false" > to be true.) > > I only used And, but created Or as well for completeness. > > /Magnus >> >> /Magnus >>> >>> /Erik >>> >>> On 2019-02-05 07:28, Magnus Ihse Bursie wrote: >>>> On 2019-02-05 15:49, Magnus Ihse Bursie wrote: >>>>> To check for various aspects of the build or target platform, we >>>>> do a lot of checks like: >>>>> ?? ifeq ($(OPENJDK_BUILD_OS_ENV), windows.cygwin) >>>>> ?????? ... >>>>> >>>>> The naming of those platform information variables is a bit >>>>> unfortunate. Yes, we know we're building OpenJDK, so why the >>>>> OPENJDK_ prefix? I've been wanting for a long time to do something >>>>> about this odd prefix, and it became more urgent after the recent >>>>> fix of JDK-8160926, which pushes the matter about unifying the >>>>> naming of build/target variables. >>>>> >>>>> The solution in this patch is not to rename the variables per se, >>>>> but to introduce an abstraction layer in terms of function calls >>>>> for checking platform aspects. >>>>> >>>>> This *really* shines when it comes to testing for multiple >>>>> platforms. Previously, we were required to resort to constructs >>>>> such as: >>>>> >>>>> ?? ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) >>>>> >>>>> but this can now be expressed as: >>>>> >>>>> ?? ifeq ($(call isTargetOs, windows solaris), true) >>>>> >>>>> Or this (actually technically broken) horrible example: >>>>> >>>>> ?? ifneq (, $(findstring $(OPENJDK_TARGET_OS), linux macosx)) >>>>> >>>>> which I had to read three times before being sure that this was >>>>> the correct way to replace it: >>>>> >>>>> ?? ifeq ($(call isTargetOs, linux macosx), true) >>>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218431 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.01 >>>> ... and here's an updated version that fixes a typo: >>>> >>>> http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.02 >>>> >>>> >>>> /Magnus >>>> >>>>> >>>>> /Magnus >>>>> >>>> >> > From francogpellegrini at gmail.com Wed Feb 6 19:07:12 2019 From: francogpellegrini at gmail.com (=?UTF-8?Q?Franco_Gast=C3=B3n_Pellegrini?=) Date: Wed, 6 Feb 2019 16:07:12 -0300 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> Message-ID: Can this be fixed before JDK 12? I will not able to compile java 12 32bits because I will not have java 11 32bits as a boot-jdk. El s?b., 24 de nov. de 2018 a la(s) 03:59, David Holmes ( david.holmes at oracle.com) escribi?: > On 23/11/2018 7:10 pm, Magnus Ihse Bursie wrote: > > > > On 2018-11-23 08:35, Franco Gast?n Pellegrini wrote: > >> Using the same command as before, and then using > >> make CONF=windows-x86-normal-client-fastdebug clean; > >> make CONF=windows-x86-normal-client-fastdebug; > >> > >> I get warnings as error, and cannot compile. The output is (and I > >> attached the logs): > >> > >> $ make CONF=windows-x86-normal-client-fastdebug; > >> Building target 'default (exploded-image)' in configuration > >> 'windows-x86-normal-client-fastdebug' > >> Compiling 8 files for BUILD_TOOLS_LANGTOOLS > >> Compiling 2 files for BUILD_JVMTI_TOOLS > >> Compiling 1 files for BUILD_JFR_TOOLS > >> Compiling 12 properties into resource bundles for jdk.jdeps > >> Compiling 7 properties into resource bundles for jdk.jshell > >> Parsing 2 properties into enum-like class for jdk.compiler > >> Compiling 19 properties into resource bundles for jdk.compiler > >> Compiling 13 properties into resource bundles for jdk.javadoc > >> Compiling 117 files for BUILD_java.compiler.interim > >> Compiling 394 files for BUILD_jdk.compiler.interim > >> Creating support/modules_libs/java.base/client/jvm.dll from 746 file(s) > >> Creating hotspot/variant-client/libjvm/gtest/jvm.dll from 90 file(s) > >> Creating hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1 > >> file(s) > >> Compiling 299 files for BUILD_jdk.javadoc.interim > >> Compiling 162 files for BUILD_TOOLS_JDK > >> Compiling 188 files for BUILD_jdk.rmic.interim > >> Note: Some input files use or override a deprecated API. > >> Note: Recompile with -Xlint:deprecation for details. > >> Note: Some input files use unchecked or unsafe operations. > >> Note: Recompile with -Xlint:unchecked for details. > >> Compiling 2 files for COMPILE_DEPEND > >> Note: Some input files use or override a deprecated API. > >> Note: Recompile with -Xlint:deprecation for details. > >> Compiling 2 files for BUILD_BREAKITERATOR_BASE > >> Compiling 2 files for BUILD_BREAKITERATOR_LD > >> SocketOptionRegistry.java.template > >> Compiling 11 properties into resource bundles for java.base > >> Compiling 6 properties into resource bundles for java.base > >> Compiling 11 properties into resource bundles for java.logging > >> Compiling 11 properties into resource bundles for jdk.jartool > >> Compiling 11 properties into resource bundles for jdk.management.agent > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > >> error C2220: warning treated as error - no 'object' file generated > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > >> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of > >> data > >> make[3]: *** [lib/CompileJvm.gmk:151: > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/hotspot/variant-client/libjvm/objs/classFileParser.obj] > > >> Error 1 > > > > 32-bit Windows is not regularly built, and might become unbuildable from > > time to time. I think you are running into > > https://bugs.openjdk.java.net/browse/JDK-8214206, which has a patch out > > for review. > > No, this isn't JDK-8214206 - that was caused by a change only in JDK 12. > > But the above must have been fixed at some point as 32-bit builds in > mainline are being done fairly regularly. (We have ARM 32-bit in our > tier 5 now). > > David > > > /Magnus > > > > > >> make[3]: *** Waiting for unfinished jobs.... > >> make[2]: *** [make/Main.gmk:257: hotspot-client-libs] Error 2 > >> make[2]: *** Waiting for unfinished jobs.... > >> Compiling 4 properties into resource bundles for jdk.jlink > >> Compiling 3 properties into resource bundles for jdk.jdi > >> Compiling 3 properties into resource bundles for jdk.jlink > >> Compiling 1 properties into resource bundles for jdk.jlink > >> > >> ERROR: Build failed for target 'default (exploded-image)' in > >> configuration 'windows-x86-normal-client-fastdebug' (exit code 2) > >> > >> === Output from failing command(s) repeated here === > >> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: > >> classFileParser.cpp > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > >> error C2220: warning treated as error - no 'object' file generated > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > >> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of > >> data > >> ... (rest of output omitted) > >> > >> * All command lines available in > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/make-support/failure-logs. > > >> > >> === End of repeated output === > >> > >> El jue., 22 de nov. de 2018 a la(s) 22:19, Franco Gast?n Pellegrini > >> (francogpellegrini at gmail.com ) > >> escribi?: > >> > >> yes, it was gcc, for some reason it get broken. I reinstall cygwin > >> and reconfigure it, an now it works, thanks! > >> > >> El lun., 5 de nov. de 2018 a la(s) 07:00, Magnus Ihse Bursie > >> (magnus.ihse.bursie at oracle.com > >> ) escribi?: > >> > >> On 2018-11-04 06:16, Franco Gast?n Pellegrini wrote: > >>> I used this command: > >>> /bash ./configure --enable-debug --with-target-bits=32 > >>> --with-toolchain-version=2017 --with-jvm-variants=client > >>> > >>> > --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/";/ > > >>> > >>> I tried Visual studio 2015 and 2017 (with-toolchain-version). > >>> I attached config.log as you asked. > >>> Thanks. > >>> > >>> El s?b., 3 de nov. de 2018 a la(s) 04:43, Magnus Ihse Bursie > >>> (magnus.ihse.bursie at oracle.com > >>> ) escribi?: > >>> > >>> Have you tried running > >>> > >>> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > > >>> > >>> > >>> from the same prompt you ran configure to see what > >>> happens? It seems to > >>> have located a compiler but fails to run it. > >>> > >> > >> Let me re-iterate this question: Have you tried running > >> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > > >> > >> from the same prompt you ran configure to see what happens? > >> > >> Here is the relevant part of the config.log, it basically says > >> it cannot compile a simple C program. You can try recreating > >> conftest.c as shown in the log below, or try just any other > >> simple C program. > >> > >> configure:35681: checking whether the C compiler works > >> configure:35703: > >> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > > >> > >> conftest.c >&5 > >> Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26732.1 > >> for x86 > >> Copyright (C) Microsoft Corporation. All rights reserved. > >> > >> conftest.c > >> Microsoft (R) Incremental Linker Version 14.15.26732.1 > >> Copyright (C) Microsoft Corporation. All rights reserved. > >> > >> /out:conftest.exe > >> conftest.obj > >> LINK : fatal error LNK1104: cannot open file 'conftest.exe' > >> configure:35707: $? = 2 > >> configure:35745: result: no > >> configure: failed program was: > >> | /* confdefs.h */ > >> | #define PACKAGE_NAME "OpenJDK" > >> | #define PACKAGE_TARNAME "openjdk" > >> | #define PACKAGE_VERSION "openjdk" > >> | #define PACKAGE_STRING "OpenJDK openjdk" > >> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" > >> > >> | #define PACKAGE_URL "http://openjdk.java.net" > >> > >> | /* end confdefs.h. */ > >> | > >> | int > >> | main () > >> | { > >> | > >> | ; > >> | return 0; > >> | } > >> configure:35750: error: in `/home/Franco/Java/jdk11': > >> configure:35752: error: C compiler cannot create executables > >> > >> /Magnus > >> > >>> > >>> There is also a second log file, config.log, generated by > >>> autoconf. It > >>> will hopefully contain output from the failed run of CL, > >>> and the > >>> complete command line it used when it concluded that the > >>> C compiler > >>> cannot create executables. > >>> > >>> /Magnus > >>> > >>> On 2018-11-03 02:50, Franco Gast?n Pellegrini wrote: > >>> > Hello, > >>> > When I try to comp?le OpenJDK 11, I get an error. I > >>> tried using visual > >>> > studio 2015 and 2017 with the same error. *Note that > >>> compiling OpenJDK 9 > >>> > and 10 work just fine.* > >>> > > >>> > I attached the log, but the error is: > >>> > > >>> > > >>> > >>> ********************************************************************** > >>> > ** Visual Studio 2017 Developer Command Prompt v15.8.9 > >>> > ** Copyright (c) 2017 Microsoft Corporation > >>> > > >>> > >>> ********************************************************************** > >>> > [vcvarsall.bat] Environment initialized for: 'x86' > >>> > configure: Setting extracted environment variables > >>> > checking for Visual Studio variables... ok > >>> > configure: Rewriting ipath to > >>> > > >>> > >>> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/include" > > >>> > >>> > configure: Rewriting ipath to > >>> > > >>> > >>> "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/include/um" > >>> > configure: Rewriting ipath to > >>> > > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/ucrt" > >>> > configure: Rewriting ipath to > >>> > > >>> > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/shared" > >>> > configure: Rewriting ipath to > >>> > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/um" > >>> > configure: Rewriting ipath to > >>> > > >>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/winrt" > >>> > configure: Rewriting ipath to > >>> > > >>> > >>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/cppwinrt" > >>> > configure: Rewriting libpath to > >>> > > >>> > >>> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/lib/x86" > > >>> > >>> > configure: Rewriting libpath to > >>> > > >>> > >>> "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/lib/um/x86" > >>> > configure: Rewriting libpath to > >>> > > "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/ucrt/x86" > >>> > configure: Rewriting libpath to > >>> > "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/um/x86" > >>> > checking for cl... > >>> > > >>> > >>> > /cygdrive/c/PROGRA~1/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/14.15.26726/bin/HostX86/x86/cl > > >>> > >>> > configure: Rewriting CC to > >>> > > >>> > >>> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl" > > >>> > >>> > checking resolved symbolic links for CC... no symlink > >>> > configure: Using microsoft C compiler version > >>> 19.15.26732.1 [Microsoft (R) > >>> > C/C++ Optimizing Compiler Version 19.15.26732.1 for x86] > >>> > checking whether the C compiler works... no > >>> > configure: error: in `/home/Franco/Java/jdk11': > >>> > configure: error: C compiler cannot create executables > >>> > See `config.log' for more details > >>> > configure exiting with result code 77 > >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> -- Franco Gast?n Pellegrini > >> > >> > >> > >> -- Franco Gast?n Pellegrini > >> > >> > >> > >> -- > >> Franco Gast?n Pellegrini > > > -- Franco Gast?n Pellegrini From erik.joelsson at oracle.com Wed Feb 6 19:15:28 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 6 Feb 2019 11:15:28 -0800 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> Message-ID: If you are running into warnings treated as errors, please try configuring with --disable-warnings-as-errors. That is often needed on less tested platforms. Note that as long as you run the build on a 64 bit system, you can use a 64 bit bootjdk to build a 32 bit JDK. /Erik On 2019-02-06 11:07, Franco Gast?n Pellegrini wrote: > Can this be fixed before JDK 12? I will not able to compile java 12 32bits > because I will not have java 11 32bits as a boot-jdk. > > El s?b., 24 de nov. de 2018 a la(s) 03:59, David Holmes ( > david.holmes at oracle.com) escribi?: > >> On 23/11/2018 7:10 pm, Magnus Ihse Bursie wrote: >>> On 2018-11-23 08:35, Franco Gast?n Pellegrini wrote: >>>> Using the same command as before, and then using >>>> make CONF=windows-x86-normal-client-fastdebug clean; >>>> make CONF=windows-x86-normal-client-fastdebug; >>>> >>>> I get warnings as error, and cannot compile. The output is (and I >>>> attached the logs): >>>> >>>> $ make CONF=windows-x86-normal-client-fastdebug; >>>> Building target 'default (exploded-image)' in configuration >>>> 'windows-x86-normal-client-fastdebug' >>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >>>> Compiling 2 files for BUILD_JVMTI_TOOLS >>>> Compiling 1 files for BUILD_JFR_TOOLS >>>> Compiling 12 properties into resource bundles for jdk.jdeps >>>> Compiling 7 properties into resource bundles for jdk.jshell >>>> Parsing 2 properties into enum-like class for jdk.compiler >>>> Compiling 19 properties into resource bundles for jdk.compiler >>>> Compiling 13 properties into resource bundles for jdk.javadoc >>>> Compiling 117 files for BUILD_java.compiler.interim >>>> Compiling 394 files for BUILD_jdk.compiler.interim >>>> Creating support/modules_libs/java.base/client/jvm.dll from 746 file(s) >>>> Creating hotspot/variant-client/libjvm/gtest/jvm.dll from 90 file(s) >>>> Creating hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1 >>>> file(s) >>>> Compiling 299 files for BUILD_jdk.javadoc.interim >>>> Compiling 162 files for BUILD_TOOLS_JDK >>>> Compiling 188 files for BUILD_jdk.rmic.interim >>>> Note: Some input files use or override a deprecated API. >>>> Note: Recompile with -Xlint:deprecation for details. >>>> Note: Some input files use unchecked or unsafe operations. >>>> Note: Recompile with -Xlint:unchecked for details. >>>> Compiling 2 files for COMPILE_DEPEND >>>> Note: Some input files use or override a deprecated API. >>>> Note: Recompile with -Xlint:deprecation for details. >>>> Compiling 2 files for BUILD_BREAKITERATOR_BASE >>>> Compiling 2 files for BUILD_BREAKITERATOR_LD >>>> SocketOptionRegistry.java.template >>>> Compiling 11 properties into resource bundles for java.base >>>> Compiling 6 properties into resource bundles for java.base >>>> Compiling 11 properties into resource bundles for java.logging >>>> Compiling 11 properties into resource bundles for jdk.jartool >>>> Compiling 11 properties into resource bundles for jdk.management.agent >>>> >> c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >> >>>> error C2220: warning treated as error - no 'object' file generated >>>> >> c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >> >>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of >>>> data >>>> make[3]: *** [lib/CompileJvm.gmk:151: >>>> >> /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/hotspot/variant-client/libjvm/objs/classFileParser.obj] >> >>>> Error 1 >>> 32-bit Windows is not regularly built, and might become unbuildable from >>> time to time. I think you are running into >>> https://bugs.openjdk.java.net/browse/JDK-8214206, which has a patch out >>> for review. >> No, this isn't JDK-8214206 - that was caused by a change only in JDK 12. >> >> But the above must have been fixed at some point as 32-bit builds in >> mainline are being done fairly regularly. (We have ARM 32-bit in our >> tier 5 now). >> >> David >> >>> /Magnus >>> >>> >>>> make[3]: *** Waiting for unfinished jobs.... >>>> make[2]: *** [make/Main.gmk:257: hotspot-client-libs] Error 2 >>>> make[2]: *** Waiting for unfinished jobs.... >>>> Compiling 4 properties into resource bundles for jdk.jlink >>>> Compiling 3 properties into resource bundles for jdk.jdi >>>> Compiling 3 properties into resource bundles for jdk.jlink >>>> Compiling 1 properties into resource bundles for jdk.jlink >>>> >>>> ERROR: Build failed for target 'default (exploded-image)' in >>>> configuration 'windows-x86-normal-client-fastdebug' (exit code 2) >>>> >>>> === Output from failing command(s) repeated here === >>>> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: >>>> classFileParser.cpp >>>> >> c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >> >>>> error C2220: warning treated as error - no 'object' file generated >>>> >> c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >> >>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of >>>> data >>>> ... (rest of output omitted) >>>> >>>> * All command lines available in >>>> >> /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/make-support/failure-logs. >> >>>> === End of repeated output === >>>> >>>> El jue., 22 de nov. de 2018 a la(s) 22:19, Franco Gast?n Pellegrini >>>> (francogpellegrini at gmail.com ) >>>> escribi?: >>>> >>>> yes, it was gcc, for some reason it get broken. I reinstall cygwin >>>> and reconfigure it, an now it works, thanks! >>>> >>>> El lun., 5 de nov. de 2018 a la(s) 07:00, Magnus Ihse Bursie >>>> (magnus.ihse.bursie at oracle.com >>>> ) escribi?: >>>> >>>> On 2018-11-04 06:16, Franco Gast?n Pellegrini wrote: >>>>> I used this command: >>>>> /bash ./configure --enable-debug --with-target-bits=32 >>>>> --with-toolchain-version=2017 --with-jvm-variants=client >>>>> >>>>> >> --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/";/ >> >>>>> I tried Visual studio 2015 and 2017 (with-toolchain-version). >>>>> I attached config.log as you asked. >>>>> Thanks. >>>>> >>>>> El s?b., 3 de nov. de 2018 a la(s) 04:43, Magnus Ihse Bursie >>>>> (magnus.ihse.bursie at oracle.com >>>>> ) escribi?: >>>>> >>>>> Have you tried running >>>>> >>>>> >> /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl >> >>>>> >>>>> from the same prompt you ran configure to see what >>>>> happens? It seems to >>>>> have located a compiler but fails to run it. >>>>> >>>> Let me re-iterate this question: Have you tried running >>>> >>>> >> /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl >> >>>> from the same prompt you ran configure to see what happens? >>>> >>>> Here is the relevant part of the config.log, it basically says >>>> it cannot compile a simple C program. You can try recreating >>>> conftest.c as shown in the log below, or try just any other >>>> simple C program. >>>> >>>> configure:35681: checking whether the C compiler works >>>> configure:35703: >>>> >>>> >> /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl >> >>>> conftest.c >&5 >>>> Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26732.1 >>>> for x86 >>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>> >>>> conftest.c >>>> Microsoft (R) Incremental Linker Version 14.15.26732.1 >>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>> >>>> /out:conftest.exe >>>> conftest.obj >>>> LINK : fatal error LNK1104: cannot open file 'conftest.exe' >>>> configure:35707: $? = 2 >>>> configure:35745: result: no >>>> configure: failed program was: >>>> | /* confdefs.h */ >>>> | #define PACKAGE_NAME "OpenJDK" >>>> | #define PACKAGE_TARNAME "openjdk" >>>> | #define PACKAGE_VERSION "openjdk" >>>> | #define PACKAGE_STRING "OpenJDK openjdk" >>>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" >>>> >>>> | #define PACKAGE_URL "http://openjdk.java.net" >>>> >>>> | /* end confdefs.h. */ >>>> | >>>> | int >>>> | main () >>>> | { >>>> | >>>> | ; >>>> | return 0; >>>> | } >>>> configure:35750: error: in `/home/Franco/Java/jdk11': >>>> configure:35752: error: C compiler cannot create executables >>>> >>>> /Magnus >>>> >>>>> There is also a second log file, config.log, generated by >>>>> autoconf. It >>>>> will hopefully contain output from the failed run of CL, >>>>> and the >>>>> complete command line it used when it concluded that the >>>>> C compiler >>>>> cannot create executables. >>>>> >>>>> /Magnus >>>>> >>>>> On 2018-11-03 02:50, Franco Gast?n Pellegrini wrote: >>>>> > Hello, >>>>> > When I try to comp?le OpenJDK 11, I get an error. I >>>>> tried using visual >>>>> > studio 2015 and 2017 with the same error. *Note that >>>>> compiling OpenJDK 9 >>>>> > and 10 work just fine.* >>>>> > >>>>> > I attached the log, but the error is: >>>>> > >>>>> > >>>>> >>>>> ********************************************************************** >>>>> > ** Visual Studio 2017 Developer Command Prompt v15.8.9 >>>>> > ** Copyright (c) 2017 Microsoft Corporation >>>>> > >>>>> >>>>> ********************************************************************** >>>>> > [vcvarsall.bat] Environment initialized for: 'x86' >>>>> > configure: Setting extracted environment variables >>>>> > checking for Visual Studio variables... ok >>>>> > configure: Rewriting ipath to >>>>> > >>>>> >>>>> >> "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/include" >> >>>>> > configure: Rewriting ipath to >>>>> > >>>>> >>>>> "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/include/um" >>>>> > configure: Rewriting ipath to >>>>> > >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/ucrt" >>>>> > configure: Rewriting ipath to >>>>> > >>>>> >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/shared" >>>>> > configure: Rewriting ipath to >>>>> > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/um" >>>>> > configure: Rewriting ipath to >>>>> > >>>>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/winrt" >>>>> > configure: Rewriting ipath to >>>>> > >>>>> >>>>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/cppwinrt" >>>>> > configure: Rewriting libpath to >>>>> > >>>>> >>>>> >> "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/lib/x86" >> >>>>> > configure: Rewriting libpath to >>>>> > >>>>> >>>>> "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/lib/um/x86" >>>>> > configure: Rewriting libpath to >>>>> > >> "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/ucrt/x86" >>>>> > configure: Rewriting libpath to >>>>> > "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/um/x86" >>>>> > checking for cl... >>>>> > >>>>> >>>>> >> /cygdrive/c/PROGRA~1/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/14.15.26726/bin/HostX86/x86/cl >> >>>>> > configure: Rewriting CC to >>>>> > >>>>> >>>>> >> "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl" >> >>>>> > checking resolved symbolic links for CC... no symlink >>>>> > configure: Using microsoft C compiler version >>>>> 19.15.26732.1 [Microsoft (R) >>>>> > C/C++ Optimizing Compiler Version 19.15.26732.1 for x86] >>>>> > checking whether the C compiler works... no >>>>> > configure: error: in `/home/Franco/Java/jdk11': >>>>> > configure: error: C compiler cannot create executables >>>>> > See `config.log' for more details >>>>> > configure exiting with result code 77 >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> -- Franco Gast?n Pellegrini >>>> >>>> >>>> -- Franco Gast?n Pellegrini >>>> >>>> >>>> >>>> -- >>>> Franco Gast?n Pellegrini > From francogpellegrini at gmail.com Wed Feb 6 22:15:19 2019 From: francogpellegrini at gmail.com (=?UTF-8?Q?Franco_Gast=C3=B3n_Pellegrini?=) Date: Wed, 6 Feb 2019 19:15:19 -0300 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> Message-ID: Thanks for the tip! El mi?., 6 de feb. de 2019 a la(s) 16:15, Erik Joelsson ( erik.joelsson at oracle.com) escribi?: > If you are running into warnings treated as errors, please try > configuring with --disable-warnings-as-errors. That is often needed on > less tested platforms. > > Note that as long as you run the build on a 64 bit system, you can use a > 64 bit bootjdk to build a 32 bit JDK. > > /Erik > > On 2019-02-06 11:07, Franco Gast?n Pellegrini wrote: > > Can this be fixed before JDK 12? I will not able to compile java 12 > 32bits > > because I will not have java 11 32bits as a boot-jdk. > > > > El s?b., 24 de nov. de 2018 a la(s) 03:59, David Holmes ( > > david.holmes at oracle.com) escribi?: > > > >> On 23/11/2018 7:10 pm, Magnus Ihse Bursie wrote: > >>> On 2018-11-23 08:35, Franco Gast?n Pellegrini wrote: > >>>> Using the same command as before, and then using > >>>> make CONF=windows-x86-normal-client-fastdebug clean; > >>>> make CONF=windows-x86-normal-client-fastdebug; > >>>> > >>>> I get warnings as error, and cannot compile. The output is (and I > >>>> attached the logs): > >>>> > >>>> $ make CONF=windows-x86-normal-client-fastdebug; > >>>> Building target 'default (exploded-image)' in configuration > >>>> 'windows-x86-normal-client-fastdebug' > >>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS > >>>> Compiling 2 files for BUILD_JVMTI_TOOLS > >>>> Compiling 1 files for BUILD_JFR_TOOLS > >>>> Compiling 12 properties into resource bundles for jdk.jdeps > >>>> Compiling 7 properties into resource bundles for jdk.jshell > >>>> Parsing 2 properties into enum-like class for jdk.compiler > >>>> Compiling 19 properties into resource bundles for jdk.compiler > >>>> Compiling 13 properties into resource bundles for jdk.javadoc > >>>> Compiling 117 files for BUILD_java.compiler.interim > >>>> Compiling 394 files for BUILD_jdk.compiler.interim > >>>> Creating support/modules_libs/java.base/client/jvm.dll from 746 > file(s) > >>>> Creating hotspot/variant-client/libjvm/gtest/jvm.dll from 90 file(s) > >>>> Creating hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1 > >>>> file(s) > >>>> Compiling 299 files for BUILD_jdk.javadoc.interim > >>>> Compiling 162 files for BUILD_TOOLS_JDK > >>>> Compiling 188 files for BUILD_jdk.rmic.interim > >>>> Note: Some input files use or override a deprecated API. > >>>> Note: Recompile with -Xlint:deprecation for details. > >>>> Note: Some input files use unchecked or unsafe operations. > >>>> Note: Recompile with -Xlint:unchecked for details. > >>>> Compiling 2 files for COMPILE_DEPEND > >>>> Note: Some input files use or override a deprecated API. > >>>> Note: Recompile with -Xlint:deprecation for details. > >>>> Compiling 2 files for BUILD_BREAKITERATOR_BASE > >>>> Compiling 2 files for BUILD_BREAKITERATOR_LD > >>>> SocketOptionRegistry.java.template > >>>> Compiling 11 properties into resource bundles for java.base > >>>> Compiling 6 properties into resource bundles for java.base > >>>> Compiling 11 properties into resource bundles for java.logging > >>>> Compiling 11 properties into resource bundles for jdk.jartool > >>>> Compiling 11 properties into resource bundles for jdk.management.agent > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> error C2220: warning treated as error - no 'object' file generated > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of > >>>> data > >>>> make[3]: *** [lib/CompileJvm.gmk:151: > >>>> > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/hotspot/variant-client/libjvm/objs/classFileParser.obj] > >> > >>>> Error 1 > >>> 32-bit Windows is not regularly built, and might become unbuildable > from > >>> time to time. I think you are running into > >>> https://bugs.openjdk.java.net/browse/JDK-8214206, which has a patch > out > >>> for review. > >> No, this isn't JDK-8214206 - that was caused by a change only in JDK 12. > >> > >> But the above must have been fixed at some point as 32-bit builds in > >> mainline are being done fairly regularly. (We have ARM 32-bit in our > >> tier 5 now). > >> > >> David > >> > >>> /Magnus > >>> > >>> > >>>> make[3]: *** Waiting for unfinished jobs.... > >>>> make[2]: *** [make/Main.gmk:257: hotspot-client-libs] Error 2 > >>>> make[2]: *** Waiting for unfinished jobs.... > >>>> Compiling 4 properties into resource bundles for jdk.jlink > >>>> Compiling 3 properties into resource bundles for jdk.jdi > >>>> Compiling 3 properties into resource bundles for jdk.jlink > >>>> Compiling 1 properties into resource bundles for jdk.jlink > >>>> > >>>> ERROR: Build failed for target 'default (exploded-image)' in > >>>> configuration 'windows-x86-normal-client-fastdebug' (exit code 2) > >>>> > >>>> === Output from failing command(s) repeated here === > >>>> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: > >>>> classFileParser.cpp > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> error C2220: warning treated as error - no 'object' file generated > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of > >>>> data > >>>> ... (rest of output omitted) > >>>> > >>>> * All command lines available in > >>>> > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/make-support/failure-logs. > >> > >>>> === End of repeated output === > >>>> > >>>> El jue., 22 de nov. de 2018 a la(s) 22:19, Franco Gast?n Pellegrini > >>>> (francogpellegrini at gmail.com ) > >>>> escribi?: > >>>> > >>>> yes, it was gcc, for some reason it get broken. I reinstall > cygwin > >>>> and reconfigure it, an now it works, thanks! > >>>> > >>>> El lun., 5 de nov. de 2018 a la(s) 07:00, Magnus Ihse Bursie > >>>> (magnus.ihse.bursie at oracle.com > >>>> ) escribi?: > >>>> > >>>> On 2018-11-04 06:16, Franco Gast?n Pellegrini wrote: > >>>>> I used this command: > >>>>> /bash ./configure --enable-debug --with-target-bits=32 > >>>>> --with-toolchain-version=2017 --with-jvm-variants=client > >>>>> > >>>>> > >> > --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/";/ > >> > >>>>> I tried Visual studio 2015 and 2017 > (with-toolchain-version). > >>>>> I attached config.log as you asked. > >>>>> Thanks. > >>>>> > >>>>> El s?b., 3 de nov. de 2018 a la(s) 04:43, Magnus Ihse Bursie > >>>>> (magnus.ihse.bursie at oracle.com > >>>>> ) escribi?: > >>>>> > >>>>> Have you tried running > >>>>> > >>>>> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > >> > >>>>> > >>>>> from the same prompt you ran configure to see what > >>>>> happens? It seems to > >>>>> have located a compiler but fails to run it. > >>>>> > >>>> Let me re-iterate this question: Have you tried running > >>>> > >>>> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > >> > >>>> from the same prompt you ran configure to see what happens? > >>>> > >>>> Here is the relevant part of the config.log, it basically > says > >>>> it cannot compile a simple C program. You can try recreating > >>>> conftest.c as shown in the log below, or try just any other > >>>> simple C program. > >>>> > >>>> configure:35681: checking whether the C compiler works > >>>> configure:35703: > >>>> > >>>> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > >> > >>>> conftest.c >&5 > >>>> Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26732.1 > >>>> for x86 > >>>> Copyright (C) Microsoft Corporation. All rights reserved. > >>>> > >>>> conftest.c > >>>> Microsoft (R) Incremental Linker Version 14.15.26732.1 > >>>> Copyright (C) Microsoft Corporation. All rights reserved. > >>>> > >>>> /out:conftest.exe > >>>> conftest.obj > >>>> LINK : fatal error LNK1104: cannot open file 'conftest.exe' > >>>> configure:35707: $? = 2 > >>>> configure:35745: result: no > >>>> configure: failed program was: > >>>> | /* confdefs.h */ > >>>> | #define PACKAGE_NAME "OpenJDK" > >>>> | #define PACKAGE_TARNAME "openjdk" > >>>> | #define PACKAGE_VERSION "openjdk" > >>>> | #define PACKAGE_STRING "OpenJDK openjdk" > >>>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" > >>>> > >>>> | #define PACKAGE_URL "http://openjdk.java.net" > >>>> > >>>> | /* end confdefs.h. */ > >>>> | > >>>> | int > >>>> | main () > >>>> | { > >>>> | > >>>> | ; > >>>> | return 0; > >>>> | } > >>>> configure:35750: error: in `/home/Franco/Java/jdk11': > >>>> configure:35752: error: C compiler cannot create executables > >>>> > >>>> /Magnus > >>>> > >>>>> There is also a second log file, config.log, generated > by > >>>>> autoconf. It > >>>>> will hopefully contain output from the failed run of CL, > >>>>> and the > >>>>> complete command line it used when it concluded that the > >>>>> C compiler > >>>>> cannot create executables. > >>>>> > >>>>> /Magnus > >>>>> > >>>>> On 2018-11-03 02:50, Franco Gast?n Pellegrini wrote: > >>>>> > Hello, > >>>>> > When I try to comp?le OpenJDK 11, I get an error. I > >>>>> tried using visual > >>>>> > studio 2015 and 2017 with the same error. *Note that > >>>>> compiling OpenJDK 9 > >>>>> > and 10 work just fine.* > >>>>> > > >>>>> > I attached the log, but the error is: > >>>>> > > >>>>> > > >>>>> > >>>>> > ********************************************************************** > >>>>> > ** Visual Studio 2017 Developer Command Prompt v15.8.9 > >>>>> > ** Copyright (c) 2017 Microsoft Corporation > >>>>> > > >>>>> > >>>>> > ********************************************************************** > >>>>> > [vcvarsall.bat] Environment initialized for: 'x86' > >>>>> > configure: Setting extracted environment variables > >>>>> > checking for Visual Studio variables... ok > >>>>> > configure: Rewriting ipath to > >>>>> > > >>>>> > >>>>> > >> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/include" > >> > >>>>> > configure: Rewriting ipath to > >>>>> > > >>>>> > >>>>> "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/include/um" > >>>>> > configure: Rewriting ipath to > >>>>> > > >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/ucrt" > >>>>> > configure: Rewriting ipath to > >>>>> > > >>>>> > >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/shared" > >>>>> > configure: Rewriting ipath to > >>>>> > > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/um" > >>>>> > configure: Rewriting ipath to > >>>>> > > >>>>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/winrt" > >>>>> > configure: Rewriting ipath to > >>>>> > > >>>>> > >>>>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/cppwinrt" > >>>>> > configure: Rewriting libpath to > >>>>> > > >>>>> > >>>>> > >> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/lib/x86" > >> > >>>>> > configure: Rewriting libpath to > >>>>> > > >>>>> > >>>>> "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/lib/um/x86" > >>>>> > configure: Rewriting libpath to > >>>>> > > >> "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/ucrt/x86" > >>>>> > configure: Rewriting libpath to > >>>>> > > "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/um/x86" > >>>>> > checking for cl... > >>>>> > > >>>>> > >>>>> > >> > /cygdrive/c/PROGRA~1/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/14.15.26726/bin/HostX86/x86/cl > >> > >>>>> > configure: Rewriting CC to > >>>>> > > >>>>> > >>>>> > >> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl" > >> > >>>>> > checking resolved symbolic links for CC... no symlink > >>>>> > configure: Using microsoft C compiler version > >>>>> 19.15.26732.1 [Microsoft (R) > >>>>> > C/C++ Optimizing Compiler Version 19.15.26732.1 for > x86] > >>>>> > checking whether the C compiler works... no > >>>>> > configure: error: in `/home/Franco/Java/jdk11': > >>>>> > configure: error: C compiler cannot create executables > >>>>> > See `config.log' for more details > >>>>> > configure exiting with result code 77 > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> -- Franco Gast?n Pellegrini > >>>> > >>>> > >>>> -- Franco Gast?n Pellegrini > >>>> > >>>> > >>>> > >>>> -- > >>>> Franco Gast?n Pellegrini > > > -- Franco Gast?n Pellegrini From francogpellegrini at gmail.com Wed Feb 6 22:23:02 2019 From: francogpellegrini at gmail.com (=?UTF-8?Q?Franco_Gast=C3=B3n_Pellegrini?=) Date: Wed, 6 Feb 2019 19:23:02 -0300 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> Message-ID: I just tried --disable-warnings-as-errors, and JDK 11 64bits as a bootjdk, but I get a lots of errors, and it refuse to build, like this: c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' El mi?., 6 de feb. de 2019 a la(s) 16:15, Erik Joelsson ( erik.joelsson at oracle.com) escribi?: > If you are running into warnings treated as errors, please try > configuring with --disable-warnings-as-errors. That is often needed on > less tested platforms. > > Note that as long as you run the build on a 64 bit system, you can use a > 64 bit bootjdk to build a 32 bit JDK. > > /Erik > > On 2019-02-06 11:07, Franco Gast?n Pellegrini wrote: > > Can this be fixed before JDK 12? I will not able to compile java 12 > 32bits > > because I will not have java 11 32bits as a boot-jdk. > > > > El s?b., 24 de nov. de 2018 a la(s) 03:59, David Holmes ( > > david.holmes at oracle.com) escribi?: > > > >> On 23/11/2018 7:10 pm, Magnus Ihse Bursie wrote: > >>> On 2018-11-23 08:35, Franco Gast?n Pellegrini wrote: > >>>> Using the same command as before, and then using > >>>> make CONF=windows-x86-normal-client-fastdebug clean; > >>>> make CONF=windows-x86-normal-client-fastdebug; > >>>> > >>>> I get warnings as error, and cannot compile. The output is (and I > >>>> attached the logs): > >>>> > >>>> $ make CONF=windows-x86-normal-client-fastdebug; > >>>> Building target 'default (exploded-image)' in configuration > >>>> 'windows-x86-normal-client-fastdebug' > >>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS > >>>> Compiling 2 files for BUILD_JVMTI_TOOLS > >>>> Compiling 1 files for BUILD_JFR_TOOLS > >>>> Compiling 12 properties into resource bundles for jdk.jdeps > >>>> Compiling 7 properties into resource bundles for jdk.jshell > >>>> Parsing 2 properties into enum-like class for jdk.compiler > >>>> Compiling 19 properties into resource bundles for jdk.compiler > >>>> Compiling 13 properties into resource bundles for jdk.javadoc > >>>> Compiling 117 files for BUILD_java.compiler.interim > >>>> Compiling 394 files for BUILD_jdk.compiler.interim > >>>> Creating support/modules_libs/java.base/client/jvm.dll from 746 > file(s) > >>>> Creating hotspot/variant-client/libjvm/gtest/jvm.dll from 90 file(s) > >>>> Creating hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1 > >>>> file(s) > >>>> Compiling 299 files for BUILD_jdk.javadoc.interim > >>>> Compiling 162 files for BUILD_TOOLS_JDK > >>>> Compiling 188 files for BUILD_jdk.rmic.interim > >>>> Note: Some input files use or override a deprecated API. > >>>> Note: Recompile with -Xlint:deprecation for details. > >>>> Note: Some input files use unchecked or unsafe operations. > >>>> Note: Recompile with -Xlint:unchecked for details. > >>>> Compiling 2 files for COMPILE_DEPEND > >>>> Note: Some input files use or override a deprecated API. > >>>> Note: Recompile with -Xlint:deprecation for details. > >>>> Compiling 2 files for BUILD_BREAKITERATOR_BASE > >>>> Compiling 2 files for BUILD_BREAKITERATOR_LD > >>>> SocketOptionRegistry.java.template > >>>> Compiling 11 properties into resource bundles for java.base > >>>> Compiling 6 properties into resource bundles for java.base > >>>> Compiling 11 properties into resource bundles for java.logging > >>>> Compiling 11 properties into resource bundles for jdk.jartool > >>>> Compiling 11 properties into resource bundles for jdk.management.agent > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> error C2220: warning treated as error - no 'object' file generated > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of > >>>> data > >>>> make[3]: *** [lib/CompileJvm.gmk:151: > >>>> > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/hotspot/variant-client/libjvm/objs/classFileParser.obj] > >> > >>>> Error 1 > >>> 32-bit Windows is not regularly built, and might become unbuildable > from > >>> time to time. I think you are running into > >>> https://bugs.openjdk.java.net/browse/JDK-8214206, which has a patch > out > >>> for review. > >> No, this isn't JDK-8214206 - that was caused by a change only in JDK 12. > >> > >> But the above must have been fixed at some point as 32-bit builds in > >> mainline are being done fairly regularly. (We have ARM 32-bit in our > >> tier 5 now). > >> > >> David > >> > >>> /Magnus > >>> > >>> > >>>> make[3]: *** Waiting for unfinished jobs.... > >>>> make[2]: *** [make/Main.gmk:257: hotspot-client-libs] Error 2 > >>>> make[2]: *** Waiting for unfinished jobs.... > >>>> Compiling 4 properties into resource bundles for jdk.jlink > >>>> Compiling 3 properties into resource bundles for jdk.jdi > >>>> Compiling 3 properties into resource bundles for jdk.jlink > >>>> Compiling 1 properties into resource bundles for jdk.jlink > >>>> > >>>> ERROR: Build failed for target 'default (exploded-image)' in > >>>> configuration 'windows-x86-normal-client-fastdebug' (exit code 2) > >>>> > >>>> === Output from failing command(s) repeated here === > >>>> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: > >>>> classFileParser.cpp > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> error C2220: warning treated as error - no 'object' file generated > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of > >>>> data > >>>> ... (rest of output omitted) > >>>> > >>>> * All command lines available in > >>>> > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/make-support/failure-logs. > >> > >>>> === End of repeated output === > >>>> > >>>> El jue., 22 de nov. de 2018 a la(s) 22:19, Franco Gast?n Pellegrini > >>>> (francogpellegrini at gmail.com ) > >>>> escribi?: > >>>> > >>>> yes, it was gcc, for some reason it get broken. I reinstall > cygwin > >>>> and reconfigure it, an now it works, thanks! > >>>> > >>>> El lun., 5 de nov. de 2018 a la(s) 07:00, Magnus Ihse Bursie > >>>> (magnus.ihse.bursie at oracle.com > >>>> ) escribi?: > >>>> > >>>> On 2018-11-04 06:16, Franco Gast?n Pellegrini wrote: > >>>>> I used this command: > >>>>> /bash ./configure --enable-debug --with-target-bits=32 > >>>>> --with-toolchain-version=2017 --with-jvm-variants=client > >>>>> > >>>>> > >> > --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/";/ > >> > >>>>> I tried Visual studio 2015 and 2017 > (with-toolchain-version). > >>>>> I attached config.log as you asked. > >>>>> Thanks. > >>>>> > >>>>> El s?b., 3 de nov. de 2018 a la(s) 04:43, Magnus Ihse Bursie > >>>>> (magnus.ihse.bursie at oracle.com > >>>>> ) escribi?: > >>>>> > >>>>> Have you tried running > >>>>> > >>>>> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > >> > >>>>> > >>>>> from the same prompt you ran configure to see what > >>>>> happens? It seems to > >>>>> have located a compiler but fails to run it. > >>>>> > >>>> Let me re-iterate this question: Have you tried running > >>>> > >>>> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > >> > >>>> from the same prompt you ran configure to see what happens? > >>>> > >>>> Here is the relevant part of the config.log, it basically > says > >>>> it cannot compile a simple C program. You can try recreating > >>>> conftest.c as shown in the log below, or try just any other > >>>> simple C program. > >>>> > >>>> configure:35681: checking whether the C compiler works > >>>> configure:35703: > >>>> > >>>> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > >> > >>>> conftest.c >&5 > >>>> Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26732.1 > >>>> for x86 > >>>> Copyright (C) Microsoft Corporation. All rights reserved. > >>>> > >>>> conftest.c > >>>> Microsoft (R) Incremental Linker Version 14.15.26732.1 > >>>> Copyright (C) Microsoft Corporation. All rights reserved. > >>>> > >>>> /out:conftest.exe > >>>> conftest.obj > >>>> LINK : fatal error LNK1104: cannot open file 'conftest.exe' > >>>> configure:35707: $? = 2 > >>>> configure:35745: result: no > >>>> configure: failed program was: > >>>> | /* confdefs.h */ > >>>> | #define PACKAGE_NAME "OpenJDK" > >>>> | #define PACKAGE_TARNAME "openjdk" > >>>> | #define PACKAGE_VERSION "openjdk" > >>>> | #define PACKAGE_STRING "OpenJDK openjdk" > >>>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" > >>>> > >>>> | #define PACKAGE_URL "http://openjdk.java.net" > >>>> > >>>> | /* end confdefs.h. */ > >>>> | > >>>> | int > >>>> | main () > >>>> | { > >>>> | > >>>> | ; > >>>> | return 0; > >>>> | } > >>>> configure:35750: error: in `/home/Franco/Java/jdk11': > >>>> configure:35752: error: C compiler cannot create executables > >>>> > >>>> /Magnus > >>>> > >>>>> There is also a second log file, config.log, generated > by > >>>>> autoconf. It > >>>>> will hopefully contain output from the failed run of CL, > >>>>> and the > >>>>> complete command line it used when it concluded that the > >>>>> C compiler > >>>>> cannot create executables. > >>>>> > >>>>> /Magnus > >>>>> > >>>>> On 2018-11-03 02:50, Franco Gast?n Pellegrini wrote: > >>>>> > Hello, > >>>>> > When I try to comp?le OpenJDK 11, I get an error. I > >>>>> tried using visual > >>>>> > studio 2015 and 2017 with the same error. *Note that > >>>>> compiling OpenJDK 9 > >>>>> > and 10 work just fine.* > >>>>> > > >>>>> > I attached the log, but the error is: > >>>>> > > >>>>> > > >>>>> > >>>>> > ********************************************************************** > >>>>> > ** Visual Studio 2017 Developer Command Prompt v15.8.9 > >>>>> > ** Copyright (c) 2017 Microsoft Corporation > >>>>> > > >>>>> > >>>>> > ********************************************************************** > >>>>> > [vcvarsall.bat] Environment initialized for: 'x86' > >>>>> > configure: Setting extracted environment variables > >>>>> > checking for Visual Studio variables... ok > >>>>> > configure: Rewriting ipath to > >>>>> > > >>>>> > >>>>> > >> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/include" > >> > >>>>> > configure: Rewriting ipath to > >>>>> > > >>>>> > >>>>> "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/include/um" > >>>>> > configure: Rewriting ipath to > >>>>> > > >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/ucrt" > >>>>> > configure: Rewriting ipath to > >>>>> > > >>>>> > >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/shared" > >>>>> > configure: Rewriting ipath to > >>>>> > > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/um" > >>>>> > configure: Rewriting ipath to > >>>>> > > >>>>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/winrt" > >>>>> > configure: Rewriting ipath to > >>>>> > > >>>>> > >>>>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/cppwinrt" > >>>>> > configure: Rewriting libpath to > >>>>> > > >>>>> > >>>>> > >> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/lib/x86" > >> > >>>>> > configure: Rewriting libpath to > >>>>> > > >>>>> > >>>>> "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/lib/um/x86" > >>>>> > configure: Rewriting libpath to > >>>>> > > >> "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/ucrt/x86" > >>>>> > configure: Rewriting libpath to > >>>>> > > "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/um/x86" > >>>>> > checking for cl... > >>>>> > > >>>>> > >>>>> > >> > /cygdrive/c/PROGRA~1/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/14.15.26726/bin/HostX86/x86/cl > >> > >>>>> > configure: Rewriting CC to > >>>>> > > >>>>> > >>>>> > >> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl" > >> > >>>>> > checking resolved symbolic links for CC... no symlink > >>>>> > configure: Using microsoft C compiler version > >>>>> 19.15.26732.1 [Microsoft (R) > >>>>> > C/C++ Optimizing Compiler Version 19.15.26732.1 for > x86] > >>>>> > checking whether the C compiler works... no > >>>>> > configure: error: in `/home/Franco/Java/jdk11': > >>>>> > configure: error: C compiler cannot create executables > >>>>> > See `config.log' for more details > >>>>> > configure exiting with result code 77 > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> -- Franco Gast?n Pellegrini > >>>> > >>>> > >>>> -- Franco Gast?n Pellegrini > >>>> > >>>> > >>>> > >>>> -- > >>>> Franco Gast?n Pellegrini > > > -- Franco Gast?n Pellegrini From matthias.baesken at sap.com Thu Feb 7 09:12:39 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 7 Feb 2019 09:12:39 +0000 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: <9588d9f5-4207-b0c8-3793-d3b1643d6781@oracle.com> References: <9588d9f5-4207-b0c8-3793-d3b1643d6781@oracle.com> Message-ID: Thanks . A second review would be great . Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Mittwoch, 6. Februar 2019 17:38 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; 'build- > dev at openjdk.java.net' > Subject: Re: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for > clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings > > On 2019-02-06 16:17, Baesken, Matthias wrote: > > Hello, please review this small change . > > > > I noticed (when looking into AIX xlc16 / xlclang++) the following: in the > case that clang is used for compilation, HOTSPOT_BUILD_COMPILER claims > to be a gcc . > > This is a bit misleading. > > This change adjusts the setting for clang usage on AIX (for future usage > with xlclang++) and macOSX. > > > > Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy > Oracle / Sun Studio versions ). > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8218562 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ > Looks good to me. > > /Magnus > > > > > > Thanks, Matthias From martin.doerr at sap.com Thu Feb 7 09:17:33 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 7 Feb 2019 09:17:33 +0000 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: References: <9588d9f5-4207-b0c8-3793-d3b1643d6781@oracle.com> Message-ID: Hi Matthias, looks good to me, too. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Baesken, Matthias Sent: Donnerstag, 7. Februar 2019 10:13 To: Magnus Ihse Bursie ; 'hotspot-dev at openjdk.java.net' ; 'build-dev at openjdk.java.net' Subject: RE: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings Thanks . A second review would be great . Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Mittwoch, 6. Februar 2019 17:38 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; 'build- > dev at openjdk.java.net' > Subject: Re: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for > clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings > > On 2019-02-06 16:17, Baesken, Matthias wrote: > > Hello, please review this small change . > > > > I noticed (when looking into AIX xlc16 / xlclang++) the following: in the > case that clang is used for compilation, HOTSPOT_BUILD_COMPILER claims > to be a gcc . > > This is a bit misleading. > > This change adjusts the setting for clang usage on AIX (for future usage > with xlclang++) and macOSX. > > > > Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy > Oracle / Sun Studio versions ). > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8218562 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ > Looks good to me. > > /Magnus > > > > > > Thanks, Matthias From david.holmes at oracle.com Thu Feb 7 09:36:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Feb 2019 19:36:23 +1000 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: References: Message-ID: <0fcee21f-f147-fd78-4571-8f683e4a8bc4@oracle.com> Hi Matthias, On 7/02/2019 1:17 am, Baesken, Matthias wrote: > Hello, please review this small change . > > I noticed (when looking into AIX xlc16 / xlclang++) the following: in the case that clang is used for compilation, HOTSPOT_BUILD_COMPILER claims to be a gcc . > This is a bit misleading. > This change adjusts the setting for clang usage on AIX (for future usage with xlclang++) and macOSX. > > Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy Oracle / Sun Studio versions ). Possibly more could be removed :) Changes seem fine. I've always been irked by the fact we can access an actual version string from the compilers themselves, so we wouldn't need this code. Thanks, David > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8218562 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ > > > Thanks, Matthias > From magnus.ihse.bursie at oracle.com Thu Feb 7 11:38:10 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Feb 2019 12:38:10 +0100 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: <0fcee21f-f147-fd78-4571-8f683e4a8bc4@oracle.com> References: <0fcee21f-f147-fd78-4571-8f683e4a8bc4@oracle.com> Message-ID: <33d2b12a-8ab4-256d-701f-c47798ed749e@oracle.com> On 2019-02-07 10:36, David Holmes wrote: > Hi Matthias, > > On 7/02/2019 1:17 am, Baesken, Matthias wrote: >> Hello, please review this small change . >> >> I noticed (when looking into AIX xlc16 / xlclang++)? the >> following:??? in the case that? clang is used for compilation,??? >> HOTSPOT_BUILD_COMPILER?? claims to be a gcc . >> This is a bit misleading. >> This change? adjusts the setting for clang usage on? AIX? (for future >> usage with xlclang++)?? and macOSX. >> >> Additionally I removed some? old? HOTSPOT_BUILD_COMPILER?? for legacy >> Oracle / Sun Studio versions ). > > Possibly more could be removed :) > > Changes seem fine. > > I've always been irked by the fact we can access an actual version > string from the compilers themselves, so we wouldn't need this code. How do you do that? I'm having this kind of background low-intensity itch to fix the duplication between hotspot and build system in this (and related system detection code). It never rises to enough annoyance to actually get me to do anything about it, though. /Magnus > > Thanks, > David > >> >> Bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8218562 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ >> >> >> Thanks, Matthias >> From david.holmes at oracle.com Thu Feb 7 11:44:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Feb 2019 21:44:47 +1000 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: <33d2b12a-8ab4-256d-701f-c47798ed749e@oracle.com> References: <0fcee21f-f147-fd78-4571-8f683e4a8bc4@oracle.com> <33d2b12a-8ab4-256d-701f-c47798ed749e@oracle.com> Message-ID: <008410b9-87cb-1fdd-1b97-8b96900122cc@oracle.com> On 7/02/2019 9:38 pm, Magnus Ihse Bursie wrote: > On 2019-02-07 10:36, David Holmes wrote: >> Hi Matthias, >> >> On 7/02/2019 1:17 am, Baesken, Matthias wrote: >>> Hello, please review this small change . >>> >>> I noticed (when looking into AIX xlc16 / xlclang++)? the >>> following:??? in the case that? clang is used for compilation, >>> HOTSPOT_BUILD_COMPILER?? claims to be a gcc . >>> This is a bit misleading. >>> This change? adjusts the setting for clang usage on? AIX? (for future >>> usage with xlclang++)?? and macOSX. >>> >>> Additionally I removed some? old? HOTSPOT_BUILD_COMPILER?? for legacy >>> Oracle / Sun Studio versions ). >> >> Possibly more could be removed :) >> >> Changes seem fine. >> >> I've always been irked by the fact we can access an actual version >> string from the compilers themselves, so we wouldn't need this code. > How do you do that? Sorry typo s/we can access/we can't access/ > I'm having this kind of background low-intensity itch to fix the > duplication between hotspot and build system in this (and related system > detection code). It never rises to enough annoyance to actually get me > to do anything about it, though. I guess configure could generate a version string for hotspot to use, but it's probably not the brief version string we prefer to have. David > /Magnus > > >> >> Thanks, >> David >> >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8218562 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ >>> >>> >>> Thanks, Matthias >>> > From sgehwolf at redhat.com Thu Feb 7 17:09:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 Feb 2019 18:09:18 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries Message-ID: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Hi, Could I please get reviews for this enhancement? It adds a debug symbols stripping plug-in to jlink for Linux and Unix platforms. It's the first platform specific jlink plugin and the approach taken for keeping it contained is to use a plugin specific ResourceBundle. Discussion for this happened in [1]. The test uses a native library which should never get debug symbols stripped during the test library build. As such, tiny modifications were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev being on the list for this RFR. The test currently only runs on Linux and requires objcopy to be available. Otherwise the test is being skipped. Example usage of this plugin is described in the bug. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on Linux x86_64 (with good and broken objcopy) and the newly added test. It's currently running through jdk/submit too. Thoughts? Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html From jan.lahoda at oracle.com Thu Feb 7 17:15:36 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 7 Feb 2019 18:15:36 +0100 Subject: RFR: JDK-8218630: CreateSymbols includes class and module headers unnecessarily. Message-ID: <5C5C67B8.5050302@oracle.com> Hi, Joe noted that the proposed historical data for JDK 12: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ may contain unnecessary items, and it indeed is the case. The main problems appear to be: -when the class headers are being compared, the nestMembers for the current version may be null, and the nestMembers for the previous version may be an empty list. So, currently, such headers won't match and the header will be generated again to the historical record. listMatch can be used to consider null and empty list to be the same -module header descriptions may refer to RequiresDescription/ProvidesDescription, which are missing hashCode/equals, which means that headers that have either requires or provides won't match any of the existing headers. The fix is to add hashCode and equals I generated the ct.sym for the original JDK 12 historical data from http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ and the historical data generated by this patch, and the resulting content appears to be equivalent. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8218630/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8218630 How does this look? Thanks, Jan From jan.lahoda at oracle.com Thu Feb 7 17:21:45 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 7 Feb 2019 18:21:45 +0100 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <5C4207A4.1040203@oracle.com> References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com> <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com> <5C40B289.7070408@oracle.com> <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com> <5C40CF23.4050608@oracle.com> <5C4207A4.1040203@oracle.com> Message-ID: <5C5C6929.30108@oracle.com> Hello, I've regenerated the patch using JDK 12b30, and also using the patch from: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012938.html (which makes the historical record smaller). The updated patch is here: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.04/ How does that look? Thanks, Jan On 18.1.2019 18:06, Jan Lahoda wrote: > Adding build-dev. > > Jan > > On 17.1.2019 19:53, Jan Lahoda wrote: >> On 17.1.2019 17:58, Jonathan Gibbons wrote: >>> Re: >>> >>> 36 # The checkout must not have any local changes that could >>> interfere with the new data. In particular, >>> 37 # there must be absolutely no changed, new or removed files >>> under the ${JDK_CHECKOUT}/make/data/symbols >>> 38 # directory. >>> >>> That seems like a simple check that could be incorporated into the >>> script itself. >>> >>> But, it also seems reasonable to separate enhancements like that from >>> the specific issue here, to add historical data for 12. >> >> Ok. Sent as: >> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html >> >> >> >> And limited this patch to the historical data only: >> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/ >> >> Thanks, >> Jan >> >>> >>> -- Jon >>> >>> On 1/17/19 8:51 AM, Jan Lahoda wrote: >>>> Hi Joe, >>>> >>>> On 17.1.2019 02:13, Joseph D. Darcy wrote: >>>>> Hi Jan, >>>>> >>>>> On 1/8/2019 2:13 AM, Jan Lahoda wrote: >>>>>> Hi Joe, >>>>>> >>>>>> Thanks for the comments, some responses inline. Updated webrev: >>>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/ >>>>>> >>>>>> On 7.1.2019 23:51, Joseph D. Darcy wrote: >>>>>>> Hi Jan, >>>>>>> >>>>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> To make --release 12 work, we need to add historical data for JDK >>>>>>>> 12. >>>>>>>> The current historical data is based on: >>>>>>>> $ javac -fullversion >>>>>>>> javac full version "12-ea+26" >>>>>>>> >>>>>>>> We may need to update the data once JDK 12 is out to cover any >>>>>>>> changes >>>>>>>> to the APIs that might happen. >>>>>>>> >>>>>>>> The patch also adds a simple (shell) script to generate the >>>>>>>> data, so >>>>>>>> all that was needed to generate the data was: >>>>>>>> $ cd make/data/symbols >>>>>>>> $ sh generate-data >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >>>>>>>> >>>>>>>> How does this look? >>>>>>> >>>>>>> If the overhead is small enough and we don't mind a few updates to >>>>>>> the >>>>>>> JDK N+1 data, than perhaps the generation of this information >>>>>>> could be >>>>>>> included as part of the start of JDK N+1 activities. >>>>>> >>>>>> That would be perfect! >>>>>> >>>>>>> >>>>>>> I suggest a more extensive description of how to >>>>>>> make/data/symbols/generate-data. For example, this builds the data >>>>>>> for >>>>>>> the current release independent of whether or not the current >>>>>>> release >>>>>>> has already had its data generated, correct? >>>>>> >>>>>> Yes. >>>>>> >>>>>>> >>>>>>> Concretely, if JDK N+1 has already forked, what is the proper way >>>>>>> to get >>>>>>> data for JDK N? Likewise, how should a re-build of the data for JDK >>>>>>> N be >>>>>>> done? >>>>>> >>>>>> What exactly should be there? To the existing description: >>>>>> # to generate (add) data for JDK N, do: >>>>>> # cd make/data/symbols >>>>>> # sh generate-data >>>>>> >>>>>> I've added (in .01): >>>>>> # to regenerate the data for JDK N, run the above commands again >>>>>> >>>>>> What more should be there? >>>>>> >>>>> >>>>> I'd appreciate somewhere to have a textual discussion of how >>>>> make/data/symbols/symbols should be updated, the A = 10, B = 11, etc. >>>>> convention, what else need to be done to generate the contents of this >>>>> changeset. >>>>> >>>>> The is the contents of the build directory? >>>>> >>>>> In general, a description of how the data of JDK N should be added to >>>>> JDK (N+1). >>>> >>>> I've added more textual description to the script, an updated webrev >>>> is here: >>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/ >>>> >>>> Jan >>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> From erik.joelsson at oracle.com Thu Feb 7 17:39:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Feb 2019 09:39:09 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> Hello Severin, There is a macro for automatically finding all source dirs for a module. So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using that macro, like this: JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) The above could/should even be inlined. Otherwise build changes look ok. /Erik On 2019-02-07 09:09, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this enhancement? It adds a debug > symbols stripping plug-in to jlink for Linux and Unix platforms. It's > the first platform specific jlink plugin and the approach taken for > keeping it contained is to use a plugin specific ResourceBundle. > Discussion for this happened in [1]. > > The test uses a native library which should never get debug symbols > stripped during the test library build. As such, tiny modifications > were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev > being on the list for this RFR. The test currently only runs on Linux > and requires objcopy to be available. Otherwise the test is being > skipped. > > Example usage of this plugin is described in the bug. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on Linux > x86_64 (with good and broken objcopy) and the newly added test. It's > currently running through jdk/submit too. > > Thoughts? > > Thanks, > Severin > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html > From jonathan.gibbons at oracle.com Thu Feb 7 18:27:31 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 7 Feb 2019 10:27:31 -0800 Subject: RFR: JDK-8218630: CreateSymbols includes class and module headers unnecessarily. In-Reply-To: <5C5C67B8.5050302@oracle.com> References: <5C5C67B8.5050302@oracle.com> Message-ID: <3747b7e8-c8a2-a4ca-264d-38b2df8dc5f8@oracle.com> Looks good to me. -- Jon On 2/7/19 9:15 AM, Jan Lahoda wrote: > Hi, > > Joe noted that the proposed historical data for JDK 12: > http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ > may contain unnecessary items, and it indeed is the case. > > The main problems appear to be: > -when the class headers are being compared, the nestMembers for the > current version may be null, and the nestMembers for the previous > version may be an empty list. So, currently, such headers won't match > and the header will be generated again to the historical record. > listMatch can be used to consider null and empty list to be the same > > -module header descriptions may refer to > RequiresDescription/ProvidesDescription, which are missing > hashCode/equals, which means that headers that have either requires or > provides won't match any of the existing headers. The fix is to add > hashCode and equals > > I generated the ct.sym for the original JDK 12 historical data from > http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ > > and the historical data generated by this patch, and the resulting > content appears to be equivalent. > > Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8218630/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218630 > > How does this look? > > Thanks, > ??? Jan From jonathan.gibbons at oracle.com Thu Feb 7 18:30:16 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 7 Feb 2019 10:30:16 -0800 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <5C5C6929.30108@oracle.com> References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com> <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com> <5C40B289.7070408@oracle.com> <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com> <5C40CF23.4050608@oracle.com> <5C4207A4.1040203@oracle.com> <5C5C6929.30108@oracle.com> Message-ID: Looks good to me. -- Jon On 2/7/19 9:21 AM, Jan Lahoda wrote: > Hello, > > I've regenerated the patch using JDK 12b30, and also using the patch > from: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012938.html > > > (which makes the historical record smaller). > > The updated patch is here: > http://cr.openjdk.java.net/~jlahoda/8216263/webrev.04/ > > How does that look? > > Thanks, > ??? Jan > > On 18.1.2019 18:06, Jan Lahoda wrote: >> Adding build-dev. >> >> Jan >> >> On 17.1.2019 19:53, Jan Lahoda wrote: >>> On 17.1.2019 17:58, Jonathan Gibbons wrote: >>>> Re: >>>> >>>> ?? 36 #?? The checkout must not have any local changes that could >>>> interfere with the new data. In particular, >>>> ?? 37 #?? there must be absolutely no changed, new or removed files >>>> under the ${JDK_CHECKOUT}/make/data/symbols >>>> ?? 38 #?? directory. >>>> >>>> That seems like a simple check that could be incorporated into the >>>> script itself. >>>> >>>> But, it also seems reasonable to separate enhancements like that from >>>> the specific issue here, to add historical data for 12. >>> >>> Ok. Sent as: >>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html >>> >>> >>> >>> >>> And limited this patch to the historical data only: >>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/ >>> >>> Thanks, >>> ??? Jan >>> >>>> >>>> -- Jon >>>> >>>> On 1/17/19 8:51 AM, Jan Lahoda wrote: >>>>> Hi Joe, >>>>> >>>>> On 17.1.2019 02:13, Joseph D. Darcy wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On 1/8/2019 2:13 AM, Jan Lahoda wrote: >>>>>>> Hi Joe, >>>>>>> >>>>>>> Thanks for the comments, some responses inline. Updated webrev: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/ >>>>>>> >>>>>>> On 7.1.2019 23:51, Joseph D. Darcy wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> To make --release 12 work, we need to add historical data for JDK >>>>>>>>> 12. >>>>>>>>> The current historical data is based on: >>>>>>>>> $ javac? -fullversion >>>>>>>>> javac full version "12-ea+26" >>>>>>>>> >>>>>>>>> We may need to update the data once JDK 12 is out to cover any >>>>>>>>> changes >>>>>>>>> to the APIs that might happen. >>>>>>>>> >>>>>>>>> The patch also adds a simple (shell) script to generate the >>>>>>>>> data, so >>>>>>>>> all that was needed to generate the data was: >>>>>>>>> $ cd make/data/symbols >>>>>>>>> $ sh generate-data >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >>>>>>>>> >>>>>>>>> How does this look? >>>>>>>> >>>>>>>> If the overhead is small enough and we don't mind a few updates to >>>>>>>> the >>>>>>>> JDK N+1 data, than perhaps the generation of this information >>>>>>>> could be >>>>>>>> included as part of the start of JDK N+1 activities. >>>>>>> >>>>>>> That would be perfect! >>>>>>> >>>>>>>> >>>>>>>> I suggest a more extensive description of how to >>>>>>>> make/data/symbols/generate-data. For example, this builds the data >>>>>>>> for >>>>>>>> the current release independent of whether or not the current >>>>>>>> release >>>>>>>> has already had its data generated, correct? >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>> >>>>>>>> Concretely, if JDK N+1 has already forked, what is the proper way >>>>>>>> to get >>>>>>>> data for JDK N? Likewise, how should a re-build of the data for >>>>>>>> JDK >>>>>>>> N be >>>>>>>> done? >>>>>>> >>>>>>> What exactly should be there? To the existing description: >>>>>>> # to generate (add) data for JDK N, do: >>>>>>> # cd make/data/symbols >>>>>>> # sh generate-data >>>>>>> >>>>>>> I've added (in .01): >>>>>>> # to regenerate the data for JDK N, run the above commands again >>>>>>> >>>>>>> What more should be there? >>>>>>> >>>>>> >>>>>> I'd appreciate somewhere to have a textual discussion of how >>>>>> make/data/symbols/symbols should be updated, the A = 10, B = 11, >>>>>> etc. >>>>>> convention, what else need to be done to generate the contents of >>>>>> this >>>>>> changeset. >>>>>> >>>>>> The is the contents of the build directory? >>>>>> >>>>>> In general, a description of how the data of JDK N should be >>>>>> added to >>>>>> JDK (N+1). >>>>> >>>>> I've added more textual description to the script, an updated webrev >>>>> is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/ >>>>> >>>>> Jan >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>>> From joe.darcy at oracle.com Thu Feb 7 19:04:31 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 7 Feb 2019 11:04:31 -0800 Subject: RFR: JDK-8218630: CreateSymbols includes class and module headers unnecessarily. In-Reply-To: <5C5C67B8.5050302@oracle.com> References: <5C5C67B8.5050302@oracle.com> Message-ID: <749c1759-8a84-995b-12f0-e81f369ddd02@oracle.com> Hi Jan, Is the revised historical data also available for review? Thanks, -Joe On 2/7/2019 9:15 AM, Jan Lahoda wrote: > Hi, > > Joe noted that the proposed historical data for JDK 12: > http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ > may contain unnecessary items, and it indeed is the case. > > The main problems appear to be: > -when the class headers are being compared, the nestMembers for the > current version may be null, and the nestMembers for the previous > version may be an empty list. So, currently, such headers won't match > and the header will be generated again to the historical record. > listMatch can be used to consider null and empty list to be the same > > -module header descriptions may refer to > RequiresDescription/ProvidesDescription, which are missing > hashCode/equals, which means that headers that have either requires or > provides won't match any of the existing headers. The fix is to add > hashCode and equals > > I generated the ct.sym for the original JDK 12 historical data from > http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ > > and the historical data generated by this patch, and the resulting > content appears to be equivalent. > > Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8218630/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218630 > > How does this look? > > Thanks, > ??? Jan From francogpellegrini at gmail.com Thu Feb 7 19:07:42 2019 From: francogpellegrini at gmail.com (=?UTF-8?Q?Franco_Gast=C3=B3n_Pellegrini?=) Date: Thu, 7 Feb 2019 16:07:42 -0300 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> Message-ID: I tried compiling JDK 12 for 32 bits, and I get similar errors: === Output from failing command(s) repeated here === * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: classFileParser.cpp c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): error C2220: warning treated as error - no 'object' file generated c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data ... (rest of output omitted) * All command lines available in /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. === End of repeated output === No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: See doc/building.html#troubleshooting for assistance. make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 El mi?., 6 de feb. de 2019 a la(s) 19:23, Franco Gast?n Pellegrini ( francogpellegrini at gmail.com) escribi?: > I just tried --disable-warnings-as-errors, and JDK 11 64bits as a > bootjdk, but I get a lots of errors, and it refuse to build, like this: > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): > error C2956: sized deallocation function 'operator delete(void*, size_t)' > would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): > error C2956: sized deallocation function 'operator delete(void*, size_t)' > would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): > error C2956: sized deallocation function 'operator delete(void*, size_t)' > would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): > error C2956: sized deallocation function 'operator delete(void*, size_t)' > would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): > error C2956: sized deallocation function 'operator delete(void*, size_t)' > would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): > error C2956: sized deallocation function 'operator delete(void*, size_t)' > would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): > error C2956: sized deallocation function 'operator delete(void*, size_t)' > would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): > error C2956: sized deallocation function 'operator delete(void*, size_t)' > would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > > > > El mi?., 6 de feb. de 2019 a la(s) 16:15, Erik Joelsson ( > erik.joelsson at oracle.com) escribi?: > >> If you are running into warnings treated as errors, please try >> configuring with --disable-warnings-as-errors. That is often needed on >> less tested platforms. >> >> Note that as long as you run the build on a 64 bit system, you can use a >> 64 bit bootjdk to build a 32 bit JDK. >> >> /Erik >> >> On 2019-02-06 11:07, Franco Gast?n Pellegrini wrote: >> > Can this be fixed before JDK 12? I will not able to compile java 12 >> 32bits >> > because I will not have java 11 32bits as a boot-jdk. >> > >> > El s?b., 24 de nov. de 2018 a la(s) 03:59, David Holmes ( >> > david.holmes at oracle.com) escribi?: >> > >> >> On 23/11/2018 7:10 pm, Magnus Ihse Bursie wrote: >> >>> On 2018-11-23 08:35, Franco Gast?n Pellegrini wrote: >> >>>> Using the same command as before, and then using >> >>>> make CONF=windows-x86-normal-client-fastdebug clean; >> >>>> make CONF=windows-x86-normal-client-fastdebug; >> >>>> >> >>>> I get warnings as error, and cannot compile. The output is (and I >> >>>> attached the logs): >> >>>> >> >>>> $ make CONF=windows-x86-normal-client-fastdebug; >> >>>> Building target 'default (exploded-image)' in configuration >> >>>> 'windows-x86-normal-client-fastdebug' >> >>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >> >>>> Compiling 2 files for BUILD_JVMTI_TOOLS >> >>>> Compiling 1 files for BUILD_JFR_TOOLS >> >>>> Compiling 12 properties into resource bundles for jdk.jdeps >> >>>> Compiling 7 properties into resource bundles for jdk.jshell >> >>>> Parsing 2 properties into enum-like class for jdk.compiler >> >>>> Compiling 19 properties into resource bundles for jdk.compiler >> >>>> Compiling 13 properties into resource bundles for jdk.javadoc >> >>>> Compiling 117 files for BUILD_java.compiler.interim >> >>>> Compiling 394 files for BUILD_jdk.compiler.interim >> >>>> Creating support/modules_libs/java.base/client/jvm.dll from 746 >> file(s) >> >>>> Creating hotspot/variant-client/libjvm/gtest/jvm.dll from 90 file(s) >> >>>> Creating hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1 >> >>>> file(s) >> >>>> Compiling 299 files for BUILD_jdk.javadoc.interim >> >>>> Compiling 162 files for BUILD_TOOLS_JDK >> >>>> Compiling 188 files for BUILD_jdk.rmic.interim >> >>>> Note: Some input files use or override a deprecated API. >> >>>> Note: Recompile with -Xlint:deprecation for details. >> >>>> Note: Some input files use unchecked or unsafe operations. >> >>>> Note: Recompile with -Xlint:unchecked for details. >> >>>> Compiling 2 files for COMPILE_DEPEND >> >>>> Note: Some input files use or override a deprecated API. >> >>>> Note: Recompile with -Xlint:deprecation for details. >> >>>> Compiling 2 files for BUILD_BREAKITERATOR_BASE >> >>>> Compiling 2 files for BUILD_BREAKITERATOR_LD >> >>>> SocketOptionRegistry.java.template >> >>>> Compiling 11 properties into resource bundles for java.base >> >>>> Compiling 6 properties into resource bundles for java.base >> >>>> Compiling 11 properties into resource bundles for java.logging >> >>>> Compiling 11 properties into resource bundles for jdk.jartool >> >>>> Compiling 11 properties into resource bundles for >> jdk.management.agent >> >>>> >> >> >> c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >> >> >> >>>> error C2220: warning treated as error - no 'object' file generated >> >>>> >> >> >> c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >> >> >> >>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss >> of >> >>>> data >> >>>> make[3]: *** [lib/CompileJvm.gmk:151: >> >>>> >> >> >> /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/hotspot/variant-client/libjvm/objs/classFileParser.obj] >> >> >> >>>> Error 1 >> >>> 32-bit Windows is not regularly built, and might become unbuildable >> from >> >>> time to time. I think you are running into >> >>> https://bugs.openjdk.java.net/browse/JDK-8214206, which has a patch >> out >> >>> for review. >> >> No, this isn't JDK-8214206 - that was caused by a change only in JDK >> 12. >> >> >> >> But the above must have been fixed at some point as 32-bit builds in >> >> mainline are being done fairly regularly. (We have ARM 32-bit in our >> >> tier 5 now). >> >> >> >> David >> >> >> >>> /Magnus >> >>> >> >>> >> >>>> make[3]: *** Waiting for unfinished jobs.... >> >>>> make[2]: *** [make/Main.gmk:257: hotspot-client-libs] Error 2 >> >>>> make[2]: *** Waiting for unfinished jobs.... >> >>>> Compiling 4 properties into resource bundles for jdk.jlink >> >>>> Compiling 3 properties into resource bundles for jdk.jdi >> >>>> Compiling 3 properties into resource bundles for jdk.jlink >> >>>> Compiling 1 properties into resource bundles for jdk.jlink >> >>>> >> >>>> ERROR: Build failed for target 'default (exploded-image)' in >> >>>> configuration 'windows-x86-normal-client-fastdebug' (exit code 2) >> >>>> >> >>>> === Output from failing command(s) repeated here === >> >>>> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: >> >>>> classFileParser.cpp >> >>>> >> >> >> c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >> >> >> >>>> error C2220: warning treated as error - no 'object' file generated >> >>>> >> >> >> c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >> >> >> >>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss >> of >> >>>> data >> >>>> ... (rest of output omitted) >> >>>> >> >>>> * All command lines available in >> >>>> >> >> >> /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/make-support/failure-logs. >> >> >> >>>> === End of repeated output === >> >>>> >> >>>> El jue., 22 de nov. de 2018 a la(s) 22:19, Franco Gast?n Pellegrini >> >>>> (francogpellegrini at gmail.com ) >> >>>> escribi?: >> >>>> >> >>>> yes, it was gcc, for some reason it get broken. I reinstall >> cygwin >> >>>> and reconfigure it, an now it works, thanks! >> >>>> >> >>>> El lun., 5 de nov. de 2018 a la(s) 07:00, Magnus Ihse Bursie >> >>>> (magnus.ihse.bursie at oracle.com >> >>>> ) escribi?: >> >>>> >> >>>> On 2018-11-04 06:16, Franco Gast?n Pellegrini wrote: >> >>>>> I used this command: >> >>>>> /bash ./configure --enable-debug --with-target-bits=32 >> >>>>> --with-toolchain-version=2017 --with-jvm-variants=client >> >>>>> >> >>>>> >> >> >> --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/";/ >> >> >> >>>>> I tried Visual studio 2015 and 2017 >> (with-toolchain-version). >> >>>>> I attached config.log as you asked. >> >>>>> Thanks. >> >>>>> >> >>>>> El s?b., 3 de nov. de 2018 a la(s) 04:43, Magnus Ihse >> Bursie >> >>>>> (magnus.ihse.bursie at oracle.com >> >>>>> ) escribi?: >> >>>>> >> >>>>> Have you tried running >> >>>>> >> >>>>> >> >> >> /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl >> >> >> >>>>> >> >>>>> from the same prompt you ran configure to see what >> >>>>> happens? It seems to >> >>>>> have located a compiler but fails to run it. >> >>>>> >> >>>> Let me re-iterate this question: Have you tried running >> >>>> >> >>>> >> >> >> /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl >> >> >> >>>> from the same prompt you ran configure to see what happens? >> >>>> >> >>>> Here is the relevant part of the config.log, it basically >> says >> >>>> it cannot compile a simple C program. You can try recreating >> >>>> conftest.c as shown in the log below, or try just any other >> >>>> simple C program. >> >>>> >> >>>> configure:35681: checking whether the C compiler works >> >>>> configure:35703: >> >>>> >> >>>> >> >> >> /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl >> >> >> >>>> conftest.c >&5 >> >>>> Microsoft (R) C/C++ Optimizing Compiler Version >> 19.15.26732.1 >> >>>> for x86 >> >>>> Copyright (C) Microsoft Corporation. All rights reserved. >> >>>> >> >>>> conftest.c >> >>>> Microsoft (R) Incremental Linker Version 14.15.26732.1 >> >>>> Copyright (C) Microsoft Corporation. All rights reserved. >> >>>> >> >>>> /out:conftest.exe >> >>>> conftest.obj >> >>>> LINK : fatal error LNK1104: cannot open file 'conftest.exe' >> >>>> configure:35707: $? = 2 >> >>>> configure:35745: result: no >> >>>> configure: failed program was: >> >>>> | /* confdefs.h */ >> >>>> | #define PACKAGE_NAME "OpenJDK" >> >>>> | #define PACKAGE_TARNAME "openjdk" >> >>>> | #define PACKAGE_VERSION "openjdk" >> >>>> | #define PACKAGE_STRING "OpenJDK openjdk" >> >>>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" >> >>>> >> >>>> | #define PACKAGE_URL "http://openjdk.java.net" >> >>>> >> >>>> | /* end confdefs.h. */ >> >>>> | >> >>>> | int >> >>>> | main () >> >>>> | { >> >>>> | >> >>>> | ; >> >>>> | return 0; >> >>>> | } >> >>>> configure:35750: error: in `/home/Franco/Java/jdk11': >> >>>> configure:35752: error: C compiler cannot create executables >> >>>> >> >>>> /Magnus >> >>>> >> >>>>> There is also a second log file, config.log, generated >> by >> >>>>> autoconf. It >> >>>>> will hopefully contain output from the failed run of >> CL, >> >>>>> and the >> >>>>> complete command line it used when it concluded that >> the >> >>>>> C compiler >> >>>>> cannot create executables. >> >>>>> >> >>>>> /Magnus >> >>>>> >> >>>>> On 2018-11-03 02:50, Franco Gast?n Pellegrini wrote: >> >>>>> > Hello, >> >>>>> > When I try to comp?le OpenJDK 11, I get an error. I >> >>>>> tried using visual >> >>>>> > studio 2015 and 2017 with the same error. *Note that >> >>>>> compiling OpenJDK 9 >> >>>>> > and 10 work just fine.* >> >>>>> > >> >>>>> > I attached the log, but the error is: >> >>>>> > >> >>>>> > >> >>>>> >> >>>>> >> ********************************************************************** >> >>>>> > ** Visual Studio 2017 Developer Command Prompt >> v15.8.9 >> >>>>> > ** Copyright (c) 2017 Microsoft Corporation >> >>>>> > >> >>>>> >> >>>>> >> ********************************************************************** >> >>>>> > [vcvarsall.bat] Environment initialized for: 'x86' >> >>>>> > configure: Setting extracted environment variables >> >>>>> > checking for Visual Studio variables... ok >> >>>>> > configure: Rewriting ipath to >> >>>>> > >> >>>>> >> >>>>> >> >> >> "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/include" >> >> >> >>>>> > configure: Rewriting ipath to >> >>>>> > >> >>>>> >> >>>>> "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/include/um" >> >>>>> > configure: Rewriting ipath to >> >>>>> > >> >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/ucrt" >> >>>>> > configure: Rewriting ipath to >> >>>>> > >> >>>>> >> >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/shared" >> >>>>> > configure: Rewriting ipath to >> >>>>> > >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/um" >> >>>>> > configure: Rewriting ipath to >> >>>>> > >> >>>>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/winrt" >> >>>>> > configure: Rewriting ipath to >> >>>>> > >> >>>>> >> >>>>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/cppwinrt" >> >>>>> > configure: Rewriting libpath to >> >>>>> > >> >>>>> >> >>>>> >> >> >> "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/lib/x86" >> >> >> >>>>> > configure: Rewriting libpath to >> >>>>> > >> >>>>> >> >>>>> "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/lib/um/x86" >> >>>>> > configure: Rewriting libpath to >> >>>>> > >> >> "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/ucrt/x86" >> >>>>> > configure: Rewriting libpath to >> >>>>> > >> "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/um/x86" >> >>>>> > checking for cl... >> >>>>> > >> >>>>> >> >>>>> >> >> >> /cygdrive/c/PROGRA~1/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/14.15.26726/bin/HostX86/x86/cl >> >> >> >>>>> > configure: Rewriting CC to >> >>>>> > >> >>>>> >> >>>>> >> >> >> "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl" >> >> >> >>>>> > checking resolved symbolic links for CC... no symlink >> >>>>> > configure: Using microsoft C compiler version >> >>>>> 19.15.26732.1 [Microsoft (R) >> >>>>> > C/C++ Optimizing Compiler Version 19.15.26732.1 for >> x86] >> >>>>> > checking whether the C compiler works... no >> >>>>> > configure: error: in `/home/Franco/Java/jdk11': >> >>>>> > configure: error: C compiler cannot create >> executables >> >>>>> > See `config.log' for more details >> >>>>> > configure exiting with result code 77 >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- Franco Gast?n Pellegrini >> >>>> >> >>>> >> >>>> -- Franco Gast?n Pellegrini >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Franco Gast?n Pellegrini >> > >> > > > -- > Franco Gast?n Pellegrini > -- Franco Gast?n Pellegrini From joe.darcy at oracle.com Thu Feb 7 19:08:15 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 7 Feb 2019 11:08:15 -0800 Subject: RFR: JDK-8218630: CreateSymbols includes class and module headers unnecessarily. In-Reply-To: <749c1759-8a84-995b-12f0-e81f369ddd02@oracle.com> References: <5C5C67B8.5050302@oracle.com> <749c1759-8a84-995b-12f0-e81f369ddd02@oracle.com> Message-ID: <27d215e2-d5b4-ea53-bf9c-135fa6caaa98@oracle.com> PS I see that data is already out for review on a different thread: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012939.html https://mail.openjdk.java.net/pipermail/build-dev/2019-February/024936.html Thanks, -Joe On 2/7/2019 11:04 AM, Joe Darcy wrote: > Hi Jan, > > Is the revised historical data also available for review? > > Thanks, > > -Joe > > On 2/7/2019 9:15 AM, Jan Lahoda wrote: >> Hi, >> >> Joe noted that the proposed historical data for JDK 12: >> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >> may contain unnecessary items, and it indeed is the case. >> >> The main problems appear to be: >> -when the class headers are being compared, the nestMembers for the >> current version may be null, and the nestMembers for the previous >> version may be an empty list. So, currently, such headers won't match >> and the header will be generated again to the historical record. >> listMatch can be used to consider null and empty list to be the same >> >> -module header descriptions may refer to >> RequiresDescription/ProvidesDescription, which are missing >> hashCode/equals, which means that headers that have either requires >> or provides won't match any of the existing headers. The fix is to >> add hashCode and equals >> >> I generated the ct.sym for the original JDK 12 historical data from >> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >> >> and the historical data generated by this patch, and the resulting >> content appears to be equivalent. >> >> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8218630/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218630 >> >> How does this look? >> >> Thanks, >> ??? Jan From sgehwolf at redhat.com Thu Feb 7 19:09:24 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 Feb 2019 20:09:24 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> Message-ID: Hi Erik, On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: > Hello Severin, > > There is a macro for automatically finding all source dirs for a module. > So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using > that macro, like this: > > JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix > /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) > > The above could/should even be inlined. I've considered this. It seems, though, that FindModuleSrcDirs comes from make/common/Modules.gmk which isn't included in make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused problems with multiple includes of Modules.gmk (JDK-8213736) I was reluctant to include it here too. Without the new include the above won't work. The approach I've taken here seems to be the lesser evil. Thoughts? Thanks, Severin > Otherwise build changes look ok. > > /Erik > > On 2019-02-07 09:09, Severin Gehwolf wrote: > > Hi, > > > > Could I please get reviews for this enhancement? It adds a debug > > symbols stripping plug-in to jlink for Linux and Unix platforms. It's > > the first platform specific jlink plugin and the approach taken for > > keeping it contained is to use a plugin specific ResourceBundle. > > Discussion for this happened in [1]. > > > > The test uses a native library which should never get debug symbols > > stripped during the test library build. As such, tiny modifications > > were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev > > being on the list for this RFR. The test currently only runs on Linux > > and requires objcopy to be available. Otherwise the test is being > > skipped. > > > > Example usage of this plugin is described in the bug. > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > > > Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on Linux > > x86_64 (with good and broken objcopy) and the newly added test. It's > > currently running through jdk/submit too. > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html > > From joe.darcy at oracle.com Thu Feb 7 19:17:54 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 7 Feb 2019 11:17:54 -0800 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <5C5C6929.30108@oracle.com> References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com> <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com> <5C40B289.7070408@oracle.com> <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com> <5C40CF23.4050608@oracle.com> <5C4207A4.1040203@oracle.com> <5C5C6929.30108@oracle.com> Message-ID: <364fcd61-9e64-79c2-df7d-8bdfc6fa9f06@oracle.com> Hi Jan, Thanks for looking into this. The generated information is much smaller as you note, 1087 inserted lines vs 16328 inserted lines before. From looking over data for several modules, the revised changes look plausible in terms of corresponding to known work in those areas. Looks good! Cheers, -Joe On 2/7/2019 9:21 AM, Jan Lahoda wrote: > Hello, > > I've regenerated the patch using JDK 12b30, and also using the patch > from: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012938.html > > > (which makes the historical record smaller). > > The updated patch is here: > http://cr.openjdk.java.net/~jlahoda/8216263/webrev.04/ > > How does that look? > > Thanks, > ??? Jan > > On 18.1.2019 18:06, Jan Lahoda wrote: >> Adding build-dev. >> >> Jan >> >> On 17.1.2019 19:53, Jan Lahoda wrote: >>> On 17.1.2019 17:58, Jonathan Gibbons wrote: >>>> Re: >>>> >>>> ?? 36 #?? The checkout must not have any local changes that could >>>> interfere with the new data. In particular, >>>> ?? 37 #?? there must be absolutely no changed, new or removed files >>>> under the ${JDK_CHECKOUT}/make/data/symbols >>>> ?? 38 #?? directory. >>>> >>>> That seems like a simple check that could be incorporated into the >>>> script itself. >>>> >>>> But, it also seems reasonable to separate enhancements like that from >>>> the specific issue here, to add historical data for 12. >>> >>> Ok. Sent as: >>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html >>> >>> >>> >>> >>> And limited this patch to the historical data only: >>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/ >>> >>> Thanks, >>> ??? Jan >>> >>>> >>>> -- Jon >>>> >>>> On 1/17/19 8:51 AM, Jan Lahoda wrote: >>>>> Hi Joe, >>>>> >>>>> On 17.1.2019 02:13, Joseph D. Darcy wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On 1/8/2019 2:13 AM, Jan Lahoda wrote: >>>>>>> Hi Joe, >>>>>>> >>>>>>> Thanks for the comments, some responses inline. Updated webrev: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/ >>>>>>> >>>>>>> On 7.1.2019 23:51, Joseph D. Darcy wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> To make --release 12 work, we need to add historical data for JDK >>>>>>>>> 12. >>>>>>>>> The current historical data is based on: >>>>>>>>> $ javac? -fullversion >>>>>>>>> javac full version "12-ea+26" >>>>>>>>> >>>>>>>>> We may need to update the data once JDK 12 is out to cover any >>>>>>>>> changes >>>>>>>>> to the APIs that might happen. >>>>>>>>> >>>>>>>>> The patch also adds a simple (shell) script to generate the >>>>>>>>> data, so >>>>>>>>> all that was needed to generate the data was: >>>>>>>>> $ cd make/data/symbols >>>>>>>>> $ sh generate-data >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >>>>>>>>> >>>>>>>>> How does this look? >>>>>>>> >>>>>>>> If the overhead is small enough and we don't mind a few updates to >>>>>>>> the >>>>>>>> JDK N+1 data, than perhaps the generation of this information >>>>>>>> could be >>>>>>>> included as part of the start of JDK N+1 activities. >>>>>>> >>>>>>> That would be perfect! >>>>>>> >>>>>>>> >>>>>>>> I suggest a more extensive description of how to >>>>>>>> make/data/symbols/generate-data. For example, this builds the data >>>>>>>> for >>>>>>>> the current release independent of whether or not the current >>>>>>>> release >>>>>>>> has already had its data generated, correct? >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>> >>>>>>>> Concretely, if JDK N+1 has already forked, what is the proper way >>>>>>>> to get >>>>>>>> data for JDK N? Likewise, how should a re-build of the data for >>>>>>>> JDK >>>>>>>> N be >>>>>>>> done? >>>>>>> >>>>>>> What exactly should be there? To the existing description: >>>>>>> # to generate (add) data for JDK N, do: >>>>>>> # cd make/data/symbols >>>>>>> # sh generate-data >>>>>>> >>>>>>> I've added (in .01): >>>>>>> # to regenerate the data for JDK N, run the above commands again >>>>>>> >>>>>>> What more should be there? >>>>>>> >>>>>> >>>>>> I'd appreciate somewhere to have a textual discussion of how >>>>>> make/data/symbols/symbols should be updated, the A = 10, B = 11, >>>>>> etc. >>>>>> convention, what else need to be done to generate the contents of >>>>>> this >>>>>> changeset. >>>>>> >>>>>> The is the contents of the build directory? >>>>>> >>>>>> In general, a description of how the data of JDK N should be >>>>>> added to >>>>>> JDK (N+1). >>>>> >>>>> I've added more textual description to the script, an updated webrev >>>>> is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/ >>>>> >>>>> Jan >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>>> From mandy.chung at oracle.com Thu Feb 7 20:43:06 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Feb 2019 12:43:06 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: Hi Severin, Using the plugin specific ResourceBundle is good. Thanks for making the change. I see that Alan's comment [1] on the plugin options and I assume you will investigate the plugin options and bring back a proposal. Did I miss the discussion on these options? Option: --strip-native-debug-symbols=][:debuginfo-file-ext=][:include-debug-syms=true]> Examples: --strip-native-debug-symbols=defaults I suggest the above be simplified and drop the "=defaults". Simply: --strip-native-debug-symbols Examples: --strip-native-debug-symbols=options:objcopy-cmd=/usr/bin/objcopy:debuginfo-file-ext=dbg:include-debug-syms=true If include-debug-syms=true then it will run objcopy --only-keep-debug foo foo. to create debug symbols file objcopy --add-gnu-debuglink=foo.dbg foo So what about simplifying the options to: --strip-native-debug-symbols=keep-debug-symbols=dbg,objcopy-path=/usr/bin/objcopy We could also drop the word "symbols": --strip-native-debug=[keep-debug=,][objcopy-path=] By default, `--strip-native-debug` will strip native debug symbols and don't keep debug symbols. keep-debug= creates the debug symbols file. specifies the file extension. It would be nice to use the default `debuginfo` extension and simply accept `keep-debug` option. `objcopy-cmd` may be okay too. Others may have opinion. I think we should agree on the plugin options first before doing the code review. W.r.t. the test: > The test currently only runs on Linux > and requires objcopy to be available. Otherwise the test is being > skipped. We can create a fake objcopy utility for testing purpose such that the test will validate if the options are passed properly to the test utility. > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ I haven't reviewed the new files. Just notice that very long lines in the new files that you may want to fix the formatting that will help further side-by-side review. The --list-plugin output is very very long. The existing plugins didn't set a good example to keep the well formatted (I recorded that they were cleaned up at one point to keep 80 chars width). One other question: should this plugin be moved to linux/classes rather than unix/classes given that that's the platform it intends to support? Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014099.html From erik.joelsson at oracle.com Fri Feb 8 01:01:04 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Feb 2019 17:01:04 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> Message-ID: <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> On 2019-02-07 11:09, Severin Gehwolf wrote: > Hi Erik, > > On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: >> Hello Severin, >> >> There is a macro for automatically finding all source dirs for a module. >> So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using >> that macro, like this: >> >> JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix >> /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) >> >> The above could/should even be inlined. > I've considered this. It seems, though, that FindModuleSrcDirs comes > from make/common/Modules.gmk which isn't included in > make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused > problems with multiple includes of Modules.gmk (JDK-8213736) I was > reluctant to include it here too. Without the new include the above > won't work. > > The approach I've taken here seems to be the lesser evil. Thoughts? I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, which is part of where Modules.gmk gets bootstrapped. In any normal makefile (as in where stuff is just being built), the bootstrapping is done and including Modules.gmk is completely fine. Any -.gmk file certainly qualifies here. /Erik > Thanks, > Severin > >> Otherwise build changes look ok. >> >> /Erik >> >> On 2019-02-07 09:09, Severin Gehwolf wrote: >>> Hi, >>> >>> Could I please get reviews for this enhancement? It adds a debug >>> symbols stripping plug-in to jlink for Linux and Unix platforms. It's >>> the first platform specific jlink plugin and the approach taken for >>> keeping it contained is to use a plugin specific ResourceBundle. >>> Discussion for this happened in [1]. >>> >>> The test uses a native library which should never get debug symbols >>> stripped during the test library build. As such, tiny modifications >>> were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev >>> being on the list for this RFR. The test currently only runs on Linux >>> and requires objcopy to be available. Otherwise the test is being >>> skipped. >>> >>> Example usage of this plugin is described in the bug. >>> >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 >>> >>> Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on Linux >>> x86_64 (with good and broken objcopy) and the newly added test. It's >>> currently running through jdk/submit too. >>> >>> Thoughts? >>> >>> Thanks, >>> Severin >>> >>> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html >>> From Alan.Bateman at oracle.com Fri Feb 8 10:08:21 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Feb 2019 10:08:21 +0000 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: On 07/02/2019 17:09, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this enhancement? It adds a debug > symbols stripping plug-in to jlink for Linux and Unix platforms. It's > the first platform specific jlink plugin and the approach taken for > keeping it contained is to use a plugin specific ResourceBundle. > Discussion for this happened in [1]. > > The test uses a native library which should never get debug symbols > stripped during the test library build. As such, tiny modifications > were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev > being on the list for this RFR. The test currently only runs on Linux > and requires objcopy to be available. Otherwise the test is being > skipped. > > Example usage of this plugin is described in the bug. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > I agree with Mandy that the CLI options need examination. The proposed `--strip-native-debug-symbols` seems reasonable but it will be inconsistent with the existing `--strip-debug` option. Mandy - what you would think about renaming the existing option to something that makes it clear that it strips the debug attribute from class files? (we would of course need to do something to keep the existing option working). The need to specify the argument as "defaults" or "options" is a bit annoying. It might be time to replace hasArguments in the plugin interface to allow for optional arguments. The plugin interface is not exported/documented/supported so we have flexibility to change it. If we do this then it should mean the usages reduce down to: --strip-native-debug-symbols --strip-native-debug-symbols objcopy=:... I see the plugin has moved to src/jdk.jlink/unix in this iteration. It might be better to start out in src/jdk.jlink/linux - we can always move to the unix tree in the event that there is interest/support on other platforms. Mandy points out the issue with wrapping in the usage output. I agree that the`jlink --list-plugins` needs to be readable/tidy esp. in this case as there are many sub-options to read about. The implementation will need a bit of a tidy up too. The readFileBytes method can be replaced with Files.readAllBytes. The BAIS usage can be replaced with Files.write. Ignoring exceptions thrown in stripBinary will also need consideration. -Alan From mandy.chung at oracle.com Fri Feb 8 18:53:34 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 8 Feb 2019 10:53:34 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> On 2/8/19 2:08 AM, Alan Bateman wrote: > I agree with Mandy that the CLI options need examination. The proposed > `--strip-native-debug-symbols` seems reasonable but it will be > inconsistent with the existing `--strip-debug` option. Mandy - what you > would think about renaming the existing option to something that makes > it clear that it strips the debug attribute from class files? (we would > of course need to do something to keep the existing option working). Renaming it to make it clear is good. How about: --strip-debug-attribute --strip-native-debug-symbols --strip-debug will invoke both --strip-debug-attribute and --strip-native-debug-symbols, if supported. Typically we want to strip both. If only stripping debug attribute, then it can use --strip-debug-attribute. What do you think? > The need to specify the argument as "defaults" or "options" is a bit > annoying. It might be time to replace hasArguments in the plugin > interface to allow for optional arguments. Hmm... I thought it allows optional arguments. LegalNoticeFilePlugin accepts an optional argument. On the other hand, pluginToMaps will put an empty map if hasArguments return false. The plugin processing code (PluginsHelper) is quite complicated that I can't quite tell without spending time. In any case I think a plugin should support optional arguments. > The plugin interface is not > exported/documented/supported so we have flexibility to change it. If we > do this then it should mean the usages reduce down to: > > --strip-native-debug-symbols > --strip-native-debug-symbols objcopy=:... objcopy is fine. It would also be nice to allow `keep-debuginfo` taking an optional file extension. --strip-native-debug-symbols keep-debuginfo --strip-native-debug-symbols keep-debuginfo=dbg > > I see the plugin has moved to src/jdk.jlink/unix in this iteration. It > might be better to start out in src/jdk.jlink/linux - we can always move > to the unix tree in the event that there is interest/support on other > platforms. Agree. > Mandy points out the issue with wrapping in the usage output. I agree > that the`jlink --list-plugins` needs to be readable/tidy esp. in this > case as there are many sub-options to read about. I file JDK-8218685 for --list-plugins tidy up. Mandy From alexandre.iline at oracle.com Fri Feb 8 21:26:13 2019 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 8 Feb 2019 13:26:13 -0800 Subject: RFR: JDK-8218692 Switch to JCov build which supports byte code version 57 Message-ID: Hi. Can you take a look on quick change to enable JCov runs for jdk/jdk. The fix is to use a custom build of JCov: diff -r 6268e0cdb008 make/conf/jib-profiles.js --- a/make/conf/jib-profiles.js Wed Feb 06 16:25:58 2019 +0000 +++ b/make/conf/jib-profiles.js Fri Feb 08 05:19:34 2019 -0900 @@ -944,11 +944,17 @@ }, jcov: { - server: "jpg", - product: "jcov", - version: "3.0", - build_number: "b07", - file: "bundles/jcov-3_0.zip", + // Until an official build of JCov is available, use custom + // build to support classfile version 57. + // See CODETOOLS-7902358 for more info. + // server: "jpg", + // product: "jcov", + // version: "3.0", + // build_number: "b07", + // file: "bundles/jcov-3_0.zip", + organization: common.organization, + revision: "3.0-57-support+1.0", + ext: "zip", environment_name: "JCOV_HOME", }, Thank you. Shura From erik.joelsson at oracle.com Fri Feb 8 21:27:06 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Feb 2019 13:27:06 -0800 Subject: RFR: JDK-8218692 Switch to JCov build which supports byte code version 57 In-Reply-To: References: Message-ID: <5b5c469b-07ce-3209-8aff-fe3d907e58bd@oracle.com> Looks good. /Erik On 2019-02-08 13:26, Alexandre (Shura) Iline wrote: > Hi. > > Can you take a look on quick change to enable JCov runs for jdk/jdk. > > The fix is to use a custom build of JCov: > > diff -r 6268e0cdb008 make/conf/jib-profiles.js > --- a/make/conf/jib-profiles.js Wed Feb 06 16:25:58 2019 +0000 > +++ b/make/conf/jib-profiles.js Fri Feb 08 05:19:34 2019 -0900 > @@ -944,11 +944,17 @@ > }, > > jcov: { > - server: "jpg", > - product: "jcov", > - version: "3.0", > - build_number: "b07", > - file: "bundles/jcov-3_0.zip", > + // Until an official build of JCov is available, use custom > + // build to support classfile version 57. > + // See CODETOOLS-7902358 for more info. > + // server: "jpg", > + // product: "jcov", > + // version: "3.0", > + // build_number: "b07", > + // file: "bundles/jcov-3_0.zip", > + organization: common.organization, > + revision: "3.0-57-support+1.0", > + ext: "zip", > environment_name: "JCOV_HOME", > }, > > > > Thank you. > > Shura From Alan.Bateman at oracle.com Sun Feb 10 15:33:02 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 10 Feb 2019 15:33:02 +0000 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: <5d2f03ff-1d64-bb9a-3c23-90274cbe6dec@oracle.com> On 08/02/2019 18:53, Mandy Chung wrote: > > Renaming it to make it clear is good.? How about: > > --strip-debug-attribute > --strip-native-debug-symbols > > --strip-debug will invoke both --strip-debug-attribute and > --strip-native-debug-symbols, if supported. > > Typically we want to strip both.? If only stripping debug attribute, > then it can use --strip-debug-attribute. > > What do you think? This make sense and I'm just wondering if we need to extend this to debug symbols that are in external files. This suggests exploring whether it should imply --exclude-files too. > : > > Hmm... I thought it allows optional arguments. LegalNoticeFilePlugin > accepts an optional argument. I don't think --dedup-legal-notices works without an option. It would be generally useful to allow optional values. -Alan From david.holmes at oracle.com Mon Feb 11 02:03:55 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Feb 2019 12:03:55 +1000 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> Message-ID: On 8/02/2019 5:07 am, Franco Gast?n Pellegrini wrote: > I tried compiling JDK 12 for 32 bits, and I get similar errors: > > === Output from failing command(s) repeated here === > * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: > classFileParser.cpp > c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): > error C2220: warning treated as error - no 'object' file generated > c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): > warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data > ? ?... (rest of output omitted) This is an issue we ran into compiling 8u with VS2017: https://bugs.openjdk.java.net/browse/JDK-8205677 We probably never noticed in JDK 12 because we don't do 32-bits builds with VS2017. David ----- > * All command lines available in > /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. > === End of repeated output === > > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: See doc/building.html#troubleshooting for assistance. > > make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 > make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 > > > El mi?., 6 de feb. de 2019 a la(s) 19:23, Franco Gast?n Pellegrini > (francogpellegrini at gmail.com ) escribi?: > > I just tried --disable-warnings-as-errors, and JDK 11 64bits as a > bootjdk, but I get a lots of errors, and it refuse to build, like this: > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > warning C4267: '=': conversion from 'size_t' to 'u2', possible loss > of data > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): > error C2956: sized deallocation function 'operator delete(void*, > size_t)' would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration > of 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): > error C2956: sized deallocation function 'operator delete(void*, > size_t)' would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration > of 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): > error C2956: sized deallocation function 'operator delete(void*, > size_t)' would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration > of 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): > error C2956: sized deallocation function 'operator delete(void*, > size_t)' would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration > of 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): > error C2956: sized deallocation function 'operator delete(void*, > size_t)' would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration > of 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): > error C2956: sized deallocation function 'operator delete(void*, > size_t)' would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration > of 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): > error C2956: sized deallocation function 'operator delete(void*, > size_t)' would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration > of 'operator delete' > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): > error C2956: sized deallocation function 'operator delete(void*, > size_t)' would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration > of 'operator delete' > > > > El mi?., 6 de feb. de 2019 a la(s) 16:15, Erik Joelsson > (erik.joelsson at oracle.com ) escribi?: > > If you are running into warnings treated as errors, please try > configuring with --disable-warnings-as-errors. That is often > needed on > less tested platforms. > > Note that as long as you run the build on a 64 bit system, you > can use a > 64 bit bootjdk to build a 32 bit JDK. > > /Erik > > On 2019-02-06 11:07, Franco Gast?n Pellegrini wrote: > > Can this be fixed before JDK 12? I will not able to compile > java 12 32bits > > because I will not have java 11 32bits as a boot-jdk. > > > > El s?b., 24 de nov. de 2018 a la(s) 03:59, David Holmes ( > > david.holmes at oracle.com ) > escribi?: > > > >> On 23/11/2018 7:10 pm, Magnus Ihse Bursie wrote: > >>> On 2018-11-23 08:35, Franco Gast?n Pellegrini wrote: > >>>> Using the same command as before, and then using > >>>> make CONF=windows-x86-normal-client-fastdebug clean; > >>>> make CONF=windows-x86-normal-client-fastdebug; > >>>> > >>>> I get warnings as error, and cannot compile. The output is > (and I > >>>> attached the logs): > >>>> > >>>> $ make CONF=windows-x86-normal-client-fastdebug; > >>>> Building target 'default (exploded-image)' in configuration > >>>> 'windows-x86-normal-client-fastdebug' > >>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS > >>>> Compiling 2 files for BUILD_JVMTI_TOOLS > >>>> Compiling 1 files for BUILD_JFR_TOOLS > >>>> Compiling 12 properties into resource bundles for jdk.jdeps > >>>> Compiling 7 properties into resource bundles for jdk.jshell > >>>> Parsing 2 properties into enum-like class for jdk.compiler > >>>> Compiling 19 properties into resource bundles for jdk.compiler > >>>> Compiling 13 properties into resource bundles for jdk.javadoc > >>>> Compiling 117 files for BUILD_java.compiler.interim > >>>> Compiling 394 files for BUILD_jdk.compiler.interim > >>>> Creating support/modules_libs/java.base/client/jvm.dll > from 746 file(s) > >>>> Creating hotspot/variant-client/libjvm/gtest/jvm.dll from > 90 file(s) > >>>> Creating > hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1 > >>>> file(s) > >>>> Compiling 299 files for BUILD_jdk.javadoc.interim > >>>> Compiling 162 files for BUILD_TOOLS_JDK > >>>> Compiling 188 files for BUILD_jdk.rmic.interim > >>>> Note: Some input files use or override a deprecated API. > >>>> Note: Recompile with -Xlint:deprecation for details. > >>>> Note: Some input files use unchecked or unsafe operations. > >>>> Note: Recompile with -Xlint:unchecked for details. > >>>> Compiling 2 files for COMPILE_DEPEND > >>>> Note: Some input files use or override a deprecated API. > >>>> Note: Recompile with -Xlint:deprecation for details. > >>>> Compiling 2 files for BUILD_BREAKITERATOR_BASE > >>>> Compiling 2 files for BUILD_BREAKITERATOR_LD > >>>> SocketOptionRegistry.java.template > >>>> Compiling 11 properties into resource bundles for java.base > >>>> Compiling 6 properties into resource bundles for java.base > >>>> Compiling 11 properties into resource bundles for java.logging > >>>> Compiling 11 properties into resource bundles for jdk.jartool > >>>> Compiling 11 properties into resource bundles for > jdk.management.agent > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> error C2220: warning treated as error - no 'object' file > generated > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> warning C4267: '=': conversion from 'size_t' to 'u2', > possible loss of > >>>> data > >>>> make[3]: *** [lib/CompileJvm.gmk:151: > >>>> > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/hotspot/variant-client/libjvm/objs/classFileParser.obj] > >> > >>>> Error 1 > >>> 32-bit Windows is not regularly built, and might become > unbuildable from > >>> time to time. I think you are running into > >>> https://bugs.openjdk.java.net/browse/JDK-8214206, which has > a patch out > >>> for review. > >> No, this isn't JDK-8214206 - that was caused by a change > only in JDK 12. > >> > >> But the above must have been fixed at some point as 32-bit > builds in > >> mainline are being done fairly regularly. (We have ARM > 32-bit in our > >> tier 5 now). > >> > >> David > >> > >>> /Magnus > >>> > >>> > >>>> make[3]: *** Waiting for unfinished jobs.... > >>>> make[2]: *** [make/Main.gmk:257: hotspot-client-libs] Error 2 > >>>> make[2]: *** Waiting for unfinished jobs.... > >>>> Compiling 4 properties into resource bundles for jdk.jlink > >>>> Compiling 3 properties into resource bundles for jdk.jdi > >>>> Compiling 3 properties into resource bundles for jdk.jlink > >>>> Compiling 1 properties into resource bundles for jdk.jlink > >>>> > >>>> ERROR: Build failed for target 'default (exploded-image)' in > >>>> configuration 'windows-x86-normal-client-fastdebug' (exit > code 2) > >>>> > >>>> === Output from failing command(s) repeated here === > >>>> * For target > hotspot_variant-client_libjvm_objs_classFileParser.obj: > >>>> classFileParser.cpp > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> error C2220: warning treated as error - no 'object' file > generated > >>>> > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > >>>> warning C4267: '=': conversion from 'size_t' to 'u2', > possible loss of > >>>> data > >>>>? ? ?... (rest of output omitted) > >>>> > >>>> * All command lines available in > >>>> > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/make-support/failure-logs. > >> > >>>> === End of repeated output === > >>>> > >>>> El jue., 22 de nov. de 2018 a la(s) 22:19, Franco Gast?n > Pellegrini > >>>> (francogpellegrini at gmail.com > > >) > >>>> escribi?: > >>>> > >>>>? ? ? yes, it was gcc, for some reason it get broken. I > reinstall cygwin > >>>>? ? ? and reconfigure it, an now it works, thanks! > >>>> > >>>>? ? ? El lun., 5 de nov. de 2018 a la(s) 07:00, Magnus Ihse > Bursie > >>>>? ? ? (magnus.ihse.bursie at oracle.com > > >>>>? ? ? >) escribi?: > >>>> > >>>>? ? ? ? ? On 2018-11-04 06:16, Franco Gast?n Pellegrini wrote: > >>>>>? ? ? ? ? I used this command: > >>>>>? ? ? ? ? /bash ./configure --enable-debug > --with-target-bits=32 > >>>>>? ? ? ? ? --with-toolchain-version=2017 > --with-jvm-variants=client > >>>>> > >>>>> > >> > --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/";/ > >> > >>>>>? ? ? ? ? I tried Visual studio 2015 and 2017 > (with-toolchain-version). > >>>>>? ? ? ? ? I attached config.log as you asked. > >>>>>? ? ? ? ? Thanks. > >>>>> > >>>>>? ? ? ? ? El s?b., 3 de nov. de 2018 a la(s) 04:43, Magnus > Ihse Bursie > >>>>>? ? ? ? ? (magnus.ihse.bursie at oracle.com > > >>>>>? ? ? ? ? >) escribi?: > >>>>> > >>>>>? ? ? ? ? ? ? Have you tried running > >>>>> > >>>>> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > >> > >>>>> > >>>>>? ? ? ? ? ? ? from the same prompt you ran configure to > see what > >>>>>? ? ? ? ? ? ? happens? It seems to > >>>>>? ? ? ? ? ? ? have located a compiler but fails to run it. > >>>>> > >>>>? ? ? ? ? Let me re-iterate this question: Have you tried > running > >>>> > >>>> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > >> > >>>>? ? ? ? ? from the same prompt you ran configure to see > what happens? > >>>> > >>>>? ? ? ? ? Here is the relevant part of the config.log, it > basically says > >>>>? ? ? ? ? it cannot compile a simple C program. You can try > recreating > >>>>? ? ? ? ? conftest.c as shown in the log below, or try just > any other > >>>>? ? ? ? ? simple C program. > >>>> > >>>>? ? ? ? ? configure:35681: checking whether the C compiler > works > >>>>? ? ? ? ? configure:35703: > >>>> > >>>> > >> > /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl > >> > >>>>? ? ? ? ? conftest.c? >&5 > >>>>? ? ? ? ? Microsoft (R) C/C++ Optimizing Compiler Version > 19.15.26732.1 > >>>>? ? ? ? ? for x86 > >>>>? ? ? ? ? Copyright (C) Microsoft Corporation.? All rights > reserved. > >>>> > >>>>? ? ? ? ? conftest.c > >>>>? ? ? ? ? Microsoft (R) Incremental Linker Version > 14.15.26732.1 > >>>>? ? ? ? ? Copyright (C) Microsoft Corporation.? All rights > reserved. > >>>> > >>>>? ? ? ? ? /out:conftest.exe > >>>>? ? ? ? ? conftest.obj > >>>>? ? ? ? ? LINK : fatal error LNK1104: cannot open file > 'conftest.exe' > >>>>? ? ? ? ? configure:35707: $? = 2 > >>>>? ? ? ? ? configure:35745: result: no > >>>>? ? ? ? ? configure: failed program was: > >>>>? ? ? ? ? | /* confdefs.h */ > >>>>? ? ? ? ? | #define PACKAGE_NAME "OpenJDK" > >>>>? ? ? ? ? | #define PACKAGE_TARNAME "openjdk" > >>>>? ? ? ? ? | #define PACKAGE_VERSION "openjdk" > >>>>? ? ? ? ? | #define PACKAGE_STRING "OpenJDK openjdk" > >>>>? ? ? ? ? | #define PACKAGE_BUGREPORT > "build-dev at openjdk.java.net " > >>>>? ? ? ? ? > > >>>>? ? ? ? ? | #define PACKAGE_URL "http://openjdk.java.net" > >>>>? ? ? ? ? > >>>>? ? ? ? ? | /* end confdefs.h.? */ > >>>>? ? ? ? ? | > >>>>? ? ? ? ? | int > >>>>? ? ? ? ? | main () > >>>>? ? ? ? ? | { > >>>>? ? ? ? ? | > >>>>? ? ? ? ? |? ?; > >>>>? ? ? ? ? |? ?return 0; > >>>>? ? ? ? ? | } > >>>>? ? ? ? ? configure:35750: error: in `/home/Franco/Java/jdk11': > >>>>? ? ? ? ? configure:35752: error: C compiler cannot create > executables > >>>> > >>>>? ? ? ? ? /Magnus > >>>> > >>>>>? ? ? ? ? ? ? There is also a second log file, config.log, > generated by > >>>>>? ? ? ? ? ? ? autoconf. It > >>>>>? ? ? ? ? ? ? will hopefully contain output from the > failed run of CL, > >>>>>? ? ? ? ? ? ? and the > >>>>>? ? ? ? ? ? ? complete command line it used when it > concluded that the > >>>>>? ? ? ? ? ? ? C compiler > >>>>>? ? ? ? ? ? ? cannot create executables. > >>>>> > >>>>>? ? ? ? ? ? ? /Magnus > >>>>> > >>>>>? ? ? ? ? ? ? On 2018-11-03 02:50, Franco Gast?n > Pellegrini wrote: > >>>>>? ? ? ? ? ? ? > Hello, > >>>>>? ? ? ? ? ? ? > When I try to comp?le OpenJDK 11, I get an > error. I > >>>>>? ? ? ? ? ? ? tried using visual > >>>>>? ? ? ? ? ? ? > studio 2015 and 2017 with the same error. > *Note that > >>>>>? ? ? ? ? ? ? compiling OpenJDK 9 > >>>>>? ? ? ? ? ? ? > and 10 work just fine.* > >>>>>? ? ? ? ? ? ? > > >>>>>? ? ? ? ? ? ? > I attached the log, but the error is: > >>>>>? ? ? ? ? ? ? > > >>>>>? ? ? ? ? ? ? > > >>>>> > >>>>> > ********************************************************************** > >>>>>? ? ? ? ? ? ? > ** Visual Studio 2017 Developer Command > Prompt v15.8.9 > >>>>>? ? ? ? ? ? ? > ** Copyright (c) 2017 Microsoft Corporation > >>>>>? ? ? ? ? ? ? > > >>>>> > >>>>> > ********************************************************************** > >>>>>? ? ? ? ? ? ? > [vcvarsall.bat] Environment initialized > for: 'x86' > >>>>>? ? ? ? ? ? ? > configure: Setting extracted environment > variables > >>>>>? ? ? ? ? ? ? > checking for Visual Studio variables... ok > >>>>>? ? ? ? ? ? ? > configure: Rewriting ipath to > >>>>>? ? ? ? ? ? ? > > >>>>> > >>>>> > >> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/include" > >> > >>>>>? ? ? ? ? ? ? > configure: Rewriting ipath to > >>>>>? ? ? ? ? ? ? > > >>>>> > >>>>> > "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/include/um" > >>>>>? ? ? ? ? ? ? > configure: Rewriting ipath to > >>>>>? ? ? ? ? ? ? > > >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/ucrt" > >>>>>? ? ? ? ? ? ? > configure: Rewriting ipath to > >>>>>? ? ? ? ? ? ? > > >>>>> > >> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/shared" > >>>>>? ? ? ? ? ? ? > configure: Rewriting ipath to > >>>>>? ? ? ? ? ? ? > > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/um" > >>>>>? ? ? ? ? ? ? > configure: Rewriting ipath to > >>>>>? ? ? ? ? ? ? > > >>>>> "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/winrt" > >>>>>? ? ? ? ? ? ? > configure: Rewriting ipath to > >>>>>? ? ? ? ? ? ? > > >>>>> > >>>>> > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/cppwinrt" > >>>>>? ? ? ? ? ? ? > configure: Rewriting libpath to > >>>>>? ? ? ? ? ? ? > > >>>>> > >>>>> > >> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/lib/x86" > >> > >>>>>? ? ? ? ? ? ? > configure: Rewriting libpath to > >>>>>? ? ? ? ? ? ? > > >>>>> > >>>>> > "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/lib/um/x86" > >>>>>? ? ? ? ? ? ? > configure: Rewriting libpath to > >>>>>? ? ? ? ? ? ? > > >> "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/ucrt/x86" > >>>>>? ? ? ? ? ? ? > configure: Rewriting libpath to > >>>>>? ? ? ? ? ? ? > > "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/um/x86" > >>>>>? ? ? ? ? ? ? > checking for cl... > >>>>>? ? ? ? ? ? ? > > >>>>> > >>>>> > >> > /cygdrive/c/PROGRA~1/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/14.15.26726/bin/HostX86/x86/cl > >> > >>>>>? ? ? ? ? ? ? > configure: Rewriting CC to > >>>>>? ? ? ? ? ? ? > > >>>>> > >>>>> > >> > "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl" > >> > >>>>>? ? ? ? ? ? ? > checking resolved symbolic links for CC... > no symlink > >>>>>? ? ? ? ? ? ? > configure: Using microsoft C compiler version > >>>>>? ? ? ? ? ? ? 19.15.26732.1 [Microsoft (R) > >>>>>? ? ? ? ? ? ? > C/C++ Optimizing Compiler Version > 19.15.26732.1 for x86] > >>>>>? ? ? ? ? ? ? > checking whether the C compiler works... no > >>>>>? ? ? ? ? ? ? > configure: error: in > `/home/Franco/Java/jdk11': > >>>>>? ? ? ? ? ? ? > configure: error: C compiler cannot create > executables > >>>>>? ? ? ? ? ? ? > See `config.log' for more details > >>>>>? ? ? ? ? ? ? > configure exiting with result code 77 > >>>>>? ? ? ? ? ? ? > > >>>>>? ? ? ? ? ? ? > > >>>>>? ? ? ? ? ? ? > > >>>>> > >>>>> > >>>>> > >>>>>? ? ? ? ? --? ? ? ? ?Franco Gast?n Pellegrini > >>>> > >>>> > >>>>? ? ? --? ? ?Franco Gast?n Pellegrini > >>>> > >>>> > >>>> > >>>> -- > >>>> Franco Gast?n Pellegrini > > > > > > -- > Franco Gast?n Pellegrini > > > > -- > Franco Gast?n Pellegrini From alexey.ivanov at oracle.com Mon Feb 11 09:12:13 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 11 Feb 2019 09:12:13 +0000 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> Message-ID: Hi Franco, On 11/02/2019 02:03, David Holmes wrote: > On 8/02/2019 5:07 am, Franco Gast?n Pellegrini wrote: >> I tried compiling JDK 12 for 32 bits, and I get similar errors: >> >> === Output from failing command(s) repeated here === >> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: >> classFileParser.cpp >> c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): >> error C2220: warning treated as error - no 'object' file generated >> c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): >> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss >> of data >> ?? ?... (rest of output omitted) I used --disable-warnings-as-errors option to configure when I built JDK for 32 bit Windows last time. David pointed to JDK-8205677 which should be forwardported to 13 to fix the problem. Regards, Alexey > > This is an issue we ran into compiling 8u with VS2017: > > https://bugs.openjdk.java.net/browse/JDK-8205677 > > We probably never noticed in JDK 12 because we don't do 32-bits builds > with VS2017. > > David > ----- > >> * All command lines available in >> /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. >> === End of repeated output === >> >> No indication of failed target found. >> Hint: Try searching the build log for '] Error'. >> Hint: See doc/building.html#troubleshooting for assistance. >> >> make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 >> make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 >> >> >> El mi?., 6 de feb. de 2019 a la(s) 19:23, Franco Gast?n Pellegrini >> (francogpellegrini at gmail.com ) >> escribi?: >> >> ??? I just tried --disable-warnings-as-errors, and JDK 11 64bits as a >> ??? bootjdk, but I get a lots of errors, and it refuse to build, like >> this: >> >> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >> ??? warning C4267: '=': conversion from 'size_t' to 'u2', possible loss >> ??? of data >> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): >> ??? error C2956: sized deallocation function 'operator delete(void*, >> ??? size_t)' would be chosen as placement deallocation function. >> ??? predefined C++ types (compiler internal)(44): note: see declaration >> ??? of 'operator delete' >> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): >> ??? error C2956: sized deallocation function 'operator delete(void*, >> ??? size_t)' would be chosen as placement deallocation function. >> ??? predefined C++ types (compiler internal)(44): note: see declaration >> ??? of 'operator delete' >> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): >> ??? error C2956: sized deallocation function 'operator delete(void*, >> ??? size_t)' would be chosen as placement deallocation function. >> ??? predefined C++ types (compiler internal)(44): note: see declaration >> ??? of 'operator delete' >> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): >> ??? error C2956: sized deallocation function 'operator delete(void*, >> ??? size_t)' would be chosen as placement deallocation function. >> ??? predefined C++ types (compiler internal)(44): note: see declaration >> ??? of 'operator delete' >> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): >> ??? error C2956: sized deallocation function 'operator delete(void*, >> ??? size_t)' would be chosen as placement deallocation function. >> ??? predefined C++ types (compiler internal)(44): note: see declaration >> ??? of 'operator delete' >> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): >> ??? error C2956: sized deallocation function 'operator delete(void*, >> ??? size_t)' would be chosen as placement deallocation function. >> ??? predefined C++ types (compiler internal)(44): note: see declaration >> ??? of 'operator delete' >> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): >> ??? error C2956: sized deallocation function 'operator delete(void*, >> ??? size_t)' would be chosen as placement deallocation function. >> ??? predefined C++ types (compiler internal)(44): note: see declaration >> ??? of 'operator delete' >> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): >> ??? error C2956: sized deallocation function 'operator delete(void*, >> ??? size_t)' would be chosen as placement deallocation function. >> ??? predefined C++ types (compiler internal)(44): note: see declaration >> ??? of 'operator delete' >> >> From magnus.ihse.bursie at oracle.com Mon Feb 11 10:23:28 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 11 Feb 2019 11:23:28 +0100 Subject: RFR: JDK-8218736 Build warning in lib/JvmFlags.gmk: extraneous text after 'ifeq' directive Message-ID: <490461d6-00cc-bea6-82a8-e578d50006c4@oracle.com> Unfortunately I introduced a build error in JDK-8218431 (Improved platform checking). This resulted in the following error message: lib/JvmFlags.gmk:77: extraneous text after 'ifeq' directive This only happens for fastdebug builds, which is why I did not discover it during the testing of JDK-8218431. The fix is trivial. Bug: https://bugs.openjdk.java.net/browse/JDK-8218736 Patch inline: diff --git a/make/hotspot/lib/JvmFlags.gmk b/make/hotspot/lib/JvmFlags.gmk --- a/make/hotspot/lib/JvmFlags.gmk +++ b/make/hotspot/lib/JvmFlags.gmk @@ -74,7 +74,7 @@ ?? endif ?else ifeq ($(DEBUG_LEVEL), fastdebug) ?? JVM_CFLAGS_DEBUGLEVEL := -DASSERT -? ifeq ($call isTargetOs, windows aix), false) +? ifeq ($(call isTargetOs, windows aix), false) ???? # NOTE: Old build did not define CHECK_UNHANDLED_OOPS on Windows and AIX. ???? JVM_CFLAGS_DEBUGLEVEL += -DCHECK_UNHANDLED_OOPS ?? endif /Magnus From claes.redestad at oracle.com Mon Feb 11 10:31:11 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 11 Feb 2019 11:31:11 +0100 Subject: RFR: JDK-8218736 Build warning in lib/JvmFlags.gmk: extraneous text after 'ifeq' directive In-Reply-To: <490461d6-00cc-bea6-82a8-e578d50006c4@oracle.com> References: <490461d6-00cc-bea6-82a8-e578d50006c4@oracle.com> Message-ID: <2dd46c88-9865-8d4d-a8a8-38c6251ca822@oracle.com> Looks good, ship it! /Claes On 2019-02-11 11:23, Magnus Ihse Bursie wrote: > Unfortunately I introduced a build error in JDK-8218431 (Improved > platform checking). This resulted in the following error message: > lib/JvmFlags.gmk:77: extraneous text after 'ifeq' directive > > This only happens for fastdebug builds, which is why I did not discover > it during the testing of JDK-8218431. The fix is trivial. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218736 > Patch inline: > diff --git a/make/hotspot/lib/JvmFlags.gmk b/make/hotspot/lib/JvmFlags.gmk > --- a/make/hotspot/lib/JvmFlags.gmk > +++ b/make/hotspot/lib/JvmFlags.gmk > @@ -74,7 +74,7 @@ > ?? endif > ?else ifeq ($(DEBUG_LEVEL), fastdebug) > ?? JVM_CFLAGS_DEBUGLEVEL := -DASSERT > -? ifeq ($call isTargetOs, windows aix), false) > +? ifeq ($(call isTargetOs, windows aix), false) > ???? # NOTE: Old build did not define CHECK_UNHANDLED_OOPS on Windows > and AIX. > ???? JVM_CFLAGS_DEBUGLEVEL += -DCHECK_UNHANDLED_OOPS > ?? endif > > /Magnus From shade at redhat.com Mon Feb 11 10:40:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Feb 2019 11:40:36 +0100 Subject: RFR: JDK-8218736 Build warning in lib/JvmFlags.gmk: extraneous text after 'ifeq' directive In-Reply-To: <490461d6-00cc-bea6-82a8-e578d50006c4@oracle.com> References: <490461d6-00cc-bea6-82a8-e578d50006c4@oracle.com> Message-ID: <2121aab4-4500-5a0e-0ddb-1bb2996ead0d@redhat.com> On 2/11/19 11:23 AM, Magnus Ihse Bursie wrote: > Unfortunately I introduced a build error in JDK-8218431 (Improved platform checking). This resulted > in the following error message: > lib/JvmFlags.gmk:77: extraneous text after 'ifeq' directive > > This only happens for fastdebug builds, which is why I did not discover it during the testing of > JDK-8218431. The fix is trivial. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218736 > Patch inline: > diff --git a/make/hotspot/lib/JvmFlags.gmk b/make/hotspot/lib/JvmFlags.gmk > --- a/make/hotspot/lib/JvmFlags.gmk > +++ b/make/hotspot/lib/JvmFlags.gmk > @@ -74,7 +74,7 @@ > ?? endif > ?else ifeq ($(DEBUG_LEVEL), fastdebug) > ?? JVM_CFLAGS_DEBUGLEVEL := -DASSERT > -? ifeq ($call isTargetOs, windows aix), false) > +? ifeq ($(call isTargetOs, windows aix), false) > ???? # NOTE: Old build did not define CHECK_UNHANDLED_OOPS on Windows and AIX. > ???? JVM_CFLAGS_DEBUGLEVEL += -DCHECK_UNHANDLED_OOPS > ?? endif Looks good and trivial. -Aleksey From david.holmes at oracle.com Mon Feb 11 11:33:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Feb 2019 21:33:02 +1000 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> Message-ID: <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> Hi Alexey, On 11/02/2019 7:12 pm, Alexey Ivanov wrote: > Hi Franco, > > On 11/02/2019 02:03, David Holmes wrote: >> On 8/02/2019 5:07 am, Franco Gast?n Pellegrini wrote: >>> I tried compiling JDK 12 for 32 bits, and I get similar errors: >>> >>> === Output from failing command(s) repeated here === >>> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: >>> classFileParser.cpp >>> c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): >>> error C2220: warning treated as error - no 'object' file generated >>> c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): >>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss >>> of data >>> ?? ?... (rest of output omitted) > > I used --disable-warnings-as-errors option to configure when I built JDK > for 32 bit Windows last time. Note there are actual errors in Franco's log not just the warnings I commented on. I think we've already encountered the operate delete issue so it may be fixed in 13, but not 12. Need to track it down. Cheers, David > David pointed to JDK-8205677 which should be forwardported to 13 to fix > the problem. > > Regards, > Alexey > >> >> This is an issue we ran into compiling 8u with VS2017: >> >> https://bugs.openjdk.java.net/browse/JDK-8205677 >> >> We probably never noticed in JDK 12 because we don't do 32-bits builds >> with VS2017. >> >> David >> ----- >> >>> * All command lines available in >>> /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. >>> >>> === End of repeated output === >>> >>> No indication of failed target found. >>> Hint: Try searching the build log for '] Error'. >>> Hint: See doc/building.html#troubleshooting for assistance. >>> >>> make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 >>> make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 >>> >>> >>> El mi?., 6 de feb. de 2019 a la(s) 19:23, Franco Gast?n Pellegrini >>> (francogpellegrini at gmail.com ) >>> escribi?: >>> >>> ??? I just tried --disable-warnings-as-errors, and JDK 11 64bits as a >>> ??? bootjdk, but I get a lots of errors, and it refuse to build, like >>> this: >>> >>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >>> >>> ??? warning C4267: '=': conversion from 'size_t' to 'u2', possible loss >>> ??? of data >>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): >>> >>> ??? error C2956: sized deallocation function 'operator delete(void*, >>> ??? size_t)' would be chosen as placement deallocation function. >>> ??? predefined C++ types (compiler internal)(44): note: see declaration >>> ??? of 'operator delete' >>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): >>> >>> ??? error C2956: sized deallocation function 'operator delete(void*, >>> ??? size_t)' would be chosen as placement deallocation function. >>> ??? predefined C++ types (compiler internal)(44): note: see declaration >>> ??? of 'operator delete' >>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): >>> >>> ??? error C2956: sized deallocation function 'operator delete(void*, >>> ??? size_t)' would be chosen as placement deallocation function. >>> ??? predefined C++ types (compiler internal)(44): note: see declaration >>> ??? of 'operator delete' >>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): >>> >>> ??? error C2956: sized deallocation function 'operator delete(void*, >>> ??? size_t)' would be chosen as placement deallocation function. >>> ??? predefined C++ types (compiler internal)(44): note: see declaration >>> ??? of 'operator delete' >>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): >>> >>> ??? error C2956: sized deallocation function 'operator delete(void*, >>> ??? size_t)' would be chosen as placement deallocation function. >>> ??? predefined C++ types (compiler internal)(44): note: see declaration >>> ??? of 'operator delete' >>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): >>> >>> ??? error C2956: sized deallocation function 'operator delete(void*, >>> ??? size_t)' would be chosen as placement deallocation function. >>> ??? predefined C++ types (compiler internal)(44): note: see declaration >>> ??? of 'operator delete' >>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): >>> >>> ??? error C2956: sized deallocation function 'operator delete(void*, >>> ??? size_t)' would be chosen as placement deallocation function. >>> ??? predefined C++ types (compiler internal)(44): note: see declaration >>> ??? of 'operator delete' >>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): >>> >>> ??? error C2956: sized deallocation function 'operator delete(void*, >>> ??? size_t)' would be chosen as placement deallocation function. >>> ??? predefined C++ types (compiler internal)(44): note: see declaration >>> ??? of 'operator delete' >>> >>> > From magnus.ihse.bursie at oracle.com Mon Feb 11 11:42:55 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 11 Feb 2019 12:42:55 +0100 Subject: RFR: JDK-8218413 make reconfigure ignores configure-time AUTOCONF environment variable Message-ID: <4222644c-e3ba-0c37-361c-a1317f48c6c9@oracle.com> From the bug report: "Suppose PATH points to an out-of date autoconf. We can use the AUTOCONF environment variable with configure to override finding autoconf on PATH, but that variable is not remembered, so make reconfigure fails. # Recipe: rm -rf build AUTOCONF=/usr/bin/autoconf PATH="$MOLDY/bin:$PATH" bash configure ... # configure + make succeed make reconfigure # Fails with: Using autoconf at $MOLDY/bin/autoconf [autoconf (GNU Autoconf) 2.62] stdin:33: error: Autoconf version 2.69 or higher is required" Bug: https://bugs.openjdk.java.net/browse/JDK-8218413 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8218413-preserve-AUTOCONF-for-reconfigure/webrev.01 /Magnus From alexey.ivanov at oracle.com Mon Feb 11 14:03:47 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 11 Feb 2019 14:03:47 +0000 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> Message-ID: Hi David, On 11/02/2019 11:33, David Holmes wrote: > Hi Alexey, > > On 11/02/2019 7:12 pm, Alexey Ivanov wrote: >> Hi Franco, >> >> On 11/02/2019 02:03, David Holmes wrote: >>> On 8/02/2019 5:07 am, Franco Gast?n Pellegrini wrote: >>>> I tried compiling JDK 12 for 32 bits, and I get similar errors: >>>> >>>> === Output from failing command(s) repeated here === >>>> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: >>>> classFileParser.cpp >>>> c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): >>>> error C2220: warning treated as error - no 'object' file generated >>>> c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): >>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss >>>> of data >>>> ?? ?... (rest of output omitted) >> >> I used --disable-warnings-as-errors option to configure when I built >> JDK for 32 bit Windows last time. > > Note there are actual errors in Franco's log not just the warnings I > commented on. I think we've already encountered the operate delete > issue so it may be fixed in 13, but not 12. Need to track it down. I must have missed that point. The message above says ?error C2220: warning treated as error?, so I decided to let Franco know --disable-warnings-as-errors helped me. It's been a long while since I built jdk-dev on 32 bit Windows last time; many things could have changed there. Regards, Alexey > > Cheers, > David > >> David pointed to JDK-8205677 which should be forwardported to 13 to >> fix the problem. >> >> Regards, >> Alexey >> >>> >>> This is an issue we ran into compiling 8u with VS2017: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8205677 >>> >>> We probably never noticed in JDK 12 because we don't do 32-bits >>> builds with VS2017. >>> >>> David >>> ----- >>> >>>> * All command lines available in >>>> /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. >>>> >>>> === End of repeated output === >>>> >>>> No indication of failed target found. >>>> Hint: Try searching the build log for '] Error'. >>>> Hint: See doc/building.html#troubleshooting for assistance. >>>> >>>> make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 >>>> make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 >>>> >>>> >>>> El mi?., 6 de feb. de 2019 a la(s) 19:23, Franco Gast?n Pellegrini >>>> (francogpellegrini at gmail.com ) >>>> escribi?: >>>> >>>> ??? I just tried --disable-warnings-as-errors, and JDK 11 64bits as a >>>> ??? bootjdk, but I get a lots of errors, and it refuse to build, >>>> like this: >>>> >>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >>>> >>>> ??? warning C4267: '=': conversion from 'size_t' to 'u2', possible >>>> loss >>>> ??? of data >>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): >>>> >>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>> ??? size_t)' would be chosen as placement deallocation function. >>>> ??? predefined C++ types (compiler internal)(44): note: see >>>> declaration >>>> ??? of 'operator delete' >>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): >>>> >>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>> ??? size_t)' would be chosen as placement deallocation function. >>>> ??? predefined C++ types (compiler internal)(44): note: see >>>> declaration >>>> ??? of 'operator delete' >>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): >>>> >>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>> ??? size_t)' would be chosen as placement deallocation function. >>>> ??? predefined C++ types (compiler internal)(44): note: see >>>> declaration >>>> ??? of 'operator delete' >>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): >>>> >>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>> ??? size_t)' would be chosen as placement deallocation function. >>>> ??? predefined C++ types (compiler internal)(44): note: see >>>> declaration >>>> ??? of 'operator delete' >>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): >>>> >>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>> ??? size_t)' would be chosen as placement deallocation function. >>>> ??? predefined C++ types (compiler internal)(44): note: see >>>> declaration >>>> ??? of 'operator delete' >>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): >>>> >>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>> ??? size_t)' would be chosen as placement deallocation function. >>>> ??? predefined C++ types (compiler internal)(44): note: see >>>> declaration >>>> ??? of 'operator delete' >>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): >>>> >>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>> ??? size_t)' would be chosen as placement deallocation function. >>>> ??? predefined C++ types (compiler internal)(44): note: see >>>> declaration >>>> ??? of 'operator delete' >>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): >>>> >>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>> ??? size_t)' would be chosen as placement deallocation function. >>>> ??? predefined C++ types (compiler internal)(44): note: see >>>> declaration >>>> ??? of 'operator delete' >>>> >>>> >> From erik.joelsson at oracle.com Mon Feb 11 16:50:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Feb 2019 08:50:09 -0800 Subject: RFR: JDK-8218413 make reconfigure ignores configure-time AUTOCONF environment variable In-Reply-To: <4222644c-e3ba-0c37-361c-a1317f48c6c9@oracle.com> References: <4222644c-e3ba-0c37-361c-a1317f48c6c9@oracle.com> Message-ID: <3f67be5e-573e-95c4-749b-25912b6695c2@oracle.com> Looks good. /Erik On 2019-02-11 03:42, Magnus Ihse Bursie wrote: > From the bug report: > > "Suppose PATH points to an out-of date autoconf. > We can use the AUTOCONF environment variable with configure to > override finding autoconf on PATH, but that variable is not > remembered, so > make reconfigure fails. > > # Recipe: > rm -rf build > AUTOCONF=/usr/bin/autoconf PATH="$MOLDY/bin:$PATH" bash configure ... > # configure + make succeed > > make reconfigure > # Fails with: > Using autoconf at $MOLDY/bin/autoconf [autoconf (GNU Autoconf) 2.62] > stdin:33: error: Autoconf version 2.69 or higher is required" > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218413 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8218413-preserve-AUTOCONF-for-reconfigure/webrev.01 > > /Magnus From sgehwolf at redhat.com Mon Feb 11 18:03:28 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 Feb 2019 19:03:28 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> Message-ID: <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> Hi Erik, On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: > On 2019-02-07 11:09, Severin Gehwolf wrote: > > Hi Erik, > > > > On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: > > > Hello Severin, > > > > > > There is a macro for automatically finding all source dirs for a module. > > > So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using > > > that macro, like this: > > > > > > JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix > > > /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) > > > > > > The above could/should even be inlined. > > I've considered this. It seems, though, that FindModuleSrcDirs comes > > from make/common/Modules.gmk which isn't included in > > make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused > > problems with multiple includes of Modules.gmk (JDK-8213736) I was > > reluctant to include it here too. Without the new include the above > > won't work. > > > > The approach I've taken here seems to be the lesser evil. Thoughts? > > I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, > which is part of where Modules.gmk gets bootstrapped. In any normal > makefile (as in where stuff is just being built), the bootstrapping is > done and including Modules.gmk is completely fine. Any > -.gmk file certainly qualifies here. OK. Updated: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ Thanks, Severin > /Erik > > > Thanks, > > Severin > > > > > Otherwise build changes look ok. > > > > > > /Erik > > > > > > On 2019-02-07 09:09, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get reviews for this enhancement? It adds a > > > > debug > > > > symbols stripping plug-in to jlink for Linux and Unix > > > > platforms. It's > > > > the first platform specific jlink plugin and the approach taken > > > > for > > > > keeping it contained is to use a plugin specific > > > > ResourceBundle. > > > > Discussion for this happened in [1]. > > > > > > > > The test uses a native library which should never get debug > > > > symbols > > > > stripped during the test library build. As such, tiny > > > > modifications > > > > were needed to make/common/TestFilesCompilation.gmk. Hence, > > > > build-dev > > > > being on the list for this RFR. The test currently only runs on > > > > Linux > > > > and requires objcopy to be available. Otherwise the test is > > > > being > > > > skipped. > > > > > > > > Example usage of this plugin is described in the bug. > > > > > > > > webrev: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > > > > > > > Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on > > > > Linux > > > > x86_64 (with good and broken objcopy) and the newly added test. > > > > It's > > > > currently running through jdk/submit too. > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > > > > > [1] > > > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html > > > > From sgehwolf at redhat.com Mon Feb 11 18:10:49 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 Feb 2019 19:10:49 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: <3e804780fbf51164f1136c080a7091889b3b8343.camel@redhat.com> Hi Alan, Thanks for the review! On Fri, 2019-02-08 at 10:08 +0000, Alan Bateman wrote: > On 07/02/2019 17:09, Severin Gehwolf wrote: > > Hi, > > > > Could I please get reviews for this enhancement? It adds a debug > > symbols stripping plug-in to jlink for Linux and Unix platforms. It's > > the first platform specific jlink plugin and the approach taken for > > keeping it contained is to use a plugin specific ResourceBundle. > > Discussion for this happened in [1]. > > > > The test uses a native library which should never get debug symbols > > stripped during the test library build. As such, tiny modifications > > were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev > > being on the list for this RFR. The test currently only runs on Linux > > and requires objcopy to be available. Otherwise the test is being > > skipped. > > > > Example usage of this plugin is described in the bug. > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > > I agree with Mandy that the CLI options need examination. The proposed > `--strip-native-debug-symbols` seems reasonable but it will be > inconsistent with the existing `--strip-debug` option. Mandy - what you > would think about renaming the existing option to something that makes > it clear that it strips the debug attribute from class files? (we would > of course need to do something to keep the existing option working). > > The need to specify the argument as "defaults" or "options" is a bit > annoying. It might be time to replace hasArguments in the plugin > interface to allow for optional arguments. The plugin interface is not > exported/documented/supported so we have flexibility to change it. I've filed this bug for optional arguments: https://bugs.openjdk.java.net/browse/JDK-8218761 It's a separate issue, after all. > If we > do this then it should mean the usages reduce down to: > > --strip-native-debug-symbols > --strip-native-debug-symbols objcopy=:... > > I see the plugin has moved to src/jdk.jlink/unix in this iteration. It > might be better to start out in src/jdk.jlink/linux - we can always move > to the unix tree in the event that there is interest/support on other > platforms. > > Mandy points out the issue with wrapping in the usage output. I agree > that the`jlink --list-plugins` needs to be readable/tidy esp. in this > case as there are many sub-options to read about. I'll tackle those once there is some agreement as to what the option should be called and which arguments it should have for the initial implementation. I'll reply with a proposal in the other thread. > The implementation will need a bit of a tidy up too. The readFileBytes > method can be replaced with Files.readAllBytes. The BAIS usage can be > replaced with Files.write. Ignoring exceptions thrown in stripBinary > will also need consideration. Should be fixed in the latest webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ FWIW, I've refrained from using Files.readAllBytes in the initial webrev because of this note in the javadoc: """ Note that this method is intended for simple cases where it is convenient to read all bytes into a byte array. It is not intended for reading in large files. """ Cheers, Severin From martinrb at google.com Mon Feb 11 18:54:01 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 11 Feb 2019 10:54:01 -0800 Subject: RFR: JDK-8218413 make reconfigure ignores configure-time AUTOCONF environment variable In-Reply-To: <4222644c-e3ba-0c37-361c-a1317f48c6c9@oracle.com> References: <4222644c-e3ba-0c37-361c-a1317f48c6c9@oracle.com> Message-ID: Looks good to me. On Mon, Feb 11, 2019 at 3:42 AM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > From the bug report: > > "Suppose PATH points to an out-of date autoconf. > We can use the AUTOCONF environment variable with configure to override > finding autoconf on PATH, but that variable is not remembered, so > make reconfigure fails. > > # Recipe: > rm -rf build > AUTOCONF=/usr/bin/autoconf PATH="$MOLDY/bin:$PATH" bash configure ... > # configure + make succeed > > make reconfigure > # Fails with: > Using autoconf at $MOLDY/bin/autoconf [autoconf (GNU Autoconf) 2.62] > stdin:33: error: Autoconf version 2.69 or higher is required" > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218413 > WebRev: > > http://cr.openjdk.java.net/~ihse/JDK-8218413-preserve-AUTOCONF-for-reconfigure/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Mon Feb 11 19:12:24 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Feb 2019 11:12:24 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> Message-ID: <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> Hello Severin, I think you also need a $(wildcard ) around it, but I may be wrong. Did you try this version? Also, please do not indent so much. We have style guidelines [1], which recommend 4 spaces for line break indentation. /Erik [1] http://openjdk.java.net/groups/build/doc/code-conventions.html On 2019-02-11 10:03, Severin Gehwolf wrote: > Hi Erik, > > On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: >> On 2019-02-07 11:09, Severin Gehwolf wrote: >>> Hi Erik, >>> >>> On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: >>>> Hello Severin, >>>> >>>> There is a macro for automatically finding all source dirs for a module. >>>> So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using >>>> that macro, like this: >>>> >>>> JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix >>>> /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) >>>> >>>> The above could/should even be inlined. >>> I've considered this. It seems, though, that FindModuleSrcDirs comes >>> from make/common/Modules.gmk which isn't included in >>> make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused >>> problems with multiple includes of Modules.gmk (JDK-8213736) I was >>> reluctant to include it here too. Without the new include the above >>> won't work. >>> >>> The approach I've taken here seems to be the lesser evil. Thoughts? >> I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, >> which is part of where Modules.gmk gets bootstrapped. In any normal >> makefile (as in where stuff is just being built), the bootstrapping is >> done and including Modules.gmk is completely fine. Any >> -.gmk file certainly qualifies here. > OK. Updated: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ > > Thanks, > Severin > >> /Erik >> >>> Thanks, >>> Severin >>> >>>> Otherwise build changes look ok. >>>> >>>> /Erik >>>> >>>> On 2019-02-07 09:09, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Could I please get reviews for this enhancement? It adds a >>>>> debug >>>>> symbols stripping plug-in to jlink for Linux and Unix >>>>> platforms. It's >>>>> the first platform specific jlink plugin and the approach taken >>>>> for >>>>> keeping it contained is to use a plugin specific >>>>> ResourceBundle. >>>>> Discussion for this happened in [1]. >>>>> >>>>> The test uses a native library which should never get debug >>>>> symbols >>>>> stripped during the test library build. As such, tiny >>>>> modifications >>>>> were needed to make/common/TestFilesCompilation.gmk. Hence, >>>>> build-dev >>>>> being on the list for this RFR. The test currently only runs on >>>>> Linux >>>>> and requires objcopy to be available. Otherwise the test is >>>>> being >>>>> skipped. >>>>> >>>>> Example usage of this plugin is described in the bug. >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 >>>>> >>>>> Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on >>>>> Linux >>>>> x86_64 (with good and broken objcopy) and the newly added test. >>>>> It's >>>>> currently running through jdk/submit too. >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html >>>>> From david.holmes at oracle.com Mon Feb 11 22:26:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Feb 2019 08:26:13 +1000 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> Message-ID: <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> On 12/02/2019 12:03 am, Alexey Ivanov wrote: > Hi David, > > On 11/02/2019 11:33, David Holmes wrote: >> Hi Alexey, >> >> On 11/02/2019 7:12 pm, Alexey Ivanov wrote: >>> Hi Franco, >>> >>> On 11/02/2019 02:03, David Holmes wrote: >>>> On 8/02/2019 5:07 am, Franco Gast?n Pellegrini wrote: >>>>> I tried compiling JDK 12 for 32 bits, and I get similar errors: >>>>> >>>>> === Output from failing command(s) repeated here === >>>>> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: >>>>> classFileParser.cpp >>>>> c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): >>>>> error C2220: warning treated as error - no 'object' file generated >>>>> c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): >>>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss >>>>> of data >>>>> ?? ?... (rest of output omitted) >>> >>> I used --disable-warnings-as-errors option to configure when I built >>> JDK for 32 bit Windows last time. >> >> Note there are actual errors in Franco's log not just the warnings I >> commented on. I think we've already encountered the operate delete >> issue so it may be fixed in 13, but not 12. Need to track it down. > > I must have missed that point. > The message above says ?error C2220: warning treated as error?, so I > decided to let Franco know --disable-warnings-as-errors helped me. Yeah sorry - getting confused by the different things Franco tried. He tried a JDK11 build with --disable-warnings-as-errors but it still failed because of real errors: c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' Then he posted that he'd tried jdk12 as well with "similar errors" but only showed the error C2220: warning treated as error - no 'object' file generated warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data which means he was not running with --disable-warnings-as-errors David ----- > > It's been a long while since I built jdk-dev on 32 bit Windows last > time; many things could have changed there. > > Regards, > Alexey > >> >> Cheers, >> David >> >>> David pointed to JDK-8205677 which should be forwardported to 13 to >>> fix the problem. >>> >>> Regards, >>> Alexey >>> >>>> >>>> This is an issue we ran into compiling 8u with VS2017: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8205677 >>>> >>>> We probably never noticed in JDK 12 because we don't do 32-bits >>>> builds with VS2017. >>>> >>>> David >>>> ----- >>>> >>>>> * All command lines available in >>>>> /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. >>>>> >>>>> === End of repeated output === >>>>> >>>>> No indication of failed target found. >>>>> Hint: Try searching the build log for '] Error'. >>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>> >>>>> make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 >>>>> make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 >>>>> >>>>> >>>>> El mi?., 6 de feb. de 2019 a la(s) 19:23, Franco Gast?n Pellegrini >>>>> (francogpellegrini at gmail.com ) >>>>> escribi?: >>>>> >>>>> ??? I just tried --disable-warnings-as-errors, and JDK 11 64bits as a >>>>> ??? bootjdk, but I get a lots of errors, and it refuse to build, >>>>> like this: >>>>> >>>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): >>>>> >>>>> ??? warning C4267: '=': conversion from 'size_t' to 'u2', possible >>>>> loss >>>>> ??? of data >>>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): >>>>> >>>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>>> ??? size_t)' would be chosen as placement deallocation function. >>>>> ??? predefined C++ types (compiler internal)(44): note: see >>>>> declaration >>>>> ??? of 'operator delete' >>>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): >>>>> >>>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>>> ??? size_t)' would be chosen as placement deallocation function. >>>>> ??? predefined C++ types (compiler internal)(44): note: see >>>>> declaration >>>>> ??? of 'operator delete' >>>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): >>>>> >>>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>>> ??? size_t)' would be chosen as placement deallocation function. >>>>> ??? predefined C++ types (compiler internal)(44): note: see >>>>> declaration >>>>> ??? of 'operator delete' >>>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): >>>>> >>>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>>> ??? size_t)' would be chosen as placement deallocation function. >>>>> ??? predefined C++ types (compiler internal)(44): note: see >>>>> declaration >>>>> ??? of 'operator delete' >>>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): >>>>> >>>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>>> ??? size_t)' would be chosen as placement deallocation function. >>>>> ??? predefined C++ types (compiler internal)(44): note: see >>>>> declaration >>>>> ??? of 'operator delete' >>>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): >>>>> >>>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>>> ??? size_t)' would be chosen as placement deallocation function. >>>>> ??? predefined C++ types (compiler internal)(44): note: see >>>>> declaration >>>>> ??? of 'operator delete' >>>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): >>>>> >>>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>>> ??? size_t)' would be chosen as placement deallocation function. >>>>> ??? predefined C++ types (compiler internal)(44): note: see >>>>> declaration >>>>> ??? of 'operator delete' >>>>> c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): >>>>> >>>>> ??? error C2956: sized deallocation function 'operator delete(void*, >>>>> ??? size_t)' would be chosen as placement deallocation function. >>>>> ??? predefined C++ types (compiler internal)(44): note: see >>>>> declaration >>>>> ??? of 'operator delete' >>>>> >>>>> >>> > From francogpellegrini at gmail.com Mon Feb 11 22:28:58 2019 From: francogpellegrini at gmail.com (=?UTF-8?Q?Franco_Gast=C3=B3n_Pellegrini?=) Date: Mon, 11 Feb 2019 19:28:58 -0300 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> Message-ID: My mistake to not fully describe it but I tried jdk 11 and 12 using the disable warning as error on both, getting similar errors. (Both 32 bits) El lun., 11 de feb. de 2019 19:26, David Holmes escribi?: > On 12/02/2019 12:03 am, Alexey Ivanov wrote: > > Hi David, > > > > On 11/02/2019 11:33, David Holmes wrote: > >> Hi Alexey, > >> > >> On 11/02/2019 7:12 pm, Alexey Ivanov wrote: > >>> Hi Franco, > >>> > >>> On 11/02/2019 02:03, David Holmes wrote: > >>>> On 8/02/2019 5:07 am, Franco Gast?n Pellegrini wrote: > >>>>> I tried compiling JDK 12 for 32 bits, and I get similar errors: > >>>>> > >>>>> === Output from failing command(s) repeated here === > >>>>> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: > >>>>> classFileParser.cpp > >>>>> > c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): > > >>>>> error C2220: warning treated as error - no 'object' file generated > >>>>> > c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): > > >>>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss > >>>>> of data > >>>>> ... (rest of output omitted) > >>> > >>> I used --disable-warnings-as-errors option to configure when I built > >>> JDK for 32 bit Windows last time. > >> > >> Note there are actual errors in Franco's log not just the warnings I > >> commented on. I think we've already encountered the operate delete > >> issue so it may be fixed in 13, but not 12. Need to track it down. > > > > I must have missed that point. > > The message above says ?error C2220: warning treated as error?, so I > > decided to let Franco know --disable-warnings-as-errors helped me. > > Yeah sorry - getting confused by the different things Franco tried. He > tried a JDK11 build with --disable-warnings-as-errors but it still > failed because of real errors: > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): > > error C2956: sized deallocation function 'operator delete(void*, > size_t)' would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > > Then he posted that he'd tried jdk12 as well with "similar errors" but > only showed the > > error C2220: warning treated as error - no 'object' file generated > warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data > > which means he was not running with --disable-warnings-as-errors > > David > ----- > > > > > > It's been a long while since I built jdk-dev on 32 bit Windows last > > time; many things could have changed there. > > > > Regards, > > Alexey > > > >> > >> Cheers, > >> David > >> > >>> David pointed to JDK-8205677 which should be forwardported to 13 to > >>> fix the problem. > >>> > >>> Regards, > >>> Alexey > >>> > >>>> > >>>> This is an issue we ran into compiling 8u with VS2017: > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8205677 > >>>> > >>>> We probably never noticed in JDK 12 because we don't do 32-bits > >>>> builds with VS2017. > >>>> > >>>> David > >>>> ----- > >>>> > >>>>> * All command lines available in > >>>>> > /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. > > >>>>> > >>>>> === End of repeated output === > >>>>> > >>>>> No indication of failed target found. > >>>>> Hint: Try searching the build log for '] Error'. > >>>>> Hint: See doc/building.html#troubleshooting for assistance. > >>>>> > >>>>> make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 > >>>>> make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 > >>>>> > >>>>> > >>>>> El mi?., 6 de feb. de 2019 a la(s) 19:23, Franco Gast?n Pellegrini > >>>>> (francogpellegrini at gmail.com ) > >>>>> escribi?: > >>>>> > >>>>> I just tried --disable-warnings-as-errors, and JDK 11 64bits as a > >>>>> bootjdk, but I get a lots of errors, and it refuse to build, > >>>>> like this: > >>>>> > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > >>>>> > >>>>> warning C4267: '=': conversion from 'size_t' to 'u2', possible > >>>>> loss > >>>>> of data > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): > >>>>> > >>>>> error C2956: sized deallocation function 'operator delete(void*, > >>>>> size_t)' would be chosen as placement deallocation function. > >>>>> predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): > >>>>> > >>>>> error C2956: sized deallocation function 'operator delete(void*, > >>>>> size_t)' would be chosen as placement deallocation function. > >>>>> predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): > >>>>> > >>>>> error C2956: sized deallocation function 'operator delete(void*, > >>>>> size_t)' would be chosen as placement deallocation function. > >>>>> predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): > >>>>> > >>>>> error C2956: sized deallocation function 'operator delete(void*, > >>>>> size_t)' would be chosen as placement deallocation function. > >>>>> predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): > >>>>> > >>>>> error C2956: sized deallocation function 'operator delete(void*, > >>>>> size_t)' would be chosen as placement deallocation function. > >>>>> predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): > >>>>> > >>>>> error C2956: sized deallocation function 'operator delete(void*, > >>>>> size_t)' would be chosen as placement deallocation function. > >>>>> predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): > >>>>> > >>>>> error C2956: sized deallocation function 'operator delete(void*, > >>>>> size_t)' would be chosen as placement deallocation function. > >>>>> predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): > >>>>> > >>>>> error C2956: sized deallocation function 'operator delete(void*, > >>>>> size_t)' would be chosen as placement deallocation function. > >>>>> predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> of 'operator delete' > >>>>> > >>>>> > >>> > > > From david.holmes at oracle.com Mon Feb 11 22:53:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Feb 2019 08:53:05 +1000 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> Message-ID: <294f30aa-fef4-3c6c-302d-77a1bc7d1547@oracle.com> On 12/02/2019 8:28 am, Franco Gast?n Pellegrini wrote: > My mistake to not fully describe it but I tried jdk 11 and 12 using the > disable warning as error on both, getting similar errors. (Both 32 bits) The "operator delete" issue has already been encountered: https://bugs.openjdk.java.net/browse/JDK-8196880 But I can't see how that relates to share/code/codeBlob.cpp and only for 32-bit. That would be a question for hotspot-dev at openjdk.java.net David > El lun., 11 de feb. de 2019 19:26, David Holmes > escribi?: > > On 12/02/2019 12:03 am, Alexey Ivanov wrote: > > Hi David, > > > > On 11/02/2019 11:33, David Holmes wrote: > >> Hi Alexey, > >> > >> On 11/02/2019 7:12 pm, Alexey Ivanov wrote: > >>> Hi Franco, > >>> > >>> On 11/02/2019 02:03, David Holmes wrote: > >>>> On 8/02/2019 5:07 am, Franco Gast?n Pellegrini wrote: > >>>>> I tried compiling JDK 12 for 32 bits, and I get similar errors: > >>>>> > >>>>> === Output from failing command(s) repeated here === > >>>>> * For target > hotspot_variant-client_libjvm_objs_classFileParser.obj: > >>>>> classFileParser.cpp > >>>>> > c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): > > >>>>> error C2220: warning treated as error - no 'object' file > generated > >>>>> > c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): > > >>>>> warning C4267: '=': conversion from 'size_t' to 'u2', > possible loss > >>>>> of data > >>>>> ?? ?... (rest of output omitted) > >>> > >>> I used --disable-warnings-as-errors option to configure when I > built > >>> JDK for 32 bit Windows last time. > >> > >> Note there are actual errors in Franco's log not just the > warnings I > >> commented on. I think we've already encountered the operate delete > >> issue so it may be fixed in 13, but not 12. Need to track it down. > > > > I must have missed that point. > > The message above says ?error C2220: warning treated as error?, so I > > decided to let Franco know --disable-warnings-as-errors helped me. > > Yeah sorry - getting confused by the different things Franco tried. He > tried a JDK11 build with --disable-warnings-as-errors but it still > failed because of real errors: > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): > > error C2956: sized deallocation function 'operator delete(void*, > size_t)' would be chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > > Then he posted that he'd tried jdk12 as well with "similar errors" but > only showed the > > error C2220: warning treated as error - no 'object' file generated > warning C4267: '=': conversion from 'size_t' to 'u2', possible loss > of data > > which means he was not running with --disable-warnings-as-errors > > David > ----- > > > > > > It's been a long while since I built jdk-dev on 32 bit Windows last > > time; many things could have changed there. > > > > Regards, > > Alexey > > > >> > >> Cheers, > >> David > >> > >>> David pointed to JDK-8205677 which should be forwardported to > 13 to > >>> fix the problem. > >>> > >>> Regards, > >>> Alexey > >>> > >>>> > >>>> This is an issue we ran into compiling 8u with VS2017: > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8205677 > >>>> > >>>> We probably never noticed in JDK 12 because we don't do 32-bits > >>>> builds with VS2017. > >>>> > >>>> David > >>>> ----- > >>>> > >>>>> * All command lines available in > >>>>> > /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. > > >>>>> > >>>>> === End of repeated output === > >>>>> > >>>>> No indication of failed target found. > >>>>> Hint: Try searching the build log for '] Error'. > >>>>> Hint: See doc/building.html#troubleshooting for assistance. > >>>>> > >>>>> make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] > Error 2 > >>>>> make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] > Error 2 > >>>>> > >>>>> > >>>>> El mi?., 6 de feb. de 2019 a la(s) 19:23, Franco Gast?n > Pellegrini > >>>>> (francogpellegrini at gmail.com > > >) > >>>>> escribi?: > >>>>> > >>>>> ??? I just tried --disable-warnings-as-errors, and JDK 11 > 64bits as a > >>>>> ??? bootjdk, but I get a lots of errors, and it refuse to build, > >>>>> like this: > >>>>> > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > >>>>> > >>>>> ??? warning C4267: '=': conversion from 'size_t' to 'u2', > possible > >>>>> loss > >>>>> ??? of data > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): > > >>>>> > >>>>> ??? error C2956: sized deallocation function 'operator > delete(void*, > >>>>> ??? size_t)' would be chosen as placement deallocation function. > >>>>> ??? predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> ??? of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): > > >>>>> > >>>>> ??? error C2956: sized deallocation function 'operator > delete(void*, > >>>>> ??? size_t)' would be chosen as placement deallocation function. > >>>>> ??? predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> ??? of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): > > >>>>> > >>>>> ??? error C2956: sized deallocation function 'operator > delete(void*, > >>>>> ??? size_t)' would be chosen as placement deallocation function. > >>>>> ??? predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> ??? of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): > > >>>>> > >>>>> ??? error C2956: sized deallocation function 'operator > delete(void*, > >>>>> ??? size_t)' would be chosen as placement deallocation function. > >>>>> ??? predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> ??? of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): > > >>>>> > >>>>> ??? error C2956: sized deallocation function 'operator > delete(void*, > >>>>> ??? size_t)' would be chosen as placement deallocation function. > >>>>> ??? predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> ??? of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): > > >>>>> > >>>>> ??? error C2956: sized deallocation function 'operator > delete(void*, > >>>>> ??? size_t)' would be chosen as placement deallocation function. > >>>>> ??? predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> ??? of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): > > >>>>> > >>>>> ??? error C2956: sized deallocation function 'operator > delete(void*, > >>>>> ??? size_t)' would be chosen as placement deallocation function. > >>>>> ??? predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> ??? of 'operator delete' > >>>>> > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): > > >>>>> > >>>>> ??? error C2956: sized deallocation function 'operator > delete(void*, > >>>>> ??? size_t)' would be chosen as placement deallocation function. > >>>>> ??? predefined C++ types (compiler internal)(44): note: see > >>>>> declaration > >>>>> ??? of 'operator delete' > >>>>> > >>>>> > >>> > > > From francogpellegrini at gmail.com Tue Feb 12 03:45:47 2019 From: francogpellegrini at gmail.com (=?UTF-8?Q?Franco_Gast=C3=B3n_Pellegrini?=) Date: Tue, 12 Feb 2019 00:45:47 -0300 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: <294f30aa-fef4-3c6c-302d-77a1bc7d1547@oracle.com> References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> <294f30aa-fef4-3c6c-302d-77a1bc7d1547@oracle.com> Message-ID: I just downloaded again (to be sure about my errors) JDK 12 and use this command: bash ./configure --enable-debug --disable-warnings-as-errors --with-target-bits=32 --with-toolchain-version=2017 --with-jvm-variants=client --with-boot-jdk="/cygdrive/c/Program Files/Java/jdk-11.0.2/"; and I get: ERROR: Build failed for target 'default (exploded-image)' in configuration 'windows-x86-client-fastdebug' (exit code 2) Stopping sjavac server === Output from failing command(s) repeated here === * For target support_native_java.desktop_libawt_Hashtable.obj: Hashtable.cpp c:/cygwin64/home/franc/java/jdk12/src/java.desktop/windows/native/libawt/windows/Hashtable.cpp(53): error C2664: 'void DTrace_PrintFunction(DTRACE_PRINT_CALLBACK,dtrace_id *,dtrace_id *,const char *,int,int,const char *,...)': cannot convert argument 1 from 'void (__stdcall *)(const char *,int,int,const char *,va_list)' to 'DTRACE_PRINT_CALLBACK' c:/cygwin64/home/franc/java/jdk12/src/java.desktop/windows/native/libawt/windows/Hashtable.cpp(53): note: None of the functions with this name in scope match the target type ... (rest of output omitted) * All command lines available in /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. === End of repeated output === No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: See doc/building.html#troubleshooting for assistance. make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 El lun., 11 de feb. de 2019 a la(s) 19:53, David Holmes ( david.holmes at oracle.com) escribi?: > On 12/02/2019 8:28 am, Franco Gast?n Pellegrini wrote: > > My mistake to not fully describe it but I tried jdk 11 and 12 using the > > disable warning as error on both, getting similar errors. (Both 32 bits) > > The "operator delete" issue has already been encountered: > > https://bugs.openjdk.java.net/browse/JDK-8196880 > > But I can't see how that relates to share/code/codeBlob.cpp and only for > 32-bit. That would be a question for hotspot-dev at openjdk.java.net > > David > > > El lun., 11 de feb. de 2019 19:26, David Holmes > > escribi?: > > > > On 12/02/2019 12:03 am, Alexey Ivanov wrote: > > > Hi David, > > > > > > On 11/02/2019 11:33, David Holmes wrote: > > >> Hi Alexey, > > >> > > >> On 11/02/2019 7:12 pm, Alexey Ivanov wrote: > > >>> Hi Franco, > > >>> > > >>> On 11/02/2019 02:03, David Holmes wrote: > > >>>> On 8/02/2019 5:07 am, Franco Gast?n Pellegrini wrote: > > >>>>> I tried compiling JDK 12 for 32 bits, and I get similar > errors: > > >>>>> > > >>>>> === Output from failing command(s) repeated here === > > >>>>> * For target > > hotspot_variant-client_libjvm_objs_classFileParser.obj: > > >>>>> classFileParser.cpp > > >>>>> > > > c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): > > > > >>>>> error C2220: warning treated as error - no 'object' file > > generated > > >>>>> > > > c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): > > > > >>>>> warning C4267: '=': conversion from 'size_t' to 'u2', > > possible loss > > >>>>> of data > > >>>>> ... (rest of output omitted) > > >>> > > >>> I used --disable-warnings-as-errors option to configure when I > > built > > >>> JDK for 32 bit Windows last time. > > >> > > >> Note there are actual errors in Franco's log not just the > > warnings I > > >> commented on. I think we've already encountered the operate > delete > > >> issue so it may be fixed in 13, but not 12. Need to track it > down. > > > > > > I must have missed that point. > > > The message above says ?error C2220: warning treated as error?, > so I > > > decided to let Franco know --disable-warnings-as-errors helped me. > > > > Yeah sorry - getting confused by the different things Franco tried. > He > > tried a JDK11 build with --disable-warnings-as-errors but it still > > failed because of real errors: > > > > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): > > > > error C2956: sized deallocation function 'operator delete(void*, > > size_t)' would be chosen as placement deallocation function. > > predefined C++ types (compiler internal)(44): note: see declaration > of > > 'operator delete' > > > > Then he posted that he'd tried jdk12 as well with "similar errors" > but > > only showed the > > > > error C2220: warning treated as error - no 'object' file generated > > warning C4267: '=': conversion from 'size_t' to 'u2', possible loss > > of data > > > > which means he was not running with --disable-warnings-as-errors > > > > David > > ----- > > > > > > > > > > It's been a long while since I built jdk-dev on 32 bit Windows > last > > > time; many things could have changed there. > > > > > > Regards, > > > Alexey > > > > > >> > > >> Cheers, > > >> David > > >> > > >>> David pointed to JDK-8205677 which should be forwardported to > > 13 to > > >>> fix the problem. > > >>> > > >>> Regards, > > >>> Alexey > > >>> > > >>>> > > >>>> This is an issue we ran into compiling 8u with VS2017: > > >>>> > > >>>> https://bugs.openjdk.java.net/browse/JDK-8205677 > > >>>> > > >>>> We probably never noticed in JDK 12 because we don't do 32-bits > > >>>> builds with VS2017. > > >>>> > > >>>> David > > >>>> ----- > > >>>> > > >>>>> * All command lines available in > > >>>>> > > > /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. > > > > >>>>> > > >>>>> === End of repeated output === > > >>>>> > > >>>>> No indication of failed target found. > > >>>>> Hint: Try searching the build log for '] Error'. > > >>>>> Hint: See doc/building.html#troubleshooting for assistance. > > >>>>> > > >>>>> make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] > > Error 2 > > >>>>> make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] > > Error 2 > > >>>>> > > >>>>> > > >>>>> El mi?., 6 de feb. de 2019 a la(s) 19:23, Franco Gast?n > > Pellegrini > > >>>>> (francogpellegrini at gmail.com > > > > > >) > > >>>>> escribi?: > > >>>>> > > >>>>> I just tried --disable-warnings-as-errors, and JDK 11 > > 64bits as a > > >>>>> bootjdk, but I get a lots of errors, and it refuse to > build, > > >>>>> like this: > > >>>>> > > >>>>> > > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > > > >>>>> > > >>>>> warning C4267: '=': conversion from 'size_t' to 'u2', > > possible > > >>>>> loss > > >>>>> of data > > >>>>> > > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): > > > > >>>>> > > >>>>> error C2956: sized deallocation function 'operator > > delete(void*, > > >>>>> size_t)' would be chosen as placement deallocation > function. > > >>>>> predefined C++ types (compiler internal)(44): note: see > > >>>>> declaration > > >>>>> of 'operator delete' > > >>>>> > > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): > > > > >>>>> > > >>>>> error C2956: sized deallocation function 'operator > > delete(void*, > > >>>>> size_t)' would be chosen as placement deallocation > function. > > >>>>> predefined C++ types (compiler internal)(44): note: see > > >>>>> declaration > > >>>>> of 'operator delete' > > >>>>> > > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): > > > > >>>>> > > >>>>> error C2956: sized deallocation function 'operator > > delete(void*, > > >>>>> size_t)' would be chosen as placement deallocation > function. > > >>>>> predefined C++ types (compiler internal)(44): note: see > > >>>>> declaration > > >>>>> of 'operator delete' > > >>>>> > > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): > > > > >>>>> > > >>>>> error C2956: sized deallocation function 'operator > > delete(void*, > > >>>>> size_t)' would be chosen as placement deallocation > function. > > >>>>> predefined C++ types (compiler internal)(44): note: see > > >>>>> declaration > > >>>>> of 'operator delete' > > >>>>> > > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): > > > > >>>>> > > >>>>> error C2956: sized deallocation function 'operator > > delete(void*, > > >>>>> size_t)' would be chosen as placement deallocation > function. > > >>>>> predefined C++ types (compiler internal)(44): note: see > > >>>>> declaration > > >>>>> of 'operator delete' > > >>>>> > > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): > > > > >>>>> > > >>>>> error C2956: sized deallocation function 'operator > > delete(void*, > > >>>>> size_t)' would be chosen as placement deallocation > function. > > >>>>> predefined C++ types (compiler internal)(44): note: see > > >>>>> declaration > > >>>>> of 'operator delete' > > >>>>> > > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): > > > > >>>>> > > >>>>> error C2956: sized deallocation function 'operator > > delete(void*, > > >>>>> size_t)' would be chosen as placement deallocation > function. > > >>>>> predefined C++ types (compiler internal)(44): note: see > > >>>>> declaration > > >>>>> of 'operator delete' > > >>>>> > > > c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): > > > > >>>>> > > >>>>> error C2956: sized deallocation function 'operator > > delete(void*, > > >>>>> size_t)' would be chosen as placement deallocation > function. > > >>>>> predefined C++ types (compiler internal)(44): note: see > > >>>>> declaration > > >>>>> of 'operator delete' > > >>>>> > > >>>>> > > >>> > > > > > > -- Franco Gast?n Pellegrini From david.holmes at oracle.com Tue Feb 12 04:25:15 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Feb 2019 14:25:15 +1000 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> <294f30aa-fef4-3c6c-302d-77a1bc7d1547@oracle.com> Message-ID: On 12/02/2019 1:45 pm, Franco Gast?n Pellegrini wrote: > I just downloaded again (to be sure about my errors) JDK 12 and use this > command: > bash ./configure --enable-debug --disable-warnings-as-errors > --with-target-bits=32 --with-toolchain-version=2017 > --with-jvm-variants=client --with-boot-jdk="/cygdrive/c/Program > Files/Java/jdk-11.0.2/"; > > and I get: > > ERROR: Build failed for target 'default (exploded-image)' in > configuration 'windows-x86-client-fastdebug' (exit code 2) > Stopping sjavac server > > === Output from failing command(s) repeated here === > * For target support_native_java.desktop_libawt_Hashtable.obj: > Hashtable.cpp > c:/cygwin64/home/franc/java/jdk12/src/java.desktop/windows/native/libawt/windows/Hashtable.cpp(53): > error C2664: 'void DTrace_PrintFunction(DTRACE_PRINT_CALLBACK,dtrace_id > *,dtrace_id *,const char *,int,int,const char *,...)': cannot convert > argument 1 from 'void (__stdcall *)(const char *,int,int,const char > *,va_list)' to 'DTRACE_PRINT_CALLBACK' > c:/cygwin64/home/franc/java/jdk12/src/java.desktop/windows/native/libawt/windows/Hashtable.cpp(53): > note: None of the functions with this name in scope match the target type Sorry I can't see anything that would cause that - certainly nothing 32-bit specific. David ----- > ? ?... (rest of output omitted) > > * All command lines available in > /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. > === End of repeated output === > > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: See doc/building.html#troubleshooting for assistance. > > make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 > make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 > > > El lun., 11 de feb. de 2019 a la(s) 19:53, David Holmes > (david.holmes at oracle.com ) escribi?: > > On 12/02/2019 8:28 am, Franco Gast?n Pellegrini wrote: > > My mistake to not fully describe it but I tried jdk 11 and 12 > using the > > disable warning as error on both, getting similar errors. (Both > 32 bits) > > The "operator delete" issue has already been encountered: > > https://bugs.openjdk.java.net/browse/JDK-8196880 > > But I can't see how that relates to share/code/codeBlob.cpp and only > for > 32-bit. That would be a question for hotspot-dev at openjdk.java.net > > > David > > > El lun., 11 de feb. de 2019 19:26, David Holmes > > > >> escribi?: > > > >? ? ?On 12/02/2019 12:03 am, Alexey Ivanov wrote: > >? ? ? > Hi David, > >? ? ? > > >? ? ? > On 11/02/2019 11:33, David Holmes wrote: > >? ? ? >> Hi Alexey, > >? ? ? >> > >? ? ? >> On 11/02/2019 7:12 pm, Alexey Ivanov wrote: > >? ? ? >>> Hi Franco, > >? ? ? >>> > >? ? ? >>> On 11/02/2019 02:03, David Holmes wrote: > >? ? ? >>>> On 8/02/2019 5:07 am, Franco Gast?n Pellegrini wrote: > >? ? ? >>>>> I tried compiling JDK 12 for 32 bits, and I get > similar errors: > >? ? ? >>>>> > >? ? ? >>>>> === Output from failing command(s) repeated here === > >? ? ? >>>>> * For target > >? ? ?hotspot_variant-client_libjvm_objs_classFileParser.obj: > >? ? ? >>>>> classFileParser.cpp > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): > > > >? ? ? >>>>> error C2220: warning treated as error - no 'object' file > >? ? ?generated > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk12/src/hotspot/share/classfile/classFileParser.cpp(312): > > > >? ? ? >>>>> warning C4267: '=': conversion from 'size_t' to 'u2', > >? ? ?possible loss > >? ? ? >>>>> of data > >? ? ? >>>>> ?? ?... (rest of output omitted) > >? ? ? >>> > >? ? ? >>> I used --disable-warnings-as-errors option to configure > when I > >? ? ?built > >? ? ? >>> JDK for 32 bit Windows last time. > >? ? ? >> > >? ? ? >> Note there are actual errors in Franco's log not just the > >? ? ?warnings I > >? ? ? >> commented on. I think we've already encountered the > operate delete > >? ? ? >> issue so it may be fixed in 13, but not 12. Need to track > it down. > >? ? ? > > >? ? ? > I must have missed that point. > >? ? ? > The message above says ?error C2220: warning treated as > error?, so I > >? ? ? > decided to let Franco know --disable-warnings-as-errors > helped me. > > > >? ? ?Yeah sorry - getting confused by the different things Franco > tried. He > >? ? ?tried a JDK11 build with --disable-warnings-as-errors but it > still > >? ? ?failed because of real errors: > > > > > ?c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): > > > >? ? ?error C2956: sized deallocation function 'operator delete(void*, > >? ? ?size_t)' would be chosen as placement deallocation function. > >? ? ?predefined C++ types (compiler internal)(44): note: see > declaration of > >? ? ?'operator delete' > > > >? ? ?Then he posted that he'd tried jdk12 as well with "similar > errors" but > >? ? ?only showed the > > > >? ? ?error C2220: warning treated as error - no 'object' file > generated > >? ? ?warning C4267: '=': conversion from 'size_t' to 'u2', > possible loss > >? ? ?of data > > > >? ? ?which means he was not running with --disable-warnings-as-errors > > > >? ? ?David > >? ? ?----- > > > > > >? ? ? > > >? ? ? > It's been a long while since I built jdk-dev on 32 bit > Windows last > >? ? ? > time; many things could have changed there. > >? ? ? > > >? ? ? > Regards, > >? ? ? > Alexey > >? ? ? > > >? ? ? >> > >? ? ? >> Cheers, > >? ? ? >> David > >? ? ? >> > >? ? ? >>> David pointed to JDK-8205677 which should be > forwardported to > >? ? ?13 to > >? ? ? >>> fix the problem. > >? ? ? >>> > >? ? ? >>> Regards, > >? ? ? >>> Alexey > >? ? ? >>> > >? ? ? >>>> > >? ? ? >>>> This is an issue we ran into compiling 8u with VS2017: > >? ? ? >>>> > >? ? ? >>>> https://bugs.openjdk.java.net/browse/JDK-8205677 > >? ? ? >>>> > >? ? ? >>>> We probably never noticed in JDK 12 because we don't do > 32-bits > >? ? ? >>>> builds with VS2017. > >? ? ? >>>> > >? ? ? >>>> David > >? ? ? >>>> ----- > >? ? ? >>>> > >? ? ? >>>>> * All command lines available in > >? ? ? >>>>> > > > ?/cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. > > > >? ? ? >>>>> > >? ? ? >>>>> === End of repeated output === > >? ? ? >>>>> > >? ? ? >>>>> No indication of failed target found. > >? ? ? >>>>> Hint: Try searching the build log for '] Error'. > >? ? ? >>>>> Hint: See doc/building.html#troubleshooting for > assistance. > >? ? ? >>>>> > >? ? ? >>>>> make[1]: *** > [/home/franc/java/jdk12/make/Init.gmk:310: main] > >? ? ?Error 2 > >? ? ? >>>>> make: *** [/home/franc/java/jdk12/make/Init.gmk:186: > default] > >? ? ?Error 2 > >? ? ? >>>>> > >? ? ? >>>>> > >? ? ? >>>>> El mi?., 6 de feb. de 2019 a la(s) 19:23, Franco Gast?n > >? ? ?Pellegrini > >? ? ? >>>>> (francogpellegrini at gmail.com > > >? ? ? > > >? ? ? > >? ? ? >>) > >? ? ? >>>>> escribi?: > >? ? ? >>>>> > >? ? ? >>>>> ??? I just tried --disable-warnings-as-errors, and JDK 11 > >? ? ?64bits as a > >? ? ? >>>>> ??? bootjdk, but I get a lots of errors, and it refuse > to build, > >? ? ? >>>>> like this: > >? ? ? >>>>> > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > > >? ? ? >>>>> > >? ? ? >>>>> ??? warning C4267: '=': conversion from 'size_t' to 'u2', > >? ? ?possible > >? ? ? >>>>> loss > >? ? ? >>>>> ??? of data > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): > > > >? ? ? >>>>> > >? ? ? >>>>> ??? error C2956: sized deallocation function 'operator > >? ? ?delete(void*, > >? ? ? >>>>> ??? size_t)' would be chosen as placement deallocation > function. > >? ? ? >>>>> ??? predefined C++ types (compiler internal)(44): > note: see > >? ? ? >>>>> declaration > >? ? ? >>>>> ??? of 'operator delete' > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): > > > >? ? ? >>>>> > >? ? ? >>>>> ??? error C2956: sized deallocation function 'operator > >? ? ?delete(void*, > >? ? ? >>>>> ??? size_t)' would be chosen as placement deallocation > function. > >? ? ? >>>>> ??? predefined C++ types (compiler internal)(44): > note: see > >? ? ? >>>>> declaration > >? ? ? >>>>> ??? of 'operator delete' > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): > > > >? ? ? >>>>> > >? ? ? >>>>> ??? error C2956: sized deallocation function 'operator > >? ? ?delete(void*, > >? ? ? >>>>> ??? size_t)' would be chosen as placement deallocation > function. > >? ? ? >>>>> ??? predefined C++ types (compiler internal)(44): > note: see > >? ? ? >>>>> declaration > >? ? ? >>>>> ??? of 'operator delete' > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): > > > >? ? ? >>>>> > >? ? ? >>>>> ??? error C2956: sized deallocation function 'operator > >? ? ?delete(void*, > >? ? ? >>>>> ??? size_t)' would be chosen as placement deallocation > function. > >? ? ? >>>>> ??? predefined C++ types (compiler internal)(44): > note: see > >? ? ? >>>>> declaration > >? ? ? >>>>> ??? of 'operator delete' > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): > > > >? ? ? >>>>> > >? ? ? >>>>> ??? error C2956: sized deallocation function 'operator > >? ? ?delete(void*, > >? ? ? >>>>> ??? size_t)' would be chosen as placement deallocation > function. > >? ? ? >>>>> ??? predefined C++ types (compiler internal)(44): > note: see > >? ? ? >>>>> declaration > >? ? ? >>>>> ??? of 'operator delete' > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): > > > >? ? ? >>>>> > >? ? ? >>>>> ??? error C2956: sized deallocation function 'operator > >? ? ?delete(void*, > >? ? ? >>>>> ??? size_t)' would be chosen as placement deallocation > function. > >? ? ? >>>>> ??? predefined C++ types (compiler internal)(44): > note: see > >? ? ? >>>>> declaration > >? ? ? >>>>> ??? of 'operator delete' > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): > > > >? ? ? >>>>> > >? ? ? >>>>> ??? error C2956: sized deallocation function 'operator > >? ? ?delete(void*, > >? ? ? >>>>> ??? size_t)' would be chosen as placement deallocation > function. > >? ? ? >>>>> ??? predefined C++ types (compiler internal)(44): > note: see > >? ? ? >>>>> declaration > >? ? ? >>>>> ??? of 'operator delete' > >? ? ? >>>>> > > > ?c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): > > > >? ? ? >>>>> > >? ? ? >>>>> ??? error C2956: sized deallocation function 'operator > >? ? ?delete(void*, > >? ? ? >>>>> ??? size_t)' would be chosen as placement deallocation > function. > >? ? ? >>>>> ??? predefined C++ types (compiler internal)(44): > note: see > >? ? ? >>>>> declaration > >? ? ? >>>>> ??? of 'operator delete' > >? ? ? >>>>> > >? ? ? >>>>> > >? ? ? >>> > >? ? ? > > > > > > > -- > Franco Gast?n Pellegrini From robin.westberg at oracle.com Tue Feb 12 08:01:34 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Tue, 12 Feb 2019 09:01:34 +0100 Subject: RFR: JDK-8218807: Compilation database (compile_commands.json) may contain obsolete items Message-ID: <5C755533-D78B-451F-B8D5-874760CA166F@oracle.com> Hi all, When generating a compilation database by either "make compile-commands" or "make compile-commands-hotspot", every object file that should be built results in a temporary json fragment describing the compiler invocation. However, when the final compile_commands.json file is assembled, all these temporary files are combined, regardless of whether they belong to the current make invocation or were left behind from a previous one. This has the unfortunate effect that "make compile-commands" followed by "make compile-commands-hotspot" generates something very different from an initial invocation of "make compile-commands-hotspot". Also, if a source file has been removed, it will still retain an entry in the final compile_commands.json file until the build directory is cleaned. This will lead to errors if generating an IDE project from the compile_commands.json file. Proposed solution is to always remove all previous temporary json fragments and generate them again. This generation is quite fast and only adds a second or two for repeated invocations of "make compile-commands?, which should be a reasonable tradeoff for ensuring that the compilation database contains correct information. Issue: https://bugs.openjdk.java.net/browse/JDK-8218807 Webrev: http://cr.openjdk.java.net/~rwestberg/8218807/ Testing: make test-make-compile-commands, build windows, linux, mac, solaris Best regards, Robin From sgehwolf at redhat.com Tue Feb 12 09:35:09 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Feb 2019 10:35:09 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> Message-ID: Hi Erik, On Mon, 2019-02-11 at 11:12 -0800, Erik Joelsson wrote: > Hello Severin, > > I think you also need a $(wildcard ) around it, but I may be wrong. Did > you try this version? Yes, this version works for me without $(wildcard). Why is it needed? > Also, please do not indent so much. We have style guidelines [1], which > recommend 4 spaces for line break indentation. OK, sorry. Fixed locally. Thanks, Severin > /Erik > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > On 2019-02-11 10:03, Severin Gehwolf wrote: > > Hi Erik, > > > > On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: > > > On 2019-02-07 11:09, Severin Gehwolf wrote: > > > > Hi Erik, > > > > > > > > On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: > > > > > Hello Severin, > > > > > > > > > > There is a macro for automatically finding all source dirs for a module. > > > > > So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using > > > > > that macro, like this: > > > > > > > > > > JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix > > > > > /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) > > > > > > > > > > The above could/should even be inlined. > > > > I've considered this. It seems, though, that FindModuleSrcDirs comes > > > > from make/common/Modules.gmk which isn't included in > > > > make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused > > > > problems with multiple includes of Modules.gmk (JDK-8213736) I was > > > > reluctant to include it here too. Without the new include the above > > > > won't work. > > > > > > > > The approach I've taken here seems to be the lesser evil. Thoughts? > > > I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, > > > which is part of where Modules.gmk gets bootstrapped. In any normal > > > makefile (as in where stuff is just being built), the bootstrapping is > > > done and including Modules.gmk is completely fine. Any > > > -.gmk file certainly qualifies here. > > OK. Updated: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ > > > > Thanks, > > Severin > > > > > /Erik > > > > > > > Thanks, > > > > Severin > > > > > > > > > Otherwise build changes look ok. > > > > > > > > > > /Erik > > > > > > > > > > On 2019-02-07 09:09, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > Could I please get reviews for this enhancement? It adds a > > > > > > debug > > > > > > symbols stripping plug-in to jlink for Linux and Unix > > > > > > platforms. It's > > > > > > the first platform specific jlink plugin and the approach taken > > > > > > for > > > > > > keeping it contained is to use a plugin specific > > > > > > ResourceBundle. > > > > > > Discussion for this happened in [1]. > > > > > > > > > > > > The test uses a native library which should never get debug > > > > > > symbols > > > > > > stripped during the test library build. As such, tiny > > > > > > modifications > > > > > > were needed to make/common/TestFilesCompilation.gmk. Hence, > > > > > > build-dev > > > > > > being on the list for this RFR. The test currently only runs on > > > > > > Linux > > > > > > and requires objcopy to be available. Otherwise the test is > > > > > > being > > > > > > skipped. > > > > > > > > > > > > Example usage of this plugin is described in the bug. > > > > > > > > > > > > webrev: > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > > > > > > > > > > > Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on > > > > > > Linux > > > > > > x86_64 (with good and broken objcopy) and the newly added test. > > > > > > It's > > > > > > currently running through jdk/submit too. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > [1] > > > > > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html > > > > > > From alexey.ivanov at oracle.com Tue Feb 12 13:38:13 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 12 Feb 2019 13:38:13 +0000 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> <294f30aa-fef4-3c6c-302d-77a1bc7d1547@oracle.com> Message-ID: On 12/02/2019 04:25, David Holmes wrote: > On 12/02/2019 1:45 pm, Franco Gast?n Pellegrini wrote: >> I just downloaded again (to be sure about my errors) JDK 12 and use >> this command: >> bash ./configure --enable-debug --disable-warnings-as-errors >> --with-target-bits=32 --with-toolchain-version=2017 >> --with-jvm-variants=client --with-boot-jdk="/cygdrive/c/Program >> Files/Java/jdk-11.0.2/"; >> >> and I get: >> >> ERROR: Build failed for target 'default (exploded-image)' in >> configuration 'windows-x86-client-fastdebug' (exit code 2) >> Stopping sjavac server >> >> === Output from failing command(s) repeated here === >> * For target support_native_java.desktop_libawt_Hashtable.obj: >> Hashtable.cpp >> c:/cygwin64/home/franc/java/jdk12/src/java.desktop/windows/native/libawt/windows/Hashtable.cpp(53): >> error C2664: 'void >> DTrace_PrintFunction(DTRACE_PRINT_CALLBACK,dtrace_id *,dtrace_id >> *,const char *,int,int,const char *,...)': cannot convert argument 1 >> from 'void (__stdcall *)(const char *,int,int,const char *,va_list)' >> to 'DTRACE_PRINT_CALLBACK' >> c:/cygwin64/home/franc/java/jdk12/src/java.desktop/windows/native/libawt/windows/Hashtable.cpp(53): >> note: None of the functions with this name in scope match the target >> type Maybe CALLBACK / JNICALL macro is missing somewhere? If I understand correctly, a pointer to function with __stdcall calling convention is expected; but DTRACE_PRINT_CALLBACK probably does not have it. Does it build successfully if you don't define DEBUG? Regards, Alexey > > Sorry I can't see anything that would cause that - certainly nothing > 32-bit specific. > > David > ----- > >> ?? ?... (rest of output omitted) >> >> * All command lines available in >> /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. >> === End of repeated output === >> >> No indication of failed target found. >> Hint: Try searching the build log for '] Error'. >> Hint: See doc/building.html#troubleshooting for assistance. >> >> make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 >> make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 >> >> From magnus.ihse.bursie at oracle.com Tue Feb 12 14:37:16 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 12 Feb 2019 15:37:16 +0100 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <62427bc6-d809-6746-7717-255752360d8a@oracle.com> <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> <294f30aa-fef4-3c6c-302d-77a1bc7d1547@oracle.com> Message-ID: On 2019-02-12 14:38, Alexey Ivanov wrote: > On 12/02/2019 04:25, David Holmes wrote: >> On 12/02/2019 1:45 pm, Franco Gast?n Pellegrini wrote: >>> I just downloaded again (to be sure about my errors) JDK 12 and use >>> this command: >>> bash ./configure --enable-debug --disable-warnings-as-errors >>> --with-target-bits=32 --with-toolchain-version=2017 >>> --with-jvm-variants=client --with-boot-jdk="/cygdrive/c/Program >>> Files/Java/jdk-11.0.2/"; >>> >>> and I get: >>> >>> ERROR: Build failed for target 'default (exploded-image)' in >>> configuration 'windows-x86-client-fastdebug' (exit code 2) >>> Stopping sjavac server >>> >>> === Output from failing command(s) repeated here === >>> * For target support_native_java.desktop_libawt_Hashtable.obj: >>> Hashtable.cpp >>> c:/cygwin64/home/franc/java/jdk12/src/java.desktop/windows/native/libawt/windows/Hashtable.cpp(53): >>> error C2664: 'void >>> DTrace_PrintFunction(DTRACE_PRINT_CALLBACK,dtrace_id *,dtrace_id >>> *,const char *,int,int,const char *,...)': cannot convert argument 1 >>> from 'void (__stdcall *)(const char *,int,int,const char *,va_list)' >>> to 'DTRACE_PRINT_CALLBACK' >>> c:/cygwin64/home/franc/java/jdk12/src/java.desktop/windows/native/libawt/windows/Hashtable.cpp(53): >>> note: None of the functions with this name in scope match the target >>> type > > Maybe CALLBACK / JNICALL macro is missing somewhere? > If I understand correctly, a pointer to function with __stdcall > calling convention is expected; but DTRACE_PRINT_CALLBACK probably > does not have it. There has been some fallout due to the mapfile/linking changes made in JDK 12 that affected JNICALL. However, that should not be affecting JDK 11. /Magnus > > Does it build successfully if you don't define DEBUG? > > Regards, > Alexey > >> >> Sorry I can't see anything that would cause that - certainly nothing >> 32-bit specific. >> >> David >> ----- >> >>> ?? ?... (rest of output omitted) >>> >>> * All command lines available in >>> /cygdrive/c/cygwin64/home/franc/java/jdk12/build/windows-x86-client-fastdebug/make-support/failure-logs. >>> === End of repeated output === >>> >>> No indication of failed target found. >>> Hint: Try searching the build log for '] Error'. >>> Hint: See doc/building.html#troubleshooting for assistance. >>> >>> make[1]: *** [/home/franc/java/jdk12/make/Init.gmk:310: main] Error 2 >>> make: *** [/home/franc/java/jdk12/make/Init.gmk:186: default] Error 2 >>> >>> > From magnus.ihse.bursie at oracle.com Tue Feb 12 14:38:38 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 12 Feb 2019 15:38:38 +0100 Subject: RFR: JDK-8218807: Compilation database (compile_commands.json) may contain obsolete items In-Reply-To: <5C755533-D78B-451F-B8D5-874760CA166F@oracle.com> References: <5C755533-D78B-451F-B8D5-874760CA166F@oracle.com> Message-ID: <4c146b6f-1a7c-7acb-f67f-0c611426955b@oracle.com> On 2019-02-12 09:01, Robin Westberg wrote: > Hi all, > > When generating a compilation database by either "make compile-commands" or "make compile-commands-hotspot", every object file that should be built results in a temporary json fragment describing the compiler invocation. However, when the final compile_commands.json file is assembled, all these temporary files are combined, regardless of whether they belong to the current make invocation or were left behind from a previous one. > > This has the unfortunate effect that "make compile-commands" followed by "make compile-commands-hotspot" generates something very different from an initial invocation of "make compile-commands-hotspot". Also, if a source file has been removed, it will still retain an entry in the final compile_commands.json file until the build directory is cleaned. This will lead to errors if generating an IDE project from the compile_commands.json file. > > Proposed solution is to always remove all previous temporary json fragments and generate them again. This generation is quite fast and only adds a second or two for repeated invocations of "make compile-commands?, which should be a reasonable tradeoff for ensuring that the compilation database contains correct information. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8218807 > Webrev: http://cr.openjdk.java.net/~rwestberg/8218807/ Looks good to me. /Magnus > Testing: make test-make-compile-commands, build windows, linux, mac, solaris > > Best regards, > Robin From alexey.ivanov at oracle.com Tue Feb 12 14:42:07 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 12 Feb 2019 14:42:07 +0000 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <29577ad6-5bbc-a36e-e526-fe735af3e3c5@oracle.com> <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> <294f30aa-fef4-3c6c-302d-77a1bc7d1547@oracle.com> Message-ID: <29c6de1c-a756-d03c-358f-cd1d82b3ad94@oracle.com> On 12/02/2019 14:37, Magnus Ihse Bursie wrote: > There has been some fallout due to the mapfile/linking changes made in > JDK 12 that affected JNICALL. However, that should not be affecting > JDK 11. Wasn't it done in JDK 11? If my memory serves me right, it was done in JDK 11. -- Alexey From erik.joelsson at oracle.com Tue Feb 12 16:44:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Feb 2019 08:44:48 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> Message-ID: On 2019-02-12 01:35, Severin Gehwolf wrote: > Hi Erik, > > On Mon, 2019-02-11 at 11:12 -0800, Erik Joelsson wrote: >> Hello Severin, >> >> I think you also need a $(wildcard ) around it, but I may be wrong. Did >> you try this version? > Yes, this version works for me without $(wildcard). Why is it needed? I had to go back and check again to verify, but now I'm sure. The list of directories returned by FindModuleSrcDirs is all src dirs for the module. Not all of them are going to contain the specific directory jdk/tools/jlink/resources. This means SetupCompileProperties will get called with a few non existing directories. While this will work fine, the find implementation on some platforms will complain (Macos in particular), so to avoid introducing confusing warning messages in the build, it's better to filter down the list of directories to those that actually exist. >> Also, please do not indent so much. We have style guidelines [1], which >> recommend 4 spaces for line break indentation. > OK, sorry. Fixed locally. Thanks! /Erik > Thanks, > Severin > >> /Erik >> >> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >> >> On 2019-02-11 10:03, Severin Gehwolf wrote: >>> Hi Erik, >>> >>> On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: >>>> On 2019-02-07 11:09, Severin Gehwolf wrote: >>>>> Hi Erik, >>>>> >>>>> On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: >>>>>> Hello Severin, >>>>>> >>>>>> There is a macro for automatically finding all source dirs for a module. >>>>>> So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using >>>>>> that macro, like this: >>>>>> >>>>>> JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix >>>>>> /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) >>>>>> >>>>>> The above could/should even be inlined. >>>>> I've considered this. It seems, though, that FindModuleSrcDirs comes >>>>> from make/common/Modules.gmk which isn't included in >>>>> make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused >>>>> problems with multiple includes of Modules.gmk (JDK-8213736) I was >>>>> reluctant to include it here too. Without the new include the above >>>>> won't work. >>>>> >>>>> The approach I've taken here seems to be the lesser evil. Thoughts? >>>> I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, >>>> which is part of where Modules.gmk gets bootstrapped. In any normal >>>> makefile (as in where stuff is just being built), the bootstrapping is >>>> done and including Modules.gmk is completely fine. Any >>>> -.gmk file certainly qualifies here. >>> OK. Updated: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ >>> >>> Thanks, >>> Severin >>> >>>> /Erik >>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>>> Otherwise build changes look ok. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2019-02-07 09:09, Severin Gehwolf wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could I please get reviews for this enhancement? It adds a >>>>>>> debug >>>>>>> symbols stripping plug-in to jlink for Linux and Unix >>>>>>> platforms. It's >>>>>>> the first platform specific jlink plugin and the approach taken >>>>>>> for >>>>>>> keeping it contained is to use a plugin specific >>>>>>> ResourceBundle. >>>>>>> Discussion for this happened in [1]. >>>>>>> >>>>>>> The test uses a native library which should never get debug >>>>>>> symbols >>>>>>> stripped during the test library build. As such, tiny >>>>>>> modifications >>>>>>> were needed to make/common/TestFilesCompilation.gmk. Hence, >>>>>>> build-dev >>>>>>> being on the list for this RFR. The test currently only runs on >>>>>>> Linux >>>>>>> and requires objcopy to be available. Otherwise the test is >>>>>>> being >>>>>>> skipped. >>>>>>> >>>>>>> Example usage of this plugin is described in the bug. >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 >>>>>>> >>>>>>> Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on >>>>>>> Linux >>>>>>> x86_64 (with good and broken objcopy) and the newly added test. >>>>>>> It's >>>>>>> currently running through jdk/submit too. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Thanks, >>>>>>> Severin >>>>>>> >>>>>>> [1] >>>>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html >>>>>>> From erik.joelsson at oracle.com Tue Feb 12 16:47:35 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Feb 2019 08:47:35 -0800 Subject: RFR: JDK-8218807: Compilation database (compile_commands.json) may contain obsolete items In-Reply-To: <5C755533-D78B-451F-B8D5-874760CA166F@oracle.com> References: <5C755533-D78B-451F-B8D5-874760CA166F@oracle.com> Message-ID: Looks good. /Erik On 2019-02-12 00:01, Robin Westberg wrote: > Hi all, > > When generating a compilation database by either "make compile-commands" or "make compile-commands-hotspot", every object file that should be built results in a temporary json fragment describing the compiler invocation. However, when the final compile_commands.json file is assembled, all these temporary files are combined, regardless of whether they belong to the current make invocation or were left behind from a previous one. > > This has the unfortunate effect that "make compile-commands" followed by "make compile-commands-hotspot" generates something very different from an initial invocation of "make compile-commands-hotspot". Also, if a source file has been removed, it will still retain an entry in the final compile_commands.json file until the build directory is cleaned. This will lead to errors if generating an IDE project from the compile_commands.json file. > > Proposed solution is to always remove all previous temporary json fragments and generate them again. This generation is quite fast and only adds a second or two for repeated invocations of "make compile-commands?, which should be a reasonable tradeoff for ensuring that the compilation database contains correct information. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8218807 > Webrev: http://cr.openjdk.java.net/~rwestberg/8218807/ > Testing: make test-make-compile-commands, build windows, linux, mac, solaris > > Best regards, > Robin From sgehwolf at redhat.com Tue Feb 12 17:05:48 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Feb 2019 18:05:48 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> Message-ID: <10369b87099fa48f796161ac5bc1cb08dc6f5cc5.camel@redhat.com> Hi Erik, On Tue, 2019-02-12 at 08:44 -0800, Erik Joelsson wrote: > On 2019-02-12 01:35, Severin Gehwolf wrote: > > Hi Erik, > > > > On Mon, 2019-02-11 at 11:12 -0800, Erik Joelsson wrote: > > > Hello Severin, > > > > > > I think you also need a $(wildcard ) around it, but I may be wrong. Did > > > you try this version? > > Yes, this version works for me without $(wildcard). Why is it needed? > > I had to go back and check again to verify, but now I'm sure. The list > of directories returned by FindModuleSrcDirs is all src dirs for the > module. Not all of them are going to contain the specific directory > jdk/tools/jlink/resources. This means SetupCompileProperties will get > called with a few non existing directories. While this will work fine, > the find implementation on some platforms will complain (Macos in > particular), so to avoid introducing confusing warning messages in the > build, it's better to filter down the list of directories to those that > actually exist. OK, thanks for the explanation. I suppose $(wildcard ...) does that, then? I've added it back locally but I have no way of testing whether this makes any difference, except jdk/submit perhaps? diff --git a/make/gensrc/Gensrc-jdk.jlink.gmk b/make/gensrc/Gensrc-jdk.jlink.gmk --- a/make/gensrc/Gensrc-jdk.jlink.gmk +++ b/make/gensrc/Gensrc-jdk.jlink.gmk @@ -29,8 +29,9 @@ ################################################################################ -JLINK_RESOURCES_DIRS := $(addsuffix /jdk/tools/jlink/resources, \ - $(call FindModuleSrcDirs, jdk.jlink)) +# Use wildcard so as to avoid getting non-existing directories back +JLINK_RESOURCES_DIRS := $(wildcard $(addsuffix /jdk/tools/jlink/resources, \ + $(call FindModuleSrcDirs, jdk.jlink))) $(eval $(call SetupCompileProperties, JLINK_PROPERTIES, \ SRC_DIRS := $(JLINK_RESOURCES_DIRS), \ Thanks, Severin > > > Also, please do not indent so much. We have style guidelines [1], which > > > recommend 4 spaces for line break indentation. > > OK, sorry. Fixed locally. > > Thanks! > > /Erik > > > Thanks, > > Severin > > > > > /Erik > > > > > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > > > > > On 2019-02-11 10:03, Severin Gehwolf wrote: > > > > Hi Erik, > > > > > > > > On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: > > > > > On 2019-02-07 11:09, Severin Gehwolf wrote: > > > > > > Hi Erik, > > > > > > > > > > > > On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: > > > > > > > Hello Severin, > > > > > > > > > > > > > > There is a macro for automatically finding all source dirs for a module. > > > > > > > So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using > > > > > > > that macro, like this: > > > > > > > > > > > > > > JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix > > > > > > > /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) > > > > > > > > > > > > > > The above could/should even be inlined. > > > > > > I've considered this. It seems, though, that FindModuleSrcDirs comes > > > > > > from make/common/Modules.gmk which isn't included in > > > > > > make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused > > > > > > problems with multiple includes of Modules.gmk (JDK-8213736) I was > > > > > > reluctant to include it here too. Without the new include the above > > > > > > won't work. > > > > > > > > > > > > The approach I've taken here seems to be the lesser evil. Thoughts? > > > > > I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, > > > > > which is part of where Modules.gmk gets bootstrapped. In any normal > > > > > makefile (as in where stuff is just being built), the bootstrapping is > > > > > done and including Modules.gmk is completely fine. Any > > > > > -.gmk file certainly qualifies here. > > > > OK. Updated: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ > > > > > > > > Thanks, > > > > Severin > > > > > > > > > /Erik > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > > Otherwise build changes look ok. > > > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > On 2019-02-07 09:09, Severin Gehwolf wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Could I please get reviews for this enhancement? It adds a > > > > > > > > debug > > > > > > > > symbols stripping plug-in to jlink for Linux and Unix > > > > > > > > platforms. It's > > > > > > > > the first platform specific jlink plugin and the approach taken > > > > > > > > for > > > > > > > > keeping it contained is to use a plugin specific > > > > > > > > ResourceBundle. > > > > > > > > Discussion for this happened in [1]. > > > > > > > > > > > > > > > > The test uses a native library which should never get debug > > > > > > > > symbols > > > > > > > > stripped during the test library build. As such, tiny > > > > > > > > modifications > > > > > > > > were needed to make/common/TestFilesCompilation.gmk. Hence, > > > > > > > > build-dev > > > > > > > > being on the list for this RFR. The test currently only runs on > > > > > > > > Linux > > > > > > > > and requires objcopy to be available. Otherwise the test is > > > > > > > > being > > > > > > > > skipped. > > > > > > > > > > > > > > > > Example usage of this plugin is described in the bug. > > > > > > > > > > > > > > > > webrev: > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > > > > > > > > > > > > > > > Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on > > > > > > > > Linux > > > > > > > > x86_64 (with good and broken objcopy) and the newly added test. > > > > > > > > It's > > > > > > > > currently running through jdk/submit too. > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Severin > > > > > > > > > > > > > > > > [1] > > > > > > > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html > > > > > > > > From erik.joelsson at oracle.com Tue Feb 12 17:10:23 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Feb 2019 09:10:23 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <10369b87099fa48f796161ac5bc1cb08dc6f5cc5.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> <10369b87099fa48f796161ac5bc1cb08dc6f5cc5.camel@redhat.com> Message-ID: <17f599cc-22d8-6dd2-e187-b8e03da4eda3@oracle.com> Hello, On 2019-02-12 09:05, Severin Gehwolf wrote: > Hi Erik, > > On Tue, 2019-02-12 at 08:44 -0800, Erik Joelsson wrote: >> On 2019-02-12 01:35, Severin Gehwolf wrote: >>> Hi Erik, >>> >>> On Mon, 2019-02-11 at 11:12 -0800, Erik Joelsson wrote: >>>> Hello Severin, >>>> >>>> I think you also need a $(wildcard ) around it, but I may be wrong. Did >>>> you try this version? >>> Yes, this version works for me without $(wildcard). Why is it needed? >> I had to go back and check again to verify, but now I'm sure. The list >> of directories returned by FindModuleSrcDirs is all src dirs for the >> module. Not all of them are going to contain the specific directory >> jdk/tools/jlink/resources. This means SetupCompileProperties will get >> called with a few non existing directories. While this will work fine, >> the find implementation on some platforms will complain (Macos in >> particular), so to avoid introducing confusing warning messages in the >> build, it's better to filter down the list of directories to those that >> actually exist. > OK, thanks for the explanation. I suppose $(wildcard ...) does that, > then? I've added it back locally but I have no way of testing whether > this makes any difference, except jdk/submit perhaps? Yes, that is what wildcard does, it filters out any non existing dirs. No need for you to verify anything but that it works as far as I am concerned. I'm happy with the below. /Erik > diff --git a/make/gensrc/Gensrc-jdk.jlink.gmk b/make/gensrc/Gensrc-jdk.jlink.gmk > --- a/make/gensrc/Gensrc-jdk.jlink.gmk > +++ b/make/gensrc/Gensrc-jdk.jlink.gmk > @@ -29,8 +29,9 @@ > > ################################################################################ > > -JLINK_RESOURCES_DIRS := $(addsuffix /jdk/tools/jlink/resources, \ > - $(call FindModuleSrcDirs, jdk.jlink)) > +# Use wildcard so as to avoid getting non-existing directories back > +JLINK_RESOURCES_DIRS := $(wildcard $(addsuffix /jdk/tools/jlink/resources, \ > + $(call FindModuleSrcDirs, jdk.jlink))) > > $(eval $(call SetupCompileProperties, JLINK_PROPERTIES, \ > SRC_DIRS := $(JLINK_RESOURCES_DIRS), \ > > Thanks, > Severin > >>>> Also, please do not indent so much. We have style guidelines [1], which >>>> recommend 4 spaces for line break indentation. >>> OK, sorry. Fixed locally. >> Thanks! >> >> /Erik >> >>> Thanks, >>> Severin >>> >>>> /Erik >>>> >>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>>> >>>> On 2019-02-11 10:03, Severin Gehwolf wrote: >>>>> Hi Erik, >>>>> >>>>> On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: >>>>>> On 2019-02-07 11:09, Severin Gehwolf wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: >>>>>>>> Hello Severin, >>>>>>>> >>>>>>>> There is a macro for automatically finding all source dirs for a module. >>>>>>>> So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using >>>>>>>> that macro, like this: >>>>>>>> >>>>>>>> JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix >>>>>>>> /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) >>>>>>>> >>>>>>>> The above could/should even be inlined. >>>>>>> I've considered this. It seems, though, that FindModuleSrcDirs comes >>>>>>> from make/common/Modules.gmk which isn't included in >>>>>>> make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused >>>>>>> problems with multiple includes of Modules.gmk (JDK-8213736) I was >>>>>>> reluctant to include it here too. Without the new include the above >>>>>>> won't work. >>>>>>> >>>>>>> The approach I've taken here seems to be the lesser evil. Thoughts? >>>>>> I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, >>>>>> which is part of where Modules.gmk gets bootstrapped. In any normal >>>>>> makefile (as in where stuff is just being built), the bootstrapping is >>>>>> done and including Modules.gmk is completely fine. Any >>>>>> -.gmk file certainly qualifies here. >>>>> OK. Updated: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>>> /Erik >>>>>> >>>>>>> Thanks, >>>>>>> Severin >>>>>>> >>>>>>>> Otherwise build changes look ok. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> On 2019-02-07 09:09, Severin Gehwolf wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Could I please get reviews for this enhancement? It adds a >>>>>>>>> debug >>>>>>>>> symbols stripping plug-in to jlink for Linux and Unix >>>>>>>>> platforms. It's >>>>>>>>> the first platform specific jlink plugin and the approach taken >>>>>>>>> for >>>>>>>>> keeping it contained is to use a plugin specific >>>>>>>>> ResourceBundle. >>>>>>>>> Discussion for this happened in [1]. >>>>>>>>> >>>>>>>>> The test uses a native library which should never get debug >>>>>>>>> symbols >>>>>>>>> stripped during the test library build. As such, tiny >>>>>>>>> modifications >>>>>>>>> were needed to make/common/TestFilesCompilation.gmk. Hence, >>>>>>>>> build-dev >>>>>>>>> being on the list for this RFR. The test currently only runs on >>>>>>>>> Linux >>>>>>>>> and requires objcopy to be available. Otherwise the test is >>>>>>>>> being >>>>>>>>> skipped. >>>>>>>>> >>>>>>>>> Example usage of this plugin is described in the bug. >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 >>>>>>>>> >>>>>>>>> Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on >>>>>>>>> Linux >>>>>>>>> x86_64 (with good and broken objcopy) and the newly added test. >>>>>>>>> It's >>>>>>>>> currently running through jdk/submit too. >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Severin >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html >>>>>>>>> From sgehwolf at redhat.com Tue Feb 12 19:52:36 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Feb 2019 20:52:36 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: Hi Mandy, Alan, Please find the proposal for CLI option of --strip-native-debug-symbols below. On Fri, 2019-02-08 at 10:53 -0800, Mandy Chung wrote: > > On 2/8/19 2:08 AM, Alan Bateman wrote: > > I agree with Mandy that the CLI options need examination. The proposed > > `--strip-native-debug-symbols` seems reasonable but it will be > > inconsistent with the existing `--strip-debug` option. Mandy - what you > > would think about renaming the existing option to something that makes > > it clear that it strips the debug attribute from class files? (we would > > of course need to do something to keep the existing option working). > > Renaming it to make it clear is good. How about: > > --strip-debug-attribute > --strip-native-debug-symbols > > --strip-debug will invoke both --strip-debug-attribute and > --strip-native-debug-symbols, if supported. > > Typically we want to strip both. If only stripping debug attribute, > then it can use --strip-debug-attribute. > > What do you think? > > > The need to specify the argument as "defaults" or "options" is a bit > > annoying. It might be time to replace hasArguments in the plugin > interface to allow for optional arguments. > > Hmm... I thought it allows optional arguments. LegalNoticeFilePlugin > accepts an optional argument. > > On the other hand, pluginToMaps will put an empty map if hasArguments > return false. The plugin processing code (PluginsHelper) is quite > complicated that I can't quite tell without spending time. > > In any case I think a plugin should support optional arguments. > > > The plugin interface is not > > exported/documented/supported so we have flexibility to change it. If we > > do this then it should mean the usages reduce down to: > > > > --strip-native-debug-symbols > > --strip-native-debug-symbols objcopy=:... > > objcopy is fine. > > It would also be nice to allow `keep-debuginfo` taking an optional > file extension. > > --strip-native-debug-symbols keep-debuginfo > --strip-native-debug-symbols keep-debuginfo=dbg The current implementation here has the following options: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ [i] --strip-native-debug-symbols defaults [ii] --strip-native-debug-symbols options:objcopy-cmd= [iii] --strip-native-debug-symbols options:debuginfo-file-ext= [iv] --strip-native-debug-symbols options:include-debug-syms=true The first option is a work-around for JDK-8218761. AFAIUI, fixing it will need rework of the Plugin interface and probably of the options parsing. Hence, I'd like to defer this post integration of the initial version of --strip-native-debug-symbols plugin. Cases [iii] and [iv] can be folded into one as suggested by Mandy with: --strip-native-debug-symbols keep-debuginfo --strip-native-debug-symbols keep-debuginfo= Case [ii] would become: --strip-native-debug-symbols objcopy= So in summary I'd propose these, where a) and b) may be combined, c) and a) or c) and b) combined would be an error: [a] --strip-native-debug-symbols keep-debuginfo[=] [b] --strip-native-debug-symbols objcopy= [c] --strip-native-debug-symbols defaults As a follow-up to an initial implementation of the above, I'd propose to hook it up with the current --strip-debug by a follow-up patch. It would first rename --strip-debug to --strip-debug-attribute or perhaps --strip-java-debug-symbols, and then let --strip-debug perform java and native debug symbols stripping as Alan suggested. Does that sound reasonable to you? Thanks, Severin From sgehwolf at redhat.com Tue Feb 12 20:05:55 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Feb 2019 21:05:55 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: Hi Mandy, Thanks for the review! On Thu, 2019-02-07 at 12:43 -0800, Mandy Chung wrote: > Hi Severin, > > Using the plugin specific ResourceBundle is good. Thanks for making > the change. > > I see that Alan's comment [1] on the plugin options and I assume > you will investigate the plugin options and bring back a proposal. > Did I miss the discussion on these options? > > Option: > --strip-native-debug-symbols=][:debuginfo-file-ext=][:include-debug-syms=true]> > > Examples: --strip-native-debug-symbols=defaults > > I suggest the above be simplified and drop the "=defaults". Simply: > --strip-native-debug-symbols > > Examples: > --strip-native-debug-symbols=options:objcopy-cmd=/usr/bin/objcopy:debuginfo-file-ext=dbg:include-debug-syms=true > > > If include-debug-syms=true then it will run > objcopy --only-keep-debug foo foo. to create debug symbols file > objcopy --add-gnu-debuglink=foo.dbg foo > > So what about simplifying the options to: > > --strip-native-debug-symbols=keep-debug-symbols=dbg,objcopy-path=/usr/bin/objcopy > > We could also drop the word "symbols": > > > --strip-native-debug=[keep-debug=,][objcopy-path=] > > By default, `--strip-native-debug` will strip native debug symbols > and don't keep debug symbols. > > keep-debug= creates the debug symbols file. > specifies the file extension. It would be > nice to use the default `debuginfo` extension and simply > accept `keep-debug` option. > > `objcopy-cmd` may be okay too. Others may have opinion. > > I think we should agree on the plugin options first before > doing the code review. OK. Here is the summary: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-February/014132.html Personally, I find --strip-native-debug-info or --strip-native-debug- symbols clearer than just --strip-native-debug. > > W.r.t. the test: > > > The test currently only runs on Linux > > and requires objcopy to be available. Otherwise the test is being > > skipped. > > We can create a fake objcopy utility for testing purpose > such that the test will validate if the options are passed > properly to the test utility. AFAIK, objcopy is a build requirement for OpenJDK already, so I'm wondering whether it makes sense to stub objcopy for the tests. Perhaps you meant that to be used in addition to existing tests? Anyhow, I'll look into it. It'll likely have to use the '--strip- native-debug-symbols objcopy= > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > I haven't reviewed the new files. Just notice that very long > lines in the new files that you may want to fix the formatting > that will help further side-by-side review. Some of the longer lines have been cleaned up in the lates webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ > The --list-plugin output is very very long. The existing plugins > didn't set a good example to keep the well formatted (I recorded > that they were cleaned up at one point to keep 80 chars width). Right. I'll make sure --list-plugins looks right for --strip-native- debug-symbols once we've agreed on the options. > One other question: should this plugin be moved to linux/classes > rather than unix/classes given that that's the platform it > intends to support? Done in version 05. Thanks, Severin > Mandy > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014099.html From mandy.chung at oracle.com Tue Feb 12 22:27:20 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Feb 2019 14:27:20 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: On 2/12/19 12:05 PM, Severin Gehwolf wrote: > Hi Mandy, > > Thanks for the review! > > OK. Here is the summary: > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-February/014132.html > > Personally, I find --strip-native-debug-info or --strip-native-debug- > symbols clearer than just --strip-native-debug. Fine with me and we can stick with --strip-native-debug-symbols >> W.r.t. the test: >> >> > The test currently only runs on Linux >> > and requires objcopy to be available. Otherwise the test is being >> > skipped. >> >> We can create a fake objcopy utility for testing purpose >> such that the test will validate if the options are passed >> properly to the test utility. > > AFAIK, objcopy is a build requirement for OpenJDK already, so I'm > wondering whether it makes sense to stub objcopy for the tests. Perhaps > you meant that to be used in addition to existing tests? Test machines may not have objcopy. It'd increase the test coverage to include a test that can run on all test machines. Yes it's an additional test in addition to a test you have that only runs if objcopy utility is present. > Anyhow, I'll look into it. It'll likely have to use the '--strip- > native-debug-symbols objcopy= case. What I was thinking is: --strip-native-debug-symbols objcopy="java fakeobjcopy" where objcopy accepts a command that can contain arguments. It'll have to be some native code which will require some custom > make machinery to get compiled, no? If you have pointers to examples in > the JDK already, I'd appreciate it. See the idea above. >> > webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ >> >> I haven't reviewed the new files. Just notice that very long >> lines in the new files that you may want to fix the formatting >> that will help further side-by-side review. > > Some of the longer lines have been cleaned up in the lates webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ > >> The --list-plugin output is very very long. The existing plugins >> didn't set a good example to keep the well formatted (I recorded >> that they were cleaned up at one point to keep 80 chars width). > > Right. I'll make sure --list-plugins looks right for --strip-native- > debug-symbols once we've agreed on the options. > >> One other question: should this plugin be moved to linux/classes >> rather than unix/classes given that that's the platform it >> intends to support? > > Done in version 05. Thanks for making the change. I will reply the other thread. Mandy From mandy.chung at oracle.com Tue Feb 12 23:29:28 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Feb 2019 15:29:28 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: On 2/12/19 11:52 AM, Severin Gehwolf wrote: > Hi Mandy, Alan, > > Please find the proposal for CLI option of --strip-native-debug-symbols > below. > > The current implementation here has the following options: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ > > [i] --strip-native-debug-symbols defaults > [ii] --strip-native-debug-symbols options:objcopy-cmd= > [iii] --strip-native-debug-symbols options:debuginfo-file-ext= > [iv] --strip-native-debug-symbols options:include-debug-syms=true > > The first option is a work-around for JDK-8218761. AFAIUI, fixing it > will need rework of the Plugin interface and probably of the options > parsing. Hence, I'd like to defer this post integration of the initial > version of --strip-native-debug-symbols plugin. > > Cases [iii] and [iv] can be folded into one as suggested by Mandy with: > > --strip-native-debug-symbols keep-debuginfo > --strip-native-debug-symbols keep-debuginfo= > > Case [ii] would become: > > --strip-native-debug-symbols objcopy= we could relax this to a command that can contain arguments. > So in summary I'd propose these, where a) and b) may be combined, c) > and a) or c) and b) combined would be an error: > > [a] --strip-native-debug-symbols keep-debuginfo[=] > [b] --strip-native-debug-symbols objcopy= > [c] --strip-native-debug-symbols defaults This is a good compromise. When JDK-8218761 is implemented, [c] can become `--strip-native-debug-symbols` "defaults" is unclear to what it does. What about --strip-native-debug-symbols no-keep-debuginfo > As a follow-up to an initial implementation of the above, I'd propose > to hook it up with the current --strip-debug by a follow-up patch. It > would first rename --strip-debug to --strip-debug-attribute or perhaps > --strip-java-debug-symbols, and then let --strip-debug perform java and > native debug symbols stripping as Alan suggested. The renaming can be done separately. I would prefer changing --strip-debug to invoke --strip-native-debug-symbols, if present, at the same time with this new strip native debug symbols plugin to ensure that they all go in the same release. In other words, the renaming should be done before this new plugin. That's my opinion. Mandy > Does that sound reasonable to you? > > Thanks, > Severin > From sgehwolf at redhat.com Wed Feb 13 09:04:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 13 Feb 2019 10:04:29 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: On Tue, 2019-02-12 at 15:29 -0800, Mandy Chung wrote: > > On 2/12/19 11:52 AM, Severin Gehwolf wrote: > > Hi Mandy, Alan, > > > > Please find the proposal for CLI option of --strip-native-debug-symbols > > below. > > > > The current implementation here has the following options: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ > > > > [i] --strip-native-debug-symbols defaults > > [ii] --strip-native-debug-symbols options:objcopy-cmd= > > [iii] --strip-native-debug-symbols options:debuginfo-file-ext= > > [iv] --strip-native-debug-symbols options:include-debug-syms=true > > > > The first option is a work-around for JDK-8218761. AFAIUI, fixing it > > will need rework of the Plugin interface and probably of the options > > parsing. Hence, I'd like to defer this post integration of the initial > > version of --strip-native-debug-symbols plugin. > > > > Cases [iii] and [iv] can be folded into one as suggested by Mandy with: > > > > --strip-native-debug-symbols keep-debuginfo > > --strip-native-debug-symbols keep-debuginfo= > > > > Case [ii] would become: > > > > --strip-native-debug-symbols objcopy= > > we could relax this to a command that can contain arguments. OK. I'll explore that. > > So in summary I'd propose these, where a) and b) may be combined, c) > > and a) or c) and b) combined would be an error: > > > > [a] --strip-native-debug-symbols keep-debuginfo[=] > > [b] --strip-native-debug-symbols objcopy= > > [c] --strip-native-debug-symbols defaults > > This is a good compromise. When JDK-8218761 is implemented, > [c] can become `--strip-native-debug-symbols` > > "defaults" is unclear to what it does. What about > --strip-native-debug-symbols no-keep-debuginfo Makes sense. How about this? --strip-native-debug-symbols strip-debuginfo or --strip-native-debug-symbols remove-debuginfo It would avoid using negation. > > As a follow-up to an initial implementation of the above, I'd propose > > to hook it up with the current --strip-debug by a follow-up patch. It > > would first rename --strip-debug to --strip-debug-attribute or perhaps > > --strip-java-debug-symbols, and then let --strip-debug perform java and > > native debug symbols stripping as Alan suggested. > > The renaming can be done separately. I would prefer changing > --strip-debug to invoke --strip-native-debug-symbols, if present, > at the same time with this new strip native debug symbols plugin > to ensure that they all go in the same release. > > In other words, the renaming should be done before this new plugin. > That's my opinion. Sure. I've filed JDK-8218913 for doing this first. Would a name of -- strip-java-debug-symbols be acceptable? My thinking is that it would have nice symmetry with --strip-native-debug-symbols. Thoughts? Thanks, Severin > Mandy > > > Does that sound reasonable to you? > > > > Thanks, > > Severin > > From mandy.chung at oracle.com Wed Feb 13 23:36:32 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Feb 2019 15:36:32 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: On 2/13/19 1:04 AM, Severin Gehwolf wrote: >> --strip-native-debug-symbols no-keep-debuginfo > --strip-native-debug-symbols strip-debuginfo > --strip-native-debug-symbols remove-debuginfo > > It would avoid using negation. What about 'omit', i.e. --strip-native-debug-symbols omit-debuginfo --strip-native-debug-symbols keep-debuginfo= > Sure. I've filed JDK-8218913 for doing this first. Would a name of -- > strip-java-debug-symbols be acceptable? My thinking is that it would > have nice symmetry with --strip-native-debug-symbols. Thoughts? --strip-native-debug-symbols is okay. Having a second thought, javac -g and gcc -g both say "debugging information". I think we could go with: --strip-java-debug-info --strip-native-debug-info omit-debuginfo --strip-native-debug-info keep-debuginfo= unless anyone thinks `-debug-symbols` is better? The options are getting pretty good now. Mandy From sgehwolf at redhat.com Thu Feb 14 08:27:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Feb 2019 09:27:12 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: <529c7a3d7e6095e213498150cb5fbb50e2342f36.camel@redhat.com> On Wed, 2019-02-13 at 15:36 -0800, Mandy Chung wrote: > On 2/13/19 1:04 AM, Severin Gehwolf wrote: > > > --strip-native-debug-symbols no-keep-debuginfo > > --strip-native-debug-symbols strip-debuginfo > > --strip-native-debug-symbols remove-debuginfo > > > > It would avoid using negation. > > What about 'omit', i.e. > > --strip-native-debug-symbols omit-debuginfo > --strip-native-debug-symbols keep-debuginfo= I like it. Good for me. > > Sure. I've filed JDK-8218913 for doing this first. Would a name of -- > > strip-java-debug-symbols be acceptable? My thinking is that it would > > have nice symmetry with --strip-native-debug-symbols. Thoughts? > > --strip-native-debug-symbols is okay. > > Having a second thought, javac -g and gcc -g both say "debugging > information". I think we could go with: > > --strip-java-debug-info > --strip-native-debug-info omit-debuginfo > --strip-native-debug-info keep-debuginfo= > > unless anyone thinks `-debug-symbols` is better? > > The options are getting pretty good now. +1. debug-info over debug-symbols is good for me. Thanks, Severin From matthias.baesken at sap.com Thu Feb 14 14:44:01 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 14 Feb 2019 14:44:01 +0000 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection Message-ID: Hello, please review this small change . On AIX, it adds detection of xlc16 / clang to the build environment. The xlc16 package contains 2 compiler frontends : * The legacy xlc * The new clang-based xlclang++ For older xlc (12 / 13) we should for now still support the "legacy" xlc . For xlc16 the usage of xlclang++ is desired , because it promises better C++11/14 support (important for the coming JEPs dealing with C++11/14 features) . Additionally to the compiler detection , the debug-flag is changed to -g1 when xlclang++ is used (because of issues with -g) ; thanks to Steven for providing the info. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8218965 http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.0/ Thanks, Matthias From erik.joelsson at oracle.com Thu Feb 14 23:26:20 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Feb 2019 15:26:20 -0800 Subject: RFR: JDK-8217032: Check pandoc capabilities in configure Message-ID: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> Please review this minor fix. The JDK build now has support for generating man pages, and will try to do so if it finds pandoc on the system. Unfortunately, not all versions of pandoc are valid, and if a bad version is found, the build will fail. This patch adds an extensions check for the found pandoc in configure, and if the "smart" extension that we use is missing, pandoc is disabled. Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ /Erik From mikael.vidstedt at oracle.com Thu Feb 14 23:29:37 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 14 Feb 2019 15:29:37 -0800 Subject: RFR: JDK-8217032: Check pandoc capabilities in configure In-Reply-To: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> References: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> Message-ID: <40813F85-7868-45D1-9456-1A13B2283C7D@oracle.com> Looks good. Cheers, Mikael > On Feb 14, 2019, at 3:26 PM, Erik Joelsson wrote: > > Please review this minor fix. The JDK build now has support for generating man pages, and will try to do so if it finds pandoc on the system. Unfortunately, not all versions of pandoc are valid, and if a bad version is found, the build will fail. This patch adds an extensions check for the found pandoc in configure, and if the "smart" extension that we use is missing, pandoc is disabled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 > > Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ > > /Erik > From philip.race at oracle.com Thu Feb 14 23:32:37 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 14 Feb 2019 15:32:37 -0800 Subject: RFR: JDK-8217032: Check pandoc capabilities in configure In-Reply-To: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> References: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> Message-ID: <82c249b0-8743-74f6-33ef-2f8bb03462eb@oracle.com> Looks fine. I'll be happy to have this fix ! -phil. On 2/14/2019 3:26 PM, Erik Joelsson wrote: > Please review this minor fix. The JDK build now has support for > generating man pages, and will try to do so if it finds pandoc on the > system. Unfortunately, not all versions of pandoc are valid, and if a > bad version is found, the build will fail. This patch adds an > extensions check for the found pandoc in configure, and if the "smart" > extension that we use is missing, pandoc is disabled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 > > Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ > > /Erik > From alexander.matveev at oracle.com Fri Feb 15 03:31:03 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 14 Feb 2019 19:31:03 -0800 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files Message-ID: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Moved native code under platform specific folder. - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp for Mac specific code to filter out some arguments. I decided to keep it as is for now, since Mac specific code is small. - Defines are used in Platform.cpp to initialize platform specific classes. - Removed all pragma warning and fixed all compilation warnings. - Removed unused code. [1] https://bugs.openjdk.java.net/browse/JDK-8212091 [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ Thanks, Alexander From magnus.ihse.bursie at oracle.com Fri Feb 15 07:34:33 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Feb 2019 08:34:33 +0100 Subject: RFR: JDK-8217032: Check pandoc capabilities in configure In-Reply-To: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> References: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> Message-ID: <7aee0988-a4c7-c977-037b-2bd375518fb4@oracle.com> On 2019-02-15 00:26, Erik Joelsson wrote: > Please review this minor fix. The JDK build now has support for > generating man pages, and will try to do so if it finds pandoc on the > system. Unfortunately, not all versions of pandoc are valid, and if a > bad version is found, the build will fail. This patch adds an > extensions check for the found pandoc in configure, and if the "smart" > extension that we use is missing, pandoc is disabled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 > > Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ Actually, the problem is slightly more subtle. :( We're not using the "smart" extension, we're disabling it. If the pandoc we discover does not have the smart extension, we should instead use to output format "markdown" instead of "markdown-smart". This is what we used before, and it worked all well, until I updated the version of markdown used by jib, and it started doing "smart" (actually: dumb) quoting, and I had to disable it. Since the version of pandoc commonly installed by Ubuntu (and maybe other distros as well) is old enough to not contain the smart extension, I don't think it's good to disable it -- after all, it works just perfectly; but we should adjust the "flags" to markdown in that case. /Magnus > > /Erik > From magnus.ihse.bursie at oracle.com Fri Feb 15 07:44:16 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Feb 2019 08:44:16 +0100 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> Message-ID: <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> On 2019-02-15 04:31, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Moved native code under platform specific folder. > - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. > - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp > for Mac specific code to filter out some arguments. I decided to keep > it as is for now, since Mac specific code is small. > - Defines are used in Platform.cpp to initialize platform specific > classes. > - Removed all pragma warning and fixed all compilation warnings. > - Removed unused code. > > [1] https://bugs.openjdk.java.net/browse/JDK-8212091 > > [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ The JDK standard is to use "unix", not "posix", for the shared functionality between linux/solaris/macosx. You can keep the name "PosixPlatform.*" if you want, though; the important thing is the directory name. Also, if you do that, you do not need any changes to make/lib/Lib-jdk.jpackage.gmk, since that will be automatically understood by the build system. It looks from the webrev that you have "moved" the files by doing "hg add" and "hg remove". Please use "hg move" instead -- this will keep history intact, and it allows reviewers to see if you have also made changes to the moved files. (If you do have modified the moved file, reverting a "hg add+hg remove" process is a bit more tricky -- you need to do "hg forget" on the new file, rename it to something else (otherwise "hg move" will complain), "hg revert" the old file back in place, do a "hg move" from the old to the new, and then copy the modified, renamed file back over the target new file again.) /Magnus > > Thanks, > Alexander From magnus.ihse.bursie at oracle.com Fri Feb 15 07:56:16 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Feb 2019 08:56:16 +0100 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: References: Message-ID: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> On 2019-02-14 15:44, Baesken, Matthias wrote: > Hello, > > please review this small change . > > On AIX, it adds detection of xlc16 / clang to the build environment. > > The xlc16 package contains 2 compiler frontends : > > > * The legacy xlc > * The new clang-based xlclang++ > > For older xlc (12 / 13) we should for now still support the "legacy" xlc . > For xlc16 the usage of xlclang++ is desired , because it promises better C++11/14 support (important for the coming JEPs dealing with C++11/14 features) . > > Additionally to the compiler detection , the debug-flag is changed to -g1 when xlclang++ is used (because of issues with -g) ; thanks to Steven for providing the info. > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8218965 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.0/ Hi Matthias, I have several doubts about this patch. Let me start at the highest level before dwelling on details. Is this really the right way to handle this? Maybe we should either treat xlclang as a new, separate toolchain, or we should treat xlclang as a variant of the clang toolchain. If xlclang is very similar to clang (same compilation behavior, same compiler flags), then I believe the latter way is the proper way forward. If xlclang is -- even though the change of frontend -- mostly similar to the traditional xlc, then the path chosen by you might be the best way forward after all. If xlclang is different enought from both the traditional xlc, and from clang, we might want to treat it like an entirely new toolchain. We can of course share code with the existing xlc and clang toolchains. I think this is the best way if e.g. compiler flags are still shared with xlc, but source code defines etc is shared with clang. That way we can test for "xlc or xlclang" when setting up flags, but "clang or xlclang" in the #ifdefs. --- If we should go forward with your patch, please note the following: We try to use "true" and "false" as values for boolean variable, so "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". The test to determine if we're using xlclang seem to happen in the wrong location. It also calls the bare "xlclang++" from the path, without any consideration if the user has specified a toolchain path, etc. I won't go into more details on the patch until we've determined if this is the solution we should pursue. /Magnus > > > > Thanks, Matthias From matthias.baesken at sap.com Fri Feb 15 08:31:22 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 15 Feb 2019 08:31:22 +0000 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> References: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> Message-ID: Hi Magnus , I think it is not a separate toolchain , just another compiler frontend offered by the xlc toolchain of xlc16 . Our current toolchains are : # These toolchains are valid on different platforms VALID_TOOLCHAINS_linux="gcc clang" VALID_TOOLCHAINS_solaris="solstudio" VALID_TOOLCHAINS_macosx="gcc clang" VALID_TOOLCHAINS_aix="xlc" VALID_TOOLCHAINS_windows="microsoft" # Toolchain descriptions TOOLCHAIN_DESCRIPTION_clang="clang/LLVM" TOOLCHAIN_DESCRIPTION_gcc="GNU Compiler Collection" TOOLCHAIN_DESCRIPTION_microsoft="Microsoft Visual Studio" TOOLCHAIN_DESCRIPTION_solstudio="Oracle Solaris Studio" TOOLCHAIN_DESCRIPTION_xlc="IBM XL C/C++" XLC16 /xlclang++ identifies itself as : xlclang++ -qversion IBM XL C/C++ for AIX, V16.1.0 In the long run , with JEP 347: Adopt C++14 Language Features in HotSpot , the legacy XlC_r will most likely not be usable any more to build the HS codebase . Then we must go to another compiler , and xlclang++ is the choice I think . (other option is to discontinue the AIX support in OpenJDK, or strip down JEP 347 to some C++ 11 features supported by the legacy XlC_r ). So then we do not really need such a detection any more and have to go for the usable tool . > > We try to use "true" and "false" as values for boolean variable, so > "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". > Good point. > > The test to determine if we're using xlclang seem to happen in the wrong > location. It also calls the bare "xlclang++" from the path, without any > consideration if the user has specified a toolchain path, etc. > I think this is how it is currently done on AIX for years, you just put xlc in the PATH and then let configure find it there. However you are right on this one , toolchain path settings should be supported ( not sure whether they currently work or not). In our AIX envs they are not of much use, because we have ***one*** xlc per machine ( I am not even sure if it is 100% supported to have multiple xlc in parallel on one machine, guess it somehow works but is not officially recommended ). > > I won't go into more details on the patch until we've determined if this > is the solution we should pursue. > There is no need to rush the patch in , for now the legacy xlc_r still works ( until the C++11/14 features show up ) . Best regards, Matthias > > please review this small change . > > > > On AIX, it adds detection of xlc16 / clang to the build environment. > > > > The xlc16 package contains 2 compiler frontends : > > > > > > * The legacy xlc > > * The new clang-based xlclang++ > > > > For older xlc (12 / 13) we should for now still support the "legacy" xlc . > > For xlc16 the usage of xlclang++ is desired , because it promises > better C++11/14 support (important for the coming JEPs dealing with > C++11/14 features) . > > > > Additionally to the compiler detection , the debug-flag is changed to -g1 > when xlclang++ is used (because of issues with -g) ; thanks to Steven for > providing the info. > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8218965 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.0/ > Hi Matthias, > > I have several doubts about this patch. > > Let me start at the highest level before dwelling on details. > > Is this really the right way to handle this? Maybe we should either > treat xlclang as a new, separate toolchain, or we should treat xlclang > as a variant of the clang toolchain. > > If xlclang is very similar to clang (same compilation behavior, same > compiler flags), then I believe the latter way is the proper way forward. > > If xlclang is -- even though the change of frontend -- mostly similar to > the traditional xlc, then the path chosen by you might be the best way > forward after all. > > If xlclang is different enought from both the traditional xlc, and from > clang, we might want to treat it like an entirely new toolchain. We can > of course share code with the existing xlc and clang toolchains. I think > this is the best way if e.g. compiler flags are still shared with xlc, > but source code defines etc is shared with clang. That way we can test > for "xlc or xlclang" when setting up flags, but "clang or xlclang" in > the #ifdefs. > > --- > > If we should go forward with your patch, please note the following: > > We try to use "true" and "false" as values for boolean variable, so > "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". > > The test to determine if we're using xlclang seem to happen in the wrong > location. It also calls the bare "xlclang++" from the path, without any > consideration if the user has specified a toolchain path, etc. > > I won't go into more details on the patch until we've determined if this > is the solution we should pursue. > > /Magnus > > > > > > > > Thanks, Matthias From magnus.ihse.bursie at oracle.com Fri Feb 15 11:05:08 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Feb 2019 12:05:08 +0100 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: <29c6de1c-a756-d03c-358f-cd1d82b3ad94@oracle.com> References: <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> <294f30aa-fef4-3c6c-302d-77a1bc7d1547@oracle.com> <29c6de1c-a756-d03c-358f-cd1d82b3ad94@oracle.com> Message-ID: On 2019-02-12 15:42, Alexey Ivanov wrote: > On 12/02/2019 14:37, Magnus Ihse Bursie wrote: >> There has been some fallout due to the mapfile/linking changes made >> in JDK 12 that affected JNICALL. However, that should not be >> affecting JDK 11. > Wasn't it done in JDK 11? > If my memory serves me right, it was done in JDK 11. You are correct. The major part of the mapfile removal was done in JDK-8200358, which was pushed to JDK 11. There were follow up issues going on all the way into JDK 12, though. Anyway, I've now looked more into this issue. And this time map files were not really to blame, but JNICALL still is. First of all, it's important to note that this only shows up when compiling a debug build. As a workaround, building a normal release build for 32-bit Windows will not trigger this issue. (This is likely how it has gotten unnoticed.) To Franco: that means removing "--enable-debug" from your configure line. There core problem seems indeed to be discrepancy whether a function is declared JNICALL or not. In JDK-8214120, DTrace_VPrintln() & co. got JNICALL added in src/java.desktop/share/native/common/awt/debug/debug_trace.c and debug_trace.h. However, the typedef DTRACE_PRINT_CALLBACK was not updated. Since JNICALL is a no-op on all platforms except Windows 32, this was not discovered. However, according to JBS JDK-8214120 was fixed in JDK-12. So why this is causing issues in JDK-11, I don't understand. Or maybe the discussion drifted from testing JDK 11 to testing JDK 12? In any case, it is likely currently broken in JDK 13. Here is a suggested patch. Hopefully I got the JNICALL modifier in the correct place (C function pointer typedefs are the worst!). diff --git a/src/java.desktop/share/native/common/awt/debug/debug_trace.h b/src/java.desktop/share/native/common/awt/debug/debug_trace.h --- a/src/java.desktop/share/native/common/awt/debug/debug_trace.h +++ b/src/java.desktop/share/native/common/awt/debug/debug_trace.h @@ -48,7 +48,7 @@ ?typedef void (*DTRACE_OUTPUT_CALLBACK)(const char * msg); ?/* prototype for client provided print callback function */ -typedef void (*DTRACE_PRINT_CALLBACK)(const char * file, int line, int argc, const char * fmt, va_list arglist); +typedef void (JNICALL *DTRACE_PRINT_CALLBACK)(const char * file, int line, int argc, const char * fmt, va_list arglist); ?extern void DTrace_EnableAll(dbool_t enabled); ?extern void DTrace_EnableFile(const char * file, dbool_t enabled); Please test and let me know if it works. If so it should be pushed to JDK 13, and possibly backported. /Magnus From magnus.ihse.bursie at oracle.com Fri Feb 15 11:37:16 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Feb 2019 12:37:16 +0100 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: References: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> Message-ID: <8a9cf0ba-6641-6a80-caeb-e42abf64ad61@oracle.com> On 2019-02-15 09:31, Baesken, Matthias wrote: > Hi Magnus , I think it is not a separate toolchain , just another compiler frontend offered by the xlc toolchain of xlc16 . So will this distinction between xlc and xlclang be needed elsewhere? Or is it just the -g flag? I was worried that this was just the start of a flood of changes related to xlc vs xlclang, but maybe this is all that is needed? If so, could the choice between -g ang -g1 be handled with the normal TOOLCHAIN_CHECK_COMPILER_VERSION? /Magnus > Our current toolchains are : > > # These toolchains are valid on different platforms > VALID_TOOLCHAINS_linux="gcc clang" > VALID_TOOLCHAINS_solaris="solstudio" > VALID_TOOLCHAINS_macosx="gcc clang" > VALID_TOOLCHAINS_aix="xlc" > VALID_TOOLCHAINS_windows="microsoft" > > # Toolchain descriptions > TOOLCHAIN_DESCRIPTION_clang="clang/LLVM" > TOOLCHAIN_DESCRIPTION_gcc="GNU Compiler Collection" > TOOLCHAIN_DESCRIPTION_microsoft="Microsoft Visual Studio" > TOOLCHAIN_DESCRIPTION_solstudio="Oracle Solaris Studio" > TOOLCHAIN_DESCRIPTION_xlc="IBM XL C/C++" > > > XLC16 /xlclang++ identifies itself as : > > xlclang++ -qversion > IBM XL C/C++ for AIX, V16.1.0 > > > In the long run , with JEP 347: Adopt C++14 Language Features in HotSpot , the legacy XlC_r will most likely not be usable any more to build the HS codebase . > Then we must go to another compiler , and xlclang++ is the choice I think . > > (other option is to discontinue the AIX support in OpenJDK, or strip down JEP 347 to some C++ 11 features supported by the legacy XlC_r ). > So then we do not really need such a detection any more and have to go for the usable tool . > >> We try to use "true" and "false" as values for boolean variable, so >> "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". >> > Good point. > >> The test to determine if we're using xlclang seem to happen in the wrong >> location. It also calls the bare "xlclang++" from the path, without any >> consideration if the user has specified a toolchain path, etc. >> > I think this is how it is currently done on AIX for years, you just put xlc in the PATH and then let configure find it there. > However you are right on this one , toolchain path settings should be supported ( not sure whether they currently work or not). > In our AIX envs they are not of much use, because we have ***one*** xlc per machine ( I am not even sure if it is 100% supported to have multiple xlc in parallel on one machine, > guess it somehow works but is not officially recommended ). > >> I won't go into more details on the patch until we've determined if this >> is the solution we should pursue. >> > There is no need to rush the patch in , for now the legacy xlc_r still works ( until the C++11/14 features show up ) . > > Best regards, Matthias > > > >>> please review this small change . >>> >>> On AIX, it adds detection of xlc16 / clang to the build environment. >>> >>> The xlc16 package contains 2 compiler frontends : >>> >>> >>> * The legacy xlc >>> * The new clang-based xlclang++ >>> >>> For older xlc (12 / 13) we should for now still support the "legacy" xlc . >>> For xlc16 the usage of xlclang++ is desired , because it promises >> better C++11/14 support (important for the coming JEPs dealing with >> C++11/14 features) . >>> Additionally to the compiler detection , the debug-flag is changed to -g1 >> when xlclang++ is used (because of issues with -g) ; thanks to Steven for >> providing the info. >>> >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8218965 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.0/ >> Hi Matthias, >> >> I have several doubts about this patch. >> >> Let me start at the highest level before dwelling on details. >> >> Is this really the right way to handle this? Maybe we should either >> treat xlclang as a new, separate toolchain, or we should treat xlclang >> as a variant of the clang toolchain. >> >> If xlclang is very similar to clang (same compilation behavior, same >> compiler flags), then I believe the latter way is the proper way forward. >> >> If xlclang is -- even though the change of frontend -- mostly similar to >> the traditional xlc, then the path chosen by you might be the best way >> forward after all. >> >> If xlclang is different enought from both the traditional xlc, and from >> clang, we might want to treat it like an entirely new toolchain. We can >> of course share code with the existing xlc and clang toolchains. I think >> this is the best way if e.g. compiler flags are still shared with xlc, >> but source code defines etc is shared with clang. That way we can test >> for "xlc or xlclang" when setting up flags, but "clang or xlclang" in >> the #ifdefs. >> >> --- >> >> If we should go forward with your patch, please note the following: >> >> We try to use "true" and "false" as values for boolean variable, so >> "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". >> >> The test to determine if we're using xlclang seem to happen in the wrong >> location. It also calls the bare "xlclang++" from the path, without any >> consideration if the user has specified a toolchain path, etc. >> >> I won't go into more details on the patch until we've determined if this >> is the solution we should pursue. >> >> /Magnus >>> >>> >>> Thanks, Matthias From matthias.baesken at sap.com Fri Feb 15 11:53:37 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 15 Feb 2019 11:53:37 +0000 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: <8a9cf0ba-6641-6a80-caeb-e42abf64ad61@oracle.com> References: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> <8a9cf0ba-6641-6a80-caeb-e42abf64ad61@oracle.com> Message-ID: Hi Magnus, we are currently able to build (+ test ? ) jdk/jdk on AIX with the xlclang++ based build . Only needed are this change , plus a one-liner in harfhuzz is needed (we try to get this upstream into harbuzz directly, in case the next harfhuzz update to jdk/jdk is in the mid/far future , I would add this one liner to my patch). So I hope that there will be not so many follow ups (but you never know ). > > If so, could the choice between -g ang -g1 be handled with the normal > TOOLCHAIN_CHECK_COMPILER_VERSION? > I'll look into this . Unfortunately the version output is the same for both frontends : New one: bash-4.4$ xlclang++ -qversion IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) Version: 16.01.0000.0001 Legacy xlc: bash-4.4$ xlC_r -qversion IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) Version: 16.01.0000.0001 (and some-strange-hex-string is the same for both) Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Freitag, 15. Februar 2019 12:37 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection > > On 2019-02-15 09:31, Baesken, Matthias wrote: > > Hi Magnus , I think it is not a separate toolchain , just another compiler > frontend offered by the xlc toolchain of xlc16 . > So will this distinction between xlc and xlclang be needed elsewhere? Or > is it just the -g flag? I was worried that this was just the start of a > flood of changes related to xlc vs xlclang, but maybe this is all that > is needed? > > If so, could the choice between -g ang -g1 be handled with the normal > TOOLCHAIN_CHECK_COMPILER_VERSION? > > /Magnus > > > Our current toolchains are : > > > > # These toolchains are valid on different platforms > > VALID_TOOLCHAINS_linux="gcc clang" > > VALID_TOOLCHAINS_solaris="solstudio" > > VALID_TOOLCHAINS_macosx="gcc clang" > > VALID_TOOLCHAINS_aix="xlc" > > VALID_TOOLCHAINS_windows="microsoft" > > > > # Toolchain descriptions > > TOOLCHAIN_DESCRIPTION_clang="clang/LLVM" > > TOOLCHAIN_DESCRIPTION_gcc="GNU Compiler Collection" > > TOOLCHAIN_DESCRIPTION_microsoft="Microsoft Visual Studio" > > TOOLCHAIN_DESCRIPTION_solstudio="Oracle Solaris Studio" > > TOOLCHAIN_DESCRIPTION_xlc="IBM XL C/C++" > > > > > > XLC16 /xlclang++ identifies itself as : > > > > xlclang++ -qversion > > IBM XL C/C++ for AIX, V16.1.0 > > > > > > In the long run , with JEP 347: Adopt C++14 Language Features in HotSpot > , the legacy XlC_r will most likely not be usable any more to build the HS > codebase . > > Then we must go to another compiler , and xlclang++ is the choice I think . > > > > (other option is to discontinue the AIX support in OpenJDK, or strip > down JEP 347 to some C++ 11 features supported by the legacy XlC_r ). > > So then we do not really need such a detection any more and have to go > for the usable tool . > > > >> We try to use "true" and "false" as values for boolean variable, so > >> "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". > >> > > Good point. > > > >> The test to determine if we're using xlclang seem to happen in the wrong > >> location. It also calls the bare "xlclang++" from the path, without any > >> consideration if the user has specified a toolchain path, etc. > >> > > I think this is how it is currently done on AIX for years, you just put xlc in > the PATH and then let configure find it there. > > However you are right on this one , toolchain path settings should be > supported ( not sure whether they currently work or not). > > In our AIX envs they are not of much use, because we have ***one*** > xlc per machine ( I am not even sure if it is 100% supported to have > multiple xlc in parallel on one machine, > > guess it somehow works but is not officially recommended ). > > > >> I won't go into more details on the patch until we've determined if this > >> is the solution we should pursue. > >> > > There is no need to rush the patch in , for now the legacy xlc_r still works > ( until the C++11/14 features show up ) . > > > > Best regards, Matthias > > > > > > > >>> please review this small change . > >>> > >>> On AIX, it adds detection of xlc16 / clang to the build environment. > >>> > >>> The xlc16 package contains 2 compiler frontends : > >>> > >>> > >>> * The legacy xlc > >>> * The new clang-based xlclang++ > >>> > >>> For older xlc (12 / 13) we should for now still support the "legacy" xlc . > >>> For xlc16 the usage of xlclang++ is desired , because it promises > >> better C++11/14 support (important for the coming JEPs dealing with > >> C++11/14 features) . > >>> Additionally to the compiler detection , the debug-flag is changed to -g1 > >> when xlclang++ is used (because of issues with -g) ; thanks to Steven for > >> providing the info. > >>> > >>> > >>> Bug/webrev : > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8218965 > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.0/ > >> Hi Matthias, > >> > >> I have several doubts about this patch. > >> > >> Let me start at the highest level before dwelling on details. > >> > >> Is this really the right way to handle this? Maybe we should either > >> treat xlclang as a new, separate toolchain, or we should treat xlclang > >> as a variant of the clang toolchain. > >> > >> If xlclang is very similar to clang (same compilation behavior, same > >> compiler flags), then I believe the latter way is the proper way forward. > >> > >> If xlclang is -- even though the change of frontend -- mostly similar to > >> the traditional xlc, then the path chosen by you might be the best way > >> forward after all. > >> > >> If xlclang is different enought from both the traditional xlc, and from > >> clang, we might want to treat it like an entirely new toolchain. We can > >> of course share code with the existing xlc and clang toolchains. I think > >> this is the best way if e.g. compiler flags are still shared with xlc, > >> but source code defines etc is shared with clang. That way we can test > >> for "xlc or xlclang" when setting up flags, but "clang or xlclang" in > >> the #ifdefs. > >> > >> --- > >> > >> If we should go forward with your patch, please note the following: > >> > >> We try to use "true" and "false" as values for boolean variable, so > >> "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". > >> > >> The test to determine if we're using xlclang seem to happen in the wrong > >> location. It also calls the bare "xlclang++" from the path, without any > >> consideration if the user has specified a toolchain path, etc. > >> > >> I won't go into more details on the patch until we've determined if this > >> is the solution we should pursue. > >> > >> /Magnus > >>> > >>> > >>> Thanks, Matthias From magnus.ihse.bursie at oracle.com Fri Feb 15 12:31:37 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Feb 2019 13:31:37 +0100 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: References: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> <8a9cf0ba-6641-6a80-caeb-e42abf64ad61@oracle.com> Message-ID: <97bb3895-269d-dac2-8fc5-7b1480646f99@oracle.com> On 2019-02-15 12:53, Baesken, Matthias wrote: > Hi Magnus, > > we are currently able to build (+ test ? ) jdk/jdk on AIX with the xlclang++ based build . > Only needed are this change , > plus a one-liner in harfhuzz is needed (we try to get this upstream into harbuzz directly, in case the next harfhuzz update to jdk/jdk is in the mid/far future , I would add this one liner to my patch). > > So I hope that there will be not so many follow ups (but you never know ). Ok, that's good to hear. > >> If so, could the choice between -g ang -g1 be handled with the normal >> TOOLCHAIN_CHECK_COMPILER_VERSION? >> > I'll look into this . Unfortunately the version output is the same for both frontends : > > New one: > > bash-4.4$ xlclang++ -qversion > IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) > Version: 16.01.0000.0001 > > Legacy xlc: > > bash-4.4$ xlC_r -qversion > IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) > Version: 16.01.0000.0001 > > > (and some-strange-hex-string is the same for both) Hm. Are they both pointing to the same binary, and the mode of operation (legacy xlc vs xlclang) is determined by the name of the executable? Is xlclang++ always available for version 16+ of xlc? If so, maybe we should just make sure we call the compiler with the correct name if version 16+ is detected? Or is there a way to force xlclang mode using a flag? /Magnus > > Best regards, Matthias > > >> -----Original Message----- >> From: Magnus Ihse Bursie >> Sent: Freitag, 15. Februar 2019 12:37 >> To: Baesken, Matthias ; 'build- >> dev at openjdk.java.net' >> Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection >> >> On 2019-02-15 09:31, Baesken, Matthias wrote: >>> Hi Magnus , I think it is not a separate toolchain , just another compiler >> frontend offered by the xlc toolchain of xlc16 . >> So will this distinction between xlc and xlclang be needed elsewhere? Or >> is it just the -g flag? I was worried that this was just the start of a >> flood of changes related to xlc vs xlclang, but maybe this is all that >> is needed? >> >> If so, could the choice between -g ang -g1 be handled with the normal >> TOOLCHAIN_CHECK_COMPILER_VERSION? >> >> /Magnus >> >>> Our current toolchains are : >>> >>> # These toolchains are valid on different platforms >>> VALID_TOOLCHAINS_linux="gcc clang" >>> VALID_TOOLCHAINS_solaris="solstudio" >>> VALID_TOOLCHAINS_macosx="gcc clang" >>> VALID_TOOLCHAINS_aix="xlc" >>> VALID_TOOLCHAINS_windows="microsoft" >>> >>> # Toolchain descriptions >>> TOOLCHAIN_DESCRIPTION_clang="clang/LLVM" >>> TOOLCHAIN_DESCRIPTION_gcc="GNU Compiler Collection" >>> TOOLCHAIN_DESCRIPTION_microsoft="Microsoft Visual Studio" >>> TOOLCHAIN_DESCRIPTION_solstudio="Oracle Solaris Studio" >>> TOOLCHAIN_DESCRIPTION_xlc="IBM XL C/C++" >>> >>> >>> XLC16 /xlclang++ identifies itself as : >>> >>> xlclang++ -qversion >>> IBM XL C/C++ for AIX, V16.1.0 >>> >>> >>> In the long run , with JEP 347: Adopt C++14 Language Features in HotSpot >> , the legacy XlC_r will most likely not be usable any more to build the HS >> codebase . >>> Then we must go to another compiler , and xlclang++ is the choice I think . >>> >>> (other option is to discontinue the AIX support in OpenJDK, or strip >> down JEP 347 to some C++ 11 features supported by the legacy XlC_r ). >>> So then we do not really need such a detection any more and have to go >> for the usable tool . >>>> We try to use "true" and "false" as values for boolean variable, so >>>> "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". >>>> >>> Good point. >>> >>>> The test to determine if we're using xlclang seem to happen in the wrong >>>> location. It also calls the bare "xlclang++" from the path, without any >>>> consideration if the user has specified a toolchain path, etc. >>>> >>> I think this is how it is currently done on AIX for years, you just put xlc in >> the PATH and then let configure find it there. >>> However you are right on this one , toolchain path settings should be >> supported ( not sure whether they currently work or not). >>> In our AIX envs they are not of much use, because we have ***one*** >> xlc per machine ( I am not even sure if it is 100% supported to have >> multiple xlc in parallel on one machine, >>> guess it somehow works but is not officially recommended ). >>> >>>> I won't go into more details on the patch until we've determined if this >>>> is the solution we should pursue. >>>> >>> There is no need to rush the patch in , for now the legacy xlc_r still works >> ( until the C++11/14 features show up ) . >>> Best regards, Matthias >>> >>> >>> >>>>> please review this small change . >>>>> >>>>> On AIX, it adds detection of xlc16 / clang to the build environment. >>>>> >>>>> The xlc16 package contains 2 compiler frontends : >>>>> >>>>> >>>>> * The legacy xlc >>>>> * The new clang-based xlclang++ >>>>> >>>>> For older xlc (12 / 13) we should for now still support the "legacy" xlc . >>>>> For xlc16 the usage of xlclang++ is desired , because it promises >>>> better C++11/14 support (important for the coming JEPs dealing with >>>> C++11/14 features) . >>>>> Additionally to the compiler detection , the debug-flag is changed to -g1 >>>> when xlclang++ is used (because of issues with -g) ; thanks to Steven for >>>> providing the info. >>>>> >>>>> Bug/webrev : >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8218965 >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.0/ >>>> Hi Matthias, >>>> >>>> I have several doubts about this patch. >>>> >>>> Let me start at the highest level before dwelling on details. >>>> >>>> Is this really the right way to handle this? Maybe we should either >>>> treat xlclang as a new, separate toolchain, or we should treat xlclang >>>> as a variant of the clang toolchain. >>>> >>>> If xlclang is very similar to clang (same compilation behavior, same >>>> compiler flags), then I believe the latter way is the proper way forward. >>>> >>>> If xlclang is -- even though the change of frontend -- mostly similar to >>>> the traditional xlc, then the path chosen by you might be the best way >>>> forward after all. >>>> >>>> If xlclang is different enought from both the traditional xlc, and from >>>> clang, we might want to treat it like an entirely new toolchain. We can >>>> of course share code with the existing xlc and clang toolchains. I think >>>> this is the best way if e.g. compiler flags are still shared with xlc, >>>> but source code defines etc is shared with clang. That way we can test >>>> for "xlc or xlclang" when setting up flags, but "clang or xlclang" in >>>> the #ifdefs. >>>> >>>> --- >>>> >>>> If we should go forward with your patch, please note the following: >>>> >>>> We try to use "true" and "false" as values for boolean variable, so >>>> "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". >>>> >>>> The test to determine if we're using xlclang seem to happen in the wrong >>>> location. It also calls the bare "xlclang++" from the path, without any >>>> consideration if the user has specified a toolchain path, etc. >>>> >>>> I won't go into more details on the patch until we've determined if this >>>> is the solution we should pursue. >>>> >>>> /Magnus >>>>> >>>>> Thanks, Matthias From matthias.baesken at sap.com Fri Feb 15 13:30:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 15 Feb 2019 13:30:51 +0000 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: <97bb3895-269d-dac2-8fc5-7b1480646f99@oracle.com> References: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> <8a9cf0ba-6641-6a80-caeb-e42abf64ad61@oracle.com> <97bb3895-269d-dac2-8fc5-7b1480646f99@oracle.com> Message-ID: > > Are they both pointing to the same binary, and the mode of operation > (legacy xlc vs xlclang) is determined by the name of the executable? > Hello, in the installation I use I have separate binaries . > > Is xlclang++ always available for version 16+ of xlc? > I think so, as least I am not aware of an installation mode with separate binaries . However I am not an XLC installation guru ? . > > If so, maybe we should just make sure we call the compiler with the > correct name if version 16+ is detected? > I thought that we currently first set the toolchain name and then set a fix name for the binary and check the version . But I might be wrong. Maybe we need to adjust this . Or just at some future point in time declare xlc16 as minimum requirement (this makes things easier , we can then use the new binary names ). Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Freitag, 15. Februar 2019 13:32 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Cc: Doerr, Martin > Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection > > On 2019-02-15 12:53, Baesken, Matthias wrote: > > Hi Magnus, > > > > we are currently able to build (+ test ? ) jdk/jdk on AIX with the > xlclang++ based build . > > Only needed are this change , > > plus a one-liner in harfhuzz is needed (we try to get this upstream into > harbuzz directly, in case the next harfhuzz update to jdk/jdk is in the mid/far > future , I would add this one liner to my patch). > > > > So I hope that there will be not so many follow ups (but you never know > ). > > Ok, that's good to hear. > > > >> If so, could the choice between -g ang -g1 be handled with the normal > >> TOOLCHAIN_CHECK_COMPILER_VERSION? > >> > > I'll look into this . Unfortunately the version output is the same for both > frontends : > > > > New one: > > > > bash-4.4$ xlclang++ -qversion > > IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) > > Version: 16.01.0000.0001 > > > > Legacy xlc: > > > > bash-4.4$ xlC_r -qversion > > IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) > > Version: 16.01.0000.0001 > > > > > > (and some-strange-hex-string is the same for both) > Hm. > > Are they both pointing to the same binary, and the mode of operation > (legacy xlc vs xlclang) is determined by the name of the executable? > > Is xlclang++ always available for version 16+ of xlc? > > If so, maybe we should just make sure we call the compiler with the > correct name if version 16+ is detected? > > Or is there a way to force xlclang mode using a flag? > > /Magnus > From sgehwolf at redhat.com Fri Feb 15 17:01:27 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Feb 2019 18:01:27 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> Hi Alan, Mandy, Here is the next round of this change: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ It now also has tests which don't require objcopy to be present on test machines as well as being integrated with --strip-debug (once JDK- 8218913 is pushed). --list-plugins help output for --strip-native- debug-symbols now reads: ----->8------------------------- Plugin Name: strip-native-debug-symbols Option: --strip-native-debug-symbols= Description: Strip debug symbols from native libraries (if any). This plugin requires at least one option: objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. omit-debuginfo: Do not keep debug info files. Defaults to true. keep-debuginfo[=]: Keep debug info files in .. Defaults to .debuginfo Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy --strip-native-debug-symbols=omit-debuginfo --strip-native-debug-symbols keep-debuginfo:objcopy=objcopy ----->8------------------------- Testing: jdk.jlink tests jdk/submit (ongoing), added tests: DefaultStripDebugPluginTest, StripNativeDebugSymbolsPluginTest Note: IntegrationTest needed a heap size bump as this now runs StripNativeDebugSymbolsPluginTest on some systems. Especially with --with-native-debug-symbols=internal builds this can eat some memory. Please let me know what you think. Thanks, Severin On Wed, 2019-02-13 at 15:36 -0800, Mandy Chung wrote: > On 2/13/19 1:04 AM, Severin Gehwolf wrote: > > > --strip-native-debug-symbols no-keep-debuginfo > > --strip-native-debug-symbols strip-debuginfo > > --strip-native-debug-symbols remove-debuginfo > > > > It would avoid using negation. > > What about 'omit', i.e. > > --strip-native-debug-symbols omit-debuginfo > --strip-native-debug-symbols keep-debuginfo= > > > Sure. I've filed JDK-8218913 for doing this first. Would a name of -- > > strip-java-debug-symbols be acceptable? My thinking is that it would > > have nice symmetry with --strip-native-debug-symbols. Thoughts? > > --strip-native-debug-symbols is okay. > > Having a second thought, javac -g and gcc -g both say "debugging > information". I think we could go with: > > --strip-java-debug-info > --strip-native-debug-info omit-debuginfo > --strip-native-debug-info keep-debuginfo= > > unless anyone thinks `-debug-symbols` is better? > > The options are getting pretty good now. > > Mandy From erik.joelsson at oracle.com Fri Feb 15 19:00:01 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2019 11:00:01 -0800 Subject: RFR: JDK-8219129: Allow overriding of license files in legal dir Message-ID: <8f4a3edb-4b2f-b0e6-b0cf-76bf3f8293eb@oracle.com> Like with sources in java and native compilation, this patch allows automatic override of license files in the legal dir by just providing a "custom" file with the same name. Bug: https://bugs.openjdk.java.net/browse/JDK-8219129 Webrev: http://cr.openjdk.java.net/~erikj/8219129/webrev.01/ /Erik From erik.joelsson at oracle.com Fri Feb 15 19:57:54 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2019 11:57:54 -0800 Subject: RFR: JDK-8217032: Check pandoc capabilities in configure In-Reply-To: <7aee0988-a4c7-c977-037b-2bd375518fb4@oracle.com> References: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> <7aee0988-a4c7-c977-037b-2bd375518fb4@oracle.com> Message-ID: <2aa6b892-4abe-efa9-c4aa-88a8b5c4e1c9@oracle.com> Thanks for the input. Here is a new webrev that only tries to disable the "smart" extension if it is present. http://cr.openjdk.java.net/~erikj/8217032/webrev.02/index.html /Erik On 2019-02-14 23:34, Magnus Ihse Bursie wrote: > On 2019-02-15 00:26, Erik Joelsson wrote: >> Please review this minor fix. The JDK build now has support for >> generating man pages, and will try to do so if it finds pandoc on the >> system. Unfortunately, not all versions of pandoc are valid, and if a >> bad version is found, the build will fail. This patch adds an >> extensions check for the found pandoc in configure, and if the >> "smart" extension that we use is missing, pandoc is disabled. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ > Actually, the problem is slightly more subtle. :( > > We're not using the "smart" extension, we're disabling it. > > If the pandoc we discover does not have the smart extension, we should > instead use to output format "markdown" instead of "markdown-smart". > This is what we used before, and it worked all well, until I updated > the version of markdown used by jib, and it started doing "smart" > (actually: dumb) quoting, and I had to disable it. > > Since the version of pandoc commonly installed by Ubuntu (and maybe > other distros as well) is old enough to not contain the smart > extension, I don't think it's good to disable it -- after all, it > works just perfectly; but we should adjust the "flags" to markdown in > that case. > > /Magnus > >> >> /Erik >> > From erik.joelsson at oracle.com Fri Feb 15 20:48:26 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2019 12:48:26 -0800 Subject: RFR: JDK-8211016: make images does not update jdk/lib/src.zip with latest changes Message-ID: <9988740e-7302-92c2-754f-356e1ff65dc6@oracle.com> The incremental build of src.zip is broken. The cause of this is a bit complex. To create the correct layout for the files in src.zip, we create a set of directories with symlinks back to the real source. When we then run find over these symlinked directories to figure out the make dependencies, find will not follow symlinks by default. The fix adds -L to find only when creating zip files. I think this is the right thing to do because zip will follow symlinks by default as well, so it keeps the behavior of the makefile and the resulting zip file the same. I don't think we should always follow symlinks when finding files however, because most of the time, we do want the links rather than their targets in the result. While investigating I also decided to wrap the zip commands in ExecuteWithLog. Note that since zip is called in a loop, only the output of the last call will end up in the log. I think this is ok because successful runs should not produce output, and make will terminate on failure anyway. Bug: https://bugs.openjdk.java.net/browse/JDK-8211016 Webrev: http://cr.openjdk.java.net/~erikj/8211016/webrev.01/index.html /Erik From mikael.vidstedt at oracle.com Fri Feb 15 22:04:19 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 14:04:19 -0800 Subject: RFR: JDK-8217032: Check pandoc capabilities in configure In-Reply-To: <2aa6b892-4abe-efa9-c4aa-88a8b5c4e1c9@oracle.com> References: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> <7aee0988-a4c7-c977-037b-2bd375518fb4@oracle.com> <2aa6b892-4abe-efa9-c4aa-88a8b5c4e1c9@oracle.com> Message-ID: How about having the variable be called something like PANDOC_MARKDOWN_FLAG, and have the value include ?markdown?? Cheers, Mikael > On Feb 15, 2019, at 11:57 AM, Erik Joelsson wrote: > > Thanks for the input. Here is a new webrev that only tries to disable the "smart" extension if it is present. > > http://cr.openjdk.java.net/~erikj/8217032/webrev.02/index.html > > /Erik > > On 2019-02-14 23:34, Magnus Ihse Bursie wrote: >> On 2019-02-15 00:26, Erik Joelsson wrote: >>> Please review this minor fix. The JDK build now has support for generating man pages, and will try to do so if it finds pandoc on the system. Unfortunately, not all versions of pandoc are valid, and if a bad version is found, the build will fail. This patch adds an extensions check for the found pandoc in configure, and if the "smart" extension that we use is missing, pandoc is disabled. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ >> Actually, the problem is slightly more subtle. :( >> >> We're not using the "smart" extension, we're disabling it. >> >> If the pandoc we discover does not have the smart extension, we should instead use to output format "markdown" instead of "markdown-smart". This is what we used before, and it worked all well, until I updated the version of markdown used by jib, and it started doing "smart" (actually: dumb) quoting, and I had to disable it. >> >> Since the version of pandoc commonly installed by Ubuntu (and maybe other distros as well) is old enough to not contain the smart extension, I don't think it's good to disable it -- after all, it works just perfectly; but we should adjust the "flags" to markdown in that case. >> >> /Magnus >> >>> >>> /Erik >>> >> From erik.joelsson at oracle.com Fri Feb 15 22:28:44 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2019 14:28:44 -0800 Subject: RFR: JDK-8217032: Check pandoc capabilities in configure In-Reply-To: References: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> <7aee0988-a4c7-c977-037b-2bd375518fb4@oracle.com> <2aa6b892-4abe-efa9-c4aa-88a8b5c4e1c9@oracle.com> Message-ID: That would look better. Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.03/index.html /Erik On 2019-02-15 14:04, Mikael Vidstedt wrote: > How about having the variable be called something like PANDOC_MARKDOWN_FLAG, and have the value include ?markdown?? > > Cheers, > Mikael > >> On Feb 15, 2019, at 11:57 AM, Erik Joelsson wrote: >> >> Thanks for the input. Here is a new webrev that only tries to disable the "smart" extension if it is present. >> >> http://cr.openjdk.java.net/~erikj/8217032/webrev.02/index.html >> >> /Erik >> >> On 2019-02-14 23:34, Magnus Ihse Bursie wrote: >>> On 2019-02-15 00:26, Erik Joelsson wrote: >>>> Please review this minor fix. The JDK build now has support for generating man pages, and will try to do so if it finds pandoc on the system. Unfortunately, not all versions of pandoc are valid, and if a bad version is found, the build will fail. This patch adds an extensions check for the found pandoc in configure, and if the "smart" extension that we use is missing, pandoc is disabled. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ >>> Actually, the problem is slightly more subtle. :( >>> >>> We're not using the "smart" extension, we're disabling it. >>> >>> If the pandoc we discover does not have the smart extension, we should instead use to output format "markdown" instead of "markdown-smart". This is what we used before, and it worked all well, until I updated the version of markdown used by jib, and it started doing "smart" (actually: dumb) quoting, and I had to disable it. >>> >>> Since the version of pandoc commonly installed by Ubuntu (and maybe other distros as well) is old enough to not contain the smart extension, I don't think it's good to disable it -- after all, it works just perfectly; but we should adjust the "flags" to markdown in that case. >>> >>> /Magnus >>> >>>> /Erik >>>> From erik.joelsson at oracle.com Fri Feb 15 22:35:54 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Feb 2019 14:35:54 -0800 Subject: RFR: JDK-8218135: Redo: Add ppc64le and s390x profiles to jib-profiles.js Message-ID: This is a "redo" of JDK-8218057, which was backed out in JDK-8218084. The underlying issue has been resolved so we can now put this change in again. The patch is the same as last time. Bug: https://bugs.openjdk.java.net/browse/JDK-8218135 Webrev: http://cr.openjdk.java.net/~erikj/8218135/webrev.01/ From mikael.vidstedt at oracle.com Fri Feb 15 22:36:45 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 14:36:45 -0800 Subject: RFR: JDK-8217032: Check pandoc capabilities in configure In-Reply-To: References: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> <7aee0988-a4c7-c977-037b-2bd375518fb4@oracle.com> <2aa6b892-4abe-efa9-c4aa-88a8b5c4e1c9@oracle.com> Message-ID: +1 Cheers, Mikael > On Feb 15, 2019, at 2:28 PM, Erik Joelsson wrote: > > That would look better. Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.03/index.html > > /Erik > > On 2019-02-15 14:04, Mikael Vidstedt wrote: >> How about having the variable be called something like PANDOC_MARKDOWN_FLAG, and have the value include ?markdown?? >> >> Cheers, >> Mikael >> >>> On Feb 15, 2019, at 11:57 AM, Erik Joelsson wrote: >>> >>> Thanks for the input. Here is a new webrev that only tries to disable the "smart" extension if it is present. >>> >>> http://cr.openjdk.java.net/~erikj/8217032/webrev.02/index.html >>> >>> /Erik >>> >>> On 2019-02-14 23:34, Magnus Ihse Bursie wrote: >>>> On 2019-02-15 00:26, Erik Joelsson wrote: >>>>> Please review this minor fix. The JDK build now has support for generating man pages, and will try to do so if it finds pandoc on the system. Unfortunately, not all versions of pandoc are valid, and if a bad version is found, the build will fail. This patch adds an extensions check for the found pandoc in configure, and if the "smart" extension that we use is missing, pandoc is disabled. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ >>>> Actually, the problem is slightly more subtle. :( >>>> >>>> We're not using the "smart" extension, we're disabling it. >>>> >>>> If the pandoc we discover does not have the smart extension, we should instead use to output format "markdown" instead of "markdown-smart". This is what we used before, and it worked all well, until I updated the version of markdown used by jib, and it started doing "smart" (actually: dumb) quoting, and I had to disable it. >>>> >>>> Since the version of pandoc commonly installed by Ubuntu (and maybe other distros as well) is old enough to not contain the smart extension, I don't think it's good to disable it -- after all, it works just perfectly; but we should adjust the "flags" to markdown in that case. >>>> >>>> /Magnus >>>> >>>>> /Erik >>>>> From alexander.matveev at oracle.com Sat Feb 16 03:03:00 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 15 Feb 2019 19:03:00 -0800 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> Message-ID: <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> Hi Magnus, http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ Moved all files from "posix" to "unix" folder and reverted Lib-jdk.jpackage.gmk changes. Webrev updated with files moved, instead of add/remove. Thanks, Alexander On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: > > > On 2019-02-15 04:31, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - Moved native code under platform specific folder. >> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >> - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp >> for Mac specific code to filter out some arguments. I decided to keep >> it as is for now, since Mac specific code is small. >> - Defines are used in Platform.cpp to initialize platform specific >> classes. >> - Removed all pragma warning and fixed all compilation warnings. >> - Removed unused code. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >> >> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ > The JDK standard is to use "unix", not "posix", for the shared > functionality between linux/solaris/macosx. You can keep the name > "PosixPlatform.*" if you want, though; the important thing is the > directory name. > > Also, if you do that, you do not need any changes to > make/lib/Lib-jdk.jpackage.gmk, since that will be automatically > understood by the build system. > > It looks from the webrev that you have "moved" the files by doing "hg > add" and "hg remove". Please use "hg move" instead -- this will keep > history intact, and it allows reviewers to see if you have also made > changes to the moved files. > > (If you do have modified the moved file, reverting a "hg add+hg > remove" process is a bit more tricky -- you need to do "hg forget" on > the new file, rename it to something else (otherwise "hg move" will > complain), "hg revert" the old file back in place, do a "hg move" from > the old to the new, and then copy the modified, renamed file back over > the target new file again.) > > /Magnus >> >> Thanks, >> Alexander > From francogpellegrini at gmail.com Sat Feb 16 06:47:48 2019 From: francogpellegrini at gmail.com (=?UTF-8?Q?Franco_Gast=C3=B3n_Pellegrini?=) Date: Sat, 16 Feb 2019 03:47:48 -0300 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> <294f30aa-fef4-3c6c-302d-77a1bc7d1547@oracle.com> <29c6de1c-a756-d03c-358f-cd1d82b3ad94@oracle.com> Message-ID: Yes, removing --debug-mode enables a 32 bits compilation, with warnings. Thanks! El vie., 15 de feb. de 2019 a la(s) 08:05, Magnus Ihse Bursie ( magnus.ihse.bursie at oracle.com) escribi?: > > > On 2019-02-12 15:42, Alexey Ivanov wrote: > > On 12/02/2019 14:37, Magnus Ihse Bursie wrote: > >> There has been some fallout due to the mapfile/linking changes made > >> in JDK 12 that affected JNICALL. However, that should not be > >> affecting JDK 11. > > Wasn't it done in JDK 11? > > If my memory serves me right, it was done in JDK 11. > > You are correct. The major part of the mapfile removal was done in > JDK-8200358, which was pushed to JDK 11. There were follow up issues > going on all the way into JDK 12, though. > > Anyway, I've now looked more into this issue. And this time map files > were not really to blame, but JNICALL still is. > > First of all, it's important to note that this only shows up when > compiling a debug build. As a workaround, building a normal release > build for 32-bit Windows will not trigger this issue. (This is likely > how it has gotten unnoticed.) To Franco: that means removing > "--enable-debug" from your configure line. > > There core problem seems indeed to be discrepancy whether a function is > declared JNICALL or not. > > In JDK-8214120, DTrace_VPrintln() & co. got JNICALL added in > src/java.desktop/share/native/common/awt/debug/debug_trace.c and > debug_trace.h. However, the typedef DTRACE_PRINT_CALLBACK was not > updated. Since JNICALL is a no-op on all platforms except Windows 32, > this was not discovered. > > However, according to JBS JDK-8214120 was fixed in JDK-12. So why this > is causing issues in JDK-11, I don't understand. Or maybe the discussion > drifted from testing JDK 11 to testing JDK 12? In any case, it is likely > currently broken in JDK 13. > > Here is a suggested patch. Hopefully I got the JNICALL modifier in the > correct place (C function pointer typedefs are the worst!). > > diff --git > a/src/java.desktop/share/native/common/awt/debug/debug_trace.h > b/src/java.desktop/share/native/common/awt/debug/debug_trace.h > --- a/src/java.desktop/share/native/common/awt/debug/debug_trace.h > +++ b/src/java.desktop/share/native/common/awt/debug/debug_trace.h > @@ -48,7 +48,7 @@ > typedef void (*DTRACE_OUTPUT_CALLBACK)(const char * msg); > > /* prototype for client provided print callback function */ > -typedef void (*DTRACE_PRINT_CALLBACK)(const char * file, int line, int > argc, const char * fmt, va_list arglist); > +typedef void (JNICALL *DTRACE_PRINT_CALLBACK)(const char * file, int > line, int argc, const char * fmt, va_list arglist); > > extern void DTrace_EnableAll(dbool_t enabled); > extern void DTrace_EnableFile(const char * file, dbool_t enabled); > > Please test and let me know if it works. If so it should be pushed to > JDK 13, and possibly backported. > > /Magnus > -- Franco Gast?n Pellegrini From magnus.ihse.bursie at oracle.com Sun Feb 17 18:40:12 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 17 Feb 2019 19:40:12 +0100 Subject: compiling openJdk 11 on windows 7 32bits fail In-Reply-To: References: <0ea9613e-5b5b-2011-9b35-2ddf626deaed@oracle.com> <3ea50260-cd2a-f9d3-4d7d-31c6178cbb2f@oracle.com> <294f30aa-fef4-3c6c-302d-77a1bc7d1547@oracle.com> <29c6de1c-a756-d03c-358f-cd1d82b3ad94@oracle.com> Message-ID: > 16 feb. 2019 kl. 07:47 skrev Franco Gast?n Pellegrini : > > Yes, removing --debug-mode enables a 32 bits compilation, with warnings. Thanks! Great! Did the patch help for debug builds? /Magnus > > El vie., 15 de feb. de 2019 a la(s) 08:05, Magnus Ihse Bursie (magnus.ihse.bursie at oracle.com) escribi?: >> >> >> On 2019-02-12 15:42, Alexey Ivanov wrote: >> > On 12/02/2019 14:37, Magnus Ihse Bursie wrote: >> >> There has been some fallout due to the mapfile/linking changes made >> >> in JDK 12 that affected JNICALL. However, that should not be >> >> affecting JDK 11. >> > Wasn't it done in JDK 11? >> > If my memory serves me right, it was done in JDK 11. >> >> You are correct. The major part of the mapfile removal was done in >> JDK-8200358, which was pushed to JDK 11. There were follow up issues >> going on all the way into JDK 12, though. >> >> Anyway, I've now looked more into this issue. And this time map files >> were not really to blame, but JNICALL still is. >> >> First of all, it's important to note that this only shows up when >> compiling a debug build. As a workaround, building a normal release >> build for 32-bit Windows will not trigger this issue. (This is likely >> how it has gotten unnoticed.) To Franco: that means removing >> "--enable-debug" from your configure line. >> >> There core problem seems indeed to be discrepancy whether a function is >> declared JNICALL or not. >> >> In JDK-8214120, DTrace_VPrintln() & co. got JNICALL added in >> src/java.desktop/share/native/common/awt/debug/debug_trace.c and >> debug_trace.h. However, the typedef DTRACE_PRINT_CALLBACK was not >> updated. Since JNICALL is a no-op on all platforms except Windows 32, >> this was not discovered. >> >> However, according to JBS JDK-8214120 was fixed in JDK-12. So why this >> is causing issues in JDK-11, I don't understand. Or maybe the discussion >> drifted from testing JDK 11 to testing JDK 12? In any case, it is likely >> currently broken in JDK 13. >> >> Here is a suggested patch. Hopefully I got the JNICALL modifier in the >> correct place (C function pointer typedefs are the worst!). >> >> diff --git >> a/src/java.desktop/share/native/common/awt/debug/debug_trace.h >> b/src/java.desktop/share/native/common/awt/debug/debug_trace.h >> --- a/src/java.desktop/share/native/common/awt/debug/debug_trace.h >> +++ b/src/java.desktop/share/native/common/awt/debug/debug_trace.h >> @@ -48,7 +48,7 @@ >> typedef void (*DTRACE_OUTPUT_CALLBACK)(const char * msg); >> >> /* prototype for client provided print callback function */ >> -typedef void (*DTRACE_PRINT_CALLBACK)(const char * file, int line, int >> argc, const char * fmt, va_list arglist); >> +typedef void (JNICALL *DTRACE_PRINT_CALLBACK)(const char * file, int >> line, int argc, const char * fmt, va_list arglist); >> >> extern void DTrace_EnableAll(dbool_t enabled); >> extern void DTrace_EnableFile(const char * file, dbool_t enabled); >> >> Please test and let me know if it works. If so it should be pushed to >> JDK 13, and possibly backported. >> >> /Magnus > > > -- > Franco Gast?n Pellegrini From magnus.ihse.bursie at oracle.com Sun Feb 17 18:43:00 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 17 Feb 2019 19:43:00 +0100 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> Message-ID: <0C35970E-82CA-4DB8-8F7D-B86A3E01B8FD@oracle.com> > 16 feb. 2019 kl. 04:03 skrev Alexander Matveev : > > Hi Magnus, > > http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ > > Moved all files from "posix" to "unix" folder and reverted Lib-jdk.jpackage.gmk changes. > Webrev updated with files moved, instead of add/remove. Thank you! This looks good now from a build point of view, but you'll need a review from core-libs as well. /Magnus > > Thanks, > Alexander > >> On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: >> >> >>> On 2019-02-15 04:31, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). >>> >>> - Moved native code under platform specific folder. >>> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >>> - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp for Mac specific code to filter out some arguments. I decided to keep it as is for now, since Mac specific code is small. >>> - Defines are used in Platform.cpp to initialize platform specific classes. >>> - Removed all pragma warning and fixed all compilation warnings. >>> - Removed unused code. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ >> The JDK standard is to use "unix", not "posix", for the shared functionality between linux/solaris/macosx. You can keep the name "PosixPlatform.*" if you want, though; the important thing is the directory name. >> >> Also, if you do that, you do not need any changes to make/lib/Lib-jdk.jpackage.gmk, since that will be automatically understood by the build system. >> >> It looks from the webrev that you have "moved" the files by doing "hg add" and "hg remove". Please use "hg move" instead -- this will keep history intact, and it allows reviewers to see if you have also made changes to the moved files. >> >> (If you do have modified the moved file, reverting a "hg add+hg remove" process is a bit more tricky -- you need to do "hg forget" on the new file, rename it to something else (otherwise "hg move" will complain), "hg revert" the old file back in place, do a "hg move" from the old to the new, and then copy the modified, renamed file back over the target new file again.) >> >> /Magnus >>> >>> Thanks, >>> Alexander > From magnus.ihse.bursie at oracle.com Mon Feb 18 08:16:40 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Feb 2019 09:16:40 +0100 Subject: RFR: JDK-8217032: Check pandoc capabilities in configure In-Reply-To: References: <6fb87df9-4046-4db8-9a2a-86d5842ea86a@oracle.com> <7aee0988-a4c7-c977-037b-2bd375518fb4@oracle.com> <2aa6b892-4abe-efa9-c4aa-88a8b5c4e1c9@oracle.com> Message-ID: LGTM. /Magnus > 15 feb. 2019 kl. 23:28 skrev Erik Joelsson : > > That would look better. Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.03/index.html > > /Erik > >> On 2019-02-15 14:04, Mikael Vidstedt wrote: >> How about having the variable be called something like PANDOC_MARKDOWN_FLAG, and have the value include ?markdown?? >> >> Cheers, >> Mikael >> >>> On Feb 15, 2019, at 11:57 AM, Erik Joelsson wrote: >>> >>> Thanks for the input. Here is a new webrev that only tries to disable the "smart" extension if it is present. >>> >>> http://cr.openjdk.java.net/~erikj/8217032/webrev.02/index.html >>> >>> /Erik >>> >>>> On 2019-02-14 23:34, Magnus Ihse Bursie wrote: >>>>> On 2019-02-15 00:26, Erik Joelsson wrote: >>>>> Please review this minor fix. The JDK build now has support for generating man pages, and will try to do so if it finds pandoc on the system. Unfortunately, not all versions of pandoc are valid, and if a bad version is found, the build will fail. This patch adds an extensions check for the found pandoc in configure, and if the "smart" extension that we use is missing, pandoc is disabled. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ >>>> Actually, the problem is slightly more subtle. :( >>>> >>>> We're not using the "smart" extension, we're disabling it. >>>> >>>> If the pandoc we discover does not have the smart extension, we should instead use to output format "markdown" instead of "markdown-smart". This is what we used before, and it worked all well, until I updated the version of markdown used by jib, and it started doing "smart" (actually: dumb) quoting, and I had to disable it. >>>> >>>> Since the version of pandoc commonly installed by Ubuntu (and maybe other distros as well) is old enough to not contain the smart extension, I don't think it's good to disable it -- after all, it works just perfectly; but we should adjust the "flags" to markdown in that case. >>>> >>>> /Magnus >>>> >>>>> /Erik >>>>> From magnus.ihse.bursie at oracle.com Mon Feb 18 08:17:58 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Feb 2019 09:17:58 +0100 Subject: RFR: JDK-8218135: Redo: Add ppc64le and s390x profiles to jib-profiles.js In-Reply-To: References: Message-ID: <925E8E3A-2E5C-475D-80F8-A302BB519FD4@oracle.com> Looks good to me. Thanks for fixing this, I never got around to it. /Magnus > 15 feb. 2019 kl. 23:35 skrev Erik Joelsson : > > This is a "redo" of JDK-8218057, which was backed out in JDK-8218084. The underlying issue has been resolved so we can now put this change in again. The patch is the same as last time. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218135 > > Webrev: http://cr.openjdk.java.net/~erikj/8218135/webrev.01/ > > From magnus.ihse.bursie at oracle.com Mon Feb 18 08:20:49 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Feb 2019 09:20:49 +0100 Subject: RFR: JDK-8211016: make images does not update jdk/lib/src.zip with latest changes In-Reply-To: <9988740e-7302-92c2-754f-356e1ff65dc6@oracle.com> References: <9988740e-7302-92c2-754f-356e1ff65dc6@oracle.com> Message-ID: <40094B68-9423-4C82-8FDA-A0C0B54F0D7A@oracle.com> > 15 feb. 2019 kl. 21:48 skrev Erik Joelsson : > > The incremental build of src.zip is broken. The cause of this is a bit complex. To create the correct layout for the files in src.zip, we create a set of directories with symlinks back to the real source. When we then run find over these symlinked directories to figure out the make dependencies, find will not follow symlinks by default. > > The fix adds -L to find only when creating zip files. I think this is the right thing to do because zip will follow symlinks by default as well, so it keeps the behavior of the makefile and the resulting zip file the same. I don't think we should always follow symlinks when finding files however, because most of the time, we do want the links rather than their targets in the result. > > While investigating I also decided to wrap the zip commands in ExecuteWithLog. Note that since zip is called in a loop, only the output of the last call will end up in the log. I think this is ok because successful runs should not produce output, and make will terminate on failure anyway. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211016 > > Webrev: http://cr.openjdk.java.net/~erikj/8211016/webrev.01/index.html Looks good to me. I agree with your reasoning. /Magnus > > /Erik > From magnus.ihse.bursie at oracle.com Mon Feb 18 08:27:32 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Feb 2019 09:27:32 +0100 Subject: RFR: JDK-8219129: Allow overriding of license files in legal dir In-Reply-To: <8f4a3edb-4b2f-b0e6-b0cf-76bf3f8293eb@oracle.com> References: <8f4a3edb-4b2f-b0e6-b0cf-76bf3f8293eb@oracle.com> Message-ID: <0508BE55-0391-4609-8166-4BB1C8F06E15@oracle.com> > 15 feb. 2019 kl. 20:00 skrev Erik Joelsson : > > Like with sources in java and native compilation, this patch allows automatic override of license files in the legal dir by just providing a "custom" file with the same name. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219129 > > Webrev: http://cr.openjdk.java.net/~erikj/8219129/webrev.01/ Looks good, but please add some documentation that if multiple files have the same name, only the first will be copied. No need to respin webrev. /Magnus > > /Erik > From magnus.ihse.bursie at oracle.com Mon Feb 18 08:32:17 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Feb 2019 09:32:17 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> Message-ID: > 15 feb. 2019 kl. 18:01 skrev Severin Gehwolf : > > Hi Alan, Mandy, > > Here is the next round of this change: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ Looks good from the build PoV, with one minor nit: In JtregNativeJdk.gmk, please use the new construct: ifeq ($(call isTargetOs, linux), true) /Magnus > > It now also has tests which don't require objcopy to be present on test > machines as well as being integrated with --strip-debug (once JDK- > 8218913 is pushed). --list-plugins help output for --strip-native- > debug-symbols now reads: > > ----->8------------------------- > Plugin Name: strip-native-debug-symbols > Option: --strip-native-debug-symbols= > Description: Strip debug symbols from native libraries (if any). > This plugin requires at least one option: > objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. > omit-debuginfo: Do not keep debug info files. Defaults to true. > keep-debuginfo[=]: Keep debug info files in .. > Defaults to .debuginfo > Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy > --strip-native-debug-symbols=omit-debuginfo > --strip-native-debug-symbols keep-debuginfo:objcopy=objcopy > ----->8------------------------- > > Testing: jdk.jlink tests jdk/submit (ongoing), added tests: > DefaultStripDebugPluginTest, StripNativeDebugSymbolsPluginTest > > Note: IntegrationTest needed a heap size bump as this now runs > StripNativeDebugSymbolsPluginTest on some systems. Especially with > --with-native-debug-symbols=internal builds this can eat some > memory. > > Please let me know what you think. > > Thanks, > Severin > >> On Wed, 2019-02-13 at 15:36 -0800, Mandy Chung wrote: >> On 2/13/19 1:04 AM, Severin Gehwolf wrote: >>>> --strip-native-debug-symbols no-keep-debuginfo >>> --strip-native-debug-symbols strip-debuginfo >>> --strip-native-debug-symbols remove-debuginfo >>> >>> It would avoid using negation. >> >> What about 'omit', i.e. >> >> --strip-native-debug-symbols omit-debuginfo >> --strip-native-debug-symbols keep-debuginfo= >> >>> Sure. I've filed JDK-8218913 for doing this first. Would a name of -- >>> strip-java-debug-symbols be acceptable? My thinking is that it would >>> have nice symmetry with --strip-native-debug-symbols. Thoughts? >> >> --strip-native-debug-symbols is okay. >> >> Having a second thought, javac -g and gcc -g both say "debugging >> information". I think we could go with: >> >> --strip-java-debug-info >> --strip-native-debug-info omit-debuginfo >> --strip-native-debug-info keep-debuginfo= >> >> unless anyone thinks `-debug-symbols` is better? >> >> The options are getting pretty good now. >> >> Mandy > From martin.doerr at sap.com Mon Feb 18 10:12:02 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Feb 2019 10:12:02 +0000 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: References: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> <8a9cf0ba-6641-6a80-caeb-e42abf64ad61@oracle.com> <97bb3895-269d-dac2-8fc5-7b1480646f99@oracle.com> Message-ID: Hi Matthias, thanks for working on xlclang++ support. Seems like we only 2 changes away from C++14 support on AIX: 1. The TOOLCHAIN_CC/CXX_BINARY_xlc change you proposed. 2. Backport the following harfbuzz change: Support xlclang++ on AIX. (#1584) src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh -#elif !defined(HB_NO_MT) && defined(_AIX) && defined(__IBMCPP__) +#elif !defined(HB_NO_MT) && defined(_AIX) && (defined(__IBMCPP__) || defined(__ibmxl__)) Can you add this tiny harfbuzz backport to your change once the xlC/xlclang++ selection mechanism is clearified? Best regards, Martin -----Original Message----- From: Baesken, Matthias Sent: Freitag, 15. Februar 2019 14:31 To: Magnus Ihse Bursie ; 'build-dev at openjdk.java.net' Cc: Doerr, Martin Subject: RE: RFR : 8218965: aix: support xlclang++ in the compiler detection > > Are they both pointing to the same binary, and the mode of operation > (legacy xlc vs xlclang) is determined by the name of the executable? > Hello, in the installation I use I have separate binaries . > > Is xlclang++ always available for version 16+ of xlc? > I think so, as least I am not aware of an installation mode with separate binaries . However I am not an XLC installation guru ? . > > If so, maybe we should just make sure we call the compiler with the > correct name if version 16+ is detected? > I thought that we currently first set the toolchain name and then set a fix name for the binary and check the version . But I might be wrong. Maybe we need to adjust this . Or just at some future point in time declare xlc16 as minimum requirement (this makes things easier , we can then use the new binary names ). Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Freitag, 15. Februar 2019 13:32 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Cc: Doerr, Martin > Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection > > On 2019-02-15 12:53, Baesken, Matthias wrote: > > Hi Magnus, > > > > we are currently able to build (+ test ? ) jdk/jdk on AIX with the > xlclang++ based build . > > Only needed are this change , > > plus a one-liner in harfhuzz is needed (we try to get this upstream into > harbuzz directly, in case the next harfhuzz update to jdk/jdk is in the mid/far > future , I would add this one liner to my patch). > > > > So I hope that there will be not so many follow ups (but you never know > ). > > Ok, that's good to hear. > > > >> If so, could the choice between -g ang -g1 be handled with the normal > >> TOOLCHAIN_CHECK_COMPILER_VERSION? > >> > > I'll look into this . Unfortunately the version output is the same for both > frontends : > > > > New one: > > > > bash-4.4$ xlclang++ -qversion > > IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) > > Version: 16.01.0000.0001 > > > > Legacy xlc: > > > > bash-4.4$ xlC_r -qversion > > IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) > > Version: 16.01.0000.0001 > > > > > > (and some-strange-hex-string is the same for both) > Hm. > > Are they both pointing to the same binary, and the mode of operation > (legacy xlc vs xlclang) is determined by the name of the executable? > > Is xlclang++ always available for version 16+ of xlc? > > If so, maybe we should just make sure we call the compiler with the > correct name if version 16+ is detected? > > Or is there a way to force xlclang mode using a flag? > > /Magnus > From magnus.ihse.bursie at oracle.com Mon Feb 18 10:17:36 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Feb 2019 11:17:36 +0100 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: References: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> <8a9cf0ba-6641-6a80-caeb-e42abf64ad61@oracle.com> <97bb3895-269d-dac2-8fc5-7b1480646f99@oracle.com> Message-ID: On 2019-02-15 14:30, Baesken, Matthias wrote: >> Are they both pointing to the same binary, and the mode of operation >> (legacy xlc vs xlclang) is determined by the name of the executable? >> > Hello, in the installation I use I have separate binaries . > > >> Is xlclang++ always available for version 16+ of xlc? >> > I think so, as least I am not aware of an installation mode with separate binaries . > However I am not an XLC installation guru ? . > >> If so, maybe we should just make sure we call the compiler with the >> correct name if version 16+ is detected? >> > I thought that we currently first set the toolchain name and then set a fix name for the binary and check the version . > But I might be wrong. Maybe we need to adjust this . > Or just at some future point in time declare xlc16 as minimum requirement (this makes things easier , we can then use the new binary names ). Yeah, we can adjust the process if needed. And to solve this *properly*, we should. I still think this looks like the wrong way to do it. But... If we're talking about a short migration story, where soon XLC 16 will be required, and we can just replace TOOLCHAIN_CC_BINARY_xlc="xlc_r" with TOOLCHAIN_CC_BINARY_xlc="xlclang" then I can accept it anyway, so we don't need to complicate things. I also don't like how xlclang is just run from the path, but OTOH it's only you guys who are going to run that in practice, and it's just going to be temporary, so, whatever. The name AIX_USE_CLANG is not really correct, though. This is not about AIX. It should be XLC_USE_CLANG (or maybe better XLC_USES_CLANG, even perhaps XLC_IS_CLANG?!). And, as I said, it should use true/false, not 0/1. If you fix this, and we agree that this is a temporary measure, I'm OK with the patch. /Magnus > > Best regards, Matthias > > >> -----Original Message----- >> From: Magnus Ihse Bursie >> Sent: Freitag, 15. Februar 2019 13:32 >> To: Baesken, Matthias ; 'build- >> dev at openjdk.java.net' >> Cc: Doerr, Martin >> Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection >> >> On 2019-02-15 12:53, Baesken, Matthias wrote: >>> Hi Magnus, >>> >>> we are currently able to build (+ test ? ) jdk/jdk on AIX with the >> xlclang++ based build . >>> Only needed are this change , >>> plus a one-liner in harfhuzz is needed (we try to get this upstream into >> harbuzz directly, in case the next harfhuzz update to jdk/jdk is in the mid/far >> future , I would add this one liner to my patch). >>> So I hope that there will be not so many follow ups (but you never know >> ). >> >> Ok, that's good to hear. >>>> If so, could the choice between -g ang -g1 be handled with the normal >>>> TOOLCHAIN_CHECK_COMPILER_VERSION? >>>> >>> I'll look into this . Unfortunately the version output is the same for both >> frontends : >>> New one: >>> >>> bash-4.4$ xlclang++ -qversion >>> IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) >>> Version: 16.01.0000.0001 >>> >>> Legacy xlc: >>> >>> bash-4.4$ xlC_r -qversion >>> IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) >>> Version: 16.01.0000.0001 >>> >>> >>> (and some-strange-hex-string is the same for both) >> Hm. >> >> Are they both pointing to the same binary, and the mode of operation >> (legacy xlc vs xlclang) is determined by the name of the executable? >> >> Is xlclang++ always available for version 16+ of xlc? >> >> If so, maybe we should just make sure we call the compiler with the >> correct name if version 16+ is detected? >> >> Or is there a way to force xlclang mode using a flag? >> >> /Magnus >> From sgehwolf at redhat.com Mon Feb 18 11:02:54 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Feb 2019 12:02:54 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> Message-ID: <80c48f6909765e95700db49ed040ce02be9b692f.camel@redhat.com> Hi Magnus, On Mon, 2019-02-18 at 09:32 +0100, Magnus Ihse Bursie wrote: > > 15 feb. 2019 kl. 18:01 skrev Severin Gehwolf : > > > > Hi Alan, Mandy, > > > > Here is the next round of this change: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ > > Looks good from the build PoV, with one minor nit: In > JtregNativeJdk.gmk, please use the new construct: > > ifeq ($(call isTargetOs, linux), true) Right. Thanks for this. I've updated it locally. The hunk in JtregNaitveJdk.gmk now reads: diff --git a/make/test/JtregNativeJdk.gmk b/make/test/JtregNativeJdk.gmk --- a/make/test/JtregNativeJdk.gmk +++ b/make/test/JtregNativeJdk.gmk @@ -82,6 +82,14 @@ BUILD_JDK_JTREG_EXCLUDE += exeJniInvocationTest.c endif +ifeq ($(call isTargetOs, linux), true) + # Unconditionally compile with debug symbols and don't ever perform + # stripping during the test libraries' build. + BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libFib := -g + BUILD_JDK_JTREG_LIBRARIES_STRIP_SYMBOLS_libFib := false +endif + + $(eval $(call SetupTestFilesCompilation, BUILD_JDK_JTREG_LIBRARIES, \ TYPE := LIBRARY, \ SOURCE_DIRS := $(BUILD_JDK_JTREG_NATIVE_SRC), \ Thanks, Severin From magnus.ihse.bursie at oracle.com Mon Feb 18 11:05:27 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Feb 2019 12:05:27 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <80c48f6909765e95700db49ed040ce02be9b692f.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <80c48f6909765e95700db49ed040ce02be9b692f.camel@redhat.com> Message-ID: <03abff3e-5dec-d8dd-185b-4f7566da7c2d@oracle.com> On 2019-02-18 12:02, Severin Gehwolf wrote: > Hi Magnus, > > On Mon, 2019-02-18 at 09:32 +0100, Magnus Ihse Bursie wrote: >>> 15 feb. 2019 kl. 18:01 skrev Severin Gehwolf : >>> >>> Hi Alan, Mandy, >>> >>> Here is the next round of this change: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ >> Looks good from the build PoV, with one minor nit: In >> JtregNativeJdk.gmk, please use the new construct: >> >> ifeq ($(call isTargetOs, linux), true) > Right. Thanks for this. I've updated it locally. The hunk in > JtregNaitveJdk.gmk now reads: > > diff --git a/make/test/JtregNativeJdk.gmk b/make/test/JtregNativeJdk.gmk > --- a/make/test/JtregNativeJdk.gmk > +++ b/make/test/JtregNativeJdk.gmk > @@ -82,6 +82,14 @@ > BUILD_JDK_JTREG_EXCLUDE += exeJniInvocationTest.c > endif > > +ifeq ($(call isTargetOs, linux), true) > + # Unconditionally compile with debug symbols and don't ever perform > + # stripping during the test libraries' build. > + BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libFib := -g > + BUILD_JDK_JTREG_LIBRARIES_STRIP_SYMBOLS_libFib := false > +endif > + > + > $(eval $(call SetupTestFilesCompilation, BUILD_JDK_JTREG_LIBRARIES, \ > TYPE := LIBRARY, \ > SOURCE_DIRS := $(BUILD_JDK_JTREG_NATIVE_SRC), \ > > Thanks, > Severin +1 /Magnus > From matthias.baesken at sap.com Mon Feb 18 12:52:59 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 18 Feb 2019 12:52:59 +0000 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: References: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> <8a9cf0ba-6641-6a80-caeb-e42abf64ad61@oracle.com> <97bb3895-269d-dac2-8fc5-7b1480646f99@oracle.com> Message-ID: Hello Martin and Magnus, I included Martin?s harfbuzz fix and adjusted the xlc version check ( renamed variable to XLC_USES_CLANG and also check the TOOLCHAIN_PATH ) . > >If we're talking about a short migration story, where soon XLC 16 will be required, and we can just replace >TOOLCHAIN_CC_BINARY_xlc="xlc_r" >with >TOOLCHAIN_CC_BINARY_xlc="xlclang" > then I can accept it anyway, so we don't need to complicate things. > Yes , that?s the idea - to do the replacement above sooner or later ; depends of course also on the introduction of the C++11/14 features in the code base . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.1/ Best Regards, Matthias From: Magnus Ihse Bursie Sent: Montag, 18. Februar 2019 11:18 To: Baesken, Matthias ; 'build-dev at openjdk.java.net' Cc: Doerr, Martin Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection On 2019-02-15 14:30, Baesken, Matthias wrote: Are they both pointing to the same binary, and the mode of operation (legacy xlc vs xlclang) is determined by the name of the executable? Hello, in the installation I use I have separate binaries . Is xlclang++ always available for version 16+ of xlc? I think so, as least I am not aware of an installation mode with separate binaries . However I am not an XLC installation guru ? . If so, maybe we should just make sure we call the compiler with the correct name if version 16+ is detected? I thought that we currently first set the toolchain name and then set a fix name for the binary and check the version . But I might be wrong. Maybe we need to adjust this . Or just at some future point in time declare xlc16 as minimum requirement (this makes things easier , we can then use the new binary names ). Yeah, we can adjust the process if needed. And to solve this *properly*, we should. I still think this looks like the wrong way to do it. But... If we're talking about a short migration story, where soon XLC 16 will be required, and we can just replace TOOLCHAIN_CC_BINARY_xlc="xlc_r" with TOOLCHAIN_CC_BINARY_xlc="xlclang" then I can accept it anyway, so we don't need to complicate things. I also don't like how xlclang is just run from the path, but OTOH it's only you guys who are going to run that in practice, and it's just going to be temporary, so, whatever. The name AIX_USE_CLANG is not really correct, though. This is not about AIX. It should be XLC_USE_CLANG (or maybe better XLC_USES_CLANG, even perhaps XLC_IS_CLANG?!). And, as I said, it should use true/false, not 0/1. If you fix this, and we agree that this is a temporary measure, I'm OK with the patch. /Magnus From martin.doerr at sap.com Mon Feb 18 14:37:28 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Feb 2019 14:37:28 +0000 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: References: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> <8a9cf0ba-6641-6a80-caeb-e42abf64ad61@oracle.com> <97bb3895-269d-dac2-8fc5-7b1480646f99@oracle.com> Message-ID: Hi Matthias, excellent. Looks good to me. This should make AIX ready for JEP 347. Thanks Martin From: Baesken, Matthias Sent: Montag, 18. Februar 2019 13:53 To: Magnus Ihse Bursie ; 'build-dev at openjdk.java.net' Cc: Doerr, Martin Subject: RE: RFR : 8218965: aix: support xlclang++ in the compiler detection Hello Martin and Magnus, I included Martin?s harfbuzz fix and adjusted the xlc version check ( renamed variable to XLC_USES_CLANG and also check the TOOLCHAIN_PATH ) . > >If we're talking about a short migration story, where soon XLC 16 will be required, and we can just replace >TOOLCHAIN_CC_BINARY_xlc="xlc_r" >with >TOOLCHAIN_CC_BINARY_xlc="xlclang" > then I can accept it anyway, so we don't need to complicate things. > Yes , that?s the idea - to do the replacement above sooner or later ; depends of course also on the introduction of the C++11/14 features in the code base . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.1/ Best Regards, Matthias From: Magnus Ihse Bursie > Sent: Montag, 18. Februar 2019 11:18 To: Baesken, Matthias >; 'build-dev at openjdk.java.net' > Cc: Doerr, Martin > Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection On 2019-02-15 14:30, Baesken, Matthias wrote: Are they both pointing to the same binary, and the mode of operation (legacy xlc vs xlclang) is determined by the name of the executable? Hello, in the installation I use I have separate binaries . Is xlclang++ always available for version 16+ of xlc? I think so, as least I am not aware of an installation mode with separate binaries . However I am not an XLC installation guru ? . If so, maybe we should just make sure we call the compiler with the correct name if version 16+ is detected? I thought that we currently first set the toolchain name and then set a fix name for the binary and check the version . But I might be wrong. Maybe we need to adjust this . Or just at some future point in time declare xlc16 as minimum requirement (this makes things easier , we can then use the new binary names ). Yeah, we can adjust the process if needed. And to solve this *properly*, we should. I still think this looks like the wrong way to do it. But... If we're talking about a short migration story, where soon XLC 16 will be required, and we can just replace TOOLCHAIN_CC_BINARY_xlc="xlc_r" with TOOLCHAIN_CC_BINARY_xlc="xlclang" then I can accept it anyway, so we don't need to complicate things. I also don't like how xlclang is just run from the path, but OTOH it's only you guys who are going to run that in practice, and it's just going to be temporary, so, whatever. The name AIX_USE_CLANG is not really correct, though. This is not about AIX. It should be XLC_USE_CLANG (or maybe better XLC_USES_CLANG, even perhaps XLC_IS_CLANG?!). And, as I said, it should use true/false, not 0/1. If you fix this, and we agree that this is a temporary measure, I'm OK with the patch. /Magnus From magnus.ihse.bursie at oracle.com Mon Feb 18 14:46:02 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Feb 2019 15:46:02 +0100 Subject: RFR : 8218965: aix: support xlclang++ in the compiler detection In-Reply-To: References: <6ab5f7f3-656d-7b51-91a0-6b6eb8ce510d@oracle.com> <8a9cf0ba-6641-6a80-caeb-e42abf64ad61@oracle.com> <97bb3895-269d-dac2-8fc5-7b1480646f99@oracle.com> Message-ID: <464DC1FF-C05A-4EB0-91A8-593BB36E153E@oracle.com> Looks good to me. /Magnus > 18 feb. 2019 kl. 15:37 skrev Doerr, Martin : > > Hi Matthias, > > excellent. Looks good to me. This should make AIX ready for JEP 347. > > Thanks > Martin > > > From: Baesken, Matthias > Sent: Montag, 18. Februar 2019 13:53 > To: Magnus Ihse Bursie ; 'build-dev at openjdk.java.net' > Cc: Doerr, Martin > Subject: RE: RFR : 8218965: aix: support xlclang++ in the compiler detection > > Hello Martin and Magnus, > > I included Martin?s harfbuzz fix and adjusted the xlc version check ( renamed variable to XLC_USES_CLANG and also check the TOOLCHAIN_PATH ) . > > > > >If we're talking about a short migration story, where soon XLC 16 will be required, and we can just replace > >TOOLCHAIN_CC_BINARY_xlc="xlc_r" > >with > >TOOLCHAIN_CC_BINARY_xlc="xlclang" > > then I can accept it anyway, so we don't need to complicate things. > > > > Yes , that?s the idea - to do the replacement above sooner or later ; depends of course also on the introduction of the C++11/14 features in the code base . > > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.1/ > > > Best Regards, Matthias > > > > From: Magnus Ihse Bursie > Sent: Montag, 18. Februar 2019 11:18 > To: Baesken, Matthias ; 'build-dev at openjdk.java.net' > Cc: Doerr, Martin > Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection > > > > On 2019-02-15 14:30, Baesken, Matthias wrote: > > Are they both pointing to the same binary, and the mode of operation > (legacy xlc vs xlclang) is determined by the name of the executable? > > > Hello, in the installation I use I have separate binaries . > > > > Is xlclang++ always available for version 16+ of xlc? > > > I think so, as least I am not aware of an installation mode with separate binaries . > However I am not an XLC installation guru ? . > > > If so, maybe we should just make sure we call the compiler with the > correct name if version 16+ is detected? > > > I thought that we currently first set the toolchain name and then set a fix name for the binary and check the version . > But I might be wrong. Maybe we need to adjust this . > Or just at some future point in time declare xlc16 as minimum requirement (this makes things easier , we can then use the new binary names ). > > Yeah, we can adjust the process if needed. And to solve this *properly*, we should. I still think this looks like the wrong way to do it. But... > > If we're talking about a short migration story, where soon XLC 16 will be required, and we can just replace > > TOOLCHAIN_CC_BINARY_xlc="xlc_r" > with > > TOOLCHAIN_CC_BINARY_xlc="xlclang" > then I can accept it anyway, so we don't need to complicate things. > > I also don't like how xlclang is just run from the path, but OTOH it's only you guys who are going to run that in practice, and it's just going to be temporary, so, whatever. > > The name AIX_USE_CLANG is not really correct, though. This is not about AIX. It should be XLC_USE_CLANG (or maybe better XLC_USES_CLANG, even perhaps XLC_IS_CLANG?!). And, as I said, it should use true/false, not 0/1. > > If you fix this, and we agree that this is a temporary measure, I'm OK with the patch. > > /Magnus > > > > From claes.redestad at oracle.com Mon Feb 18 22:20:40 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 Feb 2019 23:20:40 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <4bbd9ce71073a494d211492308321604@xs4all.nl> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> Message-ID: <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> Hi, On 2019-02-18 22:34, Jorn Vernee wrote: > Hi Claes, > >> 1. Does running make test rather than make test-only work? > > No. Same error there. Sorry, I tried that first and then re-ran with > `test-only`. I also tried with a clean build FWIW. > >> 2. Can you run the benchmarks.jar directly? > > Yes, this is working, thanks. This way I can also pass extra flags to > JMH, which is nice :) > > --- > > FWIW, I also had some problems when running configure. > > ? 1.) I did not get a warning when I was missing --with-jmh for > configure, although it looks like there is supposed to be one (without > --with-jmh I got the same access error, but the benchmarks.jar did not > exist). --with-jmh is an optional configure flag, not sure what we could do to warn here. Perhaps there's some way to ensure certain make targets depend on the configure having been run with the necessary prerequistes. Sounds like a fine enhancement. > ? 2.) My path to the --with-jmh folder had spaces in it, which was > causing an error in make/autoconf/lib-tests.m4 on line 76 [1]. Sounds like a bug. > > But those both had obvious workarounds. > > --- > > I was hoping to use the framework for Panama, so I'd likely have some > native library as dependency of the benchmark. Is there currently any > support for building (native) dependencies automatically? There should be support in the build system _somewhere_, but adding a native library to a microbenchmark might still be a non-trivial enhancement to the current implementation. It'd be a great addition, though. I might have time to help out sometime soon, but I've got my hands full right now. Perhaps someone else on this list could advice? Thanks! /Claes > > Thanks, > Jorn > > [1] : > http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 > From jbvernee at xs4all.nl Mon Feb 18 22:38:19 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Mon, 18 Feb 2019 23:38:19 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> Message-ID: <87cec9d9c3855524782be92261546b79@xs4all.nl> Hi, >> ? 1.) I did not get a warning when I was missing --with-jmh for >> configure, although it looks like there is supposed to be one (without >> --with-jmh I got the same access error, but the benchmarks.jar did not >> exist). > > --with-jmh is an optional configure flag, not sure what we could do to > warn here. Perhaps there's some way to ensure certain make targets > depend on the configure having been run with the necessary > prerequistes. > Sounds like a fine enhancement. There seems to be a check for this in make/test/BuildMicrobenchmark.gmk [2]: ``` ifeq ($(JMH_CORE_JAR), ) $(info Error: JMH is missing. Please use configure --with-jmh.) $(error Cannot continue) endif ``` But this does not seem to be triggered. >> I was hoping to use the framework for Panama, so I'd likely have some >> native library as dependency of the benchmark. Is there currently any >> support for building (native) dependencies automatically? > > There should be support in the build system _somewhere_, but adding a > native library to a microbenchmark might still be a non-trivial > enhancement to the current implementation. It'd be a great addition, > though. I might have time to help out sometime soon, but I've got my > hands full right now. Perhaps someone else on this list could advice? The Panama native test sources are being built by 'make/test/JtregNativeJdk.gmk' I'm not sure it's possible to hook directly into that, but maybe it can serve as an example for adding a similar feature to the benchmark suite. I'll try looking into that. > Thanks! Thanks for the help! Jorn [2] : http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34 > /Claes > >> >> Thanks, >> Jorn >> >> [1] : >> http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 From jbvernee at xs4all.nl Tue Feb 19 11:49:03 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Tue, 19 Feb 2019 12:49:03 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <87cec9d9c3855524782be92261546b79@xs4all.nl> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> <87cec9d9c3855524782be92261546b79@xs4all.nl> Message-ID: Hi, I've taken a first stab at adding support for native dependencies: http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/ With a small test benchmark: http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/ Please be aware that both are based on the Panama/foreign branch [1]. I was not able to find a workaround for my problem with the jar file access unfortunately. So I have been testing by manually running the jar file with the expected arguments (but, that's not really testing the RunTests.gmk changes). It would be great if someone can offer a suggestion for that. The jar file is being created in make/test/BuildMicrobenchmark.gmk using the SetupJarArchive function [2]. The execution of the jar is done by code in RunTests.gmk [3]. I guess these 2 are racing to access the jar, and that is what's causing the error from the subject line. Otherwise, I can't really test this properly, so maybe someone else can take it from here. Cheers, Jorn [1] : http://hg.openjdk.java.net/panama/dev/shortlog/tip [2] : http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/test/BuildMicrobenchmark.gmk#l98 [3] : http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/RunTests.gmk#l692 Jorn Vernee schreef op 2019-02-18 23:38: > Hi, > >>> ? 1.) I did not get a warning when I was missing --with-jmh for >>> configure, although it looks like there is supposed to be one >>> (without --with-jmh I got the same access error, but the >>> benchmarks.jar did not exist). >> >> --with-jmh is an optional configure flag, not sure what we could do to >> warn here. Perhaps there's some way to ensure certain make targets >> depend on the configure having been run with the necessary >> prerequistes. >> Sounds like a fine enhancement. > > There seems to be a check for this in make/test/BuildMicrobenchmark.gmk > [2]: > > ``` > ifeq ($(JMH_CORE_JAR), ) > $(info Error: JMH is missing. Please use configure --with-jmh.) > $(error Cannot continue) > endif > ``` > > But this does not seem to be triggered. > >>> I was hoping to use the framework for Panama, so I'd likely have some >>> native library as dependency of the benchmark. Is there currently any >>> support for building (native) dependencies automatically? >> >> There should be support in the build system _somewhere_, but adding a >> native library to a microbenchmark might still be a non-trivial >> enhancement to the current implementation. It'd be a great addition, >> though. I might have time to help out sometime soon, but I've got my >> hands full right now. Perhaps someone else on this list could advice? > > The Panama native test sources are being built by > 'make/test/JtregNativeJdk.gmk' I'm not sure it's possible to hook > directly into that, but maybe it can serve as an example for adding a > similar feature to the benchmark suite. > > I'll try looking into that. > >> Thanks! > > Thanks for the help! > > Jorn > > [2] : > http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34 > >> /Claes >> >>> >>> Thanks, >>> Jorn >>> >>> [1] : >>> http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 From Roger.Riggs at oracle.com Tue Feb 19 16:49:18 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 19 Feb 2019 11:49:18 -0500 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> Message-ID: <661ca8a0-8761-83b8-9532-2e3deafbfbba@oracle.com> Hi Alexander, Some files appear to be moved with hg, but others are copied and deleted. Please use hg mv to retain the continuity of the history. Thanks, Roger On 02/15/2019 10:03 PM, Alexander Matveev wrote: > Hi Magnus, > > http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ > > Moved all files from "posix" to "unix" folder and reverted > Lib-jdk.jpackage.gmk changes. > Webrev updated with files moved, instead of add/remove. > > Thanks, > Alexander > > On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: >> >> >> On 2019-02-15 04:31, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - Moved native code under platform specific folder. >>> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >>> - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp >>> for Mac specific code to filter out some arguments. I decided to >>> keep it as is for now, since Mac specific code is small. >>> - Defines are used in Platform.cpp to initialize platform specific >>> classes. >>> - Removed all pragma warning and fixed all compilation warnings. >>> - Removed unused code. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ >> The JDK standard is to use "unix", not "posix", for the shared >> functionality between linux/solaris/macosx. You can keep the name >> "PosixPlatform.*" if you want, though; the important thing is the >> directory name. >> >> Also, if you do that, you do not need any changes to >> make/lib/Lib-jdk.jpackage.gmk, since that will be automatically >> understood by the build system. >> >> It looks from the webrev that you have "moved" the files by doing "hg >> add" and "hg remove". Please use "hg move" instead -- this will keep >> history intact, and it allows reviewers to see if you have also made >> changes to the moved files. >> >> (If you do have modified the moved file, reverting a "hg add+hg >> remove" process is a bit more tricky -- you need to do "hg forget" on >> the new file, rename it to something else (otherwise "hg move" will >> complain), "hg revert" the old file back in place, do a "hg move" >> from the old to the new, and then copy the modified, renamed file >> back over the target new file again.) >> >> /Magnus >>> >>> Thanks, >>> Alexander >> > From erik.joelsson at oracle.com Tue Feb 19 17:04:11 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Feb 2019 09:04:11 -0800 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> Message-ID: <6089d9ea-19eb-3e88-91d8-046d805cc25d@oracle.com> The problem with the jarfile looks to be a missing $(FIXPATH) when running microbenchmarks. The java process is simply unable to understand cygwin paths. Does this patch solve the issue for you, Jorn? diff -r 7c17199fa37d make/RunTests.gmk --- a/make/RunTests.gmk +++ b/make/RunTests.gmk @@ -690,7 +690,7 @@ ???? $$(call LogWarn, Running test '$$($1_TEST)') ???? $$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR)) ???? $$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/micro, \ -??? ??? $$($1_MICRO_TEST_JDK)/bin/java $$($1_MICRO_JAVA_OPTIONS) -jar $$($1_MICRO_BENCHMARKS_JAR) \ +??? ??? $$(FIXPATH) $$($1_MICRO_TEST_JDK)/bin/java $$($1_MICRO_JAVA_OPTIONS) -jar $$($1_MICRO_BENCHMARKS_JAR) \ ???? ??????? $$($1_MICRO_ITER) $$($1_MICRO_FORK) $$($1_MICRO_TIME) \ ???? ??????? $$($1_MICRO_WARMUP_ITER) $$($1_MICRO_WARMUP_TIME) \ ???? ??????? $$($1_MICRO_VM_OPTIONS) $$($1_MICRO_BASIC_OPTIONS) $$(MICRO_OPTIONS) \ /Erik On 2019-02-18 14:20, Claes Redestad wrote: > http://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002624.html> > > Hi, > > On 2019-02-18 22:34, Jorn Vernee wrote: >> Hi Claes, >> >>> 1. Does running make test rather than make test-only work? >> >> No. Same error there. Sorry, I tried that first and then re-ran with >> `test-only`. I also tried with a clean build FWIW. >> >>> 2. Can you run the benchmarks.jar directly? >> >> Yes, this is working, thanks. This way I can also pass extra flags to >> JMH, which is nice :) >> >> --- >> >> FWIW, I also had some problems when running configure. >> >> ?? 1.) I did not get a warning when I was missing --with-jmh for >> configure, although it looks like there is supposed to be one >> (without --with-jmh I got the same access error, but the >> benchmarks.jar did not exist). > > --with-jmh is an optional configure flag, not sure what we could do to > warn here. Perhaps there's some way to ensure certain make targets > depend on the configure having been run with the necessary prerequistes. > Sounds like a fine enhancement. > >> ?? 2.) My path to the --with-jmh folder had spaces in it, which was >> causing an error in make/autoconf/lib-tests.m4 on line 76 [1]. > > Sounds like a bug. > >> >> But those both had obvious workarounds. >> >> --- >> >> I was hoping to use the framework for Panama, so I'd likely have some >> native library as dependency of the benchmark. Is there currently any >> support for building (native) dependencies automatically? > > There should be support in the build system _somewhere_, but adding a > native library to a microbenchmark might still be a non-trivial > enhancement to the current implementation. It'd be a great addition, > though. I might have time to help out sometime soon, but I've got my > hands full right now. Perhaps someone else on this list could advice? > > Thanks! > > /Claes > >> >> Thanks, >> Jorn >> >> [1] : >> http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 >> From erik.joelsson at oracle.com Tue Feb 19 17:13:43 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Feb 2019 09:13:43 -0800 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> <87cec9d9c3855524782be92261546b79@xs4all.nl> Message-ID: Hello Jorn, This looks pretty good and should probably be pushed to mainline. Some minor nits. In BuildMicrobenchmark.gmk: Please base MICROBENCHMARK_IMAGE dir on TEST_IMAGE_DIR like in RunTests.gmk. Line 131, please add ", \" plus newline like on 123-124. /Erik On 2019-02-19 03:49, Jorn Vernee wrote: > Hi, > > I've taken a first stab at adding support for native dependencies: > http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/ > > With a small test benchmark: > http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/ > > Please be aware that both are based on the Panama/foreign branch [1]. > > I was not able to find a workaround for my problem with the jar file > access unfortunately. So I have been testing by manually running the > jar file with the expected arguments (but, that's not really testing > the RunTests.gmk changes). > > It would be great if someone can offer a suggestion for that. The jar > file is being created in make/test/BuildMicrobenchmark.gmk using the > SetupJarArchive function [2]. The execution of the jar is done by code > in RunTests.gmk [3]. I guess these 2 are racing to access the jar, and > that is what's causing the error from the subject line. > > Otherwise, I can't really test this properly, so maybe someone else > can take it from here. > > Cheers, > Jorn > > [1] : http://hg.openjdk.java.net/panama/dev/shortlog/tip > [2] : > http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/test/BuildMicrobenchmark.gmk#l98 > [3] : > http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/RunTests.gmk#l692 > > Jorn Vernee schreef op 2019-02-18 23:38: >> Hi, >> >>>> ?? 1.) I did not get a warning when I was missing --with-jmh for >>>> configure, although it looks like there is supposed to be one >>>> (without --with-jmh I got the same access error, but the >>>> benchmarks.jar did not exist). >>> >>> --with-jmh is an optional configure flag, not sure what we could do to >>> warn here. Perhaps there's some way to ensure certain make targets >>> depend on the configure having been run with the necessary >>> prerequistes. >>> Sounds like a fine enhancement. >> >> There seems to be a check for this in >> make/test/BuildMicrobenchmark.gmk [2]: >> >> ``` >> ifeq ($(JMH_CORE_JAR), ) >> ? $(info Error: JMH is missing. Please use configure --with-jmh.) >> ? $(error Cannot continue) >> endif >> ``` >> >> But this does not seem to be triggered. >> >>>> I was hoping to use the framework for Panama, so I'd likely have >>>> some native library as dependency of the benchmark. Is there >>>> currently any support for building (native) dependencies >>>> automatically? >>> >>> There should be support in the build system _somewhere_, but adding a >>> native library to a microbenchmark might still be a non-trivial >>> enhancement to the current implementation. It'd be a great addition, >>> though. I might have time to help out sometime soon, but I've got my >>> hands full right now. Perhaps someone else on this list could advice? >> >> The Panama native test sources are being built by >> 'make/test/JtregNativeJdk.gmk' I'm not sure it's possible to hook >> directly into that, but maybe it can serve as an example for adding a >> similar feature to the benchmark suite. >> >> I'll try looking into that. >> >>> Thanks! >> >> Thanks for the help! >> >> Jorn >> >> [2] : >> http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34 >> >> >>> /Claes >>> >>>> >>>> Thanks, >>>> Jorn >>>> >>>> [1] : >>>> http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 From jbvernee at xs4all.nl Tue Feb 19 18:11:43 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Tue, 19 Feb 2019 19:11:43 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <6089d9ea-19eb-3e88-91d8-046d805cc25d@oracle.com> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> <6089d9ea-19eb-3e88-91d8-046d805cc25d@oracle.com> Message-ID: <7b0b67e1e590d5681eb33d27178765d5@xs4all.nl> Yes, that fixes the problem. Thanks! Jorn Erik Joelsson schreef op 2019-02-19 18:04: > The problem with the jarfile looks to be a missing $(FIXPATH) when > running microbenchmarks. The java process is simply unable to > understand cygwin paths. Does this patch solve the issue for you, > Jorn? > > diff -r 7c17199fa37d make/RunTests.gmk > --- a/make/RunTests.gmk > +++ b/make/RunTests.gmk > @@ -690,7 +690,7 @@ > ???? $$(call LogWarn, Running test '$$($1_TEST)') > ???? $$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR)) > ???? $$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/micro, \ > -??? ??? $$($1_MICRO_TEST_JDK)/bin/java $$($1_MICRO_JAVA_OPTIONS) -jar > $$($1_MICRO_BENCHMARKS_JAR) \ > +??? ??? $$(FIXPATH) $$($1_MICRO_TEST_JDK)/bin/java > $$($1_MICRO_JAVA_OPTIONS) -jar $$($1_MICRO_BENCHMARKS_JAR) \ > ???? ??????? $$($1_MICRO_ITER) $$($1_MICRO_FORK) $$($1_MICRO_TIME) \ > ???? ??????? $$($1_MICRO_WARMUP_ITER) $$($1_MICRO_WARMUP_TIME) \ > ???? ??????? $$($1_MICRO_VM_OPTIONS) $$($1_MICRO_BASIC_OPTIONS) > $$(MICRO_OPTIONS) \ > > /Erik > > On 2019-02-18 14:20, Claes Redestad wrote: >> > http://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002624.html> >> >> Hi, >> >> On 2019-02-18 22:34, Jorn Vernee wrote: >>> Hi Claes, >>> >>>> 1. Does running make test rather than make test-only work? >>> >>> No. Same error there. Sorry, I tried that first and then re-ran with >>> `test-only`. I also tried with a clean build FWIW. >>> >>>> 2. Can you run the benchmarks.jar directly? >>> >>> Yes, this is working, thanks. This way I can also pass extra flags to >>> JMH, which is nice :) >>> >>> --- >>> >>> FWIW, I also had some problems when running configure. >>> >>> ?? 1.) I did not get a warning when I was missing --with-jmh for >>> configure, although it looks like there is supposed to be one >>> (without --with-jmh I got the same access error, but the >>> benchmarks.jar did not exist). >> >> --with-jmh is an optional configure flag, not sure what we could do to >> warn here. Perhaps there's some way to ensure certain make targets >> depend on the configure having been run with the necessary >> prerequistes. >> Sounds like a fine enhancement. >> >>> ?? 2.) My path to the --with-jmh folder had spaces in it, which was >>> causing an error in make/autoconf/lib-tests.m4 on line 76 [1]. >> >> Sounds like a bug. >> >>> >>> But those both had obvious workarounds. >>> >>> --- >>> >>> I was hoping to use the framework for Panama, so I'd likely have some >>> native library as dependency of the benchmark. Is there currently any >>> support for building (native) dependencies automatically? >> >> There should be support in the build system _somewhere_, but adding a >> native library to a microbenchmark might still be a non-trivial >> enhancement to the current implementation. It'd be a great addition, >> though. I might have time to help out sometime soon, but I've got my >> hands full right now. Perhaps someone else on this list could advice? >> >> Thanks! >> >> /Claes >> >>> >>> Thanks, >>> Jorn >>> >>> [1] : >>> http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 From jbvernee at xs4all.nl Tue Feb 19 18:35:12 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Tue, 19 Feb 2019 19:35:12 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> <87cec9d9c3855524782be92261546b79@xs4all.nl> Message-ID: <506bc01d70ce3026f94fe2255b15d6d9@xs4all.nl> Hi Erik, I have included your suggestions: http://cr.openjdk.java.net/~jvernee/micronative/webrev.01 I'm a committer on project Panama, but I'm not sure if I have write access to jdk/jdk as well. If the new webrev looks good I could give it a try, but otherwise someone else would have to create a commit for me. Thanks, Jorn Erik Joelsson schreef op 2019-02-19 18:13: > Hello Jorn, > > This looks pretty good and should probably be pushed to mainline. Some > minor nits. > > In BuildMicrobenchmark.gmk: > > Please base MICROBENCHMARK_IMAGE dir on TEST_IMAGE_DIR like in > RunTests.gmk. > > Line 131, please add ", \" plus newline like on 123-124. > > /Erik > > On 2019-02-19 03:49, Jorn Vernee wrote: >> Hi, >> >> I've taken a first stab at adding support for native dependencies: >> http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/ >> >> With a small test benchmark: >> http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/ >> >> Please be aware that both are based on the Panama/foreign branch [1]. >> >> I was not able to find a workaround for my problem with the jar file >> access unfortunately. So I have been testing by manually running the >> jar file with the expected arguments (but, that's not really testing >> the RunTests.gmk changes). >> >> It would be great if someone can offer a suggestion for that. The jar >> file is being created in make/test/BuildMicrobenchmark.gmk using the >> SetupJarArchive function [2]. The execution of the jar is done by code >> in RunTests.gmk [3]. I guess these 2 are racing to access the jar, and >> that is what's causing the error from the subject line. >> >> Otherwise, I can't really test this properly, so maybe someone else >> can take it from here. >> >> Cheers, >> Jorn >> >> [1] : http://hg.openjdk.java.net/panama/dev/shortlog/tip >> [2] : >> http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/test/BuildMicrobenchmark.gmk#l98 >> [3] : >> http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/RunTests.gmk#l692 >> >> Jorn Vernee schreef op 2019-02-18 23:38: >>> Hi, >>> >>>>> ?? 1.) I did not get a warning when I was missing --with-jmh for >>>>> configure, although it looks like there is supposed to be one >>>>> (without --with-jmh I got the same access error, but the >>>>> benchmarks.jar did not exist). >>>> >>>> --with-jmh is an optional configure flag, not sure what we could do >>>> to >>>> warn here. Perhaps there's some way to ensure certain make targets >>>> depend on the configure having been run with the necessary >>>> prerequistes. >>>> Sounds like a fine enhancement. >>> >>> There seems to be a check for this in >>> make/test/BuildMicrobenchmark.gmk [2]: >>> >>> ``` >>> ifeq ($(JMH_CORE_JAR), ) >>> ? $(info Error: JMH is missing. Please use configure --with-jmh.) >>> ? $(error Cannot continue) >>> endif >>> ``` >>> >>> But this does not seem to be triggered. >>> >>>>> I was hoping to use the framework for Panama, so I'd likely have >>>>> some native library as dependency of the benchmark. Is there >>>>> currently any support for building (native) dependencies >>>>> automatically? >>>> >>>> There should be support in the build system _somewhere_, but adding >>>> a >>>> native library to a microbenchmark might still be a non-trivial >>>> enhancement to the current implementation. It'd be a great addition, >>>> though. I might have time to help out sometime soon, but I've got my >>>> hands full right now. Perhaps someone else on this list could >>>> advice? >>> >>> The Panama native test sources are being built by >>> 'make/test/JtregNativeJdk.gmk' I'm not sure it's possible to hook >>> directly into that, but maybe it can serve as an example for adding a >>> similar feature to the benchmark suite. >>> >>> I'll try looking into that. >>> >>>> Thanks! >>> >>> Thanks for the help! >>> >>> Jorn >>> >>> [2] : >>> http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34 >>>> /Claes >>>> >>>>> >>>>> Thanks, >>>>> Jorn >>>>> >>>>> [1] : >>>>> http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 From igor.ignatyev at oracle.com Tue Feb 19 19:46:46 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 11:46:46 -0800 Subject: RFR(S) : 8219391 : extend gcov support to llvm/clang Message-ID: <8E0BE21B-BF07-4B0B-B1B0-BD0AA3D008AC@oracle.com> http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00 > 21 lines changed: 3 ins; 0 del; 18 mod; Hi all, could you please review this small and trivial patch which allows usage of --enable-native-coverage configure option w/ clang devkit? > llvm/clang supports gcov in the same way gcc does, it has the same compiler/linker options to enable code coverage information, produces the same .gcda files; the produced binaries generate .gcdo files and treat env. variables in the same way. webrev: http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8219391 testing: built on mac w/ --enable-native-coverage, run some tests and spot-checked coverage Thanks, -- Igor From martinrb at google.com Tue Feb 19 20:03:26 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Feb 2019 12:03:26 -0800 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <506bc01d70ce3026f94fe2255b15d6d9@xs4all.nl> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> <87cec9d9c3855524782be92261546b79@xs4all.nl> <506bc01d70ce3026f94fe2255b15d6d9@xs4all.nl> Message-ID: On Tue, Feb 19, 2019 at 10:37 AM Jorn Vernee wrote: > > I'm a committer on project Panama, but I'm not sure if I have write > access to jdk/jdk as well. You don't https://openjdk.java.net/census#jvernee From erik.joelsson at oracle.com Tue Feb 19 20:35:50 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Feb 2019 12:35:50 -0800 Subject: RFR(S) : 8219391 : extend gcov support to llvm/clang In-Reply-To: <8E0BE21B-BF07-4B0B-B1B0-BD0AA3D008AC@oracle.com> References: <8E0BE21B-BF07-4B0B-B1B0-BD0AA3D008AC@oracle.com> Message-ID: Looks good. Does this mean it works on Macos? /Erik On 2019-02-19 11:46, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00 >> 21 lines changed: 3 ins; 0 del; 18 mod; > Hi all, > > could you please review this small and trivial patch which allows usage of --enable-native-coverage configure option w/ clang devkit? > >> llvm/clang supports gcov in the same way gcc does, it has the same compiler/linker options to enable code coverage information, produces the same .gcda files; the produced binaries generate .gcdo files and treat env. variables in the same way. > webrev: http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8219391 > testing: built on mac w/ --enable-native-coverage, run some tests and spot-checked coverage > > Thanks, > -- Igor > From claes.redestad at oracle.com Tue Feb 19 21:36:30 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 Feb 2019 22:36:30 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <506bc01d70ce3026f94fe2255b15d6d9@xs4all.nl> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> <87cec9d9c3855524782be92261546b79@xs4all.nl> <506bc01d70ce3026f94fe2255b15d6d9@xs4all.nl> Message-ID: <569fd375-ec04-0b73-a7e9-c7f8ef652d9c@oracle.com> Hi Jorn, I'll sponsor this for jdk/jdk. I'll file a RFE, test it and push it seeing it's already reviewed. Thanks! /Claes On 2019-02-19 19:35, Jorn Vernee wrote: > Hi Erik, > > I have included your suggestions: > http://cr.openjdk.java.net/~jvernee/micronative/webrev.01 > > I'm a committer on project Panama, but I'm not sure if I have write > access to jdk/jdk as well. If the new webrev looks good I could give it > a try, but otherwise someone else would have to create a commit for me. > > Thanks, > Jorn > > Erik Joelsson schreef op 2019-02-19 18:13: >> Hello Jorn, >> >> This looks pretty good and should probably be pushed to mainline. Some >> minor nits. >> >> In BuildMicrobenchmark.gmk: >> >> Please base MICROBENCHMARK_IMAGE dir on TEST_IMAGE_DIR like in >> RunTests.gmk. >> >> Line 131, please add ", \" plus newline like on 123-124. >> >> /Erik >> >> On 2019-02-19 03:49, Jorn Vernee wrote: >>> Hi, >>> >>> I've taken a first stab at adding support for native dependencies: >>> http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/ >>> >>> With a small test benchmark: >>> http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/ >>> >>> Please be aware that both are based on the Panama/foreign branch [1]. >>> >>> I was not able to find a workaround for my problem with the jar file >>> access unfortunately. So I have been testing by manually running the >>> jar file with the expected arguments (but, that's not really testing >>> the RunTests.gmk changes). >>> >>> It would be great if someone can offer a suggestion for that. The jar >>> file is being created in make/test/BuildMicrobenchmark.gmk using the >>> SetupJarArchive function [2]. The execution of the jar is done by >>> code in RunTests.gmk [3]. I guess these 2 are racing to access the >>> jar, and that is what's causing the error from the subject line. >>> >>> Otherwise, I can't really test this properly, so maybe someone else >>> can take it from here. >>> >>> Cheers, >>> Jorn >>> >>> [1] : http://hg.openjdk.java.net/panama/dev/shortlog/tip >>> [2] : >>> http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/test/BuildMicrobenchmark.gmk#l98 >>> >>> [3] : >>> http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/RunTests.gmk#l692 >>> >>> >>> Jorn Vernee schreef op 2019-02-18 23:38: >>>> Hi, >>>> >>>>>> ?? 1.) I did not get a warning when I was missing --with-jmh for >>>>>> configure, although it looks like there is supposed to be one >>>>>> (without --with-jmh I got the same access error, but the >>>>>> benchmarks.jar did not exist). >>>>> >>>>> --with-jmh is an optional configure flag, not sure what we could do to >>>>> warn here. Perhaps there's some way to ensure certain make targets >>>>> depend on the configure having been run with the necessary >>>>> prerequistes. >>>>> Sounds like a fine enhancement. >>>> >>>> There seems to be a check for this in >>>> make/test/BuildMicrobenchmark.gmk [2]: >>>> >>>> ``` >>>> ifeq ($(JMH_CORE_JAR), ) >>>> ? $(info Error: JMH is missing. Please use configure --with-jmh.) >>>> ? $(error Cannot continue) >>>> endif >>>> ``` >>>> >>>> But this does not seem to be triggered. >>>> >>>>>> I was hoping to use the framework for Panama, so I'd likely have >>>>>> some native library as dependency of the benchmark. Is there >>>>>> currently any support for building (native) dependencies >>>>>> automatically? >>>>> >>>>> There should be support in the build system _somewhere_, but adding a >>>>> native library to a microbenchmark might still be a non-trivial >>>>> enhancement to the current implementation. It'd be a great addition, >>>>> though. I might have time to help out sometime soon, but I've got my >>>>> hands full right now. Perhaps someone else on this list could advice? >>>> >>>> The Panama native test sources are being built by >>>> 'make/test/JtregNativeJdk.gmk' I'm not sure it's possible to hook >>>> directly into that, but maybe it can serve as an example for adding a >>>> similar feature to the benchmark suite. >>>> >>>> I'll try looking into that. >>>> >>>>> Thanks! >>>> >>>> Thanks for the help! >>>> >>>> Jorn >>>> >>>> [2] : >>>> http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34 >>>> >>>>> /Claes >>>>> >>>>>> >>>>>> Thanks, >>>>>> Jorn >>>>>> >>>>>> [1] : >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 >>>>>> From jbvernee at xs4all.nl Tue Feb 19 21:41:14 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Tue, 19 Feb 2019 22:41:14 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <569fd375-ec04-0b73-a7e9-c7f8ef652d9c@oracle.com> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> <87cec9d9c3855524782be92261546b79@xs4all.nl> <506bc01d70ce3026f94fe2255b15d6d9@xs4all.nl> <569fd375-ec04-0b73-a7e9-c7f8ef652d9c@oracle.com> Message-ID: <7e15d1b541a593489070fd8a77b4a830@xs4all.nl> Great! Thanks for picking this up. Jorn Claes Redestad schreef op 2019-02-19 22:36: > Hi Jorn, > > I'll sponsor this for jdk/jdk. I'll file a RFE, test it and push it > seeing it's already reviewed. > > Thanks! > > /Claes > > On 2019-02-19 19:35, Jorn Vernee wrote: >> Hi Erik, >> >> I have included your suggestions: >> http://cr.openjdk.java.net/~jvernee/micronative/webrev.01 >> >> I'm a committer on project Panama, but I'm not sure if I have write >> access to jdk/jdk as well. If the new webrev looks good I could give >> it a try, but otherwise someone else would have to create a commit for >> me. >> >> Thanks, >> Jorn >> >> Erik Joelsson schreef op 2019-02-19 18:13: >>> Hello Jorn, >>> >>> This looks pretty good and should probably be pushed to mainline. >>> Some >>> minor nits. >>> >>> In BuildMicrobenchmark.gmk: >>> >>> Please base MICROBENCHMARK_IMAGE dir on TEST_IMAGE_DIR like in >>> RunTests.gmk. >>> >>> Line 131, please add ", \" plus newline like on 123-124. >>> >>> /Erik >>> >>> On 2019-02-19 03:49, Jorn Vernee wrote: >>>> Hi, >>>> >>>> I've taken a first stab at adding support for native dependencies: >>>> http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/ >>>> >>>> With a small test benchmark: >>>> http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/ >>>> >>>> Please be aware that both are based on the Panama/foreign branch >>>> [1]. >>>> >>>> I was not able to find a workaround for my problem with the jar file >>>> access unfortunately. So I have been testing by manually running the >>>> jar file with the expected arguments (but, that's not really testing >>>> the RunTests.gmk changes). >>>> >>>> It would be great if someone can offer a suggestion for that. The >>>> jar file is being created in make/test/BuildMicrobenchmark.gmk using >>>> the SetupJarArchive function [2]. The execution of the jar is done >>>> by code in RunTests.gmk [3]. I guess these 2 are racing to access >>>> the jar, and that is what's causing the error from the subject line. >>>> >>>> Otherwise, I can't really test this properly, so maybe someone else >>>> can take it from here. >>>> >>>> Cheers, >>>> Jorn >>>> >>>> [1] : http://hg.openjdk.java.net/panama/dev/shortlog/tip >>>> [2] : >>>> http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/test/BuildMicrobenchmark.gmk#l98 >>>> [3] : >>>> http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/RunTests.gmk#l692 >>>> Jorn Vernee schreef op 2019-02-18 23:38: >>>>> Hi, >>>>> >>>>>>> ?? 1.) I did not get a warning when I was missing --with-jmh for >>>>>>> configure, although it looks like there is supposed to be one >>>>>>> (without --with-jmh I got the same access error, but the >>>>>>> benchmarks.jar did not exist). >>>>>> >>>>>> --with-jmh is an optional configure flag, not sure what we could >>>>>> do to >>>>>> warn here. Perhaps there's some way to ensure certain make targets >>>>>> depend on the configure having been run with the necessary >>>>>> prerequistes. >>>>>> Sounds like a fine enhancement. >>>>> >>>>> There seems to be a check for this in >>>>> make/test/BuildMicrobenchmark.gmk [2]: >>>>> >>>>> ``` >>>>> ifeq ($(JMH_CORE_JAR), ) >>>>> ? $(info Error: JMH is missing. Please use configure --with-jmh.) >>>>> ? $(error Cannot continue) >>>>> endif >>>>> ``` >>>>> >>>>> But this does not seem to be triggered. >>>>> >>>>>>> I was hoping to use the framework for Panama, so I'd likely have >>>>>>> some native library as dependency of the benchmark. Is there >>>>>>> currently any support for building (native) dependencies >>>>>>> automatically? >>>>>> >>>>>> There should be support in the build system _somewhere_, but >>>>>> adding a >>>>>> native library to a microbenchmark might still be a non-trivial >>>>>> enhancement to the current implementation. It'd be a great >>>>>> addition, >>>>>> though. I might have time to help out sometime soon, but I've got >>>>>> my >>>>>> hands full right now. Perhaps someone else on this list could >>>>>> advice? >>>>> >>>>> The Panama native test sources are being built by >>>>> 'make/test/JtregNativeJdk.gmk' I'm not sure it's possible to hook >>>>> directly into that, but maybe it can serve as an example for adding >>>>> a >>>>> similar feature to the benchmark suite. >>>>> >>>>> I'll try looking into that. >>>>> >>>>>> Thanks! >>>>> >>>>> Thanks for the help! >>>>> >>>>> Jorn >>>>> >>>>> [2] : >>>>> http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34 >>>>>> /Claes >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Jorn >>>>>>> >>>>>>> [1] : >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 From erik.joelsson at oracle.com Tue Feb 19 21:45:37 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Feb 2019 13:45:37 -0800 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <506bc01d70ce3026f94fe2255b15d6d9@xs4all.nl> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> <87cec9d9c3855524782be92261546b79@xs4all.nl> <506bc01d70ce3026f94fe2255b15d6d9@xs4all.nl> Message-ID: <230f88dc-ed85-b1a1-c787-510b0f0410e4@oracle.com> Thanks, looks good! /Erik On 2019-02-19 10:35, Jorn Vernee wrote: > Hi Erik, > > I have included your suggestions: > http://cr.openjdk.java.net/~jvernee/micronative/webrev.01 > > I'm a committer on project Panama, but I'm not sure if I have write > access to jdk/jdk as well. If the new webrev looks good I could give > it a try, but otherwise someone else would have to create a commit for > me. > > Thanks, > Jorn > > Erik Joelsson schreef op 2019-02-19 18:13: >> Hello Jorn, >> >> This looks pretty good and should probably be pushed to mainline. Some >> minor nits. >> >> In BuildMicrobenchmark.gmk: >> >> Please base MICROBENCHMARK_IMAGE dir on TEST_IMAGE_DIR like in >> RunTests.gmk. >> >> Line 131, please add ", \" plus newline like on 123-124. >> >> /Erik >> >> On 2019-02-19 03:49, Jorn Vernee wrote: >>> Hi, >>> >>> I've taken a first stab at adding support for native dependencies: >>> http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/ >>> >>> With a small test benchmark: >>> http://cr.openjdk.java.net/~jvernee/micronative_test/webrev.00/ >>> >>> Please be aware that both are based on the Panama/foreign branch [1]. >>> >>> I was not able to find a workaround for my problem with the jar file >>> access unfortunately. So I have been testing by manually running the >>> jar file with the expected arguments (but, that's not really testing >>> the RunTests.gmk changes). >>> >>> It would be great if someone can offer a suggestion for that. The >>> jar file is being created in make/test/BuildMicrobenchmark.gmk using >>> the SetupJarArchive function [2]. The execution of the jar is done >>> by code in RunTests.gmk [3]. I guess these 2 are racing to access >>> the jar, and that is what's causing the error from the subject line. >>> >>> Otherwise, I can't really test this properly, so maybe someone else >>> can take it from here. >>> >>> Cheers, >>> Jorn >>> >>> [1] : http://hg.openjdk.java.net/panama/dev/shortlog/tip >>> [2] : >>> http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/test/BuildMicrobenchmark.gmk#l98 >>> [3] : >>> http://hg.openjdk.java.net/jdk/jdk/file/784537ff9c4e/make/RunTests.gmk#l692 >>> >>> Jorn Vernee schreef op 2019-02-18 23:38: >>>> Hi, >>>> >>>>>> ?? 1.) I did not get a warning when I was missing --with-jmh for >>>>>> configure, although it looks like there is supposed to be one >>>>>> (without --with-jmh I got the same access error, but the >>>>>> benchmarks.jar did not exist). >>>>> >>>>> --with-jmh is an optional configure flag, not sure what we could >>>>> do to >>>>> warn here. Perhaps there's some way to ensure certain make targets >>>>> depend on the configure having been run with the necessary >>>>> prerequistes. >>>>> Sounds like a fine enhancement. >>>> >>>> There seems to be a check for this in >>>> make/test/BuildMicrobenchmark.gmk [2]: >>>> >>>> ``` >>>> ifeq ($(JMH_CORE_JAR), ) >>>> ? $(info Error: JMH is missing. Please use configure --with-jmh.) >>>> ? $(error Cannot continue) >>>> endif >>>> ``` >>>> >>>> But this does not seem to be triggered. >>>> >>>>>> I was hoping to use the framework for Panama, so I'd likely have >>>>>> some native library as dependency of the benchmark. Is there >>>>>> currently any support for building (native) dependencies >>>>>> automatically? >>>>> >>>>> There should be support in the build system _somewhere_, but adding a >>>>> native library to a microbenchmark might still be a non-trivial >>>>> enhancement to the current implementation. It'd be a great addition, >>>>> though. I might have time to help out sometime soon, but I've got my >>>>> hands full right now. Perhaps someone else on this list could advice? >>>> >>>> The Panama native test sources are being built by >>>> 'make/test/JtregNativeJdk.gmk' I'm not sure it's possible to hook >>>> directly into that, but maybe it can serve as an example for adding a >>>> similar feature to the benchmark suite. >>>> >>>> I'll try looking into that. >>>> >>>>> Thanks! >>>> >>>> Thanks for the help! >>>> >>>> Jorn >>>> >>>> [2] : >>>> http://hg.openjdk.java.net/jdk/jdk/file/6fb43030a1b4/make/test/BuildMicrobenchmark.gmk#l34 >>>> >>>>> /Claes >>>>> >>>>>> >>>>>> Thanks, >>>>>> Jorn >>>>>> >>>>>> [1] : >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 From igor.ignatyev at oracle.com Tue Feb 19 21:51:42 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 13:51:42 -0800 Subject: RFR(S) : 8219391 : extend gcov support to llvm/clang In-Reply-To: References: <8E0BE21B-BF07-4B0B-B1B0-BD0AA3D008AC@oracle.com> Message-ID: <64F6E7A1-AB0E-4D5A-9359-35ADE6FD0396@oracle.com> thanks Erik, pushed. y, this means exactly that. -- Igor > On Feb 19, 2019, at 12:35 PM, Erik Joelsson wrote: > > Looks good. > > Does this mean it works on Macos? > > /Erik > > On 2019-02-19 11:46, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00 >>> 21 lines changed: 3 ins; 0 del; 18 mod; >> Hi all, >> >> could you please review this small and trivial patch which allows usage of --enable-native-coverage configure option w/ clang devkit? >> >>> llvm/clang supports gcov in the same way gcc does, it has the same compiler/linker options to enable code coverage information, produces the same .gcda files; the produced binaries generate .gcdo files and treat env. variables in the same way. >> webrev: http://cr.openjdk.java.net/~iignatyev//8219391/webrev.00 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219391 >> testing: built on mac w/ --enable-native-coverage, run some tests and spot-checked coverage >> >> Thanks, >> -- Igor >> From claes.redestad at oracle.com Tue Feb 19 21:59:37 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 Feb 2019 22:59:37 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <7e15d1b541a593489070fd8a77b4a830@xs4all.nl> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> <87cec9d9c3855524782be92261546b79@xs4all.nl> <506bc01d70ce3026f94fe2255b15d6d9@xs4all.nl> <569fd375-ec04-0b73-a7e9-c7f8ef652d9c@oracle.com> <7e15d1b541a593489070fd8a77b4a830@xs4all.nl> Message-ID: <33a6403d-a27b-d486-f882-26cd2aecbcf9@oracle.com> Pushed here: http://hg.openjdk.java.net/jdk/jdk/rev/1b40a0178b2a /Claes On 2019-02-19 22:41, Jorn Vernee wrote: > Great! Thanks for picking this up. > > Jorn From claes.redestad at oracle.com Tue Feb 19 22:04:45 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 Feb 2019 23:04:45 +0100 Subject: Running micro benchmark results in 'Error: Unable to access jarfile' In-Reply-To: <6089d9ea-19eb-3e88-91d8-046d805cc25d@oracle.com> References: <16148e879571c48749bd2f546b95c527@xs4all.nl> <4bbd9ce71073a494d211492308321604@xs4all.nl> <1570b7bf-41b2-e7b9-32fc-f8c4cbeb7670@oracle.com> <6089d9ea-19eb-3e88-91d8-046d805cc25d@oracle.com> Message-ID: <4d529741-532d-61ad-7bb9-08dbd51582fb@oracle.com> Looks good. I filed https://bugs.openjdk.java.net/browse/JDK-8219394 for this bug. Thanks! /Claes On 2019-02-19 18:04, Erik Joelsson wrote: > The problem with the jarfile looks to be a missing $(FIXPATH) when > running microbenchmarks. The java process is simply unable to understand > cygwin paths. Does this patch solve the issue for you, Jorn? > > diff -r 7c17199fa37d make/RunTests.gmk > --- a/make/RunTests.gmk > +++ b/make/RunTests.gmk > @@ -690,7 +690,7 @@ > ???? $$(call LogWarn, Running test '$$($1_TEST)') > ???? $$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR)) > ???? $$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/micro, \ > -??? ??? $$($1_MICRO_TEST_JDK)/bin/java $$($1_MICRO_JAVA_OPTIONS) -jar > $$($1_MICRO_BENCHMARKS_JAR) \ > +??? ??? $$(FIXPATH) $$($1_MICRO_TEST_JDK)/bin/java > $$($1_MICRO_JAVA_OPTIONS) -jar $$($1_MICRO_BENCHMARKS_JAR) \ > ???? ??????? $$($1_MICRO_ITER) $$($1_MICRO_FORK) $$($1_MICRO_TIME) \ > ???? ??????? $$($1_MICRO_WARMUP_ITER) $$($1_MICRO_WARMUP_TIME) \ > ???? ??????? $$($1_MICRO_VM_OPTIONS) $$($1_MICRO_BASIC_OPTIONS) > $$(MICRO_OPTIONS) \ > > /Erik > > On 2019-02-18 14:20, Claes Redestad wrote: >> > http://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002624.html> >> >> Hi, >> >> On 2019-02-18 22:34, Jorn Vernee wrote: >>> Hi Claes, >>> >>>> 1. Does running make test rather than make test-only work? >>> >>> No. Same error there. Sorry, I tried that first and then re-ran with >>> `test-only`. I also tried with a clean build FWIW. >>> >>>> 2. Can you run the benchmarks.jar directly? >>> >>> Yes, this is working, thanks. This way I can also pass extra flags to >>> JMH, which is nice :) >>> >>> --- >>> >>> FWIW, I also had some problems when running configure. >>> >>> ?? 1.) I did not get a warning when I was missing --with-jmh for >>> configure, although it looks like there is supposed to be one >>> (without --with-jmh I got the same access error, but the >>> benchmarks.jar did not exist). >> >> --with-jmh is an optional configure flag, not sure what we could do to >> warn here. Perhaps there's some way to ensure certain make targets >> depend on the configure having been run with the necessary prerequistes. >> Sounds like a fine enhancement. >> >>> ?? 2.) My path to the --with-jmh folder had spaces in it, which was >>> causing an error in make/autoconf/lib-tests.m4 on line 76 [1]. >> >> Sounds like a bug. >> >>> >>> But those both had obvious workarounds. >>> >>> --- >>> >>> I was hoping to use the framework for Panama, so I'd likely have some >>> native library as dependency of the benchmark. Is there currently any >>> support for building (native) dependencies automatically? >> >> There should be support in the build system _somewhere_, but adding a >> native library to a microbenchmark might still be a non-trivial >> enhancement to the current implementation. It'd be a great addition, >> though. I might have time to help out sometime soon, but I've got my >> hands full right now. Perhaps someone else on this list could advice? >> >> Thanks! >> >> /Claes >> >>> >>> Thanks, >>> Jorn >>> >>> [1] : >>> http://hg.openjdk.java.net/jdk/jdk/file/bec6c8739833/make/autoconf/lib-tests.m4#l76 >>> From igor.ignatyev at oracle.com Wed Feb 20 00:34:49 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 16:34:49 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 Message-ID: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html > 1 line changed: 0 ins; 0 del; 1 mod; Hi all, could you please review this one-liner which switch jtreg version to jtreg4.2-b14? webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies Thanks, -- Igor From ioi.lam at oracle.com Wed Feb 20 01:01:47 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 19 Feb 2019 17:01:47 -0800 Subject: Faster rebuild with GNU gold linker Message-ID: For the impatient engineers .... I did some measurement between the default GNU linker "ld" vs "ld.gold". I am trying to get the fastest rebuild time after I modify one cpp file. With gold, it's down to about 1/3 of the original time. slowdebug (~220MB libjvm.so) ???????????????? recompile 1 cpp file? |? relink libjvm.so only ld:? ?? ????????????? 33 s ????????????????? 25 s gold 1 thread:??????? 16 s ?????????? ? ? ? ? 9 s gold 8 threads:?????? 13 s ?????????????????? 6 s fastdebug (~360MB libjvm.so) ???????????????? recompile 1 cpp file? |? relink libjvm.so only ld:? ? ?? ??????????? 35 s ? ? ? ? ?????????? 25 s gold 1 thread:????? ? 18 s ?????????????????? 10 s gold 8 threads:???? ? 15 s ??????????????????? 6 s Question: do we want to add built-in support for gold into the JDK makefiles? Notes: To choose gold, run configure with something like: ??? --with-extra-ldflags='-fuse-ld=gold -Wl,--threads,--thread-count,8' I essentially do a "make hotspot" and then move the libjvm.so into a JDK image, instead of doing a full JDK image build. "make hotspot" makes a copy of libjvm.so (from support/modules_libs/java.base/server/ to jdk/lib/server/). I hacked the Makefile to make a hard link instead to avoid the unnecessary I/O. libjvm.so is built with --with-native-debug-symbols=internal to avoid the expensive invocations of objcopy and strip. My environment: I am using gcc7.3.0 on Ubuntu 16.04.5 on a 5 year old Dell Precision T7600 with dual socket Xeon E5-2665 @ 2.40GHz, 64GB RAM, Samsung 840 PRO SSD. I suspect gold can run even faster, but my slow SSD is holding it back. ld version?? = GNU ld (GNU Binutils) 2.30 gold version = GNU gold (GNU Binutils for Ubuntu 2.26.1) 1.11 (These are just the versions available to me on my machine, not necessarily the best) From erik.joelsson at oracle.com Wed Feb 20 01:01:34 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Feb 2019 17:01:34 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> Message-ID: <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> Looks good. Do we need to also bump the required version in the TEST.ROOT files? /Erik On 2019-02-19 16:34, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >> 1 line changed: 0 ins; 0 del; 1 mod; > Hi all, > > could you please review this one-liner which switch jtreg version to jtreg4.2-b14? > > webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 > testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies > > Thanks, > -- Igor From igor.ignatyev at oracle.com Wed Feb 20 01:06:59 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 17:06:59 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> Message-ID: Hi Erik, thanks for your review. we can't just bump the required version as it can introduce changes in tests' behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1], this will affect all the tests which have ${} in their @run directives, for example it will affect many vmTestbase tests which use PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after we clean up such tests and have filed 8219140[2] to deal w/ vmTestbase tests. I'll check if there are other tests which will be affected and will file RFE(s) to cover them as well. [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 [2] https://bugs.openjdk.java.net/browse/JDK-8219140 Thanks, -- Igor > On Feb 19, 2019, at 5:01 PM, Erik Joelsson wrote: > > Looks good. > > Do we need to also bump the required version in the TEST.ROOT files? > > /Erik > > On 2019-02-19 16:34, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>> 1 line changed: 0 ins; 0 del; 1 mod; >> Hi all, >> >> could you please review this one-liner which switch jtreg version to jtreg4.2-b14? >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 >> testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies >> >> Thanks, >> -- Igor From martinrb at google.com Wed Feb 20 01:23:41 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Feb 2019 17:23:41 -0800 Subject: Faster rebuild with GNU gold linker In-Reply-To: References: Message-ID: https://openjdk.markmail.org/thread/q3layufiyjivu42c On Tue, Feb 19, 2019 at 5:03 PM Ioi Lam wrote: > For the impatient engineers .... > > I did some measurement between the default GNU linker "ld" vs "ld.gold". > I am trying to get the fastest rebuild time after I modify one cpp file. > With gold, it's down to about 1/3 of the original time. > > > slowdebug (~220MB libjvm.so) > > recompile 1 cpp file | relink libjvm.so only > ld: 33 s 25 s > gold 1 thread: 16 s 9 s > gold 8 threads: 13 s 6 s > > > fastdebug (~360MB libjvm.so) > > > recompile 1 cpp file | relink libjvm.so only > ld: 35 s 25 s > gold 1 thread: 18 s 10 s > gold 8 threads: 15 s 6 s > > > Question: do we want to add built-in support for gold into the JDK > makefiles? > > > Notes: > > To choose gold, run configure with something like: > > --with-extra-ldflags='-fuse-ld=gold -Wl,--threads,--thread-count,8' > > I essentially do a "make hotspot" and then move the libjvm.so into a JDK > image, instead of doing a full JDK image build. > > "make hotspot" makes a copy of libjvm.so (from > support/modules_libs/java.base/server/ to jdk/lib/server/). I hacked the > Makefile to make a hard link instead to avoid the unnecessary I/O. > > libjvm.so is built with --with-native-debug-symbols=internal to avoid > the expensive invocations of objcopy and strip. > > > My environment: > > I am using gcc7.3.0 on Ubuntu 16.04.5 on a 5 year old Dell Precision > T7600 with dual socket Xeon E5-2665 @ 2.40GHz, 64GB RAM, Samsung 840 PRO > SSD. I suspect gold can run even faster, but my slow SSD is holding it > back. > > ld version = GNU ld (GNU Binutils) 2.30 > gold version = GNU gold (GNU Binutils for Ubuntu 2.26.1) 1.11 > > (These are just the versions available to me on my machine, not > necessarily the best) > > From igor.ignatyev at oracle.com Wed Feb 20 01:26:46 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 17:26:46 -0800 Subject: RFR(S) : 8219395 : integrate gcov w/ run-test Message-ID: <072FFA48-2587-42BD-9BF1-0B650F059AF6@oracle.com> http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html > 65 lines changed: 59 ins; 0 del; 6 mod; Hi all, could you please review the patch which makes it easy to run tests on the builds w/ native-code-coverage enabled? to do so the patch - sets GCOV_PREFIX env. variable, so .gcda files will be stored in build/*/test-results/gcov-output directory, and makes jtreg to propagate this env. variable to JDK under test - adds linux-x64-gcov and macosx-x64-gcov jib profiles - changes 'run-test-prebuilt' profile to set GCOV_ENABLED=true if it's the tested profile is -gcov profile and also fixes comment for JDKOPT_SETUP_CODE_COVERAGE in jdk-options.m4. webrev: http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8219395 testing: - :tier1 on {linux,macos}-x64 and {linux,macos}-x64-gcov - checked that *-gcov builds have .gcno files generated and stored in symbols bundle; and regular builds don't - checked that *-gcov runs have .gcda files generated in test-results/gcov-output; and runs on regular builds don't Thanks, -- Igor From joe.darcy at oracle.com Wed Feb 20 01:49:11 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 19 Feb 2019 17:49:11 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> Message-ID: <5C6CB217.80909@oracle.com> Hello, On 2/19/2019 5:06 PM, Igor Ignatyev wrote: > Hi Erik, > > thanks for your review. > > we can't just bump the required version as it can introduce changes in tests' behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1], From what I understand from Jon, allowSmartActionArgs is opt-in and has to be enabled in the TEST.ROOT file with allowSmartActionArgs=true Therefore, IIRC, the required version could be bumped without enabling smart action args. (I have a patch in progress to use smart action args for langtools tests: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012959.html) HTH, -Joe > this will affect all the tests which have ${} in their @run directives, for example it will affect many vmTestbase tests which use PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after we clean up such tests and have filed 8219140[2] to deal w/ vmTestbase tests. I'll check if there are other tests which will be affected and will file RFE(s) to cover them as well. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 > [2] https://bugs.openjdk.java.net/browse/JDK-8219140 > > Thanks, > -- Igor > >> On Feb 19, 2019, at 5:01 PM, Erik Joelsson wrote: >> >> Looks good. >> >> Do we need to also bump the required version in the TEST.ROOT files? >> >> /Erik >> >> On 2019-02-19 16:34, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>>> 1 line changed: 0 ins; 0 del; 1 mod; >>> Hi all, >>> >>> could you please review this one-liner which switch jtreg version to jtreg4.2-b14? >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 >>> testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies >>> >>> Thanks, >>> -- Igor From igor.ignatyev at oracle.com Wed Feb 20 01:54:08 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 17:54:08 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: <5C6CB217.80909@oracle.com> References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> <5C6CB217.80909@oracle.com> Message-ID: Joe, allowSmartActionArgs is opt-in if requiredVersion < b14, and opt-out if requiredVersion >= b14, please see http://hg.openjdk.java.net/code-tools/jtreg/rev/36c592d2f544 . so you don't have to have allowSmartActionArgs=true in 8219254. Thanks, -- Igor > On Feb 19, 2019, at 5:49 PM, Joseph D. Darcy wrote: > > Hello, > > On 2/19/2019 5:06 PM, Igor Ignatyev wrote: >> Hi Erik, >> >> thanks for your review. >> >> we can't just bump the required version as it can introduce changes in tests' behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1], > > From what I understand from Jon, allowSmartActionArgs is opt-in and has to be enabled in the TEST.ROOT file with > > allowSmartActionArgs=true > > Therefore, IIRC, the required version could be bumped without enabling smart action args. > > (I have a patch in progress to use smart action args for langtools tests: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012959.html) > > HTH, > > -Joe > >> this will affect all the tests which have ${} in their @run directives, for example it will affect many vmTestbase tests which use PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after we clean up such tests and have filed 8219140[2] to deal w/ vmTestbase tests. I'll check if there are other tests which will be affected and will file RFE(s) to cover them as well. >> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 >> [2] https://bugs.openjdk.java.net/browse/JDK-8219140 >> >> Thanks, >> -- Igor >> >>> On Feb 19, 2019, at 5:01 PM, Erik Joelsson wrote: >>> >>> Looks good. >>> >>> Do we need to also bump the required version in the TEST.ROOT files? >>> >>> /Erik >>> >>> On 2019-02-19 16:34, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>>>> 1 line changed: 0 ins; 0 del; 1 mod; >>>> Hi all, >>>> >>>> could you please review this one-liner which switch jtreg version to jtreg4.2-b14? >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 >>>> testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies >>>> >>>> Thanks, >>>> -- Igor > From joe.darcy at oracle.com Wed Feb 20 01:57:10 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 19 Feb 2019 17:57:10 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> <5C6CB217.80909@oracle.com> Message-ID: <5C6CB3F6.3050401@oracle.com> Hi Igor, On 2/19/2019 5:54 PM, Igor Ignatyev wrote: > Joe, > > allowSmartActionArgs is opt-in if requiredVersion < b14, and opt-out > if requiredVersion >= b14, please see > http://hg.openjdk.java.net/code-tools/jtreg/rev/36c592d2f544 . so you > don't have to have allowSmartActionArgs=true in 8219254. > > Thanks, > -- Igor > Thanks for the correction Igor; I'll update my patch accordingly. Cheers, -Joe From igor.ignatyev at oracle.com Wed Feb 20 03:32:24 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 19:32:24 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> Message-ID: <42C0334A-09DA-48CD-962C-087C12970BD8@oracle.com> I've pushed the patch. for the reference, 8219408 [1] was filed to handle jdk tests which have ${; the only affected hotspot tests are vmTestbase tests, so 8219140 [2] covers all hotspot tests. [1] https://bugs.openjdk.java.net/browse/JDK-8219408 [2] https://bugs.openjdk.java.net/browse/JDK-8219140 Thanks, -- Igor > On Feb 19, 2019, at 5:06 PM, Igor Ignatyev wrote: > > Hi Erik, > > thanks for your review. > > we can't just bump the required version as it can introduce changes in tests' behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1], this will affect all the tests which have ${} in their @run directives, for example it will affect many vmTestbase tests which use PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after we clean up such tests and have filed 8219140[2] to deal w/ vmTestbase tests. I'll check if there are other tests which will be affected and will file RFE(s) to cover them as well. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 > [2] https://bugs.openjdk.java.net/browse/JDK-8219140 > > Thanks, > -- Igor > >> On Feb 19, 2019, at 5:01 PM, Erik Joelsson wrote: >> >> Looks good. >> >> Do we need to also bump the required version in the TEST.ROOT files? >> >> /Erik >> >> On 2019-02-19 16:34, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>>> 1 line changed: 0 ins; 0 del; 1 mod; >>> Hi all, >>> >>> could you please review this one-liner which switch jtreg version to jtreg4.2-b14? >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 >>> testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies >>> >>> Thanks, >>> -- Igor > From alexander.matveev at oracle.com Wed Feb 20 03:44:52 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 19 Feb 2019 19:44:52 -0800 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: <661ca8a0-8761-83b8-9532-2e3deafbfbba@oracle.com> References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> <661ca8a0-8761-83b8-9532-2e3deafbfbba@oracle.com> Message-ID: Hi Roger, Some deleted files are actually deleted files, since I did code cleanup as well. Added files contain code from splitting original source files. This was needed to re-arrange code. Not sure how to log with hg file split. Also, we already moved files without keeping history, since we are not planing to keep history when moving jpackage from sandbox. Thanks, Alexander On 2/19/2019 8:49 AM, Roger Riggs wrote: > Hi Alexander, > > Some files appear to be moved with hg, but others are copied and deleted. > > Please use hg mv to retain the continuity of the history. > > Thanks, Roger > > On 02/15/2019 10:03 PM, Alexander Matveev wrote: >> Hi Magnus, >> >> http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ >> >> Moved all files from "posix" to "unix" folder and reverted >> Lib-jdk.jpackage.gmk changes. >> Webrev updated with files moved, instead of add/remove. >> >> Thanks, >> Alexander >> >> On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2019-02-15 04:31, Alexander Matveev wrote: >>>> Please review the jpackage fix for bug [1] at [2]. >>>> >>>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>>> repository (jpackage). >>>> >>>> - Moved native code under platform specific folder. >>>> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >>>> - MAC define is still used in JavaVirtualMachine.cpp and >>>> Package.cpp for Mac specific code to filter out some arguments. I >>>> decided to keep it as is for now, since Mac specific code is small. >>>> - Defines are used in Platform.cpp to initialize platform specific >>>> classes. >>>> - Removed all pragma warning and fixed all compilation warnings. >>>> - Removed unused code. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >>>> >>>> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ >>> The JDK standard is to use "unix", not "posix", for the shared >>> functionality between linux/solaris/macosx. You can keep the name >>> "PosixPlatform.*" if you want, though; the important thing is the >>> directory name. >>> >>> Also, if you do that, you do not need any changes to >>> make/lib/Lib-jdk.jpackage.gmk, since that will be automatically >>> understood by the build system. >>> >>> It looks from the webrev that you have "moved" the files by doing >>> "hg add" and "hg remove". Please use "hg move" instead -- this will >>> keep history intact, and it allows reviewers to see if you have also >>> made changes to the moved files. >>> >>> (If you do have modified the moved file, reverting a "hg add+hg >>> remove" process is a bit more tricky -- you need to do "hg forget" >>> on the new file, rename it to something else (otherwise "hg move" >>> will complain), "hg revert" the old file back in place, do a "hg >>> move" from the old to the new, and then copy the modified, renamed >>> file back over the target new file again.) >>> >>> /Magnus >>>> >>>> Thanks, >>>> Alexander >>> >> > From ioi.lam at oracle.com Wed Feb 20 06:35:07 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 19 Feb 2019 22:35:07 -0800 Subject: Faster rebuild with GNU gold linker In-Reply-To: References: Message-ID: Hi Martin, Thanks for the info. I didn't know that this has been discussed so recently. Should have checked befor I posted. Anyway, I built the latest lld from GIT, but it's slower than gold on my machine. Just linking libjvm.so is 5.8s vs 3.8s. On 2/19/19 5:23 PM, Martin Buchholz wrote: > https://openjdk.markmail.org/thread/q3layufiyjivu42c > > On Tue, Feb 19, 2019 at 5:03 PM Ioi Lam > wrote: > > For the impatient engineers .... > > I did some measurement between the default GNU linker "ld" vs > "ld.gold". > I am trying to get the fastest rebuild time after I modify one cpp > file. > With gold, it's down to about 1/3 of the original time. > > > slowdebug (~220MB libjvm.so) > > ????????????????? recompile 1 cpp file? |? relink libjvm.so only > ld:? ?? ????????????? 33 s ????????????????? 25 s > gold 1 thread:??????? 16 s ?????????? ? ? ? ? 9 s > gold 8 threads:?????? 13 s ?????????????????? 6 s > > > fastdebug (~360MB libjvm.so) > > > ????????????????? recompile 1 cpp file? |? relink libjvm.so only > ld:? ? ?? ??????????? 35 s ? ? ? ? ?????????? 25 s > gold 1 thread:????? ? 18 s ?????????????????? 10 s > gold 8 threads:???? ? 15 s ??????????????????? 6 s > > > Question: do we want to add built-in support for gold into the JDK > makefiles? > > > Notes: > > To choose gold, run configure with something like: > > ???? --with-extra-ldflags='-fuse-ld=gold > -Wl,--threads,--thread-count,8' > > I essentially do a "make hotspot" and then move the libjvm.so into > a JDK > image, instead of doing a full JDK image build. > > "make hotspot" makes a copy of libjvm.so (from > support/modules_libs/java.base/server/ to jdk/lib/server/). I > hacked the > Makefile to make a hard link instead to avoid the unnecessary I/O. > > libjvm.so is built with --with-native-debug-symbols=internal to avoid > the expensive invocations of objcopy and strip. > > > My environment: > > I am using gcc7.3.0 on Ubuntu 16.04.5 on a 5 year old Dell Precision > T7600 with dual socket Xeon E5-2665 @ 2.40GHz, 64GB RAM, Samsung > 840 PRO > SSD. I suspect gold can run even faster, but my slow SSD is > holding it back. > > ld version?? = GNU ld (GNU Binutils) 2.30 > gold version = GNU gold (GNU Binutils for Ubuntu 2.26.1) 1.11 > > (These are just the versions available to me on my machine, not > necessarily the best) > From Alan.Bateman at oracle.com Wed Feb 20 07:08:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2019 07:08:23 +0000 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> Message-ID: On 20/02/2019 00:34, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >> 1 line changed: 0 ins; 0 del; 1 mod; > Hi all, > > could you please review this one-liner which switch jtreg version to jtreg4.2-b14? > > webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 > testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies > I don't think we should rev this without also updating the `requiredVersion` key in the TEST.ROOT file at the top of each test suite. That is, I think we want everyone to use the same minimum version of jtreg, irrespective of how they run the tests. -Alan From ioi.lam at oracle.com Wed Feb 20 07:54:40 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 19 Feb 2019 23:54:40 -0800 Subject: Faster rebuild with GNU gold linker In-Reply-To: References: Message-ID: <23b0fc3d-bf2c-7a8c-e809-a955145c2c0f@oracle.com> Ahh, I was using a debug build of lld. After making a release build, the link time drops to 1.1 seconds! It's definitely better than gold. On 2/19/19 10:35 PM, Ioi Lam wrote: > Hi Martin, > > Thanks for the info. I didn't know that this has been discussed so > recently. Should have checked befor I posted. > > Anyway, I built the latest lld from GIT, but it's slower than gold on > my machine. Just linking libjvm.so is 5.8s vs 3.8s. > > On 2/19/19 5:23 PM, Martin Buchholz wrote: >> https://openjdk.markmail.org/thread/q3layufiyjivu42c >> >> On Tue, Feb 19, 2019 at 5:03 PM Ioi Lam > > wrote: >> >> ??? For the impatient engineers .... >> >> ??? I did some measurement between the default GNU linker "ld" vs >> ??? "ld.gold". >> ??? I am trying to get the fastest rebuild time after I modify one cpp >> ??? file. >> ??? With gold, it's down to about 1/3 of the original time. >> >> >> ??? slowdebug (~220MB libjvm.so) >> >> ??? ????????????????? recompile 1 cpp file? |? relink libjvm.so only >> ??? ld:? ?? ????????????? 33 s ????????????????? 25 s >> ??? gold 1 thread:??????? 16 s ?????????? ? ? ? ? 9 s >> ??? gold 8 threads:?????? 13 s ?????????????????? 6 s >> >> >> ??? fastdebug (~360MB libjvm.so) >> >> >> ??? ????????????????? recompile 1 cpp file? |? relink libjvm.so only >> ??? ld:? ? ?? ??????????? 35 s ? ? ? ? ?????????? 25 s >> ??? gold 1 thread:????? ? 18 s ?????????????????? 10 s >> ??? gold 8 threads:???? ? 15 s ??????????????????? 6 s >> >> >> ??? Question: do we want to add built-in support for gold into the JDK >> ??? makefiles? >> >> >> ??? Notes: >> >> ??? To choose gold, run configure with something like: >> >> ??? ???? --with-extra-ldflags='-fuse-ld=gold >> ??? -Wl,--threads,--thread-count,8' >> >> ??? I essentially do a "make hotspot" and then move the libjvm.so into >> ??? a JDK >> ??? image, instead of doing a full JDK image build. >> >> ??? "make hotspot" makes a copy of libjvm.so (from >> ??? support/modules_libs/java.base/server/ to jdk/lib/server/). I >> ??? hacked the >> ??? Makefile to make a hard link instead to avoid the unnecessary I/O. >> >> ??? libjvm.so is built with --with-native-debug-symbols=internal to >> avoid >> ??? the expensive invocations of objcopy and strip. >> >> >> ??? My environment: >> >> ??? I am using gcc7.3.0 on Ubuntu 16.04.5 on a 5 year old Dell Precision >> ??? T7600 with dual socket Xeon E5-2665 @ 2.40GHz, 64GB RAM, Samsung >> ??? 840 PRO >> ??? SSD. I suspect gold can run even faster, but my slow SSD is >> ??? holding it back. >> >> ??? ld version?? = GNU ld (GNU Binutils) 2.30 >> ??? gold version = GNU gold (GNU Binutils for Ubuntu 2.26.1) 1.11 >> >> ??? (These are just the versions available to me on my machine, not >> ??? necessarily the best) >> > From david.holmes at oracle.com Wed Feb 20 08:40:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2019 18:40:29 +1000 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> Message-ID: <414e2516-f078-3437-f9e9-1705069a3435@oracle.com> Hi Alan, On 20/02/2019 5:08 pm, Alan Bateman wrote: > > > On 20/02/2019 00:34, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>> 1 line changed: 0 ins; 0 del; 1 mod; >> Hi all, >> >> could you please review this one-liner which switch jtreg version to >> jtreg4.2-b14? >> >> webrev: >> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >> JBS:? https://bugs.openjdk.java.net/browse/JDK-8219132 >> testing: tier[1-5], client tests and jcstress test group testing >> showed no new failures; spot checking of .jtr files also didn't find >> any anomalies >> > I don't think we should rev this without also updating the > `requiredVersion` key in the TEST.ROOT file at the top of each test > suite. That is, I think we want everyone to use the same minimum version > of jtreg, irrespective of how they run the tests. That's not how we've been doing things to-date. Some areas are still on 4.1. David > -Alan From aph at redhat.com Wed Feb 20 09:20:29 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Feb 2019 09:20:29 +0000 Subject: Faster rebuild with GNU gold linker In-Reply-To: References: Message-ID: On 2/20/19 6:35 AM, Ioi Lam wrote: > Thanks for the info. I didn't know that this has been discussed so > recently. Should have checked befor I posted. > > Anyway, I built the latest lld from GIT, but it's slower than gold on my > machine. Just linking libjvm.so is 5.8s vs 3.8s. This is exactly the opposite of everyone else's results. Cany you please post the results of using "time" on just the link step? Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Feb 20 10:09:51 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Feb 2019 10:09:51 +0000 Subject: Faster rebuild with GNU gold linker In-Reply-To: <23b0fc3d-bf2c-7a8c-e809-a955145c2c0f@oracle.com> References: <23b0fc3d-bf2c-7a8c-e809-a955145c2c0f@oracle.com> Message-ID: <42a9dd14-dbaa-5a28-bf33-1ac6aa59b5df@redhat.com> On 2/20/19 7:54 AM, Ioi Lam wrote: > Ahh, I was using a debug build of lld. After making a release build, the > link time drops to 1.1 seconds! It's definitely better than gold. Right, exactly. And when you're working on just one file in HotSpot, this can make a very significant difference to the programmer experience. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.joelsson at oracle.com Wed Feb 20 14:59:47 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Feb 2019 06:59:47 -0800 Subject: RFR(S) : 8219395 : integrate gcov w/ run-test In-Reply-To: <072FFA48-2587-42BD-9BF1-0B650F059AF6@oracle.com> References: <072FFA48-2587-42BD-9BF1-0B650F059AF6@oracle.com> Message-ID: <55d8c515-1aec-b65a-e114-0f3213642d92@oracle.com> Hello Igor, This looks pretty good. Just a few comments. In jib-profiles.js, the linux-x64 profile also builds docs-bundles, so if you base linux-x64-gcov on a clone of that there is some extra build work being done unnecessarily. I would recommend explicitly setting the default_make_targets (which would be product-bundles and test-bundles) for the new *-gcov profiles. On lines 795, 804 and 812 you seem to have left commented out code that should probably be removed. /Erik On 2019-02-19 17:26, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html >> 65 lines changed: 59 ins; 0 del; 6 mod; > Hi all, > > could you please review the patch which makes it easy to run tests on the builds w/ native-code-coverage enabled? to do so the patch > - sets GCOV_PREFIX env. variable, so .gcda files will be stored in build/*/test-results/gcov-output directory, and makes jtreg to propagate this env. variable to JDK under test > - adds linux-x64-gcov and macosx-x64-gcov jib profiles > - changes 'run-test-prebuilt' profile to set GCOV_ENABLED=true if it's the tested profile is -gcov profile > > and also fixes comment for JDKOPT_SETUP_CODE_COVERAGE in jdk-options.m4. > > webrev: http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219395 > testing: > - :tier1 on {linux,macos}-x64 and {linux,macos}-x64-gcov > - checked that *-gcov builds have .gcno files generated and stored in symbols bundle; and regular builds don't > - checked that *-gcov runs have .gcda files generated in test-results/gcov-output; and runs on regular builds don't > > Thanks, > -- Igor From Roger.Riggs at oracle.com Wed Feb 20 16:50:04 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 20 Feb 2019 11:50:04 -0500 Subject: RFR: JDK-8212091 : Move native code under platform specific folders and files In-Reply-To: References: <22161369-51df-528a-17c7-3b3e70bcc11f@oracle.com> <6e5778fa-1097-a6aa-116b-eca0595b81ec@oracle.com> <3d3ab83f-4d16-b93a-5e04-5f87e81785ab@oracle.com> <661ca8a0-8761-83b8-9532-2e3deafbfbba@oracle.com> Message-ID: Hi Alexander, Ok, thanks Note: code reviews of code going into the sandbox is not a substitute for code review when it is to be pushed to jdk/jdk. (The sandbox has much more informal rules for commits that are branch specific.) Roger On 02/19/2019 10:44 PM, Alexander Matveev wrote: > Hi Roger, > > Some deleted files are actually deleted files, since I did code > cleanup as well. > Added files contain code from splitting original source files. This > was needed to re-arrange code. > Not sure how to log with hg file split. > > Also, we already moved files without keeping history, since we are not > planing to keep history when moving jpackage from sandbox. > > Thanks, > Alexander > > On 2/19/2019 8:49 AM, Roger Riggs wrote: >> Hi Alexander, >> >> Some files appear to be moved with hg, but others are copied and >> deleted. >> >> Please use hg mv to retain the continuity of the history. >> >> Thanks, Roger >> >> On 02/15/2019 10:03 PM, Alexander Matveev wrote: >>> Hi Magnus, >>> >>> http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ >>> >>> Moved all files from "posix" to "unix" folder and reverted >>> Lib-jdk.jpackage.gmk changes. >>> Webrev updated with files moved, instead of add/remove. >>> >>> Thanks, >>> Alexander >>> >>> On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2019-02-15 04:31, Alexander Matveev wrote: >>>>> Please review the jpackage fix for bug [1] at [2]. >>>>> >>>>> This is a fix for the JDK-8200758-branch branch of the open >>>>> sandbox repository (jpackage). >>>>> >>>>> - Moved native code under platform specific folder. >>>>> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. >>>>> - MAC define is still used in JavaVirtualMachine.cpp and >>>>> Package.cpp for Mac specific code to filter out some arguments. I >>>>> decided to keep it as is for now, since Mac specific code is small. >>>>> - Defines are used in Platform.cpp to initialize platform specific >>>>> classes. >>>>> - Removed all pragma warning and fixed all compilation warnings. >>>>> - Removed unused code. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212091 >>>>> >>>>> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ >>>> The JDK standard is to use "unix", not "posix", for the shared >>>> functionality between linux/solaris/macosx. You can keep the name >>>> "PosixPlatform.*" if you want, though; the important thing is the >>>> directory name. >>>> >>>> Also, if you do that, you do not need any changes to >>>> make/lib/Lib-jdk.jpackage.gmk, since that will be automatically >>>> understood by the build system. >>>> >>>> It looks from the webrev that you have "moved" the files by doing >>>> "hg add" and "hg remove". Please use "hg move" instead -- this will >>>> keep history intact, and it allows reviewers to see if you have >>>> also made changes to the moved files. >>>> >>>> (If you do have modified the moved file, reverting a "hg add+hg >>>> remove" process is a bit more tricky -- you need to do "hg forget" >>>> on the new file, rename it to something else (otherwise "hg move" >>>> will complain), "hg revert" the old file back in place, do a "hg >>>> move" from the old to the new, and then copy the modified, renamed >>>> file back over the target new file again.) >>>> >>>> /Magnus >>>>> >>>>> Thanks, >>>>> Alexander >>>> >>> >> > From igor.ignatyev at oracle.com Wed Feb 20 18:27:26 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Feb 2019 10:27:26 -0800 Subject: RFR(S) : 8219395 : integrate gcov w/ run-test In-Reply-To: <55d8c515-1aec-b65a-e114-0f3213642d92@oracle.com> References: <072FFA48-2587-42BD-9BF1-0B650F059AF6@oracle.com> <55d8c515-1aec-b65a-e114-0f3213642d92@oracle.com> Message-ID: <56B47486-3BE5-47E2-9C8D-9DC1A3D1367A@oracle.com> Hi Erik, thanks for your review, I've removed the commented lines and changed default_make_targets, http://cr.openjdk.java.net/~iignatyev//8219395/webrev.0-1/index.html is incremental webrev. Thanks, -- Igor > On Feb 20, 2019, at 6:59 AM, Erik Joelsson wrote: > > Hello Igor, > > This looks pretty good. Just a few comments. > > In jib-profiles.js, the linux-x64 profile also builds docs-bundles, so if you base linux-x64-gcov on a clone of that there is some extra build work being done unnecessarily. I would recommend explicitly setting the default_make_targets (which would be product-bundles and test-bundles) for the new *-gcov profiles. > > On lines 795, 804 and 812 you seem to have left commented out code that should probably be removed. > > /Erik > > On 2019-02-19 17:26, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html >>> 65 lines changed: 59 ins; 0 del; 6 mod; >> Hi all, >> >> could you please review the patch which makes it easy to run tests on the builds w/ native-code-coverage enabled? to do so the patch >> - sets GCOV_PREFIX env. variable, so .gcda files will be stored in build/*/test-results/gcov-output directory, and makes jtreg to propagate this env. variable to JDK under test >> - adds linux-x64-gcov and macosx-x64-gcov jib profiles >> - changes 'run-test-prebuilt' profile to set GCOV_ENABLED=true if it's the tested profile is -gcov profile >> >> and also fixes comment for JDKOPT_SETUP_CODE_COVERAGE in jdk-options.m4. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219395 >> testing: >> - :tier1 on {linux,macos}-x64 and {linux,macos}-x64-gcov >> - checked that *-gcov builds have .gcno files generated and stored in symbols bundle; and regular builds don't >> - checked that *-gcov runs have .gcda files generated in test-results/gcov-output; and runs on regular builds don't >> >> Thanks, >> -- Igor From erik.joelsson at oracle.com Wed Feb 20 18:44:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Feb 2019 10:44:09 -0800 Subject: RFR(S) : 8219395 : integrate gcov w/ run-test In-Reply-To: <56B47486-3BE5-47E2-9C8D-9DC1A3D1367A@oracle.com> References: <072FFA48-2587-42BD-9BF1-0B650F059AF6@oracle.com> <55d8c515-1aec-b65a-e114-0f3213642d92@oracle.com> <56B47486-3BE5-47E2-9C8D-9DC1A3D1367A@oracle.com> Message-ID: <0fcf4c3a-919a-618e-978f-196f127f8c44@oracle.com> Looks good. /Erik On 2019-02-20 10:27, Igor Ignatyev wrote: > Hi Erik, > > thanks for your review, I've removed the commented lines and changed > default_make_targets, > http://cr.openjdk.java.net/~iignatyev//8219395/webrev.0-1/index.html?is > incremental webrev. > > Thanks, > -- Igor > >> On Feb 20, 2019, at 6:59 AM, Erik Joelsson > > wrote: >> >> Hello Igor, >> >> This looks pretty good. Just a few comments. >> >> In jib-profiles.js, the linux-x64 profile also builds docs-bundles, >> so if you base linux-x64-gcov on a clone of that there is some extra >> build work being done unnecessarily. I would recommend explicitly >> setting the default_make_targets (which would be product-bundles and >> test-bundles) for the new *-gcov profiles. >> >> On lines 795, 804 and 812 you seem to have left commented out code >> that should probably be removed. >> >> /Erik >> >> On 2019-02-19 17:26, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html >>>> 65 lines changed: 59 ins; 0 del; 6 mod; >>> Hi all, >>> >>> could you please review the patch which makes it easy to run tests >>> on the builds w/ native-code-coverage enabled? to do so the patch >>> ?- sets GCOV_PREFIX env. variable, so .gcda files will be stored in >>> build/*/test-results/gcov-output directory, and makes jtreg to >>> propagate this env. variable to JDK under test >>> ?- adds linux-x64-gcov and macosx-x64-gcov jib profiles >>> ?- changes 'run-test-prebuilt' profile to set GCOV_ENABLED=true if >>> it's the tested profile is -gcov profile >>> >>> and also fixes comment for JDKOPT_SETUP_CODE_COVERAGE in jdk-options.m4. >>> >>> webrev: >>> http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219395 >>> testing: >>> ?- :tier1 on {linux,macos}-x64 and {linux,macos}-x64-gcov >>> ?- checked that *-gcov builds have .gcno files generated and stored >>> in symbols bundle; and regular builds don't >>> ?- checked that *-gcov runs have .gcda files generated in >>> test-results/gcov-output; and runs on regular builds don't >>> >>> Thanks, >>> -- Igor > From ioi.lam at oracle.com Sun Feb 24 03:52:29 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Sat, 23 Feb 2019 19:52:29 -0800 Subject: Faster rebuild with GNU gold linker In-Reply-To: <42a9dd14-dbaa-5a28-bf33-1ac6aa59b5df@redhat.com> References: <23b0fc3d-bf2c-7a8c-e809-a955145c2c0f@oracle.com> <42a9dd14-dbaa-5a28-bf33-1ac6aa59b5df@redhat.com> Message-ID: BTW, for those who want to save an extra second or so in rebuilding hotspot: ??? make hotspot VM_VERSION_OBJ=xxx This doesn't rebuild vm_version.o (which is usually built in a separate pass after all other objects have been built). There are some caveats. See my comments in JDK-8218577. On 2/20/19 2:09 AM, Andrew Haley wrote: > On 2/20/19 7:54 AM, Ioi Lam wrote: >> Ahh, I was using a debug build of lld. After making a release build, the >> link time drops to 1.1 seconds! It's definitely better than gold. > Right, exactly. And when you're working on just one file in HotSpot, > this can make a very significant difference to the programmer experience. > From mikael.vidstedt at oracle.com Mon Feb 25 21:28:45 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 25 Feb 2019 13:28:45 -0800 Subject: RFR(XS): 8219675: Disable harfbuzz warnings with gcc 8 Message-ID: <00794AA4-12F4-4384-B858-832CA5A0066A@oracle.com> Please review this change which (temporarily) disables two gcc warnings which are triggered by the harfbuzz code. JBS: https://bugs.openjdk.java.net/browse/JDK-8219675 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219675/webrev.00/open/webrev/ This change disables the two warnings in question (missing-attributes and class-memaccess). An alternative would be to make changes to the harfbuzz code itself instead. Passes tier1. Cheers, Mikael From philip.race at oracle.com Mon Feb 25 21:59:23 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Feb 2019 13:59:23 -0800 Subject: [OpenJDK 2D-Dev] RFR(XS): 8219675: Disable harfbuzz warnings with gcc 8 In-Reply-To: <00794AA4-12F4-4384-B858-832CA5A0066A@oracle.com> References: <00794AA4-12F4-4384-B858-832CA5A0066A@oracle.com> Message-ID: Looks fine to me so long as the build is happy. -phil. On 2/25/19 1:28 PM, Mikael Vidstedt wrote: > > Please review this change which (temporarily) disables two gcc > warnings which are triggered by the harfbuzz code. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8219675 > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8219675/webrev.00/open/webrev/ > > This change disables the two warnings in question (missing-attributes > and class-memaccess). An alternative would be to make changes to the > harfbuzz code itself instead. > > Passes tier1. > > Cheers, > Mikael > From erik.joelsson at oracle.com Mon Feb 25 22:16:10 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Feb 2019 14:16:10 -0800 Subject: RFR(XS): 8219675: Disable harfbuzz warnings with gcc 8 In-Reply-To: <00794AA4-12F4-4384-B858-832CA5A0066A@oracle.com> References: <00794AA4-12F4-4384-B858-832CA5A0066A@oracle.com> Message-ID: <97aeae83-2002-c35b-6566-87ee9811650f@oracle.com> Looks good. /Erik On 2019-02-25 13:28, Mikael Vidstedt wrote: > Please review this change which (temporarily) disables two gcc warnings which are triggered by the harfbuzz code. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8219675 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219675/webrev.00/open/webrev/ > > This change disables the two warnings in question (missing-attributes and class-memaccess). An alternative would be to make changes to the harfbuzz code itself instead. > > Passes tier1. > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Tue Feb 26 00:09:55 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 25 Feb 2019 16:09:55 -0800 Subject: RFR(XS): 8219675: Disable harfbuzz warnings with gcc 8 In-Reply-To: <97aeae83-2002-c35b-6566-87ee9811650f@oracle.com> References: <00794AA4-12F4-4384-B858-832CA5A0066A@oracle.com> <97aeae83-2002-c35b-6566-87ee9811650f@oracle.com> Message-ID: <23E2B148-4E63-4BC6-8F32-7627A9B02BC7@oracle.com> Erik/Phil, thanks for the reviews. Change pushed! I also filed https://bugs.openjdk.java.net/browse/JDK-8219676 to cover re-enabling the warnings (effectively reverting this change) once harfbuzz has been upgraded. Cheers, Mikael > On Feb 25, 2019, at 2:16 PM, Erik Joelsson wrote: > > Looks good. > > /Erik > > On 2019-02-25 13:28, Mikael Vidstedt wrote: >> Please review this change which (temporarily) disables two gcc warnings which are triggered by the harfbuzz code. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219675 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219675/webrev.00/open/webrev/ >> >> This change disables the two warnings in question (missing-attributes and class-memaccess). An alternative would be to make changes to the harfbuzz code itself instead. >> >> Passes tier1. >> >> Cheers, >> Mikael >> From aph at redhat.com Tue Feb 26 20:09:50 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Feb 2019 20:09:50 +0000 Subject: How can I see where the sjavac_server is started? Message-ID: <4ef8da59-9609-6e43-cfe6-6276f9c4d5eb@redhat.com> I'm seeing a crash in the javac server while building openjdk. I want to run the exact same command that started the server running, but even with LOG=debug I cannot find the command line that starts it. The command seems not to be there at all. So, how exactly does the javac server get started, and how do I find the command line that started it? And, incidentally, given that I'f configured with --disable-sjavac, why is the build running a javac server? Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.joelsson at oracle.com Wed Feb 27 15:51:45 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Feb 2019 07:51:45 -0800 Subject: How can I see where the sjavac_server is started? In-Reply-To: <4ef8da59-9609-6e43-cfe6-6276f9c4d5eb@redhat.com> References: <4ef8da59-9609-6e43-cfe6-6276f9c4d5eb@redhat.com> Message-ID: Hello Andrew, On 2019-02-26 12:09, Andrew Haley wrote: > I'm seeing a crash in the javac server while building openjdk. We are seeing this too intermittently. > I want to run the exact same command that started the server running, > but even with LOG=debug I cannot find the command line that starts > it. The command seems not to be there at all. > > So, how exactly does the javac server get started, and how do I find > the command line that started it? The server is started lazily by the first javac invocation that needs it. There is a parameter given to javac that describes how it should be started, but to get the exact command line, you would have to instrument javac java source. You should be able to add additional parameters to that JVM, at least by editing spec.gmk, that could help you with diagnostics. > And, incidentally, given that I'f configured with --disable-sjavac, > why is the build running a javac server? Thanks. > The "smart javac" and the javac server are not one the same. The server was introduced in sjavac, but the server part was later ported over to javac proper (I think). So now we have two configure arguments, --enable-sjavac and --disable-javac-server. The latter is what you are looking for. I think we should really get rid of sjavac since the relevant benefits are already present in the default build, with the javac server and the dependency plugin. The only possible benefit of sjavac today would be more fine grained incremental build support, but I doubt it works very well given that it's not being maintained. /Erik From jonathan.gibbons at oracle.com Wed Feb 27 16:41:41 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 27 Feb 2019 08:41:41 -0800 Subject: How can I see where the sjavac_server is started? In-Reply-To: References: <4ef8da59-9609-6e43-cfe6-6276f9c4d5eb@redhat.com> Message-ID: <67aad4dc-af56-39e1-0735-d919d6404ee5@oracle.com> What Erik stated regarding javac and sjavac is not entirely correct: currently, javac does not itself support starting a background server, although that is a goal that we (javac team) would like to achieve. Instead, it is the case that sjavac provides various facilities, including the ability to start a background server, and to do "smart compilation" by? determining the reduced set of files that need to be recompiled.?? The current build uses the first point (the ability to start a background server) but not the second.? It is my understanding that the background server is started by the first invocation of sjavac, which is given suitable parameters to enable it to do so. -- Jon On 2/27/19 7:51 AM, Erik Joelsson wrote: > Hello Andrew, > > On 2019-02-26 12:09, Andrew Haley wrote: >> I'm seeing a crash in the javac server while building openjdk. > We are seeing this too intermittently. >> I want to run the exact same command that started the server running, >> but even with LOG=debug I cannot find the command line that starts >> it. The command seems not to be there at all. >> >> So, how exactly does the javac server get started, and how do I find >> the command line that started it? > The server is started lazily by the first javac invocation that needs > it. There is a parameter given to javac that describes how it should > be started, but to get the exact command line, you would have to > instrument javac java source. You should be able to add additional > parameters to that JVM, at least by editing spec.gmk, that could help > you with diagnostics. >> And, incidentally, given that I'f configured with --disable-sjavac, >> why is the build running a javac server? Thanks. >> > The "smart javac" and the javac server are not one the same. The > server was introduced in sjavac, but the server part was later ported > over to javac proper (I think). So now we have two configure > arguments, --enable-sjavac and --disable-javac-server. The latter is > what you are looking for. > > I think we should really get rid of sjavac since the relevant benefits > are already present in the default build, with the javac server and > the dependency plugin. The only possible benefit of sjavac today would > be more fine grained incremental build support, but I doubt it works > very well given that it's not being maintained. > > /Erik > From aoqi at loongson.cn Thu Feb 28 08:13:00 2019 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 28 Feb 2019 16:13:00 +0800 Subject: RFR: JDK-8219906: Update test documentation with default test jobs settings Message-ID: Hi, Test jobs setting for sparc is different with x86 (JDK-8211727). Besides, test jobs setting is based on memory size (JDK-8214003). The test documentation fails to mention these and needs update. Bug: https://bugs.openjdk.java.net/browse/JDK-8219906 Webrev: http://cr.openjdk.java.net/~aoqi/8219906/webrev.00/ Cheers, Ao Qi From matthias.baesken at sap.com Thu Feb 28 12:53:17 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 28 Feb 2019 12:53:17 +0000 Subject: RFR: 8219920: dependency help output in configure-step : support zypper tool Message-ID: Hello, please review the following change . Currently the configure-step outputs help for a number of packages + related installation calls in case of missing dependencies (like cups / alsa etc.) . This help output step covers a few tools (like apt-get). However the OpenSUSE / SLES tool zypper is not supported . This change adds output for zypper . Bug/webrev: https://bugs.openjdk.java.net/browse/JDK-8219920 http://cr.openjdk.java.net/~mbaesken/webrevs/8219920.0/ Thanks, Matthias