From andy.herrick at oracle.com Wed May 1 14:59:06 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 1 May 2019 10:59:06 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <01b88418-1c69-4180-be24-5e4207c06493@oracle.com> References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com> <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com> <5CC4F7E0.7020208@oracle.com> <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com> <01b88418-1c69-4180-be24-5e4207c06493@oracle.com> Message-ID: I filed task JDK-8223187 to look into (1) and CR JDK-8223188 to address (2). /Andy On 4/30/2019 6:53 PM, Phil Race wrote: > A couple of questions / observations :- > 1) setlocale > http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/linux/native/jpackageapplauncher/launcher.cpp.html > > 52 int main(int argc, char *argv[]) { > 53 int result = 1; > 54 setlocale(LC_ALL, "en_US.utf8"); > > Why is this setlocale() call there ? > > What does this mean for a user whose desktop is (say) German, or French, or Japanese ? > > When the Java app is launched from this environment is it inheriting this US locale ? I hope not. > > We have the same on Mac :- > > http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/macosx/native/jpackageapplauncher/main.m.html > > and windows :- > > http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/native/jpackageapplauncher/WinLauncher.cpp.html > > 64 ::setlocale(LC_ALL, "en_US.utf8"); > > > 2) C++ files containing C > > src/jdk.jpackage/windows/native/libjpackage/WindowsRegistry.cpp > > > > src/jdk.jpackage/windows/native/libjpackage/jpackage.cpp > > > > src/jdk.jpackage/windows/native/libwixhelper/libwixhelper.cpp > > > > have their entire contents wrapped in > > 36 #ifdef __cplusplus > 37 extern "C" { > 38 #endif > > 159 #ifdef __cplusplus > 160 } > 161 #endif > > wouldn't it be better to put them in .c files ? > > > -phil. From andy.herrick at oracle.com Wed May 1 15:08:55 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 1 May 2019 11:08:55 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com> References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com> <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com> <5CC4F7E0.7020208@oracle.com> <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com> <01b88418-1c69-4180-be24-5e4207c06493@oracle.com> <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com> Message-ID: I have filed JDK-8223189 to address these. /Andy On 4/30/2019 7:02 PM, Kevin Rushforth wrote: > I have a couple nit-picky comments: > > 1. The change to src/jdk.jlink/share/classes/module-info.java is > unrelated to jpackage and should be reverted (there is only a > white-space change and a copyright date change to that file) > > > 2. The following files have whitespace errors that will cause jcheck > to fail: > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java:326: > Trailing whitespace > src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java:58: > Tab character > src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkBundlerHelper.java:217: > Trailing whitespace > src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java:55: > Trailing whitespace > > > 3. I recommend to replace the wild-card imports with explicit imports, > for example: > src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java > (java.util.* and java.io.*) > (I think the wild-card static import is fine, just not the import > every class from a package) > > I'll try to remember to note these as I go through the review. This > one could be done as a follow-up bug rather than doing it prior to > integration if you prefer. > > -- Kevin > From jcbeyler at google.com Thu May 2 02:39:05 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 1 May 2019 19:39:05 -0700 Subject: RFR (L) 8220747: Message-ID: Hi all, I want to move the libHeapMonitorTest.c to C++ and here is the first "step" towards that. There are two parts to this: move the file to C++ and move some of the C-style to C++-style code. But this webrev failed on solaris; Igor helped me figure it out and his solution was to add the change to the JtregNativeHotspot.gmk for solstudio. We are not sure this is the "right" solution to this and hence have added both the serviceability and build lists to review both file changes and figure out what is best :) This does pass the submit-repo testing and the tests on my local dev machine. Bug: https://bugs.openjdk.java.net/browse/JDK-8220747 Webrev: http://cr.openjdk.java.net/~jcbeyler/8220747/webrev.02/ Thanks all for your help, Jc From jcbeyler at google.com Thu May 2 03:08:26 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 1 May 2019 20:08:26 -0700 Subject: RFR (L) 8220747: Migrate data structures to being more C++ Message-ID: Hi all, Re-sending with the full title.... (OK... so JC will promise to go around the block 3 times before submitting a review request; and will do any item you would like to redeem myself; I apologize profusely and feel horrible...) I want to move the libHeapMonitorTest.c to C++ and here is the first "step" towards that. There are two parts to this: move the file to C++ and move some of the C-style to C++-style code. But this webrev failed on solaris; Igor helped me figure it out and his solution was to add the change to the JtregNativeHotspot.gmk for solstudio. We are not sure this is the "right" solution to this and hence have added both the serviceability and build lists to review both file changes and figure out what is best :) This does pass the submit-repo testing and the tests on my local dev machine. Bug: https://bugs.openjdk.java.net/browse/JDK-8220747 Webrev: http://cr.openjdk.java.net/~jcbeyler/8220747/webrev.02/ Thanks all for your help, Jc From david.holmes at oracle.com Thu May 2 05:22:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 May 2019 15:22:07 +1000 Subject: RFR (L) 8220747: Migrate data structures to being more C++ In-Reply-To: References: Message-ID: <4927d1b1-49ad-9be7-d2ca-483e521f7b18@oracle.com> Hi Jc, I just a had a quick look at this so not a full review - sorry. I'm not sure it makes sense to define classes within "extern C {". The extern C is intended to define an interface for this C++ library to be used from a C program - as discussed here for your Solaris issue: https://docs.oracle.com/cd/E18659_01/html/821-1383/bkamu.html Cheers, David On 2/05/2019 1:08 pm, Jean Christophe Beyler wrote: > Hi all, > > Re-sending with the full title.... > > (OK... so JC will promise to go around the block 3 times before submitting > a review request; and will do any item you would like to redeem myself; I > apologize profusely and feel horrible...) > > I want to move the libHeapMonitorTest.c to C++ and here is the first "step" > towards that. There are two parts to this: move the file to C++ and move > some of the C-style to C++-style code. > > But this webrev failed on solaris; Igor helped me figure it out and his > solution was to add the change to the JtregNativeHotspot.gmk for solstudio. > We are not sure this is the "right" solution to this and hence have added > both the serviceability and build lists to review both file changes and > figure out what is best :) > > This does pass the submit-repo testing and the tests on my local dev > machine. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220747 > Webrev: http://cr.openjdk.java.net/~jcbeyler/8220747/webrev.02/ > > Thanks all for your help, > Jc > From Roger.Riggs at oracle.com Thu May 2 15:16:30 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 2 May 2019 11:16:30 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com> <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com> <5CC4F7E0.7020208@oracle.com> <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com> <01b88418-1c69-4180-be24-5e4207c06493@oracle.com> <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com> Message-ID: <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com> Hi, Some comments, a initial batch... Having support for the ToolProvider is great. However, there is no indication about whether it is valid to use it from multiple threads. The implementation is structured to be deliberately single thread use only with the invocation being via a static method and the logging being via static methods. There will need to be a disclaimer and perhaps an exception should be thrown. A future improvement: The implementation should be methods on the instance created by the ToolProvider and the logging relative to that instance/delegated where needed. Main can then be a simple lookup of the tool provider and invoke. jpackage.main.Main: ?- Main.run returns -1, which then is used as exit status, -1 is not the usual exit status for a C/Unix main. 65,? the run() method is usually not static and should be re-named to avoid confusion 92: Implies something should be logged on a failure. 65: Run (Pw, Pw, args...) doesn't use try ... finally to ensure log is flushed. 65: 'throws Exception' implies it can throw an exception but is ambiguous as to whether it returns an error number or throws on what kinds of errors? 91: Ambiguous as to whether processArguments() throws or return false! CommandLine: 59: Would be more flexible and powerful to use List consistently... 67: use arg.startsWith() for cleaner code. 102: Seems wasteful to parse all the arguments twice. jdk.jpackage.internal classes: AbstractAppImageBuilder: ?57: The constructor does not need to throw IOException 60:? are .diz files common enough to preemptively exclude (w/o documentation) 89: Can the mix of old File API and new Path/Files APIs be avoided? Adding javadoc to the abstract builder methods will help future maintainers. 203: is a bit more generous than most CLASSPATH parsing and might lead to non-obvious bugs. ?? For example, a path component with a space in it! 229:? There is no mention of debugging support in JEP 343. ? Where is this functionality defined or is it to be identified as undocumented internal implementation Regards, Roger From alexey.semenyuk at oracle.com Thu May 2 17:49:22 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 2 May 2019 13:49:22 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <5CC4F7E0.7020208@oracle.com> References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com> <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com> <5CC4F7E0.7020208@oracle.com> Message-ID: <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com> Some findings: http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html. Reason: these targets don't output executables into images/jdk/bin directory. They produce artifacts that stored as resources in jpackage just like other targets defined in Lib-jdk.jpackage.gmk. Wix source code produced by http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html doesn't comply to recommendations of how files should be packed in component. The recommendation is to use one file per a component - http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html. However jpackage produces way less components than files: --- $ less config/bundle.wxi | grep ' Adding build-dev for the build changes. I don't know if these were > previously reviewed there, > but I am not sure what the changes in NativeCompilation.gmk have to do > with jpackage. > > -phil. > > On 4/24/19, 5:47 PM, Andy Herrick wrote: >> >> On 4/24/2019 8:44 PM, Andy Herrick wrote: >>> Please review? changes for [1] which is the implementation bug for >>> JEP-343. >>> >>> The webrev at [2] is the total cumulative webrev of changes for the >>> jpackage tool, currently in the JDK-8200758-branch branch of the >>> open sandbox repository. >>> >>> The webrev at [3] shows the changes from EA-05 to EA-06. >> sorry - the links are reversed from what is stated above. [2] is the >> incremental webrev since EA 05, [3] is the cumulativewebrev >> /Andy >>> >>> The latest EA-6 (build 49) is posted at [4]. >>> >>> Please send feedback to core-libs-dev at openjdk.java.net >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/ >>> >>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/ >>> >>> [4] http://jdk.java.net/jpackage/ >>> >>> >>> /Andy >>> >>> >> From andy.herrick at oracle.com Thu May 2 21:08:25 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 2 May 2019 17:08:25 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com> References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com> <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com> <5CC4F7E0.7020208@oracle.com> <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com> Message-ID: <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com> Alexey: Please file Bugs for these two issues. /Andy On 5/2/2019 1:49 PM, Alexey Semenyuk wrote: > Some findings: > > http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: > > I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and > BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to > http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html. > Reason: these targets don't output executables into images/jdk/bin > directory. They produce artifacts that stored as resources in jpackage > just like other targets defined in Lib-jdk.jpackage.gmk. > > Wix source code produced by > http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html > doesn't comply to recommendations of how files should be packed in > component. The recommendation is to use one file per a component - > http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html. > However jpackage produces way less components than files: > --- > $ less config/bundle.wxi | grep ' 634 > > $ less config/bundle.wxi | grep ' 1650 > --- > Data picked from my local test project. > > http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745 > > ???? + " Guid=\"" + UUID.randomUUID().toString() + "\"" > Use of random GUIDs for components is not recommended and potentially > can result in issues with application updates. The recommended > approach is to generate stable GUIDs - > http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html, > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html. > > Algorithm to create stable GUIDs is explained at > https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the > hassle of generating stable GUIDs if we would put only one file in > every component. In this case WiX is able to generate stable GUIDs for > us. > > - Alexey > > On 4/27/2019 8:46 PM, Philip Race wrote: >> Adding build-dev for the build changes. I don't know if these were >> previously reviewed there, >> but I am not sure what the changes in NativeCompilation.gmk have to >> do with jpackage. >> >> -phil. >> >> On 4/24/19, 5:47 PM, Andy Herrick wrote: >>> >>> On 4/24/2019 8:44 PM, Andy Herrick wrote: >>>> Please review? changes for [1] which is the implementation bug for >>>> JEP-343. >>>> >>>> The webrev at [2] is the total cumulative webrev of changes for the >>>> jpackage tool, currently in the JDK-8200758-branch branch of the >>>> open sandbox repository. >>>> >>>> The webrev at [3] shows the changes from EA-05 to EA-06. >>> sorry - the links are reversed from what is stated above. [2] is the >>> incremental webrev since EA 05, [3] is the cumulativewebrev >>> /Andy >>>> >>>> The latest EA-6 (build 49) is posted at [4]. >>>> >>>> Please send feedback to core-libs-dev at openjdk.java.net >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>>> >>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/ >>>> >>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/ >>>> >>>> [4] http://jdk.java.net/jpackage/ >>>> >>>> >>>> /Andy >>>> >>>> >>> > From swpalmer at gmail.com Fri May 3 00:54:49 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 2 May 2019 20:54:49 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com> References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com> <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com> <5CC4F7E0.7020208@oracle.com> <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com> <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com> Message-ID: <43E836D1-908F-426B-A4BB-6CD1A413A7B2@gmail.com> Ideally the wix code should be generated by running the heat.exe tool on the application image. Scott > On May 2, 2019, at 5:08 PM, Andy Herrick wrote: > > Alexey: > > Please file Bugs for these two issues. > > /Andy > > >> On 5/2/2019 1:49 PM, Alexey Semenyuk wrote: >> Some findings: >> >> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: >> I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html. Reason: these targets don't output executables into images/jdk/bin directory. They produce artifacts that stored as resources in jpackage just like other targets defined in Lib-jdk.jpackage.gmk. >> >> Wix source code produced by http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html doesn't comply to recommendations of how files should be packed in component. The recommendation is to use one file per a component - http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html. However jpackage produces way less components than files: >> --- >> $ less config/bundle.wxi | grep '> 634 >> >> $ less config/bundle.wxi | grep '> 1650 >> --- >> Data picked from my local test project. >> >> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745 >> + " Guid=\"" + UUID.randomUUID().toString() + "\"" >> Use of random GUIDs for components is not recommended and potentially can result in issues with application updates. The recommended approach is to generate stable GUIDs - http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html, http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html. >> Algorithm to create stable GUIDs is explained at https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the hassle of generating stable GUIDs if we would put only one file in every component. In this case WiX is able to generate stable GUIDs for us. >> >> - Alexey >> >>> On 4/27/2019 8:46 PM, Philip Race wrote: >>> Adding build-dev for the build changes. I don't know if these were previously reviewed there, >>> but I am not sure what the changes in NativeCompilation.gmk have to do with jpackage. >>> >>> -phil. >>> >>>> On 4/24/19, 5:47 PM, Andy Herrick wrote: >>>> >>>>> On 4/24/2019 8:44 PM, Andy Herrick wrote: >>>>> Please review changes for [1] which is the implementation bug for JEP-343. >>>>> >>>>> The webrev at [2] is the total cumulative webrev of changes for the jpackage tool, currently in the JDK-8200758-branch branch of the open sandbox repository. >>>>> >>>>> The webrev at [3] shows the changes from EA-05 to EA-06. >>>> sorry - the links are reversed from what is stated above. [2] is the incremental webrev since EA 05, [3] is the cumulativewebrev >>>> /Andy >>>>> >>>>> The latest EA-6 (build 49) is posted at [4]. >>>>> >>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>> >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>>>> >>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/ >>>>> >>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/ >>>>> >>>>> [4] http://jdk.java.net/jpackage/ >>>>> >>>>> >>>>> /Andy >>>>> >>>>> >>>> >> > From matthias.baesken at sap.com Fri May 3 12:48:07 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 3 May 2019 12:48:07 +0000 Subject: RFR: 8223307: enable the Stack Execution Disable flag for JDK binaries on AIX - was : AIX : -bnorwexec linker flag Message-ID: Hello, I created a webrev for the previously discussed issue (AIX : -bnorwexec linker flag). AIX supports a binary hardening option called SED, see : https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.security/stack_exec_disable.htm System wide configuration can be done with the sedmgr tool : https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.cmds5/sedmgr.htm The system-wide configuration supports various modes, very often "select" mode is configured where binaries can opt-in to use SED : "select: Only a select set of files are enabled and monitored for SED protection. The select set of files are chosen by reviewing the SED related flags in the executable program binary headers. The executable program header enables SED related flags to request to be included in the select mode." We can set a linker option on AIX to configure "select" mode for the JDK binaries; our tests show that this does not "kill" the JIT (jitted code). changed binary shows then the opt-in flag ("request" ) : bash-4.4$ sedmgr -d /rs6000_64/nightly/output-jdk-test/images/jdk/bin/java /rs6000_64/nightly/output-jdk-test/images/jdk/bin/java : request while the unchanged binary does not have the flag set ("system") : bash-4.4$ sedmgr -d /rs6000_64/nightly/output-jdk11-test/images/jdk/bin/java /rs6000_64/nightly/output-jdk11-test/images/jdk/bin/java : system Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8223307 http://cr.openjdk.java.net/~mbaesken/webrevs/8223307.0/ Thanks, Matthias > -----Original Message----- > From: Erik Joelsson > Sent: Freitag, 12. April 2019 15:30 > To: Baesken, Matthias ; ppc-aix-port- > dev at openjdk.java.net; 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: AIX : -bnorwexec linker flag > > From a build point of view, the patch looks good. I cannot comment on > the validity of adding the flag though. > > /Erik > > On 2019-04-12 02:15, Baesken, Matthias wrote: > > Hello, I have a question regarding the AIX -bnorwexec linker flag . > > I think it is related to an AIX security feature SED , see also : > > > > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. > aix.security/stack_exec_disable_flags.htm > > > > When building with the additional -bnorwexec linker flag we signal the > OS that we "request" the SED feature . > > Please compare a patched and an unpatched java ( patched is flagged > "request" while unpatched uses the "system" setting ). > > > > bash-4.3$ sedmgr -d /patched_jdk/images/jdk/bin/java > > /patched_jdk/images/images/jdk/bin/java : request > > > > > > bash-4.3$ sedmgr -d /normal_jdk/images/jdk/bin/java > > /normal_jdk/images/jdk/bin/java : system > > > > > > System config on the example machine is "normal" (default) select : > > bash-4.3$ sedmgr > > Stack Execution Disable (SED) mode: select > > SED configured in kernel: select > > > > > > In our internal tests I noticed so far no issues when setting the - > bnorwexec linker flag in OpenJDK on AIX . > > Do you have any experience with it, do you see issues when setting the > flag ? > > > > > > The documentation of the flag is a bit short . > > > > > > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. > aix.cmds3/ld.htm > > > > > > norwexec > > > > Specifies that if the system's sed_config setting is not off, the process' > private data areas will have non-execute permission. > > > > > > > > > > Patch would be : > > > > diff -r 0d7fb7f07134 make/autoconf/flags-ldflags.m4 > > --- a/make/autoconf/flags-ldflags.m4 Mon Apr 08 06:56:37 2019 +0100 > > +++ b/make/autoconf/flags-ldflags.m4 Mon Apr 08 10:50:07 2019 +0200 > > @@ -1,5 +1,5 @@ > > # > > -# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. > > +# Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. > > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > # > > # This code is free software; you can redistribute it and/or modify it > > @@ -88,7 +88,7 @@ > > BASIC_LDFLAGS_JVM_ONLY="-library=%none -mt -z noversion" > > elif test "x$TOOLCHAIN_TYPE" = xxlc; then > > - BASIC_LDFLAGS="-b64 -brtl -bnolibpath -bexpall -bernotok - > btextpsize:64K \ > > + BASIC_LDFLAGS="-b64 -brtl -bnorwexec -bnolibpath -bexpall -bernotok > -btextpsize:64K \ > > -bdatapsize:64K -bstackpsize:64K" > > # libjvm.so has gotten too large for normal TOC size; compile with > qpic=large and link with bigtoc > > BASIC_LDFLAGS_JVM_ONLY="-Wl,-lC_r -bbigtoc" > > > > > > Best regards, Matthias > > From erik.joelsson at oracle.com Fri May 3 13:32:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 06:32:17 -0700 Subject: RFR: 8223307: enable the Stack Execution Disable flag for JDK binaries on AIX - was : AIX : -bnorwexec linker flag In-Reply-To: References: Message-ID: Change looks good from a build perspective. I can't comment on the validity of the flag itself for a platform I don't know. /Erik On 2019-05-03 05:48, Baesken, Matthias wrote: > Hello, I created a webrev for the previously discussed issue (AIX : -bnorwexec linker flag). > > AIX supports a binary hardening option called SED, see : > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.security/stack_exec_disable.htm > > System wide configuration can be done with the sedmgr tool : > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.cmds5/sedmgr.htm > > > The system-wide configuration supports various modes, very often "select" mode is configured where > binaries can opt-in to use SED : > > "select: > Only a select set of files are enabled and monitored for SED protection. The select set of files are chosen by reviewing the SED related flags in the executable program binary headers. > The executable program header enables SED related flags to request to be included in the select mode." > > > We can set a linker option on AIX to configure "select" mode for the JDK binaries; our tests show that this does not "kill" the JIT (jitted code). > > changed binary shows then the opt-in flag ("request" ) : > > bash-4.4$ sedmgr -d /rs6000_64/nightly/output-jdk-test/images/jdk/bin/java > /rs6000_64/nightly/output-jdk-test/images/jdk/bin/java : request > > while the unchanged binary does not have the flag set ("system") : > > bash-4.4$ sedmgr -d /rs6000_64/nightly/output-jdk11-test/images/jdk/bin/java > /rs6000_64/nightly/output-jdk11-test/images/jdk/bin/java : system > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8223307 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223307.0/ > > > Thanks, Matthias > > > >> -----Original Message----- >> From: Erik Joelsson >> Sent: Freitag, 12. April 2019 15:30 >> To: Baesken, Matthias ; ppc-aix-port- >> dev at openjdk.java.net; 'build-dev at openjdk.java.net' > dev at openjdk.java.net> >> Subject: Re: AIX : -bnorwexec linker flag >> >> From a build point of view, the patch looks good. I cannot comment on >> the validity of adding the flag though. >> >> /Erik >> >> On 2019-04-12 02:15, Baesken, Matthias wrote: >>> Hello, I have a question regarding the AIX -bnorwexec linker flag . >>> I think it is related to an AIX security feature SED , see also : >>> >>> >> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. >> aix.security/stack_exec_disable_flags.htm >>> When building with the additional -bnorwexec linker flag we signal the >> OS that we "request" the SED feature . >>> Please compare a patched and an unpatched java ( patched is flagged >> "request" while unpatched uses the "system" setting ). >>> bash-4.3$ sedmgr -d /patched_jdk/images/jdk/bin/java >>> /patched_jdk/images/images/jdk/bin/java : request >>> >>> >>> bash-4.3$ sedmgr -d /normal_jdk/images/jdk/bin/java >>> /normal_jdk/images/jdk/bin/java : system >>> >>> >>> System config on the example machine is "normal" (default) select : >>> bash-4.3$ sedmgr >>> Stack Execution Disable (SED) mode: select >>> SED configured in kernel: select >>> >>> >>> In our internal tests I noticed so far no issues when setting the - >> bnorwexec linker flag in OpenJDK on AIX . >>> Do you have any experience with it, do you see issues when setting the >> flag ? >>> >>> The documentation of the flag is a bit short . >>> >>> >>> >> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. >> aix.cmds3/ld.htm >>> >>> norwexec >>> >>> Specifies that if the system's sed_config setting is not off, the process' >> private data areas will have non-execute permission. >>> >>> >>> >>> Patch would be : >>> >>> diff -r 0d7fb7f07134 make/autoconf/flags-ldflags.m4 >>> --- a/make/autoconf/flags-ldflags.m4 Mon Apr 08 06:56:37 2019 +0100 >>> +++ b/make/autoconf/flags-ldflags.m4 Mon Apr 08 10:50:07 2019 +0200 >>> @@ -1,5 +1,5 @@ >>> # >>> -# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. >>> +# Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. >>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> # >>> # This code is free software; you can redistribute it and/or modify it >>> @@ -88,7 +88,7 @@ >>> BASIC_LDFLAGS_JVM_ONLY="-library=%none -mt -z noversion" >>> elif test "x$TOOLCHAIN_TYPE" = xxlc; then >>> - BASIC_LDFLAGS="-b64 -brtl -bnolibpath -bexpall -bernotok - >> btextpsize:64K \ >>> + BASIC_LDFLAGS="-b64 -brtl -bnorwexec -bnolibpath -bexpall -bernotok >> -btextpsize:64K \ >>> -bdatapsize:64K -bstackpsize:64K" >>> # libjvm.so has gotten too large for normal TOC size; compile with >> qpic=large and link with bigtoc >>> BASIC_LDFLAGS_JVM_ONLY="-Wl,-lC_r -bbigtoc" >>> >>> >>> Best regards, Matthias >>> From johan.vos at gluonhq.com Fri May 3 14:44:52 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 3 May 2019 16:44:52 +0200 Subject: RFR: JDK-8223309: test failing due to self-assign-overloaded Message-ID: Using MacOS X 10.14.4 and Xcode 10.2.1 I could not build jdk/jdk anymore: /Users/johan/openjdk/jdk/test/hotspot/gtest/classfile/test_symbolTable.cpp:62:6: error: explicitly assigning value of variable of type 'TempNewSymbol' to itself [-Werror,-Wself-assign-overloaded] s1 = s1; // self assignment ~~ ^ ~~ 1 error generated. I added an entry to the list of disabled warnings, and that fixed the problem. Bug: https://bugs.openjdk.java.net/browse/JDK-8223309 Webrev: http://cr.openjdk.java.net/~jvos/8223309/webrev.00/ - Johan From erik.joelsson at oracle.com Fri May 3 15:02:10 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 08:02:10 -0700 Subject: RFR: JDK-8223309: test failing due to self-assign-overloaded In-Reply-To: References: Message-ID: <62cc02f8-5bf1-314e-fdc6-3dc0022e29bf@oracle.com> Hello, Change looks good, but I would prefer a line break. We try to keep the lines in the makefiles/build system at least close to 80 chars when possible. No need for new webrev if you make this change. /Erik On 2019-05-03 07:44, Johan Vos wrote: > Using MacOS X 10.14.4 and Xcode 10.2.1 I could not build jdk/jdk anymore: > /Users/johan/openjdk/jdk/test/hotspot/gtest/classfile/test_symbolTable.cpp:62:6: > error: explicitly assigning value of variable of type 'TempNewSymbol' to > itself [-Werror,-Wself-assign-overloaded] > s1 = s1; // self assignment > ~~ ^ ~~ > 1 error generated. > > I added an entry to the list of disabled warnings, and that fixed the > problem. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223309 > > Webrev: http://cr.openjdk.java.net/~jvos/8223309/webrev.00/ > > - Johan From matthias.baesken at sap.com Fri May 3 15:12:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 3 May 2019 15:12:51 +0000 Subject: gcc FORTIFY_SOURCE application security flags Message-ID: Hello. maybe some of you are aware of the gcc FORTIFY_SOURCE application security flags. Developers can enable compile and also runtime checks for some string / memory related operations with the flag. See details : https://access.redhat.com/blogs/766093/posts/1976213 Have you tried already those flags in the OpenJDK ? One issue I experienced when using the flag (-D_FORTIFY_SOURCE=2) is that in case that a runtime issue is detected, no hs_err file is written , only a "*** buffer overflow detected ***" + backtrace + Memory map output is written, looks like this : *** buffer overflow detected ***: /bin/java terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x7f5b500b7177] /lib64/libc.so.6(+0xe8e10)[0x7f5b500b4e10] /lib64/libc.so.6(+0xe8109)[0x7f5b500b4109] /lib64/libc.so.6(_IO_default_xsputn+0x85)[0x7f5b5003f705] /lib64/libc.so.6(_IO_vfprintf+0x18e)[0x7f5b5000f0ce] /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f5b500b41ad] /lib64/libc.so.6(__sprintf_chk+0x80)[0x7f5b500b40f0] ........ ======= Memory map: ======== c0000000-c0700000 rw-p 00000000 00:00 0 ..... I would prefer to get a hs_err file, do you know a way to get this in context of the gcc flag _FORTIFY_SOURCE ? In case this is not possible, the flag might not be useful any more for OpenJDK . Maybe the gcc7 flags for memory error detection https://developers.redhat.com/blog/2017/02/22/memory-error-detection-using-gcc/ might provide an alternative solution - are they already enabled by default ? Thanks, Matthias From erik.joelsson at oracle.com Fri May 3 15:40:06 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 08:40:06 -0700 Subject: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: Message-ID: Hello Matthias, We have tried to use it before but later removed it. See https://bugs.openjdk.java.net/browse/JDK-8050803 /Erik On 2019-05-03 08:12, Baesken, Matthias wrote: > > > Hello. > maybe some of you are aware of the gcc FORTIFY_SOURCE application security flags. > Developers can enable compile and also runtime checks for some string / memory related operations with the flag. > > See details : > https://access.redhat.com/blogs/766093/posts/1976213 > > Have you tried already those flags in the OpenJDK ? > > One issue I experienced when using the flag (-D_FORTIFY_SOURCE=2) is that in case that a runtime issue is detected, > no hs_err file is written , only a "*** buffer overflow detected ***" + backtrace + Memory map output is written, looks like this : > > > *** buffer overflow detected ***: /bin/java terminated > ======= Backtrace: ========= > /lib64/libc.so.6(__fortify_fail+0x37)[0x7f5b500b7177] > /lib64/libc.so.6(+0xe8e10)[0x7f5b500b4e10] > /lib64/libc.so.6(+0xe8109)[0x7f5b500b4109] > /lib64/libc.so.6(_IO_default_xsputn+0x85)[0x7f5b5003f705] > /lib64/libc.so.6(_IO_vfprintf+0x18e)[0x7f5b5000f0ce] > /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f5b500b41ad] > /lib64/libc.so.6(__sprintf_chk+0x80)[0x7f5b500b40f0] > > ........ > ======= Memory map: ======== > c0000000-c0700000 rw-p 00000000 00:00 0 > ..... > > > > I would prefer to get a hs_err file, do you know a way to get this in context of the gcc flag _FORTIFY_SOURCE ? > > In case this is not possible, the flag might not be useful any more for OpenJDK . > Maybe the gcc7 flags for memory error detection > > https://developers.redhat.com/blog/2017/02/22/memory-error-detection-using-gcc/ > > might provide an alternative solution - are they already enabled by default ? > > > Thanks, Matthias From kim.barrett at oracle.com Fri May 3 15:46:49 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 3 May 2019 11:46:49 -0400 Subject: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: Message-ID: > On May 3, 2019, at 11:12 AM, Baesken, Matthias wrote: > > > > > Hello. > maybe some of you are aware of the gcc FORTIFY_SOURCE application security flags. > Developers can enable compile and also runtime checks for some string / memory related operations with the flag. > > See details : > https://access.redhat.com/blogs/766093/posts/1976213 > > Have you tried already those flags in the OpenJDK ? I happen to like _FORTIFY_SOURCE, as I?ve seen it catch some real problems that would have been much harder to find otherwise. However, we?ve tried it in the past and ran into some problems. There is an existing RFE to reinstate it?s use, which also mentions or references those previous attempts and the problems encountered. See JDK-8130017 "use _FORTIFY_SOURCE in gcc fastdebug builds?. I didn?t know about the hs_err problem. It might be considered less of a problem if only enabling in fastdebug builds (as suggested by JDK-8130017), as such builds are developer-oriented and the loss of an hs_err file is (while annoying) perhaps less critical. From erik.joelsson at oracle.com Fri May 3 15:54:41 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 08:54:41 -0700 Subject: RFR: JDK-8223309: test failing due to self-assign-overloaded In-Reply-To: <62cc02f8-5bf1-314e-fdc6-3dc0022e29bf@oracle.com> References: <62cc02f8-5bf1-314e-fdc6-3dc0022e29bf@oracle.com> Message-ID: I agreed to sponsor this off list. While doing a sanity build locally with the compiler we use at Oracle (Xcode 10.1), I discovered that clang does not let us use unknown warnings like we do with GCC: error: unknown warning option '-Wno-self-assign-overloaded'; did you mean '-Wno-self-assign-field'? [-Werror,-Wunknown-warning-option] I'm guessing -Wall is enabling that warning. Since we rely on being able to disable new warnings in new versions of the compilers we use, I added unknown-warning-option to the default set of disabled warnings for clang. New webrev: http://cr.openjdk.java.net/~erikj/8223309/webrev.01/ /Erik On 2019-05-03 08:02, Erik Joelsson wrote: > Hello, > > Change looks good, but I would prefer a line break. We try to keep the > lines in the makefiles/build system at least close to 80 chars when > possible. No need for new webrev if you make this change. > > /Erik > > On 2019-05-03 07:44, Johan Vos wrote: >> Using MacOS X 10.14.4 and Xcode 10.2.1 I could not build jdk/jdk >> anymore: >> /Users/johan/openjdk/jdk/test/hotspot/gtest/classfile/test_symbolTable.cpp:62:6: >> >> error: explicitly assigning value of variable of type 'TempNewSymbol' to >> itself [-Werror,-Wself-assign-overloaded] >> ?? s1 = s1; // self assignment >> ?? ~~ ^ ~~ >> 1 error generated. >> >> I added an entry to the list of disabled warnings, and that fixed the >> problem. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223309 >> >> Webrev: http://cr.openjdk.java.net/~jvos/8223309/webrev.00/ >> >> - Johan From tim.bell at oracle.com Fri May 3 16:03:08 2019 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 03 May 2019 09:03:08 -0700 Subject: RFR: JDK-8223309: test failing due to self-assign-overloaded In-Reply-To: References: <62cc02f8-5bf1-314e-fdc6-3dc0022e29bf@oracle.com> Message-ID: <5CCC663C.2030308@oracle.com> Erik: Looks good. Tim > I agreed to sponsor this off list. While doing a sanity build locally > with the compiler we use at Oracle (Xcode 10.1), I discovered that clang > does not let us use unknown warnings like we do with GCC: > > error: unknown warning option '-Wno-self-assign-overloaded'; did you > mean '-Wno-self-assign-field'? [-Werror,-Wunknown-warning-option] > > I'm guessing -Wall is enabling that warning. Since we rely on being able > to disable new warnings in new versions of the compilers we use, I added > unknown-warning-option to the default set of disabled warnings for clang. > > New webrev: http://cr.openjdk.java.net/~erikj/8223309/webrev.01/ > > /Erik > > On 2019-05-03 08:02, Erik Joelsson wrote: >> Hello, >> >> Change looks good, but I would prefer a line break. We try to keep the >> lines in the makefiles/build system at least close to 80 chars when >> possible. No need for new webrev if you make this change. >> >> /Erik >> >> On 2019-05-03 07:44, Johan Vos wrote: >>> Using MacOS X 10.14.4 and Xcode 10.2.1 I could not build jdk/jdk >>> anymore: >>> /Users/johan/openjdk/jdk/test/hotspot/gtest/classfile/test_symbolTable.cpp:62:6: >>> >>> error: explicitly assigning value of variable of type 'TempNewSymbol' to >>> itself [-Werror,-Wself-assign-overloaded] >>> s1 = s1; // self assignment >>> ~~ ^ ~~ >>> 1 error generated. >>> >>> I added an entry to the list of disabled warnings, and that fixed the >>> problem. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223309 >>> >>> Webrev: http://cr.openjdk.java.net/~jvos/8223309/webrev.00/ >>> >>> - Johan From sgehwolf at redhat.com Fri May 3 16:35:42 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 03 May 2019 18:35:42 +0200 Subject: [8u] RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization Message-ID: Hi, Could I please get reviews for this 8u backport of an optimization fix pertaining to the hotspot copy of fdlibm? Historically, sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have been compiled with optimization turned off on x86/x86_64. As JDK-8210416 will be backported to JDK 8u fixing optimization for fdlibm itself, so should be the hotspot copy in OpenJDK 8u. The build system for hotspot in JDK 8u is very different, so the original fix for JDK 12 doesn't apply. It's a complete rewrite. Please see this webrev which shows the prerequisite patch. It adds the FDLIBM_CFLAGS logic: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ It also fixes a bug on ppc64{,le} where optimization is being turned on in hotspot (-O3), but not providing the -ffp-contract=off flag (or older equivalent). Before (on ppc64le): /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp After (on ppc64le; Note -ffp-contract=off flag): /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -ffp-contract=off -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/jdk8/02/webrev Testing: Builds on x86_64 (server/Zero). Manual inspection of compile log of sharedRuntimeTrans.cpp/sharedRuntimeTrig.cpp. Same for ppc64le. Note that we've been using this patch downstream for a while now. We haven't seen any issues so far. Thanks, Severin From erik.joelsson at oracle.com Fri May 3 16:37:58 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 09:37:58 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages Message-ID: The (optional) specs and man pages should have the same copyright footer as the generated API docs. This patch adds the logic to add such footers. It also removes the existing footer in jvmti.html. Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html /Erik From iris.clark at oracle.com Fri May 3 16:53:23 2019 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 3 May 2019 09:53:23 -0700 (PDT) Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: References: Message-ID: <04a8b0c5-2984-41a9-8829-59782d7ac261@default> Hi, Erik. I'm happy to see this change go in. It looks good. Just one comment. When removing the footer in jvmit.html, I suspect that you also need to make changes to jvmti.xsl, which was also modified when the copyright footer was inserted in this changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9884b717f2ed Thanks, iris -----Original Message----- From: Erik Joelsson Sent: Friday, May 3, 2019 9:38 AM To: build-dev ; OpenJDK Serviceability Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages The (optional) specs and man pages should have the same copyright footer as the generated API docs. This patch adds the logic to add such footers. It also removes the existing footer in jvmti.html. Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html /Erik From alexey.semenyuk at oracle.com Fri May 3 17:04:37 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 3 May 2019 13:04:37 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <43E836D1-908F-426B-A4BB-6CD1A413A7B2@gmail.com> References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com> <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com> <5CC4F7E0.7020208@oracle.com> <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com> <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com> <43E836D1-908F-426B-A4BB-6CD1A413A7B2@gmail.com> Message-ID: <53cf1f6b-c9bc-d244-bb9a-3266a27253d5@oracle.com> Hi Scott, I agree this a good option. Though we still need to create some custom wix source code for shortcuts, so we can't get rid completely of Java code generating wix sources. - Alexey On 5/2/2019 8:54 PM, Scott Palmer wrote: > Ideally the wix code should be generated by running the heat.exe tool on the application image. > > Scott > >> On May 2, 2019, at 5:08 PM, Andy Herrick wrote: >> >> Alexey: >> >> Please file Bugs for these two issues. >> >> /Andy >> >> >>> On 5/2/2019 1:49 PM, Alexey Semenyuk wrote: >>> Some findings: >>> >>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: >>> I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html. Reason: these targets don't output executables into images/jdk/bin directory. They produce artifacts that stored as resources in jpackage just like other targets defined in Lib-jdk.jpackage.gmk. >>> >>> Wix source code produced by http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html doesn't comply to recommendations of how files should be packed in component. The recommendation is to use one file per a component - http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html. However jpackage produces way less components than files: >>> --- >>> $ less config/bundle.wxi | grep '>> 634 >>> >>> $ less config/bundle.wxi | grep '>> 1650 >>> --- >>> Data picked from my local test project. >>> >>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745 >>> + " Guid=\"" + UUID.randomUUID().toString() + "\"" >>> Use of random GUIDs for components is not recommended and potentially can result in issues with application updates. The recommended approach is to generate stable GUIDs - http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html, http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html. >>> Algorithm to create stable GUIDs is explained at https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the hassle of generating stable GUIDs if we would put only one file in every component. In this case WiX is able to generate stable GUIDs for us. >>> >>> - Alexey >>> >>>> On 4/27/2019 8:46 PM, Philip Race wrote: >>>> Adding build-dev for the build changes. I don't know if these were previously reviewed there, >>>> but I am not sure what the changes in NativeCompilation.gmk have to do with jpackage. >>>> >>>> -phil. >>>> >>>>> On 4/24/19, 5:47 PM, Andy Herrick wrote: >>>>> >>>>>> On 4/24/2019 8:44 PM, Andy Herrick wrote: >>>>>> Please review changes for [1] which is the implementation bug for JEP-343. >>>>>> >>>>>> The webrev at [2] is the total cumulative webrev of changes for the jpackage tool, currently in the JDK-8200758-branch branch of the open sandbox repository. >>>>>> >>>>>> The webrev at [3] shows the changes from EA-05 to EA-06. >>>>> sorry - the links are reversed from what is stated above. [2] is the incremental webrev since EA 05, [3] is the cumulativewebrev >>>>> /Andy >>>>>> The latest EA-6 (build 49) is posted at [4]. >>>>>> >>>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>>> >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>>>>> >>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/ >>>>>> >>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/ >>>>>> >>>>>> [4] http://jdk.java.net/jpackage/ >>>>>> >>>>>> >>>>>> /Andy >>>>>> >>>>>> From erik.joelsson at oracle.com Fri May 3 17:05:02 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 10:05:02 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: <04a8b0c5-2984-41a9-8829-59782d7ac261@default> References: <04a8b0c5-2984-41a9-8829-59782d7ac261@default> Message-ID: <0080c925-b766-7ff0-4d06-0fecd3e4066f@oracle.com> Thanks Iris! I did not think about jvmti.xsl, but have removed those lines as well now. New webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.02/ /Erik On 2019-05-03 09:53, Iris Clark wrote: > Hi, Erik. > > I'm happy to see this change go in. It looks good. > > Just one comment. When removing the footer in jvmit.html, I suspect that you also need to make changes to jvmti.xsl, which was also modified when the copyright footer was inserted in this changeset: > > http://hg.openjdk.java.net/jdk/jdk/rev/9884b717f2ed > > Thanks, > iris > > -----Original Message----- > From: Erik Joelsson > Sent: Friday, May 3, 2019 9:38 AM > To: build-dev ; OpenJDK Serviceability > Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages > > The (optional) specs and man pages should have the same copyright footer as the generated API docs. This patch adds the logic to add such footers. It also removes the existing footer in jvmti.html. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 > > Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html > > /Erik > From serguei.spitsyn at oracle.com Fri May 3 17:26:49 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 May 2019 10:26:49 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: References: Message-ID: Hi Erik, Could you, please, show a simple diff for jvmti.html and jdwp-protocol.html? Thanks, Serguei On 5/3/19 09:37, Erik Joelsson wrote: > The (optional) specs and man pages should have the same copyright > footer as the generated API docs. This patch adds the logic to add > such footers. It also removes the existing footer in jvmti.html. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 > > Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html > > /Erik > From alexey.semenyuk at oracle.com Fri May 3 17:31:07 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 3 May 2019 13:31:07 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com> References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com> <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com> <5CC4F7E0.7020208@oracle.com> <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com> <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com> Message-ID: <9a2388a2-6243-9360-536b-b71e4e52f9a5@oracle.com> Andy, I've created the following CRs to track the findings: https://bugs.openjdk.java.net/browse/JDK-8223325 https://bugs.openjdk.java.net/browse/JDK-8223323 - Alexey On 5/2/2019 5:08 PM, Andy Herrick wrote: > Alexey: > > Please file Bugs for these two issues. > > /Andy > > > On 5/2/2019 1:49 PM, Alexey Semenyuk wrote: >> Some findings: >> >> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: >> >> I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and >> BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to >> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html. >> Reason: these targets don't output executables into images/jdk/bin >> directory. They produce artifacts that stored as resources in >> jpackage just like other targets defined in Lib-jdk.jpackage.gmk. >> >> Wix source code produced by >> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html >> doesn't comply to recommendations of how files should be packed in >> component. The recommendation is to use one file per a component - >> http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html. >> However jpackage produces way less components than files: >> --- >> $ less config/bundle.wxi | grep '> 634 >> >> $ less config/bundle.wxi | grep '> 1650 >> --- >> Data picked from my local test project. >> >> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745 >> >> ???? + " Guid=\"" + UUID.randomUUID().toString() + "\"" >> Use of random GUIDs for components is not recommended and potentially >> can result in issues with application updates. The recommended >> approach is to generate stable GUIDs - >> http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html, >> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html. >> >> Algorithm to create stable GUIDs is explained at >> https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the >> hassle of generating stable GUIDs if we would put only one file in >> every component. In this case WiX is able to generate stable GUIDs >> for us. >> >> - Alexey >> >> On 4/27/2019 8:46 PM, Philip Race wrote: >>> Adding build-dev for the build changes. I don't know if these were >>> previously reviewed there, >>> but I am not sure what the changes in NativeCompilation.gmk have to >>> do with jpackage. >>> >>> -phil. >>> >>> On 4/24/19, 5:47 PM, Andy Herrick wrote: >>>> >>>> On 4/24/2019 8:44 PM, Andy Herrick wrote: >>>>> Please review? changes for [1] which is the implementation bug for >>>>> JEP-343. >>>>> >>>>> The webrev at [2] is the total cumulative webrev of changes for >>>>> the jpackage tool, currently in the JDK-8200758-branch branch of >>>>> the open sandbox repository. >>>>> >>>>> The webrev at [3] shows the changes from EA-05 to EA-06. >>>> sorry - the links are reversed from what is stated above. [2] is >>>> the incremental webrev since EA 05, [3] is the cumulativewebrev >>>> /Andy >>>>> >>>>> The latest EA-6 (build 49) is posted at [4]. >>>>> >>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>> >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>>>> >>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/ >>>>> >>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/ >>>>> >>>>> [4] http://jdk.java.net/jpackage/ >>>>> >>>>> >>>>> /Andy >>>>> >>>>> >>>> >> > From erik.joelsson at oracle.com Fri May 3 18:50:08 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 11:50:08 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: References: Message-ID: <18495294-3cd0-abee-90fe-500949fd8b08@oracle.com> The new footer looks exactly like on the api docs today. jvmti.html: 36481,36484c36481 --- >????
Copyright © 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.
DRAFT 13-internal+0-2019-04-29-1349399.erik.null jdwp-protocolhtml: 4071c4071 < --- >
Copyright © 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.
DRAFT 13-internal+0-2019-04-29-1349399.erik.null /Erik On 2019-05-03 10:26, serguei.spitsyn at oracle.com wrote: > Hi Erik, > > Could you, please, show a simple diff for jvmti.html and > jdwp-protocol.html? > > Thanks, > Serguei > > > On 5/3/19 09:37, Erik Joelsson wrote: >> The (optional) specs and man pages should have the same copyright >> footer as the generated API docs. This patch adds the logic to add >> such footers. It also removes the existing footer in jvmti.html. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html >> >> /Erik >> > From iris.clark at oracle.com Fri May 3 19:20:07 2019 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 3 May 2019 12:20:07 -0700 (PDT) Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: <0080c925-b766-7ff0-4d06-0fecd3e4066f@oracle.com> References: <04a8b0c5-2984-41a9-8829-59782d7ac261@default> <0080c925-b766-7ff0-4d06-0fecd3e4066f@oracle.com> Message-ID: Hi, Erik. > New webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.02/ The revised webrev looks good. Thank you! Iris From serguei.spitsyn at oracle.com Fri May 3 20:35:11 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 May 2019 13:35:11 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: <18495294-3cd0-abee-90fe-500949fd8b08@oracle.com> References: <18495294-3cd0-abee-90fe-500949fd8b08@oracle.com> Message-ID: <9485ec04-4860-7c78-4073-a3caaaa06608@oracle.com> Thank you, Erik. Is it the same with the jdwp-protocol.html? If so then I'm Okay with the fix. Thanks, Serguei On 5/3/19 11:50 AM, Erik Joelsson wrote: > The new footer looks exactly like on the api docs today. > > jvmti.html: > > 36481,36484c36481 > > rights reserved. > > > --- > >????
Copyright © > 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood > Shores, CA 94065 USA.
All rights reserved. Use is subject to href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license > terms and the href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation > redistribution policy.
DRAFT > 13-internal+0-2019-04-29-1349399.erik.null > > jdwp-protocolhtml: > > 4071c4071 > < > --- > >
Copyright © 1993, > 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood > Shores, CA 94065 USA.
All rights reserved. Use is subject to href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license > terms and the href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation > redistribution policy.
DRAFT > 13-internal+0-2019-04-29-1349399.erik.null > > /Erik > > On 2019-05-03 10:26, serguei.spitsyn at oracle.com wrote: >> Hi Erik, >> >> Could you, please, show a simple diff for jvmti.html and >> jdwp-protocol.html? >> >> Thanks, >> Serguei >> >> >> On 5/3/19 09:37, Erik Joelsson wrote: >>> The (optional) specs and man pages should have the same copyright >>> footer as the generated API docs. This patch adds the logic to add >>> such footers. It also removes the existing footer in jvmti.html. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html >>> >>> /Erik >>> >> From erik.joelsson at oracle.com Fri May 3 21:00:44 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 14:00:44 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: <9485ec04-4860-7c78-4073-a3caaaa06608@oracle.com> References: <18495294-3cd0-abee-90fe-500949fd8b08@oracle.com> <9485ec04-4860-7c78-4073-a3caaaa06608@oracle.com> Message-ID: I posted the diff for jdwp-protocol.html below too (but I forgot the dot in the filename). That file currently does not have any copyright visible in html, but the new footer looks the same (except for having a different relative path in the link to copyright.html). /Erik On 2019-05-03 13:35, serguei.spitsyn at oracle.com wrote: > Thank you, Erik. > Is it the same with the jdwp-protocol.html? > If so then I'm Okay with the fix. > > Thanks, > Serguei > > > On 5/3/19 11:50 AM, Erik Joelsson wrote: >> The new footer looks exactly like on the api docs today. >> >> jvmti.html: >> >> 36481,36484c36481 >> >> > rights reserved. >> >> >> --- >> >????
Copyright © >> 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood >> Shores, CA 94065 USA.
All rights reserved. Use is subject to > href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license >> terms and the > href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation >> redistribution policy.
DRAFT >> 13-internal+0-2019-04-29-1349399.erik.null >> >> jdwp-protocolhtml: >> >> 4071c4071 >> < >> --- >> >
Copyright © >> 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood >> Shores, CA 94065 USA.
All rights reserved. Use is subject to > href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license >> terms and the > href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation >> redistribution policy.
DRAFT >> 13-internal+0-2019-04-29-1349399.erik.null >> >> /Erik >> >> On 2019-05-03 10:26, serguei.spitsyn at oracle.com wrote: >>> Hi Erik, >>> >>> Could you, please, show a simple diff for jvmti.html and >>> jdwp-protocol.html? >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/3/19 09:37, Erik Joelsson wrote: >>>> The (optional) specs and man pages should have the same copyright >>>> footer as the generated API docs. This patch adds the logic to add >>>> such footers. It also removes the existing footer in jvmti.html. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html >>>> >>>> /Erik >>>> >>> > From serguei.spitsyn at oracle.com Fri May 3 21:50:51 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 May 2019 14:50:51 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: References: <18495294-3cd0-abee-90fe-500949fd8b08@oracle.com> <9485ec04-4860-7c78-4073-a3caaaa06608@oracle.com> Message-ID: <51ade44c-1e18-d7fd-fcf7-8fc257d953a5@oracle.com> On 5/3/19 2:00 PM, Erik Joelsson wrote: > I posted the diff for jdwp-protocol.html below too (but I forgot the > dot in the filename). That file currently does not have any copyright > visible in html, but the new footer looks the same (except for having > a different relative path in the link to copyright.html). Oh, thanks! I overlooked the second file name. So, I'm Okay with the fix. Thanks, Serguei > > /Erik > > On 2019-05-03 13:35, serguei.spitsyn at oracle.com wrote: >> Thank you, Erik. >> Is it the same with the jdwp-protocol.html? >> If so then I'm Okay with the fix. >> >> Thanks, >> Serguei >> >> >> On 5/3/19 11:50 AM, Erik Joelsson wrote: >>> The new footer looks exactly like on the api docs today. >>> >>> jvmti.html: >>> >>> 36481,36484c36481 >>> >>> >> rights reserved. >>> >>> >>> --- >>> >????
Copyright © >>> 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, >>> Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject >>> to >> href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license >>> terms and the >> href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation >>> redistribution policy.
DRAFT >>> 13-internal+0-2019-04-29-1349399.erik.null >>> >>> jdwp-protocolhtml: >>> >>> 4071c4071 >>> < >>> --- >>> >
Copyright © >>> 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, >>> Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject >>> to >> href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license >>> terms and the >> href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation >>> redistribution policy.
DRAFT >>> 13-internal+0-2019-04-29-1349399.erik.null >>> >>> /Erik >>> >>> On 2019-05-03 10:26, serguei.spitsyn at oracle.com wrote: >>>> Hi Erik, >>>> >>>> Could you, please, show a simple diff for jvmti.html and >>>> jdwp-protocol.html? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 5/3/19 09:37, Erik Joelsson wrote: >>>>> The (optional) specs and man pages should have the same copyright >>>>> footer as the generated API docs. This patch adds the logic to add >>>>> such footers. It also removes the existing footer in jvmti.html. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html >>>>> >>>>> /Erik >>>>> >>>> >> From matthias.baesken at sap.com Mon May 6 07:03:48 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 6 May 2019 07:03:48 +0000 Subject: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: Message-ID: Hello Kim and Erik, thanks for pointing me at https://bugs.openjdk.java.net/browse/JDK-8050803 https://bugs.openjdk.java.net/browse/JDK-8130017 I noticed too that the flag needs to be set together with optimization flags (which is pointed out in these 2 bugs). Performance seems to be not much affected (however I might need to look into it more ). But the missing hs_err file in case of hitting an issue is bad, as long as there is no fix for this, I would not set the flag (otherwise I like _FORTIFY_SOURCE ). Best regards, Matthias > > > > > > Hello. > > maybe some of you are aware of the gcc FORTIFY_SOURCE application > security flags. > > Developers can enable compile and also runtime checks for some string / > memory related operations with the flag. > > > > See details : > > https://access.redhat.com/blogs/766093/posts/1976213 > > > > Have you tried already those flags in the OpenJDK ? > > I happen to like _FORTIFY_SOURCE, as I?ve seen it catch some real problems > that would have been > much harder to find otherwise. However, we?ve tried it in the past and ran > into some problems. There > is an existing RFE to reinstate it?s use, which also mentions or references > those previous attempts and > the problems encountered. See JDK-8130017 "use _FORTIFY_SOURCE in gcc > fastdebug builds?. > > I didn?t know about the hs_err problem. It might be considered less of a > problem if only enabling in > fastdebug builds (as suggested by JDK-8130017), as such builds are > developer-oriented and the > loss of an hs_err file is (while annoying) perhaps less critical. From erik.joelsson at oracle.com Mon May 6 13:39:57 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 6 May 2019 06:39:57 -0700 Subject: RFR: JDK-8223335: Compare baseline builds on linux are failing Message-ID: <7db869af-24bb-ee3b-13be-5400d12c938b@oracle.com> Since JDK-8221851, the COMPARE_BUILD baseline builds have started failing. This seems to be caused by the same issue as affected reconfigure when introducing that change. A call to configure from make requires a cd to CONFIGURE_START_DIR first. Bug: https://bugs.openjdk.java.net/browse/JDK-8223335 Webrev: http://cr.openjdk.java.net/~erikj/8223335/webrev.01 /Erik From fweimer at redhat.com Mon May 6 14:38:19 2019 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 06 May 2019 16:38:19 +0200 Subject: gcc FORTIFY_SOURCE application security flags In-Reply-To: (Matthias Baesken's message of "Fri, 3 May 2019 15:12:51 +0000") References: Message-ID: <87r29bbqck.fsf@oldenburg2.str.redhat.com> * Matthias Baesken: > I would prefer to get a hs_err file, do you know a way to get this in > context of the gcc flag _FORTIFY_SOURCE ? __fortify_fail should eventually raise SIGABRT. So if you install a handler for that signal, you should be able to generate hs_err file. __fortify_fail is different from the other checks in that typically runs *before* memory corruption occurs, so it could be fairly safe to do in-process error logging. But that's not necessarily true for other process aborts, so intercepting SIGABRT could increase exposure. Thanks, Florian From tim.bell at oracle.com Mon May 6 14:54:27 2019 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 06 May 2019 07:54:27 -0700 Subject: RFR: JDK-8223335: Compare baseline builds on linux are failing In-Reply-To: <7db869af-24bb-ee3b-13be-5400d12c938b@oracle.com> References: <7db869af-24bb-ee3b-13be-5400d12c938b@oracle.com> Message-ID: <5CD04AA3.1030700@oracle.com> Erik: > ... A call to configure from make > requires a cd to CONFIGURE_START_DIR first. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223335 > > Webrev: http://cr.openjdk.java.net/~erikj/8223335/webrev.01 Looks good. Tim From christoph.langer at sap.com Tue May 7 14:15:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 May 2019 14:15:56 +0000 Subject: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 In-Reply-To: References: Message-ID: Ping: Can I please get a review for this? From: Langer, Christoph Sent: Dienstag, 30. April 2019 11:26 To: jdk-updates-dev at openjdk.java.net Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; Baesken, Matthias Subject: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 Hi, please help reviewing the backport of JDK-8210782: Upgrade HarfBuzz to the latest 2.3.1. This has been backported to 11.0.4-oracle already. I took the large change down to 11u-dev. It applies quite nicely, apart from a little issue in make/lib/Awt2dLibraries.gmk: --- Awt2dLibraries.gmk +++ Awt2dLibraries.gmk @@ -613,8 +614,7 @@ type-limits missing-field-initializers implicit-fallthrough \ strict-aliasing undef unused-function, \ DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ - maybe-uninitialized \ - missing-attributes class-memaccess, \ + maybe-uninitialized class-memaccess, \ DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \ tautological-constant-out-of-range-compare int-to-pointer-cast \ sign-compare undef missing-field-initializers, \ The original change would remove the disabling of the "missing-attributes" warnings, but since this warning type is not disabled in jdk11u-dev currently, I would just skip that diff. With that change, most platforms did build fine, except for Solaris (where we use Oracle Studio 12u4 in jdk11u-dev vs Oracle Studio 12u6 in jdk/jdk) and AIX (xlc12 vs. xlc16). To keep support for Oracle Studio 12u4 for Solaris, I had to remove the warning flag "refmemnoconstr_aggr" from line 622 (as opposed to the original change). Seems that it is not yet supported in OS12u4. Furthermore, a code tweak had to be done (Thanks, Matthias, for your help here): --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-cff-common.hh Fri Mar 01 16:59:19 2019 -0800 +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-cff-common.hh Mon Apr 29 16:26:41 2019 +0200 @@ -280,6 +280,10 @@ { str_buff_t &flatStr; bool drop_hints; + + // Solaris: OS12u4 complains about "A class with a reference member lacks a user-defined constructor" + // so provide the constructor + flatten_param_t(str_buff_t& sbt, bool dh) : flatStr(sbt), drop_hints(dh) {} }; template @@ -305,7 +309,9 @@ return false; cs_interpreter_t interp; interp.env.init (str, acc, fd); - flatten_param_t param = { flat_charstrings[i], drop_hints }; + // Solaris: OS12u4 does not like the C++11 style init + // flatten_param_t param = { flat_charstrings[i], drop_hints }; + flatten_param_t param(flat_charstrings[i], drop_hints); if (unlikely (!interp.interpret (param))) return false; } For AIX, this tweak had to be added (credit goes to Matthias as well): diff -r 2b3dbedfbfb9 src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh Fri Mar 01 16:59:19 2019 -0800 +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh Mon Apr 29 16:26:41 2019 +0200 @@ -83,7 +83,9 @@ template struct _hb_assign -{ static inline void value (T &o, const V v) { o = v; } }; +// add cast to please AIX xlc12.1 +//{ static inline void value (T &o, const V v) { o = v; } }; +{ static inline void value (T &o, const V v) { o = (T&) v; } }; template struct _hb_assign > { static inline void value (T &o, const V v) { o.set (v); } }; Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/7c11a7cc7c1d Review discussion for jdk/jdk: https://mail.openjdk.java.net/pipermail/2d-dev/2019-March/009914.html New Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8210782.jdk11u/ Thanks & Best regards Christoph From erik.joelsson at oracle.com Tue May 7 14:21:30 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 7 May 2019 07:21:30 -0700 Subject: RFR: JDK-8223464: Improve version string for Oracle CI builds Message-ID: This change changes how the version string will look in Oracle CI builds. A string that current looks like this: 13-internal+0-jdk13-jdk.844 Will instead look like this: 13-ea+0-844 For projects, the $PRE string will be used to identify the project, like this: 13-panama+0-844 While in the area, I also moved the setting of "ea" or not in the $PRE string to a property in the version-numbers file. Note that these changes only affect builds produced by Oracle. Bug: https://bugs.openjdk.java.net/browse/JDK-8223464 Webrev: http://cr.openjdk.java.net/~erikj/8223464/webrev.01/ /Erik From tim.bell at oracle.com Tue May 7 14:50:17 2019 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 07 May 2019 07:50:17 -0700 Subject: RFR: JDK-8223464: Improve version string for Oracle CI builds In-Reply-To: References: Message-ID: <5CD19B29.9070103@oracle.com> Erik: Looks good. Thanks for doing this. Tim On 05/07/19 07:21, Erik Joelsson wrote: > This change changes how the version string will look in Oracle CI > builds. A string that current looks like this: > > 13-internal+0-jdk13-jdk.844 > > Will instead look like this: > > 13-ea+0-844 > > For projects, the $PRE string will be used to identify the project, like > this: > > 13-panama+0-844 > > While in the area, I also moved the setting of "ea" or not in the $PRE > string to a property in the version-numbers file. > > Note that these changes only affect builds produced by Oracle. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223464 > > Webrev: http://cr.openjdk.java.net/~erikj/8223464/webrev.01/ > > /Erik From goetz.lindenmaier at sap.com Tue May 7 14:51:23 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 May 2019 14:51:23 +0000 Subject: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 In-Reply-To: References: Message-ID: Hi Christoph, I had a look at this change. The integration is good. I thought about the adaptions you had to do. They look good for the compilers you mention, and I would assume they also work with more recent ones. I guess nobody uses more recent compilers on Solaris. On AIX I know further adaptions are needed, and as they are missing it is ruled out anybody compiles with xlc 16. So looks good, too. I checked the tests, and the only somewhat related failing one is java/awt/FontMetrics/MaxAdvanceIsMax.java, but that is also failing without your patch. So testing is fine. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Dienstag, 30. April 2019 11:26 > To: jdk-updates-dev at openjdk.java.net > Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; Baesken, > Matthias > Subject: [CAUTION] [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 > > Hi, > > please help reviewing the backport of JDK-8210782: Upgrade HarfBuzz to the > latest 2.3.1. > > This has been backported to 11.0.4-oracle already. I took the large change > down to 11u-dev. It applies quite nicely, apart from a little issue in > make/lib/Awt2dLibraries.gmk: > > --- Awt2dLibraries.gmk > +++ Awt2dLibraries.gmk > @@ -613,8 +614,7 @@ > type-limits missing-field-initializers implicit-fallthrough \ > strict-aliasing undef unused-function, \ > DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict- > overflow \ > - maybe-uninitialized \ > - missing-attributes class-memaccess, \ > + maybe-uninitialized class-memaccess, \ > DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \ > tautological-constant-out-of-range-compare int-to-pointer-cast \ > sign-compare undef missing-field-initializers, \ > > The original change would remove the disabling of the "missing-attributes" > warnings, but since this warning type is not disabled in jdk11u-dev currently, I > would just skip that diff. > > With that change, most platforms did build fine, except for Solaris (where we > use Oracle Studio 12u4 in jdk11u-dev vs Oracle Studio 12u6 in jdk/jdk) and AIX > (xlc12 vs. xlc16). > > To keep support for Oracle Studio 12u4 for Solaris, I had to remove the warning > flag "refmemnoconstr_aggr" from line 622 (as opposed to the original change). > Seems that it is not yet supported in OS12u4. > > Furthermore, a code tweak had to be done (Thanks, Matthias, for your help > here): > > --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-cff- > common.hh Fri Mar 01 16:59:19 2019 -0800 > +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-cff- > common.hh Mon Apr 29 16:26:41 2019 +0200 > @@ -280,6 +280,10 @@ > { > str_buff_t &flatStr; > bool drop_hints; > + > + // Solaris: OS12u4 complains about "A class with a reference member lacks a > user-defined constructor" > + // so provide the constructor > + flatten_param_t(str_buff_t& sbt, bool dh) : flatStr(sbt), drop_hints(dh) {} > }; > > template > @@ -305,7 +309,9 @@ > return false; > cs_interpreter_t interp; > interp.env.init (str, acc, fd); > - flatten_param_t param = { flat_charstrings[i], drop_hints }; > + // Solaris: OS12u4 does not like the C++11 style init > + // flatten_param_t param = { flat_charstrings[i], drop_hints }; > + flatten_param_t param(flat_charstrings[i], drop_hints); > if (unlikely (!interp.interpret (param))) > return false; > } > > For AIX, this tweak had to be added (credit goes to Matthias as well): > diff -r 2b3dbedfbfb9 > src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh > --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh Fri > Mar 01 16:59:19 2019 -0800 > +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh > Mon Apr 29 16:26:41 2019 +0200 > @@ -83,7 +83,9 @@ > > template > struct _hb_assign > -{ static inline void value (T &o, const V v) { o = v; } }; > +// add cast to please AIX xlc12.1 > +//{ static inline void value (T &o, const V v) { o = v; } }; > +{ static inline void value (T &o, const V v) { o = (T&) v; } }; > template > struct _hb_assign > > > { static inline void value (T &o, const V v) { o.set (v); } }; > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/7c11a7cc7c1d > Review discussion for jdk/jdk: https://mail.openjdk.java.net/pipermail/2d- > dev/2019-March/009914.html > New Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8210782.jdk11u/ > > Thanks & Best regards > Christoph From matthias.baesken at sap.com Tue May 7 14:54:32 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 7 May 2019 14:54:32 +0000 Subject: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: Message-ID: Hello, I looked at JDK-8050803 . There are build issues reported when using the _FORTIFY_SOURCE flag . However I only noticed one build issue, this is related to an additional warning ("no result checking of fwrite call") , most likely generated by the added compile time checks of -D_FORTIFY_SOURCE=2 . Obviously , the _FORTIFY_SOURCE flag must be used together with optimization flags , otherwise the feature does not work . So I propose to add it to the optimization flags, but only in case we have a fastdebug build. See the patch below . Best regards, Matthias Patch : ----------- diff -r 26748009f2e5 make/autoconf/flags-cflags.m4 --- a/make/autoconf/flags-cflags.m4 Thu May 02 20:47:23 2019 +0200 +++ b/make/autoconf/flags-cflags.m4 Tue May 07 16:07:32 2019 +0200 @@ -300,6 +300,13 @@ C_O_FLAG_DEBUG="-O0" C_O_FLAG_DEBUG_JVM="-O0" C_O_FLAG_NONE="-O0" + # -D_FORTIFY_SOURCE=2 hardening option needs optimization enabled + if test "x$OPENJDK_TARGET_OS" = xlinux -a "x$DEBUG_LEVEL" = "xfastdebug"; then + C_O_FLAG_HIGHEST_JVM="${C_O_FLAG_HIGHEST_JVM} -D_FORTIFY_SOURCE=2" + C_O_FLAG_HIGHEST="${C_O_FLAG_HIGHEST} -D_FORTIFY_SOURCE=2" + C_O_FLAG_HI="${C_O_FLAG_HI} -D_FORTIFY_SOURCE=2" + C_O_FLAG_NORM="${C_O_FLAG_NORM} -D_FORTIFY_SOURCE=2" + fi elif test "x$TOOLCHAIN_TYPE" = xclang; then if test "x$OPENJDK_TARGET_OS" = xmacosx; then # On MacOSX we optimize for size, something diff -r 26748009f2e5 test/fmw/gtest/src/gtest.cc --- a/test/fmw/gtest/src/gtest.cc Thu May 02 20:47:23 2019 +0200 +++ b/test/fmw/gtest/src/gtest.cc Tue May 07 16:07:32 2019 +0200 @@ -34,6 +34,7 @@ #include "gtest/gtest.h" #include "gtest/gtest-spi.h" +#include #include #include #include @@ -3538,7 +3539,8 @@ // errors are ignored as there's nothing better we can do and we // don't want to fail the test because of this. FILE* pfile = posix::FOpen(premature_exit_filepath, "w"); - fwrite("0", 1, 1, pfile); + size_t cnt= fwrite("0", 1, 1, pfile); + assert(cnt == (size_t)1); fclose(pfile); } } > -----Original Message----- > From: Erik Joelsson > Sent: Freitag, 3. Mai 2019 17:40 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Subject: Re: gcc FORTIFY_SOURCE application security flags > > Hello Matthias, > > We have tried to use it before but later removed it. See > https://bugs.openjdk.java.net/browse/JDK-8050803 > > /Erik > > On 2019-05-03 08:12, Baesken, Matthias wrote: > > > > > > Hello. > > maybe some of you are aware of the gcc FORTIFY_SOURCE application > security flags. > > Developers can enable compile and also runtime checks for some string / > memory related operations with the flag. > > > > See details : > > https://access.redhat.com/blogs/766093/posts/1976213 > > > > Have you tried already those flags in the OpenJDK ? > > > > One issue I experienced when using the flag (-D_FORTIFY_SOURCE=2) is > that in case that a runtime issue is detected, > > no hs_err file is written , only a "*** buffer overflow detected ***" + > backtrace + Memory map output is written, looks like this : > > > > > > *** buffer overflow detected ***: /bin/java terminated > > ======= Backtrace: ========= > > /lib64/libc.so.6(__fortify_fail+0x37)[0x7f5b500b7177] > > /lib64/libc.so.6(+0xe8e10)[0x7f5b500b4e10] > > /lib64/libc.so.6(+0xe8109)[0x7f5b500b4109] > > /lib64/libc.so.6(_IO_default_xsputn+0x85)[0x7f5b5003f705] > > /lib64/libc.so.6(_IO_vfprintf+0x18e)[0x7f5b5000f0ce] > > /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f5b500b41ad] > > /lib64/libc.so.6(__sprintf_chk+0x80)[0x7f5b500b40f0] > > > > ........ > > ======= Memory map: ======== > > c0000000-c0700000 rw-p 00000000 00:00 0 > > ..... > > > > > > > > I would prefer to get a hs_err file, do you know a way to get this in context > of the gcc flag _FORTIFY_SOURCE ? > > > > In case this is not possible, the flag might not be useful any more for > OpenJDK . > > Maybe the gcc7 flags for memory error detection > > > > https://developers.redhat.com/blog/2017/02/22/memory-error- > detection-using-gcc/ > > > > might provide an alternative solution - are they already enabled by default > ? > > > > > > Thanks, Matthias From sgehwolf at redhat.com Tue May 7 15:19:40 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 07 May 2019 17:19:40 +0200 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: Message-ID: On Tue, 2019-05-07 at 14:51 +0000, Lindenmaier, Goetz wrote: > I checked the tests, and the only somewhat related > failing one is java/awt/FontMetrics/MaxAdvanceIsMax.java, > but that is also failing without your patch. How is it failing and has a bug been create for this failure if it's not a test setup issue? https://bugs.openjdk.java.net/browse/JDK-8218854 FWIW, I have: Passed: java/awt/FontMetrics/MaxAdvanceIsMax.java Thanks, Severin From Sergey.Bylokhov at oracle.com Tue May 7 17:12:07 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 7 May 2019 10:12:07 -0700 Subject: RFR: JDK-8223464: Improve version string for Oracle CI builds In-Reply-To: References: Message-ID: <6ce9acf0-1734-f0a8-6eaf-9ce67acd3c0d@oracle.com> Hi, Erik. I remember that some of the code uses the "internal" as a mark which enables additional assertions. Will this "internal" mark be used for the local builds? On 07/05/2019 07:21, Erik Joelsson wrote: > This change changes how the version string will look in Oracle CI builds. A string that current looks like this: > > 13-internal+0-jdk13-jdk.844 > > Will instead look like this: > > 13-ea+0-844 > > For projects, the $PRE string will be used to identify the project, like this: > > 13-panama+0-844 > > While in the area, I also moved the setting of "ea" or not in the $PRE string to a property in the version-numbers file. > > Note that these changes only affect builds produced by Oracle. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223464 > > Webrev: http://cr.openjdk.java.net/~erikj/8223464/webrev.01/ > > /Erik > -- Best regards, Sergey. From erik.joelsson at oracle.com Tue May 7 17:20:37 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 7 May 2019 10:20:37 -0700 Subject: RFR: JDK-8223464: Improve version string for Oracle CI builds In-Reply-To: <6ce9acf0-1734-f0a8-6eaf-9ce67acd3c0d@oracle.com> References: <6ce9acf0-1734-f0a8-6eaf-9ce67acd3c0d@oracle.com> Message-ID: <651e5a27-8c21-1486-b8c9-c21628175b41@oracle.com> Hello Sergey, On 2019-05-07 10:12, Sergey Bylokhov wrote: > Hi, Erik. > > I remember that some of the code uses the "internal" as a mark which > enables additional assertions. Will this "internal" mark be used for > the local builds? > Yes, the change only applies to CI builds. Local builds and any build without using Jib will be unaffected. /Erik > On 07/05/2019 07:21, Erik Joelsson wrote: >> This change changes how the version string will look in Oracle CI >> builds. A string that current looks like this: >> >> 13-internal+0-jdk13-jdk.844 >> >> Will instead look like this: >> >> 13-ea+0-844 >> >> For projects, the $PRE string will be used to identify the project, >> like this: >> >> 13-panama+0-844 >> >> While in the area, I also moved the setting of "ea" or not in the >> $PRE string to a property in the version-numbers file. >> >> Note that these changes only affect builds produced by Oracle. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223464 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8223464/webrev.01/ >> >> /Erik >> > > From goetz.lindenmaier at sap.com Wed May 8 06:26:56 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 8 May 2019 06:26:56 +0000 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: Message-ID: Hi Severin, Thanks for looking at the issue! I can reproduce the issue starting the test stand alone. So it's not a problem of our test infrastructure. But I can only reproduce it on a limited set of OSes: linuxppc64le: Red Hat Enterprise Linux Server release 7.2 (Maipo) Red Hat Enterprise Linux Server release 7.3 (Maipo) SUSE Linux Enterprise Server 15 I cannot reproduce it on these OSes: linuxppc64le: Red Hat Enterprise Linux Server VERSION 7.4 (Maipo) SUSE Linux Enterprise Server 12 (ppc64le) VERSION = 12 PATCHLEVEL = 1 Ubuntu 16.04.3 LTS Unfortunately, I don't have RHEL 7.2 or 7.3 on a linuxx86_64 box. But the test is passing on SLES 15 on linuxx86_64. I didn't yet open a bug for this, but the failure is still there with jdk-11.0.4+2. Checking 11.0.3, I see the failure too. So it is not a regression. I also can reproduce it with jdk/jdk on RHEL 7.2. Our nightly tests of 11.0.3 and jdk/jdk are scheduled on a SLES 12.3, therefor they don't show the problem. I'll send you a jtr file of the failure off-list. Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Tuesday, May 7, 2019 5:20 PM > To: Lindenmaier, Goetz ; Langer, Christoph > ; jdk-updates-dev at openjdk.java.net > Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; > Martin Balao Alonso > Subject: Re: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure > (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) > > On Tue, 2019-05-07 at 14:51 +0000, Lindenmaier, Goetz wrote: > > I checked the tests, and the only somewhat related > > failing one is java/awt/FontMetrics/MaxAdvanceIsMax.java, > > but that is also failing without your patch. > > How is it failing and has a bug been create for this failure if it's > not a test setup issue? > > https://bugs.openjdk.java.net/browse/JDK-8218854 > > FWIW, I have: > > Passed: java/awt/FontMetrics/MaxAdvanceIsMax.java > > Thanks, > Severin From matthias.baesken at sap.com Wed May 8 08:05:17 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 8 May 2019 08:05:17 +0000 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags Message-ID: Hello, here is a webrev, I used the existing bug "JDK-8130017 : use _FORTIFY_SOURCE in gcc fastdebug builds" Hope that?s fine . https://bugs.openjdk.java.net/browse/JDK-8130017 http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.0/ Our internal OpenJDK Linux (x86_64, ppc64, ppc64le , s390x) fastdebug builds are fine with the added flag . Best Regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 7. Mai 2019 16:55 > To: 'Erik Joelsson' ; 'build- > dev at openjdk.java.net' > Cc: 'Kim Barrett' ; Zeller, Arno > > Subject: RE: gcc FORTIFY_SOURCE application security flags > > Hello, I looked at JDK-8050803 . > There are build issues reported when using the _FORTIFY_SOURCE flag . > However I only noticed one build issue, this is related to an additional > warning ("no result checking of fwrite call") , most likely generated by the > added compile time checks of -D_FORTIFY_SOURCE=2 . > Obviously , the _FORTIFY_SOURCE flag must be used together with > optimization flags , otherwise the feature does not work . > So I propose to add it to the optimization flags, but only in case we have a > fastdebug build. See the patch below . > > Best regards, Matthias > > > Patch : > ----------- > > diff -r 26748009f2e5 make/autoconf/flags-cflags.m4 > --- a/make/autoconf/flags-cflags.m4 Thu May 02 20:47:23 2019 +0200 > +++ b/make/autoconf/flags-cflags.m4 Tue May 07 16:07:32 2019 +0200 > @@ -300,6 +300,13 @@ > C_O_FLAG_DEBUG="-O0" > C_O_FLAG_DEBUG_JVM="-O0" > C_O_FLAG_NONE="-O0" > + # -D_FORTIFY_SOURCE=2 hardening option needs optimization enabled > + if test "x$OPENJDK_TARGET_OS" = xlinux -a "x$DEBUG_LEVEL" = > "xfastdebug"; then > + C_O_FLAG_HIGHEST_JVM="${C_O_FLAG_HIGHEST_JVM} - > D_FORTIFY_SOURCE=2" > + C_O_FLAG_HIGHEST="${C_O_FLAG_HIGHEST} -D_FORTIFY_SOURCE=2" > + C_O_FLAG_HI="${C_O_FLAG_HI} -D_FORTIFY_SOURCE=2" > + C_O_FLAG_NORM="${C_O_FLAG_NORM} -D_FORTIFY_SOURCE=2" > + fi > elif test "x$TOOLCHAIN_TYPE" = xclang; then > if test "x$OPENJDK_TARGET_OS" = xmacosx; then > # On MacOSX we optimize for size, something > diff -r 26748009f2e5 test/fmw/gtest/src/gtest.cc > --- a/test/fmw/gtest/src/gtest.cc Thu May 02 20:47:23 2019 +0200 > +++ b/test/fmw/gtest/src/gtest.cc Tue May 07 16:07:32 2019 +0200 > @@ -34,6 +34,7 @@ > #include "gtest/gtest.h" > #include "gtest/gtest-spi.h" > > +#include > #include > #include > #include > @@ -3538,7 +3539,8 @@ > // errors are ignored as there's nothing better we can do and we > // don't want to fail the test because of this. > FILE* pfile = posix::FOpen(premature_exit_filepath, "w"); > - fwrite("0", 1, 1, pfile); > + size_t cnt= fwrite("0", 1, 1, pfile); > + assert(cnt == (size_t)1); > fclose(pfile); > } > } > > > > -----Original Message----- > > From: Erik Joelsson > > Sent: Freitag, 3. Mai 2019 17:40 > > To: Baesken, Matthias ; 'build- > > dev at openjdk.java.net' > > Subject: Re: gcc FORTIFY_SOURCE application security flags > > > > Hello Matthias, > > > > We have tried to use it before but later removed it. See > > https://bugs.openjdk.java.net/browse/JDK-8050803 > > > > /Erik > > > > On 2019-05-03 08:12, Baesken, Matthias wrote: > > > > > > > > > Hello. > > > maybe some of you are aware of the gcc FORTIFY_SOURCE application > > security flags. > > > Developers can enable compile and also runtime checks for some string / > > memory related operations with the flag. > > > > > > See details : > > > https://access.redhat.com/blogs/766093/posts/1976213 > > > > > > Have you tried already those flags in the OpenJDK ? > > > > > > One issue I experienced when using the flag (-D_FORTIFY_SOURCE=2) is > > that in case that a runtime issue is detected, > > > no hs_err file is written , only a "*** buffer overflow detected ***" + > > backtrace + Memory map output is written, looks like this : > > > > > > > > > *** buffer overflow detected ***: /bin/java terminated > > > ======= Backtrace: ========= > > > /lib64/libc.so.6(__fortify_fail+0x37)[0x7f5b500b7177] > > > /lib64/libc.so.6(+0xe8e10)[0x7f5b500b4e10] > > > /lib64/libc.so.6(+0xe8109)[0x7f5b500b4109] > > > /lib64/libc.so.6(_IO_default_xsputn+0x85)[0x7f5b5003f705] > > > /lib64/libc.so.6(_IO_vfprintf+0x18e)[0x7f5b5000f0ce] > > > /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f5b500b41ad] > > > /lib64/libc.so.6(__sprintf_chk+0x80)[0x7f5b500b40f0] > > > > > > ........ > > > ======= Memory map: ======== > > > c0000000-c0700000 rw-p 00000000 00:00 0 > > > ..... > > > > > > > > > > > > I would prefer to get a hs_err file, do you know a way to get this in > context > > of the gcc flag _FORTIFY_SOURCE ? > > > > > > In case this is not possible, the flag might not be useful any more for > > OpenJDK . > > > Maybe the gcc7 flags for memory error detection > > > > > > https://developers.redhat.com/blog/2017/02/22/memory-error- > > detection-using-gcc/ > > > > > > might provide an alternative solution - are they already enabled by > default > > ? > > > > > > > > > Thanks, Matthias From david.holmes at oracle.com Wed May 8 12:06:08 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 May 2019 22:06:08 +1000 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: Message-ID: Hi Matthias, On 8/05/2019 6:05 pm, Baesken, Matthias wrote: > Hello, here is a webrev, I used the existing bug > "JDK-8130017 : use _FORTIFY_SOURCE in gcc fastdebug builds" > > Hope that?s fine . That is fine, but please add a comment to the bug explaining exactly how you fixed the issue and how the issues raised in the bug description regarding optimisation levels have been addressed. Not a review - I'll leave that to build team. The proof of this will be in the building and testing. Thanks, David > https://bugs.openjdk.java.net/browse/JDK-8130017 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.0/ > > > Our internal OpenJDK Linux (x86_64, ppc64, ppc64le , s390x) fastdebug builds are fine with the added flag . > > > Best Regards, Matthias > > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Dienstag, 7. Mai 2019 16:55 >> To: 'Erik Joelsson' ; 'build- >> dev at openjdk.java.net' >> Cc: 'Kim Barrett' ; Zeller, Arno >> >> Subject: RE: gcc FORTIFY_SOURCE application security flags >> >> Hello, I looked at JDK-8050803 . >> There are build issues reported when using the _FORTIFY_SOURCE flag . >> However I only noticed one build issue, this is related to an additional >> warning ("no result checking of fwrite call") , most likely generated by the >> added compile time checks of -D_FORTIFY_SOURCE=2 . >> Obviously , the _FORTIFY_SOURCE flag must be used together with >> optimization flags , otherwise the feature does not work . >> So I propose to add it to the optimization flags, but only in case we have a >> fastdebug build. See the patch below . >> >> Best regards, Matthias >> >> >> Patch : >> ----------- >> >> diff -r 26748009f2e5 make/autoconf/flags-cflags.m4 >> --- a/make/autoconf/flags-cflags.m4 Thu May 02 20:47:23 2019 +0200 >> +++ b/make/autoconf/flags-cflags.m4 Tue May 07 16:07:32 2019 +0200 >> @@ -300,6 +300,13 @@ >> C_O_FLAG_DEBUG="-O0" >> C_O_FLAG_DEBUG_JVM="-O0" >> C_O_FLAG_NONE="-O0" >> + # -D_FORTIFY_SOURCE=2 hardening option needs optimization enabled >> + if test "x$OPENJDK_TARGET_OS" = xlinux -a "x$DEBUG_LEVEL" = >> "xfastdebug"; then >> + C_O_FLAG_HIGHEST_JVM="${C_O_FLAG_HIGHEST_JVM} - >> D_FORTIFY_SOURCE=2" >> + C_O_FLAG_HIGHEST="${C_O_FLAG_HIGHEST} -D_FORTIFY_SOURCE=2" >> + C_O_FLAG_HI="${C_O_FLAG_HI} -D_FORTIFY_SOURCE=2" >> + C_O_FLAG_NORM="${C_O_FLAG_NORM} -D_FORTIFY_SOURCE=2" >> + fi >> elif test "x$TOOLCHAIN_TYPE" = xclang; then >> if test "x$OPENJDK_TARGET_OS" = xmacosx; then >> # On MacOSX we optimize for size, something >> diff -r 26748009f2e5 test/fmw/gtest/src/gtest.cc >> --- a/test/fmw/gtest/src/gtest.cc Thu May 02 20:47:23 2019 +0200 >> +++ b/test/fmw/gtest/src/gtest.cc Tue May 07 16:07:32 2019 +0200 >> @@ -34,6 +34,7 @@ >> #include "gtest/gtest.h" >> #include "gtest/gtest-spi.h" >> >> +#include >> #include >> #include >> #include >> @@ -3538,7 +3539,8 @@ >> // errors are ignored as there's nothing better we can do and we >> // don't want to fail the test because of this. >> FILE* pfile = posix::FOpen(premature_exit_filepath, "w"); >> - fwrite("0", 1, 1, pfile); >> + size_t cnt= fwrite("0", 1, 1, pfile); >> + assert(cnt == (size_t)1); >> fclose(pfile); >> } >> } >> >> >>> -----Original Message----- >>> From: Erik Joelsson >>> Sent: Freitag, 3. Mai 2019 17:40 >>> To: Baesken, Matthias ; 'build- >>> dev at openjdk.java.net' >>> Subject: Re: gcc FORTIFY_SOURCE application security flags >>> >>> Hello Matthias, >>> >>> We have tried to use it before but later removed it. See >>> https://bugs.openjdk.java.net/browse/JDK-8050803 >>> >>> /Erik >>> >>> On 2019-05-03 08:12, Baesken, Matthias wrote: >>>> >>>> >>>> Hello. >>>> maybe some of you are aware of the gcc FORTIFY_SOURCE application >>> security flags. >>>> Developers can enable compile and also runtime checks for some string / >>> memory related operations with the flag. >>>> >>>> See details : >>>> https://access.redhat.com/blogs/766093/posts/1976213 >>>> >>>> Have you tried already those flags in the OpenJDK ? >>>> >>>> One issue I experienced when using the flag (-D_FORTIFY_SOURCE=2) is >>> that in case that a runtime issue is detected, >>>> no hs_err file is written , only a "*** buffer overflow detected ***" + >>> backtrace + Memory map output is written, looks like this : >>>> >>>> >>>> *** buffer overflow detected ***: /bin/java terminated >>>> ======= Backtrace: ========= >>>> /lib64/libc.so.6(__fortify_fail+0x37)[0x7f5b500b7177] >>>> /lib64/libc.so.6(+0xe8e10)[0x7f5b500b4e10] >>>> /lib64/libc.so.6(+0xe8109)[0x7f5b500b4109] >>>> /lib64/libc.so.6(_IO_default_xsputn+0x85)[0x7f5b5003f705] >>>> /lib64/libc.so.6(_IO_vfprintf+0x18e)[0x7f5b5000f0ce] >>>> /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f5b500b41ad] >>>> /lib64/libc.so.6(__sprintf_chk+0x80)[0x7f5b500b40f0] >>>> >>>> ........ >>>> ======= Memory map: ======== >>>> c0000000-c0700000 rw-p 00000000 00:00 0 >>>> ..... >>>> >>>> >>>> >>>> I would prefer to get a hs_err file, do you know a way to get this in >> context >>> of the gcc flag _FORTIFY_SOURCE ? >>>> >>>> In case this is not possible, the flag might not be useful any more for >>> OpenJDK . >>>> Maybe the gcc7 flags for memory error detection >>>> >>>> https://developers.redhat.com/blog/2017/02/22/memory-error- >>> detection-using-gcc/ >>>> >>>> might provide an alternative solution - are they already enabled by >> default >>> ? >>>> >>>> >>>> Thanks, Matthias From matthias.baesken at sap.com Wed May 8 12:36:52 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 8 May 2019 12:36:52 +0000 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: Message-ID: Hi David, thanks for the comment . Currently I do not see the issue in our fastdebug builds . So I think the opt-flag filtering got changed/removed in the years after the issues were reported . https://bugs.openjdk.java.net/browse/JDK-8047952 mentions special O-level settings for sharedRuntimeTrig.cpp and sharedRuntimeTrans.cpp . But the files have optimization set in both fastdebug and opt builds : Linux x86_64 gcc-7 based builds : fastdebug build (with the added -D_FORTIFY_SOURCE=2 flag) : -Werror -O3 -D_FORTIFY_SOURCE=2 -DNO_PCH -ffp-contract=off -O2 -D_FORTIFY_SOURCE=2 Opt build (without -D_FORTIFY_SOURCE=... ) : -O3 -DNO_PCH -ffp-contract=off -O2 .... (btw. the setting of both -O3 AND -O2 looks strange to me , but that?s unrelated to my change ; I noticed that already in OpenJDK 11 ). Best regards, Matthias > > Hi Matthias, > > On 8/05/2019 6:05 pm, Baesken, Matthias wrote: > > Hello, here is a webrev, I used the existing bug > > "JDK-8130017 : use _FORTIFY_SOURCE in gcc fastdebug builds" > > > > Hope that?s fine . > > That is fine, but please add a comment to the bug explaining exactly how > you fixed the issue and how the issues raised in the bug description > regarding optimisation levels have been addressed. > > Not a review - I'll leave that to build team. The proof of this will be > in the building and testing. > > Thanks, > David > > > https://bugs.openjdk.java.net/browse/JDK-8130017 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.0/ > > > > > > Our internal OpenJDK Linux (x86_64, ppc64, ppc64le , s390x) fastdebug > builds are fine with the added flag . > > > > > > Best Regards, Matthias > > > > > > > >> -----Original Message----- > >> From: Baesken, Matthias > >> Sent: Dienstag, 7. Mai 2019 16:55 > >> To: 'Erik Joelsson' ; 'build- > >> dev at openjdk.java.net' > >> Cc: 'Kim Barrett' ; Zeller, Arno > >> > >> Subject: RE: gcc FORTIFY_SOURCE application security flags > >> > >> Hello, I looked at JDK-8050803 . > >> There are build issues reported when using the _FORTIFY_SOURCE flag . > >> However I only noticed one build issue, this is related to an additional > >> warning ("no result checking of fwrite call") , most likely generated by > the > >> added compile time checks of -D_FORTIFY_SOURCE=2 . > >> Obviously , the _FORTIFY_SOURCE flag must be used together with > >> optimization flags , otherwise the feature does not work . > >> So I propose to add it to the optimization flags, but only in case we have a > >> fastdebug build. See the patch below . > >> > >> Best regards, Matthias > >> > >> > >> Patch : > >> ----------- > >> > >> diff -r 26748009f2e5 make/autoconf/flags-cflags.m4 > >> --- a/make/autoconf/flags-cflags.m4 Thu May 02 20:47:23 2019 +0200 > >> +++ b/make/autoconf/flags-cflags.m4 Tue May 07 16:07:32 2019 +0200 > >> @@ -300,6 +300,13 @@ > >> C_O_FLAG_DEBUG="-O0" > >> C_O_FLAG_DEBUG_JVM="-O0" > >> C_O_FLAG_NONE="-O0" > >> + # -D_FORTIFY_SOURCE=2 hardening option needs optimization > enabled > >> + if test "x$OPENJDK_TARGET_OS" = xlinux -a "x$DEBUG_LEVEL" = > >> "xfastdebug"; then > >> + C_O_FLAG_HIGHEST_JVM="${C_O_FLAG_HIGHEST_JVM} - > >> D_FORTIFY_SOURCE=2" > >> + C_O_FLAG_HIGHEST="${C_O_FLAG_HIGHEST} - > D_FORTIFY_SOURCE=2" > >> + C_O_FLAG_HI="${C_O_FLAG_HI} -D_FORTIFY_SOURCE=2" > >> + C_O_FLAG_NORM="${C_O_FLAG_NORM} -D_FORTIFY_SOURCE=2" > >> + fi > >> elif test "x$TOOLCHAIN_TYPE" = xclang; then > >> if test "x$OPENJDK_TARGET_OS" = xmacosx; then > >> # On MacOSX we optimize for size, something > >> diff -r 26748009f2e5 test/fmw/gtest/src/gtest.cc > >> --- a/test/fmw/gtest/src/gtest.cc Thu May 02 20:47:23 2019 +0200 > >> +++ b/test/fmw/gtest/src/gtest.cc Tue May 07 16:07:32 2019 +0200 > >> @@ -34,6 +34,7 @@ > >> #include "gtest/gtest.h" > >> #include "gtest/gtest-spi.h" > >> > >> +#include > >> #include > >> #include > >> #include > >> @@ -3538,7 +3539,8 @@ > >> // errors are ignored as there's nothing better we can do and we > >> // don't want to fail the test because of this. > >> FILE* pfile = posix::FOpen(premature_exit_filepath, "w"); > >> - fwrite("0", 1, 1, pfile); > >> + size_t cnt= fwrite("0", 1, 1, pfile); > >> + assert(cnt == (size_t)1); > >> fclose(pfile); > >> } > >> } > >> > >> > >>> -----Original Message----- > >>> From: Erik Joelsson > >>> Sent: Freitag, 3. Mai 2019 17:40 > >>> To: Baesken, Matthias ; 'build- > >>> dev at openjdk.java.net' > >>> Subject: Re: gcc FORTIFY_SOURCE application security flags > >>> > >>> Hello Matthias, > >>> > >>> We have tried to use it before but later removed it. See > >>> https://bugs.openjdk.java.net/browse/JDK-8050803 > >>> > >>> /Erik > >>> > >>> On 2019-05-03 08:12, Baesken, Matthias wrote: > >>>> > >>>> > >>>> Hello. > >>>> maybe some of you are aware of the gcc FORTIFY_SOURCE > application > >>> security flags. > >>>> Developers can enable compile and also runtime checks for some string > / > >>> memory related operations with the flag. > >>>> > >>>> See details : > >>>> https://access.redhat.com/blogs/766093/posts/1976213 > >>>> > >>>> Have you tried already those flags in the OpenJDK ? > >>>> > >>>> One issue I experienced when using the flag (-D_FORTIFY_SOURCE=2) > is > >>> that in case that a runtime issue is detected, > >>>> no hs_err file is written , only a "*** buffer overflow detected ***" + > >>> backtrace + Memory map output is written, looks like this : > >>>> > >>>> > >>>> *** buffer overflow detected ***: /bin/java terminated > >>>> ======= Backtrace: ========= > >>>> /lib64/libc.so.6(__fortify_fail+0x37)[0x7f5b500b7177] > >>>> /lib64/libc.so.6(+0xe8e10)[0x7f5b500b4e10] > >>>> /lib64/libc.so.6(+0xe8109)[0x7f5b500b4109] > >>>> /lib64/libc.so.6(_IO_default_xsputn+0x85)[0x7f5b5003f705] > >>>> /lib64/libc.so.6(_IO_vfprintf+0x18e)[0x7f5b5000f0ce] > >>>> /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f5b500b41ad] > >>>> /lib64/libc.so.6(__sprintf_chk+0x80)[0x7f5b500b40f0] > >>>> > >>>> ........ > >>>> ======= Memory map: ======== > >>>> c0000000-c0700000 rw-p 00000000 00:00 0 > >>>> ..... > >>>> > >>>> > >>>> > >>>> I would prefer to get a hs_err file, do you know a way to get this in > >> context > >>> of the gcc flag _FORTIFY_SOURCE ? > >>>> > >>>> In case this is not possible, the flag might not be useful any more for > >>> OpenJDK . > >>>> Maybe the gcc7 flags for memory error detection > >>>> > >>>> https://developers.redhat.com/blog/2017/02/22/memory-error- > >>> detection-using-gcc/ > >>>> > >>>> might provide an alternative solution - are they already enabled by > >> default > >>> ? > >>>> > >>>> > >>>> Thanks, Matthias From matthias.baesken at sap.com Wed May 8 13:27:26 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 8 May 2019 13:27:26 +0000 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: Message-ID: Hello, I looked a bit more into it . It seems to me , that when -ffp-contract=off is available which is the case with current gcc versions , we want to optimize the 2 special files ( sharedRuntimeTrig.cpp / sharedRuntimeTrans.cpp ). see the following comments : jdk/make/hotspot/lib/JvmOverrideFiles.gmk 47# If the FDLIBM_CFLAGS variable is non-empty we know 48# that the fdlibm-fork in hotspot can get optimized 49# by using -ffp-contract=off on GCC/Clang platforms. ...... 58 BUILD_LIBJVM_sharedRuntimeTrig.cpp_CXXFLAGS := -DNO_PCH $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) 59 BUILD_LIBJVM_sharedRuntimeTrans.cpp_CXXFLAGS := -DNO_PCH $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) 60 But still, setting both -O3 and -O2 in one compile call looks not nice to me . In case of ancient gcc ***without*** -ffp-contract=off , we might still run into issues for these 2 special files when _FORTIFY_SOURCE is set . Don't know if this is still relevant . In case we want to be on the very safe side , we might need to filter out -D_FORTIFY_SOURCE=2 for these 2 compilation units . Best regards, Matthias > > Hi David, thanks for the comment . > > Currently I do not see the issue in our fastdebug builds . > So I think the opt-flag filtering got changed/removed in the years after the > issues were reported . > > > https://bugs.openjdk.java.net/browse/JDK-8047952 > > mentions special O-level settings for sharedRuntimeTrig.cpp and > sharedRuntimeTrans.cpp . > > But the files have optimization set in both fastdebug and opt builds : > > Linux x86_64 gcc-7 based builds : > > fastdebug build (with the added -D_FORTIFY_SOURCE=2 flag) : > > -Werror -O3 -D_FORTIFY_SOURCE=2 -DNO_PCH -ffp-contract=off -O2 - > D_FORTIFY_SOURCE=2 > > > Opt build (without -D_FORTIFY_SOURCE=... ) : > > -O3 -DNO_PCH -ffp-contract=off -O2 .... > > > (btw. the setting of both -O3 AND -O2 looks strange to me , but that?s > unrelated to my change ; I noticed that already in OpenJDK 11 ). > > > Best regards, Matthias > > > > > > > > Hi Matthias, > > > > On 8/05/2019 6:05 pm, Baesken, Matthias wrote: > > > Hello, here is a webrev, I used the existing bug > > > "JDK-8130017 : use _FORTIFY_SOURCE in gcc fastdebug builds" > > > > > > Hope that?s fine . > > > > That is fine, but please add a comment to the bug explaining exactly how > > you fixed the issue and how the issues raised in the bug description > > regarding optimisation levels have been addressed. > > > > Not a review - I'll leave that to build team. The proof of this will be > > in the building and testing. > > > > Thanks, > > David > > > > > https://bugs.openjdk.java.net/browse/JDK-8130017 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.0/ > > > > > > > > > Our internal OpenJDK Linux (x86_64, ppc64, ppc64le , s390x) fastdebug > > builds are fine with the added flag . > > > > > > From erik.joelsson at oracle.com Wed May 8 15:19:04 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 8 May 2019 08:19:04 -0700 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: Message-ID: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> Hello Matthias, On 2019-05-08 06:27, Baesken, Matthias wrote: > Hello, I looked a bit more into it . > It seems to me , that when -ffp-contract=off is available which is the case with current gcc versions , we want to optimize the 2 special files ( sharedRuntimeTrig.cpp / sharedRuntimeTrans.cpp ). > see the following comments : > > jdk/make/hotspot/lib/JvmOverrideFiles.gmk > > 47# If the FDLIBM_CFLAGS variable is non-empty we know > 48# that the fdlibm-fork in hotspot can get optimized > 49# by using -ffp-contract=off on GCC/Clang platforms. > ...... > 58 BUILD_LIBJVM_sharedRuntimeTrig.cpp_CXXFLAGS := -DNO_PCH $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) > 59 BUILD_LIBJVM_sharedRuntimeTrans.cpp_CXXFLAGS := -DNO_PCH $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) > 60 Will this not just resolve itself if you also add -D_FORTIFY_SOURCE=0 to C_O_FLAG_NONE (and all the other optimization flag variables that have the value "-O0")? > But still, setting both -O3 and -O2 in one compile call looks not nice to me . This may not look nice, but is how we have to do things. The last flag on a compiler command line takes precedence. We rely on this to override general flags with more specific ones (typically a general flag for the whole library with specific ones for certain compilation units). This technique is quite common. > > In case of ancient gcc ***without*** -ffp-contract=off , we might still run into issues for these 2 special files when _FORTIFY_SOURCE is set . > Don't know if this is still relevant . > In case we want to be on the very safe side , we might need to filter out -D_FORTIFY_SOURCE=2 for these 2 compilation units . We don't want to filter out flags. It creates very brittle code that is likely to break in the future. For the patch, I think it would make sense to introduce a variable for the value -D_FORTIFY_SOURCE=2 (and -D_FORTIFY_SOURCE=0/-U_FORTIFY_SOURCE) to avoid repeating it. /Erik > Best regards, Matthias > > > >> Hi David, thanks for the comment . >> >> Currently I do not see the issue in our fastdebug builds . >> So I think the opt-flag filtering got changed/removed in the years after the >> issues were reported . >> >> >> https://bugs.openjdk.java.net/browse/JDK-8047952 >> >> mentions special O-level settings for sharedRuntimeTrig.cpp and >> sharedRuntimeTrans.cpp . >> >> But the files have optimization set in both fastdebug and opt builds : >> >> Linux x86_64 gcc-7 based builds : >> >> fastdebug build (with the added -D_FORTIFY_SOURCE=2 flag) : >> >> -Werror -O3 -D_FORTIFY_SOURCE=2 -DNO_PCH -ffp-contract=off -O2 - >> D_FORTIFY_SOURCE=2 >> >> >> Opt build (without -D_FORTIFY_SOURCE=... ) : >> >> -O3 -DNO_PCH -ffp-contract=off -O2 .... >> >> >> (btw. the setting of both -O3 AND -O2 looks strange to me , but that?s >> unrelated to my change ; I noticed that already in OpenJDK 11 ). >> >> >> Best regards, Matthias >> >> >> >> >>> Hi Matthias, >>> >>> On 8/05/2019 6:05 pm, Baesken, Matthias wrote: >>>> Hello, here is a webrev, I used the existing bug >>>> "JDK-8130017 : use _FORTIFY_SOURCE in gcc fastdebug builds" >>>> >>>> Hope that?s fine . >>> That is fine, but please add a comment to the bug explaining exactly how >>> you fixed the issue and how the issues raised in the bug description >>> regarding optimisation levels have been addressed. >>> >>> Not a review - I'll leave that to build team. The proof of this will be >>> in the building and testing. >>> >>> Thanks, >>> David >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8130017 >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.0/ >>>> >>>> >>>> Our internal OpenJDK Linux (x86_64, ppc64, ppc64le , s390x) fastdebug >>> builds are fine with the added flag . >>>> From sgehwolf at redhat.com Wed May 8 17:10:01 2019 From: sgehwolf at redhat.com (sgehwolf at redhat.com) Date: Wed, 08 May 2019 19:10:01 +0200 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: Message-ID: <6e97b6d7cba1a4ffe8456759d57600df0225f30f.camel@redhat.com> Hi Matthias, For some background about the -O2 -ffp-contract=off flags for sharedRuntimeTrig.cpp and sharedRuntimeTrans.cpp see: https://bugs.openjdk.java.net/browse/JDK-8210425 My understanding is that if there is a per-file override of the optimization level, the compilation command will end up containing both -O3 and a later, possible override, via the per-file settings. The -O3 flag originates from it being a release/fastdebug build. Thanks, Severin On Wed, 2019-05-08 at 13:27 +0000, Baesken, Matthias wrote: > Hello, I looked a bit more into it . > It seems to me , that when -ffp-contract=off is > available which is the case with current gcc versions , we want to > optimize the 2 special files ( sharedRuntimeTrig.cpp / > sharedRuntimeTrans.cpp ). > see the following comments : > > jdk/make/hotspot/lib/JvmOverrideFiles.gmk > > 47# If the FDLIBM_CFLAGS variable is non-empty we know > 48# that the fdlibm-fork in hotspot can get optimized > 49# by using -ffp-contract=off on GCC/Clang platforms. > ...... > 58 BUILD_LIBJVM_sharedRuntimeTrig.cpp_CXXFLAGS := -DNO_PCH > $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) > 59 BUILD_LIBJVM_sharedRuntimeTrans.cpp_CXXFLAGS := -DNO_PCH > $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) > 60 > > But still, setting both -O3 and -O2 in one compile call looks not > nice to me . > > In case of ancient gcc ***without*** -ffp-contract=off , we > might still run into issues for these 2 special files when > _FORTIFY_SOURCE is set . > Don't know if this is still relevant . > In case we want to be on the very safe side , we > might need to filter out -D_FORTIFY_SOURCE=2 for these 2 > compilation units . > > > Best regards, Matthias > > > > > Hi David, thanks for the comment . > > > > Currently I do not see the issue in our fastdebug builds . > > So I think the opt-flag filtering got changed/removed in the > > years after the > > issues were reported . > > > > > > https://bugs.openjdk.java.net/browse/JDK-8047952 > > > > mentions special O-level settings for sharedRuntimeTrig.cpp and > > sharedRuntimeTrans.cpp . > > > > But the files have optimization set in both fastdebug > > and opt builds : > > > > Linux x86_64 gcc-7 based builds : > > > > fastdebug build (with the added -D_FORTIFY_SOURCE=2 flag) : > > > > -Werror -O3 -D_FORTIFY_SOURCE=2 -DNO_PCH -ffp-contract=off -O2 - > > D_FORTIFY_SOURCE=2 > > > > > > Opt build (without -D_FORTIFY_SOURCE=... ) : > > > > -O3 -DNO_PCH -ffp-contract=off -O2 .... > > > > > > (btw. the setting of both -O3 AND -O2 looks strange to me , > > but that?s > > unrelated to my change ; I noticed that already in OpenJDK 11 ). > > > > > > Best regards, Matthias > > > > > > > > > > > Hi Matthias, > > > > > > On 8/05/2019 6:05 pm, Baesken, Matthias wrote: > > > > Hello, here is a webrev, I used the existing bug > > > > "JDK-8130017 : use _FORTIFY_SOURCE in gcc fastdebug builds" > > > > > > > > Hope that?s fine . > > > > > > That is fine, but please add a comment to the bug explaining > > > exactly how > > > you fixed the issue and how the issues raised in the bug > > > description > > > regarding optimisation levels have been addressed. > > > > > > Not a review - I'll leave that to build team. The proof of this > > > will be > > > in the building and testing. > > > > > > Thanks, > > > David > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8130017 > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.0/ > > > > > > > > > > > > Our internal OpenJDK Linux (x86_64, ppc64, ppc64le , > > > > s390x) fastdebug > > > builds are fine with the added flag . > > > > From jcbeyler at google.com Wed May 8 23:06:13 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 8 May 2019 16:06:13 -0700 Subject: RFR (L) 8220747: Migrate data structures to being more C++ In-Reply-To: <4927d1b1-49ad-9be7-d2ca-483e521f7b18@oracle.com> References: <4927d1b1-49ad-9be7-d2ca-483e521f7b18@oracle.com> Message-ID: Hi David, Thanks for the quick look :) I moved the code around to really only have the minimal part in the extern C part. It seems that the link you are providing seems to show that what we did is the right thing then so that seems like it's a good start I guess! Here is an updated webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8220747/webrev.03/ I left the structs in structs so I did not have to append the fields with '_', which otherwise made the code review feel (to me) messy. Thanks again for your help, Jc On Wed, May 1, 2019 at 10:22 PM David Holmes wrote: > Hi Jc, > > I just a had a quick look at this so not a full review - sorry. > > I'm not sure it makes sense to define classes within "extern C {". The > extern C is intended to define an interface for this C++ library to be > used from a C program - as discussed here for your Solaris issue: > > https://docs.oracle.com/cd/E18659_01/html/821-1383/bkamu.html > > Cheers, > David > > On 2/05/2019 1:08 pm, Jean Christophe Beyler wrote: > > Hi all, > > > > Re-sending with the full title.... > > > > (OK... so JC will promise to go around the block 3 times before > submitting > > a review request; and will do any item you would like to redeem myself; I > > apologize profusely and feel horrible...) > > > > I want to move the libHeapMonitorTest.c to C++ and here is the first > "step" > > towards that. There are two parts to this: move the file to C++ and move > > some of the C-style to C++-style code. > > > > But this webrev failed on solaris; Igor helped me figure it out and his > > solution was to add the change to the JtregNativeHotspot.gmk for > solstudio. > > We are not sure this is the "right" solution to this and hence have added > > both the serviceability and build lists to review both file changes and > > figure out what is best :) > > > > This does pass the submit-repo testing and the tests on my local dev > > machine. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220747 > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8220747/webrev.02/ > > > > Thanks all for your help, > > Jc > > > -- Thanks, Jc From matthias.baesken at sap.com Thu May 9 12:36:01 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 May 2019 12:36:01 +0000 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> References: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> Message-ID: Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++ command line call works , setting together -D_FORTIFY_SOURCE=2 and -D_FORTIFY_SOURCE=0 in one command line call generates a warning , so I think we cannot do that . Best regards, Matthias > Hello Matthias, > > On 2019-05-08 06:27, Baesken, Matthias wrote: > > Hello, I looked a bit more into it . > > It seems to me , that when -ffp-contract=off is available which is the > case with current gcc versions , we want to optimize the 2 special files ( > sharedRuntimeTrig.cpp / sharedRuntimeTrans.cpp ). > > see the following comments : > > > > jdk/make/hotspot/lib/JvmOverrideFiles.gmk > > > > 47# If the FDLIBM_CFLAGS variable is non-empty we know > > 48# that the fdlibm-fork in hotspot can get optimized > > 49# by using -ffp-contract=off on GCC/Clang platforms. > > ...... > > 58 BUILD_LIBJVM_sharedRuntimeTrig.cpp_CXXFLAGS := -DNO_PCH > $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) > > 59 BUILD_LIBJVM_sharedRuntimeTrans.cpp_CXXFLAGS := -DNO_PCH > $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) > > 60 > Will this not just resolve itself if you also add -D_FORTIFY_SOURCE=0 to > C_O_FLAG_NONE (and all the other optimization flag variables that have > the value "-O0")? > > But still, setting both -O3 and -O2 in one compile call looks not nice to me . > This may not look nice, but is how we have to do things. The last flag > on a compiler command line takes precedence. We rely on this to override > general flags with more specific ones (typically a general flag for the > whole library with specific ones for certain compilation units). This > technique is quite common. > > > > In case of ancient gcc ***without*** -ffp-contract=off , we might still > run into issues for these 2 special files when _FORTIFY_SOURCE is set . > > Don't know if this is still relevant . > > In case we want to be on the very safe side , we might need to filter out > -D_FORTIFY_SOURCE=2 for these 2 compilation units . > > We don't want to filter out flags. It creates very brittle code that is > likely to break in the future. > > For the patch, I think it would make sense to introduce a variable for > the value -D_FORTIFY_SOURCE=2 (and > -D_FORTIFY_SOURCE=0/-U_FORTIFY_SOURCE) to avoid repeating it. > > /Erik From sgehwolf at redhat.com Thu May 9 12:39:18 2019 From: sgehwolf at redhat.com (sgehwolf at redhat.com) Date: Thu, 09 May 2019 14:39:18 +0200 Subject: [PING] [8u] RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: References: Message-ID: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> Ping? On Fri, 2019-05-03 at 18:35 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this 8u backport of an optimization fix > pertaining to the hotspot copy of fdlibm? Historically, > sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have been compiled > with optimization turned off on x86/x86_64. As JDK-8210416 will be > backported to JDK 8u fixing optimization for fdlibm itself, so should > be the hotspot copy in OpenJDK 8u. The build system for hotspot in JDK > 8u is very different, so the original fix for JDK 12 doesn't apply. > It's a complete rewrite. Please see this webrev which shows the > prerequisite patch. It adds the FDLIBM_CFLAGS logic: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ > > It also fixes a bug on ppc64{,le} where optimization is being turned on > in hotspot (-O3), but not providing the -ffp-contract=off flag (or > older equivalent). > > Before (on ppc64le): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > After (on ppc64le; Note -ffp-contract=off flag): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -ffp-contract=off -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/jdk8/02/webrev > > Testing: Builds on x86_64 (server/Zero). Manual inspection of compile > log of sharedRuntimeTrans.cpp/sharedRuntimeTrig.cpp. Same for ppc64le. > Note that we've been using this patch downstream for a while now. We > haven't seen any issues so far. > > Thanks, > Severin From erik.joelsson at oracle.com Thu May 9 13:17:35 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 9 May 2019 06:17:35 -0700 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> Message-ID: Hello, I just tried this and you are correct. However, it does seem to work if you instead use -U_FORTIFY_SOURCE. /Erik On 2019-05-09 05:36, Baesken, Matthias wrote: > Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++ command line call works , > setting together -D_FORTIFY_SOURCE=2 and -D_FORTIFY_SOURCE=0 in one command line call generates a warning , so I think we cannot do that . > > > Best regards, Matthias > > >> Hello Matthias, >> >> On 2019-05-08 06:27, Baesken, Matthias wrote: >>> Hello, I looked a bit more into it . >>> It seems to me , that when -ffp-contract=off is available which is the >> case with current gcc versions , we want to optimize the 2 special files ( >> sharedRuntimeTrig.cpp / sharedRuntimeTrans.cpp ). >>> see the following comments : >>> >>> jdk/make/hotspot/lib/JvmOverrideFiles.gmk >>> >>> 47# If the FDLIBM_CFLAGS variable is non-empty we know >>> 48# that the fdlibm-fork in hotspot can get optimized >>> 49# by using -ffp-contract=off on GCC/Clang platforms. >>> ...... >>> 58 BUILD_LIBJVM_sharedRuntimeTrig.cpp_CXXFLAGS := -DNO_PCH >> $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) >>> 59 BUILD_LIBJVM_sharedRuntimeTrans.cpp_CXXFLAGS := -DNO_PCH >> $(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG) >>> 60 >> Will this not just resolve itself if you also add -D_FORTIFY_SOURCE=0 to >> C_O_FLAG_NONE (and all the other optimization flag variables that have >> the value "-O0")? >>> But still, setting both -O3 and -O2 in one compile call looks not nice to me . >> This may not look nice, but is how we have to do things. The last flag >> on a compiler command line takes precedence. We rely on this to override >> general flags with more specific ones (typically a general flag for the >> whole library with specific ones for certain compilation units). This >> technique is quite common. >>> In case of ancient gcc ***without*** -ffp-contract=off , we might still >> run into issues for these 2 special files when _FORTIFY_SOURCE is set . >>> Don't know if this is still relevant . >>> In case we want to be on the very safe side , we might need to filter out >> -D_FORTIFY_SOURCE=2 for these 2 compilation units . >> >> We don't want to filter out flags. It creates very brittle code that is >> likely to break in the future. >> >> For the patch, I think it would make sense to introduce a variable for >> the value -D_FORTIFY_SOURCE=2 (and >> -D_FORTIFY_SOURCE=0/-U_FORTIFY_SOURCE) to avoid repeating it. >> >> /Erik From erik.joelsson at oracle.com Thu May 9 13:44:05 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 9 May 2019 06:44:05 -0700 Subject: RFR: JDK-8223627: jdk-13+20 bundle name contains null instead of ea Message-ID: <5a141bea-f826-f2bb-44a3-2091709846e6@oracle.com> In JDK-8223464 I managed to introduce a bug. The reference to the new property for the PRE string is misspelled in one location. Bug: https://bugs.openjdk.java.net/browse/JDK-8223627 Webrev: http://cr.openjdk.java.net/~erikj/8223627/webrev.01/ /Erik From david.holmes at oracle.com Thu May 9 14:02:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 00:02:16 +1000 Subject: RFR: JDK-8223627: jdk-13+20 bundle name contains null instead of ea In-Reply-To: <5a141bea-f826-f2bb-44a3-2091709846e6@oracle.com> References: <5a141bea-f826-f2bb-44a3-2091709846e6@oracle.com> Message-ID: Looks good. David ----- On 9/05/2019 11:44 pm, Erik Joelsson wrote: > In JDK-8223464 I managed to introduce a bug. The reference to the new > property for the PRE string is misspelled in one location. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223627 > > Webrev: http://cr.openjdk.java.net/~erikj/8223627/webrev.01/ > > /Erik > From martin.doerr at sap.com Thu May 9 14:04:12 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 9 May 2019 14:04:12 +0000 Subject: FW: RFR: 8223307: enable the Stack Execution Disable flag for JDK binaries on AIX - was : AIX : -bnorwexec linker flag In-Reply-To: References: Message-ID: Hi Matthias, the change looks good to me. According to an old redbook [1], this flag makes stacks and r/w sections of the lib non-executable. This makes sense. Best regards, Martin [1] AIX 5L Differences Guide Version 5.3 Edition -----Original Message----- From: Erik Joelsson > Sent: Freitag, 3. Mai 2019 15:32 To: Baesken, Matthias >; ppc-aix-port-dev at openjdk.java.net; 'build-dev at openjdk.java.net' > Subject: Re: RFR: 8223307: enable the Stack Execution Disable flag for JDK binaries on AIX - was : AIX : -bnorwexec linker flag Change looks good from a build perspective. I can't comment on the validity of the flag itself for a platform I don't know. /Erik On 2019-05-03 05:48, Baesken, Matthias wrote: > Hello, I created a webrev for the previously discussed issue (AIX : -bnorwexec linker flag). > > AIX supports a binary hardening option called SED, see : > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.security/stack_exec_disable.htm > > System wide configuration can be done with the sedmgr tool : > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.cmds5/sedmgr.htm > > > The system-wide configuration supports various modes, very often "select" mode is configured where > binaries can opt-in to use SED : > > "select: > Only a select set of files are enabled and monitored for SED protection. The select set of files are chosen by reviewing the SED related flags in the executable program binary headers. > The executable program header enables SED related flags to request to be included in the select mode." > > > We can set a linker option on AIX to configure "select" mode for the JDK binaries; our tests show that this does not "kill" the JIT (jitted code). > > changed binary shows then the opt-in flag ("request" ) : > > bash-4.4$ sedmgr -d /rs6000_64/nightly/output-jdk-test/images/jdk/bin/java > /rs6000_64/nightly/output-jdk-test/images/jdk/bin/java : request > > while the unchanged binary does not have the flag set ("system") : > > bash-4.4$ sedmgr -d /rs6000_64/nightly/output-jdk11-test/images/jdk/bin/java > /rs6000_64/nightly/output-jdk11-test/images/jdk/bin/java : system > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8223307 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223307.0/ > > > Thanks, Matthias > > > >> -----Original Message----- >> From: Erik Joelsson > >> Sent: Freitag, 12. April 2019 15:30 >> To: Baesken, Matthias >; ppc-aix-port- >> dev at openjdk.java.net; 'build-dev at openjdk.java.net' > dev at openjdk.java.net> >> Subject: Re: AIX : -bnorwexec linker flag >> >> From a build point of view, the patch looks good. I cannot comment on >> the validity of adding the flag though. >> >> /Erik >> >> On 2019-04-12 02:15, Baesken, Matthias wrote: >>> Hello, I have a question regarding the AIX -bnorwexec linker flag . >>> I think it is related to an AIX security feature SED , see also : >>> >>> >> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. >> aix.security/stack_exec_disable_flags.htm >>> When building with the additional -bnorwexec linker flag we signal the >> OS that we "request" the SED feature . >>> Please compare a patched and an unpatched java ( patched is flagged >> "request" while unpatched uses the "system" setting ). >>> bash-4.3$ sedmgr -d /patched_jdk/images/jdk/bin/java >>> /patched_jdk/images/images/jdk/bin/java : request >>> >>> >>> bash-4.3$ sedmgr -d /normal_jdk/images/jdk/bin/java >>> /normal_jdk/images/jdk/bin/java : system >>> >>> >>> System config on the example machine is "normal" (default) select : >>> bash-4.3$ sedmgr >>> Stack Execution Disable (SED) mode: select >>> SED configured in kernel: select >>> >>> >>> In our internal tests I noticed so far no issues when setting the - >> bnorwexec linker flag in OpenJDK on AIX . >>> Do you have any experience with it, do you see issues when setting the >> flag ? >>> >>> The documentation of the flag is a bit short . >>> >>> >>> >> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. >> aix.cmds3/ld.htm >>> >>> norwexec >>> >>> Specifies that if the system's sed_config setting is not off, the process' >> private data areas will have non-execute permission. >>> >>> >>> >>> Patch would be : >>> >>> diff -r 0d7fb7f07134 make/autoconf/flags-ldflags.m4 >>> --- a/make/autoconf/flags-ldflags.m4 Mon Apr 08 06:56:37 2019 +0100 >>> +++ b/make/autoconf/flags-ldflags.m4 Mon Apr 08 10:50:07 2019 +0200 >>> @@ -1,5 +1,5 @@ >>> # >>> -# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. >>> +# Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. >>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> # >>> # This code is free software; you can redistribute it and/or modify it >>> @@ -88,7 +88,7 @@ >>> BASIC_LDFLAGS_JVM_ONLY="-library=%none -mt -z noversion" >>> elif test "x$TOOLCHAIN_TYPE" = xxlc; then >>> - BASIC_LDFLAGS="-b64 -brtl -bnolibpath -bexpall -bernotok - >> btextpsize:64K \ >>> + BASIC_LDFLAGS="-b64 -brtl -bnorwexec -bnolibpath -bexpall -bernotok >> -btextpsize:64K \ >>> -bdatapsize:64K -bstackpsize:64K" >>> # libjvm.so has gotten too large for normal TOC size; compile with >> qpic=large and link with bigtoc >>> BASIC_LDFLAGS_JVM_ONLY="-Wl,-lC_r -bbigtoc" >>> >>> >>> Best regards, Matthias >>> From matthias.baesken at sap.com Thu May 9 14:14:03 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 May 2019 14:14:03 +0000 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> Message-ID: Hello, I tried setting "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0" And this seems indeed to work , no warning any more . Let's hope gcc does not change the command line parsing . Btw. is there a gcc version that a) still compiles jdk/jdk and b) would show the issue ? (with our internally used gcc's we are always > 4.6 in jdk/jdk ) Best regards, Matthias > -----Original Message----- > From: Erik Joelsson > Sent: Donnerstag, 9. Mai 2019 15:18 > To: Baesken, Matthias ; David Holmes > ; 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - > was : RE: gcc FORTIFY_SOURCE application security flags > > Hello, > > I just tried this and you are correct. However, it does seem to work if > you instead use -U_FORTIFY_SOURCE. > > /Erik > > On 2019-05-09 05:36, Baesken, Matthias wrote: > > Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++ > command line call works , > > setting together -D_FORTIFY_SOURCE=2 and -D_FORTIFY_SOURCE=0 > in one command line call generates a warning , so I think we cannot do that . > > > > > > Best regards, Matthias > > From matthias.baesken at sap.com Thu May 9 14:14:57 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 May 2019 14:14:57 +0000 Subject: FW: RFR: 8223307: enable the Stack Execution Disable flag for JDK binaries on AIX - was : AIX : -bnorwexec linker flag In-Reply-To: References: Message-ID: Thanks ! Great you found more info in the good old redbook. Best regards , Matthias From: Doerr, Martin Sent: Donnerstag, 9. Mai 2019 16:04 To: Baesken, Matthias ; ppc-aix-port-dev at openjdk.java.net; build-dev at openjdk.java.net Cc: Steve Groeger Subject: RE: FW: RFR: 8223307: enable the Stack Execution Disable flag for JDK binaries on AIX - was : AIX : -bnorwexec linker flag Hi Matthias, the change looks good to me. According to an old redbook [1], this flag makes stacks and r/w sections of the lib non-executable. This makes sense. Best regards, Martin [1] AIX 5L Differences Guide Version 5.3 Edition -----Original Message----- From: Erik Joelsson > Sent: Freitag, 3. Mai 2019 15:32 To: Baesken, Matthias >; ppc-aix-port-dev at openjdk.java.net; 'build-dev at openjdk.java.net' > Subject: Re: RFR: 8223307: enable the Stack Execution Disable flag for JDK binaries on AIX - was : AIX : -bnorwexec linker flag Change looks good from a build perspective. I can't comment on the validity of the flag itself for a platform I don't know. /Erik On 2019-05-03 05:48, Baesken, Matthias wrote: > Hello, I created a webrev for the previously discussed issue (AIX : -bnorwexec linker flag). > > AIX supports a binary hardening option called SED, see : > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.security/stack_exec_disable.htm > > System wide configuration can be done with the sedmgr tool : > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.cmds5/sedmgr.htm > > > The system-wide configuration supports various modes, very often "select" mode is configured where > binaries can opt-in to use SED : > > "select: > Only a select set of files are enabled and monitored for SED protection. The select set of files are chosen by reviewing the SED related flags in the executable program binary headers. > The executable program header enables SED related flags to request to be included in the select mode." > > > We can set a linker option on AIX to configure "select" mode for the JDK binaries; our tests show that this does not "kill" the JIT (jitted code). > > changed binary shows then the opt-in flag ("request" ) : > > bash-4.4$ sedmgr -d /rs6000_64/nightly/output-jdk-test/images/jdk/bin/java > /rs6000_64/nightly/output-jdk-test/images/jdk/bin/java : request > > while the unchanged binary does not have the flag set ("system") : > > bash-4.4$ sedmgr -d /rs6000_64/nightly/output-jdk11-test/images/jdk/bin/java > /rs6000_64/nightly/output-jdk11-test/images/jdk/bin/java : system > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8223307 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223307.0/ > > > Thanks, Matthias > > > >> -----Original Message----- >> From: Erik Joelsson > >> Sent: Freitag, 12. April 2019 15:30 >> To: Baesken, Matthias >; ppc-aix-port- >> dev at openjdk.java.net; 'build-dev at openjdk.java.net' > dev at openjdk.java.net> >> Subject: Re: AIX : -bnorwexec linker flag >> >> From a build point of view, the patch looks good. I cannot comment on >> the validity of adding the flag though. >> >> /Erik >> >> On 2019-04-12 02:15, Baesken, Matthias wrote: >>> Hello, I have a question regarding the AIX -bnorwexec linker flag . >>> I think it is related to an AIX security feature SED , see also : >>> >>> >> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. >> aix.security/stack_exec_disable_flags.htm >>> When building with the additional -bnorwexec linker flag we signal the >> OS that we "request" the SED feature . >>> Please compare a patched and an unpatched java ( patched is flagged >> "request" while unpatched uses the "system" setting ). >>> bash-4.3$ sedmgr -d /patched_jdk/images/jdk/bin/java >>> /patched_jdk/images/images/jdk/bin/java : request >>> >>> >>> bash-4.3$ sedmgr -d /normal_jdk/images/jdk/bin/java >>> /normal_jdk/images/jdk/bin/java : system >>> >>> >>> System config on the example machine is "normal" (default) select : >>> bash-4.3$ sedmgr >>> Stack Execution Disable (SED) mode: select >>> SED configured in kernel: select >>> >>> >>> In our internal tests I noticed so far no issues when setting the - >> bnorwexec linker flag in OpenJDK on AIX . >>> Do you have any experience with it, do you see issues when setting the >> flag ? >>> >>> The documentation of the flag is a bit short . >>> >>> >>> >> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. >> aix.cmds3/ld.htm >>> >>> norwexec >>> >>> Specifies that if the system's sed_config setting is not off, the process' >> private data areas will have non-execute permission. >>> >>> >>> >>> Patch would be : >>> >>> diff -r 0d7fb7f07134 make/autoconf/flags-ldflags.m4 >>> --- a/make/autoconf/flags-ldflags.m4 Mon Apr 08 06:56:37 2019 +0100 >>> +++ b/make/autoconf/flags-ldflags.m4 Mon Apr 08 10:50:07 2019 +0200 >>> @@ -1,5 +1,5 @@ >>> # >>> -# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. >>> +# Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. >>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> # >>> # This code is free software; you can redistribute it and/or modify it >>> @@ -88,7 +88,7 @@ >>> BASIC_LDFLAGS_JVM_ONLY="-library=%none -mt -z noversion" >>> elif test "x$TOOLCHAIN_TYPE" = xxlc; then >>> - BASIC_LDFLAGS="-b64 -brtl -bnolibpath -bexpall -bernotok - >> btextpsize:64K \ >>> + BASIC_LDFLAGS="-b64 -brtl -bnorwexec -bnolibpath -bexpall -bernotok >> -btextpsize:64K \ >>> -bdatapsize:64K -bstackpsize:64K" >>> # libjvm.so has gotten too large for normal TOC size; compile with >> qpic=large and link with bigtoc >>> BASIC_LDFLAGS_JVM_ONLY="-Wl,-lC_r -bbigtoc" >>> >>> >>> Best regards, Matthias >>> From erik.joelsson at oracle.com Thu May 9 14:31:05 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 9 May 2019 07:31:05 -0700 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> Message-ID: <697940ec-9a17-cd4e-d895-2dd18c1a91b1@oracle.com> Configure will protest if GCC version is less than 4.8 (see toolchain.m4 *_MINIMUM_VERSION variables). That said, as long as we conditionally set the FDLIBM_CFLAGS like this, I would say we need to continue honoring the result of that check. You could also remove the check altogether since it seems to no longer be needed. /Erik On 2019-05-09 07:14, Baesken, Matthias wrote: > Hello, > I tried setting > > "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0" > > And this seems indeed to work , no warning any more . > > Let's hope gcc does not change the command line parsing . > > Btw. is there a gcc version that a) still compiles jdk/jdk and b) would show the issue ? > > (with our internally used gcc's we are always > 4.6 in jdk/jdk ) > > Best regards, Matthias > > >> -----Original Message----- >> From: Erik Joelsson >> Sent: Donnerstag, 9. Mai 2019 15:18 >> To: Baesken, Matthias ; David Holmes >> ; 'build-dev at openjdk.java.net' > dev at openjdk.java.net> >> Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - >> was : RE: gcc FORTIFY_SOURCE application security flags >> >> Hello, >> >> I just tried this and you are correct. However, it does seem to work if >> you instead use -U_FORTIFY_SOURCE. >> >> /Erik >> >> On 2019-05-09 05:36, Baesken, Matthias wrote: >>> Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++ >> command line call works , >>> setting together -D_FORTIFY_SOURCE=2 and -D_FORTIFY_SOURCE=0 >> in one command line call generates a warning , so I think we cannot do that . >>> >>> Best regards, Matthias >>> From tim.bell at oracle.com Thu May 9 14:32:25 2019 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 09 May 2019 07:32:25 -0700 Subject: RFR: JDK-8223627: jdk-13+20 bundle name contains null instead of ea In-Reply-To: References: <5a141bea-f826-f2bb-44a3-2091709846e6@oracle.com> Message-ID: <5CD439F9.7020603@oracle.com> Erik: Looks good to me as well. Tim On 05/09/19 07:02, David Holmes wrote: > Looks good. > > David > ----- > > On 9/05/2019 11:44 pm, Erik Joelsson wrote: >> In JDK-8223464 I managed to introduce a bug. The reference to the new >> property for the PRE string is misspelled in one location. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223627 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8223627/webrev.01/ >> >> /Erik From aeubanks at google.com Fri May 10 01:14:25 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 9 May 2019 18:14:25 -0700 Subject: [RFR]: 8223667: ASAN build broken Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8223667 Webrev: http://cr.openjdk.java.net/~aeubanks/8223667/webrev.00/index.html The ASAN build, enabled with --enable-asan, is broken. At some point during the build, the following message appears: ERROR: Invalid value for bool option: '0"' ERROR: Flag parsing failed. This is in ASAN's flag parsing code, caused by the ASAN_OPTIONS environment variable having an extra quote at the end. Instead of using quotes in spec.gmk, use $(SPACE). From matthias.baesken at sap.com Fri May 10 05:46:37 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 10 May 2019 05:46:37 +0000 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: <697940ec-9a17-cd4e-d895-2dd18c1a91b1@oracle.com> References: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> <697940ec-9a17-cd4e-d895-2dd18c1a91b1@oracle.com> Message-ID: Hello, here is the new webrev with the "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0" Set for the lower level optimization flags : http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.1/ I would suggest to leave the pre-gcc4.8 cleanup to a separate change. Best regards, Matthias > > Configure will protest if GCC version is less than 4.8 (see toolchain.m4 > *_MINIMUM_VERSION variables). > > That said, as long as we conditionally set the FDLIBM_CFLAGS like this, > I would say we need to continue honoring the result of that check. You > could also remove the check altogether since it seems to no longer be > needed. > > /Erik > > On 2019-05-09 07:14, Baesken, Matthias wrote: > > Hello, > > I tried setting > > > > "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0" > > > > And this seems indeed to work , no warning any more . > > > > Let's hope gcc does not change the command line parsing . > > > > Btw. is there a gcc version that a) still compiles jdk/jdk and b) would > show the issue ? > > > > (with our internally used gcc's we are always > 4.6 in jdk/jdk ) > > > > Best regards, Matthias > > > > > >> -----Original Message----- > >> From: Erik Joelsson > >> Sent: Donnerstag, 9. Mai 2019 15:18 > >> To: Baesken, Matthias ; David Holmes > >> ; 'build-dev at openjdk.java.net' >> dev at openjdk.java.net> > >> Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - > >> was : RE: gcc FORTIFY_SOURCE application security flags > >> > >> Hello, > >> > >> I just tried this and you are correct. However, it does seem to work if > >> you instead use -U_FORTIFY_SOURCE. > >> > >> /Erik > >> > >> On 2019-05-09 05:36, Baesken, Matthias wrote: > >>> Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++ > >> command line call works , > >>> setting together -D_FORTIFY_SOURCE=2 and - > D_FORTIFY_SOURCE=0 > >> in one command line call generates a warning , so I think we cannot do > that . > >>> > >>> Best regards, Matthias > >>> From matthias.baesken at sap.com Fri May 10 10:23:20 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 10 May 2019 10:23:20 +0000 Subject: RFR [XS] : 8223685: used bundled zlib on AIX by default Message-ID: Hello, please review this small AIX - specific change . Currently we use by default the bundled zlib (= zlib coming with OpenJDK) on Windows, on other platforms the system zlib. However it is possible to switch to the bundled zlib in the configure process . We had some build issues on AIX build systems with ancient system-zlibs , so I propose to use as default the bundled zlib on AIX too . (would also mean that we use a current 1.2.11 in the build on AIX which is not bad, on some AIX machines I've seen older zlibs) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8223685 http://cr.openjdk.java.net/~mbaesken/webrevs/8223685.0/webrev/ Thanks, Matthias From matthias.baesken at sap.com Fri May 10 12:56:14 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 10 May 2019 12:56:14 +0000 Subject: Windows/Visual Studio control flow guard Message-ID: Hello, I wonder if some people already have looked into using Windows "control flow guard" in OpenJDK, and can share the info they got. See : https://docs.microsoft.com/en-us/windows/desktop/SecBP/control-flow-guard "Control Flow Guard (CFG) is a highly-optimized platform security feature that was created to combat memory corruption vulnerabilities. By placing tight restrictions on where an application can execute code from, it makes it much harder for exploits to execute arbitrary code through vulnerabilities such as buffer overflows. CFG extends previous exploit mitigation technologies such as /GS, DEP, and ASLR." So it is basically a compiler+linker flag available in VS2015 and higher . We set it for a while in our internal OpenJDK night builds , no issues seen so far . (However I think more performance testing needs to be done ) Patch I used (might need an additional check for VS2015+ version) : diff -r 23a04fe2aca2 make/autoconf/flags-cflags.m4 --- a/make/autoconf/flags-cflags.m4 Fri Apr 05 09:53:07 2019 -0400 +++ b/make/autoconf/flags-cflags.m4 Tue Apr 09 15:57:21 2019 +0200 @@ -501,9 +501,10 @@ ALWAYS_DEFINES_JVM="-D_REENTRANT" ALWAYS_DEFINES_JDK="-D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DSTDC" elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then + # enable Windows Control Flow Guard; this might need VS2015+ ALWAYS_DEFINES_JDK="-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE \ - -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL" - ALWAYS_DEFINES_JVM="-DNOMINMAX -DWIN32_LEAN_AND_MEAN" + -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -guard:cf" + ALWAYS_DEFINES_JVM="-DNOMINMAX -DWIN32_LEAN_AND_MEAN -guard:cf" fi ############################################################################### diff -r 23a04fe2aca2 make/autoconf/flags-ldflags.m4 --- a/make/autoconf/flags-ldflags.m4 Fri Apr 05 09:53:07 2019 -0400 +++ b/make/autoconf/flags-ldflags.m4 Tue Apr 09 15:57:21 2019 +0200 @@ -94,7 +94,8 @@ BASIC_LDFLAGS_JVM_ONLY="-Wl,-lC_r -bbigtoc" elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then - BASIC_LDFLAGS="-nologo -opt:ref" + # enable Windows Control Flow Guard; this might need VS2015+ + BASIC_LDFLAGS="-nologo -opt:ref -guard:cf" BASIC_LDFLAGS_JDK_ONLY="-incremental:no" BASIC_LDFLAGS_JVM_ONLY="-opt:icf,8 -subsystem:windows" fi Thanks, Matthias From erik.joelsson at oracle.com Fri May 10 14:24:06 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 10 May 2019 07:24:06 -0700 Subject: [RFR]: 8223667: ASAN build broken In-Reply-To: References: Message-ID: <99e3554a-7ca9-c957-e93d-0a18947e93ff@oracle.com> Hello Arthur, Do you really need to use $(SPACE)? I would expect it to work with just removing the quotes. /Erik On 2019-05-09 18:14, Arthur Eubanks wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8223667 > Webrev: http://cr.openjdk.java.net/~aeubanks/8223667/webrev.00/index.html > > The ASAN build, enabled with --enable-asan, is broken. At some point during > the build, the following message appears: > > ERROR: Invalid value for bool option: '0"' > ERROR: Flag parsing failed. > > This is in ASAN's flag parsing code, caused by the ASAN_OPTIONS environment > variable having an extra quote at the end. > > Instead of using quotes in spec.gmk, use $(SPACE). From erik.joelsson at oracle.com Fri May 10 14:28:57 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 10 May 2019 07:28:57 -0700 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> <697940ec-9a17-cd4e-d895-2dd18c1a91b1@oracle.com> Message-ID: <66603421-a81d-748e-780a-25f5358bbc0f@oracle.com> Hello Matthias, I think just -U_FORTIFY_SOURCE should be enough to unset it, no need to also set it to 0. Also, I think it would be good to use an extra set of variables to avoid repeating the flag, like this: ENABLE_FORTIFY_CFLAGS="-D_FORTIFY_SOURCE=2" DISABLE_FORTIFY_CFLAGS="-U_FORTIFY_SOURCE" C_O_FLAG_HIGHEST_JVM="${C_O_FLAG_HIGHEST_JVM} ${ENABLE_FORTIFY_CFLAGS}" ... /Erik On 2019-05-09 22:46, Baesken, Matthias wrote: > Hello, here is the new webrev with the > > "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0" > > Set for the lower level optimization flags : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.1/ > > > I would suggest to leave the pre-gcc4.8 cleanup to a separate change. > > Best regards, Matthias > > > >> Configure will protest if GCC version is less than 4.8 (see toolchain.m4 >> *_MINIMUM_VERSION variables). >> >> That said, as long as we conditionally set the FDLIBM_CFLAGS like this, >> I would say we need to continue honoring the result of that check. You >> could also remove the check altogether since it seems to no longer be >> needed. >> >> /Erik >> >> On 2019-05-09 07:14, Baesken, Matthias wrote: >>> Hello, >>> I tried setting >>> >>> "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0" >>> >>> And this seems indeed to work , no warning any more . >>> >>> Let's hope gcc does not change the command line parsing . >>> >>> Btw. is there a gcc version that a) still compiles jdk/jdk and b) would >> show the issue ? >>> (with our internally used gcc's we are always > 4.6 in jdk/jdk ) >>> >>> Best regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: Erik Joelsson >>>> Sent: Donnerstag, 9. Mai 2019 15:18 >>>> To: Baesken, Matthias ; David Holmes >>>> ; 'build-dev at openjdk.java.net' >>> dev at openjdk.java.net> >>>> Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - >>>> was : RE: gcc FORTIFY_SOURCE application security flags >>>> >>>> Hello, >>>> >>>> I just tried this and you are correct. However, it does seem to work if >>>> you instead use -U_FORTIFY_SOURCE. >>>> >>>> /Erik >>>> >>>> On 2019-05-09 05:36, Baesken, Matthias wrote: >>>>> Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++ >>>> command line call works , >>>>> setting together -D_FORTIFY_SOURCE=2 and - >> D_FORTIFY_SOURCE=0 >>>> in one command line call generates a warning , so I think we cannot do >> that . >>>>> Best regards, Matthias >>>>> From erik.joelsson at oracle.com Fri May 10 14:32:04 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 10 May 2019 07:32:04 -0700 Subject: RFR [XS] : 8223685: used bundled zlib on AIX by default In-Reply-To: References: Message-ID: Looks good. Bonus points if you could also replace the ellipsis (...) in the comment with a simple comma (,). /Erik On 2019-05-10 03:23, Baesken, Matthias wrote: > Hello, please review this small AIX - specific change . > > Currently we use by default the bundled zlib (= zlib coming with OpenJDK) on Windows, on other platforms the system zlib. > However it is possible to switch to the bundled zlib in the configure process . > > We had some build issues on AIX build systems with ancient system-zlibs , so I propose to use as default the bundled zlib on AIX too . > (would also mean that we use a current 1.2.11 in the build on AIX which is not bad, on some AIX machines I've seen older zlibs) > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8223685 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223685.0/webrev/ > > Thanks, Matthias From volker.simonis at gmail.com Fri May 10 14:47:17 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 10 May 2019 16:47:17 +0200 Subject: RFR [XS] : 8223685: used bundled zlib on AIX by default In-Reply-To: References: Message-ID: Looks good! Thanks, Volker On Fri, May 10, 2019 at 12:23 PM Baesken, Matthias wrote: > > Hello, please review this small AIX - specific change . > > Currently we use by default the bundled zlib (= zlib coming with OpenJDK) on Windows, on other platforms the system zlib. > However it is possible to switch to the bundled zlib in the configure process . > > We had some build issues on AIX build systems with ancient system-zlibs , so I propose to use as default the bundled zlib on AIX too . > (would also mean that we use a current 1.2.11 in the build on AIX which is not bad, on some AIX machines I've seen older zlibs) > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8223685 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223685.0/webrev/ > > Thanks, Matthias From aeubanks at google.com Fri May 10 16:02:29 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Fri, 10 May 2019 09:02:29 -0700 Subject: [RFR]: 8223667: ASAN build broken In-Reply-To: <99e3554a-7ca9-c957-e93d-0a18947e93ff@oracle.com> References: <99e3554a-7ca9-c957-e93d-0a18947e93ff@oracle.com> Message-ID: > Do you really need to use $(SPACE)? I would expect it to work with just > removing the quotes. You're right, no need for $(SPACE). Updated webrev: http://cr.openjdk.java.net/~aeubanks/8223667/webrev.01/index.html From erik.joelsson at oracle.com Fri May 10 16:10:57 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 10 May 2019 09:10:57 -0700 Subject: [RFR]: 8223667: ASAN build broken In-Reply-To: References: <99e3554a-7ca9-c957-e93d-0a18947e93ff@oracle.com> Message-ID: <03738862-6e52-6313-b837-eb374fe3ed27@oracle.com> Looks good. /Erik On 2019-05-10 09:02, Arthur Eubanks wrote: > > Do you really need to use $(SPACE)? I would expect it to work with > just > removing the quotes. > > You're right, no need for $(SPACE). > Updated webrev: > http://cr.openjdk.java.net/~aeubanks/8223667/webrev.01/index.html From manc at google.com Sat May 11 00:43:43 2019 From: manc at google.com (Man Cao) Date: Fri, 10 May 2019 17:43:43 -0700 Subject: [RFR]: 8223667: ASAN build broken In-Reply-To: <03738862-6e52-6313-b837-eb374fe3ed27@oracle.com> References: <99e3554a-7ca9-c957-e93d-0a18947e93ff@oracle.com> <03738862-6e52-6313-b837-eb374fe3ed27@oracle.com> Message-ID: Looks good. -Man *From: *Erik Joelsson *Date: *Fri, May 10, 2019 at 9:11 AM *To: *Arthur Eubanks *Cc: *build-dev Looks good. > > /Erik > > On 2019-05-10 09:02, Arthur Eubanks wrote: > > > > Do you really need to use $(SPACE)? I would expect it to work with > > just > > removing the quotes. > > > > You're right, no need for $(SPACE). > > Updated webrev: > > http://cr.openjdk.java.net/~aeubanks/8223667/webrev.01/index.html > From david.holmes at oracle.com Sat May 11 01:47:32 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 May 2019 11:47:32 +1000 Subject: [RFR]: 8223667: ASAN build broken In-Reply-To: References: <99e3554a-7ca9-c957-e93d-0a18947e93ff@oracle.com> <03738862-6e52-6313-b837-eb374fe3ed27@oracle.com> Message-ID: <034761a5-1e27-f93a-7135-7a70a6ff5277@oracle.com> Does this fix really work? If you do this in a shell then you lose the second option: > export ASAN_OPTIONS=handle_segv=0 detect_leaks=0 > echo $ASAN_OPTIONS handle_segv=0 ?? David On 11/05/2019 10:43 am, Man Cao wrote: > Looks good. > > -Man > > > *From: *Erik Joelsson > *Date: *Fri, May 10, 2019 at 9:11 AM > *To: *Arthur Eubanks > *Cc: *build-dev > > Looks good. >> >> /Erik >> >> On 2019-05-10 09:02, Arthur Eubanks wrote: >>> >>> Do you really need to use $(SPACE)? I would expect it to work with >>> just >>> removing the quotes. >>> >>> You're right, no need for $(SPACE). >>> Updated webrev: >>> http://cr.openjdk.java.net/~aeubanks/8223667/webrev.01/index.html >> From erik.joelsson at oracle.com Mon May 13 15:15:19 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 13 May 2019 08:15:19 -0700 Subject: [RFR]: 8223667: ASAN build broken In-Reply-To: <034761a5-1e27-f93a-7135-7a70a6ff5277@oracle.com> References: <99e3554a-7ca9-c957-e93d-0a18947e93ff@oracle.com> <03738862-6e52-6313-b837-eb374fe3ed27@oracle.com> <034761a5-1e27-f93a-7135-7a70a6ff5277@oracle.com> Message-ID: On 2019-05-10 18:47, David Holmes wrote: > Does this fix really work? If you do this in a shell then you lose the > second option: > > > export ASAN_OPTIONS=handle_segv=0 detect_leaks=0 > > echo $ASAN_OPTIONS > handle_segv=0 > This is a makefile and not shell. The "export" keyword, while looking like shell, is still just a makefile keyword here so makefile syntax applies to the variable assignment. This reminds me that we would prefer := instead of = here. /Erik > ?? > > David > > On 11/05/2019 10:43 am, Man Cao wrote: >> Looks good. >> >> -Man >> >> >> *From: *Erik Joelsson >> *Date: *Fri, May 10, 2019 at 9:11 AM >> *To: *Arthur Eubanks >> *Cc: *build-dev >> >> Looks good. >>> >>> /Erik >>> >>> On 2019-05-10 09:02, Arthur Eubanks wrote: >>>> >>>> ???? Do you really need to use $(SPACE)? I would expect it to work >>>> with >>>> ???? just >>>> ???? removing the quotes. >>>> >>>> You're right, no need for $(SPACE). >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~aeubanks/8223667/webrev.01/index.html >>> From goetz.lindenmaier at sap.com Mon May 13 16:38:28 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 May 2019 16:38:28 +0000 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> References: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> Message-ID: Hi Martin, Thanks for explaining the issue to me, that sounds reasonable. Can I somehow verify that it's the font that has the problem? Can I fix the font so that the test passes? Best regards, Goetz. > -----Original Message----- > From: Martin Balao > Sent: Montag, 13. Mai 2019 18:27 > To: Lindenmaier, Goetz ; 'Severin Gehwolf' > ; Langer, Christoph ; jdk- > updates-dev at openjdk.java.net > Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; Martin > Balao Alonso > Subject: Re: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure > (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) > > Hi Goetz, > > Thanks for raising this issue. > > I'm not surprised by MaxAdvanceIsMax test failing on some OS. The reason > is that this test is very OS specific. > > All installed fonts are tested and a static value from each font is used > for the assertion, after scale calculations. If there is a difference > between what the font creator set when generating the font file and what > the OS rendering library returns -considering that different FreeType > library builds may return different values-, this test will fail. > > The internal test during development phase was more reliable because it > tested a known-font only. However, shipping a font is not allowed by > licenses and that's why we changed the test a bit. > > We should probably limit the scope somehow. > > Despite the test failure, I'm still confident that we did the right > thing in 8218854 [1]. > > Kind regards, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8218854 From matthias.baesken at sap.com Tue May 14 10:16:24 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 14 May 2019 10:16:24 +0000 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: <66603421-a81d-748e-780a-25f5358bbc0f@oracle.com> References: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> <697940ec-9a17-cd4e-d895-2dd18c1a91b1@oracle.com> <66603421-a81d-748e-780a-25f5358bbc0f@oracle.com> Message-ID: Hi Erik, here is the updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.2/ Best regards, Matthias > -----Original Message----- > From: Erik Joelsson > Sent: Freitag, 10. Mai 2019 16:29 > To: Baesken, Matthias ; David Holmes > ; 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - > was : RE: gcc FORTIFY_SOURCE application security flags > > Hello Matthias, > > I think just -U_FORTIFY_SOURCE should be enough to unset it, no need to > also set it to 0. Also, I think it would be good to use an extra set of > variables to avoid repeating the flag, like this: > > ENABLE_FORTIFY_CFLAGS="-D_FORTIFY_SOURCE=2" > DISABLE_FORTIFY_CFLAGS="-U_FORTIFY_SOURCE" > C_O_FLAG_HIGHEST_JVM="${C_O_FLAG_HIGHEST_JVM} > ${ENABLE_FORTIFY_CFLAGS}" > ... > > /Erik > > On 2019-05-09 22:46, Baesken, Matthias wrote: > > Hello, here is the new webrev with the > > > > "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0" > > > > Set for the lower level optimization flags : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.1/ > > > > > > I would suggest to leave the pre-gcc4.8 cleanup to a separate change. > > > > Best regards, Matthias > > > > > > > >> Configure will protest if GCC version is less than 4.8 (see toolchain.m4 > >> *_MINIMUM_VERSION variables). > >> > >> That said, as long as we conditionally set the FDLIBM_CFLAGS like this, > >> I would say we need to continue honoring the result of that check. You > >> could also remove the check altogether since it seems to no longer be > >> needed. > >> > >> /Erik > >> > >> On 2019-05-09 07:14, Baesken, Matthias wrote: > >>> Hello, > >>> I tried setting > >>> > >>> "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0" > >>> > >>> And this seems indeed to work , no warning any more . > >>> > >>> Let's hope gcc does not change the command line parsing . > >>> > >>> Btw. is there a gcc version that a) still compiles jdk/jdk and b) would > >> show the issue ? > >>> (with our internally used gcc's we are always > 4.6 in jdk/jdk ) > >>> > >>> Best regards, Matthias > >>> > >>> > >>>> -----Original Message----- > >>>> From: Erik Joelsson > >>>> Sent: Donnerstag, 9. Mai 2019 15:18 > >>>> To: Baesken, Matthias ; David Holmes > >>>> ; 'build-dev at openjdk.java.net' >>>> dev at openjdk.java.net> > >>>> Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug > builds - > >>>> was : RE: gcc FORTIFY_SOURCE application security flags > >>>> > >>>> Hello, > >>>> > >>>> I just tried this and you are correct. However, it does seem to work if > >>>> you instead use -U_FORTIFY_SOURCE. > >>>> > >>>> /Erik > >>>> > >>>> On 2019-05-09 05:36, Baesken, Matthias wrote: > >>>>> Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++ > >>>> command line call works , > >>>>> setting together -D_FORTIFY_SOURCE=2 and - > >> D_FORTIFY_SOURCE=0 > >>>> in one command line call generates a warning , so I think we cannot do > >> that . > >>>>> Best regards, Matthias > >>>>> From erik.joelsson at oracle.com Tue May 14 13:23:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 May 2019 06:23:09 -0700 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: References: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> <697940ec-9a17-cd4e-d895-2dd18c1a91b1@oracle.com> <66603421-a81d-748e-780a-25f5358bbc0f@oracle.com> Message-ID: <9d3ac2b8-b07f-1405-917e-88e6254965ad@oracle.com> Looks good, thanks! /Erik On 2019-05-14 03:16, Baesken, Matthias wrote: > Hi Erik, here is the updated webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.2/ > > > Best regards, Matthias > > >> -----Original Message----- >> From: Erik Joelsson >> Sent: Freitag, 10. Mai 2019 16:29 >> To: Baesken, Matthias ; David Holmes >> ; 'build-dev at openjdk.java.net' > dev at openjdk.java.net> >> Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - >> was : RE: gcc FORTIFY_SOURCE application security flags >> >> Hello Matthias, >> >> I think just -U_FORTIFY_SOURCE should be enough to unset it, no need to >> also set it to 0. Also, I think it would be good to use an extra set of >> variables to avoid repeating the flag, like this: >> >> ENABLE_FORTIFY_CFLAGS="-D_FORTIFY_SOURCE=2" >> DISABLE_FORTIFY_CFLAGS="-U_FORTIFY_SOURCE" >> C_O_FLAG_HIGHEST_JVM="${C_O_FLAG_HIGHEST_JVM} >> ${ENABLE_FORTIFY_CFLAGS}" >> ... >> >> /Erik >> >> On 2019-05-09 22:46, Baesken, Matthias wrote: >>> Hello, here is the new webrev with the >>> >>> "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0" >>> >>> Set for the lower level optimization flags : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.1/ >>> >>> >>> I would suggest to leave the pre-gcc4.8 cleanup to a separate change. >>> >>> Best regards, Matthias >>> >>> >>> >>>> Configure will protest if GCC version is less than 4.8 (see toolchain.m4 >>>> *_MINIMUM_VERSION variables). >>>> >>>> That said, as long as we conditionally set the FDLIBM_CFLAGS like this, >>>> I would say we need to continue honoring the result of that check. You >>>> could also remove the check altogether since it seems to no longer be >>>> needed. >>>> >>>> /Erik >>>> >>>> On 2019-05-09 07:14, Baesken, Matthias wrote: >>>>> Hello, >>>>> I tried setting >>>>> >>>>> "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0" >>>>> >>>>> And this seems indeed to work , no warning any more . >>>>> >>>>> Let's hope gcc does not change the command line parsing . >>>>> >>>>> Btw. is there a gcc version that a) still compiles jdk/jdk and b) would >>>> show the issue ? >>>>> (with our internally used gcc's we are always > 4.6 in jdk/jdk ) >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Erik Joelsson >>>>>> Sent: Donnerstag, 9. Mai 2019 15:18 >>>>>> To: Baesken, Matthias ; David Holmes >>>>>> ; 'build-dev at openjdk.java.net' >>>>> dev at openjdk.java.net> >>>>>> Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug >> builds - >>>>>> was : RE: gcc FORTIFY_SOURCE application security flags >>>>>> >>>>>> Hello, >>>>>> >>>>>> I just tried this and you are correct. However, it does seem to work if >>>>>> you instead use -U_FORTIFY_SOURCE. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2019-05-09 05:36, Baesken, Matthias wrote: >>>>>>> Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++ >>>>>> command line call works , >>>>>>> setting together -D_FORTIFY_SOURCE=2 and - >>>> D_FORTIFY_SOURCE=0 >>>>>> in one command line call generates a warning , so I think we cannot do >>>> that . >>>>>>> Best regards, Matthias >>>>>>> From matthias.baesken at sap.com Tue May 14 13:51:01 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 14 May 2019 13:51:01 +0000 Subject: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags In-Reply-To: <9d3ac2b8-b07f-1405-917e-88e6254965ad@oracle.com> References: <5e6c58c3-2959-33ae-4aa2-85a4275e050a@oracle.com> <697940ec-9a17-cd4e-d895-2dd18c1a91b1@oracle.com> <66603421-a81d-748e-780a-25f5358bbc0f@oracle.com> <9d3ac2b8-b07f-1405-917e-88e6254965ad@oracle.com> Message-ID: Thanks ! May I have a second review ? Btw I added a comment to https://bugs.openjdk.java.net/browse/JDK-8130017 describing a bit the "current situation" (minimum gcc 4.8 + "-U_FORTIFY_SOURCE" for lower level OPT-flags (< -O1) ) . Best regards, Matthias > > Looks good, thanks! > > /Erik > > On 2019-05-14 03:16, Baesken, Matthias wrote: > > Hi Erik, here is the updated webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.2/ > > > > > > Best regards, Matthias > > > > > >> -----Original Message----- > >> From: Erik Joelsson > >> Sent: Freitag, 10. Mai 2019 16:29 > >> To: Baesken, Matthias ; David Holmes > >> ; 'build-dev at openjdk.java.net' >> dev at openjdk.java.net> > >> Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - > >> was : RE: gcc FORTIFY_SOURCE application security flags > >> > >> Hello Matthias, > >> > >> I think just -U_FORTIFY_SOURCE should be enough to unset it, no need to > >> also set it to 0. Also, I think it would be good to use an extra set of > >> variables to avoid repeating the flag, like this: > >> > >> ENABLE_FORTIFY_CFLAGS="-D_FORTIFY_SOURCE=2" > >> DISABLE_FORTIFY_CFLAGS="-U_FORTIFY_SOURCE" > >> C_O_FLAG_HIGHEST_JVM="${C_O_FLAG_HIGHEST_JVM} > >> ${ENABLE_FORTIFY_CFLAGS}" > >> ... > >> From matthias.baesken at sap.com Tue May 14 14:58:45 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 14 May 2019 14:58:45 +0000 Subject: zlib configuration : system vs. bundled Message-ID: Hello, I checked the zlib config settings and found the following : make/autoconf/lib-bundled.m4 states : ################################################################################ # Setup bundled libraries. # # For libjpeg, giflib, libpng, lcms2 and zlib, the source is present in the # OpenJDK repository. Default is to use these libraries as bundled, but they # might be replaced by en external version by the user. ################################################################################ While it is true that "bundled" is the default for libjpeg, giflib, libpng, lcms2, it is different for zlib (for zlib "bundled" is only the default on Windows/AIX, otherwise system ). On the other OS platforms, in case a zlib is found on the system : if test "x${ZLIB_FOUND}" != "xyes"; then # If we don't find any system...set default to bundled DEFAULT_ZLIB=bundled fi we use it from the system . Wouldn't it be more consistent to have zlib=bundled as well as default for the other UNIX platforms + MacOSX ? ( people who wish to use the system zlib still can configure it ) Otherwise we often run into using old zlib installations at build time which might not be desired. In case it is seen as a good thing to stay with the current setup, at least the comment has to be adjusted . Best regards, Matthias From Alan.Bateman at oracle.com Tue May 14 15:47:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2019 16:47:03 +0100 Subject: zlib configuration : system vs. bundled In-Reply-To: References: Message-ID: On 14/05/2019 15:58, Baesken, Matthias wrote: > : > > On the other OS platforms, in case a zlib is found on the system : > > if test "x${ZLIB_FOUND}" != "xyes"; then > # If we don't find any system...set default to bundled > DEFAULT_ZLIB=bundled > fi > > we use it from the system . > Wouldn't it be more consistent to have zlib=bundled as well as default for the other UNIX platforms + MacOSX ? > ( people who wish to use the system zlib still can configure it ) > > Otherwise we often run into using old zlib installations at build time which might not be desired. > It was a deliberate change in JDK 9 to use the system zlib if possible. Windows is the outlier. If you through the archives of core-libs-dev then you should find several discussions about this, I think the most recent was in 2016, subject line "JDK-8031767 Support system or alternative implementations of zlib". -Alan From mbalao at redhat.com Mon May 13 16:27:17 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 13 May 2019 13:27:17 -0300 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: Message-ID: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> Hi Goetz, Thanks for raising this issue. I'm not surprised by MaxAdvanceIsMax test failing on some OS. The reason is that this test is very OS specific. All installed fonts are tested and a static value from each font is used for the assertion, after scale calculations. If there is a difference between what the font creator set when generating the font file and what the OS rendering library returns -considering that different FreeType library builds may return different values-, this test will fail. The internal test during development phase was more reliable because it tested a known-font only. However, shipping a font is not allowed by licenses and that's why we changed the test a bit. We should probably limit the scope somehow. Despite the test failure, I'm still confident that we did the right thing in 8218854 [1]. Kind regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8218854 From mbalao at redhat.com Tue May 14 16:41:00 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 14 May 2019 13:41:00 -0300 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> Message-ID: Hi Goetz, On 5/13/19 1:38 PM, Lindenmaier, Goetz wrote: > > Can I somehow verify that it's the font that has the problem? > Can I fix the font so that the test passes? > I cannot say whether or not the static max advance value in each font is right or not, but let's assume it is. The underlying problem here is that OpenJDK uses a couple of internal FreeType library values to calculate the effects of algorithmic bold and italic in the max advance value -"algorithmic" means that the font is not italic or bold and is up to the rendering engine to generate the desired effect-. These values have changed over the years. What we did in 8218854 [1] was updating the italic value to the latest version and supporting bold in the calculation. Ideally, OpenJDK should not be tight to these values. However, that's not easy to get rid of unless we change the API or the API semantics. All this means that if you use OpenJDK 11 with an old Free Type library, you may have different values and the test may fail. Note: this is just an hypothesis, I couldn't reproduce on my own. I believe the test assertion is right if we consider API semantics only but we can put some constraints given reality. Kind regards, Martin.- -- [1] - http://hg.openjdk.java.net/jdk/jdk/rev/0804f29e8be7 From goetz.lindenmaier at sap.com Wed May 15 07:11:13 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 15 May 2019 07:11:13 +0000 Subject: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) In-Reply-To: References: <064ab98c-5487-c61a-a050-31a4a4449771@redhat.com> Message-ID: Hi Martin, Yesterday I filed 8223869: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java on more platforms as I found it is excluded on solaris and mac already. Thanks for the explanation. I will look at what freetype libs are used on the systems where this is failing. Maybe we should mark the test with @key intermittent if it depends on the system setup that much? Best regards, Goetz. > -----Original Message----- > From: Martin Balao > Sent: Tuesday, May 14, 2019 6:41 PM > To: Lindenmaier, Goetz ; 'Severin Gehwolf' > ; Langer, Christoph ; > jdk-updates-dev at openjdk.java.net > Cc: 2d-dev <2d-dev at openjdk.java.net>; build-dev at openjdk.java.net; > Martin Balao Alonso > Subject: Re: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure > (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1) > > Hi Goetz, > > On 5/13/19 1:38 PM, Lindenmaier, Goetz wrote: > > > > Can I somehow verify that it's the font that has the problem? > > Can I fix the font so that the test passes? > > > > I cannot say whether or not the static max advance value in each font is > right or not, but let's assume it is. The underlying problem here is > that OpenJDK uses a couple of internal FreeType library values to > calculate the effects of algorithmic bold and italic in the max advance > value -"algorithmic" means that the font is not italic or bold and is up > to the rendering engine to generate the desired effect-. These values > have changed over the years. What we did in 8218854 [1] was updating the > italic value to the latest version and supporting bold in the > calculation. Ideally, OpenJDK should not be tight to these values. > However, that's not easy to get rid of unless we change the API or the > API semantics. All this means that if you use OpenJDK 11 with an old > Free Type library, you may have different values and the test may fail. > > Note: this is just an hypothesis, I couldn't reproduce on my own. > > I believe the test assertion is right if we consider API semantics only > but we can put some constraints given reality. > > Kind regards, > Martin.- > > -- > [1] - http://hg.openjdk.java.net/jdk/jdk/rev/0804f29e8be7 > From matthias.baesken at sap.com Wed May 15 08:16:01 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 15 May 2019 08:16:01 +0000 Subject: zlib configuration : system vs. bundled In-Reply-To: References: Message-ID: Hi Alan, thanks for pointing me at the old discussion . http://mail.openjdk.java.net/pipermail/build-dev/2016-February/016602.html talks about performance benefits . Are you aware of some benchmarks that showed the improvements ? In reality, if you have the latest distro versions you might be lucky and you have a nice recent zlib 1.2.11 . However on older distros , you run in reality into older zlibs (often I see 1.2.8). I don't think that this is a very good status . At least I think building.md should be fixed to state the real status , the current info is wrong : "Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms and zlib) are included in the JDK repository. The default behavior of the JDK build is to use this version of these libraries, but they might be replaced by an external version. To do so, specify `system` as the `` option in these arguments. (The default is `bundled`)." Btw how is building.html generated , is this coming from building.md ? Best regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Dienstag, 14. Mai 2019 17:47 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Subject: Re: zlib configuration : system vs. bundled > > On 14/05/2019 15:58, Baesken, Matthias wrote: > > : > > > > On the other OS platforms, in case a zlib is found on the system : > > > > if test "x${ZLIB_FOUND}" != "xyes"; then > > # If we don't find any system...set default to bundled > > DEFAULT_ZLIB=bundled > > fi > > > > we use it from the system . > > Wouldn't it be more consistent to have zlib=bundled as well as default for > the other UNIX platforms + MacOSX ? > > ( people who wish to use the system zlib still can configure it ) > > > > Otherwise we often run into using old zlib installations at build time which > might not be desired. > > > It was a deliberate change in JDK 9 to use the system zlib if possible. > Windows is the outlier. If you through the archives of core-libs-dev > then you should find several discussions about this, I think the most > recent was in 2016, subject line "JDK-8031767 Support system or > alternative implementations of zlib". > > -Alan From matthias.baesken at sap.com Wed May 15 09:32:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 15 May 2019 09:32:51 +0000 Subject: 8223944: fix zlib related building docu and comments - was : RE: zlib configuration : system vs. bundled Message-ID: Btw I adjusted the build docu and some m4 file comments regarding the zlib usage : https://bugs.openjdk.java.net/browse/JDK-8223944 http://cr.openjdk.java.net/~mbaesken/webrevs/8223944.0/ Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Mittwoch, 15. Mai 2019 10:16 > To: 'Alan Bateman' ; 'build- > dev at openjdk.java.net' > Subject: RE: zlib configuration : system vs. bundled > > Hi Alan, thanks for pointing me at the old discussion . > > http://mail.openjdk.java.net/pipermail/build-dev/2016- > February/016602.html > > talks about performance benefits . Are you aware of some benchmarks that > showed the improvements ? > > In reality, if you have the latest distro versions you might be lucky and you > have a nice recent zlib 1.2.11 . > However on older distros , you run in reality into older zlibs (often I see > 1.2.8). I don't think that this is a very good status . > > > At least I think building.md should be fixed to state the real status , the > current info is wrong : > > > "Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms > and zlib) are included in the JDK repository. The default behavior of the > JDK build is to use this version of these libraries, but they might be > replaced by an external version. To do so, specify `system` as the `` > option in these arguments. (The default is `bundled`)." > > > > Btw how is building.html generated , is this coming from building.md ? > > Best regards, Matthias > > > > > > -----Original Message----- > > From: Alan Bateman > > Sent: Dienstag, 14. Mai 2019 17:47 > > To: Baesken, Matthias ; 'build- > > dev at openjdk.java.net' > > Subject: Re: zlib configuration : system vs. bundled > > > > On 14/05/2019 15:58, Baesken, Matthias wrote: > > > : > > > > > > On the other OS platforms, in case a zlib is found on the system : > > > > > > if test "x${ZLIB_FOUND}" != "xyes"; then > > > # If we don't find any system...set default to bundled > > > DEFAULT_ZLIB=bundled > > > fi > > > > > > we use it from the system . > > > Wouldn't it be more consistent to have zlib=bundled as well as default > for > > the other UNIX platforms + MacOSX ? > > > ( people who wish to use the system zlib still can configure it ) > > > > > > Otherwise we often run into using old zlib installations at build time which > > might not be desired. > > > > > It was a deliberate change in JDK 9 to use the system zlib if possible. > > Windows is the outlier. If you through the archives of core-libs-dev > > then you should find several discussions about this, I think the most > > recent was in 2016, subject line "JDK-8031767 Support system or > > alternative implementations of zlib". > > > > -Alan From Alan.Bateman at oracle.com Wed May 15 10:24:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2019 11:24:03 +0100 Subject: zlib configuration : system vs. bundled In-Reply-To: References: Message-ID: <2ea5ad0d-04b1-4f16-17a0-8c16f7108840@oracle.com> On 15/05/2019 09:16, Baesken, Matthias wrote: > Hi Alan, thanks for pointing me at the old discussion . > > http://mail.openjdk.java.net/pipermail/build-dev/2016-February/016602.html > > talks about performance benefits . Are you aware of some benchmarks that showed the improvements ? If you can find the mails that references the Intel IPP library then you might have links to performance data comparing the different implementations. There is also mails somewhere in the archive with a proposal or patch to have the JDK select an alternative implementation at run-time, equivalent to LD_PRELOAD. I think we ended up with the right default. > > In reality, if you have the latest distro versions you might be lucky and you have a nice recent zlib 1.2.11 . > However on older distros , you run in reality into older zlibs (often I see 1.2.8). I don't think that this is a very good status . Sure but the opposite can arise too, say where someone is using a JDK release that bundles an older version of zlib. I agree with the comment that the building instructions need to be sync'ed up. -Alan. From johan.vos at gluonhq.com Wed May 15 10:45:04 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 15 May 2019 12:45:04 +0200 Subject: static libraries on mac Message-ID: In order to build static libraries for macosx, I had to apply 2 small changes to the build files[1]. If someone is willing to sponsor this, I can create a webrev for it? Thanks, - Johan [1] https://github.com/johanvos/jdk/commit/40ef1b297a3531fed3059700a398f86abeed92ce From david.holmes at oracle.com Wed May 15 12:36:22 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2019 22:36:22 +1000 Subject: static libraries on mac In-Reply-To: References: Message-ID: <1dce0a5b-54d4-ab8f-1682-133b7de208ab@oracle.com> Hi Johan, Contributions must be provided via OpenJDK infrastructure - either on cr.openjdk.java.net or email attachments (or inline) to the lists. So please create a webrev and file a bug. Thanks, David On 15/05/2019 8:45 pm, Johan Vos wrote: > In order to build static libraries for macosx, I had to apply 2 small > changes to the build files[1]. > If someone is willing to sponsor this, I can create a webrev for it? > > Thanks, > > - Johan > > [1] > https://github.com/johanvos/jdk/commit/40ef1b297a3531fed3059700a398f86abeed92ce > From erik.joelsson at oracle.com Wed May 15 15:29:47 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 15 May 2019 08:29:47 -0700 Subject: 8223944: fix zlib related building docu and comments - was : RE: zlib configuration : system vs. bundled In-Reply-To: References: Message-ID: Thanks for updating the docs! I have some details to comment on. In general, could you try to keep the doc/comments within the 80 char limit and remove the arbitrary line breaks so that it looks uniform? More specifically: doc/building.md 725: Break line. 727: Grammatical nit: might -> may 728: Break line. make/autoconf/lib-bundled.m4 30: Break line. Spelling: refered -> referred 31: Space before dot. Remove line break. 33: Remove line break. 34: Grammatical nit: might -> may /Erik On 2019-05-15 02:32, Baesken, Matthias wrote: > Btw I adjusted the build docu and some m4 file comments regarding the zlib usage : > > https://bugs.openjdk.java.net/browse/JDK-8223944 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223944.0/ > > > Best regards, Matthias > > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Mittwoch, 15. Mai 2019 10:16 >> To: 'Alan Bateman' ; 'build- >> dev at openjdk.java.net' >> Subject: RE: zlib configuration : system vs. bundled >> >> Hi Alan, thanks for pointing me at the old discussion . >> >> http://mail.openjdk.java.net/pipermail/build-dev/2016- >> February/016602.html >> >> talks about performance benefits . Are you aware of some benchmarks that >> showed the improvements ? >> >> In reality, if you have the latest distro versions you might be lucky and you >> have a nice recent zlib 1.2.11 . >> However on older distros , you run in reality into older zlibs (often I see >> 1.2.8). I don't think that this is a very good status . >> >> >> At least I think building.md should be fixed to state the real status , the >> current info is wrong : >> >> >> "Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms >> and zlib) are included in the JDK repository. The default behavior of the >> JDK build is to use this version of these libraries, but they might be >> replaced by an external version. To do so, specify `system` as the `` >> option in these arguments. (The default is `bundled`)." >> >> >> >> Btw how is building.html generated , is this coming from building.md ? >> >> Best regards, Matthias >> >> >> >> >>> -----Original Message----- >>> From: Alan Bateman >>> Sent: Dienstag, 14. Mai 2019 17:47 >>> To: Baesken, Matthias ; 'build- >>> dev at openjdk.java.net' >>> Subject: Re: zlib configuration : system vs. bundled >>> >>> On 14/05/2019 15:58, Baesken, Matthias wrote: >>>> : >>>> >>>> On the other OS platforms, in case a zlib is found on the system : >>>> >>>> if test "x${ZLIB_FOUND}" != "xyes"; then >>>> # If we don't find any system...set default to bundled >>>> DEFAULT_ZLIB=bundled >>>> fi >>>> >>>> we use it from the system . >>>> Wouldn't it be more consistent to have zlib=bundled as well as default >> for >>> the other UNIX platforms + MacOSX ? >>>> ( people who wish to use the system zlib still can configure it ) >>>> >>>> Otherwise we often run into using old zlib installations at build time which >>> might not be desired. >>> It was a deliberate change in JDK 9 to use the system zlib if possible. >>> Windows is the outlier. If you through the archives of core-libs-dev >>> then you should find several discussions about this, I think the most >>> recent was in 2016, subject line "JDK-8031767 Support system or >>> alternative implementations of zlib". >>> >>> -Alan From erik.joelsson at oracle.com Wed May 15 15:32:39 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 15 May 2019 08:32:39 -0700 Subject: zlib configuration : system vs. bundled In-Reply-To: References: Message-ID: On 2019-05-15 01:16, Baesken, Matthias wrote: > Hi Alan, thanks for pointing me at the old discussion . > > http://mail.openjdk.java.net/pipermail/build-dev/2016-February/016602.html > > talks about performance benefits . Are you aware of some benchmarks that showed the improvements ? > > In reality, if you have the latest distro versions you might be lucky and you have a nice recent zlib 1.2.11 . > However on older distros , you run in reality into older zlibs (often I see 1.2.8). I don't think that this is a very good status . > > > At least I think building.md should be fixed to state the real status , the current info is wrong : > > > "Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms > and zlib) are included in the JDK repository. The default behavior of the > JDK build is to use this version of these libraries, but they might be > replaced by an external version. To do so, specify `system` as the `` > option in these arguments. (The default is `bundled`)." > > > > Btw how is building.html generated , is this coming from building.md ? Yes, you need to configure with pandoc. Then you run "make update-build-docs". /Erik > Best regards, Matthias > > > > >> -----Original Message----- >> From: Alan Bateman >> Sent: Dienstag, 14. Mai 2019 17:47 >> To: Baesken, Matthias ; 'build- >> dev at openjdk.java.net' >> Subject: Re: zlib configuration : system vs. bundled >> >> On 14/05/2019 15:58, Baesken, Matthias wrote: >>> : >>> >>> On the other OS platforms, in case a zlib is found on the system : >>> >>> if test "x${ZLIB_FOUND}" != "xyes"; then >>> # If we don't find any system...set default to bundled >>> DEFAULT_ZLIB=bundled >>> fi >>> >>> we use it from the system . >>> Wouldn't it be more consistent to have zlib=bundled as well as default for >> the other UNIX platforms + MacOSX ? >>> ( people who wish to use the system zlib still can configure it ) >>> >>> Otherwise we often run into using old zlib installations at build time which >> might not be desired. >> It was a deliberate change in JDK 9 to use the system zlib if possible. >> Windows is the outlier. If you through the archives of core-libs-dev >> then you should find several discussions about this, I think the most >> recent was in 2016, subject line "JDK-8031767 Support system or >> alternative implementations of zlib". >> >> -Alan From kim.barrett at oracle.com Wed May 15 19:38:48 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 15 May 2019 15:38:48 -0400 Subject: static libraries on mac In-Reply-To: <1dce0a5b-54d4-ab8f-1682-133b7de208ab@oracle.com> References: <1dce0a5b-54d4-ab8f-1682-133b7de208ab@oracle.com> Message-ID: <796D41DA-AA17-47E2-AF7B-0CC4CC09ACDA@oracle.com> > On May 15, 2019, at 8:36 AM, David Holmes wrote: > > Hi Johan, > > Contributions must be provided via OpenJDK infrastructure - either on cr.openjdk.java.net or email attachments (or inline) to the lists. So please create a webrev and file a bug. There is a MacOSX-specific --enable-static-build configure option, but it's been broken for a while for various reasons (see https://bugs.openjdk.java.net/browse/JDK-8211732). You might not need to file a new bug, instead using that one. > > Thanks, > David > > On 15/05/2019 8:45 pm, Johan Vos wrote: >> In order to build static libraries for macosx, I had to apply 2 small >> changes to the build files[1]. >> If someone is willing to sponsor this, I can create a webrev for it? >> Thanks, >> - Johan >> [1] >> https://github.com/johanvos/jdk/commit/40ef1b297a3531fed3059700a398f86abeed92ce From hohensee at amazon.com Wed May 15 20:42:51 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 15 May 2019 20:42:51 +0000 Subject: [PING] [8u] RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> References: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> Message-ID: <2474115F-1A08-4C22-A267-0FA93FA29A09@amazon.com> Looks good. Paul ?On 5/9/19, 5:39 AM, "hotspot-dev on behalf of sgehwolf at redhat.com" wrote: Ping? On Fri, 2019-05-03 at 18:35 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this 8u backport of an optimization fix > pertaining to the hotspot copy of fdlibm? Historically, > sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have been compiled > with optimization turned off on x86/x86_64. As JDK-8210416 will be > backported to JDK 8u fixing optimization for fdlibm itself, so should > be the hotspot copy in OpenJDK 8u. The build system for hotspot in JDK > 8u is very different, so the original fix for JDK 12 doesn't apply. > It's a complete rewrite. Please see this webrev which shows the > prerequisite patch. It adds the FDLIBM_CFLAGS logic: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ > > It also fixes a bug on ppc64{,le} where optimization is being turned on > in hotspot (-O3), but not providing the -ffp-contract=off flag (or > older equivalent). > > Before (on ppc64le): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > After (on ppc64le; Note -ffp-contract=off flag): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -ffp-contract=off -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/jdk8/02/webrev > > Testing: Builds on x86_64 (server/Zero). Manual inspection of compile > log of sharedRuntimeTrans.cpp/sharedRuntimeTrig.cpp. Same for ppc64le. > Note that we've been using this patch downstream for a while now. We > haven't seen any issues so far. > > Thanks, > Severin From matthias.baesken at sap.com Thu May 16 11:34:00 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 16 May 2019 11:34:00 +0000 Subject: zlib configuration : system vs. bundled In-Reply-To: References: Message-ID: Hello, the updated webrev is here : http://cr.openjdk.java.net/~mbaesken/webrevs/8223944.1/ Best regards, Matthias > > > On 2019-05-15 01:16, Baesken, Matthias wrote: > > Hi Alan, thanks for pointing me at the old discussion . > > > > http://mail.openjdk.java.net/pipermail/build-dev/2016- > February/016602.html > > > > talks about performance benefits . Are you aware of some benchmarks > that showed the improvements ? > > > > In reality, if you have the latest distro versions you might be lucky and you > have a nice recent zlib 1.2.11 . > > However on older distros , you run in reality into older zlibs (often I see > 1.2.8). I don't think that this is a very good status . > > > > > > At least I think building.md should be fixed to state the real status , the > current info is wrong : > > > > > > "Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms > > and zlib) are included in the JDK repository. The default behavior of the > > JDK build is to use this version of these libraries, but they might be > > replaced by an external version. To do so, specify `system` as the > `` > > option in these arguments. (The default is `bundled`)." > > > > > > > > Btw how is building.html generated , is this coming from building.md ? > > Yes, you need to configure with pandoc. Then you run "make > update-build-docs". > > /Erik > From erik.joelsson at oracle.com Thu May 16 13:46:24 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 16 May 2019 06:46:24 -0700 Subject: zlib configuration : system vs. bundled In-Reply-To: References: Message-ID: <975f4135-c6e3-2e93-32cc-fa8200cedfeb@oracle.com> Looks ok. /Erik On 2019-05-16 04:34, Baesken, Matthias wrote: > Hello, the updated webrev is here : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223944.1/ > > > Best regards, Matthias > > > >> >> On 2019-05-15 01:16, Baesken, Matthias wrote: >>> Hi Alan, thanks for pointing me at the old discussion . >>> >>> http://mail.openjdk.java.net/pipermail/build-dev/2016- >> February/016602.html >>> talks about performance benefits . Are you aware of some benchmarks >> that showed the improvements ? >>> In reality, if you have the latest distro versions you might be lucky and you >> have a nice recent zlib 1.2.11 . >>> However on older distros , you run in reality into older zlibs (often I see >> 1.2.8). I don't think that this is a very good status . >>> >>> At least I think building.md should be fixed to state the real status , the >> current info is wrong : >>> >>> "Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms >>> and zlib) are included in the JDK repository. The default behavior of the >>> JDK build is to use this version of these libraries, but they might be >>> replaced by an external version. To do so, specify `system` as the >> `` >>> option in these arguments. (The default is `bundled`)." >>> >>> >>> >>> Btw how is building.html generated , is this coming from building.md ? >> Yes, you need to configure with pandoc. Then you run "make >> update-build-docs". >> >> /Erik >> From Alan.Bateman at oracle.com Thu May 16 13:57:21 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2019 14:57:21 +0100 Subject: zlib configuration : system vs. bundled In-Reply-To: References: Message-ID: <69382814-35b4-3095-7af9-d8d414d7a37a@oracle.com> On 16/05/2019 12:34, Baesken, Matthias wrote: > Hello, the updated webrev is here : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223944.1/ > > This looks good to me. -Alan From matthias.baesken at sap.com Thu May 16 14:18:57 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 16 May 2019 14:18:57 +0000 Subject: zlib configuration : system vs. bundled In-Reply-To: <2ea5ad0d-04b1-4f16-17a0-8c16f7108840@oracle.com> References: <2ea5ad0d-04b1-4f16-17a0-8c16f7108840@oracle.com> Message-ID: Hello Alan, I found http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032106.html and http://mail.openjdk.java.net/pipermail/build-dev/2016-February/thread.html#16602 but without much details on real or potential performance improvements . Both discussion threads are pretty old. I do not think they cover the changes done in the meantime in jdk9 and higher in the java.util.zip package . I think a lot of coding there moved from C to Java , so the libz is used in JDK less these days than in the "old times " . > > Sure but the opposite can arise too, say where someone is using a JDK > release that bundles an older version of zlib. > True , unfortunately the old JDK with bundled libz would not use the "great new current libz" from the distro (in case there is such a recent version available ), People would need to patch the JDK . At least we have the freedom to choose with the configure-flags . Best regards, Matthias > On 15/05/2019 09:16, Baesken, Matthias wrote: > > Hi Alan, thanks for pointing me at the old discussion . > > > > http://mail.openjdk.java.net/pipermail/build-dev/2016- > February/016602.html > > > > talks about performance benefits . Are you aware of some benchmarks > that showed the improvements ? > If you can find the mails that references the Intel IPP library then you > might have links to performance data comparing the different > implementations. There is also mails somewhere in the archive with a > proposal or patch to have the JDK select an alternative implementation > at run-time, equivalent to LD_PRELOAD. I think we ended up with the > right default. > > > > > In reality, if you have the latest distro versions you might be lucky and you > have a nice recent zlib 1.2.11 . > > However on older distros , you run in reality into older zlibs (often I see > 1.2.8). I don't think that this is a very good status . > Sure but the opposite can arise too, say where someone is using a JDK > release that bundles an older version of zlib. > > I agree with the comment that the building instructions need to be > sync'ed up. > > -Alan. From zuismanm at gmail.com Thu May 16 16:53:49 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Thu, 16 May 2019 19:53:49 +0300 Subject: problem building opnJdk 11 at Linux Message-ID: I have a problem building opnJdk 11 at Linux. When I run : make test I get: *Building target 'test' in configuration 'linux-x86_64-normal-server-release'* *Warning: No mercurial configuration present and no .src-rev* *Compiling 27 files for BUILD_FAILURE_HANDLER* */data1/controlm/jdk11-1ddf9a99e4ad/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:123: error: no suitable method found for save(Map)* * rp.save(map);* * ^* * method InterviewParameters.save(File) is not applicable* * (argument mismatch; Map cannot be converted to File)* * method InterviewParameters.save(Map) is not applicable* * (argument mismatch; Map cannot be converted to Map)* * where CAP#1,CAP#2 are fresh type-variables:* * CAP#1 extends Object from capture of ?* * CAP#2 extends Object from capture of ?* *Note: Some input files use or override a deprecated API.* *Note: Recompile with -Xlint:deprecation for details.* *Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output* *1 error* *gmake[3]: *** [/data1/controlm/jdk11-1ddf9a99e4ad/build/linux-x86_64-normal-server-release/support/test/failure_handler/classes/_the.BUILD_FAILURE_HANDLER_batch] Error 1* *gmake[2]: *** [build-test-failure-handler] Error 1* *gmake[2]: *** Waiting for unfinished jobs....* *ERROR: Build failed for target 'test' in configuration 'linux-x86_64-normal-server-release' (exit code 2)* *Stopping sjavac server* *=== Output from failing command(s) repeated here ===* ** For target support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch:* */data1/controlm/jdk11-1ddf9a99e4ad/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:123: error: no suitable method found for save(Map)* * rp.save(map);* * ^* * method InterviewParameters.save(File) is not applicable* * (argument mismatch; Map cannot be converted to File)* * method InterviewParameters.save(Map) is not applicable* * (argument mismatch; Map cannot be converted to Map)* * where CAP#1,CAP#2 are fresh type-variables:* * CAP#1 extends Object from capture of ?* * CAP#2 extends Object from capture of ?* *Note: Some input files use or override a deprecated API.* *Note: Recompile with -Xlint:deprecation for details.* * ... (rest of output omitted)* ** All command lines available in /data1/controlm/jdk11-1ddf9a99e4ad/build/linux-x86_64-normal-server-release/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]: *** [main] Error 1* *make: *** [test] Error 2* From shade at redhat.com Thu May 16 16:58:07 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 May 2019 18:58:07 +0200 Subject: problem building opnJdk 11 at Linux In-Reply-To: References: Message-ID: <20a1a6ff-4805-d1e5-f823-b569653bb2cc@redhat.com> On 5/16/19 6:53 PM, Moshe Zuisman wrote: > */data1/controlm/jdk11-1ddf9a99e4ad/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:123: > error: no suitable method found for save(Map)* This is jtreg incompatibility [1]. It should be already fixed in jdk11u repository here: http://hg.openjdk.java.net/jdk-updates/jdk11u http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281 ...when configured with up-to-date jtreg, for example from here: https://builds.shipilev.net/jtreg/ -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8208647 From zuismanm at gmail.com Thu May 16 17:15:16 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Thu, 16 May 2019 20:15:16 +0300 Subject: problem building opnJdk 11 at Linux In-Reply-To: <20a1a6ff-4805-d1e5-f823-b569653bb2cc@redhat.com> References: <20a1a6ff-4805-d1e5-f823-b569653bb2cc@redhat.com> Message-ID: Thanks! Will try it. ??, 16 ??? 2019 ?. ? 19:58, Aleksey Shipilev : > On 5/16/19 6:53 PM, Moshe Zuisman wrote: > > > */data1/controlm/jdk11-1ddf9a99e4ad/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:123: > > error: no suitable method found for save(Map)* > > This is jtreg incompatibility [1]. It should be already fixed in jdk11u > repository here: > http://hg.openjdk.java.net/jdk-updates/jdk11u > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281 > > ...when configured with up-to-date jtreg, for example from here: > https://builds.shipilev.net/jtreg/ > > -Aleksey > > [1] https://bugs.openjdk.java.net/browse/JDK-8208647 > > From philip.race at oracle.com Thu May 16 19:30:06 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 16 May 2019 12:30:06 -0700 Subject: RFR: 8223804: [macos] remove obsoleted reference to security framework in launcher code Message-ID: <7f3f85b2-b2ae-6fec-2a9f-300573524213@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8223804 Webrev: http://cr.openjdk.java.net/~prr/8223804/ This is a small cleanup fix. When doing a previous launcher fix : https://bugs.openjdk.java.net/browse/JDK-8222819 I failed to check if the removal there meant there were now unused imports in the affected source file. There was one. And it seems there is also no longer a need to link against the Security framework either. -phil. From Roger.Riggs at oracle.com Thu May 16 19:33:51 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 16 May 2019 15:33:51 -0400 Subject: RFR: 8223804: [macos] remove obsoleted reference to security framework in launcher code In-Reply-To: <7f3f85b2-b2ae-6fec-2a9f-300573524213@oracle.com> References: <7f3f85b2-b2ae-6fec-2a9f-300573524213@oracle.com> Message-ID: <735a671e-3759-e24f-5ebb-dd43a3075311@oracle.com> Hi Phil, Looks fine. Roger On 05/16/2019 03:30 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8223804 > Webrev: http://cr.openjdk.java.net/~prr/8223804/ > > This is a small cleanup fix. > When doing a previous launcher fix : > https://bugs.openjdk.java.net/browse/JDK-8222819 > I failed to check if the removal there meant there were now unused > imports in the > affected source file. There was one. And it seems there is also no > longer a need to link > against the Security framework either. > > -phil. From erik.joelsson at oracle.com Thu May 16 19:45:33 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 16 May 2019 12:45:33 -0700 Subject: RFR: 8223804: [macos] remove obsoleted reference to security framework in launcher code In-Reply-To: <7f3f85b2-b2ae-6fec-2a9f-300573524213@oracle.com> References: <7f3f85b2-b2ae-6fec-2a9f-300573524213@oracle.com> Message-ID: Looks good. /Erik On 2019-05-16 12:30, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8223804 > Webrev: http://cr.openjdk.java.net/~prr/8223804/ > > This is a small cleanup fix. > When doing a previous launcher fix : > https://bugs.openjdk.java.net/browse/JDK-8222819 > I failed to check if the removal there meant there were now unused > imports in the > affected source file. There was one. And it seems there is also no > longer a need to link > against the Security framework either. > > -phil. From Alan.Bateman at oracle.com Fri May 17 07:47:02 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 May 2019 08:47:02 +0100 Subject: zlib configuration : system vs. bundled In-Reply-To: References: <2ea5ad0d-04b1-4f16-17a0-8c16f7108840@oracle.com> Message-ID: <9c2696dc-8a72-b746-f148-3b8a93c2cfd2@oracle.com> On 16/05/2019 15:18, Baesken, Matthias wrote: > Hello Alan, > > I found > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032106.html > > and > > http://mail.openjdk.java.net/pipermail/build-dev/2016-February/thread.html#16602 > > but without much details on real or potential performance improvements . > > Both discussion threads are pretty old. I do not think they cover the changes done in the meantime in jdk9 and higher in the java.util.zip package . > I think a lot of coding there moved from C to Java , so the libz is used in JDK less these days than in the "old times " . Yes, the ZipFile implementation has changed significantly (many of the motivations are listed in JDK-8142508) but the compression and checksum (except CRC32C) will use libz. You'll see hotspot using it too, say when running with -Xbootclasspath/a to add a JAR file to the boot class path. There has many threads here and on core-libs-dev about using the bundled vs. system zlib. It was an issue for the Linux distros in the early days of OpenJDK as they have policies to not include copies of libraries that the OS provides. At one point there was a patch proposing a XX option to select the system vs. bundled zlib at run-time, the motivation being to be able to switch to the Intel IPP implementation. It's impossible to please everyone but I think the default that we settled on is probably the best. -Alan From matthias.baesken at sap.com Fri May 17 08:18:49 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 17 May 2019 08:18:49 +0000 Subject: zlib configuration : system vs. bundled In-Reply-To: <9c2696dc-8a72-b746-f148-3b8a93c2cfd2@oracle.com> References: <2ea5ad0d-04b1-4f16-17a0-8c16f7108840@oracle.com> <9c2696dc-8a72-b746-f148-3b8a93c2cfd2@oracle.com> Message-ID: Hi Alan, thanks for the info . Are you aware of a way to reliably see the info (e.g. in hs_err file) what version of libz was used at runtime ? On linux (with some luck ) we see it in hs_err , at least a lot of distros put the version into the libname , and then it is displayed in the hs_err section Dynamic libraries: ... /lib64/libz.so.1.2.8 ... /lib64/libz.so.1.2.8 ... /lib64/libz.so.1.2.8 On macOSX you see nothing just because the version is not in the libname : Dynamic libraries: ... /usr/lib/libz.1.dylib Best regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Freitag, 17. Mai 2019 09:47 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Subject: Re: zlib configuration : system vs. bundled > > On 16/05/2019 15:18, Baesken, Matthias wrote: > > Hello Alan, > > > > I found > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015- > March/032106.html > > > > and > > > > http://mail.openjdk.java.net/pipermail/build-dev/2016- > February/thread.html#16602 > > > > but without much details on real or potential performance > improvements . > > > > Both discussion threads are pretty old. I do not think they cover the > changes done in the meantime in jdk9 and higher in the java.util.zip > package . > > I think a lot of coding there moved from C to Java , so the libz is used in > JDK less these days than in the "old times " . > Yes, the ZipFile implementation has changed significantly (many of the > motivations are listed in JDK-8142508) but the compression and checksum > (except CRC32C) will use libz. You'll see hotspot using it too, say when > running with -Xbootclasspath/a to add a JAR file to the boot class path. > There has many threads here and on core-libs-dev about using the bundled > vs. system zlib. It was an issue for the Linux distros in the early days > of OpenJDK as they have policies to not include copies of libraries that > the OS provides. At one point there was a patch proposing a XX option to > select the system vs. bundled zlib at run-time, the motivation being to > be able to switch to the Intel IPP implementation. It's impossible to > please everyone but I think the default that we settled on is probably > the best. > > -Alan From jonathan.gibbons at oracle.com Sat May 18 00:16:47 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 17 May 2019 17:16:47 -0700 Subject: RFR: docs/build JDK-8223663 Update links for tool guides Message-ID: <0761b63b-3a30-6647-ac83-dfbb0d635b64@oracle.com> In JDK 13, the pages for the Tools Reference guides are moving, and so the links from the API pages to these guides needs to be updated. Please review a two-part change. 1. A new taglet is introduced that can generates links from API pages to pages in the sibling specs/man directory, which is the new home for the pages known as "Tool Guides" a.k.a "man" pages. ??? The new taglet is used as follows:?? @toolGuide ??? This generates a section in the specification similar to what was generated before, although previously it was done in a more complicated manner. ??? The taglet is placed in the build.tools package, alongside other recent custom taglets. ??? make/Docs.gmk is updated to use the new taglet. 2. All the references in the various module-info.java files to the old "Tools Reference" pages are replaced with usages of the new taglet. ??? Although this is generally a case of replacing old references with new references, there are some anomalies that had to be taken into account. ??? a. There is not, and apparently never was, a Tools Reference page for "jfr". The reference was 404. The link is removed for now, and can be replaced if such a page becomes available. ??? b. Some of the links under the "Tools Reference" heading were to pages that were not "man" pages, and which are not being migrated at this time. These links are left alone, although it has meant separating the two kinds of links into two separate lists, one for the old-style links which remain, and one for the new "man" pages. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8223663 Webrev: http://cr.openjdk.java.net/~jjg/8223663-toolguides/webrev.00/ Sample docs: http://cr.openjdk.java.net/~jjg/8223663-toolguides/docs/api/index.html From Alan.Bateman at oracle.com Sat May 18 07:26:15 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 18 May 2019 08:26:15 +0100 Subject: RFR: docs/build JDK-8223663 Update links for tool guides In-Reply-To: <0761b63b-3a30-6647-ac83-dfbb0d635b64@oracle.com> References: <0761b63b-3a30-6647-ac83-dfbb0d635b64@oracle.com> Message-ID: <23e9724b-3380-e8b7-2bbd-0fa88f2bd910@oracle.com> On 18/05/2019 01:16, Jonathan Gibbons wrote: > In JDK 13, the pages for the Tools Reference guides are moving, and so > the links from the API pages to these guides needs to be updated. > > Please review a two-part change. I went changes to each of the module-info.java files and skimmed through the code for the new taglet. All looks good to me. -Alan From joe.darcy at oracle.com Sun May 19 20:38:32 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 19 May 2019 13:38:32 -0700 Subject: RFR: docs/build JDK-8223663 Update links for tool guides In-Reply-To: <0761b63b-3a30-6647-ac83-dfbb0d635b64@oracle.com> References: <0761b63b-3a30-6647-ac83-dfbb0d635b64@oracle.com> Message-ID: Good docs cleanup Jon; thanks, -Joe On 5/17/2019 5:16 PM, Jonathan Gibbons wrote: > In JDK 13, the pages for the Tools Reference guides are moving, and so > the links from the API pages to these guides needs to be updated. > > Please review a two-part change. > > 1. A new taglet is introduced that can generates links from API pages > to pages in the sibling specs/man directory, which is the new home for > the pages known as "Tool Guides" a.k.a "man" pages. > > ??? The new taglet is used as follows:?? @toolGuide > ??? This generates a section in the specification similar to what was > generated before, although previously it was done in a more > complicated manner. > > ??? The taglet is placed in the build.tools package, alongside other > recent custom taglets. > > ??? make/Docs.gmk is updated to use the new taglet. > > > 2. All the references in the various module-info.java files to the old > "Tools Reference" pages are replaced with usages of the new taglet. > > ??? Although this is generally a case of replacing old references with > new references, there are some anomalies that had to be taken into > account. > > ??? a. There is not, and apparently never was, a Tools Reference page > for "jfr". The reference was 404. The link is removed for now, and can > be replaced if such a page becomes available. > > ??? b. Some of the links under the "Tools Reference" heading were to > pages that were not "man" pages, and which are not being migrated at > this time. These links are left alone, although it has meant > separating the two kinds of links into two separate lists, one for the > old-style links which remain, and one for the new "man" pages. > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223663 > Webrev: http://cr.openjdk.java.net/~jjg/8223663-toolguides/webrev.00/ > Sample docs: > http://cr.openjdk.java.net/~jjg/8223663-toolguides/docs/api/index.html > > > From david.holmes at oracle.com Mon May 20 07:40:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 May 2019 17:40:00 +1000 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ The need to remove a for-loop declaration expression to appease gcc 4.8 annoyed me enough to investigate setting C99 as our minimum allow C-language level when compiling. It turned out to be a lot more complex a situation than I thought due to toolchain quirks. See lots of details in the bug report. To summarise the changes: - gcc: force to -std=gnu99 - clang force to -std=gnu99 - Solaris studio - no effective change - Visual Studio - no change - xlc - no effective change (but we use the explicit flag rather than accepting it as default) I've checked how this works with all the toolchains except xlc as I have no access to that. Some assistance from someone who can verify the correctness on xlc would be appreciated. Thanks, David From aph at redhat.com Mon May 20 12:49:01 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 May 2019 13:49:01 +0100 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: <64cc8255-d0a4-bb75-24e8-1701417a9a9c@redhat.com> On 5/20/19 8:40 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 > webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ > > The need to remove a for-loop declaration expression to appease gcc 4.8 > annoyed me enough to investigate setting C99 as our minimum allow > C-language level when compiling. It turned out to be a lot more complex > a situation than I thought due to toolchain quirks. See lots of details > in the bug report. > > To summarise the changes: > - gcc: force to -std=gnu99 > - clang force to -std=gnu99 > - Solaris studio - no effective change > - Visual Studio - no change > - xlc - no effective change (but we use the explicit flag rather than > accepting it as default) > > I've checked how this works with all the toolchains except xlc as I have > no access to that. Some assistance from someone who can verify the > correctness on xlc would be appreciated. You are a hero for doing this. Thank you, thank you! Approved by me, checking only Linux targets. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Mon May 20 14:05:20 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 May 2019 16:05:20 +0200 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: Hi David, thanks for considering AIX in your change. With OpenJDK 13 we've moved to XLC 16 which has a new Clang based frontend. The "ucs" feature-suboption [1] you're using in your change is only supported in the old, xlc compiler but not in the new xlclang any more [2]. However, the good news is that the new xlclang now supports the same "-std=gn99" option like gcc and clang, so you could easily handle the xlc case now together with gcc and clang as shown in this webrev: http://cr.openjdk.java.net/~simonis/webrevs/2019/8224087/ Otherwise, your change looks good! Please let me know once you've pushed it. I opened "8224214: [AIX] Remove support for legacy xlc compiler" [3] for further cleannups because we still set some "-qlanglvl" options for C++ which aren't supported by the new compiler either. Best regards, Volker [1] https://www.ibm.com/support/knowledgecenter/SSGH3R_12.1.0/com.ibm.xlcpp121.aix.doc/compiler_ref/opt_langlvl.html [2] https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_langlvl_aix.html On Mon, May 20, 2019 at 9:40 AM David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 > webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ > > The need to remove a for-loop declaration expression to appease gcc 4.8 > annoyed me enough to investigate setting C99 as our minimum allow > C-language level when compiling. It turned out to be a lot more complex > a situation than I thought due to toolchain quirks. See lots of details > in the bug report. > > To summarise the changes: > - gcc: force to -std=gnu99 > - clang force to -std=gnu99 > - Solaris studio - no effective change > - Visual Studio - no change > - xlc - no effective change (but we use the explicit flag rather than > accepting it as default) > > I've checked how this works with all the toolchains except xlc as I have > no access to that. Some assistance from someone who can verify the > correctness on xlc would be appreciated. > > Thanks, > David From akashche at redhat.com Mon May 20 14:29:18 2019 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 20 May 2019 15:29:18 +0100 Subject: [PATCH] msys2 detection in autoconf Message-ID: <0892e076-05ac-d484-57cd-0b59155a87f4@redhat.com> Hi, We've got an unusual build scenario, when user has a jdk-windows build setup with a pre-configured cygwin environment (and a batch script to run the build), but want to start this build on a remote machine that runs SSH server inside msys2 environment. In this scenario, with batch script started over msys2 SSH, autoconf fails on OS detection, and the patch below (submitted by github user quanah) is needed to fix that. If someone thinks that such change is a good idea - I can file a Jira issue and prepare a webrev for it. Please note, that this patch is not intended to enable msys2 to actually run jdk build - msys2 environment is used only to start the build that uses cygwin. Some details on a relationship between msys, msysgit, msys2 and cygwin: https://stackoverflow.com/a/53572628/314015 diff --git a/make/autoconf/build-aux/autoconf-config.sub b/make/autoconf/build-aux/autoconf-config.sub index 1aab2b303..8c1d24db7 100644 --- a/make/autoconf/build-aux/autoconf-config.sub +++ b/make/autoconf/build-aux/autoconf-config.sub @@ -1274,7 +1274,7 @@ case $os in | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \ | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \ | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \ - | -chorusos* | -chorusrdb* \ + | -chorusos* | -chorusrdb* | -msys* \ | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \ | -mingw32* | -linux-gnu* | -linux-newlib* | -linux-uclibc* \ | -uxpv* | -beos* | -mpeix* | -udk* \ diff --git a/make/autoconf/platform.m4 b/make/autoconf/platform.m4 index 39134d121..ded491c64 100644 --- a/make/autoconf/platform.m4 +++ b/make/autoconf/platform.m4 @@ -192,6 +192,10 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_OS], VAR_OS=windows VAR_OS_ENV=windows.msys ;; + *msys*) + VAR_OS=windows + VAR_OS_ENV=windows.cygwin + ;; *aix*) VAR_OS=aix VAR_OS_TYPE=unix -- -Alex From erik.joelsson at oracle.com Mon May 20 15:24:55 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 20 May 2019 08:24:55 -0700 Subject: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: Build changes look good. /Erik On 2019-05-19 17:43, David Holmes wrote: > Hi Daniil, > > cc: Boris and Erik J. > > On 20/05/2019 7:12 am, Daniil Titov wrote: >> Please review the change that fixes the failure of >> sun/management/jmxremote/bootstrap JMX tests on Windows platform.? >> While running, these tests invoke revokeall.exe utility and this >> utility hangs. >> >> The problem here is that invokeall.exe goes into an endless loop? >> while iterating over Access Control Entries (ACE) for a given file if >> it encounters at least one ACE with the type different from >> ACCESS_ALLOWED_ACE_TYPE. >> >> The change fixes this problem.? It also removes revokeall.exe binary >> from the repository and changes the makefile? to get it built instead. >> >> Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap? >> tests succeeded? in Mach5. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8214545 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > > I knew this seemed very familiar ... Boris had a fix for this a few > weeks ago under JDK-8220581. Similar but not identical to yours - see > below. Though getting rid of the exe from the repo is a good idea > (thanks Erik!). > > A few comments > > test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > > Pre-existing: > > !???????? REVOKEALL="$TESTNATIVEPATH/revokeall.exe" > ????????? if [ ! -f "$REVOKEALL" ] ; then > > I would expect a -x test not -f. > > --- > > test/jdk/sun/management/windows/README > > The first copyright year should be 2004. > > ? 25 This directory contains the source and the binary version > > Delete "and the binary version". > > --- > > test/jdk/sun/management/windows/exerevokeall.c > > Pre-existing: > > ?31? * file - suitable for NT/2000/XP only. > > Please delete everything after "file". > > > ?355???????????? i++; > ?356???????????? count--; > > The count-- is obvious as it is the loop counter, but it is far from > clear to me that i++ is correct. I don't fully understand the logic > but i is only incremented under very specific conditions. If you > rewrote the code to avoid the use of the continue then i would not be > modified except where it currently is. > > Thanks, > David > ----- > >> Thanks! >> --Daniil >> >> From erik.joelsson at oracle.com Mon May 20 16:09:54 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 20 May 2019 09:09:54 -0700 Subject: RFR: docs/build JDK-8223663 Update links for tool guides In-Reply-To: <0761b63b-3a30-6647-ac83-dfbb0d635b64@oracle.com> References: <0761b63b-3a30-6647-ac83-dfbb0d635b64@oracle.com> Message-ID: Build change looks good. /Erik On 2019-05-17 17:16, Jonathan Gibbons wrote: > In JDK 13, the pages for the Tools Reference guides are moving, and so > the links from the API pages to these guides needs to be updated. > > Please review a two-part change. > > 1. A new taglet is introduced that can generates links from API pages > to pages in the sibling specs/man directory, which is the new home for > the pages known as "Tool Guides" a.k.a "man" pages. > > ??? The new taglet is used as follows:?? @toolGuide > ??? This generates a section in the specification similar to what was > generated before, although previously it was done in a more > complicated manner. > > ??? The taglet is placed in the build.tools package, alongside other > recent custom taglets. > > ??? make/Docs.gmk is updated to use the new taglet. > > > 2. All the references in the various module-info.java files to the old > "Tools Reference" pages are replaced with usages of the new taglet. > > ??? Although this is generally a case of replacing old references with > new references, there are some anomalies that had to be taken into > account. > > ??? a. There is not, and apparently never was, a Tools Reference page > for "jfr". The reference was 404. The link is removed for now, and can > be replaced if such a page becomes available. > > ??? b. Some of the links under the "Tools Reference" heading were to > pages that were not "man" pages, and which are not being migrated at > this time. These links are left alone, although it has meant > separating the two kinds of links into two separate lists, one for the > old-style links which remain, and one for the new "man" pages. > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223663 > Webrev: http://cr.openjdk.java.net/~jjg/8223663-toolguides/webrev.00/ > Sample docs: > http://cr.openjdk.java.net/~jjg/8223663-toolguides/docs/api/index.html > > > From erik.joelsson at oracle.com Mon May 20 16:15:49 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 20 May 2019 09:15:49 -0700 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: The updated webrev from Volker looks good to me. Thank you David for fixing this! /Erik On 2019-05-20 07:05, Volker Simonis wrote: > Hi David, > > thanks for considering AIX in your change. > > With OpenJDK 13 we've moved to XLC 16 which has a new Clang based > frontend. The "ucs" feature-suboption [1] you're using in your change > is only supported in the old, xlc compiler but not in the new xlclang > any more [2]. However, the good news is that the new xlclang now > supports the same "-std=gn99" option like gcc and clang, so you could > easily handle the xlc case now together with gcc and clang as shown in > this webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/2019/8224087/ > > Otherwise, your change looks good! > > Please let me know once you've pushed it. I opened "8224214: [AIX] > Remove support for legacy xlc compiler" [3] for further cleannups > because we still set some "-qlanglvl" options for C++ which aren't > supported by the new compiler either. > > Best regards, > Volker > > [1] https://www.ibm.com/support/knowledgecenter/SSGH3R_12.1.0/com.ibm.xlcpp121.aix.doc/compiler_ref/opt_langlvl.html > [2] https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_langlvl_aix.html > > > On Mon, May 20, 2019 at 9:40 AM David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 >> webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ >> >> The need to remove a for-loop declaration expression to appease gcc 4.8 >> annoyed me enough to investigate setting C99 as our minimum allow >> C-language level when compiling. It turned out to be a lot more complex >> a situation than I thought due to toolchain quirks. See lots of details >> in the bug report. >> >> To summarise the changes: >> - gcc: force to -std=gnu99 >> - clang force to -std=gnu99 >> - Solaris studio - no effective change >> - Visual Studio - no change >> - xlc - no effective change (but we use the explicit flag rather than >> accepting it as default) >> >> I've checked how this works with all the toolchains except xlc as I have >> no access to that. Some assistance from someone who can verify the >> correctness on xlc would be appreciated. >> >> Thanks, >> David From erik.joelsson at oracle.com Mon May 20 16:22:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 20 May 2019 09:22:48 -0700 Subject: [PATCH] msys2 detection in autoconf In-Reply-To: <0892e076-05ac-d484-57cd-0b59155a87f4@redhat.com> References: <0892e076-05ac-d484-57cd-0b59155a87f4@redhat.com> Message-ID: <1f680141-7af4-e5bf-7db0-995b2d675c25@oracle.com> Hello Alex, If you can come up with a change that does not touch any of the autoconf-* files, but instead the corresponding wrapper file, we can accept it. /Erik On 2019-05-20 07:29, Alex Kashchenko wrote: > Hi, > > We've got an unusual build scenario, when user has a jdk-windows build > setup with a pre-configured cygwin environment (and a batch script to > run the build), but want to start this build on a remote machine that > runs SSH server inside msys2 environment. > > In this scenario, with batch script started over msys2 SSH, autoconf > fails on OS detection, and the patch below (submitted by github user > quanah) is needed to fix that. > > If someone thinks that such change is a good idea - I can file a Jira > issue and prepare a webrev for it. > > Please note, that this patch is not intended to enable msys2 to > actually run jdk build - msys2 environment is used only to start the > build that uses cygwin. > > Some details on a relationship between msys, msysgit, msys2 and > cygwin: https://stackoverflow.com/a/53572628/314015 > > > diff --git a/make/autoconf/build-aux/autoconf-config.sub > b/make/autoconf/build-aux/autoconf-config.sub > index 1aab2b303..8c1d24db7 100644 > --- a/make/autoconf/build-aux/autoconf-config.sub > +++ b/make/autoconf/build-aux/autoconf-config.sub > @@ -1274,7 +1274,7 @@ case $os in > ????????????? | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \ > ????????????? | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \ > ????????????? | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \ > -???????????? | -chorusos* | -chorusrdb* \ > +???????????? | -chorusos* | -chorusrdb* | -msys* \ > ????????????? | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \ > ????????????? | -mingw32* | -linux-gnu* | -linux-newlib* | > -linux-uclibc* \ > ????????????? | -uxpv* | -beos* | -mpeix* | -udk* \ > diff --git a/make/autoconf/platform.m4 b/make/autoconf/platform.m4 > index 39134d121..ded491c64 100644 > --- a/make/autoconf/platform.m4 > +++ b/make/autoconf/platform.m4 > @@ -192,6 +192,10 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_OS], > ?????? VAR_OS=windows > ?????? VAR_OS_ENV=windows.msys > ?????? ;; > +??? *msys*) > +????? VAR_OS=windows > +????? VAR_OS_ENV=windows.cygwin > +????? ;; > ???? *aix*) > ?????? VAR_OS=aix > ?????? VAR_OS_TYPE=unix > > From Sergey.Bylokhov at oracle.com Mon May 20 18:15:21 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 May 2019 11:15:21 -0700 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: Hi, David. Should not the minimum version of c standard mentioned in the doc/building.html? On 20/05/2019 00:40, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 > webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ > > The need to remove a for-loop declaration expression to appease gcc 4.8 annoyed me enough to investigate setting C99 as our minimum allow C-language level when compiling. It turned out to be a lot more complex a situation than I thought due to toolchain quirks. See lots of details in the bug report. > > To summarise the changes: > - gcc: force to -std=gnu99 > - clang force to -std=gnu99 > - Solaris studio - no effective change > - Visual Studio - no change > - xlc - no effective change (but we use the explicit flag rather than accepting it as default) > > I've checked how this works with all the toolchains except xlc as I have no access to that. Some assistance from someone who can verify the correctness on xlc would be appreciated. > > Thanks, > David -- Best regards, Sergey. From volker.simonis at gmail.com Mon May 20 18:31:39 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 May 2019 20:31:39 +0200 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: Sergey Bylokhov schrieb am Mo. 20. Mai 2019 um 20:14: > Hi, David. > Should not the minimum version of c standard mentioned in the > doc/building.html? > We actually have a Wiki page for that because it?s much easier to maintain: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > On 20/05/2019 00:40, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 > > webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ > > > > The need to remove a for-loop declaration expression to appease gcc 4.8 > annoyed me enough to investigate setting C99 as our minimum allow > C-language level when compiling. It turned out to be a lot more complex a > situation than I thought due to toolchain quirks. See lots of details in > the bug report. > > > > To summarise the changes: > > - gcc: force to -std=gnu99 > > - clang force to -std=gnu99 > > - Solaris studio - no effective change > > - Visual Studio - no change > > - xlc - no effective change (but we use the explicit flag rather than > accepting it as default) > > > > I've checked how this works with all the toolchains except xlc as I have > no access to that. Some assistance from someone who can verify the > correctness on xlc would be appreciated. > > > > Thanks, > > David > > > -- > Best regards, Sergey. > From akashche at redhat.com Mon May 20 19:39:33 2019 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 20 May 2019 20:39:33 +0100 Subject: [PATCH] msys2 detection in autoconf In-Reply-To: <1f680141-7af4-e5bf-7db0-995b2d675c25@oracle.com> References: <0892e076-05ac-d484-57cd-0b59155a87f4@redhat.com> <1f680141-7af4-e5bf-7db0-995b2d675c25@oracle.com> Message-ID: <5be96af0-ff87-e2f5-51c4-596cafa78ebe@redhat.com> On 05/20/2019 05:22 PM, Erik Joelsson wrote: > Hello Alex, > > If you can come up with a change that does not touch any of the > autoconf-* files, but instead the corresponding wrapper file, we can > accept it. Thanks! I notified original patch author who may (or may not) want to continue with it. I can assist with uploading the patch and testing the change, but generally don't want to own it because we don't use msys2 for Red Hat jdk-windows builds. > > /Erik > > On 2019-05-20 07:29, Alex Kashchenko wrote: >> Hi, >> >> We've got an unusual build scenario, when user has a jdk-windows build >> setup with a pre-configured cygwin environment (and a batch script to >> run the build), but want to start this build on a remote machine that >> runs SSH server inside msys2 environment. >> >> In this scenario, with batch script started over msys2 SSH, autoconf >> fails on OS detection, and the patch below (submitted by github user >> quanah) is needed to fix that. >> >> If someone thinks that such change is a good idea - I can file a Jira >> issue and prepare a webrev for it. >> >> Please note, that this patch is not intended to enable msys2 to >> actually run jdk build - msys2 environment is used only to start the >> build that uses cygwin. >> >> Some details on a relationship between msys, msysgit, msys2 and >> cygwin: https://stackoverflow.com/a/53572628/314015 >> >> >> diff --git a/make/autoconf/build-aux/autoconf-config.sub >> b/make/autoconf/build-aux/autoconf-config.sub >> index 1aab2b303..8c1d24db7 100644 >> --- a/make/autoconf/build-aux/autoconf-config.sub >> +++ b/make/autoconf/build-aux/autoconf-config.sub >> @@ -1274,7 +1274,7 @@ case $os in >> ????????????? | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \ >> ????????????? | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \ >> ????????????? | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \ >> -???????????? | -chorusos* | -chorusrdb* \ >> +???????????? | -chorusos* | -chorusrdb* | -msys* \ >> ????????????? | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \ >> ????????????? | -mingw32* | -linux-gnu* | -linux-newlib* | >> -linux-uclibc* \ >> ????????????? | -uxpv* | -beos* | -mpeix* | -udk* \ >> diff --git a/make/autoconf/platform.m4 b/make/autoconf/platform.m4 >> index 39134d121..ded491c64 100644 >> --- a/make/autoconf/platform.m4 >> +++ b/make/autoconf/platform.m4 >> @@ -192,6 +192,10 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_OS], >> ?????? VAR_OS=windows >> ?????? VAR_OS_ENV=windows.msys >> ?????? ;; >> +??? *msys*) >> +????? VAR_OS=windows >> +????? VAR_OS_ENV=windows.cygwin >> +????? ;; >> ???? *aix*) >> ?????? VAR_OS=aix >> ?????? VAR_OS_TYPE=unix >> >> -- -Alex From jonathan.gibbons at oracle.com Mon May 20 19:45:49 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 20 May 2019 12:45:49 -0700 Subject: RFR: docs/build: JDK-8224166: Create a taglet to better handle @jls and @jvms tags Message-ID: Please review a small change to add support for new taglets to handle the @jls and @jvms tags found in our API docs. Previously, these tags were just handled with simple javadoc command-line options to echo their contents.? Now, the section number is found in the contents, and a link to the standard location for the full appropriate online spec is generated. Note that the links anticipate the publication of the updated versions of these specs in the standard location, and will be 404 until the versions are available, at GA time.? If you want to preview/play with the links, you can tweak the version number use in Docs.gmk, line 278. It defaults to the current $$(VERSION_SPECIFICATION), meaning that it will be updated automatically as we move forward to new versions. The code for handling @jls and @jvms is sufficiently similar that they are implemented as nested classes within a single common supertype.?? Of note is that the taglets do support the use of {@code} within the text. ... Separately, you may have noticed some cleanup changesets to standardize the use of these tags. Although those changes are related to this work, it is _not_ a requirement that the standard form is used.? The section number is extracted in the taglet with a fairly tolerant regex. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8224166 Webrev: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/webrev.00/ API: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/docs/api/index.html From erik.joelsson at oracle.com Mon May 20 20:05:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 20 May 2019 13:05:17 -0700 Subject: RFR: docs/build: JDK-8224166: Create a taglet to better handle @jls and @jvms tags In-Reply-To: References: Message-ID: <04128131-c69e-683c-ab27-4967dd4f7100@oracle.com> Build changes look good. /Erik On 2019-05-20 12:45, Jonathan Gibbons wrote: > Please review a small change to add support for new taglets to handle > the @jls and @jvms tags found in our API docs. > > Previously, these tags were just handled with simple javadoc > command-line options to echo their contents.? Now, the section number > is found in the contents, and a link to the standard location for the > full appropriate online spec is generated. > > Note that the links anticipate the publication of the updated versions > of these specs in the standard location, and will be 404 until the > versions are available, at GA time.? If you want to preview/play with > the links, you can tweak the version number use in Docs.gmk, line 278. > It defaults to the current $$(VERSION_SPECIFICATION), meaning that it > will be updated automatically as we move forward to new versions. > > The code for handling @jls and @jvms is sufficiently similar that they > are implemented as nested classes within a single common supertype.?? > Of note is that the taglets do support the use of {@code} within the > text. > > ... > > Separately, you may have noticed some cleanup changesets to > standardize the use of these tags. Although those changes are related > to this work, it is _not_ a requirement that the standard form is > used.? The section number is extracted in the taglet with a fairly > tolerant regex. > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224166 > Webrev: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/webrev.00/ > API: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/docs/api/index.html > > > From jonathan.gibbons at oracle.com Mon May 20 20:43:01 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 20 May 2019 13:43:01 -0700 Subject: RFR: docs/build: JDK-8224166: Create a taglet to better handle @jls and @jvms tags In-Reply-To: References: Message-ID: Joe notes some unbalanced parentheses in the doc-comment for the new JSpec taglet: I will change the doc comment to read: /** ?* A base class for block tags to insert a link to an external copy of JLS or JVMS. ?* The tags can be used as follows: ?* @jls section-number description, for example ?*

?* @jls 3.4 Line Terminators ?*

?* will produce the following html ?*

?* {@code ?*

See Java Language Specification: ?*
3.4 Line terminators ?* } ?* ?* The version of the spec must be set in the jspec.version system property. ?*/ This removes a couple of excess '}' characters, and replaces the unmemorable @ with the equivalent and slightly more readable named entity, @ -- Jon On 05/20/2019 12:45 PM, Jonathan Gibbons wrote: > Please review a small change to add support for new taglets to handle > the @jls and @jvms tags found in our API docs. > > Previously, these tags were just handled with simple javadoc > command-line options to echo their contents.? Now, the section number > is found in the contents, and a link to the standard location for the > full appropriate online spec is generated. > > Note that the links anticipate the publication of the updated versions > of these specs in the standard location, and will be 404 until the > versions are available, at GA time.? If you want to preview/play with > the links, you can tweak the version number use in Docs.gmk, line 278. > It defaults to the current $$(VERSION_SPECIFICATION), meaning that it > will be updated automatically as we move forward to new versions. > > The code for handling @jls and @jvms is sufficiently similar that they > are implemented as nested classes within a single common supertype.?? > Of note is that the taglets do support the use of {@code} within the > text. > > ... > > Separately, you may have noticed some cleanup changesets to > standardize the use of these tags. Although those changes are related > to this work, it is _not_ a requirement that the standard form is > used.? The section number is extracted in the taglet with a fairly > tolerant regex. > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224166 > Webrev: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/webrev.00/ > API: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/docs/api/index.html > > > From david.holmes at oracle.com Mon May 20 22:31:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2019 08:31:23 +1000 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: Hi Volker, Thanks for the xlc update - I will incorporate that. It has been suggested that we actually set c99 rather than gnu99 to avoid any GNU extensions creeping in. Does anyone have any concerns with doing that? Thanks, David On 21/05/2019 12:05 am, Volker Simonis wrote: > Hi David, > > thanks for considering AIX in your change. > > With OpenJDK 13 we've moved to XLC 16 which has a new Clang based > frontend. The "ucs" feature-suboption [1] you're using in your change > is only supported in the old, xlc compiler but not in the new xlclang > any more [2]. However, the good news is that the new xlclang now > supports the same "-std=gn99" option like gcc and clang, so you could > easily handle the xlc case now together with gcc and clang as shown in > this webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/2019/8224087/ > > Otherwise, your change looks good! > > Please let me know once you've pushed it. I opened "8224214: [AIX] > Remove support for legacy xlc compiler" [3] for further cleannups > because we still set some "-qlanglvl" options for C++ which aren't > supported by the new compiler either. > > Best regards, > Volker > > [1] https://www.ibm.com/support/knowledgecenter/SSGH3R_12.1.0/com.ibm.xlcpp121.aix.doc/compiler_ref/opt_langlvl.html > [2] https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_langlvl_aix.html > > > On Mon, May 20, 2019 at 9:40 AM David Holmes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 >> webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ >> >> The need to remove a for-loop declaration expression to appease gcc 4.8 >> annoyed me enough to investigate setting C99 as our minimum allow >> C-language level when compiling. It turned out to be a lot more complex >> a situation than I thought due to toolchain quirks. See lots of details >> in the bug report. >> >> To summarise the changes: >> - gcc: force to -std=gnu99 >> - clang force to -std=gnu99 >> - Solaris studio - no effective change >> - Visual Studio - no change >> - xlc - no effective change (but we use the explicit flag rather than >> accepting it as default) >> >> I've checked how this works with all the toolchains except xlc as I have >> no access to that. Some assistance from someone who can verify the >> correctness on xlc would be appreciated. >> >> Thanks, >> David From erik.joelsson at oracle.com Mon May 20 22:40:18 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 20 May 2019 15:40:18 -0700 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: That sounds good to me. I missed that distinction before, but pure c99 does sound better. /Erik On 2019-05-20 15:31, David Holmes wrote: > Hi Volker, > > Thanks for the xlc update - I will incorporate that. > > It has been suggested that we actually set c99 rather than gnu99 to > avoid any GNU extensions creeping in. Does anyone have any concerns > with doing that? > > Thanks, > David > > On 21/05/2019 12:05 am, Volker Simonis wrote: >> Hi David, >> >> thanks for considering AIX in your change. >> >> With OpenJDK 13 we've moved to XLC 16 which has a new Clang based >> frontend. The "ucs" feature-suboption [1] you're using in your change >> is only supported in the old, xlc compiler but not in the new xlclang >> any more [2]. However, the good news is that the new xlclang now >> supports the same "-std=gn99" option like gcc and clang, so you could >> easily handle the xlc case now together with gcc and clang as shown in >> this webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2019/8224087/ >> >> Otherwise, your change looks good! >> >> Please let me know once you've pushed it. I opened "8224214: [AIX] >> Remove support for legacy xlc compiler" [3] for further cleannups >> because we still set some "-qlanglvl" options for C++ which aren't >> supported by the new compiler either. >> >> Best regards, >> Volker >> >> [1] >> https://www.ibm.com/support/knowledgecenter/SSGH3R_12.1.0/com.ibm.xlcpp121.aix.doc/compiler_ref/opt_langlvl.html >> [2] >> https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_langlvl_aix.html >> >> >> On Mon, May 20, 2019 at 9:40 AM David Holmes >> wrote: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 >>> webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ >>> >>> The need to remove a for-loop declaration expression to appease gcc 4.8 >>> annoyed me enough to investigate setting C99 as our minimum allow >>> C-language level when compiling. It turned out to be a lot more complex >>> a situation than I thought due to toolchain quirks. See lots of details >>> in the bug report. >>> >>> To summarise the changes: >>> - gcc: force to -std=gnu99 >>> - clang force to -std=gnu99 >>> - Solaris studio - no effective change >>> - Visual Studio - no change >>> - xlc - no effective change (but we use the explicit flag rather than >>> accepting it as default) >>> >>> I've checked how this works with all the toolchains except xlc as I >>> have >>> no access to that. Some assistance from someone who can verify the >>> correctness on xlc would be appreciated. >>> >>> Thanks, >>> David From dean.long at oracle.com Mon May 20 22:49:12 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 20 May 2019 15:49:12 -0700 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: <27dac288-33b0-e425-7d9b-3d3ae7d3e20c@oracle.com> Isn't that going to break inline asm? dl On 5/20/19 3:40 PM, Erik Joelsson wrote: > That sounds good to me. I missed that distinction before, but pure c99 > does sound better. > > /Erik > > On 2019-05-20 15:31, David Holmes wrote: >> Hi Volker, >> >> Thanks for the xlc update - I will incorporate that. >> >> It has been suggested that we actually set c99 rather than gnu99 to >> avoid any GNU extensions creeping in. Does anyone have any concerns >> with doing that? >> >> Thanks, >> David >> >> On 21/05/2019 12:05 am, Volker Simonis wrote: >>> Hi David, >>> >>> thanks for considering AIX in your change. >>> >>> With OpenJDK 13 we've moved to XLC 16 which has a new Clang based >>> frontend. The "ucs" feature-suboption [1] you're using in your change >>> is only supported in the old, xlc compiler but not in the new xlclang >>> any more [2]. However, the good news is that the new xlclang now >>> supports the same "-std=gn99" option like gcc and clang, so you could >>> easily handle the xlc case now together with gcc and clang as shown in >>> this webrev: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8224087/ >>> >>> Otherwise, your change looks good! >>> >>> Please let me know once you've pushed it. I opened "8224214: [AIX] >>> Remove support for legacy xlc compiler" [3] for further cleannups >>> because we still set some "-qlanglvl" options for C++ which aren't >>> supported by the new compiler either. >>> >>> Best regards, >>> Volker >>> >>> [1] >>> https://www.ibm.com/support/knowledgecenter/SSGH3R_12.1.0/com.ibm.xlcpp121.aix.doc/compiler_ref/opt_langlvl.html >>> [2] >>> https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_langlvl_aix.html >>> >>> >>> On Mon, May 20, 2019 at 9:40 AM David Holmes >>> wrote: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ >>>> >>>> The need to remove a for-loop declaration expression to appease gcc >>>> 4.8 >>>> annoyed me enough to investigate setting C99 as our minimum allow >>>> C-language level when compiling. It turned out to be a lot more >>>> complex >>>> a situation than I thought due to toolchain quirks. See lots of >>>> details >>>> in the bug report. >>>> >>>> To summarise the changes: >>>> - gcc: force to -std=gnu99 >>>> - clang force to -std=gnu99 >>>> - Solaris studio - no effective change >>>> - Visual Studio - no change >>>> - xlc - no effective change (but we use the explicit flag rather than >>>> accepting it as default) >>>> >>>> I've checked how this works with all the toolchains except xlc as I >>>> have >>>> no access to that. Some assistance from someone who can verify the >>>> correctness on xlc would be appreciated. >>>> >>>> Thanks, >>>> David From david.holmes at oracle.com Mon May 20 22:59:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2019 08:59:50 +1000 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: <27dac288-33b0-e425-7d9b-3d3ae7d3e20c@oracle.com> References: <27dac288-33b0-e425-7d9b-3d3ae7d3e20c@oracle.com> Message-ID: <84706e06-c652-0295-7f3d-343c37262f3b@oracle.com> On 21/05/2019 8:49 am, dean.long at oracle.com wrote: > Isn't that going to break inline asm? It doesn't appear to. I'll check what the docs say about such things. Thanks for flagging it. David ----- > dl > > On 5/20/19 3:40 PM, Erik Joelsson wrote: >> That sounds good to me. I missed that distinction before, but pure c99 >> does sound better. >> >> /Erik >> >> On 2019-05-20 15:31, David Holmes wrote: >>> Hi Volker, >>> >>> Thanks for the xlc update - I will incorporate that. >>> >>> It has been suggested that we actually set c99 rather than gnu99 to >>> avoid any GNU extensions creeping in. Does anyone have any concerns >>> with doing that? >>> >>> Thanks, >>> David >>> >>> On 21/05/2019 12:05 am, Volker Simonis wrote: >>>> Hi David, >>>> >>>> thanks for considering AIX in your change. >>>> >>>> With OpenJDK 13 we've moved to XLC 16 which has a new Clang based >>>> frontend. The "ucs" feature-suboption [1] you're using in your change >>>> is only supported in the old, xlc compiler but not in the new xlclang >>>> any more [2]. However, the good news is that the new xlclang now >>>> supports the same "-std=gn99" option like gcc and clang, so you could >>>> easily handle the xlc case now together with gcc and clang as shown in >>>> this webrev: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8224087/ >>>> >>>> Otherwise, your change looks good! >>>> >>>> Please let me know once you've pushed it. I opened "8224214: [AIX] >>>> Remove support for legacy xlc compiler" [3] for further cleannups >>>> because we still set some "-qlanglvl" options for C++ which aren't >>>> supported by the new compiler either. >>>> >>>> Best regards, >>>> Volker >>>> >>>> [1] >>>> https://www.ibm.com/support/knowledgecenter/SSGH3R_12.1.0/com.ibm.xlcpp121.aix.doc/compiler_ref/opt_langlvl.html >>>> >>>> [2] >>>> https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_langlvl_aix.html >>>> >>>> >>>> >>>> On Mon, May 20, 2019 at 9:40 AM David Holmes >>>> wrote: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ >>>>> >>>>> The need to remove a for-loop declaration expression to appease gcc >>>>> 4.8 >>>>> annoyed me enough to investigate setting C99 as our minimum allow >>>>> C-language level when compiling. It turned out to be a lot more >>>>> complex >>>>> a situation than I thought due to toolchain quirks. See lots of >>>>> details >>>>> in the bug report. >>>>> >>>>> To summarise the changes: >>>>> - gcc: force to -std=gnu99 >>>>> - clang force to -std=gnu99 >>>>> - Solaris studio - no effective change >>>>> - Visual Studio - no change >>>>> - xlc - no effective change (but we use the explicit flag rather than >>>>> accepting it as default) >>>>> >>>>> I've checked how this works with all the toolchains except xlc as I >>>>> have >>>>> no access to that. Some assistance from someone who can verify the >>>>> correctness on xlc would be appreciated. >>>>> >>>>> Thanks, >>>>> David > From david.holmes at oracle.com Mon May 20 23:18:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2019 09:18:10 +1000 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: <84706e06-c652-0295-7f3d-343c37262f3b@oracle.com> References: <27dac288-33b0-e425-7d9b-3d3ae7d3e20c@oracle.com> <84706e06-c652-0295-7f3d-343c37262f3b@oracle.com> Message-ID: Hi Dean, On 21/05/2019 8:59 am, David Holmes wrote: > On 21/05/2019 8:49 am, dean.long at oracle.com wrote: >> Isn't that going to break inline asm? > > It doesn't appear to. I'll check what the docs say about such things. Using c99 means we have to use __asm__ for inline-assembly rather than "asm" which is the GNU extension. Looking at our sources we only use inline assembly in C code in two places. The main use is in ./jdk.crypto.ec/share/native/libsunec/impl/ecl*.c which do use the C99 __asm__ form. There is one potential problematic usage in: ./jdk.crypto.ec/share/native/libsunec/impl/mpi.c but that is ifdef'd on OSF1 which I'm assuming is not enabled in our builds anyway. The other use is ./java.desktop/share/native/libfreetype/src/truetype/ttinterp.c which is also using the C99 form. So everything looks fine in that regard. Thanks again for flagging it. David ----- > Thanks for flagging it. > > David > ----- > >> dl >> >> On 5/20/19 3:40 PM, Erik Joelsson wrote: >>> That sounds good to me. I missed that distinction before, but pure >>> c99 does sound better. >>> >>> /Erik >>> >>> On 2019-05-20 15:31, David Holmes wrote: >>>> Hi Volker, >>>> >>>> Thanks for the xlc update - I will incorporate that. >>>> >>>> It has been suggested that we actually set c99 rather than gnu99 to >>>> avoid any GNU extensions creeping in. Does anyone have any concerns >>>> with doing that? >>>> >>>> Thanks, >>>> David >>>> >>>> On 21/05/2019 12:05 am, Volker Simonis wrote: >>>>> Hi David, >>>>> >>>>> thanks for considering AIX in your change. >>>>> >>>>> With OpenJDK 13 we've moved to XLC 16 which has a new Clang based >>>>> frontend. The "ucs" feature-suboption [1] you're using in your change >>>>> is only supported in the old, xlc compiler but not in the new xlclang >>>>> any more [2]. However, the good news is that the new xlclang now >>>>> supports the same "-std=gn99" option like gcc and clang, so you could >>>>> easily handle the xlc case now together with gcc and clang as shown in >>>>> this webrev: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8224087/ >>>>> >>>>> Otherwise, your change looks good! >>>>> >>>>> Please let me know once you've pushed it. I opened "8224214: [AIX] >>>>> Remove support for legacy xlc compiler" [3] for further cleannups >>>>> because we still set some "-qlanglvl" options for C++ which aren't >>>>> supported by the new compiler either. >>>>> >>>>> Best regards, >>>>> Volker >>>>> >>>>> [1] >>>>> https://www.ibm.com/support/knowledgecenter/SSGH3R_12.1.0/com.ibm.xlcpp121.aix.doc/compiler_ref/opt_langlvl.html >>>>> >>>>> [2] >>>>> https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_langlvl_aix.html >>>>> >>>>> >>>>> >>>>> On Mon, May 20, 2019 at 9:40 AM David Holmes >>>>> wrote: >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 >>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ >>>>>> >>>>>> The need to remove a for-loop declaration expression to appease >>>>>> gcc 4.8 >>>>>> annoyed me enough to investigate setting C99 as our minimum allow >>>>>> C-language level when compiling. It turned out to be a lot more >>>>>> complex >>>>>> a situation than I thought due to toolchain quirks. See lots of >>>>>> details >>>>>> in the bug report. >>>>>> >>>>>> To summarise the changes: >>>>>> - gcc: force to -std=gnu99 >>>>>> - clang force to -std=gnu99 >>>>>> - Solaris studio - no effective change >>>>>> - Visual Studio - no change >>>>>> - xlc - no effective change (but we use the explicit flag rather than >>>>>> accepting it as default) >>>>>> >>>>>> I've checked how this works with all the toolchains except xlc as >>>>>> I have >>>>>> no access to that. Some assistance from someone who can verify the >>>>>> correctness on xlc would be appreciated. >>>>>> >>>>>> Thanks, >>>>>> David >> From jonathan.gibbons at oracle.com Mon May 20 23:51:39 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 20 May 2019 16:51:39 -0700 Subject: RFR: docs/build: JDK-8224166: Create a taglet to better handle @jls and @jvms tags In-Reply-To: References: Message-ID: <601d4611-9852-8e3a-821e-0f24b536d27a@oracle.com> Here is the updated webrev with the comment changes. Webrev: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/webrev.01/ -- Jon On 05/20/2019 01:43 PM, Jonathan Gibbons wrote: > Joe notes some unbalanced parentheses in the doc-comment for the new > JSpec taglet: > > I will change the doc comment to read: > > /** > ?* A base class for block tags to insert a link to an external copy of > JLS or JVMS. > ?* The tags can be used as follows: > ?* @jls section-number description, for example > ?*

> ?* @jls 3.4 Line Terminators > ?*

> ?* will produce the following html > ?*

> ?* {@code > ?*

See Java Language Specification: > ?*
href="https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.4">3.4 > Line terminators > ?* } > ?* > ?* The version of the spec must be set in the jspec.version system > property. > ?*/ > > This removes a couple of excess '}' characters, and replaces the > unmemorable @ with the equivalent and slightly more readable named > entity, @ > > -- Jon > > On 05/20/2019 12:45 PM, Jonathan Gibbons wrote: >> Please review a small change to add support for new taglets to handle >> the @jls and @jvms tags found in our API docs. >> >> Previously, these tags were just handled with simple javadoc >> command-line options to echo their contents.? Now, the section number >> is found in the contents, and a link to the standard location for the >> full appropriate online spec is generated. >> >> Note that the links anticipate the publication of the updated >> versions of these specs in the standard location, and will be 404 >> until the versions are available, at GA time.? If you want to >> preview/play with the links, you can tweak the version number use in >> Docs.gmk, line 278. It defaults to the current >> $$(VERSION_SPECIFICATION), meaning that it will be updated >> automatically as we move forward to new versions. >> >> The code for handling @jls and @jvms is sufficiently similar that >> they are implemented as nested classes within a single common >> supertype.?? Of note is that the taglets do support the use of >> {@code} within the text. >> >> ... >> >> Separately, you may have noticed some cleanup changesets to >> standardize the use of these tags. Although those changes are related >> to this work, it is _not_ a requirement that the standard form is >> used.? The section number is extracted in the taglet with a fairly >> tolerant regex. >> >> -- Jon >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8224166 >> Webrev: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/webrev.00/ >> API: >> http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/docs/api/index.html >> >> >> > From joe.darcy at oracle.com Tue May 21 00:38:56 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 20 May 2019 17:38:56 -0700 Subject: RFR: docs/build: JDK-8224166: Create a taglet to better handle @jls and @jvms tags In-Reply-To: <601d4611-9852-8e3a-821e-0f24b536d27a@oracle.com> References: <601d4611-9852-8e3a-821e-0f24b536d27a@oracle.com> Message-ID: Hi Jon, Minor suggestions for the javadoc, but otherwise good to push: in > 45 * The tags can be used as follows: > 46 * @jls section-number description, for example > 47 *

I suggest having "* @jls section-number description" on its own line to emphasize this is a block tag rather than an inline tag. and for > 50 * will produce the following html > 51 *

> 52 * {@code > 53 *

See Java Language Specification: > 54 *
3.4 Line terminators > 55 * } change line 50 to state "will produce the following html for a docs build configured for Java SE 12." Thanks, -Joe On 5/20/2019 4:51 PM, Jonathan Gibbons wrote: > Here is the updated webrev with the comment changes. > > Webrev: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/webrev.01/ > > -- Jon > > > On 05/20/2019 01:43 PM, Jonathan Gibbons wrote: >> Joe notes some unbalanced parentheses in the doc-comment for the new >> JSpec taglet: >> >> I will change the doc comment to read: >> >> /** >> ?* A base class for block tags to insert a link to an external copy >> of JLS or JVMS. >> ?* The tags can be used as follows: >> ?* @jls section-number description, for example >> ?*

>> ?* @jls 3.4 Line Terminators >> ?*

>> ?* will produce the following html >> ?*

>> ?* {@code >> ?*

See Java Language Specification: >> ?*
> href="https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.4">3.4 >> Line terminators >> ?* } >> ?* >> ?* The version of the spec must be set in the jspec.version system >> property. >> ?*/ >> >> This removes a couple of excess '}' characters, and replaces the >> unmemorable @ with the equivalent and slightly more readable >> named entity, @ >> >> -- Jon >> >> On 05/20/2019 12:45 PM, Jonathan Gibbons wrote: >>> Please review a small change to add support for new taglets to >>> handle the @jls and @jvms tags found in our API docs. >>> >>> Previously, these tags were just handled with simple javadoc >>> command-line options to echo their contents.? Now, the section >>> number is found in the contents, and a link to the standard location >>> for the full appropriate online spec is generated. >>> >>> Note that the links anticipate the publication of the updated >>> versions of these specs in the standard location, and will be 404 >>> until the versions are available, at GA time.? If you want to >>> preview/play with the links, you can tweak the version number use in >>> Docs.gmk, line 278. It defaults to the current >>> $$(VERSION_SPECIFICATION), meaning that it will be updated >>> automatically as we move forward to new versions. >>> >>> The code for handling @jls and @jvms is sufficiently similar that >>> they are implemented as nested classes within a single common >>> supertype.?? Of note is that the taglets do support the use of >>> {@code} within the text. >>> >>> ... >>> >>> Separately, you may have noticed some cleanup changesets to >>> standardize the use of these tags. Although those changes are >>> related to this work, it is _not_ a requirement that the standard >>> form is used.? The section number is extracted in the taglet with a >>> fairly tolerant regex. >>> >>> -- Jon >>> >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224166 >>> Webrev: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/webrev.00/ >>> API: >>> http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/docs/api/index.html >>> >>> >>> >> > From david.holmes at oracle.com Tue May 21 00:56:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2019 10:56:12 +1000 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: <3b4c973b-5cba-fcd0-c1eb-e408590c494d@oracle.com> Thank you everyone for taking a look at this. Here is version 2: http://cr.openjdk.java.net/~dholmes/8224087/webrev.v2/ Changes: - set c99 rather than gnu99 - Volker's change for xlc to match gcc and clang - added short note to build doc (can do wiki later) - cosmetic change of name to make variable based on other feedback during the C++14 discussion Thanks, David On 20/05/2019 5:40 pm, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 > webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ > > The need to remove a for-loop declaration expression to appease gcc 4.8 > annoyed me enough to investigate setting C99 as our minimum allow > C-language level when compiling. It turned out to be a lot more complex > a situation than I thought due to toolchain quirks. See lots of details > in the bug report. > > To summarise the changes: > - gcc: force to -std=gnu99 > - clang force to -std=gnu99 > - Solaris studio - no effective change > - Visual Studio - no change > - xlc - no effective change (but we use the explicit flag rather than > accepting it as default) > > I've checked how this works with all the toolchains except xlc as I have > no access to that. Some assistance from someone who can verify the > correctness on xlc would be appreciated. > > Thanks, > David From jonathan.gibbons at oracle.com Tue May 21 01:16:43 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 20 May 2019 18:16:43 -0700 Subject: RFR: docs/build: JDK-8224166: Create a taglet to better handle @jls and @jvms tags In-Reply-To: References: <601d4611-9852-8e3a-821e-0f24b536d27a@oracle.com> Message-ID: Joe, Thanks. Suggestions noted; will address them and push. -- Jon On 5/20/19 5:38 PM, Joe Darcy wrote: > > Hi Jon, > > Minor suggestions for the javadoc, but otherwise good to push: in > >> 45 * The tags can be used as follows: >> 46 * @jls section-number description, for example >> 47 *

> I suggest having "* @jls section-number description" on its own > line to emphasize this is a block tag rather than an inline tag. and for > >> 50 * will produce the following html >> 51 *

>> 52 * {@code >> 53 *

See Java Language Specification: >> 54 *
3.4 Line terminators >> 55 * } > > change line 50 to state "will produce the following html for a docs > build configured for Java SE 12." > > Thanks, > > -Joe > > On 5/20/2019 4:51 PM, Jonathan Gibbons wrote: >> Here is the updated webrev with the comment changes. >> >> Webrev: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/webrev.01/ >> >> -- Jon >> >> >> On 05/20/2019 01:43 PM, Jonathan Gibbons wrote: >>> Joe notes some unbalanced parentheses in the doc-comment for the new >>> JSpec taglet: >>> >>> I will change the doc comment to read: >>> >>> /** >>> ?* A base class for block tags to insert a link to an external copy >>> of JLS or JVMS. >>> ?* The tags can be used as follows: >>> ?* @jls section-number description, for example >>> ?*

>>> ?* @jls 3.4 Line Terminators >>> ?*

>>> ?* will produce the following html >>> ?*

>>> ?* {@code >>> ?*

See Java Language Specification: >>> ?*
>> href="https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.4">3.4 >>> Line terminators >>> ?* } >>> ?* >>> ?* The version of the spec must be set in the jspec.version system >>> property. >>> ?*/ >>> >>> This removes a couple of excess '}' characters, and replaces the >>> unmemorable @ with the equivalent and slightly more readable >>> named entity, @ >>> >>> -- Jon >>> >>> On 05/20/2019 12:45 PM, Jonathan Gibbons wrote: >>>> Please review a small change to add support for new taglets to >>>> handle the @jls and @jvms tags found in our API docs. >>>> >>>> Previously, these tags were just handled with simple javadoc >>>> command-line options to echo their contents.? Now, the section >>>> number is found in the contents, and a link to the standard >>>> location for the full appropriate online spec is generated. >>>> >>>> Note that the links anticipate the publication of the updated >>>> versions of these specs in the standard location, and will be 404 >>>> until the versions are available, at GA time.? If you want to >>>> preview/play with the links, you can tweak the version number use >>>> in Docs.gmk, line 278. It defaults to the current >>>> $$(VERSION_SPECIFICATION), meaning that it will be updated >>>> automatically as we move forward to new versions. >>>> >>>> The code for handling @jls and @jvms is sufficiently similar that >>>> they are implemented as nested classes within a single common >>>> supertype.?? Of note is that the taglets do support the use of >>>> {@code} within the text. >>>> >>>> ... >>>> >>>> Separately, you may have noticed some cleanup changesets to >>>> standardize the use of these tags. Although those changes are >>>> related to this work, it is _not_ a requirement that the standard >>>> form is used.? The section number is extracted in the taglet with a >>>> fairly tolerant regex. >>>> >>>> -- Jon >>>> >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224166 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/webrev.00/ >>>> API: >>>> http://cr.openjdk.java.net/~jjg/8224166-jls-jvms/docs/api/index.html >>>> >>>> >>>> >>> >> From thomas.stuefe at gmail.com Tue May 21 03:45:41 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 05:45:41 +0200 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: <3b4c973b-5cba-fcd0-c1eb-e408590c494d@oracle.com> References: <3b4c973b-5cba-fcd0-c1eb-e408590c494d@oracle.com> Message-ID: Hi David, Thank you for doing this, this looks all very good. I wish though we had a clear whitelist of features to use or blacklist for features to avoid. Most developers do not use Windows as a primary platform, so it will always be a surprise whether Windows breaks in submit tests. I am also (a bit) concerned about C99 features creeping in which would prevent verbatim backporting of patches to older releases. But let?s see if that is really a problem in practice. Thanks, Thomas On Tue 21. May 2019 at 02:58, David Holmes wrote: > Thank you everyone for taking a look at this. > > Here is version 2: > > http://cr.openjdk.java.net/~dholmes/8224087/webrev.v2/ > > Changes: > - set c99 rather than gnu99 > - Volker's change for xlc to match gcc and clang > - added short note to build doc (can do wiki later) > - cosmetic change of name to make variable based on other feedback > during the C++14 discussion > > Thanks, > David > > On 20/05/2019 5:40 pm, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 > > webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ > > > > The need to remove a for-loop declaration expression to appease gcc 4.8 > > annoyed me enough to investigate setting C99 as our minimum allow > > C-language level when compiling. It turned out to be a lot more complex > > a situation than I thought due to toolchain quirks. See lots of details > > in the bug report. > > > > To summarise the changes: > > - gcc: force to -std=gnu99 > > - clang force to -std=gnu99 > > - Solaris studio - no effective change > > - Visual Studio - no change > > - xlc - no effective change (but we use the explicit flag rather than > > accepting it as default) > > > > I've checked how this works with all the toolchains except xlc as I have > > no access to that. Some assistance from someone who can verify the > > correctness on xlc would be appreciated. > > > > Thanks, > > David > From erik.joelsson at oracle.com Tue May 21 13:49:05 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 May 2019 06:49:05 -0700 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: <3b4c973b-5cba-fcd0-c1eb-e408590c494d@oracle.com> References: <3b4c973b-5cba-fcd0-c1eb-e408590c494d@oracle.com> Message-ID: Looks even better! /Erik On 2019-05-20 17:56, David Holmes wrote: > Thank you everyone for taking a look at this. > > Here is version 2: > > http://cr.openjdk.java.net/~dholmes/8224087/webrev.v2/ > > Changes: > - set c99 rather than gnu99 > - Volker's change for xlc to match gcc and clang > - added short note to build doc (can do wiki later) > - cosmetic change of name to make variable based on other feedback > during the C++14 discussion > > Thanks, > David > > On 20/05/2019 5:40 pm, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 >> webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ >> >> The need to remove a for-loop declaration expression to appease gcc >> 4.8 annoyed me enough to investigate setting C99 as our minimum allow >> C-language level when compiling. It turned out to be a lot more >> complex a situation than I thought due to toolchain quirks. See lots >> of details in the bug report. >> >> To summarise the changes: >> - gcc: force to -std=gnu99 >> - clang force to -std=gnu99 >> - Solaris studio - no effective change >> - Visual Studio - no change >> - xlc - no effective change (but we use the explicit flag rather than >> accepting it as default) >> >> I've checked how this works with all the toolchains except xlc as I >> have no access to that. Some assistance from someone who can verify >> the correctness on xlc would be appreciated. >> >> Thanks, >> David From Alan.Bateman at oracle.com Tue May 21 14:32:05 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 May 2019 15:32:05 +0100 Subject: zlib configuration : system vs. bundled In-Reply-To: References: <2ea5ad0d-04b1-4f16-17a0-8c16f7108840@oracle.com> <9c2696dc-8a72-b746-f148-3b8a93c2cfd2@oracle.com> Message-ID: On 17/05/2019 09:18, Baesken, Matthias wrote: > Hi Alan, thanks for the info . > Are you aware of a way to reliably see the info (e.g. in hs_err file) what version of libz was used at runtime ? > > On linux (with some luck ) we see it in hs_err , at least a lot of distros put the version into the libname , and then it is displayed in the hs_err section > > Dynamic libraries: > > ... /lib64/libz.so.1.2.8 > ... /lib64/libz.so.1.2.8 > ... /lib64/libz.so.1.2.8 > > On macOSX you see nothing just because the version is not in the libname : > > > Dynamic libraries: > > ... /usr/lib/libz.1.dylib > I don't have any insight into how libz is built for macOS. One comment on this is that the frequency of crashes in libz should be significantly reduced in recent releases as the central directory is no longer mmapped. At least in my experience, almost every crash I've seen involving libz or the zip code is because the zip file is replaced while it is mapped. -Alan From Sergey.Bylokhov at oracle.com Tue May 21 18:33:22 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 21 May 2019 11:33:22 -0700 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: <3b4c973b-5cba-fcd0-c1eb-e408590c494d@oracle.com> Message-ID: +1 On 21/05/2019 06:49, Erik Joelsson wrote: > Looks even better! > > /Erik > > On 2019-05-20 17:56, David Holmes wrote: >> Thank you everyone for taking a look at this. >> >> Here is version 2: >> >> http://cr.openjdk.java.net/~dholmes/8224087/webrev.v2/ >> >> Changes: >> - set c99 rather than gnu99 >> - Volker's change for xlc to match gcc and clang >> - added short note to build doc (can do wiki later) >> - cosmetic change of name to make variable based on other feedback during the C++14 discussion >> >> Thanks, >> David >> >> On 20/05/2019 5:40 pm, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 >>> webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ >>> >>> The need to remove a for-loop declaration expression to appease gcc 4.8 annoyed me enough to investigate setting C99 as our minimum allow C-language level when compiling. It turned out to be a lot more complex a situation than I thought due to toolchain quirks. See lots of details in the bug report. >>> >>> To summarise the changes: >>> - gcc: force to -std=gnu99 >>> - clang force to -std=gnu99 >>> - Solaris studio - no effective change >>> - Visual Studio - no change >>> - xlc - no effective change (but we use the explicit flag rather than accepting it as default) >>> >>> I've checked how this works with all the toolchains except xlc as I have no access to that. Some assistance from someone who can verify the correctness on xlc would be appreciated. >>> >>> Thanks, >>> David -- Best regards, Sergey. From david.holmes at oracle.com Wed May 22 06:38:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2019 16:38:40 +1000 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: <3b4c973b-5cba-fcd0-c1eb-e408590c494d@oracle.com> Message-ID: <8c6ef619-2c97-7006-9784-a27dd83002cd@oracle.com> Hi Thomas, On 21/05/2019 1:45 pm, Thomas St?fe wrote: > Hi David, > > Thank you for doing this, this looks all very good. Thanks for taking another look. > I wish though we had a clear whitelist of features to use or blacklist > for features to avoid. Most developers do not use Windows as a primary > platform, so it will always be a surprise whether Windows breaks in > submit tests. I agree. Unfortunately MS don't even do a good job of documenting their supported extensions to C89/90 - AFAICS they don't list for-loop declaration expressions. > I am also (a bit) concerned about C99 features creeping in which would > prevent verbatim backporting of patches to older releases. But let?s see > if that is really a problem in practice. Yes lets not try to solve problems that haven't arisen yet. 11u at least should be in a position to enforce the same use of C99. Thanks, David > > Thanks, Thomas > > > On Tue 21. May 2019 at 02:58, David Holmes > wrote: > > Thank you everyone for taking a look at this. > > Here is version 2: > > http://cr.openjdk.java.net/~dholmes/8224087/webrev.v2/ > > Changes: > - set c99 rather than gnu99 > - Volker's change for xlc to match gcc and clang > - added short note to build doc (can do wiki later) > - cosmetic change of name to make variable based on other feedback > during the C++14 discussion > > Thanks, > David > > On 20/05/2019 5:40 pm, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 > > webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ > > > > The need to remove a for-loop declaration expression to appease > gcc 4.8 > > annoyed me enough to investigate setting C99 as our minimum allow > > C-language level when compiling. It turned out to be a lot more > complex > > a situation than I thought due to toolchain quirks. See lots of > details > > in the bug report. > > > > To summarise the changes: > > - gcc: force to -std=gnu99 > > - clang force to -std=gnu99 > > - Solaris studio - no effective change > > - Visual Studio - no change > > - xlc - no effective change (but we use the explicit flag rather > than > > accepting it as default) > > > > I've checked how this works with all the toolchains except xlc as > I have > > no access to that. Some assistance from someone who can verify the > > correctness on xlc would be appreciated. > > > > Thanks, > > David > From david.holmes at oracle.com Wed May 22 06:39:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2019 16:39:14 +1000 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: <3b4c973b-5cba-fcd0-c1eb-e408590c494d@oracle.com> Message-ID: Thanks Erik! David On 21/05/2019 11:49 pm, Erik Joelsson wrote: > Looks even better! > > /Erik > > On 2019-05-20 17:56, David Holmes wrote: >> Thank you everyone for taking a look at this. >> >> Here is version 2: >> >> http://cr.openjdk.java.net/~dholmes/8224087/webrev.v2/ >> >> Changes: >> - set c99 rather than gnu99 >> - Volker's change for xlc to match gcc and clang >> - added short note to build doc (can do wiki later) >> - cosmetic change of name to make variable based on other feedback >> during the C++14 discussion >> >> Thanks, >> David >> >> On 20/05/2019 5:40 pm, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 >>> webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ >>> >>> The need to remove a for-loop declaration expression to appease gcc >>> 4.8 annoyed me enough to investigate setting C99 as our minimum allow >>> C-language level when compiling. It turned out to be a lot more >>> complex a situation than I thought due to toolchain quirks. See lots >>> of details in the bug report. >>> >>> To summarise the changes: >>> - gcc: force to -std=gnu99 >>> - clang force to -std=gnu99 >>> - Solaris studio - no effective change >>> - Visual Studio - no change >>> - xlc - no effective change (but we use the explicit flag rather than >>> accepting it as default) >>> >>> I've checked how this works with all the toolchains except xlc as I >>> have no access to that. Some assistance from someone who can verify >>> the correctness on xlc would be appreciated. >>> >>> Thanks, >>> David From david.holmes at oracle.com Wed May 22 06:39:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2019 16:39:35 +1000 Subject: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: <3b4c973b-5cba-fcd0-c1eb-e408590c494d@oracle.com> Message-ID: Thanks Sergey! David On 22/05/2019 4:33 am, Sergey Bylokhov wrote: > +1 > > On 21/05/2019 06:49, Erik Joelsson wrote: >> Looks even better! >> >> /Erik >> >> On 2019-05-20 17:56, David Holmes wrote: >>> Thank you everyone for taking a look at this. >>> >>> Here is version 2: >>> >>> http://cr.openjdk.java.net/~dholmes/8224087/webrev.v2/ >>> >>> Changes: >>> - set c99 rather than gnu99 >>> - Volker's change for xlc to match gcc and clang >>> - added short note to build doc (can do wiki later) >>> - cosmetic change of name to make variable based on other feedback >>> during the C++14 discussion >>> >>> Thanks, >>> David >>> >>> On 20/05/2019 5:40 pm, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224087 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/ >>>> >>>> The need to remove a for-loop declaration expression to appease gcc >>>> 4.8 annoyed me enough to investigate setting C99 as our minimum >>>> allow C-language level when compiling. It turned out to be a lot >>>> more complex a situation than I thought due to toolchain quirks. See >>>> lots of details in the bug report. >>>> >>>> To summarise the changes: >>>> - gcc: force to -std=gnu99 >>>> - clang force to -std=gnu99 >>>> - Solaris studio - no effective change >>>> - Visual Studio - no change >>>> - xlc - no effective change (but we use the explicit flag rather >>>> than accepting it as default) >>>> >>>> I've checked how this works with all the toolchains except xlc as I >>>> have no access to that. Some assistance from someone who can verify >>>> the correctness on xlc would be appreciated. >>>> >>>> Thanks, >>>> David > > From sgehwolf at redhat.com Wed May 22 16:34:04 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 22 May 2019 18:34:04 +0200 Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u Message-ID: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> Hi, Could I please get reviews for this minimal implementation of a tier1- like test set for JDK 8u? The implementation is rather barebones as I don't think it's worth rewriting the build system just for a command that runs a certain set of tests across a select set of repositories. I've re-used existing work in Makefiles as much as possible. After this patch one can do: $ make test TEST="tier1" Inspiration came from JDK 11u's tier1. As for prior art to this, I've only found "make test" to be working for JDK 8u from the top level. Yet, it doesn't run any hotspot tests, exits with a zero code on test failures and doesn't present a summary at the end. Overall not a nice developer experience. This patch makes it easier for a developers tests. It presents a summary at the end, returns non-zero on test failures so this can get used in CI and runs hotspot tests. As a follow-on we can work on fixing/excluding tests so that we always have a passing set of tests for developers to run before a checkin. Bug: https://bugs.openjdk.java.net/browse/JDK-8222737 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/ (includes changes to top/hotspot/jdk/langtools repos) Example excerpt from a run: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt Thoughts? Thanks, Severin From erik.joelsson at oracle.com Wed May 22 20:38:29 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 May 2019 13:38:29 -0700 Subject: RFR: JDK-8221543: Indify-dependent microbenchmarks are broken Message-ID: <7c240935-06f1-24a7-7edb-2f3dcc82ecd1@oracle.com> This patch adds running of the Indify tool on the microbenchmark classes after building them. The Indify tool is already present in the repo in the java/lang/invoke test sources, so I'm building it from there. Claes, could you take this for spin and see that it works as expected? Bug: https://bugs.openjdk.java.net/browse/JDK-8221543 Webrev: http://cr.openjdk.java.net/~erikj/8221543/webrev.01/ /Erik From claes.redestad at oracle.com Wed May 22 20:46:59 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 22 May 2019 22:46:59 +0200 Subject: RFR: JDK-8221543: Indify-dependent microbenchmarks are broken In-Reply-To: <7c240935-06f1-24a7-7edb-2f3dcc82ecd1@oracle.com> References: <7c240935-06f1-24a7-7edb-2f3dcc82ecd1@oracle.com> Message-ID: Hi Erik, On 2019-05-22 22:38, Erik Joelsson wrote: > This patch adds running of the Indify tool on the microbenchmark classes > after building them. The Indify tool is already present in the repo in > the java/lang/invoke test sources, so I'm building it from there. > > Claes, could you take this for spin and see that it works as expected? Yep, affected CallSite micros now run without error and comparably to the standalone ones. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221543 > > Webrev: http://cr.openjdk.java.net/~erikj/8221543/webrev.01/ Looks good to me! Thanks for fixing! /Claes From naoto.sato at oracle.com Wed May 22 22:56:19 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 22 May 2019 15:56:19 -0700 Subject: [13] RFR: 8221431: Support for Unicode 12.1 In-Reply-To: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> Message-ID: <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> Adding build-dev, as the change adds a small build tool to parse emoji-data. Naoto On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote: > Hi, > > Please review the changes to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8221431 > > The proposed CSR and changeset are located at: > > https://bugs.openjdk.java.net/browse/JDK-8222771 > https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ > > This enhancement incorporates support for the recently released Unicode > version 12.1. Besides the usual addition of new characters/scripts, this > enhancement includes normalization of the Japanese Reiwa era character > (U+32FF), and up-to-date extended grapheme cluster support in regex > package. > > Naoto From erik.joelsson at oracle.com Wed May 22 23:13:32 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 May 2019 16:13:32 -0700 Subject: [13] RFR: 8221431: Support for Unicode 12.1 In-Reply-To: <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> Message-ID: <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com> Hello Naoto, In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the double $$. I would recommend calling the newer MakeTargetDir macro instead. It doesn't take an argument. Otherwise build changes look good. /Erik On 2019-05-22 15:56, naoto.sato at oracle.com wrote: > Adding build-dev, as the change adds a small build tool to parse > emoji-data. > > Naoto > > On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote: >> Hi, >> >> Please review the changes to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8221431 >> >> The proposed CSR and changeset are located at: >> >> https://bugs.openjdk.java.net/browse/JDK-8222771 >> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ >> >> This enhancement incorporates support for the recently released >> Unicode version 12.1. Besides the usual addition of new >> characters/scripts, this enhancement includes normalization of the >> Japanese Reiwa era character (U+32FF), and up-to-date extended >> grapheme cluster support in regex package. >> >> Naoto From naoto.sato at oracle.com Thu May 23 01:36:40 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 22 May 2019 18:36:40 -0700 Subject: [13] RFR: 8221431: Support for Unicode 12.1 In-Reply-To: <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com> References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com> Message-ID: Hi Erik, Thank you for your comments. Updated the webrev accordingly: https://cr.openjdk.java.net/~naoto/8221431/webrev.04/ Naoto On 5/22/19 4:13 PM, Erik Joelsson wrote: > Hello Naoto, > > In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the double > $$. I would recommend calling the newer MakeTargetDir macro instead. It > doesn't take an argument. > > Otherwise build changes look good. > > /Erik > > On 2019-05-22 15:56, naoto.sato at oracle.com wrote: >> Adding build-dev, as the change adds a small build tool to parse >> emoji-data. >> >> Naoto >> >> On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote: >>> Hi, >>> >>> Please review the changes to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8221431 >>> >>> The proposed CSR and changeset are located at: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8222771 >>> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ >>> >>> This enhancement incorporates support for the recently released >>> Unicode version 12.1. Besides the usual addition of new >>> characters/scripts, this enhancement includes normalization of the >>> Japanese Reiwa era character (U+32FF), and up-to-date extended >>> grapheme cluster support in regex package. >>> >>> Naoto From igor.ignatyev at oracle.com Thu May 23 05:20:05 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 22 May 2019 22:20:05 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 Message-ID: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 > 21638 lines changed: 21628 ins; 0 del; 10 mod; Hi all, could you please review this patch which makes mocking framework from google test available for hotspot tests? JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 testing: tier1 webrevs: - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 > 21605 lines changed: 21605 ins; 0 del; 0 mod; * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 > 33 lines changed: 23 ins; 0 del; 10 mod; * makes necessary changes in makefiles * calls gmock framework init function * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 > 21638 lines changed: 21628 ins; 0 del; 10 mod; all the changes together thanks, -- Igor From guru at unixarea.de Thu May 23 08:29:56 2019 From: guru at unixarea.de (Matthias Apitz) Date: Thu, 23 May 2019 10:29:56 +0200 Subject: Building OpenJDK 1.8 on Solaris SPARC 10 fails with compiler error Message-ID: <20190523082956.GA2700@c720-r342378> Hello, We want to build OpenJDK 1.8 on Solaris SPARC 10. Please not, OpenJDK 11 is currently not an option due to our Java written software. Based on the source openjdk-8u40-src-b25-10_feb_2015.zip we do the following steps: $ uname -a SunOS srap06dsR1 5.10 Generic_150400-35 sun4u sparc SUNW,SPARC-Enterprise $ /opt/developerstudio12.6/bin/cc -V cc: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30 We changed slightly the script common/autoconf/generated-configure.sh because the compilers version string is not accepted. The string is greped and we let the return value pass as 0. With this small fix the configure stage is fine: $ LDFLAGS='-L/usr/sfw/lib/sparcv9' \ bash ./configure --with-cups=/export/home/guru/v50/CUPS2/cups-2.0.3 ... A new configuration has been successfully created in /export/home/sisis/guru/openjdk/build/solaris-sparcv9-normal-server-release using configure arguments '--with-cups=/export/home/guru/v50/CUPS2/cups-2.0.3'. Configuration summary: * Debug level: release * JDK variant: normal * JVM variants: server * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 64 Tools summary: * Boot JDK: java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) Server VM (build 24.80-b11, mixed mode) (at /usr/jdk/instances/jdk1.7.0_80) * C Compiler: Sun Studio version 5.15 (at /opt/developerstudio12.6/bin/cc) * C++ Compiler: Sun Studio version 5.15 (at /opt/developerstudio12.6/bin/CC) Build performance summary: * Cores to use: 7 * Memory limit: 8192 MB * ccache status: not available for your system The build fails now after some hundred compilations with: $ /usr/sfw/bin/gmake ... Compiling /export/home/sisis/guru/openjdk/hotspot/src/share/vm/adlc/filebuff.cpp CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs Compiling /export/home/sisis/guru/openjdk/hotspot/src/share/vm/adlc/forms.cpp CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs "/export/home/sisis/guru/openjdk/hotspot/src/share/vm/adlc/arena.cpp", line 60: Error: Placement operator new refers to non-placement operator delete. "/export/home/sisis/guru/openjdk/hotspot/src/share/vm/adlc/arena.cpp", line 67: Error: Placement operator new refers to non-placement operator delete. "/export/home/sisis/guru/openjdk/hotspot/src/share/vm/adlc/arena.cpp", line 97: Error: Placement operator new refers to non-placement operator delete. 3 Error(s) detected. The issue looks like this https://bugs.openjdk.java.net/browse/JDK-8199782 but JDK-8199782 is for OpenJDK 11 on Solaris 11. Is there a fix as well for OpenJDK 8? Any other hints? Thanks in advance matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From adinn at redhat.com Thu May 23 08:34:19 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 23 May 2019 09:34:19 +0100 Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> Message-ID: Hi Severin, On 22/05/2019 17:34, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222737 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/ > (includes changes to top/hotspot/jdk/langtools repos) > > Example excerpt from a run: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt > > Thoughts? Unfortunately, my makefile fu is too limited to provide a reliable review of the patch (I'm mostly just surprised it took so few changes to achieve). However, I can still wholeheartedly applaud this endeavour and its present outcome. As you say tuning the test group can be done over time as a follow-up. The important thing is to quickly place devs in a position to easily check that fixes have no unintended side-effects. Very nice! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From david.holmes at oracle.com Thu May 23 09:19:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 May 2019 19:19:21 +1000 Subject: Building OpenJDK 1.8 on Solaris SPARC 10 fails with compiler error In-Reply-To: <20190523082956.GA2700@c720-r342378> References: <20190523082956.GA2700@c720-r342378> Message-ID: <63e842de-3387-8824-808c-47c3fbb02f93@oracle.com> Hi Matthias, On 23/05/2019 6:29 pm, Matthias Apitz wrote: > > Hello, > > We want to build OpenJDK 1.8 on Solaris SPARC 10. Please not, OpenJDK 11 > is currently not an option due to our Java written software. > > Based on the source openjdk-8u40-src-b25-10_feb_2015.zip we do the following steps: Why such old sources? You are better off getting the latest released 8u source. > $ uname -a > SunOS srap06dsR1 5.10 Generic_150400-35 sun4u sparc SUNW,SPARC-Enterprise > > $ /opt/developerstudio12.6/bin/cc -V > cc: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30 You can't build JDK 8u with Solaris Studio 12.6, it's too recent and will complain about too many issues in the code. The supported 8u compiler is 12.1 https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms Cheers, David ----- > We changed slightly the script common/autoconf/generated-configure.sh because > the compilers version string is not accepted. The string is greped and > we let the return value pass as 0. > > With this small fix the configure stage is fine: > > $ LDFLAGS='-L/usr/sfw/lib/sparcv9' \ > bash ./configure --with-cups=/export/home/guru/v50/CUPS2/cups-2.0.3 > ... > A new configuration has been successfully created in > /export/home/sisis/guru/openjdk/build/solaris-sparcv9-normal-server-release > using configure arguments '--with-cups=/export/home/guru/v50/CUPS2/cups-2.0.3'. > > Configuration summary: > * Debug level: release > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 64 > > Tools summary: > * Boot JDK: java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) Server VM (build 24.80-b11, mixed mode) (at /usr/jdk/instances/jdk1.7.0_80) > * C Compiler: Sun Studio version 5.15 (at /opt/developerstudio12.6/bin/cc) > * C++ Compiler: Sun Studio version 5.15 (at /opt/developerstudio12.6/bin/CC) > > Build performance summary: > * Cores to use: 7 > * Memory limit: 8192 MB > * ccache status: not available for your system > > The build fails now after some hundred compilations with: > > $ /usr/sfw/bin/gmake > ... > Compiling /export/home/sisis/guru/openjdk/hotspot/src/share/vm/adlc/filebuff.cpp > CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs > CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs > CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs > CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs > CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs > CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs > Compiling /export/home/sisis/guru/openjdk/hotspot/src/share/vm/adlc/forms.cpp > CC: Warning: illegal use of -xdebugformat option, illegal value ignored: stabs > "/export/home/sisis/guru/openjdk/hotspot/src/share/vm/adlc/arena.cpp", line 60: Error: Placement operator new refers to non-placement operator delete. > "/export/home/sisis/guru/openjdk/hotspot/src/share/vm/adlc/arena.cpp", line 67: Error: Placement operator new refers to non-placement operator delete. > "/export/home/sisis/guru/openjdk/hotspot/src/share/vm/adlc/arena.cpp", line 97: Error: Placement operator new refers to non-placement operator delete. > 3 Error(s) detected. > > > The issue looks like this https://bugs.openjdk.java.net/browse/JDK-8199782 > but JDK-8199782 is for OpenJDK 11 on Solaris 11. > > Is there a fix as well for OpenJDK 8? > > Any other hints? > > Thanks in advance > > matthias > From guru at unixarea.de Thu May 23 09:31:25 2019 From: guru at unixarea.de (Matthias Apitz) Date: Thu, 23 May 2019 11:31:25 +0200 Subject: Building OpenJDK 1.8 on Solaris SPARC 10 fails with compiler error In-Reply-To: <63e842de-3387-8824-808c-47c3fbb02f93@oracle.com> References: <20190523082956.GA2700@c720-r342378> <63e842de-3387-8824-808c-47c3fbb02f93@oracle.com> Message-ID: <20190523093125.GA3192@c720-r342378> Hello David, Thanks for the quick reply and hints. El d?a jueves, mayo 23, 2019 a las 07:19:21p. m. +1000, David Holmes escribi?: > > Based on the source openjdk-8u40-src-b25-10_feb_2015.zip we do the following steps: > > Why such old sources? You are better off getting the latest released 8u > source. I was told that this was the latest version, we will look better. > You can't build JDK 8u with Solaris Studio 12.6, it's too recent and > will complain about too many issues in the code. The supported 8u > compiler is 12.1 > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms Seems that the latest available version on oracle.com is 12.3. We will give this a try. Re/ the 12.6 I helped me with this small change: diff -c hotspot/make/solaris/makefiles/adlc.make* *** hotspot/make/solaris/makefiles/adlc.make Thu May 23 11:17:53 2019 --- hotspot/make/solaris/makefiles/adlc.make.orig Wed Feb 11 02:08:09 2015 *************** *** 74,80 **** # CFLAGS_WARN holds compiler options to suppress/enable warnings. # Compiler warnings are treated as errors ifeq ($(shell expr $(COMPILER_REV_NUMERIC) \>= 509), 1) ! CFLAGS_WARN = +w endif CFLAGS += $(CFLAGS_WARN) --- 74,80 ---- # CFLAGS_WARN holds compiler options to suppress/enable warnings. # Compiler warnings are treated as errors ifeq ($(shell expr $(COMPILER_REV_NUMERIC) \>= 509), 1) ! CFLAGS_WARN = +w -errwarn endif CFLAGS += $(CFLAGS_WARN) This let compile the source in question, but we stop here and move over to 12.3 Thanks again matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From david.holmes at oracle.com Thu May 23 09:39:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 May 2019 19:39:24 +1000 Subject: Building OpenJDK 1.8 on Solaris SPARC 10 fails with compiler error In-Reply-To: <20190523093125.GA3192@c720-r342378> References: <20190523082956.GA2700@c720-r342378> <63e842de-3387-8824-808c-47c3fbb02f93@oracle.com> <20190523093125.GA3192@c720-r342378> Message-ID: Hi Matthias, Disabling "warnings are errors" may let you compile okay, perhaps even with 12.6. But you're really on your own at that point. There may be other issues beyond simple warnings. Good luck. :) David On 23/05/2019 7:31 pm, Matthias Apitz wrote: > > Hello David, > > Thanks for the quick reply and hints. > > El d?a jueves, mayo 23, 2019 a las 07:19:21p. m. +1000, David Holmes escribi?: > >>> Based on the source openjdk-8u40-src-b25-10_feb_2015.zip we do the following steps: >> >> Why such old sources? You are better off getting the latest released 8u >> source. > > I was told that this was the latest version, we will look better. > >> You can't build JDK 8u with Solaris Studio 12.6, it's too recent and >> will complain about too many issues in the code. The supported 8u >> compiler is 12.1 >> >> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > Seems that the latest available version on oracle.com is 12.3. We > will give this a try. > > Re/ the 12.6 I helped me with this small change: > > diff -c hotspot/make/solaris/makefiles/adlc.make* > *** hotspot/make/solaris/makefiles/adlc.make Thu May 23 11:17:53 2019 > --- hotspot/make/solaris/makefiles/adlc.make.orig Wed Feb 11 > 02:08:09 2015 > *************** > *** 74,80 **** > # CFLAGS_WARN holds compiler options to suppress/enable warnings. > # Compiler warnings are treated as errors > ifeq ($(shell expr $(COMPILER_REV_NUMERIC) \>= 509), 1) > ! CFLAGS_WARN = +w > endif > CFLAGS += $(CFLAGS_WARN) > > --- 74,80 ---- > # CFLAGS_WARN holds compiler options to suppress/enable warnings. > # Compiler warnings are treated as errors > ifeq ($(shell expr $(COMPILER_REV_NUMERIC) \>= 509), 1) > ! CFLAGS_WARN = +w -errwarn > endif > CFLAGS += $(CFLAGS_WARN) > > This let compile the source in question, but we stop here and move over > to 12.3 > > Thanks again > > matthias > > > From sgehwolf at redhat.com Thu May 23 09:53:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 May 2019 11:53:29 +0200 Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> Message-ID: <38f5d5d356e7dba6162ff1cee7752ccebf0aff65.camel@redhat.com> Hi Andrew, On Thu, 2019-05-23 at 09:34 +0100, Andrew Dinn wrote: > Hi Severin, > > On 22/05/2019 17:34, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222737 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/ > > (includes changes to top/hotspot/jdk/langtools repos) > > > > Example excerpt from a run: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt > > > > Thoughts? > Unfortunately, my makefile fu is too limited to provide a reliable > review of the patch (I'm mostly just surprised it took so few changes to > achieve). However, I can still wholeheartedly applaud this endeavour and > its present outcome. :) Great. > As you say tuning the test group can be done over time as a follow-up. > The important thing is to quickly place devs in a position to easily > check that fixes have no unintended side-effects. Very nice! Thanks for looking this over! Cheers, Severin From erik.joelsson at oracle.com Thu May 23 13:46:44 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 May 2019 06:46:44 -0700 Subject: [13] RFR: 8221431: Support for Unicode 12.1 In-Reply-To: References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com> Message-ID: <36408f60-1669-1726-27be-b660267827c8@oracle.com> Build changes look good. /Erik On 2019-05-22 18:36, naoto.sato at oracle.com wrote: > Hi Erik, > > Thank you for your comments. Updated the webrev accordingly: > > https://cr.openjdk.java.net/~naoto/8221431/webrev.04/ > > Naoto > > On 5/22/19 4:13 PM, Erik Joelsson wrote: >> Hello Naoto, >> >> In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the >> double $$. I would recommend calling the newer MakeTargetDir macro >> instead. It doesn't take an argument. >> >> Otherwise build changes look good. >> >> /Erik >> >> On 2019-05-22 15:56, naoto.sato at oracle.com wrote: >>> Adding build-dev, as the change adds a small build tool to parse >>> emoji-data. >>> >>> Naoto >>> >>> On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote: >>>> Hi, >>>> >>>> Please review the changes to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8221431 >>>> >>>> The proposed CSR and changeset are located at: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8222771 >>>> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ >>>> >>>> This enhancement incorporates support for the recently released >>>> Unicode version 12.1. Besides the usual addition of new >>>> characters/scripts, this enhancement includes normalization of the >>>> Japanese Reiwa era character (U+32FF), and up-to-date extended >>>> grapheme cluster support in regex package. >>>> >>>> Naoto From erik.joelsson at oracle.com Thu May 23 13:57:27 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 May 2019 06:57:27 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> Message-ID: Hello Igor, Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. [1] http://openjdk.java.net/groups/build/doc/code-conventions.html /Erik On 2019-05-22 22:20, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >> 21638 lines changed: 21628 ins; 0 del; 10 mod; > Hi all, > > could you please review this patch which makes mocking framework from google test available for hotspot tests? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 > testing: tier1 > webrevs: > - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >> 21605 lines changed: 21605 ins; 0 del; 0 mod; > * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; > * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; > > - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >> 33 lines changed: 23 ins; 0 del; 10 mod; > * makes necessary changes in makefiles > * calls gmock framework init function > * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot > > - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >> 21638 lines changed: 21628 ins; 0 del; 10 mod; > all the changes together > > > thanks, > -- Igor From erik.joelsson at oracle.com Thu May 23 15:56:00 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 May 2019 08:56:00 -0700 Subject: RFR: JDK-8224677: Dtrace .d files clash with make dependency .d files Message-ID: Since JDK-8217728, where I introduced some optimizations for handling of the generated make dependency files for native compilation, building hotspot incrementally on Solaris has been broken. The reason for the breakage is that there is a clash between the *.d (header) files created by the dtrace build and the *.d (make) files created by the compiler. The optimization was to cat all the *.d make file together into a single file, but if dtrace is enabled, this cat will inadvertently include the dtrace files as well, which causes parse errors in make when make tries to include the resulting file. This fix changes the file extension used by dtrace files in the output dir to *.dt to avoid the clash. Bug: https://bugs.openjdk.java.net/browse/JDK-8224677 Webrev: http://cr.openjdk.java.net/~erikj/8224677/webrev.01/ /Erik From derekw at marvell.com Thu May 23 16:50:23 2019 From: derekw at marvell.com (Derek White) Date: Thu, 23 May 2019 16:50:23 +0000 Subject: [EXT] Re: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: > -----Original Message----- > From: build-dev On Behalf Of Volker > Simonis > Sent: Monday, May 20, 2019 2:32 PM > To: Sergey Bylokhov > Cc: build-dev > Subject: [EXT] Re: RFR: 8224087: Compile C code for at least C99 Standard > compliance > > External Email > > ---------------------------------------------------------------------- > Sergey Bylokhov schrieb am Mo. 20. Mai > 2019 um > 20:14: > > > Hi, David. > > Should not the minimum version of c standard mentioned in the > > doc/building.html? > > > > We actually have a Wiki page for that because it?s much easier to maintain: > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms Easier for Oracle and SAP apparently ?. How do I get write access to the wiki? I can log in but Edit menu items are greyed out. Thanks! - Derek From tim.bell at oracle.com Thu May 23 17:17:46 2019 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 23 May 2019 10:17:46 -0700 Subject: RFR: JDK-8224677: Dtrace .d files clash with make dependency .d files In-Reply-To: References: Message-ID: <5CE6D5BA.9020400@oracle.com> Erik: > Since JDK-8217728, where I introduced some optimizations for handling of > the generated make dependency files for native compilation, building > hotspot incrementally on Solaris has been broken. The reason for the > breakage is that there is a clash between the *.d (header) files created > by the dtrace build and the *.d (make) files created by the compiler. > The optimization was to cat all the *.d make file together into a single > file, but if dtrace is enabled, this cat will inadvertently include the > dtrace files as well, which causes parse errors in make when make tries > to include the resulting file. > > This fix changes the file extension used by dtrace files in the output > dir to *.dt to avoid the clash. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224677 > > Webrev: http://cr.openjdk.java.net/~erikj/8224677/webrev.01/ So the .dt files are temporary artifacts in the build anyway, used while creating dtrace.o. Looks good. /Tim From erik.joelsson at oracle.com Thu May 23 17:24:14 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 May 2019 10:24:14 -0700 Subject: RFR: JDK-8224145: Build compare script fails intermittently on test image native libraries Message-ID: Since I added comparing of the test image, we have seen some intermittent compare failures in the baseline compare builds we run. The root cause of these failures are that the native libraries in the test image are not stripped of debug information, like the product native libraries are. Non stripped libraries are notoriously hard to build in a reproducible way, so I'm fixing this by simply stripping the test libraries before comparing them on the affected platforms. On Linux, only the gtest version of libjvm.so needs to be stripped. On Solaris and macosx, all libraries and executables need it. By stripping them, we no longer need to skip the simple binary diff check. I have run the baseline compare builds at least 3 times on each platform with this change without seeing failures. Bug: https://bugs.openjdk.java.net/browse/JDK-8224145 Webrev: http://cr.openjdk.java.net/~erikj/8224145/webrev.01/index.html /Erik From tim.bell at oracle.com Thu May 23 17:43:12 2019 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 23 May 2019 10:43:12 -0700 Subject: RFR: JDK-8224145: Build compare script fails intermittently on test image native libraries In-Reply-To: References: Message-ID: <5CE6DBB0.2040607@oracle.com> Erik: > Since I added comparing of the test image, we have seen some > intermittent compare failures in the baseline compare builds we run. The > root cause of these failures are that the native libraries in the test > image are not stripped of debug information, like the product native > libraries are. Non stripped libraries are notoriously hard to build in a > reproducible way, so I'm fixing this by simply stripping the test > libraries before comparing them on the affected platforms. > > On Linux, only the gtest version of libjvm.so needs to be stripped. On > Solaris and macosx, all libraries and executables need it. By stripping > them, we no longer need to skip the simple binary diff check. > > I have run the baseline compare builds at least 3 times on each platform > with this change without seeing failures. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224145 > > Webrev: http://cr.openjdk.java.net/~erikj/8224145/webrev.01/index.html Looks good. Tim From Roger.Riggs at oracle.com Thu May 23 17:47:00 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 23 May 2019 13:47:00 -0400 Subject: [13] RFR: 8221431: Support for Unicode 12.1 In-Reply-To: References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com> Message-ID: <1f170322-b647-55cb-ad41-ff670477dce3@oracle.com> Hi Naoto, Looks ok. src/java.base/share/legal/icu.md: Line 7:? Can the copyright character be changed to (c) to make it easier to check copyrights Thanks, Roger On 05/22/2019 09:36 PM, naoto.sato at oracle.com wrote: > Hi Erik, > > Thank you for your comments. Updated the webrev accordingly: > > https://cr.openjdk.java.net/~naoto/8221431/webrev.04/ > > Naoto > > On 5/22/19 4:13 PM, Erik Joelsson wrote: >> Hello Naoto, >> >> In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the >> double $$. I would recommend calling the newer MakeTargetDir macro >> instead. It doesn't take an argument. >> >> Otherwise build changes look good. >> >> /Erik >> >> On 2019-05-22 15:56, naoto.sato at oracle.com wrote: >>> Adding build-dev, as the change adds a small build tool to parse >>> emoji-data. >>> >>> Naoto >>> >>> On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote: >>>> Hi, >>>> >>>> Please review the changes to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8221431 >>>> >>>> The proposed CSR and changeset are located at: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8222771 >>>> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ >>>> >>>> This enhancement incorporates support for the recently released >>>> Unicode version 12.1. Besides the usual addition of new >>>> characters/scripts, this enhancement includes normalization of the >>>> Japanese Reiwa era character (U+32FF), and up-to-date extended >>>> grapheme cluster support in regex package. >>>> >>>> Naoto From david.holmes at oracle.com Thu May 23 22:54:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 May 2019 08:54:42 +1000 Subject: [EXT] Re: RFR: 8224087: Compile C code for at least C99 Standard compliance In-Reply-To: References: Message-ID: <458b1667-d450-651b-e1c2-8639efe94ace@oracle.com> Hi Derek, First can you possibly get your mailer to stop putting [EXT] in the subject line because it really messes up threading and filtering. On 24/05/2019 2:50 am, Derek White wrote: > > >> -----Original Message----- >> From: build-dev On Behalf Of Volker >> Simonis >> Sent: Monday, May 20, 2019 2:32 PM >> To: Sergey Bylokhov >> Cc: build-dev >> Subject: [EXT] Re: RFR: 8224087: Compile C code for at least C99 Standard >> compliance >> >> External Email >> >> ---------------------------------------------------------------------- >> Sergey Bylokhov schrieb am Mo. 20. Mai >> 2019 um >> 20:14: >> >>> Hi, David. >>> Should not the minimum version of c standard mentioned in the >>> doc/building.html? >>> >> >> We actually have a Wiki page for that because it?s much easier to maintain: >> >> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > > Easier for Oracle and SAP apparently ?. > > How do I get write access to the wiki? I can log in but Edit menu items are greyed out. You have to be a member of a Group to edit the Group's wiki content. In this case that's the Build Group (which excludes me too). http://openjdk.java.net/census#build David > Thanks! > - Derek > From igor.ignatyev at oracle.com Fri May 24 02:07:48 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 23 May 2019 19:07:48 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> Message-ID: <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> Hi Erik, thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. -- Igor [1] > diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk > --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 > +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 > @@ -64,8 +64,9 @@ > EXCLUDES := $(JVM_EXCLUDES), \ > EXCLUDE_FILES := gtestLauncher.cpp, \ > EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ > - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ > - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ > + EXTRA_FILES := \ > + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ > + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ > EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ > $(BUILD_LIBJVM_ALL_OBJS)), \ > CFLAGS := $(JVM_CFLAGS) \ [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ > On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: > > Hello Igor, > > Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > /Erik > > On 2019-05-22 22:20, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >> Hi all, >> >> could you please review this patch which makes mocking framework from google test available for hotspot tests? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >> testing: tier1 >> webrevs: >> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >> >> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>> 33 lines changed: 23 ins; 0 del; 10 mod; >> * makes necessary changes in makefiles >> * calls gmock framework init function >> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >> >> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >> all the changes together >> >> >> thanks, >> -- Igor From david.holmes at oracle.com Fri May 24 02:31:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 May 2019 12:31:41 +1000 Subject: RFR: JDK-8224677: Dtrace .d files clash with make dependency .d files In-Reply-To: References: Message-ID: <5fa28221-351d-bb1a-ec12-23c91e00903f@oracle.com> On 24/05/2019 1:56 am, Erik Joelsson wrote: > Since JDK-8217728, where I introduced some optimizations for handling of > the generated make dependency files for native compilation, building > hotspot incrementally on Solaris has been broken. The reason for the > breakage is that there is a clash between the *.d (header) files created > by the dtrace build and the *.d (make) files created by the compiler. > The optimization was to cat all the *.d make file together into a single > file, but if dtrace is enabled, this cat will inadvertently include the > dtrace files as well, which causes parse errors in make when make tries > to include the resulting file. > > This fix changes the file extension used by dtrace files in the output > dir to *.dt to avoid the clash. I would have changed the dependencies file - ".d" is the accepted extension for DTrace files. David ----- > Bug: https://bugs.openjdk.java.net/browse/JDK-8224677 > > Webrev: http://cr.openjdk.java.net/~erikj/8224677/webrev.01/ > > /Erik > From guru at unixarea.de Fri May 24 09:55:09 2019 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 24 May 2019 11:55:09 +0200 Subject: testing a openjdk8u212-b03 on Solaris SPARC 10 Message-ID: <20190524095509.GA3886@c720-r342378> After the hints from David (thanks!) we restarted the building of openjdk8u212-b03 the correct way with Get the latest required software: 1. latest OpenJDK release source (aktually openjdk8u212-b03.tar.gz) 2. Solaris' Studio version 12.3 (note 12.6 will not work) 3. the JT regression test tool jtreg-4.2-b14.tar.gz $ uname -a SunOS srap06dsR1 5.10 Generic_150400-35 sun4u sparc SUNW,SPARC-Enterprise $ cd jdk8u212-b03 $ LDFLAGS='-L/usr/sfw/lib/sparcv9' \ FREETYPE_LIBS='-L/usr/sfw/lib/sparcv9' \ bash ./configure --prefix=/usr/local/sisis-pap/openjdk8 \ --with-cups-include=/export/home/guru/v50/CUPS2/cups-2.0.3 $ /usr/sfw/bin/gmake all I tried to use the JT regression test tool jtreg-4.2-b14.tar.gz the following way (as explained in its docs: http://openjdk.java.net/jtreg/runtests.html $ export JT_HOME=/export/home/sisis/guru/jtreg $ export JT_JAVA=/usr/local/sisis-pap/jdk1.8.0_31/bin/java $ export PRODUCT_HOME=/export/home/sisis/guru/jdk8u212-b03/build/solaris-sparcv9-normal-server-release/images/j2sdk-image (btw: The script has a bug: the shebang must be modified to '/usr/bin/bash') $ cd test $ nohup /usr/sfw/bin/gmake all But nearly all tests are failing: TEST RESULT: Error. Agent error: java.lang.Exception: Agent 0 timed out with a timeout of 10 seconds; check console log for any additional details TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 5 errors occurred. TEST RESULT: Error. Program `/export/home/sisis/guru/jdk8u212-b03/build/solaris-sparcv9-normal-server-release/images/j2sdk-image/bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 123313ms). TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Compiler exit result should be 3 TEST RESULT: Error. Program `/export/home/sisis/guru/jdk8u212-b03/build/solaris-sparcv9-normal-server-release/images/j2sdk-image/bin/java' timed out (timeout set to 600000ms, elapsed time including timeout handling was 603259ms). TEST RESULT: Error. Program `/export/home/sisis/guru/jdk8u212-b03/build/solaris-sparcv9-normal-server-release/images/j2sdk-image/bin/java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 122450ms). ... What are the time outs? What do I wrong? The full nuhup.out log is here: http://www.unixarea.de/openjdk-test-nohup.txt The built JDK itself works fine with our software. Any ideas why the test suite is failing? Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From guru at unixarea.de Fri May 24 12:14:18 2019 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 24 May 2019 14:14:18 +0200 Subject: testing a openjdk8u212-b03 on Solaris SPARC 10 In-Reply-To: <20190524095509.GA3886@c720-r342378> References: <20190524095509.GA3886@c720-r342378> Message-ID: <20190524121418.GA4751@c720-r342378> El d?a viernes, mayo 24, 2019 a las 11:55:09a. m. +0200, Matthias Apitz escribi?: > I tried to use the JT regression test tool jtreg-4.2-b14.tar.gz the > following way (as explained in its docs: > http://openjdk.java.net/jtreg/runtests.html > > > $ export JT_HOME=/export/home/sisis/guru/jtreg > $ export JT_JAVA=/usr/local/sisis-pap/jdk1.8.0_31/bin/java > $ export PRODUCT_HOME=/export/home/sisis/guru/jdk8u212-b03/build/solaris-sparcv9-normal-server-release/images/j2sdk-image > > (btw: The script has a bug: the shebang must be modified to '/usr/bin/bash') > > $ cd test > $ nohup /usr/sfw/bin/gmake all I followed the hint in http://openjdk.java.net/jtreg/runtests.html to use the new built JDK for the testing itself. I set: $ export JT_JAVA=/export/home/sisis/guru/jdk8u212-b03/build/solaris-sparcv9-normal-server-release/images/j2sdk-image/bin/java Then I looked in the test/Makefile and started not 'all', but 'default', i.e. $ nohup /usr/sfw/bin/gmake all 'default' means as target: jdk_core langtools_jtreg and these test until now are all passed with 'Execution successful' Is this good enough as a test? matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From erik.joelsson at oracle.com Fri May 24 15:28:50 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 24 May 2019 08:28:50 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> Message-ID: Thanks, looks good! /Erik On 2019-05-23 19:07, Igor Ignatyev wrote: > Hi Erik, > > thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. > > -- Igor > > [1] >> diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk >> --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 >> +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 >> @@ -64,8 +64,9 @@ >> EXCLUDES := $(JVM_EXCLUDES), \ >> EXCLUDE_FILES := gtestLauncher.cpp, \ >> EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ >> - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >> - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >> + EXTRA_FILES := \ >> + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >> + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >> EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ >> $(BUILD_LIBJVM_ALL_OBJS)), \ >> CFLAGS := $(JVM_CFLAGS) \ > [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ > >> On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: >> >> Hello Igor, >> >> Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. >> >> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >> >> /Erik >> >> On 2019-05-22 22:20, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>> Hi all, >>> >>> could you please review this patch which makes mocking framework from google test available for hotspot tests? >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >>> testing: tier1 >>> webrevs: >>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >>> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >>> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >>> >>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>>> 33 lines changed: 23 ins; 0 del; 10 mod; >>> * makes necessary changes in makefiles >>> * calls gmock framework init function >>> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >>> >>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>> all the changes together >>> >>> >>> thanks, >>> -- Igor From erik.joelsson at oracle.com Fri May 24 15:47:29 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 24 May 2019 08:47:29 -0700 Subject: testing a openjdk8u212-b03 on Solaris SPARC 10 In-Reply-To: <20190524121418.GA4751@c720-r342378> References: <20190524095509.GA3886@c720-r342378> <20190524121418.GA4751@c720-r342378> Message-ID: <191ef277-ce88-c12c-d494-d68954df6d17@oracle.com> Hello Matthias, On 2019-05-24 05:14, Matthias Apitz wrote: > El d?a viernes, mayo 24, 2019 a las 11:55:09a. m. +0200, Matthias Apitz escribi?: > >> I tried to use the JT regression test tool jtreg-4.2-b14.tar.gz the >> following way (as explained in its docs: >> http://openjdk.java.net/jtreg/runtests.html >> >> >> $ export JT_HOME=/export/home/sisis/guru/jtreg >> $ export JT_JAVA=/usr/local/sisis-pap/jdk1.8.0_31/bin/java >> $ export PRODUCT_HOME=/export/home/sisis/guru/jdk8u212-b03/build/solaris-sparcv9-normal-server-release/images/j2sdk-image >> >> (btw: The script has a bug: the shebang must be modified to '/usr/bin/bash') >> >> $ cd test >> $ nohup /usr/sfw/bin/gmake all > I followed the hint in http://openjdk.java.net/jtreg/runtests.html to > use the new built JDK for the testing itself. I set: > > $ export JT_JAVA=/export/home/sisis/guru/jdk8u212-b03/build/solaris-sparcv9-normal-server-release/images/j2sdk-image/bin/java For JT_JAVA, you generally want the JDK you trust the most, which is usually the boot jdk. > Then I looked in the test/Makefile and started not 'all', but 'default', > i.e. > > $ nohup /usr/sfw/bin/gmake all Running the 'all' target is certainly not expected to pass. Test stability in general is something that we put a lot of effort into in JDK 9 and up, but even so, I would not expect all tests to pass in current mainline either. We have sub selections of tests that are considered more or less stable. > 'default' means as target: jdk_core langtools_jtreg > and these test until now are all passed with 'Execution successful' > Is this good enough as a test? Building from source, using a different compiler version and a different environment than has been thoroughly tested is always a risk. We can of course not say if anything is good enough for you, that is ultimately your responsibility to figure out. That said, I don't know what a good selection would be. I do think you should include something from hotspot as well as that does not seem to be included in the default target. Severin is putting together some basic set of tests for jdk8u here [1] so perhaps you could look into his choices there. There is unfortunately no baseline test results available that I know of, so there really is no way to know if any test failure you see is significant. Ultimately, what should matter is what you need to run, so I would recommend testing the software you intend to use this JDK with. [1] http://mail.openjdk.java.net/pipermail/build-dev/2019-May/025585.html /Erik From martijnverburg at gmail.com Fri May 24 18:46:12 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 24 May 2019 20:46:12 +0200 Subject: Building OpenJDK 1.8 on Solaris SPARC 10 fails with compiler error In-Reply-To: References: <20190523082956.GA2700@c720-r342378> <63e842de-3387-8824-808c-47c3fbb02f93@oracle.com> <20190523093125.GA3192@c720-r342378> Message-ID: Hi Matthias, We're building Solaris builds from the same source over at https://adoptopenjdk.net - feel free to use those binaries ( https://adoptopenjdk.net/releases.html#sparcv9_solaris) and/or our build scripts (github.com/adoptopenjdk/openjdk-build). When there are genuine upstream fixes to the build scripts, we send patches upstream to here (OpenJDK proper), but mostly it's configuring things just so :-). Cheers, Martijn On Thu, 23 May 2019 at 11:39, David Holmes wrote: > Hi Matthias, > > Disabling "warnings are errors" may let you compile okay, perhaps even > with 12.6. But you're really on your own at that point. There may be > other issues beyond simple warnings. > > Good luck. :) > > David > > On 23/05/2019 7:31 pm, Matthias Apitz wrote: > > > > Hello David, > > > > Thanks for the quick reply and hints. > > > > El d?a jueves, mayo 23, 2019 a las 07:19:21p. m. +1000, David Holmes > escribi?: > > > >>> Based on the source openjdk-8u40-src-b25-10_feb_2015.zip we do the > following steps: > >> > >> Why such old sources? You are better off getting the latest released 8u > >> source. > > > > I was told that this was the latest version, we will look better. > > > >> You can't build JDK 8u with Solaris Studio 12.6, it's too recent and > >> will complain about too many issues in the code. The supported 8u > >> compiler is 12.1 > >> > >> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > > > Seems that the latest available version on oracle.com is 12.3. We > > will give this a try. > > > > Re/ the 12.6 I helped me with this small change: > > > > diff -c hotspot/make/solaris/makefiles/adlc.make* > > *** hotspot/make/solaris/makefiles/adlc.make Thu May 23 11:17:53 2019 > > --- hotspot/make/solaris/makefiles/adlc.make.orig Wed Feb 11 > > 02:08:09 2015 > > *************** > > *** 74,80 **** > > # CFLAGS_WARN holds compiler options to suppress/enable warnings. > > # Compiler warnings are treated as errors > > ifeq ($(shell expr $(COMPILER_REV_NUMERIC) \>= 509), 1) > > ! CFLAGS_WARN = +w > > endif > > CFLAGS += $(CFLAGS_WARN) > > > > --- 74,80 ---- > > # CFLAGS_WARN holds compiler options to suppress/enable warnings. > > # Compiler warnings are treated as errors > > ifeq ($(shell expr $(COMPILER_REV_NUMERIC) \>= 509), 1) > > ! CFLAGS_WARN = +w -errwarn > > endif > > CFLAGS += $(CFLAGS_WARN) > > > > This let compile the source in question, but we stop here and move over > > to 12.3 > > > > Thanks again > > > > matthias > > > > > > > From philip.race at oracle.com Fri May 24 21:03:08 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 24 May 2019 14:03:08 -0700 Subject: RFR: 8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar Message-ID: <8c8dd7d8-9341-665f-61e9-f61da72db817@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8224778 webrev : http://cr.openjdk.java.net/~prr/8224778/ With this fix the test can find the demo jar in its traditional place as before, and now also where it is placed by JIB to be invoked from RunTests.gmk -phil From erik.joelsson at oracle.com Fri May 24 21:16:12 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 24 May 2019 14:16:12 -0700 Subject: RFR: 8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar In-Reply-To: <8c8dd7d8-9341-665f-61e9-f61da72db817@oracle.com> References: <8c8dd7d8-9341-665f-61e9-f61da72db817@oracle.com> Message-ID: <8664e100-337c-a2f7-5aaa-7b3008012911@oracle.com> Hello Phil, Patch looks good, but the curly braces look weird in a makefile. I see the line below which you probably emulated also uses them, but they really should just be normal braces. /Erik On 2019-05-24 14:03, Phil Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8224778 > webrev : http://cr.openjdk.java.net/~prr/8224778/ > > With this fix the test can find the demo jar in its traditional place > as before, > and now also where it is placed by JIB to be invoked from RunTests.gmk > > -phil > From igor.ignatyev at oracle.com Fri May 24 21:33:43 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 24 May 2019 14:33:43 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> Message-ID: <439DEFFE-970A-439A-B7C8-3B8D4748041D@oracle.com> @Erik, Thanks! @hotspot (looking at Robin), can I get another review? -- Igor > On May 24, 2019, at 8:28 AM, Erik Joelsson wrote: > > Thanks, looks good! > > /Erik > > On 2019-05-23 19:07, Igor Ignatyev wrote: >> Hi Erik, >> >> thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. >> >> -- Igor >> >> [1] >>> diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk >>> --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 >>> +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 >>> @@ -64,8 +64,9 @@ >>> EXCLUDES := $(JVM_EXCLUDES), \ >>> EXCLUDE_FILES := gtestLauncher.cpp, \ >>> EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ >>> - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>> - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>> + EXTRA_FILES := \ >>> + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>> + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>> EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ >>> $(BUILD_LIBJVM_ALL_OBJS)), \ >>> CFLAGS := $(JVM_CFLAGS) \ >> [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ >> >>> On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: >>> >>> Hello Igor, >>> >>> Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. >>> >>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>> >>> /Erik >>> >>> On 2019-05-22 22:20, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>> Hi all, >>>> >>>> could you please review this patch which makes mocking framework from google test available for hotspot tests? >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >>>> testing: tier1 >>>> webrevs: >>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>>>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >>>> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >>>> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >>>> >>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>>>> 33 lines changed: 23 ins; 0 del; 10 mod; >>>> * makes necessary changes in makefiles >>>> * calls gmock framework init function >>>> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >>>> >>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>> all the changes together >>>> >>>> >>>> thanks, >>>> -- Igor From philip.race at oracle.com Fri May 24 21:41:41 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 24 May 2019 14:41:41 -0700 Subject: RFR: 8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar In-Reply-To: <8664e100-337c-a2f7-5aaa-7b3008012911@oracle.com> References: <8c8dd7d8-9341-665f-61e9-f61da72db817@oracle.com> <8664e100-337c-a2f7-5aaa-7b3008012911@oracle.com> Message-ID: <5CE86515.1080804@oracle.com> Yes, I just copied that line + edited it. I can update both lines if that is what you are asking but I'll wait a little to see if there are any other comments first. -phil. On 5/24/19, 2:16 PM, Erik Joelsson wrote: > Hello Phil, > > Patch looks good, but the curly braces look weird in a makefile. I see > the line below which you probably emulated also uses them, but they > really should just be normal braces. > > /Erik > > On 2019-05-24 14:03, Phil Race wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8224778 >> webrev : http://cr.openjdk.java.net/~prr/8224778/ >> >> With this fix the test can find the demo jar in its traditional place >> as before, >> and now also where it is placed by JIB to be invoked from RunTests.gmk >> >> -phil >> From philip.race at oracle.com Fri May 24 23:36:47 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 24 May 2019 16:36:47 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar In-Reply-To: <5CE86515.1080804@oracle.com> References: <8c8dd7d8-9341-665f-61e9-f61da72db817@oracle.com> <8664e100-337c-a2f7-5aaa-7b3008012911@oracle.com> <5CE86515.1080804@oracle.com> Message-ID: <5CE8800F.20304@oracle.com> No other comments so far so here's that update : http://cr.openjdk.java.net/~prr/8224778.1/ -phil. On 5/24/19, 2:41 PM, Philip Race wrote: > Yes, I just copied that line + edited it. > I can update both lines if that is what you are asking but I'll wait a > little to see > if there are any other comments first. > > -phil. > > On 5/24/19, 2:16 PM, Erik Joelsson wrote: >> Hello Phil, >> >> Patch looks good, but the curly braces look weird in a makefile. I >> see the line below which you probably emulated also uses them, but >> they really should just be normal braces. >> >> /Erik >> >> On 2019-05-24 14:03, Phil Race wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8224778 >>> webrev : http://cr.openjdk.java.net/~prr/8224778/ >>> >>> With this fix the test can find the demo jar in its traditional >>> place as before, >>> and now also where it is placed by JIB to be invoked from RunTests.gmk >>> >>> -phil >>> From david.holmes at oracle.com Sat May 25 05:49:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 May 2019 15:49:50 +1000 Subject: RFR (XXS) 8224790: Remove Xusage.txt file Message-ID: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8224790 webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/ Before Java 7 the Xusage.txt file was used to print the "java -X" help information in English. From Java 7 this information was provided in localised format by the launcher. The Xusage.txt file was not removed at the time because it was also used by the gamma launcher. But the gamma launcher was removed in java 8 - JDK-8008772. The information in Xusage.txt has become stale and incomplete (despite several edits post Java 7). It should just be removed. Also removed the build logic that copied the file into the JDK image. Thanks, David From Alan.Bateman at oracle.com Sat May 25 06:43:58 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 May 2019 07:43:58 +0100 Subject: RFR (XXS) 8224790: Remove Xusage.txt file In-Reply-To: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> References: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> Message-ID: <102ec81e-5ff0-8f73-644a-b725747d5263@oracle.com> On 25/05/2019 06:49, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8224790 > webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/ > > Before Java 7 the Xusage.txt file was used to print the "java -X" help > information in English. From Java 7 this information was provided in > localised format by the launcher. The Xusage.txt file was not removed > at the time because it was also used by the gamma launcher. But the > gamma launcher was removed in java 8 - JDK-8008772. The information in > Xusage.txt has become stale and incomplete (despite several edits post > Java 7). It should just be removed. > > Also removed the build logic that copied the file into the JDK image. Looks good to me, I didn't realize Xusage.txt was still in the repo. -Alan From david.holmes at oracle.com Sat May 25 12:39:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 May 2019 22:39:27 +1000 Subject: RFR (XXS) 8224790: Remove Xusage.txt file In-Reply-To: <102ec81e-5ff0-8f73-644a-b725747d5263@oracle.com> References: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> <102ec81e-5ff0-8f73-644a-b725747d5263@oracle.com> Message-ID: <78c1b5fe-c803-0f4b-d38c-0a7c26857d1a@oracle.com> Hi Alan, Thanks for taking a look. On 25/05/2019 4:43 pm, Alan Bateman wrote: > On 25/05/2019 06:49, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224790 >> webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/ >> >> Before Java 7 the Xusage.txt file was used to print the "java -X" help >> information in English. From Java 7 this information was provided in >> localised format by the launcher. The Xusage.txt file was not removed >> at the time because it was also used by the gamma launcher. But the >> gamma launcher was removed in java 8 - JDK-8008772. The information in >> Xusage.txt has become stale and incomplete (despite several edits post >> Java 7). It should just be removed. >> >> Also removed the build logic that copied the file into the JDK image. > Looks good to me, I didn't realize Xusage.txt was still in the repo. Me neither. I only realized when Henry was working on "8218997: Xusage text, man help, etc doesn't mention -Xlog option" this week. Cheers, David > -Alan From daniel.daugherty at oracle.com Sat May 25 13:11:38 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 25 May 2019 09:11:38 -0400 Subject: RFR (XXS) 8224790: Remove Xusage.txt file In-Reply-To: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> References: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> Message-ID: <6b12a5e6-4333-db0f-f040-c3279e61ecd9@oracle.com> On 5/25/19 1:49 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8224790 > webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/ make/hotspot/gensrc/GenerateSources.gmk ??? No comments. src/hotspot/share/Xusage.txt ??? Deleted file. Thumbs up! When I did a sanity check grep for Xusage.txt I was surprised that it "showed up" in binary files. For example: Binary file ./build/macosx-x86_64-normal-server-release/images/jdk/jmods/java.base.jmod matches Hopefully that's an artifact of the build process?!?!? Dan > > Before Java 7 the Xusage.txt file was used to print the "java -X" help > information in English. From Java 7 this information was provided in > localised format by the launcher. The Xusage.txt file was not removed > at the time because it was also used by the gamma launcher. But the > gamma launcher was removed in java 8 - JDK-8008772. The information in > Xusage.txt has become stale and incomplete (despite several edits post > Java 7). It should just be removed. > > Also removed the build logic that copied the file into the JDK image. > > Thanks, > David From david.holmes at oracle.com Sun May 26 05:10:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 26 May 2019 15:10:14 +1000 Subject: RFR (XXS) 8224790: Remove Xusage.txt file In-Reply-To: <6b12a5e6-4333-db0f-f040-c3279e61ecd9@oracle.com> References: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> <6b12a5e6-4333-db0f-f040-c3279e61ecd9@oracle.com> Message-ID: <49571457-2e78-72ee-cbca-be56d1679c5b@oracle.com> Hi Dan, Thanks for taking a look at this. On 25/05/2019 11:11 pm, Daniel D. Daugherty wrote: > On 5/25/19 1:49 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224790 >> webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/ > > make/hotspot/gensrc/GenerateSources.gmk > ??? No comments. > > src/hotspot/share/Xusage.txt > ??? Deleted file. > > Thumbs up! > > When I did a sanity check grep for Xusage.txt I was surprised that > it "showed up" in binary files. For example: > > Binary file > ./build/macosx-x86_64-normal-server-release/images/jdk/jmods/java.base.jmod > matches > > Hopefully that's an artifact of the build process?!?!? Yes, the make rules I deleted copy the "source" file into thje built JDK image. Thanks, David > Dan > > >> >> Before Java 7 the Xusage.txt file was used to print the "java -X" help >> information in English. From Java 7 this information was provided in >> localised format by the launcher. The Xusage.txt file was not removed >> at the time because it was also used by the gamma launcher. But the >> gamma launcher was removed in java 8 - JDK-8008772. The information in >> Xusage.txt has become stale and incomplete (despite several edits post >> Java 7). It should just be removed. >> >> Also removed the build logic that copied the file into the JDK image. >> >> Thanks, >> David > From robin.westberg at oracle.com Mon May 27 07:54:56 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Mon, 27 May 2019 09:54:56 +0200 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: <439DEFFE-970A-439A-B7C8-3B8D4748041D@oracle.com> References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> <439DEFFE-970A-439A-B7C8-3B8D4748041D@oracle.com> Message-ID: Hi Igor, Looks good to me, I tried rewriting parts of an existing test to use gmock instead of a handcrafted mock, and things worked as expected! Best regards, Robin > On 24 May 2019, at 23:33, Igor Ignatyev wrote: > > @Erik, Thanks! > > @hotspot (looking at Robin), can I get another review? > > -- Igor > >> On May 24, 2019, at 8:28 AM, Erik Joelsson wrote: >> >> Thanks, looks good! >> >> /Erik >> >> On 2019-05-23 19:07, Igor Ignatyev wrote: >>> Hi Erik, >>> >>> thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. >>> >>> -- Igor >>> >>> [1] >>>> diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk >>>> --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 >>>> +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 >>>> @@ -64,8 +64,9 @@ >>>> EXCLUDES := $(JVM_EXCLUDES), \ >>>> EXCLUDE_FILES := gtestLauncher.cpp, \ >>>> EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ >>>> - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>> - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>> + EXTRA_FILES := \ >>>> + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>> + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>> EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ >>>> $(BUILD_LIBJVM_ALL_OBJS)), \ >>>> CFLAGS := $(JVM_CFLAGS) \ >>> [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ >>> >>>> On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: >>>> >>>> Hello Igor, >>>> >>>> Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. >>>> >>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>>> >>>> /Erik >>>> >>>> On 2019-05-22 22:20, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>> Hi all, >>>>> >>>>> could you please review this patch which makes mocking framework from google test available for hotspot tests? >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >>>>> testing: tier1 >>>>> webrevs: >>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>>>>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >>>>> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >>>>> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >>>>> >>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>>>>> 33 lines changed: 23 ins; 0 del; 10 mod; >>>>> * makes necessary changes in makefiles >>>>> * calls gmock framework init function >>>>> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >>>>> >>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>> all the changes together >>>>> >>>>> >>>>> thanks, >>>>> -- Igor > From prasanta.sadhukhan at oracle.com Mon May 27 09:34:30 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 May 2019 15:04:30 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar In-Reply-To: <5CE8800F.20304@oracle.com> References: <8c8dd7d8-9341-665f-61e9-f61da72db817@oracle.com> <8664e100-337c-a2f7-5aaa-7b3008012911@oracle.com> <5CE86515.1080804@oracle.com> <5CE8800F.20304@oracle.com> Message-ID: <7c9bbf55-3fa0-2cd7-af84-69ba27caf7f2@oracle.com> +1 Regards Prasanta On 25-May-19 5:06 AM, Philip Race wrote: > No other comments so far so here's that update : > http://cr.openjdk.java.net/~prr/8224778.1/ > > -phil. > > On 5/24/19, 2:41 PM, Philip Race wrote: >> Yes, I just copied that line + edited it. >> I can update both lines if that is what you are asking but I'll wait >> a little to see >> if there are any other comments first. >> >> -phil. >> >> On 5/24/19, 2:16 PM, Erik Joelsson wrote: >>> Hello Phil, >>> >>> Patch looks good, but the curly braces look weird in a makefile. I >>> see the line below which you probably emulated also uses them, but >>> they really should just be normal braces. >>> >>> /Erik >>> >>> On 2019-05-24 14:03, Phil Race wrote: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8224778 >>>> webrev : http://cr.openjdk.java.net/~prr/8224778/ >>>> >>>> With this fix the test can find the demo jar in its traditional >>>> place as before, >>>> and now also where it is placed by JIB to be invoked from RunTests.gmk >>>> >>>> -phil >>>> From robin.westberg at oracle.com Mon May 27 16:03:11 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Mon, 27 May 2019 18:03:11 +0200 Subject: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) Message-ID: Hi all, Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE. The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html]. Issue: https://bugs.openjdk.java.net/browse/JDK-8223678 Webrev: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/ Testing: Manual testing on Linux, MacOS and Windows Thanks Erik Joelsson for taking a look at an earlier version of it! Best regards, Robin From igor.ignatyev at oracle.com Tue May 28 02:47:13 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 May 2019 19:47:13 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> <439DEFFE-970A-439A-B7C8-3B8D4748041D@oracle.com> Message-ID: <08CB35D2-CA5B-4AF7-B223-CC22DFCEF106@oracle.com> thanks Robin! pushed. -- Igor > On May 27, 2019, at 12:54 AM, Robin Westberg wrote: > > Hi Igor, > > Looks good to me, I tried rewriting parts of an existing test to use gmock instead of a handcrafted mock, and things worked as expected! > > Best regards, > Robin > >> On 24 May 2019, at 23:33, Igor Ignatyev wrote: >> >> @Erik, Thanks! >> >> @hotspot (looking at Robin), can I get another review? >> >> -- Igor >> >>> On May 24, 2019, at 8:28 AM, Erik Joelsson wrote: >>> >>> Thanks, looks good! >>> >>> /Erik >>> >>> On 2019-05-23 19:07, Igor Ignatyev wrote: >>>> Hi Erik, >>>> >>>> thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. >>>> >>>> -- Igor >>>> >>>> [1] >>>>> diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk >>>>> --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 >>>>> +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 >>>>> @@ -64,8 +64,9 @@ >>>>> EXCLUDES := $(JVM_EXCLUDES), \ >>>>> EXCLUDE_FILES := gtestLauncher.cpp, \ >>>>> EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ >>>>> - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>>> - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>>> + EXTRA_FILES := \ >>>>> + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>>> + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>>> EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ >>>>> $(BUILD_LIBJVM_ALL_OBJS)), \ >>>>> CFLAGS := $(JVM_CFLAGS) \ >>>> [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ >>>> >>>>> On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: >>>>> >>>>> Hello Igor, >>>>> >>>>> Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. >>>>> >>>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>>>> >>>>> /Erik >>>>> >>>>> On 2019-05-22 22:20, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>>> Hi all, >>>>>> >>>>>> could you please review this patch which makes mocking framework from google test available for hotspot tests? >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >>>>>> testing: tier1 >>>>>> webrevs: >>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>>>>>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >>>>>> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >>>>>> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >>>>>> >>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>>>>>> 33 lines changed: 23 ins; 0 del; 10 mod; >>>>>> * makes necessary changes in makefiles >>>>>> * calls gmock framework init function >>>>>> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >>>>>> >>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>>> all the changes together >>>>>> >>>>>> >>>>>> thanks, >>>>>> -- Igor >> > From erik.joelsson at oracle.com Tue May 28 13:35:43 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 May 2019 06:35:43 -0700 Subject: RFR (XXS) 8224790: Remove Xusage.txt file In-Reply-To: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> References: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> Message-ID: <25272e47-df88-edb7-20f7-ecda0f44acc2@oracle.com> Looks good! /Erik On 2019-05-24 22:49, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8224790 > webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/ > > Before Java 7 the Xusage.txt file was used to print the "java -X" help > information in English. From Java 7 this information was provided in > localised format by the launcher. The Xusage.txt file was not removed > at the time because it was also used by the gamma launcher. But the > gamma launcher was removed in java 8 - JDK-8008772. The information in > Xusage.txt has become stale and incomplete (despite several edits post > Java 7). It should just be removed. > > Also removed the build logic that copied the file into the JDK image. > > Thanks, > David From erik.joelsson at oracle.com Tue May 28 13:36:20 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 May 2019 06:36:20 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar In-Reply-To: <5CE8800F.20304@oracle.com> References: <8c8dd7d8-9341-665f-61e9-f61da72db817@oracle.com> <8664e100-337c-a2f7-5aaa-7b3008012911@oracle.com> <5CE86515.1080804@oracle.com> <5CE8800F.20304@oracle.com> Message-ID: Looks good, thanks! /Erik On 2019-05-24 16:36, Philip Race wrote: > No other comments so far so here's that update : > http://cr.openjdk.java.net/~prr/8224778.1/ > > -phil. > > On 5/24/19, 2:41 PM, Philip Race wrote: >> Yes, I just copied that line + edited it. >> I can update both lines if that is what you are asking but I'll wait >> a little to see >> if there are any other comments first. >> >> -phil. >> >> On 5/24/19, 2:16 PM, Erik Joelsson wrote: >>> Hello Phil, >>> >>> Patch looks good, but the curly braces look weird in a makefile. I >>> see the line below which you probably emulated also uses them, but >>> they really should just be normal braces. >>> >>> /Erik >>> >>> On 2019-05-24 14:03, Phil Race wrote: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8224778 >>>> webrev : http://cr.openjdk.java.net/~prr/8224778/ >>>> >>>> With this fix the test can find the demo jar in its traditional >>>> place as before, >>>> and now also where it is placed by JIB to be invoked from RunTests.gmk >>>> >>>> -phil >>>> From erik.joelsson at oracle.com Tue May 28 13:52:43 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 May 2019 06:52:43 -0700 Subject: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: References: Message-ID: Hello Robin, Looks good. Adding of ide.md is very nice, but could you try to format it like testing.md and building.md in regards to line lengths? I believe we are trying for 80 chars in those to make them read reasonably in a standard editor. /Erik On 2019-05-27 09:03, Robin Westberg wrote: > Hi all, > > Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE. > > The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html]. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8223678 > > Webrev: > https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/ > > Testing: > Manual testing on Linux, MacOS and Windows > > Thanks Erik Joelsson for taking a look at an earlier version of it! > > Best regards, > Robin From volker.simonis at gmail.com Tue May 28 15:33:07 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 28 May 2019 17:33:07 +0200 Subject: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: References: Message-ID: Hi Robin, thanks a lot for doing this! I have just a quick question. Do you know if any of the VSC indexers (default, clangd) support call hierarchies (i.e. "called by", "callers" of a function/method) and "used by" for variables/class fields? Regards, Volker On Mon, May 27, 2019 at 6:03 PM Robin Westberg wrote: > > Hi all, > > Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE. > > The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html]. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8223678 > > Webrev: > https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/ > > Testing: > Manual testing on Linux, MacOS and Windows > > Thanks Erik Joelsson for taking a look at an earlier version of it! > > Best regards, > Robin From zuismanm at gmail.com Tue May 28 16:15:54 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Tue, 28 May 2019 19:15:54 +0300 Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 Message-ID: I am trying to build OPEN jdk 11 on cygwin with MSVC 2017 _________________________________________________________________________ *c:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): warning C4577: 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHscmake[3]: *** [lib/CompileJvm.gmk:151: /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj] Error 1make[3]: *** Waiting for unfinished jobs....make[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2make[2]: *** Waiting for unfinished jobs....ERROR: Build failed for target 'default (exploded-image)' in configuration 'windows-x86_64-normal-server-release' (exit code 2)=== Output from failing command(s) repeated here ===* For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:BUILD_LIBJVM_pch.cppc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): error C2220: warning treated as error - no 'object' file generatedc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): warning C4577: 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHsc ... (rest of output omitted)* All command lines available in /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/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]: *** [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305: main] Error 2make: *** [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186: default] Error 2* From shade at redhat.com Tue May 28 16:34:51 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 May 2019 18:34:51 +0200 Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 In-Reply-To: References: Message-ID: <5b730596-b7d9-df39-8aef-e88f4e2eb9af@redhat.com> On 5/28/19 6:15 PM, Moshe Zuisman wrote: > warning C4577: 'noexcept' used with no exception handling mode specified; Somebody else can chime in if this is a legit warning. > error C2220: warning treated as error - no 'object' file ...but this tells that you might try to configure with --disable-warnings-as-errors. Do test the resulting binary to verify it was actually compiled fine. -- Thanks, -Aleksey From zuismanm at gmail.com Tue May 28 19:55:01 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Tue, 28 May 2019 22:55:01 +0300 Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 In-Reply-To: <5b730596-b7d9-df39-8aef-e88f4e2eb9af@redhat.com> References: <5b730596-b7d9-df39-8aef-e88f4e2eb9af@redhat.com> Message-ID: I configure with default options: *sh ./configure --with-boot-jdk=/cygdrive/c/jdk-11.0.3* By the way - ordinary VC solutions - compiles form MSVC IDE with no problem ??, 28 ??? 2019 ?. ? 19:34, Aleksey Shipilev : > On 5/28/19 6:15 PM, Moshe Zuisman wrote: > > warning C4577: 'noexcept' used with no exception handling mode specified; > > Somebody else can chime in if this is a legit warning. > > > error C2220: warning treated as error - no 'object' file > > ...but this tells that you might try to configure with > --disable-warnings-as-errors. Do test the > resulting binary to verify it was actually compiled fine. > > -- > Thanks, > -Aleksey > > From david.holmes at oracle.com Tue May 28 22:18:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2019 08:18:12 +1000 Subject: RFR (XXS) 8224790: Remove Xusage.txt file In-Reply-To: <25272e47-df88-edb7-20f7-ecda0f44acc2@oracle.com> References: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> <25272e47-df88-edb7-20f7-ecda0f44acc2@oracle.com> Message-ID: Thanks Erik! David On 28/05/2019 11:35 pm, Erik Joelsson wrote: > Looks good! > > /Erik > > On 2019-05-24 22:49, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224790 >> webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/ >> >> Before Java 7 the Xusage.txt file was used to print the "java -X" help >> information in English. From Java 7 this information was provided in >> localised format by the launcher. The Xusage.txt file was not removed >> at the time because it was also used by the gamma launcher. But the >> gamma launcher was removed in java 8 - JDK-8008772. The information in >> Xusage.txt has become stale and incomplete (despite several edits post >> Java 7). It should just be removed. >> >> Also removed the build logic that copied the file into the JDK image. >> >> Thanks, >> David From david.holmes at oracle.com Wed May 29 04:32:38 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2019 14:32:38 +1000 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: <08CB35D2-CA5B-4AF7-B223-CC22DFCEF106@oracle.com> References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> <439DEFFE-970A-439A-B7C8-3B8D4748041D@oracle.com> <08CB35D2-CA5B-4AF7-B223-CC22DFCEF106@oracle.com> Message-ID: <18a4b4c6-9572-2adf-d795-d108eae8649b@oracle.com> Hi Igor, FYI this seems to have broken the arm32 build. I've filed: https://bugs.openjdk.java.net/browse/JDK-8224945 David On 28/05/2019 12:47 pm, Igor Ignatyev wrote: > thanks Robin! pushed. > -- Igor > >> On May 27, 2019, at 12:54 AM, Robin Westberg wrote: >> >> Hi Igor, >> >> Looks good to me, I tried rewriting parts of an existing test to use gmock instead of a handcrafted mock, and things worked as expected! >> >> Best regards, >> Robin >> >>> On 24 May 2019, at 23:33, Igor Ignatyev wrote: >>> >>> @Erik, Thanks! >>> >>> @hotspot (looking at Robin), can I get another review? >>> >>> -- Igor >>> >>>> On May 24, 2019, at 8:28 AM, Erik Joelsson wrote: >>>> >>>> Thanks, looks good! >>>> >>>> /Erik >>>> >>>> On 2019-05-23 19:07, Igor Ignatyev wrote: >>>>> Hi Erik, >>>>> >>>>> thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. >>>>> >>>>> -- Igor >>>>> >>>>> [1] >>>>>> diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk >>>>>> --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 >>>>>> +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 >>>>>> @@ -64,8 +64,9 @@ >>>>>> EXCLUDES := $(JVM_EXCLUDES), \ >>>>>> EXCLUDE_FILES := gtestLauncher.cpp, \ >>>>>> EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ >>>>>> - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>>>> - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>>>> + EXTRA_FILES := \ >>>>>> + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>>>> + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>>>> EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ >>>>>> $(BUILD_LIBJVM_ALL_OBJS)), \ >>>>>> CFLAGS := $(JVM_CFLAGS) \ >>>>> [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ >>>>> >>>>>> On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: >>>>>> >>>>>> Hello Igor, >>>>>> >>>>>> Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. >>>>>> >>>>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2019-05-22 22:20, Igor Ignatyev wrote: >>>>>>> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>>>> Hi all, >>>>>>> >>>>>>> could you please review this patch which makes mocking framework from google test available for hotspot tests? >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >>>>>>> testing: tier1 >>>>>>> webrevs: >>>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>>>>>>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >>>>>>> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >>>>>>> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >>>>>>> >>>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>>>>>>> 33 lines changed: 23 ins; 0 del; 10 mod; >>>>>>> * makes necessary changes in makefiles >>>>>>> * calls gmock framework init function >>>>>>> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >>>>>>> >>>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>>>> all the changes together >>>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> -- Igor >>> >> > From david.holmes at oracle.com Wed May 29 05:35:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2019 15:35:41 +1000 Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 In-Reply-To: References: Message-ID: Hi Moshe, On 29/05/2019 2:15 am, Moshe Zuisman wrote: > I am trying to build OPEN jdk 11 on cygwin with MSVC 2017 > _________________________________________________________________________ VS 2017 is the official supported compiler for building OpenJDK 11 [1] and we don't see any issues. What version of the 11u source are you trying to compile? David [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > *c:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > warning C4577: 'noexcept' used with no exception handling mode specified; > termination on exception is not guaranteed. Specify /EHscmake[3]: *** > [lib/CompileJvm.gmk:151: > /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj] > Error 1make[3]: *** Waiting for unfinished jobs....make[2]: *** > [make/Main.gmk:257: hotspot-server-libs] Error 2make[2]: *** Waiting for > unfinished jobs....ERROR: Build failed for target 'default > (exploded-image)' in configuration 'windows-x86_64-normal-server-release' > (exit code 2)=== Output from failing command(s) repeated here ===* For > target > hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:BUILD_LIBJVM_pch.cppc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > error C2220: warning treated as error - no 'object' file > generatedc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > warning C4577: 'noexcept' used with no exception handling mode specified; > termination on exception is not guaranteed. Specify /EHsc ... (rest of > output omitted)* All command lines available in > /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/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]: *** > [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305: > main] Error 2make: *** > [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186: > default] Error 2* > From zuismanm at gmail.com Wed May 29 06:40:57 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Wed, 29 May 2019 09:40:57 +0300 Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 In-Reply-To: References: Message-ID: I am using http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281 ??, 29 ??? 2019 ?. ? 08:35, David Holmes : > Hi Moshe, > > On 29/05/2019 2:15 am, Moshe Zuisman wrote: > > I am trying to build OPEN jdk 11 on cygwin with MSVC 2017 > > _________________________________________________________________________ > > VS 2017 is the official supported compiler for building OpenJDK 11 [1] > and we don't see any issues. What version of the 11u source are you > trying to compile? > > David > > [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > > > > > *c:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > > warning C4577: 'noexcept' used with no exception handling mode specified; > > termination on exception is not guaranteed. Specify /EHscmake[3]: *** > > [lib/CompileJvm.gmk:151: > > > /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj] > > Error 1make[3]: *** Waiting for unfinished jobs....make[2]: *** > > [make/Main.gmk:257: hotspot-server-libs] Error 2make[2]: *** Waiting for > > unfinished jobs....ERROR: Build failed for target 'default > > (exploded-image)' in configuration 'windows-x86_64-normal-server-release' > > (exit code 2)=== Output from failing command(s) repeated here ===* For > > target > > > hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:BUILD_LIBJVM_pch.cppc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > > error C2220: warning treated as error - no 'object' file > > > generatedc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > > warning C4577: 'noexcept' used with no exception handling mode specified; > > termination on exception is not guaranteed. Specify /EHsc ... (rest of > > output omitted)* All command lines available in > > > /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/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]: *** > > > [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305: > > main] Error 2make: *** > > > [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186: > > default] Error 2* > > > From nick.gasson at arm.com Wed May 29 10:26:37 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 29 May 2019 18:26:37 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 Message-ID: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> Hi, Please review this set of fixes to building hotspot with GCC 8.3 or Clang 7.0 on AArch64. Bug: https://bugs.openjdk.java.net/browse/JDK-8224851 Webrev: http://cr.openjdk.java.net/~ngasson/8224851/webrev.0/ Ran jtreg with no new failures. This first one is with GCC 8.3: /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp: In function 'void pf(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)': /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp:775:35: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class RegisterMap' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess] memcpy(reg_map, &map, sizeof map); ^ RegisterMap is non-POD because its base class AllocatedObj has virtual methods, so we need to use copy-assignment rather than memcpy. But because we're allocating reg_map with os::malloc we ought to use placement new to properly construct it first. But we can't do that because RegisterMap inherits from StackObj which disallows new. So I just put in some casts to void * to silence the warning. I can't see where `pf' and `internal_pf' are used - perhaps they can be called manually from the debugger? If no one uses them maybe they should be deleted? The remaining warnings / errors are with Clang 7.0. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:279:22: error: & has lower precedence than ==; == will be evaluated first [-Werror,-Wparentheses] assert_cond(bits & mask == mask); ^~~~~~~~~~~~~~ To preserve the behaviour we should write `bits & (mask == mask)' but I don't think this was what was intended so I changed it to `(bits & mask) == mask'. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp:44:25: error: redeclaration of using declaration using MacroAssembler::call_VM_leaf_base; ~~~~~~~~~~~~~~~~^ This using declaration appears twice in a row. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/aarch64.ad:13866:80: error: invalid suffix 'D' on floating constant __ fcmps(as_FloatRegister(opnd_array(1)->reg(ra_,this,idx1)/* src1 */), 0.0D); ^ The "d" or "D" suffix on floating point literals is not in C++98. I believe it comes from an extension to C to support decimal floating point? Anyway it's not necessary here. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp:429:66: error: implicit conversion of NULL constant to 'bool' [-Werror,-Wnull-conversion] arithmetic_op_fpu(x->op(), reg, left.result(), right.result(), NULL); ~~~~~~~~~~~~~~~~~ ^~~~ false The NULL here is for the `bool is_strictfp' argument to LIRGenerator::arithmetic_op_fpu. Changing it to `false' would preserve the existing behaviour but it seems like it should be `x->is_strictfp()' to match other platforms. As a consequence of this we need to handle the lir_{div,mul}_scriptfp opcodes in LIR_Assembler::arith_op, but these just fall through to the non-strictfp variants so there should be no behaviour change. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp:1074:24: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses] if (is_unordered && op->cond() == lir_cond_equal ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Added parenthesis to make this explicit. No behaviour change. /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.s:162:32: error: index must be a multiple of 8 in range [0, 32760]. prfm pldl1keep, [s, #-256] ^ The immediate offset in `prfm' gets zero-extended to 64-bits and then left shifted three places so can only be unsigned. GNU as actually assembles [s, #-256] the same as [s]: 0: f9800000 prfm pldl1keep, [x0] Seems like GNU as ought to report an error here instead. I've replaced this with `prfum' which has a sign-extended offset. /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:43:39: error: cannot initialize a parameter of type 'char *' with an lvalue of type 'unsigned long' return __sync_add_and_fetch(dest, add_value); ^~~~~~~~~ If the add_and_fetch template is instantiated with I=integer and D=pointer then we need an explicit cast here. /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:679:8: error: conflicting types for '_Copy_conjoint_jshorts_atomic' void _Copy_conjoint_jshorts_atomic(jshort* from, jshort* to, size_t count) { ^ This family of functions is declared with const `from' pointer but in the definition it is non-const. Made it const everywhere. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp:177:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (p = strchr(buf, ':')) { ~~^~~~~~~~~~~~~~~~~~ Put parentheses around the argument. No functional change. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:2684:17: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] offset &= -1<<12; ~~^ Rewrote as ~((1<<12) - 1) which matches the masks used in the rest of the function. /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:103:20: error: variable 'esp' is uninitialized when used here [-Werror,-Wuninitialized] return (address) esp; ^~~ /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:101:21: note: initialize the variable 'esp' to silence this warning register void *esp __asm__ (SPELL_REG_SP); ^ = nullptr We could silence the -Wuninitialized warning for this function, but that doesn't help much because Clang then compiles os::current_stack_pointer() into: 0000000000000000 <_ZN2os21current_stack_pointerEv>: 0: d65f03c0 ret Whereas with GCC we get: 0000000000000250 <_ZN2os21current_stack_pointerEv>: 250: 910003e0 mov x0, sp 254: d65f03c0 ret Added some inline assembly to explicitly move sp into the result #ifdef __clang__. Same with _get_previous_fp(). Thanks, Nick From aph at redhat.com Wed May 29 13:01:15 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 May 2019 14:01:15 +0100 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> Message-ID: On 5/29/19 11:26 AM, Nick Gasson wrote: > Please review this set of fixes to building hotspot with GCC 8.3 or > Clang 7.0 on AArch64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224851 > Webrev: http://cr.openjdk.java.net/~ngasson/8224851/webrev.0/ > > Ran jtreg with no new failures. Oh dear. Experience has shown me (and probably you, too) that this is one of the most error-prone parts of software development. Many very serious failures have been recorded when trying to shut up compilers. These failures have even included major security breaches. With that, let's press on with a heavy heart... > > This first one is with GCC 8.3: > > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp: In function 'void pf(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)': > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp:775:35: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class RegisterMap' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess] > memcpy(reg_map, &map, sizeof map); > ^ > > RegisterMap is non-POD because its base class AllocatedObj has virtual > methods, so we need to use copy-assignment rather than memcpy. But > because we're allocating reg_map with os::malloc we ought to use > placement new to properly construct it first. But we can't do that > because RegisterMap inherits from StackObj which disallows new. So I > just put in some casts to void * to silence the warning. We can't do that. It seems to me that this must be Undefined Behaviour, and we must never attempt to cover up UB with casts. > I can't see where `pf' and `internal_pf' are used - perhaps they can be > called manually from the debugger? They're debugger commands. That's why they have external C linkage. > If no one uses them maybe they should be deleted? Perhaps so. We have the debugger command pfl() which does all the frame printing I find I ever need. > The remaining warnings / errors are with Clang 7.0. > > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:279:22: error: & has lower precedence than ==; == will be evaluated first [-Werror,-Wparentheses] > assert_cond(bits & mask == mask); > ^~~~~~~~~~~~~~ > > To preserve the behaviour we should write `bits & (mask == mask)' but I > don't think this was what was intended so I changed it to > `(bits & mask) == mask'. That's right. It's supposed to check that the field being read from an instruction has already been set. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp:44:25: error: redeclaration of using declaration > using MacroAssembler::call_VM_leaf_base; > ~~~~~~~~~~~~~~~~^ > > This using declaration appears twice in a row. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/aarch64.ad:13866:80: error: invalid suffix 'D' on floating constant > __ fcmps(as_FloatRegister(opnd_array(1)->reg(ra_,this,idx1)/* src1 */), 0.0D); > ^ > > The "d" or "D" suffix on floating point literals is not in C++98. I > believe it comes from an extension to C to support decimal floating > point? Anyway it's not necessary here. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp:429:66: error: implicit conversion of NULL constant to 'bool' [-Werror,-Wnull-conversion] > arithmetic_op_fpu(x->op(), reg, left.result(), right.result(), NULL); > ~~~~~~~~~~~~~~~~~ ^~~~ > false > > The NULL here is for the `bool is_strictfp' argument to > LIRGenerator::arithmetic_op_fpu. Changing it to `false' would preserve > the existing behaviour but it seems like it should be `x->is_strictfp()' > to match other platforms. OK, use x->is_strictfp(). I don't think that it can possibly make any difference on AArch64. > As a consequence of this we need to handle the lir_{div,mul}_scriptfp > opcodes in LIR_Assembler::arith_op, but these just fall through to the > non-strictfp variants so there should be no behaviour change. Yep. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp:1074:24: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses] > if (is_unordered && op->cond() == lir_cond_equal > ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Added parenthesis to make this explicit. No behaviour change. OK. I don't quite get what this is for, but I guess it shuts the compiler up. > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.s:162:32: error: index must be a multiple of 8 in range [0, 32760]. > prfm pldl1keep, [s, #-256] > ^ > > The immediate offset in `prfm' gets zero-extended to 64-bits and then > left shifted three places so can only be unsigned. GNU as actually > assembles [s, #-256] the same as [s]: > > 0: f9800000 prfm pldl1keep, [x0] > > Seems like GNU as ought to report an error here instead. I've replaced > this with `prfum' which has a sign-extended offset. OK. > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:43:39: error: cannot initialize a parameter of type 'char *' with an lvalue of type 'unsigned long' > return __sync_add_and_fetch(dest, add_value); > ^~~~~~~~~ > > If the add_and_fetch template is instantiated with I=integer and > D=pointer then we need an explicit cast here. Please don't. Please have a look at where this happens and fix the types there, as appropriate. What do other ports do? > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:679:8: error: conflicting types for '_Copy_conjoint_jshorts_atomic' > void _Copy_conjoint_jshorts_atomic(jshort* from, jshort* to, size_t count) { > ^ > > This family of functions is declared with const `from' pointer but in > the definition it is non-const. Made it const everywhere. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp:177:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] > if (p = strchr(buf, ':')) { > ~~^~~~~~~~~~~~~~~~~~ > > Put parentheses around the argument. No functional change. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:2684:17: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] > offset &= -1<<12; > ~~^ Oh FFS. :-) This is perfectly legal in GCC and probably clang as well. > Rewrote as ~((1<<12) - 1) which matches the masks used in the rest of > the function. Let's not. All we have to do to create a mask is is use -1u<<12. > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:103:20: error: variable 'esp' is uninitialized when used here [-Werror,-Wuninitialized] > return (address) esp; > ^~~ > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:101:21: note: initialize the variable 'esp' to silence this warning > register void *esp __asm__ (SPELL_REG_SP); > ^ > = nullptr > > We could silence the -Wuninitialized warning for this function, but that > doesn't help much because Clang then compiles > os::current_stack_pointer() into: > > 0000000000000000 <_ZN2os21current_stack_pointerEv>: > 0: d65f03c0 ret > > Whereas with GCC we get: > > 0000000000000250 <_ZN2os21current_stack_pointerEv>: > 250: 910003e0 mov x0, sp > 254: d65f03c0 ret > > Added some inline assembly to explicitly move sp into the result #ifdef > __clang__. Same with _get_previous_fp(). This is all looking extremely fragile. We'd need to look at what the usages of this code are and trace through. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed May 29 13:12:53 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 May 2019 14:12:53 +0100 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> Message-ID: <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> On 5/29/19 11:26 AM, Nick Gasson wrote: > Please review this set of fixes to building hotspot with GCC 8.3 or > Clang 7.0 on AArch64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224851 > Webrev: http://cr.openjdk.java.net/~ngasson/8224851/webrev.0/ > > Ran jtreg with no new failures. Oh dear. Experience has shown me (and probably you, too) that this is one of the most error-prone parts of software development. Many very serious failures have been caused by trying to shut up compilers. These failures have even included major security breaches. With that, let's press on with a heavy heart... > > This first one is with GCC 8.3: > > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp: In function 'void pf(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)': > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp:775:35: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class RegisterMap' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess] > memcpy(reg_map, &map, sizeof map); > ^ > > RegisterMap is non-POD because its base class AllocatedObj has virtual > methods, so we need to use copy-assignment rather than memcpy. But > because we're allocating reg_map with os::malloc we ought to use > placement new to properly construct it first. But we can't do that > because RegisterMap inherits from StackObj which disallows new. So I > just put in some casts to void * to silence the warning. We can't do that. It seems to me that this must be Undefined Behaviour, and we must never attempt to cover up UB with casts. > I can't see where `pf' and `internal_pf' are used - perhaps they can be > called manually from the debugger? They're debugger commands. That's why they have external C linkage. > If no one uses them maybe they should be deleted? Perhaps so. We have the debugger command pfl() which does all the frame printing I find I ever need. > The remaining warnings / errors are with Clang 7.0. > > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:279:22: error: & has lower precedence than ==; == will be evaluated first [-Werror,-Wparentheses] > assert_cond(bits & mask == mask); > ^~~~~~~~~~~~~~ > > To preserve the behaviour we should write `bits & (mask == mask)' but I > don't think this was what was intended so I changed it to > `(bits & mask) == mask'. That's right. It's supposed to check that the field being read from an instruction has already been set. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp:44:25: error: redeclaration of using declaration > using MacroAssembler::call_VM_leaf_base; > ~~~~~~~~~~~~~~~~^ > > This using declaration appears twice in a row. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/aarch64.ad:13866:80: error: invalid suffix 'D' on floating constant > __ fcmps(as_FloatRegister(opnd_array(1)->reg(ra_,this,idx1)/* src1 */), 0.0D); > ^ > > The "d" or "D" suffix on floating point literals is not in C++98. I > believe it comes from an extension to C to support decimal floating > point? Anyway it's not necessary here. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp:429:66: error: implicit conversion of NULL constant to 'bool' [-Werror,-Wnull-conversion] > arithmetic_op_fpu(x->op(), reg, left.result(), right.result(), NULL); > ~~~~~~~~~~~~~~~~~ ^~~~ > false > > The NULL here is for the `bool is_strictfp' argument to > LIRGenerator::arithmetic_op_fpu. Changing it to `false' would preserve > the existing behaviour but it seems like it should be `x->is_strictfp()' > to match other platforms. OK, use x->is_strictfp(). I don't think that it can possibly make any difference on AArch64. > As a consequence of this we need to handle the lir_{div,mul}_scriptfp > opcodes in LIR_Assembler::arith_op, but these just fall through to the > non-strictfp variants so there should be no behaviour change. Yep. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp:1074:24: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses] > if (is_unordered && op->cond() == lir_cond_equal > ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Added parenthesis to make this explicit. No behaviour change. OK. I don't quite get what this is for, but I guess it shuts the compiler up and is harmless. > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.s:162:32: error: index must be a multiple of 8 in range [0, 32760]. > prfm pldl1keep, [s, #-256] > ^ > > The immediate offset in `prfm' gets zero-extended to 64-bits and then > left shifted three places so can only be unsigned. GNU as actually > assembles [s, #-256] the same as [s]: > > 0: f9800000 prfm pldl1keep, [x0] > > Seems like GNU as ought to report an error here instead. I've replaced > this with `prfum' which has a sign-extended offset. OK. > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:43:39: error: cannot initialize a parameter of type 'char *' with an lvalue of type 'unsigned long' > return __sync_add_and_fetch(dest, add_value); > ^~~~~~~~~ > > If the add_and_fetch template is instantiated with I=integer and > D=pointer then we need an explicit cast here. Please don't. Please have a look at where this happens and fix the types there, as appropriate. What do other ports do? > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:679:8: error: conflicting types for '_Copy_conjoint_jshorts_atomic' > void _Copy_conjoint_jshorts_atomic(jshort* from, jshort* to, size_t count) { > ^ > > This family of functions is declared with const `from' pointer but in > the definition it is non-const. Made it const everywhere. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp:177:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] > if (p = strchr(buf, ':')) { > ~~^~~~~~~~~~~~~~~~~~ > > Put parentheses around the argument. No functional change. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:2684:17: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] > offset &= -1<<12; > ~~^ Oh FFS. :-) This is perfectly legal in GCC and probably clang as well. > Rewrote as ~((1<<12) - 1) which matches the masks used in the rest of > the function. Let's not. All we have to do to create a mask is is use -1u<<12. I would challenge anyone to figure out without using a pencil what the effect of &= ~(((1<<12)-1)<<12) might be. > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:103:20: error: variable 'esp' is uninitialized when used here [-Werror,-Wuninitialized] > return (address) esp; > ^~~ > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:101:21: note: initialize the variable 'esp' to silence this warning > register void *esp __asm__ (SPELL_REG_SP); > ^ > = nullptr > > We could silence the -Wuninitialized warning for this function, but that > doesn't help much because Clang then compiles > os::current_stack_pointer() into: > > 0000000000000000 <_ZN2os21current_stack_pointerEv>: > 0: d65f03c0 ret > > Whereas with GCC we get: > > 0000000000000250 <_ZN2os21current_stack_pointerEv>: > 250: 910003e0 mov x0, sp > 254: d65f03c0 ret > > Added some inline assembly to explicitly move sp into the result #ifdef > __clang__. Same with _get_previous_fp(). This is all looking extremely fragile. We'd need to look at what the usages of this code are and trace through. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From robin.westberg at oracle.com Wed May 29 13:43:51 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 29 May 2019 15:43:51 +0200 Subject: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: References: Message-ID: <43102FEE-DF34-4D9B-A503-155F80E8D967@oracle.com> Hi Volker, > On 28 May 2019, at 17:33, Volker Simonis wrote: > > Hi Robin, > > thanks a lot for doing this! > > I have just a quick question. Do you know if any of the VSC indexers > (default, clangd) support call hierarchies (i.e. "called by", > "callers" of a function/method) and "used by" for variables/class > fields? Sure, I can make a quick summary of the various pros and cons of the indexers that I?ve found so far. They are all moving pretty fast though, so didn?t think it was a good fit for the documentation file. In general, VS Code itself only just recently gained proper support for displaying call hierarchies: https://code.visualstudio.com/updates/v1_33#_call-hierarchy - but alternative indexers have worked around this by showing them differently. Default (Microsoft - C/C++ for Visual Studio Code) + Easy to setup, as no additional dependencies are needed + Good ?go to definition?, the only one that can make sense of the template+macro stuff in log.hpp for example - Find references (used by) not done yet (said to be coming in the June update: https://github.com/microsoft/vscode-cpptools/issues/15) - Call hierarchies also not there (scheduled for September apparently: https://github.com/microsoft/vscode-cpptools/issues/16) clangd + Actively developed and part of the llvm/clang project + Support for find references - ..but not call hierarchies yet - Full project indexing is still flagged as experimental, and currently seems to fail when editing commonly used header files for example Full feature list: https://clang.llvm.org/extra/clangd/Features.html#complete-list-of-features rtags This is currently the most feature-complete indexer I think. But the VS Code integration is a bit minimal and not part of the rtags project itself, and it is missing things like indexer progress. + The indexer is actively developed and has been around for quite some time - You will probably have to build the indexer from source + Full support for call hierarchies and find references - VS Code integration a bit limited, missing convenience features like switch between header/source file, showing method/class documentation on hover. There are even more indexers of course, a promising one used to be ?cquery", but that project seems to be defunct now. It lives on in the ?ccls" indexer, but ithat one is a bit tricky to configure unless you use clang for building the JDK as well. So in summary, after the summer the default indexer might be the obvious best choice, but right now it depends on which features you think are the most important I guess.. Best regards, Robin > > Regards, > Volker > > On Mon, May 27, 2019 at 6:03 PM Robin Westberg > wrote: >> >> Hi all, >> >> Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE. >> >> The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html]. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8223678 >> >> Webrev: >> https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/ >> >> Testing: >> Manual testing on Linux, MacOS and Windows >> >> Thanks Erik Joelsson for taking a look at an earlier version of it! >> >> Best regards, >> Robin From robin.westberg at oracle.com Wed May 29 13:52:22 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 29 May 2019 15:52:22 +0200 Subject: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: References: Message-ID: <01BD2934-BC92-42A4-B6DC-C977359F0FA2@oracle.com> Hi Erik, Thanks for taking a look! > On 28 May 2019, at 15:52, Erik Joelsson wrote: > > Hello Robin, > > Looks good. > > Adding of ide.md is very nice, but could you try to format it like testing.md and building.md in regards to line lengths? I believe we are trying for 80 chars in those to make them read reasonably in a standard editor. Sure, did a bit of reflowing and updated some formatting in order to look more like the other .md files. Webrevs: - Full: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.02/ - Inc: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01-02/ Best regards, Robin > > /Erik > > On 2019-05-27 09:03, Robin Westberg wrote: >> Hi all, >> >> Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE. >> >> The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html]. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8223678 >> >> Webrev: >> https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/ >> >> Testing: >> Manual testing on Linux, MacOS and Windows >> >> Thanks Erik Joelsson for taking a look at an earlier version of it! >> >> Best regards, >> Robin From volker.simonis at gmail.com Wed May 29 14:01:24 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 May 2019 16:01:24 +0200 Subject: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: <43102FEE-DF34-4D9B-A503-155F80E8D967@oracle.com> References: <43102FEE-DF34-4D9B-A503-155F80E8D967@oracle.com> Message-ID: On Wed, May 29, 2019 at 3:43 PM Robin Westberg wrote: > > Hi Volker, > > > On 28 May 2019, at 17:33, Volker Simonis wrote: > > > > Hi Robin, > > > > thanks a lot for doing this! > > > > I have just a quick question. Do you know if any of the VSC indexers > > (default, clangd) support call hierarchies (i.e. "called by", > > "callers" of a function/method) and "used by" for variables/class > > fields? > > Sure, I can make a quick summary of the various pros and cons of the indexers that I?ve found so far. They are all moving pretty fast though, so didn?t think it was a good fit for the documentation file. > > In general, VS Code itself only just recently gained proper support for displaying call hierarchies: https://code.visualstudio.com/updates/v1_33#_call-hierarchy - but alternative indexers have worked around this by showing them differently. > > Default (Microsoft - C/C++ for Visual Studio Code) > + Easy to setup, as no additional dependencies are needed > + Good ?go to definition?, the only one that can make sense of the template+macro stuff in log.hpp for example > - Find references (used by) not done yet (said to be coming in the June update: https://github.com/microsoft/vscode-cpptools/issues/15) > - Call hierarchies also not there (scheduled for September apparently: https://github.com/microsoft/vscode-cpptools/issues/16) > > clangd > + Actively developed and part of the llvm/clang project > + Support for find references > - ..but not call hierarchies yet > - Full project indexing is still flagged as experimental, and currently seems to fail when editing commonly used header files for example > > Full feature list: https://clang.llvm.org/extra/clangd/Features.html#complete-list-of-features > > rtags > This is currently the most feature-complete indexer I think. But the VS Code integration is a bit minimal and not part of the rtags project itself, and it is missing things like indexer progress. > + The indexer is actively developed and has been around for quite some time > - You will probably have to build the indexer from source > + Full support for call hierarchies and find references > - VS Code integration a bit limited, missing convenience features like switch between header/source file, showing method/class documentation on hover. > > There are even more indexers of course, a promising one used to be ?cquery", but that project seems to be defunct now. It lives on in the ?ccls" indexer, but ithat one is a bit tricky to configure unless you use clang for building the JDK as well. > > So in summary, after the summer the default indexer might be the obvious best choice, but right now it depends on which features you think are the most important I guess.. > Hi Robin, thanks a lot for the great summary! Incidentally I've just did some Google research as well and basically came to the same conclusion. "Cquery" seemed quite promising and also pretends to have call hierarchies. But it seems to be defunct and I've also found some bug reports about problems with the call hierarchies. For me "Called Hierarchy", and "Find References" (in this order) are really the most important IDE features. I'm using Eclipse and if you setup your HotSpot project correctly, these features work pretty well and reliably. Have you personally tried the rtags "call hierarchies" / "find references" support in VSC? From your summary it sounds like it's worth giving it a try. Thanks again for caring about these topics! Hotspot development with IDE support has always been a pain and every improvement in this area will be highly welcome :) Best regards, Volker > Best regards, > Robin > > > > > Regards, > > Volker > > > > On Mon, May 27, 2019 at 6:03 PM Robin Westberg > > wrote: > >> > >> Hi all, > >> > >> Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE. > >> > >> The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html]. > >> > >> Issue: > >> https://bugs.openjdk.java.net/browse/JDK-8223678 > >> > >> Webrev: > >> https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/ > >> > >> Testing: > >> Manual testing on Linux, MacOS and Windows > >> > >> Thanks Erik Joelsson for taking a look at an earlier version of it! > >> > >> Best regards, > >> Robin > From kim.barrett at oracle.com Wed May 29 14:44:26 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 May 2019 10:44:26 -0400 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> Message-ID: <4C8CB20E-43E3-4A9C-B7FB-76715CC616F6@oracle.com> Not a review, just briefly jumping in because I noticed one thing to correct. > On May 29, 2019, at 9:12 AM, Andrew Haley wrote: > > On 5/29/19 11:26 AM, Nick Gasson wrote: > > Oh dear. Experience has shown me (and probably you, too) that this is > one of the most error-prone parts of software development. Many > very serious failures have been caused by trying to shut up > compilers. These failures have even included major security breaches. > > With that, let's press on with a heavy heart? +1 on all that. >> This first one is with GCC 8.3: >> >> /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp: In function 'void pf(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)': >> /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp:775:35: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class RegisterMap' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess] >> memcpy(reg_map, &map, sizeof map); >> ^ >> >> RegisterMap is non-POD because its base class AllocatedObj has virtual >> methods, so we need to use copy-assignment rather than memcpy. But >> because we're allocating reg_map with os::malloc we ought to use >> placement new to properly construct it first. But we can't do that >> because RegisterMap inherits from StackObj which disallows new. So I >> just put in some casts to void * to silence the warning. > > We can't do that. It seems to me that this must be Undefined > Behaviour, and we must never attempt to cover up UB with casts. I think the solution here is to use placement new, but explicitly qualified to actually get there, e.g. ::new (reg_map) RegisterMap(map); Using unqualified new will do the lookup in RegisterMap, find some declarations in StackObj (but not the one we want) and fail. This is a pretty common pattern. >> /home/nicgas01/jdk/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:2684:17: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] >> offset &= -1<<12; >> ~~^ > > Oh FFS. :-) This is perfectly legal in GCC and probably clang as well. Yeah, I sometimes think we should disable -Wshift-negative-value. From erik.joelsson at oracle.com Wed May 29 15:22:54 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 May 2019 08:22:54 -0700 Subject: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: <01BD2934-BC92-42A4-B6DC-C977359F0FA2@oracle.com> References: <01BD2934-BC92-42A4-B6DC-C977359F0FA2@oracle.com> Message-ID: <48ff6be3-b2f2-68e2-8082-abba17d0dcc2@oracle.com> Thanks, looks good! /Erik On 2019-05-29 06:52, Robin Westberg wrote: > Hi Erik, > > Thanks for taking a look! > >> On 28 May 2019, at 15:52, Erik Joelsson wrote: >> >> Hello Robin, >> >> Looks good. >> >> Adding of ide.md is very nice, but could you try to format it like testing.md and building.md in regards to line lengths? I believe we are trying for 80 chars in those to make them read reasonably in a standard editor. > Sure, did a bit of reflowing and updated some formatting in order to look more like the other .md files. > > Webrevs: > - Full: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.02/ > - Inc: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01-02/ > > Best regards, > Robin > >> /Erik >> >> On 2019-05-27 09:03, Robin Westberg wrote: >>> Hi all, >>> >>> Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE. >>> >>> The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html]. >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8223678 >>> >>> Webrev: >>> https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/ >>> >>> Testing: >>> Manual testing on Linux, MacOS and Windows >>> >>> Thanks Erik Joelsson for taking a look at an earlier version of it! >>> >>> Best regards, >>> Robin From zuismanm at gmail.com Wed May 29 19:21:06 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Wed, 29 May 2019 22:21:06 +0300 Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 In-Reply-To: References: Message-ID: I thought, that may be probleem ressults form some specific configuration on my machine (for example I have 2 version of MSVCc - 2012 and 2017. So I created clean VmWare Virtual machine and installed their only MSVC 2017 and cygwin. And tried to build OPEN JDK theeir. and got exactly same failure. ??, 29 ??? 2019 ?. ? 09:40, Moshe Zuisman : > I am using http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281 > > > ??, 29 ??? 2019 ?. ? 08:35, David Holmes : > >> Hi Moshe, >> >> On 29/05/2019 2:15 am, Moshe Zuisman wrote: >> > I am trying to build OPEN jdk 11 on cygwin with MSVC 2017 >> > >> _________________________________________________________________________ >> >> VS 2017 is the official supported compiler for building OpenJDK 11 [1] >> and we don't see any issues. What version of the 11u source are you >> trying to compile? >> >> David >> >> [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >> >> > >> > >> *c:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): >> > warning C4577: 'noexcept' used with no exception handling mode >> specified; >> > termination on exception is not guaranteed. Specify /EHscmake[3]: *** >> > [lib/CompileJvm.gmk:151: >> > >> /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj] >> > Error 1make[3]: *** Waiting for unfinished jobs....make[2]: *** >> > [make/Main.gmk:257: hotspot-server-libs] Error 2make[2]: *** Waiting for >> > unfinished jobs....ERROR: Build failed for target 'default >> > (exploded-image)' in configuration >> 'windows-x86_64-normal-server-release' >> > (exit code 2)=== Output from failing command(s) repeated here ===* For >> > target >> > >> hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:BUILD_LIBJVM_pch.cppc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): >> > error C2220: warning treated as error - no 'object' file >> > >> generatedc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): >> > warning C4577: 'noexcept' used with no exception handling mode >> specified; >> > termination on exception is not guaranteed. Specify /EHsc ... (rest of >> > output omitted)* All command lines available in >> > >> /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/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]: *** >> > >> [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305: >> > main] Error 2make: *** >> > >> [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186: >> > default] Error 2* >> > >> > From erik.joelsson at oracle.com Wed May 29 20:40:44 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 May 2019 13:40:44 -0700 Subject: RFR: JDK-8224011: Failure handling in ExecuteWithLog fails in run-test-prebuilt Message-ID: When running tests using "make run-test-prebuilt", we bypass a lot of Init.gmk. One of the things we skip is initialization of the make-support/failure-logs dir. This causes make to print errors about failing to copy files into that directory if for example the AOT compilation fails, partly hiding the original error. This change simply adds a MakeDir on that directory as part of the RunTestPrebuilt.gmk bootstrap. Bug: https://bugs.openjdk.java.net/browse/JDK-8224011 Webrev: http://cr.openjdk.java.net/~erikj/8224011/webrev.01/index.html (The empty change in RunTests.gmk was a trailing tab that my Emacs thoroughly disliked, so including that here too.) /Erik From tim.bell at oracle.com Wed May 29 20:59:19 2019 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 29 May 2019 13:59:19 -0700 Subject: RFR: JDK-8224011: Failure handling in ExecuteWithLog fails in run-test-prebuilt In-Reply-To: References: Message-ID: <5CEEF2A7.6020006@oracle.com> Erik: > When running tests using "make run-test-prebuilt", we bypass a lot of > Init.gmk. One of the things we skip is initialization of the > make-support/failure-logs dir. This causes make to print errors about > failing to copy files into that directory if for example the AOT > compilation fails, partly hiding the original error. This change simply > adds a MakeDir on that directory as part of the RunTestPrebuilt.gmk > bootstrap. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224011 > > Webrev: http://cr.openjdk.java.net/~erikj/8224011/webrev.01/index.html Looks good. > (The empty change in RunTests.gmk was a trailing tab that my Emacs > thoroughly disliked, so including that here too.) Thanks for fixing that also. Tim From mandy.chung at oracle.com Wed May 29 21:19:10 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 May 2019 14:19:10 -0700 Subject: RFR (XXS) 8224790: Remove Xusage.txt file In-Reply-To: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> References: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> Message-ID: Looks good to me. Mandy On 5/25/19 1:49 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8224790 > webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/ > > Before Java 7 the Xusage.txt file was used to print the "java -X" help > information in English. From Java 7 this information was provided in > localised format by the launcher. The Xusage.txt file was not removed > at the time because it was also used by the gamma launcher. But the > gamma launcher was removed in java 8 - JDK-8008772. The information in > Xusage.txt has become stale and incomplete (despite several edits post > Java 7). It should just be removed. > > Also removed the build logic that copied the file into the JDK image. > > Thanks, > David From david.holmes at oracle.com Wed May 29 21:58:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 May 2019 07:58:06 +1000 Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 In-Reply-To: References: Message-ID: <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com> Can you provide the configuration summary produced by configure? It's an issue with precompiled headers but I've no idea what. David On 30/05/2019 5:21 am, Moshe Zuisman wrote: > I? thought, that may be probleem ressults form some specific > configuration on my? machine (for example I have 2 version of MSVCc - > 2012 and 2017. > So I created clean VmWare Virtual machine and installed their only MSVC > 2017 and cygwin. And tried to build OPEN JDK theeir. and got exactly > same? failure. > > ??, 29 ??? 2019 ?. ? 09:40, Moshe Zuisman >: > > I am using > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281 > > > > ??, 29 ??? 2019 ?. ? 08:35, David Holmes >: > > Hi Moshe, > > On 29/05/2019 2:15 am, Moshe Zuisman wrote: > > I am trying to build OPEN jdk 11 on cygwin with MSVC 2017 > > > _________________________________________________________________________ > > VS 2017 is the official supported compiler for building OpenJDK > 11 [1] > and we don't see any issues. What version of the 11u source are you > trying to compile? > > David > > [1] > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > > > > > *c:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > > warning C4577: 'noexcept' used with no exception handling > mode specified; > > termination on exception is not guaranteed. Specify > /EHscmake[3]: *** > > [lib/CompileJvm.gmk:151: > > > /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj] > > Error 1make[3]: *** Waiting for unfinished jobs....make[2]: *** > > [make/Main.gmk:257: hotspot-server-libs] Error 2make[2]: *** > Waiting for > > unfinished jobs....ERROR: Build failed for target 'default > > (exploded-image)' in configuration > 'windows-x86_64-normal-server-release' > > (exit code 2)=== Output from failing command(s) repeated here > ===* For > > target > > > hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:BUILD_LIBJVM_pch.cppc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > > error C2220: warning treated as error - no 'object' file > > > generatedc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > > warning C4577: 'noexcept' used with no exception handling > mode specified; > > termination on exception is not guaranteed. Specify /EHsc > ?... (rest of > > output omitted)* All command lines available in > > > /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/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]: *** > > > [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305: > > main] Error 2make: *** > > > [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186: > > default] Error 2* > > > From david.holmes at oracle.com Wed May 29 22:04:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 May 2019 08:04:31 +1000 Subject: RFR (XXS) 8224790: Remove Xusage.txt file In-Reply-To: References: <78c1b907-94d9-3215-d8cf-44f1ef0d48e7@oracle.com> Message-ID: Thanks Mandy! David On 30/05/2019 7:19 am, Mandy Chung wrote: > Looks good to me. > > Mandy > > On 5/25/19 1:49 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224790 >> webrev: http://cr.openjdk.java.net/~dholmes/8224790/webrev/ >> >> Before Java 7 the Xusage.txt file was used to print the "java -X" help >> information in English. From Java 7 this information was provided in >> localised format by the launcher. The Xusage.txt file was not removed >> at the time because it was also used by the gamma launcher. But the >> gamma launcher was removed in java 8 - JDK-8008772. The information in >> Xusage.txt has become stale and incomplete (despite several edits post >> Java 7). It should just be removed. >> >> Also removed the build logic that copied the file into the JDK image. >> >> Thanks, >> David > From jonathan.gibbons at oracle.com Wed May 29 22:44:35 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 29 May 2019 15:44:35 -0700 Subject: RFR: JDK-8224257 : fix issues in files generated by pandoc Message-ID: Please review a fix to provide a new build-time tool to fix up the output generated by the "pandoc" tool, which generates output that fails to meet all of our documentation standards. Post-processing the output was deemed a better solution than trying to modify the tool itself. Most of the work is in the code for the new tool, written by me. The remainder of the work, to integrate the tool into the build, was contributed by Erik Joelsson. The new tool comes in two parts. The first part uses an HTML parser to stream the content of a file and to update it on the fly; the second part of the file is just a copy-paste of a simple HTML parser that has been used in other similar contexts, like the CodeTools DocCheck utility [DocCheck]. The following changes are made to files processed by the tool, in order to pass various accessibility checking tools. * the element is modified to set `lang="en"` and to remove references to XML *
...
is inserted around palpable content not already included in a landmark region * in tables, `scope="row"` is added to the cells in the column that best define the row * (minor) in the `` element, the content is updated to indicate that the file has been modified by this tool -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8224257 Webrev: http://cr.openjdk.java.net/~jjg/8224257/webrev.00/webrev/index.html DocCheck: https://openjdk.java.net/projects/code-tools/doccheck/ From zuismanm at gmail.com Thu May 30 08:26:47 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Thu, 30 May 2019 11:26:47 +0300 Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 In-Reply-To: <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com> References: <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com> Message-ID: Configuration summary: ==================================================== The existing configuration has been successfully updated in /cygdrive/c/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release using configure arguments '--with-boot-jdk=/cygdrive/c/jdk-11.0.3'. Configuration summary: * Debug level: release * HS debug level: product * JVM variants: server * JVM features: server: 'aot cds cmsgc compiler1 compiler2 epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services vm-structs' * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64 * Version string: 11-internal+0-adhoc.ADPRODcuser.jdk11-1ddf9a99e4ad (11-internal) Tools summary: * Environment: cygwin version 3.0.7(0.338/5/3) (root at /cygdrive/c/cygwin64) * Boot JDK: java version "11.0.3" 2019-04-16 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode) (at /cygdrive/c/jdk-11.0.3) * Toolchain: microsoft (Microsoft Visual Studio 2017) * C Compiler: Version 19.10.25027 (at /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl) * C++ Compiler: Version 19.10.25027 (at /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl) Build performance summary: * Cores to use: 2 * Memory limit: 8191 MB WARNING: The result of this configuration has overridden an older configuration. You *should* run 'make clean' to make sure you get a proper build. Failure to do so might result in strange build problems. ??, 30 ??? 2019 ?. ? 00:58, David Holmes : > Can you provide the configuration summary produced by configure? > > It's an issue with precompiled headers but I've no idea what. > > David > > On 30/05/2019 5:21 am, Moshe Zuisman wrote: > > I thought, that may be probleem ressults form some specific > > configuration on my machine (for example I have 2 version of MSVCc - > > 2012 and 2017. > > So I created clean VmWare Virtual machine and installed their only MSVC > > 2017 and cygwin. And tried to build OPEN JDK theeir. and got exactly > > same failure. > > > > ??, 29 ??? 2019 ?. ? 09:40, Moshe Zuisman > >: > > > > I am using > > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281 > > > > > > > > ??, 29 ??? 2019 ?. ? 08:35, David Holmes > >: > > > > Hi Moshe, > > > > On 29/05/2019 2:15 am, Moshe Zuisman wrote: > > > I am trying to build OPEN jdk 11 on cygwin with MSVC 2017 > > > > > > _________________________________________________________________________ > > > > VS 2017 is the official supported compiler for building OpenJDK > > 11 [1] > > and we don't see any issues. What version of the 11u source are > you > > trying to compile? > > > > David > > > > [1] > > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > > > > > > > > > > *c:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > > > warning C4577: 'noexcept' used with no exception handling > > mode specified; > > > termination on exception is not guaranteed. Specify > > /EHscmake[3]: *** > > > [lib/CompileJvm.gmk:151: > > > > > > /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj] > > > Error 1make[3]: *** Waiting for unfinished jobs....make[2]: > *** > > > [make/Main.gmk:257: hotspot-server-libs] Error 2make[2]: *** > > Waiting for > > > unfinished jobs....ERROR: Build failed for target 'default > > > (exploded-image)' in configuration > > 'windows-x86_64-normal-server-release' > > > (exit code 2)=== Output from failing command(s) repeated here > > ===* For > > > target > > > > > > hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:BUILD_LIBJVM_pch.cppc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > > > error C2220: warning treated as error - no 'object' file > > > > > > generatedc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > > > warning C4577: 'noexcept' used with no exception handling > > mode specified; > > > termination on exception is not guaranteed. Specify /EHsc > > ... (rest of > > > output omitted)* All command lines available in > > > > > > /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/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]: *** > > > > > > [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305: > > > main] Error 2make: *** > > > > > > [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186: > > > default] Error 2* > > > > > > From david.holmes at oracle.com Thu May 30 09:45:55 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 May 2019 19:45:55 +1000 Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 In-Reply-To: References: <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com> Message-ID: <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com> Hi Moshe, can you try running configure with --disable-precompiled-headers Thanks, David On 30/05/2019 6:26 pm, Moshe Zuisman wrote: > Configuration summary: > ==================================================== > The existing configuration has been successfully updated in > /cygdrive/c/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release > using configure arguments '--with-boot-jdk=/cygdrive/c/jdk-11.0.3'. > > Configuration summary: > * Debug level: ? ?release > * HS debug level: product > * JVM variants: ? server > * JVM features: ? server: 'aot cds cmsgc compiler1 compiler2 epsilongc > g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc > services vm-structs' > * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64 > * Version string: 11-internal+0-adhoc.ADPRODcuser.jdk11-1ddf9a99e4ad > (11-internal) > > Tools summary: > * Environment: ? ?cygwin version 3.0.7(0.338/5/3) (root at > /cygdrive/c/cygwin64) > * Boot JDK: ? ? ? java version "11.0.3" 2019-04-16 LTS ?Java(TM) SE > Runtime Environment 18.9 (build 11.0.3+12-LTS) ?Java HotSpot(TM) 64-Bit > Server VM 18.9 (build 11.0.3+12-LTS, mixed mode) ? (at > /cygdrive/c/jdk-11.0.3) > * Toolchain: ? ? ?microsoft (Microsoft Visual Studio 2017) > * C Compiler: ? ? Version 19.10.25027 (at > /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl) > * C++ Compiler: ? Version 19.10.25027 (at > /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl) > > Build performance summary: > * Cores to use: ? 2 > * Memory limit: ? 8191 MB > > WARNING: The result of this configuration has overridden an older > configuration. You *should* run 'make clean' to make sure you get a > proper build. Failure to do so might result in strange build problems. > > ??, 30 ??? 2019 ?. ? 00:58, David Holmes >: > > Can you provide the configuration summary produced by configure? > > It's an issue with precompiled headers but I've no idea what. > > David > > On 30/05/2019 5:21 am, Moshe Zuisman wrote: > > I? thought, that may be probleem ressults form some specific > > configuration on my? machine (for example I have 2 version of > MSVCc - > > 2012 and 2017. > > So I created clean VmWare Virtual machine and installed their > only MSVC > > 2017 and cygwin. And tried to build OPEN JDK theeir. and got exactly > > same? failure. > > > > ??, 29 ??? 2019 ?. ? 09:40, Moshe Zuisman > > >>: > > > >? ? ?I am using > > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281 > >? ? ? > > > > > >? ? ???, 29 ??? 2019 ?. ? 08:35, David Holmes > > >? ? ? >>: > > > >? ? ? ? ?Hi Moshe, > > > >? ? ? ? ?On 29/05/2019 2:15 am, Moshe Zuisman wrote: > >? ? ? ? ? > I am trying to build OPEN jdk 11 on cygwin with MSVC 2017 > >? ? ? ? ? > > > > ?_________________________________________________________________________ > > > >? ? ? ? ?VS 2017 is the official supported compiler for building > OpenJDK > >? ? ? ? ?11 [1] > >? ? ? ? ?and we don't see any issues. What version of the 11u > source are you > >? ? ? ? ?trying to compile? > > > >? ? ? ? ?David > > > >? ? ? ? ?[1] > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > > >? ? ? ? ? > > >? ? ? ? ? > > > > ?*c:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > >? ? ? ? ? > warning C4577: 'noexcept' used with no exception handling > >? ? ? ? ?mode specified; > >? ? ? ? ? > termination on exception is not guaranteed. Specify > >? ? ? ? ?/EHscmake[3]: *** > >? ? ? ? ? > [lib/CompileJvm.gmk:151: > >? ? ? ? ? > > > > ?/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj] > >? ? ? ? ? > Error 1make[3]: *** Waiting for unfinished > jobs....make[2]: *** > >? ? ? ? ? > [make/Main.gmk:257: hotspot-server-libs] Error > 2make[2]: *** > >? ? ? ? ?Waiting for > >? ? ? ? ? > unfinished jobs....ERROR: Build failed for target 'default > >? ? ? ? ? > (exploded-image)' in configuration > >? ? ? ? ?'windows-x86_64-normal-server-release' > >? ? ? ? ? > (exit code 2)=== Output from failing command(s) > repeated here > >? ? ? ? ?===* For > >? ? ? ? ? > target > >? ? ? ? ? > > > > ?hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:BUILD_LIBJVM_pch.cppc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > >? ? ? ? ? > error C2220: warning treated as error - no 'object' file > >? ? ? ? ? > > > > ?generatedc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > >? ? ? ? ? > warning C4577: 'noexcept' used with no exception handling > >? ? ? ? ?mode specified; > >? ? ? ? ? > termination on exception is not guaranteed. Specify /EHsc > >? ? ? ? ? ?... (rest of > >? ? ? ? ? > output omitted)* All command lines available in > >? ? ? ? ? > > > > ?/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/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]: *** > >? ? ? ? ? > > > > ?[/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305: > >? ? ? ? ? > main] Error 2make: *** > >? ? ? ? ? > > > > ?[/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186: > >? ? ? ? ? > default] Error 2* > >? ? ? ? ? > > > > From shade at redhat.com Thu May 30 11:44:37 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 May 2019 13:44:37 +0200 Subject: RFR (M) 8225048: Shenandoah x86_32 support Message-ID: <4fb7a59f-1ceb-af71-2038-a48ef6366087@redhat.com> http://cr.openjdk.java.net/~shade/8225048/webrev.01/ Some history: Shenandoah used to support x86_32 in "passive" mode long time ago. This mode relies only on stop-the-world GC to avoid implementing barriers (basically, runs Degenerated GC all the time). It was an interesting mode to see the footprint numbers you can get with uncommits and slimmer native pointers with really small microservice-size VMs. This mode was dropped before integration upstream, because many Shenandoah tests expect all heuristics/modes to work properly, and having the rudimentary x86_32 support was breaking tier1 tests. So we disabled it. Today, we have significantly simplified runtime interface thanks to LRB and elimination of separate forwarding pointer slot, and we can build the fully concurrent x86_32 with ease. This allows us to maintain 32-bit cleanness in Shenandoah code, plus serves as the proof of concept that Shenandoah can be implemented on 32-bit platform. I am planning to backport this all the way to 8u, once other improvements are backported, so keeping the patch simple is paramount. A brief tour of changes: *) One minor change in build config to accept both x86_32 and x86_64 (therefore, cc'ing build-dev); this is the same check we had before reversal in jdk12; *) C1 changes need to disambiguate for single/double-cpu slots in CAS, this is the same other BarrierSets do; *) C2 changes need shenandoah_x86_32.ad to carry adapters for CAS barriers, plus accept StoreIConditional for raw ptr stores on some paths. *) SBSAssembler change reshuffles _LP64 checks to enable x86_32 paths. It needs to deal with UseCompressedOops blocks, getting threads into a separate register, etc.; *) Test changes enable running them on x86_32, and generally 32-bit platforms -- I can split them out, but they make little sense on their own, without having the product code that actually uses them; Builds: {x86_32, x86_64} with/without PCH; other platform builds in CI Testing: hotspot_gc_shenandoah, CTW tests, jcstress, ad-hoc footprint experiments IIRC, Oracle does not build either x86_32 or Shenandoah, so I did not run it through jdk-submit. -- Thanks, -Aleksey From rkennke at redhat.com Thu May 30 12:14:14 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 May 2019 14:14:14 +0200 Subject: RFR (M) 8225048: Shenandoah x86_32 support In-Reply-To: <4fb7a59f-1ceb-af71-2038-a48ef6366087@redhat.com> References: <4fb7a59f-1ceb-af71-2038-a48ef6366087@redhat.com> Message-ID: The changes look good to me. Thanks!! Roman > http://cr.openjdk.java.net/~shade/8225048/webrev.01/ > > Some history: Shenandoah used to support x86_32 in "passive" mode long time ago. This mode relies > only on stop-the-world GC to avoid implementing barriers (basically, runs Degenerated GC all the > time). It was an interesting mode to see the footprint numbers you can get with uncommits and > slimmer native pointers with really small microservice-size VMs. This mode was dropped before > integration upstream, because many Shenandoah tests expect all heuristics/modes to work properly, > and having the rudimentary x86_32 support was breaking tier1 tests. So we disabled it. > > Today, we have significantly simplified runtime interface thanks to LRB and elimination of separate > forwarding pointer slot, and we can build the fully concurrent x86_32 with ease. This allows us to > maintain 32-bit cleanness in Shenandoah code, plus serves as the proof of concept that Shenandoah > can be implemented on 32-bit platform. > > I am planning to backport this all the way to 8u, once other improvements are backported, so keeping > the patch simple is paramount. > > A brief tour of changes: > > *) One minor change in build config to accept both x86_32 and x86_64 (therefore, cc'ing build-dev); > this is the same check we had before reversal in jdk12; > > *) C1 changes need to disambiguate for single/double-cpu slots in CAS, this is the same other > BarrierSets do; > > *) C2 changes need shenandoah_x86_32.ad to carry adapters for CAS barriers, plus accept > StoreIConditional for raw ptr stores on some paths. > > *) SBSAssembler change reshuffles _LP64 checks to enable x86_32 paths. It needs to deal with > UseCompressedOops blocks, getting threads into a separate register, etc.; > > *) Test changes enable running them on x86_32, and generally 32-bit platforms -- I can split them > out, but they make little sense on their own, without having the product code that actually uses them; > > Builds: {x86_32, x86_64} with/without PCH; other platform builds in CI > Testing: hotspot_gc_shenandoah, CTW tests, jcstress, ad-hoc footprint experiments > > IIRC, Oracle does not build either x86_32 or Shenandoah, so I did not run it through jdk-submit. > From weijun.wang at oracle.com Thu May 30 13:01:02 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 30 May 2019 21:01:02 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) means when when the tool is changed, GENDATA_CACERTS will be called. Thanks, Max From david.holmes at oracle.com Thu May 30 13:11:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 May 2019 23:11:16 +1000 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: Message-ID: Hi Max, Not a review :) On 30/05/2019 11:01 pm, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ > > Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. > > There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line > > $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) > > means when when the tool is changed, GENDATA_CACERTS will be called. I think you have set a dependency on the directory, not the files within it. If you look at make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk for example you'll see this rule: $(GENSRC_DIR)/_gensrc_proc_done: $(PROC_SRCS) $(PROCESSOR_JARS) but PROC_SRCS is defined as PROC_SRCS := $(filter %.java, $(call FindFiles, $(PROC_SRC_DIRS))) which is all the .java files in the src directory. David > Thanks, > Max > From erik.joelsson at oracle.com Thu May 30 13:27:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 May 2019 06:27:48 -0700 Subject: RFR: JDK-8224257 : fix issues in files generated by pandoc In-Reply-To: References: Message-ID: Looks good to me, but I also contributed the build changes. /Erik On 2019-05-29 15:44, Jonathan Gibbons wrote: > Please review a fix to provide a new build-time tool to fix up the > output generated by the "pandoc" tool, which generates output that > fails to meet all of our documentation standards. Post-processing the > output was deemed a better solution than trying to modify the tool > itself. > > Most of the work is in the code for the new tool, written by me. The > remainder of the work, to integrate the tool into the build, was > contributed by Erik Joelsson. > > The new tool comes in two parts. The first part uses an HTML parser to > stream the content of a file and to update it on the fly; the second > part of the file is just a copy-paste of a simple HTML parser that has > been used in other similar contexts, like the CodeTools DocCheck > utility [DocCheck]. > > The following changes are made to files processed by the tool, in > order to pass various accessibility checking tools. > > ?* the element is modified to set `lang="en"` and to remove > ?? references to XML > > ?*
...
is inserted around palpable content not already > ?? included in a landmark region > > ?* in tables, `scope="row"` is added to the cells in the column that > ?? best define the row > > ?* (minor) in the `` element, the content is > ?? updated to indicate that the file has been modified by this tool > > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224257 > Webrev: > http://cr.openjdk.java.net/~jjg/8224257/webrev.00/webrev/index.html > DocCheck: https://openjdk.java.net/projects/code-tools/doccheck/ > From erik.joelsson at oracle.com Thu May 30 13:29:19 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 May 2019 06:29:19 -0700 Subject: RFR (M) 8225048: Shenandoah x86_32 support In-Reply-To: <4fb7a59f-1ceb-af71-2038-a48ef6366087@redhat.com> References: <4fb7a59f-1ceb-af71-2038-a48ef6366087@redhat.com> Message-ID: <52336e65-ba7d-891e-921b-eab2cb54bab1@oracle.com> Build change looks good. /Erik On 2019-05-30 04:44, Aleksey Shipilev wrote: > http://cr.openjdk.java.net/~shade/8225048/webrev.01/ > > Some history: Shenandoah used to support x86_32 in "passive" mode long time ago. This mode relies > only on stop-the-world GC to avoid implementing barriers (basically, runs Degenerated GC all the > time). It was an interesting mode to see the footprint numbers you can get with uncommits and > slimmer native pointers with really small microservice-size VMs. This mode was dropped before > integration upstream, because many Shenandoah tests expect all heuristics/modes to work properly, > and having the rudimentary x86_32 support was breaking tier1 tests. So we disabled it. > > Today, we have significantly simplified runtime interface thanks to LRB and elimination of separate > forwarding pointer slot, and we can build the fully concurrent x86_32 with ease. This allows us to > maintain 32-bit cleanness in Shenandoah code, plus serves as the proof of concept that Shenandoah > can be implemented on 32-bit platform. > > I am planning to backport this all the way to 8u, once other improvements are backported, so keeping > the patch simple is paramount. > > A brief tour of changes: > > *) One minor change in build config to accept both x86_32 and x86_64 (therefore, cc'ing build-dev); > this is the same check we had before reversal in jdk12; > > *) C1 changes need to disambiguate for single/double-cpu slots in CAS, this is the same other > BarrierSets do; > > *) C2 changes need shenandoah_x86_32.ad to carry adapters for CAS barriers, plus accept > StoreIConditional for raw ptr stores on some paths. > > *) SBSAssembler change reshuffles _LP64 checks to enable x86_32 paths. It needs to deal with > UseCompressedOops blocks, getting threads into a separate register, etc.; > > *) Test changes enable running them on x86_32, and generally 32-bit platforms -- I can split them > out, but they make little sense on their own, without having the product code that actually uses them; > > Builds: {x86_32, x86_64} with/without PCH; other platform builds in CI > Testing: hotspot_gc_shenandoah, CTW tests, jcstress, ad-hoc footprint experiments > > IIRC, Oracle does not build either x86_32 or Shenandoah, so I did not run it through jdk-submit. > From weijun.wang at oracle.com Thu May 30 13:34:07 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 30 May 2019 21:34:07 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: Message-ID: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> Since I need to track all added, removed, updated files in that directory, I thought depending on the directory itself is more correct. If I use the FindFiles function, then if some files are removed the cacerts will not be rebuilt. --Max > On May 30, 2019, at 9:11 PM, David Holmes wrote: > > Hi Max, > > Not a review :) > > On 30/05/2019 11:01 pm, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ >> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. >> There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line >> $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) >> means when when the tool is changed, GENDATA_CACERTS will be called. > > I think you have set a dependency on the directory, not the files within it. If you look at make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk for example you'll see this rule: > > $(GENSRC_DIR)/_gensrc_proc_done: $(PROC_SRCS) $(PROCESSOR_JARS) > > but PROC_SRCS is defined as > > PROC_SRCS := $(filter %.java, $(call FindFiles, $(PROC_SRC_DIRS))) > > which is all the .java files in the src directory. > > David > >> Thanks, >> Max From tim.bell at oracle.com Thu May 30 13:49:50 2019 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 30 May 2019 06:49:50 -0700 Subject: RFR: JDK-8224257 : fix issues in files generated by pandoc In-Reply-To: References: Message-ID: <5CEFDF7E.5090908@oracle.com> Jon: Looks good to me as well. Tim On 05/30/19 06:27, Erik Joelsson wrote: > Looks good to me, but I also contributed the build changes. > > /Erik > > On 2019-05-29 15:44, Jonathan Gibbons wrote: >> Please review a fix to provide a new build-time tool to fix up the >> output generated by the "pandoc" tool, which generates output that >> fails to meet all of our documentation standards. Post-processing the >> output was deemed a better solution than trying to modify the tool >> itself. >> >> Most of the work is in the code for the new tool, written by me. The >> remainder of the work, to integrate the tool into the build, was >> contributed by Erik Joelsson. >> >> The new tool comes in two parts. The first part uses an HTML parser to >> stream the content of a file and to update it on the fly; the second >> part of the file is just a copy-paste of a simple HTML parser that has >> been used in other similar contexts, like the CodeTools DocCheck >> utility [DocCheck]. >> >> The following changes are made to files processed by the tool, in >> order to pass various accessibility checking tools. >> >> * the element is modified to set `lang="en"` and to remove >> references to XML >> >> *
...
is inserted around palpable content not already >> included in a landmark region >> >> * in tables, `scope="row"` is added to the cells in the column that >> best define the row >> >> * (minor) in the `` element, the content is >> updated to indicate that the file has been modified by this tool >> >> >> -- Jon >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8224257 >> Webrev: >> http://cr.openjdk.java.net/~jjg/8224257/webrev.00/webrev/index.html >> DocCheck: https://openjdk.java.net/projects/code-tools/doccheck/ >> From erik.joelsson at oracle.com Thu May 30 14:01:30 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 May 2019 07:01:30 -0700 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> Message-ID: Hello Max, Looking in ToolsJdk.gmk, I realize that the BUILD_TOOLS variable was renamed back when we unified the repositories and is now called BUILD_TOOLS_JDK. It seems like I missed updating the references to this variable in the gendata dir. If you use the new variable name in the prerequisites list, you get a rebuild. Feel free to update the other references in make/gendata if you want to. In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as: $(wildcard $(GENDATA_CACERTS_SRC)/*) This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems. Some minor notes. The current recommended macro for creating the target directory in a recipe is $(call MakeTargetDir). For logical indent (Gendata-java.base.gmk:75 and Copy-java.base.gmk:173) please use 2 spaces [1]. I also think it would be good with a comment in Copy-java.base.gmk explaining that CACERTS_FILE is optionally set in configure to override the default cacerts which is otherwise generated in Gendata-java.base.gmk. Thanks, /Erik [1] http://openjdk.java.net/groups/build/doc/code-conventions.html On 2019-05-30 06:34, Weijun Wang wrote: > Since I need to track all added, removed, updated files in that directory, I thought depending on the directory itself is more correct. If I use the FindFiles function, then if some files are removed the cacerts will not be rebuilt. > > --Max > >> On May 30, 2019, at 9:11 PM, David Holmes wrote: >> >> Hi Max, >> >> Not a review :) >> >> On 30/05/2019 11:01 pm, Weijun Wang wrote: >>> Please take a review at >>> http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ >>> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. >>> There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line >>> $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) >>> means when when the tool is changed, GENDATA_CACERTS will be called. >> I think you have set a dependency on the directory, not the files within it. If you look at make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk for example you'll see this rule: >> >> $(GENSRC_DIR)/_gensrc_proc_done: $(PROC_SRCS) $(PROCESSOR_JARS) >> >> but PROC_SRCS is defined as >> >> PROC_SRCS := $(filter %.java, $(call FindFiles, $(PROC_SRC_DIRS))) >> >> which is all the .java files in the src directory. >> >> David >> >>> Thanks, >>> Max From weijun.wang at oracle.com Thu May 30 15:32:24 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 30 May 2019 23:32:24 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> Message-ID: > On May 30, 2019, at 10:01 PM, Erik Joelsson wrote: > > In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as: > > $(wildcard $(GENDATA_CACERTS_SRC)/*) > > This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems. But in my experiment, using the directory name does detect the file removal. Or, can I list *both* the files and the directory to get maximum awareness? --Max From erik.joelsson at oracle.com Thu May 30 17:34:32 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 May 2019 10:34:32 -0700 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> Message-ID: <3b57c56c-8b00-f9d0-aecc-4877fb3de97a@oracle.com> On 2019-05-30 08:32, Weijun Wang wrote: > >> On May 30, 2019, at 10:01 PM, Erik Joelsson wrote: >> >> In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as: >> >> $(wildcard $(GENDATA_CACERTS_SRC)/*) >> >> This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems. > But in my experiment, using the directory name does detect the file removal. It believe that worked well on your machine, but directory timestamp updates are file system dependent. I'm not sure we can count on all filesystems to accurately reflect time stamps based on file modification. It's also possible that an OS would touch directory timestamps for other reasons, which should not affect the build. I haven't tried having source directories as prerequisites before, so I simply don't know how reliable it is. My experience is rather with directories as targets, which certainly doesn't work. If you verified that it worked as expected on all supported OSes, I would be less worried. > Or, can I list *both* the files and the directory to get maximum awareness? The directory modification time will usually not change when a file in it is modified, only when adding or removing files (and possibly some other operations), so adding the files is certainly a must. If you go with both, then I would just be worried about potential false positives. /Erik From jonathan.gibbons at oracle.com Thu May 30 17:54:00 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 30 May 2019 10:54:00 -0700 Subject: RFR: P2: JDK-8225066 Add missing file Message-ID: <8931f603-9485-8fd8-0f94-8bbf8d71fa12@oracle.com> In creating the changeset for JDK-8224257, I forgot to 'hg add' a new file. Please review this changeset to add the file;? the content of the file were previously reviewed as part of JDK-8224257. JBS: https://bugs.openjdk.java.net/browse/JDK-8225066 Webrev: http://cr.openjdk.java.net/~jjg/8225066/webrev.00/ -- Jon From mandy.chung at oracle.com Thu May 30 17:59:17 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 30 May 2019 10:59:17 -0700 Subject: RFR: P2: JDK-8225066 Add missing file In-Reply-To: <8931f603-9485-8fd8-0f94-8bbf8d71fa12@oracle.com> References: <8931f603-9485-8fd8-0f94-8bbf8d71fa12@oracle.com> Message-ID: +1 Mandy On 5/30/19 10:54 AM, Jonathan Gibbons wrote: > In creating the changeset for JDK-8224257, I forgot to 'hg add' a new > file. > > Please review this changeset to add the file;? the content of the file > were previously reviewed as part of JDK-8224257. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225066 > Webrev: http://cr.openjdk.java.net/~jjg/8225066/webrev.00/ > > -- Jon > From erik.joelsson at oracle.com Thu May 30 18:00:34 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 May 2019 11:00:34 -0700 Subject: RFR: P2: JDK-8225066 Add missing file In-Reply-To: <8931f603-9485-8fd8-0f94-8bbf8d71fa12@oracle.com> References: <8931f603-9485-8fd8-0f94-8bbf8d71fa12@oracle.com> Message-ID: <6917d012-5997-71f3-e6cf-0c2efd0bf24b@oracle.com> Looks good. /Erik On 2019-05-30 10:54, Jonathan Gibbons wrote: > In creating the changeset for JDK-8224257, I forgot to 'hg add' a new > file. > > Please review this changeset to add the file;? the content of the file > were previously reviewed as part of JDK-8224257. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225066 > Webrev: http://cr.openjdk.java.net/~jjg/8225066/webrev.00/ > > -- Jon > From erik.joelsson at oracle.com Thu May 30 18:31:28 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 May 2019 11:31:28 -0700 Subject: RFR: JDK-8219788: Configure recommends JDK 8 Message-ID: Configure tries to be helpful with suggested commands for installing missing dependencies. The commands for installing a bootjdk are out of date and because of the accelerated release cycle, don't really work anymore. This patch changes the help text printed when the bootjdk is missing to "OpenJDK distributions are available at http://jdk.java.net/." and removes all the OS specific help texts for that particular dependency. Bug: https://bugs.openjdk.java.net/browse/JDK-8219788 Webrev: http://cr.openjdk.java.net/~erikj/8219788/webrev.01/ /Erik From tim.bell at oracle.com Thu May 30 18:47:34 2019 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 30 May 2019 11:47:34 -0700 Subject: RFR: JDK-8219788: Configure recommends JDK 8 In-Reply-To: References: Message-ID: <5CF02546.4020809@oracle.com> Erik: > This patch changes the help text printed when the bootjdk is > missing to "OpenJDK distributions are available at > http://jdk.java.net/." and removes all the OS specific help texts for > that particular dependency. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219788 > > > Webrev: http://cr.openjdk.java.net/~erikj/8219788/webrev.01/ Looks good. Tim From zuismanm at gmail.com Thu May 30 19:17:34 2019 From: zuismanm at gmail.com (Moshe Zuisman) Date: Thu, 30 May 2019 22:17:34 +0300 Subject: Fwd: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 In-Reply-To: References: <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com> <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com> Message-ID: Hi David. I have done it. with same result. I have added --debug-configure flag.. Attaching full configure output.. I am stuck with this issue and right now - have no idea - how to get out of this "blind alley"... ??, 30 ??? 2019 ?. ? 12:46, David Holmes : > Hi Moshe, > > can you try running configure with --disable-precompiled-headers > > Thanks, > David > > On 30/05/2019 6:26 pm, Moshe Zuisman wrote: > > Configuration summary: > > ==================================================== > > The existing configuration has been successfully updated in > > /cygdrive/c/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release > > using configure arguments '--with-boot-jdk=/cygdrive/c/jdk-11.0.3'. > > > > Configuration summary: > > * Debug level: release > > * HS debug level: product > > * JVM variants: server > > * JVM features: server: 'aot cds cmsgc compiler1 compiler2 epsilongc > > g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc > > services vm-structs' > > * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64 > > * Version string: 11-internal+0-adhoc.ADPRODcuser.jdk11-1ddf9a99e4ad > > (11-internal) > > > > Tools summary: > > * Environment: cygwin version 3.0.7(0.338/5/3) (root at > > /cygdrive/c/cygwin64) > > * Boot JDK: java version "11.0.3" 2019-04-16 LTS Java(TM) SE > > Runtime Environment 18.9 (build 11.0.3+12-LTS) Java HotSpot(TM) 64-Bit > > Server VM 18.9 (build 11.0.3+12-LTS, mixed mode) (at > > /cygdrive/c/jdk-11.0.3) > > * Toolchain: microsoft (Microsoft Visual Studio 2017) > > * C Compiler: Version 19.10.25027 (at > > > /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl) > > * C++ Compiler: Version 19.10.25027 (at > > > /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl) > > > > Build performance summary: > > * Cores to use: 2 > > * Memory limit: 8191 MB > > > > WARNING: The result of this configuration has overridden an older > > configuration. You *should* run 'make clean' to make sure you get a > > proper build. Failure to do so might result in strange build problems. > > > > ??, 30 ??? 2019 ?. ? 00:58, David Holmes > >: > > > > Can you provide the configuration summary produced by configure? > > > > It's an issue with precompiled headers but I've no idea what. > > > > David > > > > On 30/05/2019 5:21 am, Moshe Zuisman wrote: > > > I thought, that may be probleem ressults form some specific > > > configuration on my machine (for example I have 2 version of > > MSVCc - > > > 2012 and 2017. > > > So I created clean VmWare Virtual machine and installed their > > only MSVC > > From christoph.langer at sap.com Thu May 30 21:31:36 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 30 May 2019 21:31:36 +0000 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> Message-ID: Hi Max, first of all, thanks for doing this enhancement. That'll really help in the future when downstream vendors merge in additional certificates (or remove some) like we do with SapMachine. Currently we have to resolve manually everytime cacerts is modified. As for the dependencies: if you want to handle removals of certificates you might want to consider having a target that counts files in make/data/cacerts and stores the count in an intermediate file. You can do the counting every time (e.g. phony target) but only update the count file if the number has changed. And the actual cacerts target would need to depend on the count file as well. However, I guess it would also be ok to just depend on all the files in make/data/cacerts. Looking forward to see your update with Erik's suggestions worked in. Some copyright years need to be updated as well. Thanks & Best regards Christoph > -----Original Message----- > From: build-dev On Behalf Of > Weijun Wang > Sent: Donnerstag, 30. Mai 2019 17:32 > To: Erik Joelsson > Cc: security-dev at openjdk.java.net; build-dev dev at openjdk.java.net> > Subject: Re: RFR 8193255: Root Certificates should be stored in text format > and assembled at build time > > > > > On May 30, 2019, at 10:01 PM, Erik Joelsson > wrote: > > > > In my experience, using directories for dependencies in make does not > work well. Since all the files in make/data/cacerts are in a flat structure, I > would recommend expressing the prerequisites as: > > > > $(wildcard $(GENDATA_CACERTS_SRC)/*) > > > > This will not cover the case where a file is removed, but that case is rarely > handled well in make based build systems. > > But in my experiment, using the directory name does detect the file removal. > > Or, can I list *both* the files and the directory to get maximum awareness? > > --Max From sean.mullan at oracle.com Thu May 30 22:51:54 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 30 May 2019 18:51:54 -0400 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: Message-ID: <60fb9ad0-19f3-52d0-b5b4-7b5808a1b4e2@oracle.com> One suggestion is to put a printable form of the contents of the certificate at the top of each of the PEM files. It would be nice as a quick-look to see what is in the certificate. Of course, you can also use keytool -printcert to do that, but if I am just perusing the source code via a browser or something like that, it would be nice to not have to do that. --Sean On 5/30/19 9:01 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ > > Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. > > There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line > > $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) > > means when when the tool is changed, GENDATA_CACERTS will be called. > > Thanks, > Max > From weijun.wang at oracle.com Fri May 31 00:49:24 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 May 2019 08:49:24 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: <60fb9ad0-19f3-52d0-b5b4-7b5808a1b4e2@oracle.com> References: <60fb9ad0-19f3-52d0-b5b4-7b5808a1b4e2@oracle.com> Message-ID: <85D686DF-0C04-4666-922D-50D41DFB0621@oracle.com> Sure. How many info do you want to see? I can prepend `keytool -printcert` but that's too much. At least I think the extensions part is not needed. Also, I don't wish people reading the fingerprint inside as genuine and does not calculate it from the cert itself. So, I'm thinking of Owner: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US Issuer: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US Serial number: 50946cec18ead59c4dd597ef758fa0ad Valid from: 1 Nov 2004 17:14:04 GMT until: 1 Jan 2035 05:37:19 GMT Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Is that OK? Thanks, Max p.s. `keytool -printcert` shows validity in local timezone. Does not look good to me. > On May 31, 2019, at 6:51 AM, Sean Mullan wrote: > > One suggestion is to put a printable form of the contents of the certificate at the top of each of the PEM files. It would be nice as a quick-look to see what is in the certificate. Of course, you can also use keytool -printcert to do that, but if I am just perusing the source code via a browser or something like that, it would be nice to not have to do that. > > --Sean > > On 5/30/19 9:01 AM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ >> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. >> There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line >> $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) >> means when when the tool is changed, GENDATA_CACERTS will be called. >> Thanks, >> Max From weijun.wang at oracle.com Fri May 31 03:00:36 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 May 2019 11:00:36 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: <3b57c56c-8b00-f9d0-aecc-4877fb3de97a@oracle.com> References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> <3b57c56c-8b00-f9d0-aecc-4877fb3de97a@oracle.com> Message-ID: New webrev at https://cr.openjdk.java.net/~weijun/8193255/webrev.01 Changes: 1. Textual info at the beginning of each cert 2. Makefile: indentation, BUILD_TOOLS_JDK, MakeTargetDir, files instead of dir Thanks, Max > On May 31, 2019, at 1:34 AM, Erik Joelsson wrote: > > On 2019-05-30 08:32, Weijun Wang wrote: >> >>> On May 30, 2019, at 10:01 PM, Erik Joelsson wrote: >>> >>> In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as: >>> >>> $(wildcard $(GENDATA_CACERTS_SRC)/*) >>> >>> This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems. >> But in my experiment, using the directory name does detect the file removal. > > It believe that worked well on your machine, but directory timestamp updates are file system dependent. I'm not sure we can count on all filesystems to accurately reflect time stamps based on file modification. It's also possible that an OS would touch directory timestamps for other reasons, which should not affect the build. I haven't tried having source directories as prerequisites before, so I simply don't know how reliable it is. My experience is rather with directories as targets, which certainly doesn't work. If you verified that it worked as expected on all supported OSes, I would be less worried. > >> Or, can I list *both* the files and the directory to get maximum awareness? > > The directory modification time will usually not change when a file in it is modified, only when adding or removing files (and possibly some other operations), so adding the files is certainly a must. If you go with both, then I would just be worried about potential false positives. > > /Erik > From nick.gasson at arm.com Fri May 31 04:05:19 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 31 May 2019 12:05:19 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <4C8CB20E-43E3-4A9C-B7FB-76715CC616F6@oracle.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <4C8CB20E-43E3-4A9C-B7FB-76715CC616F6@oracle.com> Message-ID: Hi Kim, Kim Barrett writes: > > I think the solution here is to use placement new, but explicitly qualified to actually get there, e.g. > > ::new (reg_map) RegisterMap(map); > > Using unqualified new will do the lookup in RegisterMap, find some declarations in StackObj (but not the one we want) and fail. > This is a pretty common pattern. > This works, thanks. Nick From nick.gasson at arm.com Fri May 31 04:11:44 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 31 May 2019 12:11:44 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> Message-ID: <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> Hi Andrew, > > Oh dear. Experience has shown me (and probably you, too) that this is > one of the most error-prone parts of software development. Many > very serious failures have been caused by trying to shut up > compilers. These failures have even included major security breaches. > Fair enough. But I think several of these are worth fixing. > >> /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:43:39: error: cannot initialize a parameter of type 'char *' with an lvalue of type 'unsigned long' >> return __sync_add_and_fetch(dest, add_value); >> ^~~~~~~~~ >> >> If the add_and_fetch template is instantiated with I=integer and >> D=pointer then we need an explicit cast here. > > Please don't. Please have a look at where this happens and fix the > types there, as appropriate. What do other ports do? It's instantiated here: /home/nicgas01/jdk/src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp:259:34: note: in instantiation of function template specialization 'Atomic::add' requested here char* touch_addr = Atomic::add(actual_chunk_size, &_cur_addr) - actual_chunk_size; ^ We're adding an unsigned long to a char* which seems legitimate. The other ports except Arm32 and Zero use inline assembly so don't have problems with mismatched types. Zero uses __sync_fetch_and_add so would hit this too if it used G1. I'm not sure how to resolve this. We could add a specialisation of PlatformAdd for byte_size=8 and cast to (u)intptr_t? template<> struct Atomic::PlatformAdd<8> : Atomic::AddAndFetch > { template D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const { STATIC_ASSERT(8 == sizeof(I)); STATIC_ASSERT(8 == sizeof(D)); typedef typename Conditional::value, intptr_t, uintptr_t>::type PI; PI res = __sync_add_and_fetch(reinterpret_cast(dest), static_cast(add_value)); return reinterpret_cast(res); } } I think this is safe. > >> Rewrote as ~((1<<12) - 1) which matches the masks used in the rest of >> the function. > > Let's not. All we have to do to create a mask is is use -1u<<12. I > would challenge anyone to figure out without using a pencil what the > effect of &= ~(((1<<12)-1)<<12) might be. OK, I don't mind too much either way. > >> /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:103:20: error: variable 'esp' is uninitialized when used here [-Werror,-Wuninitialized] >> return (address) esp; >> ^~~ >> /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:101:21: note: initialize the variable 'esp' to silence this warning >> register void *esp __asm__ (SPELL_REG_SP); >> ^ >> = nullptr >> >> We could silence the -Wuninitialized warning for this function, but that >> doesn't help much because Clang then compiles >> os::current_stack_pointer() into: >> >> 0000000000000000 <_ZN2os21current_stack_pointerEv>: >> 0: d65f03c0 ret >> >> Whereas with GCC we get: >> >> 0000000000000250 <_ZN2os21current_stack_pointerEv>: >> 250: 910003e0 mov x0, sp >> 254: d65f03c0 ret >> >> Added some inline assembly to explicitly move sp into the result #ifdef >> __clang__. Same with _get_previous_fp(). > > This is all looking extremely fragile. We'd need to look at what the > usages of this code are and trace through. Yes, I agree this function seems quite fragile. What is the "current" stack pointer supposed to be? Is it the SP at the call site? That's what you get with current code on GCC -00 and -02, and with this patch on clang -O2. But clang -O0 gives SP - 16 because it creates a stack frame for os::current_stack_pointer(). On x86_64 with gcc -00 and clang -00 we get this: 0000000000000000 <_ZN2os21current_stack_pointerEv>: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 89 e0 mov %rsp,%rax 7: 5d pop %rbp 8: c3 retq The result is RSP before the CALL instruction - 16. On -02 we get caller's RSP - 8 instead: 0000000000000000 <_ZN2os21current_stack_pointerEv>: 0: 48 89 e0 mov %rsp,%rax 3: c3 retq I'm also not sure our existing use of `__asm__ (SPELL_REG_SP)' is correct. The GCC manual [1] says "The only supported use for this feature is to specify registers for input and output operands when calling Extended asm" which we are not doing here. Excluding assertions and tests, the usages are in os::current_frame() and as the input to os::stack_shadow_pages_available(). In the first case the SP seems to already be inaccurate as it points into the frame of os::current_frame() but the FP used is for the caller. In the second case I think there is only a problem if the value returned by os::current_stack_pointer() is *above* the actual SP, as then we would believe there was sufficient stack space when there really wasn't. So if it's OK to return a value slightly below the caller's SP maybe we can use __builtin_frame_address(0)? Or perhaps __builtin_frame_address(0) + 16. We could also replace the single usage of _get_previous_fp() with __builtin_frame_address(1) and avoid trying to guess whether it will be inlined or not. Thanks, Nick [1] https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html From david.holmes at oracle.com Fri May 31 05:47:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 May 2019 15:47:01 +1000 Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017 In-Reply-To: References: <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com> <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com> Message-ID: <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com> Hi Moshe, Can you update your VS 2017 installation? The only difference I can spot is that we are using Microsoft Visual Studio 2017 15.9.6 with Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27026.1 while you have: Visual Studio 2017 Developer Command Prompt v15.0.26228.86 with [Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25027 David ----- On 31/05/2019 1:55 am, Moshe Zuisman wrote: > Hi David. I have done it. with same result. > I have added?--debug-configure flag.. Attaching full configure output.. > > I am stuck with this issue and right now - have no idea - how to get out > of this "blind alley"... > > ??, 30 ??? 2019 ?. ? 12:46, David Holmes >: > > Hi Moshe, > > can you try running configure with --disable-precompiled-headers > > Thanks, > David > > On 30/05/2019 6:26 pm, Moshe Zuisman wrote: > > Configuration summary: > > ==================================================== > > The existing configuration has been successfully updated in > > > /cygdrive/c/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release > > using configure arguments '--with-boot-jdk=/cygdrive/c/jdk-11.0.3'. > > > > Configuration summary: > > * Debug level: ? ?release > > * HS debug level: product > > * JVM variants: ? server > > * JVM features: ? server: 'aot cds cmsgc compiler1 compiler2 > epsilongc > > g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc > serialgc > > services vm-structs' > > * OpenJDK target: OS: windows, CPU architecture: x86, address > length: 64 > > * Version string: 11-internal+0-adhoc.ADPRODcuser.jdk11-1ddf9a99e4ad > > (11-internal) > > > > Tools summary: > > * Environment: ? ?cygwin version 3.0.7(0.338/5/3) (root at > > /cygdrive/c/cygwin64) > > * Boot JDK: ? ? ? java version "11.0.3" 2019-04-16 LTS ?Java(TM) SE > > Runtime Environment 18.9 (build 11.0.3+12-LTS) ?Java HotSpot(TM) > 64-Bit > > Server VM 18.9 (build 11.0.3+12-LTS, mixed mode) ? (at > > /cygdrive/c/jdk-11.0.3) > > * Toolchain: ? ? ?microsoft (Microsoft Visual Studio 2017) > > * C Compiler: ? ? Version 19.10.25027 (at > > > /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl) > > * C++ Compiler: ? Version 19.10.25027 (at > > > /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl) > > > > Build performance summary: > > * Cores to use: ? 2 > > * Memory limit: ? 8191 MB > > > > WARNING: The result of this configuration has overridden an older > > configuration. You *should* run 'make clean' to make sure you get a > > proper build. Failure to do so might result in strange build > problems. > > > > ??, 30 ??? 2019 ?. ? 00:58, David Holmes > > >>: > > > >? ? ?Can you provide the configuration summary produced by configure? > > > >? ? ?It's an issue with precompiled headers but I've no idea what. > > > >? ? ?David > > > >? ? ?On 30/05/2019 5:21 am, Moshe Zuisman wrote: > >? ? ? > I? thought, that may be probleem ressults form some specific > >? ? ? > configuration on my? machine (for example I have 2 version of > >? ? ?MSVCc - > >? ? ? > 2012 and 2017. > >? ? ? > So I created clean VmWare Virtual machine and installed their > >? ? ?only MSVC > >? ? ? > 2017 and cygwin. And tried to build OPEN JDK theeir. and > got exactly > >? ? ? > same? failure. > >? ? ? > > >? ? ? > ??, 29 ??? 2019 ?. ? 09:40, Moshe Zuisman > > >? ? ?> > >? ? ? > > >>>: > >? ? ? > > >? ? ? >? ? ?I am using > >? ? ? > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281 > >? ? ? > > ? > >? ? ? > > >? ? ? > > >? ? ? >? ? ???, 29 ??? 2019 ?. ? 08:35, David Holmes > >? ? ? > > > >? ? ? >? ? ? > >? ? ? >>>: > >? ? ? > > >? ? ? >? ? ? ? ?Hi Moshe, > >? ? ? > > >? ? ? >? ? ? ? ?On 29/05/2019 2:15 am, Moshe Zuisman wrote: > >? ? ? >? ? ? ? ? > I am trying to build OPEN jdk 11 on cygwin with > MSVC 2017 > >? ? ? >? ? ? ? ? > > >? ? ? > > > > ?_________________________________________________________________________ > >? ? ? > > >? ? ? >? ? ? ? ?VS 2017 is the official supported compiler for > building > >? ? ?OpenJDK > >? ? ? >? ? ? ? ?11 [1] > >? ? ? >? ? ? ? ?and we don't see any issues. What version of the 11u > >? ? ?source are you > >? ? ? >? ? ? ? ?trying to compile? > >? ? ? > > >? ? ? >? ? ? ? ?David > >? ? ? > > >? ? ? >? ? ? ? ?[1] > >? ? ? > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > >? ? ? > > >? ? ? >? ? ? ? ? > > >? ? ? >? ? ? ? ? > > >? ? ? > > > > ?*c:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > >? ? ? >? ? ? ? ? > warning C4577: 'noexcept' used with no > exception handling > >? ? ? >? ? ? ? ?mode specified; > >? ? ? >? ? ? ? ? > termination on exception is not guaranteed. Specify > >? ? ? >? ? ? ? ?/EHscmake[3]: *** > >? ? ? >? ? ? ? ? > [lib/CompileJvm.gmk:151: > >? ? ? >? ? ? ? ? > > >? ? ? > > > > ?/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj] > >? ? ? >? ? ? ? ? > Error 1make[3]: *** Waiting for unfinished > >? ? ?jobs....make[2]: *** > >? ? ? >? ? ? ? ? > [make/Main.gmk:257: hotspot-server-libs] Error > >? ? ?2make[2]: *** > >? ? ? >? ? ? ? ?Waiting for > >? ? ? >? ? ? ? ? > unfinished jobs....ERROR: Build failed for > target 'default > >? ? ? >? ? ? ? ? > (exploded-image)' in configuration > >? ? ? >? ? ? ? ?'windows-x86_64-normal-server-release' > >? ? ? >? ? ? ? ? > (exit code 2)=== Output from failing command(s) > >? ? ?repeated here > >? ? ? >? ? ? ? ?===* For > >? ? ? >? ? ? ? ? > target > >? ? ? >? ? ? ? ? > > >? ? ? > > > > ?hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:BUILD_LIBJVM_pch.cppc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > >? ? ? >? ? ? ? ? > error C2220: warning treated as error - no > 'object' file > >? ? ? >? ? ? ? ? > > >? ? ? > > > > ?generatedc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366): > >? ? ? >? ? ? ? ? > warning C4577: 'noexcept' used with no > exception handling > >? ? ? >? ? ? ? ?mode specified; > >? ? ? >? ? ? ? ? > termination on exception is not guaranteed. > Specify /EHsc > >? ? ? >? ? ? ? ? ?... (rest of > >? ? ? >? ? ? ? ? > output omitted)* All command lines available in > >? ? ? >? ? ? ? ? > > >? ? ? > > > > ?/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/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]: *** > >? ? ? >? ? ? ? ? > > >? ? ? > > > > ?[/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305: > >? ? ? >? ? ? ? ? > main] Error 2make: *** > >? ? ? >? ? ? ? ? > > >? ? ? > > > > ?[/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186: > >? ? ? >? ? ? ? ? > default] Error 2* > >? ? ? >? ? ? ? ? > > >? ? ? > > > > From christoph.langer at sap.com Fri May 31 08:23:19 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 08:23:19 +0000 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> <3b57c56c-8b00-f9d0-aecc-4877fb3de97a@oracle.com> Message-ID: Hi Max, this looks all good to me now :) Best regards Christoph > -----Original Message----- > From: build-dev On Behalf Of > Weijun Wang > Sent: Freitag, 31. Mai 2019 05:01 > To: Erik Joelsson > Cc: security-dev at openjdk.java.net; build-dev dev at openjdk.java.net> > Subject: Re: RFR 8193255: Root Certificates should be stored in text format > and assembled at build time > > New webrev at > > https://cr.openjdk.java.net/~weijun/8193255/webrev.01 > > Changes: > > 1. Textual info at the beginning of each cert > > 2. Makefile: indentation, BUILD_TOOLS_JDK, MakeTargetDir, files instead of > dir > > Thanks, > Max > > > On May 31, 2019, at 1:34 AM, Erik Joelsson > wrote: > > > > On 2019-05-30 08:32, Weijun Wang wrote: > >> > >>> On May 30, 2019, at 10:01 PM, Erik Joelsson > wrote: > >>> > >>> In my experience, using directories for dependencies in make does not > work well. Since all the files in make/data/cacerts are in a flat structure, I > would recommend expressing the prerequisites as: > >>> > >>> $(wildcard $(GENDATA_CACERTS_SRC)/*) > >>> > >>> This will not cover the case where a file is removed, but that case is > rarely handled well in make based build systems. > >> But in my experiment, using the directory name does detect the file > removal. > > > > It believe that worked well on your machine, but directory timestamp > updates are file system dependent. I'm not sure we can count on all > filesystems to accurately reflect time stamps based on file modification. It's > also possible that an OS would touch directory timestamps for other reasons, > which should not affect the build. I haven't tried having source directories as > prerequisites before, so I simply don't know how reliable it is. My experience > is rather with directories as targets, which certainly doesn't work. If you > verified that it worked as expected on all supported OSes, I would be less > worried. > > > >> Or, can I list *both* the files and the directory to get maximum > awareness? > > > > The directory modification time will usually not change when a file in it is > modified, only when adding or removing files (and possibly some other > operations), so adding the files is certainly a must. If you go with both, then I > would just be worried about potential false positives. > > > > /Erik > > From shade at redhat.com Fri May 31 11:06:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 31 May 2019 13:06:03 +0200 Subject: RFR (M) 8225048: Shenandoah x86_32 support In-Reply-To: <52336e65-ba7d-891e-921b-eab2cb54bab1@oracle.com> References: <4fb7a59f-1ceb-af71-2038-a48ef6366087@redhat.com> <52336e65-ba7d-891e-921b-eab2cb54bab1@oracle.com> Message-ID: <73c875ae-0198-1a23-be64-db8cfa081cc0@redhat.com> On 5/30/19 3:29 PM, Erik Joelsson wrote: > Build change looks good. Thanks, Erik. Not expecting any more build changes, I am going to drop build-dev@ from the following replies on this thread. -Aleksey From robin.westberg at oracle.com Fri May 31 12:26:46 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Fri, 31 May 2019 14:26:46 +0200 Subject: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: <48ff6be3-b2f2-68e2-8082-abba17d0dcc2@oracle.com> References: <01BD2934-BC92-42A4-B6DC-C977359F0FA2@oracle.com> <48ff6be3-b2f2-68e2-8082-abba17d0dcc2@oracle.com> Message-ID: Hi Erik, > On 29 May 2019, at 17:22, Erik Joelsson wrote: > > Thanks, looks good! Thanks for reviewing! Unfortunately I had to do a few more general changes to get the ?ccls" indexer working properly as well, hope you don?t mind taking another look: Webrevs: - Full: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.03/ - Inc: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.02-03/ Best regards, Robin > > /Erik > > On 2019-05-29 06:52, Robin Westberg wrote: >> Hi Erik, >> >> Thanks for taking a look! >> >>> On 28 May 2019, at 15:52, Erik Joelsson wrote: >>> >>> Hello Robin, >>> >>> Looks good. >>> >>> Adding of ide.md is very nice, but could you try to format it like testing.md and building.md in regards to line lengths? I believe we are trying for 80 chars in those to make them read reasonably in a standard editor. >> Sure, did a bit of reflowing and updated some formatting in order to look more like the other .md files. >> >> Webrevs: >> - Full: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.02/ >> - Inc: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01-02/ >> >> Best regards, >> Robin >> >>> /Erik >>> >>> On 2019-05-27 09:03, Robin Westberg wrote: >>>> Hi all, >>>> >>>> Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE. >>>> >>>> The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html]. >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8223678 >>>> >>>> Webrev: >>>> https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/ >>>> >>>> Testing: >>>> Manual testing on Linux, MacOS and Windows >>>> >>>> Thanks Erik Joelsson for taking a look at an earlier version of it! >>>> >>>> Best regards, >>>> Robin From robin.westberg at oracle.com Fri May 31 12:27:31 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Fri, 31 May 2019 14:27:31 +0200 Subject: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: References: <43102FEE-DF34-4D9B-A503-155F80E8D967@oracle.com> Message-ID: <16F9D7B8-E330-4B52-ACFA-773744DEA114@oracle.com> Hi Volker, > On 29 May 2019, at 16:01, Volker Simonis wrote: > > On Wed, May 29, 2019 at 3:43 PM Robin Westberg > wrote: >> >> Hi Volker, >> >>> On 28 May 2019, at 17:33, Volker Simonis wrote: >>> >>> Hi Robin, >>> >>> thanks a lot for doing this! >>> >>> I have just a quick question. Do you know if any of the VSC indexers >>> (default, clangd) support call hierarchies (i.e. "called by", >>> "callers" of a function/method) and "used by" for variables/class >>> fields? >> >> Sure, I can make a quick summary of the various pros and cons of the indexers that I?ve found so far. They are all moving pretty fast though, so didn?t think it was a good fit for the documentation file. >> >> In general, VS Code itself only just recently gained proper support for displaying call hierarchies: https://urldefense.proofpoint.com/v2/url?u=https-3A__code.visualstudio.com_updates_v1-5F33-23-5Fcall-2Dhierarchy&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=UJlIwvo0Thp_BYS_NWFT0ryBTIkcL2KhsFz8CKsa4GY&m=82pYT4_vb0KoCg2J7f8ZHebXioM2IbSDUpVgSuUAz-A&s=yY4u7WPyw8IMAQOytIDpU3MePzQMuGgCTyIP4XuHXbI&e= - but alternative indexers have worked around this by showing them differently. >> >> Default (Microsoft - C/C++ for Visual Studio Code) >> + Easy to setup, as no additional dependencies are needed >> + Good ?go to definition?, the only one that can make sense of the template+macro stuff in log.hpp for example >> - Find references (used by) not done yet (said to be coming in the June update: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_microsoft_vscode-2Dcpptools_issues_15&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=UJlIwvo0Thp_BYS_NWFT0ryBTIkcL2KhsFz8CKsa4GY&m=82pYT4_vb0KoCg2J7f8ZHebXioM2IbSDUpVgSuUAz-A&s=usQi8Sluzbg7sm51fLwBgFVSkY8uj_ZkOgFhT6clIjw&e=) >> - Call hierarchies also not there (scheduled for September apparently: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_microsoft_vscode-2Dcpptools_issues_16&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=UJlIwvo0Thp_BYS_NWFT0ryBTIkcL2KhsFz8CKsa4GY&m=82pYT4_vb0KoCg2J7f8ZHebXioM2IbSDUpVgSuUAz-A&s=0nJoexh1jJuqrNQ5bhxtpwdzS9LhGYhzKyEmFbM1D8A&e=) >> >> clangd >> + Actively developed and part of the llvm/clang project >> + Support for find references >> - ..but not call hierarchies yet >> - Full project indexing is still flagged as experimental, and currently seems to fail when editing commonly used header files for example >> >> Full feature list: https://urldefense.proofpoint.com/v2/url?u=https-3A__clang.llvm.org_extra_clangd_Features.html-23complete-2Dlist-2Dof-2Dfeatures&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=UJlIwvo0Thp_BYS_NWFT0ryBTIkcL2KhsFz8CKsa4GY&m=82pYT4_vb0KoCg2J7f8ZHebXioM2IbSDUpVgSuUAz-A&s=-59_vkfX4TV8qO7PoHopjLBC1c2Qu-HjneQnNM49Zps&e= >> >> rtags >> This is currently the most feature-complete indexer I think. But the VS Code integration is a bit minimal and not part of the rtags project itself, and it is missing things like indexer progress. >> + The indexer is actively developed and has been around for quite some time >> - You will probably have to build the indexer from source >> + Full support for call hierarchies and find references >> - VS Code integration a bit limited, missing convenience features like switch between header/source file, showing method/class documentation on hover. >> >> There are even more indexers of course, a promising one used to be ?cquery", but that project seems to be defunct now. It lives on in the ?ccls" indexer, but ithat one is a bit tricky to configure unless you use clang for building the JDK as well. >> >> So in summary, after the summer the default indexer might be the obvious best choice, but right now it depends on which features you think are the most important I guess.. >> > > Hi Robin, > > thanks a lot for the great summary! Incidentally I've just did some > Google research as well and basically came to the same conclusion. > "Cquery" seemed quite promising and also pretends to have call > hierarchies. But it seems to be defunct and I've also found some bug > reports about problems with the call hierarchies. Yeah, cquery did work okay when I tried it, but had some issues. However, the ?spiritual? successor ccls has fixed all the issues I had with cquery, I spent a bit more time on configuring it today and finally figured out why it didn?t work! > For me "Called Hierarchy", and "Find References" (in this order) are > really the most important IDE features. I'm using Eclipse and if you > setup your HotSpot project correctly, these features work pretty well > and reliably. > > Have you personally tried the rtags "call hierarchies" / "find > references" support in VSC? From your summary it sounds like it's > worth giving it a try. Only tried it a bit, but I know other HotSpot developers that use it with emacs / vim. But the VS Code integration is really bare-bones, so a bit hard to use it in practice. But now that ccls actually works, I can really recommend you try that one, working very good for me so far! > Thanks again for caring about these topics! Hotspot development with > IDE support has always been a pain and every improvement in this area > will be highly welcome :) Sure, I mostly do it since I want to be able to use a good IDE myself, but it?s always nice if others can benefit from it too. :) Best regards, Robin > > Best regards, > Volker > >> Best regards, >> Robin >> >>> >>> Regards, >>> Volker >>> >>> On Mon, May 27, 2019 at 6:03 PM Robin Westberg >>> wrote: >>>> >>>> Hi all, >>>> >>>> Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE. >>>> >>>> The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html]. >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8223678 >>>> >>>> Webrev: >>>> https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/ >>>> >>>> Testing: >>>> Manual testing on Linux, MacOS and Windows >>>> >>>> Thanks Erik Joelsson for taking a look at an earlier version of it! >>>> >>>> Best regards, >>>> Robin From sean.mullan at oracle.com Fri May 31 15:15:07 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 31 May 2019 11:15:07 -0400 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: <85D686DF-0C04-4666-922D-50D41DFB0621@oracle.com> References: <60fb9ad0-19f3-52d0-b5b4-7b5808a1b4e2@oracle.com> <85D686DF-0C04-4666-922D-50D41DFB0621@oracle.com> Message-ID: <7ac9538f-664a-7e14-4bd6-513749339f8f@oracle.com> On 5/30/19 8:49 PM, Weijun Wang wrote: > Sure. How many info do you want to see? > > I can prepend `keytool -printcert` but that's too much. At least I think the extensions part is not needed. Also, I don't wish people reading the fingerprint inside as genuine and does not calculate it from the cert itself. > > So, I'm thinking of > > Owner: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US > Issuer: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US > Serial number: 50946cec18ead59c4dd597ef758fa0ad > Valid from: 1 Nov 2004 17:14:04 GMT until: 1 Jan 2035 05:37:19 GMT > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 2048-bit RSA key > Version: 3 > > Is that OK? This is good. Did you use keytool to emit those fields? It might make sense to add a brief README in this directory with instructions or a code snippet so that the next time we add a cert we know what to include at the top for consistency. Thanks, Sean > > Thanks, > Max > > p.s. `keytool -printcert` shows validity in local timezone. Does not look good to me. > >> On May 31, 2019, at 6:51 AM, Sean Mullan wrote: >> >> One suggestion is to put a printable form of the contents of the certificate at the top of each of the PEM files. It would be nice as a quick-look to see what is in the certificate. Of course, you can also use keytool -printcert to do that, but if I am just perusing the source code via a browser or something like that, it would be nice to not have to do that. >> >> --Sean >> >> On 5/30/19 9:01 AM, Weijun Wang wrote: >>> Please take a review at >>> http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ >>> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. >>> There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line >>> $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) >>> means when when the tool is changed, GENDATA_CACERTS will be called. >>> Thanks, >>> Max > From erik.joelsson at oracle.com Fri May 31 16:15:28 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 31 May 2019 09:15:28 -0700 Subject: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: References: <01BD2934-BC92-42A4-B6DC-C977359F0FA2@oracle.com> <48ff6be3-b2f2-68e2-8082-abba17d0dcc2@oracle.com> Message-ID: Hello Robin, On 2019-05-31 05:26, Robin Westberg wrote: > Hi Erik, > >> On 29 May 2019, at 17:22, Erik Joelsson wrote: >> >> Thanks, looks good! > Thanks for reviewing! Unfortunately I had to do a few more general changes to get the ?ccls" indexer working properly as well, hope you don?t mind taking another look: > > Webrevs: > - Full: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.03/ > - Inc: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.02-03/ Looks good! I sure appreciate adding tests when modifying the hairier utility macros. /Erik > Best regards, > Robin > >> /Erik >> >> On 2019-05-29 06:52, Robin Westberg wrote: >>> Hi Erik, >>> >>> Thanks for taking a look! >>> >>>> On 28 May 2019, at 15:52, Erik Joelsson wrote: >>>> >>>> Hello Robin, >>>> >>>> Looks good. >>>> >>>> Adding of ide.md is very nice, but could you try to format it like testing.md and building.md in regards to line lengths? I believe we are trying for 80 chars in those to make them read reasonably in a standard editor. >>> Sure, did a bit of reflowing and updated some formatting in order to look more like the other .md files. >>> >>> Webrevs: >>> - Full: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.02/ >>> - Inc: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01-02/ >>> >>> Best regards, >>> Robin >>> >>>> /Erik >>>> >>>> On 2019-05-27 09:03, Robin Westberg wrote: >>>>> Hi all, >>>>> >>>>> Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE. >>>>> >>>>> The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html]. >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8223678 >>>>> >>>>> Webrev: >>>>> https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/ >>>>> >>>>> Testing: >>>>> Manual testing on Linux, MacOS and Windows >>>>> >>>>> Thanks Erik Joelsson for taking a look at an earlier version of it! >>>>> >>>>> Best regards, >>>>> Robin From erik.joelsson at oracle.com Fri May 31 16:17:42 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 31 May 2019 09:17:42 -0700 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> <3b57c56c-8b00-f9d0-aecc-4877fb3de97a@oracle.com> Message-ID: <7cf607f6-cbfa-ed74-a02b-b780d65d7d30@oracle.com> This looks good to me, and thanks for fixing the other instances of BUILD_TOOLS_JDK! /Erik On 2019-05-30 20:00, Weijun Wang wrote: > New webrev at > > https://cr.openjdk.java.net/~weijun/8193255/webrev.01 > > Changes: > > 1. Textual info at the beginning of each cert > > 2. Makefile: indentation, BUILD_TOOLS_JDK, MakeTargetDir, files instead of dir > > Thanks, > Max > >> On May 31, 2019, at 1:34 AM, Erik Joelsson wrote: >> >> On 2019-05-30 08:32, Weijun Wang wrote: >>>> On May 30, 2019, at 10:01 PM, Erik Joelsson wrote: >>>> >>>> In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as: >>>> >>>> $(wildcard $(GENDATA_CACERTS_SRC)/*) >>>> >>>> This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems. >>> But in my experiment, using the directory name does detect the file removal. >> It believe that worked well on your machine, but directory timestamp updates are file system dependent. I'm not sure we can count on all filesystems to accurately reflect time stamps based on file modification. It's also possible that an OS would touch directory timestamps for other reasons, which should not affect the build. I haven't tried having source directories as prerequisites before, so I simply don't know how reliable it is. My experience is rather with directories as targets, which certainly doesn't work. If you verified that it worked as expected on all supported OSes, I would be less worried. >> >>> Or, can I list *both* the files and the directory to get maximum awareness? >> The directory modification time will usually not change when a file in it is modified, only when adding or removing files (and possibly some other operations), so adding the files is certainly a must. If you go with both, then I would just be worried about potential false positives. >> >> /Erik >> From erik.joelsson at oracle.com Fri May 31 20:36:56 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 31 May 2019 13:36:56 -0700 Subject: RFR: JDK-8225140: Build fails if directory contains 'unix' Message-ID: <39a9268d-ccaa-3774-be92-fff6c3b9a40d@oracle.com> If the workspace directory (or any parent) contains the word "unix", the build fails in java.desktop-libs. There are several libraries here that use the EXCLUDE_SRC_FILTER option of SetupJdkLibrary to filter away the src/java.desktop/unix/lib* dirs. This option incorrectly includes the whole absolute path of each source file when applying the filter, so when the workspace dir contains "unix", these libraries get no source files at all. This patch changes the filter mechanics to only apply to the path relative to the workspace root. I also changed the filter token from "unix" to "/unix/" to avoid the risk of matching substrings in directories in the future. Bug: https://bugs.openjdk.java.net/browse/JDK-8225140 Webrev: http://cr.openjdk.java.net/~erikj/8225140/webrev.01/index.html /Erik From tim.bell at oracle.com Fri May 31 20:43:19 2019 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 31 May 2019 13:43:19 -0700 Subject: RFR: JDK-8225140: Build fails if directory contains 'unix' In-Reply-To: <39a9268d-ccaa-3774-be92-fff6c3b9a40d@oracle.com> References: <39a9268d-ccaa-3774-be92-fff6c3b9a40d@oracle.com> Message-ID: <5CF191E7.2060606@oracle.com> Erik: > This patch changes the filter mechanics to only apply to the path > relative to the workspace root. I also changed the filter token from > "unix" to "/unix/" to avoid the risk of matching substrings in > directories in the future. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225140 > > Webrev: http://cr.openjdk.java.net/~erikj/8225140/webrev.01/index.html Looks good. Tim From kim.barrett at oracle.com Fri May 31 20:46:38 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 31 May 2019 16:46:38 -0400 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> Message-ID: <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> > On May 31, 2019, at 12:11 AM, Nick Gasson wrote: >>> /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:43:39: error: cannot initialize a parameter of type 'char *' with an lvalue of type 'unsigned long' >>> return __sync_add_and_fetch(dest, add_value); >>> ^~~~~~~~~ >>> >>> If the add_and_fetch template is instantiated with I=integer and >>> D=pointer then we need an explicit cast here. >> >> Please don't. Please have a look at where this happens and fix the >> types there, as appropriate. What do other ports do? > > It's instantiated here: > > /home/nicgas01/jdk/src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp:259:34: note: in instantiation of function template specialization 'Atomic::add' requested here > char* touch_addr = Atomic::add(actual_chunk_size, &_cur_addr) - actual_chunk_size; > ^ > > We're adding an unsigned long to a char* which seems legitimate. > > The other ports except Arm32 and Zero use inline assembly so don't have > problems with mismatched types. Zero uses __sync_fetch_and_add so would > hit this too if it used G1. > > I'm not sure how to resolve this. We could add a specialisation of > PlatformAdd for byte_size=8 and cast to (u)intptr_t? > > template<> > struct Atomic::PlatformAdd<8> > : Atomic::AddAndFetch > > { > template > D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const { > STATIC_ASSERT(8 == sizeof(I)); > STATIC_ASSERT(8 == sizeof(D)); > > typedef typename Conditional::value, intptr_t, uintptr_t>::type PI; > > PI res = __sync_add_and_fetch(reinterpret_cast(dest), > static_cast(add_value)); > return reinterpret_cast(res); > } > } > > I think this is safe. If I'm reading the gcc documentation for __sync_add_and_fetch correctly, I think the following (completely untested) should work, and won't cause Andrew to (I think rightly) complain about type-punning reinterpret_casts. Though I wonder if this is a clang bug. (See below.) template struct Atomic::PlatformAdd : Atomic::AddAndFetch > { template D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const { // Cast to work around clang pointer arithmetic bug. return PrimitiveConversions::cast(__sync_add_and_fetch(dest, add_value)); } } The key bit from the documentation is "Operations on pointer arguments are performed as if the operands were of the uintptr_t type." The bug description says this warning only arises with clang. It seems like clang is overdoing that as-if, and treating it literally as uintptr_t all the way through to the result type. The documentation also says "That is, they are not scaled by the size of the type to which the pointer points." Any needed scaling of add_value has already been done in the calling Atomic::AddImpl. From kim.barrett at oracle.com Fri May 31 21:02:10 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 31 May 2019 17:02:10 -0400 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> Message-ID: <176A09BD-F7A8-4565-8E14-658F380891B3@oracle.com> > On May 31, 2019, at 4:46 PM, Kim Barrett wrote: > >> On May 31, 2019, at 12:11 AM, Nick Gasson wrote: >> >> /home/nicgas01/jdk/src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp:259:34: note: in instantiation of function template specialization 'Atomic::add' requested here >> char* touch_addr = Atomic::add(actual_chunk_size, &_cur_addr) - actual_chunk_size; >> ^ > [?] > If I'm reading the gcc documentation for __sync_add_and_fetch > correctly, I think the following (completely untested) should work, > and won't cause Andrew to (I think rightly) complain about > type-punning reinterpret_casts. > > Though I wonder if this is a clang bug. (See below.) > > [?] > The bug description says this warning only arises with clang. It > seems like clang is overdoing that as-if, and treating it literally as > uintptr_t all the way through to the result type. Or don?t change the code at all here, and say that clang is not (currently) a supported compiler for this platform. From jonathan.gibbons at oracle.com Fri May 31 21:02:57 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 31 May 2019 14:02:57 -0700 Subject: RFR: docs JDK-8225134: Update man-page files Message-ID: <40d2e8ce-9302-a6e1-a2a1-c98c251c7661@oracle.com> Please review a change to refresh the content of the man pages (*.1 files) in the main repo, to contain essentially the exact same content as found in the Oracle JDK man pages. Going forward, the intent is to bulk-update these pages towards the end of each release cycle, until we can eventually open source the underlying files from which the man pages are derived, at which time these files will be deleted. This email is to build-dev at ojn, even though there are no Makefile changes, because that list includes the folk mostly likely to make direct use of these files.? It is also cc jdk-dev at ojn so that the OpenJDK community is generally aware of this change. Note, although the current man pages share a history with the previous versions of these files, the transformations that have occurred between then and now make it all but impossible to compare the versions side by side with diff. For those folk wanting to review the content, it is best to look at the "New" or "Raw" files in the webrev. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8225134 Webrev: http://cr.openjdk.java.net/~jjg/8225134/webrev.00/webrev/ From erik.joelsson at oracle.com Fri May 31 21:31:29 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 31 May 2019 14:31:29 -0700 Subject: RFR: docs JDK-8225134: Update man-page files In-Reply-To: <40d2e8ce-9302-a6e1-a2a1-c98c251c7661@oracle.com> References: <40d2e8ce-9302-a6e1-a2a1-c98c251c7661@oracle.com> Message-ID: <075cb653-155a-4398-f5e9-2bb2b7ca1f7d@oracle.com> Looks good to me. /Erik On 2019-05-31 14:02, Jonathan Gibbons wrote: > Please review a change to refresh the content of the man pages (*.1 > files) in the main repo, > to contain essentially the exact same content as found in the Oracle > JDK man pages. > > Going forward, the intent is to bulk-update these pages towards the > end of each release > cycle, until we can eventually open source the underlying files from > which the man pages > are derived, at which time these files will be deleted. > > This email is to build-dev at ojn, even though there are no Makefile > changes, because that > list includes the folk mostly likely to make direct use of these > files.? It is also cc jdk-dev at ojn > so that the OpenJDK community is generally aware of this change. > > Note, although the current man pages share a history with the previous > versions of these > files, the transformations that have occurred between then and now > make it all but > impossible to compare the versions side by side with diff. For those > folk wanting to review > the content, it is best to look at the "New" or "Raw" files in the > webrev. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225134 > Webrev: http://cr.openjdk.java.net/~jjg/8225134/webrev.00/webrev/ > > From mandy.chung at oracle.com Fri May 31 23:25:30 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 31 May 2019 16:25:30 -0700 Subject: RFR: docs JDK-8225134: Update man-page files In-Reply-To: <40d2e8ce-9302-a6e1-a2a1-c98c251c7661@oracle.com> References: <40d2e8ce-9302-a6e1-a2a1-c98c251c7661@oracle.com> Message-ID: <2818197a-ee23-9673-32e2-7e3951a20135@oracle.com> Bringing these pages to more recent version is better than the current so outdated version even it's just a snapshot. The list of new pages look okay (but I didn't validate the content.) Mandy On 5/31/19 2:02 PM, Jonathan Gibbons wrote: > Please review a change to refresh the content of the man pages (*.1 > files) in the main repo, > to contain essentially the exact same content as found in the Oracle > JDK man pages. > > Going forward, the intent is to bulk-update these pages towards the > end of each release > cycle, until we can eventually open source the underlying files from > which the man pages > are derived, at which time these files will be deleted. > > This email is to build-dev at ojn, even though there are no Makefile > changes, because that > list includes the folk mostly likely to make direct use of these > files.? It is also cc jdk-dev at ojn > so that the OpenJDK community is generally aware of this change. > > Note, although the current man pages share a history with the previous > versions of these > files, the transformations that have occurred between then and now > make it all but > impossible to compare the versions side by side with diff. For those > folk wanting to review > the content, it is best to look at the "New" or "Raw" files in the > webrev. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225134 > Webrev: http://cr.openjdk.java.net/~jjg/8225134/webrev.00/webrev/ > > From weijun.wang at oracle.com Fri May 31 23:47:14 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 1 Jun 2019 07:47:14 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: <7ac9538f-664a-7e14-4bd6-513749339f8f@oracle.com> References: <60fb9ad0-19f3-52d0-b5b4-7b5808a1b4e2@oracle.com> <85D686DF-0C04-4666-922D-50D41DFB0621@oracle.com> <7ac9538f-664a-7e14-4bd6-513749339f8f@oracle.com> Message-ID: > On May 31, 2019, at 11:15 PM, Sean Mullan wrote: > > On 5/30/19 8:49 PM, Weijun Wang wrote: >> Sure. How many info do you want to see? >> I can prepend `keytool -printcert` but that's too much. At least I think the extensions part is not needed. Also, I don't wish people reading the fingerprint inside as genuine and does not calculate it from the cert itself. >> So, I'm thinking of >> Owner: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US >> Issuer: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US >> Serial number: 50946cec18ead59c4dd597ef758fa0ad >> Valid from: 1 Nov 2004 17:14:04 GMT until: 1 Jan 2035 05:37:19 GMT >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 2048-bit RSA key >> Version: 3 >> Is that OK? > > This is good. Did you use keytool to emit those fields? Yes. > It might make sense to add a brief README in this directory with instructions or a code snippet so that the next time we add a cert we know what to include at the top for consistency. OK, so it might contain: -----START----- Each file in this directory (except for this README) contains a CA certificate in PEM format. It can be generated with keytool -J-Duser.timezone=GMT -printcert -file ca.cert | sed -n '1,4p;8,10p' keytool -printcert -file ca.cert -rfc Please note the textual comment is just a suggestion and not arbitrary. After any change in this directory, please remember to update the content of `test/jdk/sun/security/lib/cacerts/VerifyCACerts.java` as well. -----END----- And I'll need to skip this README file in the build tool. --Max > > Thanks, > Sean > >> Thanks, >> Max >> p.s. `keytool -printcert` shows validity in local timezone. Does not look good to me. >>> On May 31, 2019, at 6:51 AM, Sean Mullan wrote: >>> >>> One suggestion is to put a printable form of the contents of the certificate at the top of each of the PEM files. It would be nice as a quick-look to see what is in the certificate. Of course, you can also use keytool -printcert to do that, but if I am just perusing the source code via a browser or something like that, it would be nice to not have to do that. >>> >>> --Sean >>> >>> On 5/30/19 9:01 AM, Weijun Wang wrote: >>>> Please take a review at >>>> http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ >>>> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. >>>> There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line >>>> $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) >>>> means when when the tool is changed, GENDATA_CACERTS will be called. >>>> Thanks, >>>> Max