From magnus.ihse.bursie at oracle.com Thu Mar 1 00:48:20 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 1 Mar 2018 01:48:20 +0100 Subject: RFR: JDK-8198862 Stop doing funky compilation stuff for dtrace Message-ID: We're doing a lot of weird compilation stuff for dtrace. With this patch, most of the weirdness is removed. The remaining calls to $(CC) -E has been changed to $(CPP) to clarify that we do not compile, we just use the precompiler. One of the changes I made was to actually split up the last and final dtrace call into a separate preprocessing step. However, this uses the solaris studio preprocessor instead of the ancient system preprocessor, which has changed behavior. A string like (&``_var) is now expanded to (& ` ` _var), which is not accepted by dtrace. :-( I have worked around this by adding the preprocessed output, without the spaces, in two places. If anyone wants to dig deeper into dtrace script file syntax, or C preprocessor magic, to avoid this, let me know... (I'll just state that the "obvious" solution of sending -Xs to the preprocessor to get old-style behavior does not work: this just makes the solaris studio preprocessor call the ancient preprocessor in turn, and we've gained nothing...) Bug: https://bugs.openjdk.java.net/browse/JDK-8198862 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.01 /Magnus From paul.sandoz at oracle.com Thu Mar 1 01:29:18 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 28 Feb 2018 17:29:18 -0800 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: <144F8EF0-0020-4577-8F9B-3FC86AF8ED4A@oracle.com> References: <0EC6FFD0-31EA-4D24-B82D-C4D5DCAB8E65@oracle.com> <144F8EF0-0020-4577-8F9B-3FC86AF8ED4A@oracle.com> Message-ID: > On Feb 28, 2018, at 1:22 PM, Lance Andersen wrote: > >> >> On Feb 28, 2018, at 2:20 PM, Lance Andersen > wrote: >> >> Hi Paul, >> >> Thank you for the review. >>> On Feb 28, 2018, at 1:40 PM, Paul Sandoz > wrote: >>> >>> Compatible module refactoring in action! >>> >>> Looks good, one comment: >>> >>> test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java >>> >>> This is not a valid Java source file can you merge the jtreg meta data into XAExceptionTests instead? >> >> As we discussed offline, I will change the above file and Driver.java. I naively assumed this was OK as the change to add Driver.java was made after I had originally added these tests in 2015. > > http://cr.openjdk.java.net/~lancea/8197533/webrev.01/ has the updated tests +1, i second Joe?s request to update package-info.java while we are opportunistically cleaning this area up. Paul. From magnus.ihse.bursie at oracle.com Thu Mar 1 10:01:51 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 1 Mar 2018 11:01:51 +0100 Subject: RFR: JDK-8198859 Use elfedit to silence linker warnings on solaris Message-ID: <9ee6427c-892b-bcb2-e1c4-a819f36e5ae0@oracle.com> Solaris builds have always produced a lot of warnings when linking, like this: ld: fatal: symbol '__JvmOffsets' has differing types: ??? (file /export/home/magnusi/hg/sandbox-cflags/build/solaris-sparcv9/hotspot/variant-server/libjvm/objs/JvmOffsets.o type=OBJT; file /export/home/magnusi/hg/sandbox-cflags/build/solaris-sparcv9/hotspot/variant-server/libjvm/objs/dtrace_jhelper.o type=FUNC); This is due to an unresolved bug in dtrace. This bug has been reported on the dtrace team in 2014, but no solution have been coming forth. :-( However, I just discovered that we can actually use elfedit to fix the type of the fields that the linker is complaining about on $(DTRACE_JHELPER_OBJ). That will make the linker quiet. Bug: https://bugs.openjdk.java.net/browse/JDK-8198859 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198859-dtrace-warnings-workaround/webrev.01 /Magnus From mvala at redhat.com Thu Mar 1 11:36:37 2018 From: mvala at redhat.com (Michal Vala) Date: Thu, 1 Mar 2018 12:36:37 +0100 Subject: jdk10 bootcycle build linux failing Message-ID: <934c9aa4-35bc-6975-338b-65318923a389@redhat.com> Hi, I have an issue with bootcycle build. First run with external boot jdk is ok, but bootcycle phase always fails. I'm building on fedora27(local) and rhel7(VM). In case of local, build consume too much memory and kill my OS. I've tried to set `with-memory-size` but it seems like it accepts this value just for first build, but not for bootcycle. I'm building with: $ bash ./configure --disable-warnings-as-errors --with-boot-jdk=/home/tester/jdk-9.0.4 $ make bootcycle-images I suspect that build eats too much memory and OS kills some process, but I'm lack of knowledge here. Anyone else meeting similar issue? end of build log inlined here. I can provide more, but I was not able to find any useful log output: collect2: error: ld terminated with signal 9 [Killed] gmake[5]: *** [/home/tester/openjdk/build/linux-x86_64-normal-server-release/bootcycle-build/hotspot/variant-server/libjvm/gtest/libjvm.so] Error 1 gmake[5]: *** Deleting file `/home/tester/openjdk/build/linux-x86_64-normal-server-release/bootcycle-build/hotspot/variant-server/libjvm/gtest/libjvm.so' gmake[5]: *** Waiting for unfinished jobs.... gmake[4]: *** [hotspot-server-libs] Error 1 ERROR: Build failed for target 'product-images' in configuration 'linux-x86_64-normal-server-release' (exit code 2) gmake[4]: warning: -jN forced in submake: disabling jobserver mode. Stopping sjavac server === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: collect2: error: ld terminated with signal 9 [Killed] * All command lines available in /home/tester/openjdk/build/linux-x86_64-normal-server-release/bootcycle-build/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. gmake[3]: *** [main] Error 1 gmake[2]: *** [bootcycle-images] Error 2 ERROR: Build failed for target 'bootcycle-images' in configuration 'linux-x86_64-normal-server-release' (exit code 2) 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: *** [bootcycle-images] Error 2 -- Michal Vala OpenJDK QE Red Hat Czech From tong-kai.wang at oracle.com Thu Mar 1 09:38:12 2018 From: tong-kai.wang at oracle.com (Andrew Wang) Date: Thu, 1 Mar 2018 17:38:12 +0800 Subject: Problems of building JDK 10 on Windows 7 machine Message-ID: <89737101-b5e7-8b82-979e-e3dcfc57ed2d@oracle.com> Hi, I am trying to build JDK 10 from http://hg.openjdk.java.net/jdk10/jdk10 and also using JIB (JIB_SERVER=https://java.se.oracle.com/artifactory) to configure/make as the following: bash get_source.sh bash common/bin/jib.sh configure bash common/bin/jib.sh make It seems that test_json.cpp caused the error which failed the build process: c:/openJDK/jdk10/hotspot/test/native/utilities/test_json.cpp : error C2220: warning treated as error - no 'object' file generated Do you know how to resolve it? Thanks and regards, Andrew From tim.bell at oracle.com Thu Mar 1 16:32:31 2018 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 01 Mar 2018 08:32:31 -0800 Subject: RFR: JDK-8198859 Use elfedit to silence linker warnings on solaris In-Reply-To: <9ee6427c-892b-bcb2-e1c4-a819f36e5ae0@oracle.com> References: <9ee6427c-892b-bcb2-e1c4-a819f36e5ae0@oracle.com> Message-ID: <5A982B1F.8060301@oracle.com> Magnus: > Solaris builds have always produced a lot of warnings when linking, like > this: > > ld: fatal: symbol '__JvmOffsets' has differing types: > (file > /export/home/magnusi/hg/sandbox-cflags/build/solaris-sparcv9/hotspot/variant-server/libjvm/objs/JvmOffsets.o > type=OBJT; file > /export/home/magnusi/hg/sandbox-cflags/build/solaris-sparcv9/hotspot/variant-server/libjvm/objs/dtrace_jhelper.o > type=FUNC); > > This is due to an unresolved bug in dtrace. This bug has been reported > on the dtrace team in 2014, but no solution have been coming forth. :-( > However, I just discovered that we can actually use elfedit to fix the > type of the fields that the linker is complaining about on > $(DTRACE_JHELPER_OBJ). > > That will make the linker quiet. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198859 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198859-dtrace-warnings-workaround/webrev.01 Looks good. Tim From lance.andersen at oracle.com Thu Mar 1 16:59:08 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Mar 2018 11:59:08 -0500 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: References: <0EC6FFD0-31EA-4D24-B82D-C4D5DCAB8E65@oracle.com> <144F8EF0-0020-4577-8F9B-3FC86AF8ED4A@oracle.com> Message-ID: > On Feb 28, 2018, at 8:29 PM, Paul Sandoz wrote: > > > >> On Feb 28, 2018, at 1:22 PM, Lance Andersen > wrote: >> >>> >>> On Feb 28, 2018, at 2:20 PM, Lance Andersen > wrote: >>> >>> Hi Paul, >>> >>> Thank you for the review. >>>> On Feb 28, 2018, at 1:40 PM, Paul Sandoz > wrote: >>>> >>>> Compatible module refactoring in action! >>>> >>>> Looks good, one comment: >>>> >>>> test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java >>>> >>>> This is not a valid Java source file can you merge the jtreg meta data into XAExceptionTests instead? >>> >>> As we discussed offline, I will change the above file and Driver.java. I naively assumed this was OK as the change to add Driver.java was made after I had originally added these tests in 2015. >> >> http://cr.openjdk.java.net/~lancea/8197533/webrev.01/ has the updated tests > > +1, i second Joe?s request to update package-info.java while we are opportunistically cleaning this area up. Per your and Joe?s request, please see cr.openjdk.java.net/~lancea/8197533/webrev.02 which has your suggested update to use package-info.java Thank you both Best Lance > > Paul. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From paul.sandoz at oracle.com Thu Mar 1 17:37:19 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Mar 2018 09:37:19 -0800 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: References: <0EC6FFD0-31EA-4D24-B82D-C4D5DCAB8E65@oracle.com> <144F8EF0-0020-4577-8F9B-3FC86AF8ED4A@oracle.com> Message-ID: <945D4802-2632-4082-8970-2E983320C55A@oracle.com> +1 > On Mar 1, 2018, at 8:59 AM, Lance Andersen wrote: >> >> +1, i second Joe?s request to update package-info.java while we are opportunistically cleaning this area up. > > Per your and Joe?s request, please see cr.openjdk.java.net/~lancea/8197533/webrev.02 which has your suggested update to use package-info.java > > Thank you both > > Best > Lance From erik.joelsson at oracle.com Thu Mar 1 19:50:28 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 11:50:28 -0800 Subject: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs In-Reply-To: <8879f698-c34e-8a8c-affa-9a01cba95934@oracle.com> References: <8879f698-c34e-8a8c-affa-9a01cba95934@oracle.com> Message-ID: On 2018-02-26 12:57, joe darcy wrote: > Hi Magnus, > > Looks okay for now, but longer term should the version be queried from > the environment some way? > The problem as I understand it is that the URL is dead until the docs team creates it, which doesn't necessarily happen in sync with us bumping the version number in the jdk/jdk repository. Perhaps that's ok early in the release? /Erik > Thanks, > > -Joe > > > On 2/26/2018 12:38 PM, Magnus Ihse Bursie wrote: >> It was recently discovered that some URLs in JDK 10 still pointed to >> the "javase9" URL base. >> >> I intend to push this to jdk10/master, given suffient approval. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198658 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-links-to-javase10/webrev.01 >> >> /Magnus >> > From Alan.Bateman at oracle.com Thu Mar 1 19:52:14 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Mar 2018 19:52:14 +0000 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> Message-ID: <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> On 01/03/2018 18:44, Brian Burkhalter wrote: > On Feb 28, 2018, at 8:34 AM, Alan Bateman > wrote: > >> This look okay but I think we should looking at creating this .so in >> the build, like we do for libDirectIO.so to create the shared library >> needed for the direct I/O tests. All the details in >> test/JtregNativeJdk.gmk. > > Consider it done: > > http://cr.openjdk.java.net/~bpb/8198834/webrev.00/ > > > This removes the Makefile and all .so files. The change has been > verified to work on linux-64 and solaris-sparcv9. > The rename of Launcher.c looks a bit strange, the original name looks better to me. I see it doesn't have a copyright header so we should fix that. For the README then you can split the jtreg line to make it easier to read. Otherwise looks good to me and happy to see these checked-in .so files going away. -Alan From erik.joelsson at oracle.com Thu Mar 1 19:54:20 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 11:54:20 -0800 Subject: RFR(S) 8197453 : Add support of extra problem list In-Reply-To: <565cbc8c-64e7-8fd8-65a8-84564b2ce49b@oracle.com> References: <565cbc8c-64e7-8fd8-65a8-84564b2ce49b@oracle.com> Message-ID: <1b2b62ce-6c7d-9935-28c4-7a86371c38b8@oracle.com> Makefile change looks good. /Erik On 2018-02-27 09:45, Ekaterina Pavlova wrote: > Jon, > > thanks for the review. > I have updated the webrev. > > thanks, > -katya > > > On 2/26/18 12:02 PM, Jonathan Gibbons wrote: >> If these new problem-list files are destined for use by jtreg, I >> would encourage adding a platform specifier on each line, after the >> bug number. If you want to mark the test as excluded on all >> platforms, the convention is to use "generic-all". >> >> -- Jon >> >> >> On 2/26/18 11:47 AM, Igor Ignatyev wrote: >>> adding build-dev alias >>> >>> -- Igor >>> >>>> On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova >>>> wrote: >>>> >>>> Hi all, >>>> >>>> ProblemList.txt files used by makefiles for jtreg testing allow to >>>> specify list of tests to be excluded >>>> from execution on all or specific platforms. However to test such >>>> features like Graal we want to be able >>>> to specify list of failed tests which fail in particular JVM mode >>>> only. >>>> Please review this change which adds support of extra problem list >>>> and introduces 2 Graal specific problem list files. >>>> - test/hotspot/jtreg/ProblemList-graal.txt >>>> - test/jdk/ProblemList-graal.txt >>>> >>>> >>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8197453 >>>> ? webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/ >>>> testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS. >>>> ????????? testing in Graal mode with >>>> EXTRA_PROBLEM_LISTS=ProblemList-graal.txt >>>> >>>> thanks, >>>> -katya >>>> >>>> p.s. >>>> Igor Ignatyev volunteered to sponsor this change. >> > From brian.burkhalter at oracle.com Thu Mar 1 20:06:27 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Mar 2018 12:06:27 -0800 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> Message-ID: <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> On Mar 1, 2018, at 11:52 AM, Alan Bateman wrote: > The rename of Launcher.c looks a bit strange, the original name looks better to me. The C source file beginning with ?lib? is a requirement of the jtreg native test build. > I see it doesn't have a copyright header so we should fix that. For the README then you can split the jtreg line to make it easier to read. Will fix those. > Otherwise looks good to me and happy to see these checked-in .so files going away. Thanks, Brian From Alan.Bateman at oracle.com Thu Mar 1 20:17:43 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Mar 2018 20:17:43 +0000 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> Message-ID: On 01/03/2018 20:06, Brian Burkhalter wrote: > On Mar 1, 2018, at 11:52 AM, Alan Bateman > wrote: > >> The rename of Launcher.c looks a bit strange, the original name looks >> better to me. > > The C source file beginning with ?lib? is a requirement of the jtreg > native test build. Okay, we might have to live with it for now but hopefully it can be fixed to be able to use sensible source file names in the future. -Alan From brian.burkhalter at oracle.com Thu Mar 1 20:21:37 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Mar 2018 12:21:37 -0800 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> Message-ID: On Mar 1, 2018, at 12:17 PM, Alan Bateman wrote: >> The C source file beginning with ?lib? is a requirement of the jtreg native test build. > Okay, we might have to live with it for now but hopefully it can be fixed to be able to use sensible source file names in the future. Webrev updated in place: http://cr.openjdk.java.net/~bpb/8198834/webrev.00/ Thanks, Brian From Alan.Bateman at oracle.com Thu Mar 1 20:30:38 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Mar 2018 20:30:38 +0000 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> Message-ID: <6f0ba44c-0f32-4554-a8ae-39b43ba3b81d@oracle.com> On 01/03/2018 20:21, Brian Burkhalter wrote: > On Mar 1, 2018, at 12:17 PM, Alan Bateman > wrote: > >>> The C source file beginning with ?lib? is a requirement of the jtreg >>> native test build. >> Okay, we might have to live with it for now but hopefully it can be >> fixed to be able to use sensible source file names in the future. > > Webrev updated in place: > > http://cr.openjdk.java.net/~bpb/8198834/webrev.00/ > > Thanks for the update, I think it looks okay. -Alan From erik.joelsson at oracle.com Thu Mar 1 21:59:52 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 13:59:52 -0800 Subject: jdk10 bootcycle build linux failing In-Reply-To: <934c9aa4-35bc-6975-338b-65318923a389@redhat.com> References: <934c9aa4-35bc-6975-338b-65318923a389@redhat.com> Message-ID: Hello Michal, The --with-memory-size option is only used to help configure pick a more reasonable concurrency level for make. If your machine still gets overwhelmed, I would recommend manually turning down concurrency until you get it to work, using "make JOBS=X". You can check the end of the configure output for how many concurrent jobs configure set for you and work down from there. /Erik On 2018-03-01 03:36, Michal Vala wrote: > Hi, > > I have an issue with bootcycle build. First run with external boot jdk > is ok, but bootcycle phase always fails. I'm building on > fedora27(local) and rhel7(VM). In case of local, build consume too > much memory and kill my OS. I've tried to set `with-memory-size` but > it seems like it accepts this value just for first build, but not for > bootcycle. I'm building with: > > $ bash ./configure --disable-warnings-as-errors > --with-boot-jdk=/home/tester/jdk-9.0.4 > $ make bootcycle-images > > I suspect that build eats too much memory and OS kills some process, > but I'm lack of knowledge here. Anyone else meeting similar issue? > > end of build log inlined here. I can provide more, but I was not able > to find any useful log output: > > collect2: error: ld terminated with signal 9 [Killed] > gmake[5]: *** > [/home/tester/openjdk/build/linux-x86_64-normal-server-release/bootcycle-build/hotspot/variant-server/libjvm/gtest/libjvm.so] > Error 1 > gmake[5]: *** Deleting file > `/home/tester/openjdk/build/linux-x86_64-normal-server-release/bootcycle-build/hotspot/variant-server/libjvm/gtest/libjvm.so' > gmake[5]: *** Waiting for unfinished jobs.... > gmake[4]: *** [hotspot-server-libs] Error 1 > > ERROR: Build failed for target 'product-images' in configuration > 'linux-x86_64-normal-server-release' (exit code 2) > gmake[4]: warning: -jN forced in submake: disabling jobserver mode. > Stopping sjavac server > > === Output from failing command(s) repeated here === > * For target > hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: > collect2: error: ld terminated with signal 9 [Killed] > > * All command lines available in > /home/tester/openjdk/build/linux-x86_64-normal-server-release/bootcycle-build/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. > > gmake[3]: *** [main] Error 1 > gmake[2]: *** [bootcycle-images] Error 2 > > ERROR: Build failed for target 'bootcycle-images' in configuration > 'linux-x86_64-normal-server-release' (exit code 2) > > 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: *** [bootcycle-images] Error 2 > From erik.joelsson at oracle.com Thu Mar 1 22:07:27 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 14:07:27 -0800 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: <6f0ba44c-0f32-4554-a8ae-39b43ba3b81d@oracle.com> References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> <6f0ba44c-0f32-4554-a8ae-39b43ba3b81d@oracle.com> Message-ID: <46ed842f-0d5f-6f9f-63ac-d7b2a54e9f4b@oracle.com> These native test libs all need to live in the same global namespace, basically the same java.library.path directory. In this context, "libLauncher" doesn't look very unique and descriptive given that it originates from java/nio/channels/spi/SelectorProvider/inheritedChannel. Could we change it to something more descriptive in a global perspective? Otherwise the build changes look good. /Erik On 2018-03-01 12:30, Alan Bateman wrote: > > > On 01/03/2018 20:21, Brian Burkhalter wrote: >> On Mar 1, 2018, at 12:17 PM, Alan Bateman > > wrote: >> >>>> The C source file beginning with ?lib? is a requirement of the >>>> jtreg native test build. >>> Okay, we might have to live with it for now but hopefully it can be >>> fixed to be able to use sensible source file names in the future. >> >> Webrev updated in place: >> >> http://cr.openjdk.java.net/~bpb/8198834/webrev.00/ >> >> > Thanks for the update, I think it looks okay. > > -Alan From brian.burkhalter at oracle.com Thu Mar 1 22:09:30 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Mar 2018 14:09:30 -0800 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: <46ed842f-0d5f-6f9f-63ac-d7b2a54e9f4b@oracle.com> References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> <6f0ba44c-0f32-4554-a8ae-39b43ba3b81d@oracle.com> <46ed842f-0d5f-6f9f-63ac-d7b2a54e9f4b@oracle.com> Message-ID: HI Erik, You caught me just shy of checking this in. :-) I can change it to something else like ?libInheritedChannelLauncher? or ?libInheritedChannel.? Thanks, Brian On Mar 1, 2018, at 2:07 PM, Erik Joelsson wrote: > These native test libs all need to live in the same global namespace, basically the same java.library.path directory. In this context, "libLauncher" doesn't look very unique and descriptive given that it originates from java/nio/channels/spi/SelectorProvider/inheritedChannel. Could we change it to something more descriptive in a global perspective? > > Otherwise the build changes look good. From erik.joelsson at oracle.com Thu Mar 1 22:17:15 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 14:17:15 -0800 Subject: RFR: JDK-8198859 Use elfedit to silence linker warnings on solaris In-Reply-To: <9ee6427c-892b-bcb2-e1c4-a819f36e5ae0@oracle.com> References: <9ee6427c-892b-bcb2-e1c4-a819f36e5ae0@oracle.com> Message-ID: <6ef49d4a-748d-a466-0e12-b3dbb5119d7b@oracle.com> Hello Magnus, This is a nice fix! I would prefer if the shell expression wasn't executed on every re-make. In this case it can easily be fixed by changing := to =. There is only one use of DTRACE_ELFEDIT_COMMANDS so it will only be evaluated once, and since it's in a recipe line, it will only get evaluated if that recipe is run. For better styling, perhaps it should be renamed with camel humps to make it more apparent that it's a macro. Stylewise, I would also argue that the indentation on 149 should be 4 spaces. One could say foreach qualifies as a logic indent, but I would say this is a broken up one liner. If foreach had started on a new line, then 2 space would have been ok, and in that case I would also have liked the closing brace on a new line. /Erik On 2018-03-01 02:01, Magnus Ihse Bursie wrote: > Solaris builds have always produced a lot of warnings when linking, > like this: > > ld: fatal: symbol '__JvmOffsets' has differing types: > ??? (file > /export/home/magnusi/hg/sandbox-cflags/build/solaris-sparcv9/hotspot/variant-server/libjvm/objs/JvmOffsets.o > type=OBJT; file > /export/home/magnusi/hg/sandbox-cflags/build/solaris-sparcv9/hotspot/variant-server/libjvm/objs/dtrace_jhelper.o > type=FUNC); > > This is due to an unresolved bug in dtrace. This bug has been reported > on the dtrace team in 2014, but no solution have been coming forth. > :-( However, I just discovered that we can actually use elfedit to fix > the type of the fields that the linker is complaining about on > $(DTRACE_JHELPER_OBJ). > > That will make the linker quiet. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198859 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198859-dtrace-warnings-workaround/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Thu Mar 1 22:50:03 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 14:50:03 -0800 Subject: RFR: JDK-8198862 Stop doing funky compilation stuff for dtrace In-Reply-To: References: Message-ID: <6c39d7a4-607f-5f9b-d8e6-6e07f64cc670@oracle.com> Hello, I don't think you can remove the extra ( ) around the preprocessor commands. I added those to avoid race conditions in JDK-8158629. My conclusion then was that any command that redirected stdout needed to be wrapped in (). Otherwise this looks ok. /Erik On 2018-02-28 16:48, Magnus Ihse Bursie wrote: > We're doing a lot of weird compilation stuff for dtrace. With this > patch, most of the weirdness is removed. The remaining calls to $(CC) > -E has been changed to $(CPP) to clarify that we do not compile, we > just use the precompiler. > > One of the changes I made was to actually split up the last and final > dtrace call into a separate preprocessing step. However, this uses the > solaris studio preprocessor instead of the ancient system > preprocessor, which has changed behavior. A string like (&``_var) is > now expanded to (& ` ` _var), which is not accepted by dtrace. :-( I > have worked around this by adding the preprocessed output, without the > spaces, in two places. If anyone wants to dig deeper into dtrace > script file syntax, or C preprocessor magic, to avoid this, let me > know... (I'll just state that the "obvious" solution of sending -Xs to > the preprocessor to get old-style behavior does not work: this just > makes the solaris studio preprocessor call the ancient preprocessor in > turn, and we've gained nothing...) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198862 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Thu Mar 1 22:50:56 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 14:50:56 -0800 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> <6f0ba44c-0f32-4554-a8ae-39b43ba3b81d@oracle.com> <46ed842f-0d5f-6f9f-63ac-d7b2a54e9f4b@oracle.com> Message-ID: <6eab8565-cebe-da7b-e2cb-5a9b7a6a7493@oracle.com> Either works for me. Thanks! /Erik On 2018-03-01 14:09, Brian Burkhalter wrote: > HI Erik, > > You caught me just shy of checking this in. :-) > > I can change it to something else like ?libInheritedChannelLauncher? > or ?libInheritedChannel.? > > Thanks, > > Brian > > On Mar 1, 2018, at 2:07 PM, Erik Joelsson > wrote: > >> These native test libs all need to live in the same global namespace, >> basically the same java.library.path directory. In this context, >> "libLauncher" doesn't look very unique and descriptive given that it >> originates from >> java/nio/channels/spi/SelectorProvider/inheritedChannel. Could we >> change it to something more descriptive in a global perspective? >> >> Otherwise the build changes look good. > From brian.burkhalter at oracle.com Thu Mar 1 22:53:01 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Mar 2018 14:53:01 -0800 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: <6eab8565-cebe-da7b-e2cb-5a9b7a6a7493@oracle.com> References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> <6f0ba44c-0f32-4554-a8ae-39b43ba3b81d@oracle.com> <46ed842f-0d5f-6f9f-63ac-d7b2a54e9f4b@oracle.com> <6eab8565-cebe-da7b-e2cb-5a9b7a6a7493@oracle.com> Message-ID: <43952D6C-5039-46CF-BE5A-D8203C157191@oracle.com> I think shorter is better: http://cr.openjdk.java.net/~bpb/8198834/webrev.01/ I?ll hold off pushing until Alan comments again. Thanks, Brian On Mar 1, 2018, at 2:50 PM, Erik Joelsson wrote: > Either works for me. Thanks! > > /Erik > > > On 2018-03-01 14:09, Brian Burkhalter wrote: >> HI Erik, >> >> You caught me just shy of checking this in. :-) >> >> I can change it to something else like ?libInheritedChannelLauncher? or ?libInheritedChannel.? From erik.joelsson at oracle.com Thu Mar 1 22:57:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 14:57:57 -0800 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: <43952D6C-5039-46CF-BE5A-D8203C157191@oracle.com> References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> <6f0ba44c-0f32-4554-a8ae-39b43ba3b81d@oracle.com> <46ed842f-0d5f-6f9f-63ac-d7b2a54e9f4b@oracle.com> <6eab8565-cebe-da7b-e2cb-5a9b7a6a7493@oracle.com> <43952D6C-5039-46CF-BE5A-D8203C157191@oracle.com> Message-ID: <821bd89d-f0f1-83a5-faeb-354810557a52@oracle.com> Note that you also need to update the declarations in the makefile. /Erik On 2018-03-01 14:53, Brian Burkhalter wrote: > I think shorter is better: > > http://cr.openjdk.java.net/~bpb/8198834/webrev.01/ > > > I?ll hold off pushing until Alan comments again. > > Thanks, > > Brian > > On Mar 1, 2018, at 2:50 PM, Erik Joelsson > wrote: > >> Either works for me. Thanks! >> >> /Erik >> >> >> On 2018-03-01 14:09, Brian Burkhalter wrote: >>> HI Erik, >>> >>> You caught me just shy of checking this in. :-) >>> >>> I can change it to something else like ?libInheritedChannelLauncher? >>> or ?libInheritedChannel.? > From erik.joelsson at oracle.com Thu Mar 1 23:02:33 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 15:02:33 -0800 Subject: RFR: JDK-8198844 Clean up GensrcX11Wrappers In-Reply-To: References: Message-ID: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com> Hello, In xlibtypes.txt comment, should it be sizes-64.txt? Generating both 32 and 64 seems a bit outdated at this point. Surely this is a remnant of bundling 64 and 32 bit together on Solaris in the past? Perhaps someone in 2d can answer this? Would be nice to be able to clean up that part as well if possible. Otherwise good. /Erik On 2018-02-28 12:12, Magnus Ihse Bursie wrote: > My hunt on technical debt continues. This time my aim has been on the > sorry mess known as GensrcX11Wrappers. > > I've disentangled it into two functions, one simple gensrc part that > is actually run during the build, and which involves just a simple > java tool and some pre-calculated data files, and a separate step for > updating those pre-calculated data files. This step is now run using > "make update-x11wrappers". It involves compiling a native binary, and > running it on the target platform, so just as before, this assumes > that you are not cross-compiling. > > I'm not sure what role the "verification" step we had before ever > played. For all the years we've been "verifying" this, we've detected > no differences. In fact, as far as I understand, what we *really* > would need to verify against, is the X11 libraries on the runtime > system, i.e. where the users executes the JRE. But then again, we can > assume that this matches, just as anyone compiling with header files > on one place can assume that they can use the libraries elsewhere. The > only reason, as I see it, to keep the generation in the makefiles at > all, is to document how the files were generated, and to be ready for > the need to update the files if the list of datatypes in xlibtypes.txt > changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198844 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Thu Mar 1 23:11:19 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 15:11:19 -0800 Subject: RFR: JDK-8198751 Refactor SetupNativeCompilation to take NAME and TYPE In-Reply-To: References: Message-ID: Looks good. /Erik On 2018-02-27 03:15, Magnus Ihse Bursie wrote: > Currently, SetupNativeCompilation takes as "main" argument either > LIBRARY := $name, PROGRAM := $name or STATIC_LIBRARY := $name. > > This confounds two distinct concepts: the name of the generated > binary, and the type of binary to create. Instead, we should have a > NAME argument and a TYPE argument. > > I also took the liberty of updating the code to more modern standards > wrt whitespace, and fixed the "Yoda style" if conditions. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198751 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198751-fix-NativeCompilation-NAME-and-TYPE/webrev.01 > > /Magnus > From brian.burkhalter at oracle.com Thu Mar 1 23:44:45 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Mar 2018 15:44:45 -0800 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: <821bd89d-f0f1-83a5-faeb-354810557a52@oracle.com> References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> <6f0ba44c-0f32-4554-a8ae-39b43ba3b81d@oracle.com> <46ed842f-0d5f-6f9f-63ac-d7b2a54e9f4b@oracle.com> <6eab8565-cebe-da7b-e2cb-5a9b7a6a7493@oracle.com> <43952D6C-5039-46CF-BE5A-D8203C157191@oracle.com> <821bd89d-f0f1-83a5-faeb-354810557a52@oracle.com> Message-ID: D?oh! Thanks, Brian On Mar 1, 2018, at 2:57 PM, Erik Joelsson wrote: > Note that you also need to update the declarations in the makefile. From erik.joelsson at oracle.com Thu Mar 1 23:46:09 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Mar 2018 15:46:09 -0800 Subject: RFR: JDK-8198724 Refactor FLAGS handling in configure In-Reply-To: <92e6dbcd-dd59-7902-0bf9-fcae26c72346@oracle.com> References: <92e6dbcd-dd59-7902-0bf9-fcae26c72346@oracle.com> Message-ID: Hello Magnus, Nice to finally see this posted! Overall very nice improvement. On 2018-02-26 15:40, Magnus Ihse Bursie wrote: > The current way we're handling FLAGS (CFLAGS/CXXFLAGS, LDFLAGS, etc) > is laden with technical debt. It's a sorry mess, hard to do anything > constructive about. > > This is the first step towards a better solution. The main goal is to > have a set of more specific flags, more like how the SYSROOT flags > work today, that can be individually included, instead of a huge > CFLAGS_JDKLIB. > > To make such a change manageable, this first step will (almost) only > refactor the autoconf code, but will output the same flags in the > spec.gmk. > > To minimize special cases, I have accepted the following differences: > * On linux/gcc, we will get a -m, e.g. -m64 always (as on > aix/solaris). > * On macosx/clang, we will get a -m, e.g. -m64 always (as on > aix/solaris). > * On macosx/clang, we will now "hardcode" the max/min version number > without dots. I would advocate a simple bash replace to remove the dots, like this: MACOSX_VERSION_MIN_NODOTS=${MACOSX_VERSION_MIN//\./} > * On macosx/clang, the JVM_CFLAGS for the build toolchain will now > also get an -fPIC (this was mysteriously missing before). > * On windows/microsoft, the build toolchain will now get -nologo added > as well, and also -homeparams for debug builds. > * On solaris/solstudio, the JDKEXE flags will now include -errfmt, and > CFLAGS_JDKEXE will include -errtags=yes. The duplication of > -errtags=yes in CXXFLAGS_JDKLIB is removed. > * On solaris/solstudio, we now always use -KPIC as pic flag. > (Previously, we used -xcode=pic32 on sparc, but this is equivalent to > -KPIC, so there's no reason for a special case.) > * On solaris/solstudio, we now use e.g. "-Wc,-Qrm-s" instead of > "-Qoption cg -Qrm-s" for C++ as well as for C code. The two formats > are equivalent (for passing options to a certain compilation phase), > and there was no reason to use different ones for C and C++. > > And for clarity, I have also renamed some exported flags to clearly > show that they are consumed by LIBJSIG and ADLC. I have also renamed > "/STACK" on the Microsoft linker to "-stack", to match how we write > options elsewhere. > > I believe none of these should have any real effect, but if anything, > they could probably be considered bug fixes. > > I have considered whitespace and ordering differences as irrelevant. > In some cases ordering may be relevant, hopefully the COMPARE_BUILD run will uncover if that's the case. If those are ok, then I'm basically happy with this transformation. > I have manually verified that the generated spec.gmk and > buildjdk-spec.gmk matches this (no changes apart from the one listed > above) for linux/x64/gcc, solaris/sparcv9/solstudio, > windows/x64/microsoft and macosx/x64/clang, for release and fastdebug. > > I am also currently running a test job using the COMPARE_BUILD > functionality on our internal build system. > > I would appreciate if comments are more in the form of "think of this > for subsequent updates to the flag handling" rather than requests to > change this patch, at least for requests that are just not small > fixes. (I've been juggling this for a while, trying to get it right...) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198724 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198724-refactor-flags-step-1/webrev.01 > Comments on things I saw, not necessarily needing fixes now: In flags.m4, MACHINE_FLAG and COMPILER_TARGET_BITS_FLAG are redundant without comment. flags-cflags.m4, FLAGS_SETUP_SHARED_LIBS, comments out of date/irrelevant like: # Default works for linux, might work on other platforms as well. Solaris -errtags is not needed in CFLAGS_WARNINGS_ARE_ERRORS. Given that TOOLCHAIN_MINIMUM_VERSION_gcc="4.7", perhaps we can remove the check for -Wno-X on gcc 4.4. /Erik > /Magnus > From lance.andersen at oracle.com Fri Mar 2 00:41:30 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Mar 2018 19:41:30 -0500 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: <945D4802-2632-4082-8970-2E983320C55A@oracle.com> References: <0EC6FFD0-31EA-4D24-B82D-C4D5DCAB8E65@oracle.com> <144F8EF0-0020-4577-8F9B-3FC86AF8ED4A@oracle.com> <945D4802-2632-4082-8970-2E983320C55A@oracle.com> Message-ID: <1E0E8829-52B1-4B86-9DFD-95637C8D9FAA@oracle.com> While running the JDK regression tests, I found a test that needed to be updated, test/langtools/tools/jdeps/modules/DotFileTest.java, due to the update to the java.sql module The updated webrev is at http://cr.openjdk.java.net/~lancea/8197533/webrev.03/ Best Lance > On Mar 1, 2018, at 12:37 PM, Paul Sandoz wrote: > > +1 > >> On Mar 1, 2018, at 8:59 AM, Lance Andersen > wrote: >>> >>> +1, i second Joe?s request to update package-info.java while we are opportunistically cleaning this area up. >> >> Per your and Joe?s request, please see cr.openjdk.java.net/~lancea/8197533/webrev.02 which has your suggested update to use package-info.java >> >> Thank you both >> >> Best >> Lance > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From paul.sandoz at oracle.com Fri Mar 2 00:44:33 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Mar 2018 16:44:33 -0800 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: <1E0E8829-52B1-4B86-9DFD-95637C8D9FAA@oracle.com> References: <0EC6FFD0-31EA-4D24-B82D-C4D5DCAB8E65@oracle.com> <144F8EF0-0020-4577-8F9B-3FC86AF8ED4A@oracle.com> <945D4802-2632-4082-8970-2E983320C55A@oracle.com> <1E0E8829-52B1-4B86-9DFD-95637C8D9FAA@oracle.com> Message-ID: > On Mar 1, 2018, at 4:41 PM, Lance Andersen wrote: > > While running the JDK regression tests, I found a test that needed to be updated, test/langtools/tools/jdeps/modules/DotFileTest.java, due to the update to the java.sql module > > The updated webrev is at http://cr.openjdk.java.net/~lancea/8197533/webrev.03/ > +1 Paul. From david.holmes at oracle.com Fri Mar 2 02:01:50 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Mar 2018 12:01:50 +1000 Subject: RFR: JDK-8198862 Stop doing funky compilation stuff for dtrace In-Reply-To: References: Message-ID: <6a865220-1f02-1df3-84ff-e8d786756a22@oracle.com> Hi Magnus, On 1/03/2018 10:48 AM, Magnus Ihse Bursie wrote: > We're doing a lot of weird compilation stuff for dtrace. With this > patch, most of the weirdness is removed. The remaining calls to $(CC) -E > has been changed to $(CPP) to clarify that we do not compile, we just > use the precompiler. > > One of the changes I made was to actually split up the last and final > dtrace call into a separate preprocessing step. However, this uses the > solaris studio preprocessor instead of the ancient system preprocessor, > which has changed behavior. A string like (&``_var) is now expanded to > (& ` ` _var), which is not accepted by dtrace. :-( I have worked around > this by adding the preprocessed output, without the spaces, in two > places. If anyone wants to dig deeper into dtrace script file syntax, or > C preprocessor magic, to avoid this, let me know... (I'll just state > that the "obvious" solution of sending -Xs to the preprocessor to get > old-style behavior does not work: this just makes the solaris studio > preprocessor call the ancient preprocessor in turn, and we've gained > nothing...) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198862 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.01 Why did you rename generateJvmOffsetsMain.c to generateJvmOffsetsMain.cpp? It isn't a C++ program, it's just a C program. I agree the logic is quite confusing. I think this build logic was victim of the CPP_FLAGS (meaning C preprocessor) to CXX_FLAGS (meaning C++ flags) renaming. But this is a trivial C program and should require trivial C compiler flags. I don't see it should be being built with all the JVM_CFLAGS. The latter may be harmless but it seems wrong to lump this in together with other things. make/hotspot/lib/CompileDtracePreJvm.gmk ! # Since we cannot generated JvmOffsets.cpp as part of the gensrc step, Comment doesn't read right. Thanks, David > > /Magnus > From Alan.Bateman at oracle.com Fri Mar 2 07:52:20 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Mar 2018 07:52:20 +0000 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: <43952D6C-5039-46CF-BE5A-D8203C157191@oracle.com> References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> <6f0ba44c-0f32-4554-a8ae-39b43ba3b81d@oracle.com> <46ed842f-0d5f-6f9f-63ac-d7b2a54e9f4b@oracle.com> <6eab8565-cebe-da7b-e2cb-5a9b7a6a7493@oracle.com> <43952D6C-5039-46CF-BE5A-D8203C157191@oracle.com> Message-ID: On 01/03/2018 22:53, Brian Burkhalter wrote: > I think shorter is better: > > http://cr.openjdk.java.net/~bpb/8198834/webrev.01/ > > > I?ll hold off pushing until Alan comments again. > libInheritedLauncher.c looks okay (although still very strange to have the "lib" prefix but that is not your doing). I assume the copyright range should be 2003, 2018 (to match Launcher.java) as this is not a new file in 2018. So I think you good to go and it's great to have the .so files removed from the repos. -Alan From Alan.Bateman at oracle.com Fri Mar 2 09:13:40 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Mar 2018 09:13:40 +0000 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: <98DD56F9-A3F0-4D1D-BCCA-C72220225074@oracle.com> References: <98DD56F9-A3F0-4D1D-BCCA-C72220225074@oracle.com> Message-ID: On 28/02/2018 19:54, Lance Andersen wrote: > : >> >> Is there any XA text from the original JTA spec that should be added >> to the module description as part of this? Another way to ask this is >> whether the JTA 1.3 drops any text dealing with the XA part. > Still waiting to see what changes are made to the PDF spec, that is > still needing to be completed. So I think for now, we go with what we > have and can circle back if needed. > Thanks. I checked the latest webrev (moving the package description to package-info.java and the langtools dot test) and it all looks good to me. -Alan From magnus.ihse.bursie at oracle.com Fri Mar 2 09:54:01 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 2 Mar 2018 10:54:01 +0100 Subject: RFR: JDK-8198724 Refactor FLAGS handling in configure In-Reply-To: References: <92e6dbcd-dd59-7902-0bf9-fcae26c72346@oracle.com> Message-ID: <32ec4c66-76e2-6226-28d2-43a859a1a551@oracle.com> On 2018-03-02 00:46, Erik Joelsson wrote: > Hello Magnus, > > Nice to finally see this posted! Overall very nice improvement. Thank you. > I would advocate a simple bash replace to remove the dots, like this: > MACOSX_VERSION_MIN_NODOTS=${MACOSX_VERSION_MIN//\./} Ok, I updated this. I see no need to post another review for this. >> * On macosx/clang, the JVM_CFLAGS for the build toolchain will now >> also get an -fPIC (this was mysteriously missing before). >> * On windows/microsoft, the build toolchain will now get -nologo >> added as well, and also -homeparams for debug builds. >> * On solaris/solstudio, the JDKEXE flags will now include -errfmt, >> and CFLAGS_JDKEXE will include -errtags=yes. The duplication of >> -errtags=yes in CXXFLAGS_JDKLIB is removed. >> * On solaris/solstudio, we now always use -KPIC as pic flag. >> (Previously, we used -xcode=pic32 on sparc, but this is equivalent to >> -KPIC, so there's no reason for a special case.) >> * On solaris/solstudio, we now use e.g. "-Wc,-Qrm-s" instead of >> "-Qoption cg -Qrm-s" for C++ as well as for C code. The two formats >> are equivalent (for passing options to a certain compilation phase), >> and there was no reason to use different ones for C and C++. >> >> And for clarity, I have also renamed some exported flags to clearly >> show that they are consumed by LIBJSIG and ADLC. I have also renamed >> "/STACK" on the Microsoft linker to "-stack", to match how we write >> options elsewhere. >> >> I believe none of these should have any real effect, but if anything, >> they could probably be considered bug fixes. >> >> I have considered whitespace and ordering differences as irrelevant. >> > In some cases ordering may be relevant, hopefully the COMPARE_BUILD > run will uncover if that's the case. If those are ok, then I'm > basically happy with this transformation. COMPARE_BUILD runs on our internal mach5 system showed no discrepancies. (This was the reason I fixed the COMPARE_BUILD system for no-change builds.) I actually don't know of any cases where CFLAGS ordering is relevant. (LIBS is another issue) It's good to be aware of such issues, so please enlighten me. :-) I noticed one thing, though, was that a trivial sort of the flags before writing them to spec.gmk didn't work. I did this (and similarly on a patched baseline) to facilitate my comparison, but it was not compilable. The reason was that a few flags (actually, currently only on clang/macosx) had arguments that was space separated from the options. For most flags, we do not have this scenario, which I think is good. It makes it easier to see what is a "single" flag. >> I have manually verified that the generated spec.gmk and >> buildjdk-spec.gmk matches this (no changes apart from the one listed >> above) for linux/x64/gcc, solaris/sparcv9/solstudio, >> windows/x64/microsoft and macosx/x64/clang, for release and fastdebug. >> >> I am also currently running a test job using the COMPARE_BUILD >> functionality on our internal build system. >> >> I would appreciate if comments are more in the form of "think of this >> for subsequent updates to the flag handling" rather than requests to >> change this patch, at least for requests that are just not small >> fixes. (I've been juggling this for a while, trying to get it right...) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198724 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8198724-refactor-flags-step-1/webrev.01 >> > Comments on things I saw, not necessarily needing fixes now: > > In flags.m4, MACHINE_FLAG and COMPILER_TARGET_BITS_FLAG are redundant > without comment. Oh, how I wish this was true. :-( COMPILER_TARGET_BITS_FLAG is actually exported for use in (you guess!) GensrcX11Wrappers.gmk. (Guess why I was targeting that for cleanup :-)). When the GensrcX11Wrappers fix is in, I intend to clean up this. > > flags-cflags.m4, FLAGS_SETUP_SHARED_LIBS, comments out of > date/irrelevant like: > # Default works for linux, might work on other platforms as well. I'll go through those at a later date. For the moment, FLAGS_SETUP_SHARED_LIBS was "good enough" to be left alone. > Solaris -errtags is not needed in CFLAGS_WARNINGS_ARE_ERRORS. Yes. I'm currently working on a follow-up patch were I redesign the warnings handling, including -errtags. > Given that TOOLCHAIN_MINIMUM_VERSION_gcc="4.7", perhaps we can remove > the check for -Wno-X on gcc 4.4. Good find. It would be nice to get rid of it. In fact, I wonder if it is possible to raise the minimum gcc version to 4.8 for JDK11. That would help us get rid of even more gcc version checks for broken/bad behaviour in pre-4.8 gcc. As you can see, there's a lot of follow-up cleaning left to do. This refactoring was scary enough that I wanted to minimize the changes done in this first step. /Magnus > > /Erik > >> /Magnus >> > From magnus.ihse.bursie at oracle.com Fri Mar 2 11:00:12 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 2 Mar 2018 12:00:12 +0100 Subject: RFR: JDK-8198844 Clean up GensrcX11Wrappers In-Reply-To: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com> References: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com> Message-ID: On 2018-03-02 00:02, Erik Joelsson wrote: > Hello, > > In xlibtypes.txt comment, should it be sizes-64.txt? Yes, good catch. > > Generating both 32 and 64 seems a bit outdated at this point. Surely > this is a remnant of bundling 64 and 32 bit together on Solaris in the > past? Perhaps someone in 2d can answer this? Would be nice to be able > to clean up that part as well if possible. Yes, you are right. We should clean up that as well. I was just too conservative. I've now actually checked what happens when you generate both 32 and 64 bit versions, and the result is that instead of code like: ??? public static int getSize() { return 96; } we get code like this: ??? public static int getSize() { return ((XlibWrapper.dataModel == 32)?(80):(96)); } Since we do no longer support multiple data models for the same build, this is just unnecessary. In fact, that leads to an even better cleanup, since we will always need just a single input file. I also wrapped the tool calls in ExecuteWithLog. Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 2 11:10:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 2 Mar 2018 12:10:08 +0100 Subject: RFR: JDK-8198862 Stop doing funky compilation stuff for dtrace In-Reply-To: <6a865220-1f02-1df3-84ff-e8d786756a22@oracle.com> References: <6a865220-1f02-1df3-84ff-e8d786756a22@oracle.com> Message-ID: <8c44d583-d001-3a4c-fc2d-40140f811f84@oracle.com> On 2018-03-02 03:01, David Holmes wrote: > Hi Magnus, > > On 1/03/2018 10:48 AM, Magnus Ihse Bursie wrote: >> We're doing a lot of weird compilation stuff for dtrace. With this >> patch, most of the weirdness is removed. The remaining calls to $(CC) >> -E has been changed to $(CPP) to clarify that we do not compile, we >> just use the precompiler. >> >> One of the changes I made was to actually split up the last and final >> dtrace call into a separate preprocessing step. However, this uses >> the solaris studio preprocessor instead of the ancient system >> preprocessor, which has changed behavior. A string like (&``_var) is >> now expanded to (& ` ` _var), which is not accepted by dtrace. :-( I >> have worked around this by adding the preprocessed output, without >> the spaces, in two places. If anyone wants to dig deeper into dtrace >> script file syntax, or C preprocessor magic, to avoid this, let me >> know... (I'll just state that the "obvious" solution of sending -Xs >> to the preprocessor to get old-style behavior does not work: this >> just makes the solaris studio preprocessor call the ancient >> preprocessor in turn, and we've gained nothing...) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198862 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.01 > > > Why did you rename generateJvmOffsetsMain.c to > generateJvmOffsetsMain.cpp? It isn't a C++ program, it's just a C > program. Yes, but so are generateJvmOffsets.cpp. :-& There was no point in mixing a .cpp and .c file for this trivial build tool helper. In fact, I don't even understand why they are two separate files -- if I get the blessings from someone in hotspot, I'll gladly just concatenate them into a single file. > I agree the logic is quite confusing. I think this build logic was > victim of the CPP_FLAGS (meaning C preprocessor) to CXX_FLAGS (meaning > C++ flags) renaming. But this is a trivial C program and should > require trivial C compiler flags. I don't see it should be being built > with all the JVM_CFLAGS. The latter may be harmless but it seems wrong > to lump this in together with other things. Actually, no. Or, maybe it was a victim of CPP_FLAGS/CXX_FLAGS confusion, too. But the JVM_CFLAGS *are* needed. Otherwise I'd removed them, trust me. And I would have moved the entire piece of code to gensrc, where it belongs. (This is just about compiling a build tool that will generate source code that should be later compiled, typical gensrc stuff). But, this file includes a lot of hotspot include files. And for that to work, we need the -I and -D flags from JVM_CFLAGS. We probably don't need any other parts of the JVM_CFLAGS, so in theory, we could probably split JVM_CFLAGS into a "defines and include paths" part, and a "rest" part. But I would not bet on it, suddenly you'd have some kind of option (-xc99?) that modifies the parsing of the include files... This is the general problem with all dtrace stuff, it needs to poke it's fingers deep down in the libjvm. :( > > make/hotspot/lib/CompileDtracePreJvm.gmk > > !???? # Since we cannot generated JvmOffsets.cpp as part of the gensrc > step, > > Comment doesn't read right. Typo, should be "generate". I'll fix. /Magnus > > Thanks, > David > >> >> /Magnus >> From magnus.ihse.bursie at oracle.com Fri Mar 2 12:20:04 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 2 Mar 2018 13:20:04 +0100 Subject: RFR: JDK-8198859 Use elfedit to silence linker warnings on solaris In-Reply-To: <6ef49d4a-748d-a466-0e12-b3dbb5119d7b@oracle.com> References: <9ee6427c-892b-bcb2-e1c4-a819f36e5ae0@oracle.com> <6ef49d4a-748d-a466-0e12-b3dbb5119d7b@oracle.com> Message-ID: <827910d9-c695-1e5f-c2b7-6b4dcf7a16e0@oracle.com> On 2018-03-01 23:17, Erik Joelsson wrote: > Hello Magnus, > > This is a nice fix! > > I would prefer if the shell expression wasn't executed on every > re-make. In this case it can easily be fixed by changing := to =. > There is only one use of DTRACE_ELFEDIT_COMMANDS so it will only be > evaluated once, and since it's in a recipe line, it will only get > evaluated if that recipe is run. For better styling, perhaps it should > be renamed with camel humps to make it more apparent that it's a macro. > > Stylewise, I would also argue that the indentation on 149 should be 4 > spaces. One could say foreach qualifies as a logic indent, but I would > say this is a broken up one liner. If foreach had started on a new > line, then 2 space would have been ok, and in that case I would also > have liked the closing brace on a new line. Erik I had already pushed the changeset after Tim's review. I will fold your suggested changes into the patch for JDK-8198862. /Magnus > > /Erik > > On 2018-03-01 02:01, Magnus Ihse Bursie wrote: >> Solaris builds have always produced a lot of warnings when linking, >> like this: >> >> ld: fatal: symbol '__JvmOffsets' has differing types: >> ??? (file >> /export/home/magnusi/hg/sandbox-cflags/build/solaris-sparcv9/hotspot/variant-server/libjvm/objs/JvmOffsets.o >> type=OBJT; file >> /export/home/magnusi/hg/sandbox-cflags/build/solaris-sparcv9/hotspot/variant-server/libjvm/objs/dtrace_jhelper.o >> type=FUNC); >> >> This is due to an unresolved bug in dtrace. This bug has been >> reported on the dtrace team in 2014, but no solution have been coming >> forth. :-( However, I just discovered that we can actually use >> elfedit to fix the type of the fields that the linker is complaining >> about on $(DTRACE_JHELPER_OBJ). >> >> That will make the linker quiet. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198859 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8198859-dtrace-warnings-workaround/webrev.01 >> >> /Magnus >> > From magnus.ihse.bursie at oracle.com Fri Mar 2 12:45:16 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 2 Mar 2018 13:45:16 +0100 Subject: RFR: JDK-8198862 Stop doing funky compilation stuff for dtrace In-Reply-To: <8c44d583-d001-3a4c-fc2d-40140f811f84@oracle.com> References: <6a865220-1f02-1df3-84ff-e8d786756a22@oracle.com> <8c44d583-d001-3a4c-fc2d-40140f811f84@oracle.com> Message-ID: <3d15bc14-e39f-288f-0ccc-77d3b95fc66c@oracle.com> On 2018-03-02 12:10, Magnus Ihse Bursie wrote: > On 2018-03-02 03:01, David Holmes wrote: >> Hi Magnus, >> >> On 1/03/2018 10:48 AM, Magnus Ihse Bursie wrote: >>> We're doing a lot of weird compilation stuff for dtrace. With this >>> patch, most of the weirdness is removed. The remaining calls to >>> $(CC) -E has been changed to $(CPP) to clarify that we do not >>> compile, we just use the precompiler. >>> >>> One of the changes I made was to actually split up the last and >>> final dtrace call into a separate preprocessing step. However, this >>> uses the solaris studio preprocessor instead of the ancient system >>> preprocessor, which has changed behavior. A string like (&``_var) is >>> now expanded to (& ` ` _var), which is not accepted by dtrace. :-( I >>> have worked around this by adding the preprocessed output, without >>> the spaces, in two places. If anyone wants to dig deeper into dtrace >>> script file syntax, or C preprocessor magic, to avoid this, let me >>> know... (I'll just state that the "obvious" solution of sending -Xs >>> to the preprocessor to get old-style behavior does not work: this >>> just makes the solaris studio preprocessor call the ancient >>> preprocessor in turn, and we've gained nothing...) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198862 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.01 >> >> >> >> Why did you rename generateJvmOffsetsMain.c to >> generateJvmOffsetsMain.cpp? It isn't a C++ program, it's just a C >> program. > Yes, but so are generateJvmOffsets.cpp. :-& There was no point in > mixing a .cpp and .c file for this trivial build tool helper. In fact, > I don't even understand why they are two separate files -- if I get > the blessings from someone in hotspot, I'll gladly just concatenate > them into a single file. Come to think about it, I don't care about the hotspot group's blessing. ;-) I just moved the main function into the generateJvmOffsets.cpp file. It was just silly having it as a separate file. > >> !???? # Since we cannot generated JvmOffsets.cpp as part of the >> gensrc step, >> >> Comment doesn't read right. > Typo, should be "generate". I'll fix. Updated. I also restored the extra ( ) in ExecuteWithLog with redirection, and added an additional ( ) for one case that was previously missing one. Finally I also added the changes to dtrace that Erik requested for JDK-8198859, but which was already pushed by that time. New webrev: http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.02 /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 2 12:48:20 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 2 Mar 2018 13:48:20 +0100 Subject: RFR: JDK-8198323 testing.md not updated for repository layout change Message-ID: <523f3391-5b45-280f-d6ad-083d94542c9d@oracle.com> In make/doc/testing.md, the descriptions of the TEST option for jtreg tests has not been updated to account for the repository layout change.? For example, "hotspot/test:hotspot_gc" should be "test/hotspot/jtreg:hotspot_gc". Bug: https://bugs.openjdk.java.net/browse/JDK-8198323 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198323-update-testing-documentation/webrev.01 /Magnus From erik.joelsson at oracle.com Fri Mar 2 15:18:44 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 2 Mar 2018 07:18:44 -0800 Subject: RFR: JDK-8198724 Refactor FLAGS handling in configure In-Reply-To: <32ec4c66-76e2-6226-28d2-43a859a1a551@oracle.com> References: <92e6dbcd-dd59-7902-0bf9-fcae26c72346@oracle.com> <32ec4c66-76e2-6226-28d2-43a859a1a551@oracle.com> Message-ID: <65246b3a-d629-8d0c-b361-75252f7194a3@oracle.com> On 2018-03-02 01:54, Magnus Ihse Bursie wrote: > > I actually don't know of any cases where CFLAGS ordering is relevant. > (LIBS is another issue) It's good to be aware of such issues, so > please enlighten me. :-) If you have a flag that enables a feature and the corresponding disabling flag of the same, like -Wfoo -Wno-foo, then the latter overrides the former. Change the order and you get the opposite behavior. -I directories are searched in order so if the same header name is found in multiple directories, you get differences. /Erik From erik.joelsson at oracle.com Fri Mar 2 15:23:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 2 Mar 2018 07:23:32 -0800 Subject: RFR: JDK-8198844 Clean up GensrcX11Wrappers In-Reply-To: References: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com> Message-ID: <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com> Adding 2d-dev in the hopes of getting some input from component team. Seems like they should be aware of us removing the support for multiple data models. Looks like you left a debug message at line 40 in GensrcX11Wrappers.gmk. /Erik On 2018-03-02 03:00, Magnus Ihse Bursie wrote: > On 2018-03-02 00:02, Erik Joelsson wrote: >> Hello, >> >> In xlibtypes.txt comment, should it be sizes-64.txt? > > Yes, good catch. > >> >> Generating both 32 and 64 seems a bit outdated at this point. Surely >> this is a remnant of bundling 64 and 32 bit together on Solaris in >> the past? Perhaps someone in 2d can answer this? Would be nice to be >> able to clean up that part as well if possible. > Yes, you are right. We should clean up that as well. I was just too > conservative. I've now actually checked what happens when you generate > both 32 and 64 bit versions, and the result is that instead of code like: > ??? public static int getSize() { return 96; } > we get code like this: > ??? public static int getSize() { return ((XlibWrapper.dataModel == > 32)?(80):(96)); } > > Since we do no longer support multiple data models for the same build, > this is just unnecessary. In fact, that leads to an even better > cleanup, since we will always need just a single input file. > > I also wrapped the tool calls in ExecuteWithLog. > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 > > > /Magnus > From erik.helin at oracle.com Fri Mar 2 15:24:39 2018 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 2 Mar 2018 16:24:39 +0100 Subject: RFR: JDK-8198323 testing.md not updated for repository layout change In-Reply-To: <523f3391-5b45-280f-d6ad-083d94542c9d@oracle.com> References: <523f3391-5b45-280f-d6ad-083d94542c9d@oracle.com> Message-ID: <1463a6e7-b212-11b5-a984-97850e746fcf@oracle.com> On 03/02/2018 01:48 PM, Magnus Ihse Bursie wrote: > In make/doc/testing.md, the descriptions of the TEST option for jtreg > tests has not been updated to account for the repository layout change. > For example, "hotspot/test:hotspot_gc" should be > "test/hotspot/jtreg:hotspot_gc". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198323 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198323-update-testing-documentation/webrev.01 +example, `:tier1` will expand to `jtreg:$(TOPDIR)/test/jdk:tier1 +jtreg:$(TOPDIR)/test/langtools:tier1 jtreg:$(TOPDIR)/test/nashorn:tier1 +jtreg:$(TOPDIR)/test/jaxp:tier1`. :tier1 will now actually include `jtreg:$(TOPDIR)/test/hotspot:tier1` as well since Christian's commit: http://hg.openjdk.java.net/jdk/jdk/rev/75f4ad82866c While you are at it, you might want to change all occurrences of VM_OTIONS to VM_OPTIONS :) Thanks for updating the documentation! Erik > /Magnus From erik.joelsson at oracle.com Fri Mar 2 15:29:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 2 Mar 2018 07:29:47 -0800 Subject: RFR: JDK-8198862 Stop doing funky compilation stuff for dtrace In-Reply-To: <3d15bc14-e39f-288f-0ccc-77d3b95fc66c@oracle.com> References: <6a865220-1f02-1df3-84ff-e8d786756a22@oracle.com> <8c44d583-d001-3a4c-fc2d-40140f811f84@oracle.com> <3d15bc14-e39f-288f-0ccc-77d3b95fc66c@oracle.com> Message-ID: This looks good to me. /Erik On 2018-03-02 04:45, Magnus Ihse Bursie wrote: > On 2018-03-02 12:10, Magnus Ihse Bursie wrote: >> On 2018-03-02 03:01, David Holmes wrote: >>> Hi Magnus, >>> >>> On 1/03/2018 10:48 AM, Magnus Ihse Bursie wrote: >>>> We're doing a lot of weird compilation stuff for dtrace. With this >>>> patch, most of the weirdness is removed. The remaining calls to >>>> $(CC) -E has been changed to $(CPP) to clarify that we do not >>>> compile, we just use the precompiler. >>>> >>>> One of the changes I made was to actually split up the last and >>>> final dtrace call into a separate preprocessing step. However, this >>>> uses the solaris studio preprocessor instead of the ancient system >>>> preprocessor, which has changed behavior. A string like (&``_var) >>>> is now expanded to (& ` ` _var), which is not accepted by dtrace. >>>> :-( I have worked around this by adding the preprocessed output, >>>> without the spaces, in two places. If anyone wants to dig deeper >>>> into dtrace script file syntax, or C preprocessor magic, to avoid >>>> this, let me know... (I'll just state that the "obvious" solution >>>> of sending -Xs to the preprocessor to get old-style behavior does >>>> not work: this just makes the solaris studio preprocessor call the >>>> ancient preprocessor in turn, and we've gained nothing...) >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198862 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.01 >>> >>> >>> >>> >>> Why did you rename generateJvmOffsetsMain.c to >>> generateJvmOffsetsMain.cpp? It isn't a C++ program, it's just a C >>> program. >> Yes, but so are generateJvmOffsets.cpp. :-& There was no point in >> mixing a .cpp and .c file for this trivial build tool helper. In >> fact, I don't even understand why they are two separate files -- if I >> get the blessings from someone in hotspot, I'll gladly just >> concatenate them into a single file. > Come to think about it, I don't care about the hotspot group's > blessing. ;-) I just moved the main function into the > generateJvmOffsets.cpp file. It was just silly having it as a separate > file. > >> >>> !???? # Since we cannot generated JvmOffsets.cpp as part of the >>> gensrc step, >>> >>> Comment doesn't read right. >> Typo, should be "generate". I'll fix. > > Updated. > > I also restored the extra ( ) in ExecuteWithLog with redirection, and > added an additional ( ) for one case that was previously missing one. > > Finally I also added the changes to dtrace that Erik requested for > JDK-8198859, but which was already pushed by that time. > > New webrev: > http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.02 > > > /Magnus > From tim.bell at oracle.com Fri Mar 2 15:38:05 2018 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 02 Mar 2018 07:38:05 -0800 Subject: RFR: JDK-8198862 Stop doing funky compilation stuff for dtrace In-Reply-To: References: <6a865220-1f02-1df3-84ff-e8d786756a22@oracle.com> <8c44d583-d001-3a4c-fc2d-40140f811f84@oracle.com> <3d15bc14-e39f-288f-0ccc-77d3b95fc66c@oracle.com> Message-ID: <5A996FDD.9080800@oracle.com> Looks good to me as well. Tim On 03/02/18 07:29, Erik Joelsson wrote: > This looks good to me. > > /Erik > > > On 2018-03-02 04:45, Magnus Ihse Bursie wrote: >> On 2018-03-02 12:10, Magnus Ihse Bursie wrote: >>> On 2018-03-02 03:01, David Holmes wrote: >>>> Hi Magnus, >>>> >>>> On 1/03/2018 10:48 AM, Magnus Ihse Bursie wrote: >>>>> We're doing a lot of weird compilation stuff for dtrace. With this >>>>> patch, most of the weirdness is removed. The remaining calls to >>>>> $(CC) -E has been changed to $(CPP) to clarify that we do not >>>>> compile, we just use the precompiler. >>>>> >>>>> One of the changes I made was to actually split up the last and >>>>> final dtrace call into a separate preprocessing step. However, this >>>>> uses the solaris studio preprocessor instead of the ancient system >>>>> preprocessor, which has changed behavior. A string like (&``_var) >>>>> is now expanded to (& ` ` _var), which is not accepted by dtrace. >>>>> :-( I have worked around this by adding the preprocessed output, >>>>> without the spaces, in two places. If anyone wants to dig deeper >>>>> into dtrace script file syntax, or C preprocessor magic, to avoid >>>>> this, let me know... (I'll just state that the "obvious" solution >>>>> of sending -Xs to the preprocessor to get old-style behavior does >>>>> not work: this just makes the solaris studio preprocessor call the >>>>> ancient preprocessor in turn, and we've gained nothing...) >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198862 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.01 >>>> >>>> >>>> >>>> >>>> >>>> Why did you rename generateJvmOffsetsMain.c to >>>> generateJvmOffsetsMain.cpp? It isn't a C++ program, it's just a C >>>> program. >>> Yes, but so are generateJvmOffsets.cpp. :-& There was no point in >>> mixing a .cpp and .c file for this trivial build tool helper. In >>> fact, I don't even understand why they are two separate files -- if I >>> get the blessings from someone in hotspot, I'll gladly just >>> concatenate them into a single file. >> Come to think about it, I don't care about the hotspot group's >> blessing. ;-) I just moved the main function into the >> generateJvmOffsets.cpp file. It was just silly having it as a separate >> file. >> >>> >>>> ! # Since we cannot generated JvmOffsets.cpp as part of the >>>> gensrc step, >>>> >>>> Comment doesn't read right. >>> Typo, should be "generate". I'll fix. >> >> Updated. >> >> I also restored the extra ( ) in ExecuteWithLog with redirection, and >> added an additional ( ) for one case that was previously missing one. >> >> Finally I also added the changes to dtrace that Erik requested for >> JDK-8198859, but which was already pushed by that time. >> >> New webrev: >> http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.02 >> >> >> /Magnus >> > From erik.joelsson at oracle.com Fri Mar 2 15:38:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 2 Mar 2018 07:38:32 -0800 Subject: RFR: JDK-8198323 testing.md not updated for repository layout change In-Reply-To: <523f3391-5b45-280f-d6ad-083d94542c9d@oracle.com> References: <523f3391-5b45-280f-d6ad-083d94542c9d@oracle.com> Message-ID: <2655d933-defb-a787-9adc-70ec2849c766@oracle.com> Hello, Nice fixes, some grammar notes: building.md: 872: provide -> provides testing.md: 57: JTReg test -> JTReg tests 68: tests roots -> test roots 77: "Here too can just `hotspot` be used as an alias for `hotspot/jtreg`" reads weird (and is missing punctuation), how about: "`hotspot` can be used as an alias for `hotspot/jtreg` here as well." /Erik On 2018-03-02 04:48, Magnus Ihse Bursie wrote: > In make/doc/testing.md, the descriptions of the TEST option for jtreg > tests has not been updated to account for the repository layout > change.? For example, "hotspot/test:hotspot_gc" should be > "test/hotspot/jtreg:hotspot_gc". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198323 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198323-update-testing-documentation/webrev.01 > > /Magnus From brian.burkhalter at oracle.com Fri Mar 2 15:58:46 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Mar 2018 07:58:46 -0800 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: References: <77B1450C-2BB8-4E6D-ACDC-5BA479A14845@oracle.com> <9fa16545-aedd-7602-939f-174910dc4bcd@oracle.com> <33D609D2-FFDC-4CB7-84D6-E53CF922E784@oracle.com> <6f0ba44c-0f32-4554-a8ae-39b43ba3b81d@oracle.com> <46ed842f-0d5f-6f9f-63ac-d7b2a54e9f4b@oracle.com> <6eab8565-cebe-da7b-e2cb-5a9b7a6a7493@oracle.com> <43952D6C-5039-46CF-BE5A-D8203C157191@oracle.com> Message-ID: On Mar 1, 2018, at 11:52 PM, Alan Bateman wrote: > I assume the copyright range should be 2003, 2018 (to match Launcher.java) as this is not a new file in 2018. Will update before pushing. > So I think you good to go and it's great to have the .so files removed from the repos. +1 Thanks, Brian From erik.joelsson at oracle.com Fri Mar 2 21:18:17 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 2 Mar 2018 13:18:17 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> Message-ID: <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> Hello, Here is a new version of this patch, reworked in several ways. It now supports gcc, clang and solstudio. It uses nm instead of objdump, which is more readily available in all our current build environments. The check now uses mangled symbol names for all toolchain types which makes things considerably faster. I also added a check for only finding symbols classified as undefined. Otherwise we get false positives in operator_new.o in debug builds. I left the objdump addition to the devkit in there because it's a good thing to have anyway for compare.sh. Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.02/ I have run this patch against current jdk/jdk and jdk/hs in Mach5. In jdk/jdk the build fails as expected on Solaris, Linux and Mac and in jdk/hs, where the fixes we are detecting are present, all builds succeeds. /Erik On 2018-02-23 05:27, Magnus Ihse Bursie wrote: > On 2018-02-22 20:41, Erik Joelsson wrote: >> >> >> On 2018-02-21 21:06, David Holmes wrote: >>> On 22/02/2018 4:07 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> >>>> On 2018-02-20 21:33, David Holmes wrote: >>>>> >>>>> a) how much time it adds to the build? >>>>> >>>> I have not done extensive testing, but on my Linux workstation with >>>> 32 hw threads, building just hotspot release build from a clean >>>> workspace increased maybe 1 or 2 seconds (at around 90s total), but >>>> the variance was around the same amount as that. >>>>> b) why this doesn't work for Solaris Studio? >>>>> >>>> I didn't put a lot of effort into trying to figure it out. The >>>> check used was provided by Kim Barrett, for Linux only. I figured >>>> it would be simple enough to get it to work on mac and succeeded >>>> there. It should certainly be possible to implement a similar check >>>> on Solaris, but is it worth the time to do it? Both development >>>> time and increased build time on one of the slower build platforms? >>> >>> Depends how concerned we are with detecting this problem in OS >>> specific source code? >>> >> I investigated this some more. I was able to do it successfully, but >> the build time cost is way too large here. The culprit is c++filt on >> Solaris which is incredibly costly, and the gnu version does not >> demangle Solaris Studio symbols. I don't think we should do this on >> Solaris. > I agree, it's not worth it. > > Not all programmer's mistakes are reasonable to catch in technical > traps. It we *should* spend time on getting automatic tool for keeping > code quality up (and, yes, I really do think we should), there's most > likely to be much better areas to spend that effort in, in making a > lot of prone-to-break scripts for catching a single kind of problem. > > /Magnus > >> >> We could grep for the mangled strings for the operators instead, >> which is super fast. Problem is just figuring out all the possible >> combinations. >> >> /Erik >>> To be honest I'm not sure this pulls its own weight regardless. >>> >>> David >>> >>>> /Erik >>>>> Thanks, >>>>> David >>>>> >>>>> On 21/02/2018 4:05 AM, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> This patch adds a build time check for uses of global operators >>>>>> new and delete in hotspot C++ code. The check is only run with >>>>>> toolchains GCC and Clang (Linux and Macos builds). I have also >>>>>> modified the Oracle devkit on Linux to add the necessary symlink >>>>>> so that objdump will get picked up by configure. >>>>>> >>>>>> This change is depending on several fixes removing such uses that >>>>>> are currently in jdk/hs so this change will need to be pushed >>>>>> there as well. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >>>>>> >>>>>> /Erik >>>>>> >>>> >> > From kim.barrett at oracle.com Fri Mar 2 23:35:50 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 2 Mar 2018 18:35:50 -0500 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> Message-ID: <0FD20661-94A1-409F-B2CD-DE1C9AFB2954@oracle.com> > On Mar 2, 2018, at 4:18 PM, Erik Joelsson wrote: > > Hello, > > Here is a new version of this patch, reworked in several ways. It now supports gcc, clang and solstudio. It uses nm instead of objdump, which is more readily available in all our current build environments. The check now uses mangled symbol names for all toolchain types which makes things considerably faster. I also added a check for only finding symbols classified as undefined. Otherwise we get false positives in operator_new.o in debug builds. > > I left the objdump addition to the devkit in there because it's a good thing to have anyway for compare.sh. > > Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.02/ > > I have run this patch against current jdk/jdk and jdk/hs in Mach5. In jdk/jdk the build fails as expected on Solaris, Linux and Mac and in jdk/hs, where the fixes we are detecting are present, all builds succeeds. > > /Erik This looks good, with the same caveat as Coleen that I?m not a build expert. Thanks, Erik. From martinrb at google.com Sat Mar 3 02:14:43 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 2 Mar 2018 18:14:43 -0800 Subject: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs In-Reply-To: References: <8879f698-c34e-8a8c-affa-9a01cba95934@oracle.com> Message-ID: On Thu, Mar 1, 2018 at 11:50 AM, Erik Joelsson wrote: > > On 2018-02-26 12:57, joe darcy wrote: > >> Hi Magnus, >> >> Looks okay for now, but longer term should the version be queried from >> the environment some way? >> >> The problem as I understand it is that the URL is dead until the docs > team creates it, which doesn't necessarily happen in sync with us bumping > the version number in the jdk/jdk repository. Perhaps that's ok early in > the release? If you take "always releasable" seriously, then there's no such thing as "ok early in the release". Why can't we always have up to date docs, and the directory the docs live in is derived from the jdk sources (or generated api docs) themselves? Seems like a small amount of release engineering. From david.holmes at oracle.com Sun Mar 4 23:22:11 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 5 Mar 2018 09:22:11 +1000 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> Message-ID: <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> Hi Erik, On 3/03/2018 7:18 AM, Erik Joelsson wrote: > Hello, > > Here is a new version of this patch, reworked in several ways. It now > supports gcc, clang and solstudio. It uses nm instead of objdump, which > is more readily available in all our current build environments. The > check now uses mangled symbol names for all toolchain types which makes > things considerably faster. I also added a check for only finding > symbols classified as undefined. Otherwise we get false positives in > operator_new.o in debug builds. Sounds great! Thanks for doing the additional work on this. > I left the objdump addition to the devkit in there because it's a good > thing to have anyway for compare.sh. > > Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.02/ In toolkit.m4: + case $TOOLCHAIN_TYPE in + gcc|clang|solstudio) BASIC_CHECK_TOOLS(OBJDUMP, [gobjdump objdump]) if test "x$OBJDUMP" != x; then # Only used for compare.sh; we can live without it. BASIC_FIXUP_EXECUTABLE # bails if argument is missing. BASIC_FIXUP_EXECUTABLE(OBJDUMP) fi + BASIC_FIXUP_EXECUTABLE(OBJDUMP) Isn't the if-clause redundant now that you unconditionally call BASIC_FIXUP_EXECUTABLE(OBJDUMP)? Thanks, David > I have run this patch against current jdk/jdk and jdk/hs in Mach5. In > jdk/jdk the build fails as expected on Solaris, Linux and Mac and in > jdk/hs, where the fixes we are detecting are present, all builds succeeds. > > /Erik > > > On 2018-02-23 05:27, Magnus Ihse Bursie wrote: >> On 2018-02-22 20:41, Erik Joelsson wrote: >>> >>> >>> On 2018-02-21 21:06, David Holmes wrote: >>>> On 22/02/2018 4:07 AM, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> >>>>> On 2018-02-20 21:33, David Holmes wrote: >>>>>> >>>>>> a) how much time it adds to the build? >>>>>> >>>>> I have not done extensive testing, but on my Linux workstation with >>>>> 32 hw threads, building just hotspot release build from a clean >>>>> workspace increased maybe 1 or 2 seconds (at around 90s total), but >>>>> the variance was around the same amount as that. >>>>>> b) why this doesn't work for Solaris Studio? >>>>>> >>>>> I didn't put a lot of effort into trying to figure it out. The >>>>> check used was provided by Kim Barrett, for Linux only. I figured >>>>> it would be simple enough to get it to work on mac and succeeded >>>>> there. It should certainly be possible to implement a similar check >>>>> on Solaris, but is it worth the time to do it? Both development >>>>> time and increased build time on one of the slower build platforms? >>>> >>>> Depends how concerned we are with detecting this problem in OS >>>> specific source code? >>>> >>> I investigated this some more. I was able to do it successfully, but >>> the build time cost is way too large here. The culprit is c++filt on >>> Solaris which is incredibly costly, and the gnu version does not >>> demangle Solaris Studio symbols. I don't think we should do this on >>> Solaris. >> I agree, it's not worth it. >> >> Not all programmer's mistakes are reasonable to catch in technical >> traps. It we *should* spend time on getting automatic tool for keeping >> code quality up (and, yes, I really do think we should), there's most >> likely to be much better areas to spend that effort in, in making a >> lot of prone-to-break scripts for catching a single kind of problem. >> >> /Magnus >> >>> >>> We could grep for the mangled strings for the operators instead, >>> which is super fast. Problem is just figuring out all the possible >>> combinations. >>> >>> /Erik >>>> To be honest I'm not sure this pulls its own weight regardless. >>>> >>>> David >>>> >>>>> /Erik >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 21/02/2018 4:05 AM, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> This patch adds a build time check for uses of global operators >>>>>>> new and delete in hotspot C++ code. The check is only run with >>>>>>> toolchains GCC and Clang (Linux and Macos builds). I have also >>>>>>> modified the Oracle devkit on Linux to add the necessary symlink >>>>>>> so that objdump will get picked up by configure. >>>>>>> >>>>>>> This change is depending on several fixes removing such uses that >>>>>>> are currently in jdk/hs so this change will need to be pushed >>>>>>> there as well. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >>>>>>> >>>>>>> /Erik >>>>>>> >>>>> >>> >> > From mvala at redhat.com Mon Mar 5 11:31:52 2018 From: mvala at redhat.com (Michal Vala) Date: Mon, 5 Mar 2018 12:31:52 +0100 Subject: jdk10 bootcycle build linux failing In-Reply-To: References: <934c9aa4-35bc-6975-338b-65318923a389@redhat.com> Message-ID: Hi Erik, I've played also with --with-num-cores. It seems like it has an effect only on first build, but no effect on bootcycle build (same as --with-memory-size). Is this behavior intended or is it a bug? Or am I doing something wrong? I haven't tried "make JOBS=x" yet. I guess it may solve the issue, but I would expect that --with-num-cores should cover this. Thanks On 03/01/2018 10:59 PM, Erik Joelsson wrote: > Hello Michal, > > The --with-memory-size option is only used to help configure pick a more > reasonable concurrency level for make. If your machine still gets overwhelmed, I > would recommend manually turning down concurrency until you get it to work, > using "make JOBS=X". You can check the end of the configure output for how many > concurrent jobs configure set for you and work down from there. > > /Erik > > > On 2018-03-01 03:36, Michal Vala wrote: >> Hi, >> >> I have an issue with bootcycle build. First run with external boot jdk is ok, >> but bootcycle phase always fails. I'm building on fedora27(local) and >> rhel7(VM). In case of local, build consume too much memory and kill my OS. >> I've tried to set `with-memory-size` but it seems like it accepts this value >> just for first build, but not for bootcycle. I'm building with: >> >> $ bash ./configure --disable-warnings-as-errors >> --with-boot-jdk=/home/tester/jdk-9.0.4 >> $ make bootcycle-images >> >> I suspect that build eats too much memory and OS kills some process, but I'm >> lack of knowledge here. Anyone else meeting similar issue? >> >> end of build log inlined here. I can provide more, but I was not able to find >> any useful log output: >> >> collect2: error: ld terminated with signal 9 [Killed] >> gmake[5]: *** >> [/home/tester/openjdk/build/linux-x86_64-normal-server-release/bootcycle-build/hotspot/variant-server/libjvm/gtest/libjvm.so] >> Error 1 >> gmake[5]: *** Deleting file >> `/home/tester/openjdk/build/linux-x86_64-normal-server-release/bootcycle-build/hotspot/variant-server/libjvm/gtest/libjvm.so' >> >> gmake[5]: *** Waiting for unfinished jobs.... >> gmake[4]: *** [hotspot-server-libs] Error 1 >> >> ERROR: Build failed for target 'product-images' in configuration >> 'linux-x86_64-normal-server-release' (exit code 2) >> gmake[4]: warning: -jN forced in submake: disabling jobserver mode. >> Stopping sjavac server >> >> === Output from failing command(s) repeated here === >> * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: >> collect2: error: ld terminated with signal 9 [Killed] >> >> * All command lines available in >> /home/tester/openjdk/build/linux-x86_64-normal-server-release/bootcycle-build/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. >> >> gmake[3]: *** [main] Error 1 >> gmake[2]: *** [bootcycle-images] Error 2 >> >> ERROR: Build failed for target 'bootcycle-images' in configuration >> 'linux-x86_64-normal-server-release' (exit code 2) >> >> 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: *** [bootcycle-images] Error 2 >> > -- Michal Vala OpenJDK QE Red Hat Czech From erik.joelsson at oracle.com Mon Mar 5 16:41:51 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Mar 2018 08:41:51 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> Message-ID: <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> Hello, On 2018-03-04 15:22, David Holmes wrote: > Hi Erik, > > On 3/03/2018 7:18 AM, Erik Joelsson wrote: >> Hello, >> >> Here is a new version of this patch, reworked in several ways. It now >> supports gcc, clang and solstudio. It uses nm instead of objdump, >> which is more readily available in all our current build >> environments. The check now uses mangled symbol names for all >> toolchain types which makes things considerably faster. I also added >> a check for only finding symbols classified as undefined. Otherwise >> we get false positives in operator_new.o in debug builds. > > Sounds great! Thanks for doing the additional work on this. > >> I left the objdump addition to the devkit in there because it's a >> good thing to have anyway for compare.sh. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.02/ > > In toolkit.m4: > > +?? case $TOOLCHAIN_TYPE in > +???? gcc|clang|solstudio) > ??????? BASIC_CHECK_TOOLS(OBJDUMP, [gobjdump objdump]) > ??????? if test "x$OBJDUMP" != x; then > ????????? # Only used for compare.sh; we can live without it. > BASIC_FIXUP_EXECUTABLE > ????????? # bails if argument is missing. > ????????? BASIC_FIXUP_EXECUTABLE(OBJDUMP) > ??????? fi > +?????? BASIC_FIXUP_EXECUTABLE(OBJDUMP) > > Isn't the if-clause redundant now that you unconditionally call > BASIC_FIXUP_EXECUTABLE(OBJDUMP)? > Yes, I seem to have accidentally left the second line there. My intention was to restore the conditional now that objdump is no longer used for this new check. Here is a new webrev with the second fixup call removed: http://cr.openjdk.java.net/~erikj/8198243/webrev.03/ /Erik > Thanks, > David > >> I have run this patch against current jdk/jdk and jdk/hs in Mach5. In >> jdk/jdk the build fails as expected on Solaris, Linux and Mac and in >> jdk/hs, where the fixes we are detecting are present, all builds >> succeeds. >> >> /Erik >> >> >> On 2018-02-23 05:27, Magnus Ihse Bursie wrote: >>> On 2018-02-22 20:41, Erik Joelsson wrote: >>>> >>>> >>>> On 2018-02-21 21:06, David Holmes wrote: >>>>> On 22/02/2018 4:07 AM, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> >>>>>> On 2018-02-20 21:33, David Holmes wrote: >>>>>>> >>>>>>> a) how much time it adds to the build? >>>>>>> >>>>>> I have not done extensive testing, but on my Linux workstation >>>>>> with 32 hw threads, building just hotspot release build from a >>>>>> clean workspace increased maybe 1 or 2 seconds (at around 90s >>>>>> total), but the variance was around the same amount as that. >>>>>>> b) why this doesn't work for Solaris Studio? >>>>>>> >>>>>> I didn't put a lot of effort into trying to figure it out. The >>>>>> check used was provided by Kim Barrett, for Linux only. I figured >>>>>> it would be simple enough to get it to work on mac and succeeded >>>>>> there. It should certainly be possible to implement a similar >>>>>> check on Solaris, but is it worth the time to do it? Both >>>>>> development time and increased build time on one of the slower >>>>>> build platforms? >>>>> >>>>> Depends how concerned we are with detecting this problem in OS >>>>> specific source code? >>>>> >>>> I investigated this some more. I was able to do it successfully, >>>> but the build time cost is way too large here. The culprit is >>>> c++filt on Solaris which is incredibly costly, and the gnu version >>>> does not demangle Solaris Studio symbols. I don't think we should >>>> do this on Solaris. >>> I agree, it's not worth it. >>> >>> Not all programmer's mistakes are reasonable to catch in technical >>> traps. It we *should* spend time on getting automatic tool for >>> keeping code quality up (and, yes, I really do think we should), >>> there's most likely to be much better areas to spend that effort in, >>> in making a lot of prone-to-break scripts for catching a single kind >>> of problem. >>> >>> /Magnus >>> >>>> >>>> We could grep for the mangled strings for the operators instead, >>>> which is super fast. Problem is just figuring out all the possible >>>> combinations. >>>> >>>> /Erik >>>>> To be honest I'm not sure this pulls its own weight regardless. >>>>> >>>>> David >>>>> >>>>>> /Erik >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 21/02/2018 4:05 AM, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> This patch adds a build time check for uses of global operators >>>>>>>> new and delete in hotspot C++ code. The check is only run with >>>>>>>> toolchains GCC and Clang (Linux and Macos builds). I have also >>>>>>>> modified the Oracle devkit on Linux to add the necessary >>>>>>>> symlink so that objdump will get picked up by configure. >>>>>>>> >>>>>>>> This change is depending on several fixes removing such uses >>>>>>>> that are currently in jdk/hs so this change will need to be >>>>>>>> pushed there as well. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>> >>>> >>> >> From tim.bell at oracle.com Mon Mar 5 18:14:34 2018 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 05 Mar 2018 10:14:34 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> Message-ID: <5A9D890A.2030500@oracle.com> Erik: make/devkit/Tools.gmk Lines 565, 566 - I see you removed dtrace from this list as that is dealt with up in lines 556 ... 558. Makes sense to me. Looks good. Tim > On 2018-03-04 15:22, David Holmes wrote: >> Hi Erik, >> >> On 3/03/2018 7:18 AM, Erik Joelsson wrote: >>> Hello, >>> >>> Here is a new version of this patch, reworked in several ways. It now >>> supports gcc, clang and solstudio. It uses nm instead of objdump, >>> which is more readily available in all our current build >>> environments. The check now uses mangled symbol names for all >>> toolchain types which makes things considerably faster. I also added >>> a check for only finding symbols classified as undefined. Otherwise >>> we get false positives in operator_new.o in debug builds. >> >> Sounds great! Thanks for doing the additional work on this. >> >>> I left the objdump addition to the devkit in there because it's a >>> good thing to have anyway for compare.sh. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.02/ >> >> In toolkit.m4: >> >> + case $TOOLCHAIN_TYPE in >> + gcc|clang|solstudio) >> BASIC_CHECK_TOOLS(OBJDUMP, [gobjdump objdump]) >> if test "x$OBJDUMP" != x; then >> # Only used for compare.sh; we can live without it. >> BASIC_FIXUP_EXECUTABLE >> # bails if argument is missing. >> BASIC_FIXUP_EXECUTABLE(OBJDUMP) >> fi >> + BASIC_FIXUP_EXECUTABLE(OBJDUMP) >> >> Isn't the if-clause redundant now that you unconditionally call >> BASIC_FIXUP_EXECUTABLE(OBJDUMP)? >> > Yes, I seem to have accidentally left the second line there. My > intention was to restore the conditional now that objdump is no longer > used for this new check. > > Here is a new webrev with the second fixup call removed: > > http://cr.openjdk.java.net/~erikj/8198243/webrev.03/ > > /Erik >> Thanks, >> David >> >>> I have run this patch against current jdk/jdk and jdk/hs in Mach5. In >>> jdk/jdk the build fails as expected on Solaris, Linux and Mac and in >>> jdk/hs, where the fixes we are detecting are present, all builds >>> succeeds. >>> >>> /Erik >>> >>> >>> On 2018-02-23 05:27, Magnus Ihse Bursie wrote: >>>> On 2018-02-22 20:41, Erik Joelsson wrote: >>>>> >>>>> >>>>> On 2018-02-21 21:06, David Holmes wrote: >>>>>> On 22/02/2018 4:07 AM, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> On 2018-02-20 21:33, David Holmes wrote: >>>>>>>> >>>>>>>> a) how much time it adds to the build? >>>>>>>> >>>>>>> I have not done extensive testing, but on my Linux workstation >>>>>>> with 32 hw threads, building just hotspot release build from a >>>>>>> clean workspace increased maybe 1 or 2 seconds (at around 90s >>>>>>> total), but the variance was around the same amount as that. >>>>>>>> b) why this doesn't work for Solaris Studio? >>>>>>>> >>>>>>> I didn't put a lot of effort into trying to figure it out. The >>>>>>> check used was provided by Kim Barrett, for Linux only. I figured >>>>>>> it would be simple enough to get it to work on mac and succeeded >>>>>>> there. It should certainly be possible to implement a similar >>>>>>> check on Solaris, but is it worth the time to do it? Both >>>>>>> development time and increased build time on one of the slower >>>>>>> build platforms? >>>>>> >>>>>> Depends how concerned we are with detecting this problem in OS >>>>>> specific source code? >>>>>> >>>>> I investigated this some more. I was able to do it successfully, >>>>> but the build time cost is way too large here. The culprit is >>>>> c++filt on Solaris which is incredibly costly, and the gnu version >>>>> does not demangle Solaris Studio symbols. I don't think we should >>>>> do this on Solaris. >>>> I agree, it's not worth it. >>>> >>>> Not all programmer's mistakes are reasonable to catch in technical >>>> traps. It we *should* spend time on getting automatic tool for >>>> keeping code quality up (and, yes, I really do think we should), >>>> there's most likely to be much better areas to spend that effort in, >>>> in making a lot of prone-to-break scripts for catching a single kind >>>> of problem. >>>> >>>> /Magnus >>>> >>>>> >>>>> We could grep for the mangled strings for the operators instead, >>>>> which is super fast. Problem is just figuring out all the possible >>>>> combinations. >>>>> >>>>> /Erik >>>>>> To be honest I'm not sure this pulls its own weight regardless. >>>>>> >>>>>> David >>>>>> >>>>>>> /Erik >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 21/02/2018 4:05 AM, Erik Joelsson wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> This patch adds a build time check for uses of global operators >>>>>>>>> new and delete in hotspot C++ code. The check is only run with >>>>>>>>> toolchains GCC and Clang (Linux and Macos builds). I have also >>>>>>>>> modified the Oracle devkit on Linux to add the necessary >>>>>>>>> symlink so that objdump will get picked up by configure. >>>>>>>>> >>>>>>>>> This change is depending on several fixes removing such uses >>>>>>>>> that are currently in jdk/hs so this change will need to be >>>>>>>>> pushed there as well. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >>>>>>>>> >>>>>>>>> /Erik From kim.barrett at oracle.com Mon Mar 5 19:46:35 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 5 Mar 2018 14:46:35 -0500 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> Message-ID: <13C31CF6-8246-4781-844F-673312BEFC57@oracle.com> > On Mar 5, 2018, at 11:41 AM, Erik Joelsson wrote: > > Hello, > > On 2018-03-04 15:22, David Holmes wrote: >> Hi Erik, >> >> On 3/03/2018 7:18 AM, Erik Joelsson wrote: >>> Hello, >>> >>> Here is a new version of this patch, reworked in several ways. It now supports gcc, clang and solstudio. It uses nm instead of objdump, which is more readily available in all our current build environments. The check now uses mangled symbol names for all toolchain types which makes things considerably faster. I also added a check for only finding symbols classified as undefined. Otherwise we get false positives in operator_new.o in debug builds. >> >> Sounds great! Thanks for doing the additional work on this. >> >>> I left the objdump addition to the devkit in there because it's a good thing to have anyway for compare.sh. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.02/ >> >> In toolkit.m4: >> >> + case $TOOLCHAIN_TYPE in >> + gcc|clang|solstudio) >> BASIC_CHECK_TOOLS(OBJDUMP, [gobjdump objdump]) >> if test "x$OBJDUMP" != x; then >> # Only used for compare.sh; we can live without it. BASIC_FIXUP_EXECUTABLE >> # bails if argument is missing. >> BASIC_FIXUP_EXECUTABLE(OBJDUMP) >> fi >> + BASIC_FIXUP_EXECUTABLE(OBJDUMP) >> >> Isn't the if-clause redundant now that you unconditionally call BASIC_FIXUP_EXECUTABLE(OBJDUMP)? >> > Yes, I seem to have accidentally left the second line there. My intention was to restore the conditional now that objdump is no longer used for this new check. > > Here is a new webrev with the second fixup call removed: > > http://cr.openjdk.java.net/~erikj/8198243/webrev.03/ Old code in toolkit.m4 did the OBJDUMP stuff unconditionally. New code makes it conditional on TOOLCHAIN_TYPE. That doesn?t seem right. compare.sh seems to want OBJDUMP for aix too, and that?s not in the toolchain list here. > > /Erik >> Thanks, >> David >> >>> I have run this patch against current jdk/jdk and jdk/hs in Mach5. In jdk/jdk the build fails as expected on Solaris, Linux and Mac and in jdk/hs, where the fixes we are detecting are present, all builds succeeds. >>> >>> /Erik >>> >>> >>> On 2018-02-23 05:27, Magnus Ihse Bursie wrote: >>>> On 2018-02-22 20:41, Erik Joelsson wrote: >>>>> >>>>> >>>>> On 2018-02-21 21:06, David Holmes wrote: >>>>>> On 22/02/2018 4:07 AM, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> On 2018-02-20 21:33, David Holmes wrote: >>>>>>>> >>>>>>>> a) how much time it adds to the build? >>>>>>>> >>>>>>> I have not done extensive testing, but on my Linux workstation with 32 hw threads, building just hotspot release build from a clean workspace increased maybe 1 or 2 seconds (at around 90s total), but the variance was around the same amount as that. >>>>>>>> b) why this doesn't work for Solaris Studio? >>>>>>>> >>>>>>> I didn't put a lot of effort into trying to figure it out. The check used was provided by Kim Barrett, for Linux only. I figured it would be simple enough to get it to work on mac and succeeded there. It should certainly be possible to implement a similar check on Solaris, but is it worth the time to do it? Both development time and increased build time on one of the slower build platforms? >>>>>> >>>>>> Depends how concerned we are with detecting this problem in OS specific source code? >>>>>> >>>>> I investigated this some more. I was able to do it successfully, but the build time cost is way too large here. The culprit is c++filt on Solaris which is incredibly costly, and the gnu version does not demangle Solaris Studio symbols. I don't think we should do this on Solaris. >>>> I agree, it's not worth it. >>>> >>>> Not all programmer's mistakes are reasonable to catch in technical traps. It we *should* spend time on getting automatic tool for keeping code quality up (and, yes, I really do think we should), there's most likely to be much better areas to spend that effort in, in making a lot of prone-to-break scripts for catching a single kind of problem. >>>> >>>> /Magnus >>>> >>>>> >>>>> We could grep for the mangled strings for the operators instead, which is super fast. Problem is just figuring out all the possible combinations. >>>>> >>>>> /Erik >>>>>> To be honest I'm not sure this pulls its own weight regardless. >>>>>> >>>>>> David >>>>>> >>>>>>> /Erik >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 21/02/2018 4:05 AM, Erik Joelsson wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> This patch adds a build time check for uses of global operators new and delete in hotspot C++ code. The check is only run with toolchains GCC and Clang (Linux and Macos builds). I have also modified the Oracle devkit on Linux to add the necessary symlink so that objdump will get picked up by configure. >>>>>>>>> >>>>>>>>> This change is depending on several fixes removing such uses that are currently in jdk/hs so this change will need to be pushed there as well. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >>>>>>>>> >>>>>>>>> /Erik From erik.joelsson at oracle.com Mon Mar 5 20:03:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Mar 2018 12:03:50 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <13C31CF6-8246-4781-844F-673312BEFC57@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> <13C31CF6-8246-4781-844F-673312BEFC57@oracle.com> Message-ID: On 2018-03-05 11:46, Kim Barrett wrote: > Old code in toolkit.m4 did the OBJDUMP stuff unconditionally. New code > makes it conditional on TOOLCHAIN_TYPE. > That doesn?t seem right. compare.sh seems to want OBJDUMP for aix too, and that?s not in the toolchain list here. That is a good point. I forgot about aix and was thinking more in the lines of not windows. Will restore the OBJDUMP code completely. /Erik >> /Erik >>> Thanks, >>> David >>> >>>> I have run this patch against current jdk/jdk and jdk/hs in Mach5. In jdk/jdk the build fails as expected on Solaris, Linux and Mac and in jdk/hs, where the fixes we are detecting are present, all builds succeeds. >>>> >>>> /Erik >>>> >>>> >>>> On 2018-02-23 05:27, Magnus Ihse Bursie wrote: >>>>> On 2018-02-22 20:41, Erik Joelsson wrote: >>>>>> >>>>>> On 2018-02-21 21:06, David Holmes wrote: >>>>>>> On 22/02/2018 4:07 AM, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> >>>>>>>> On 2018-02-20 21:33, David Holmes wrote: >>>>>>>>> a) how much time it adds to the build? >>>>>>>>> >>>>>>>> I have not done extensive testing, but on my Linux workstation with 32 hw threads, building just hotspot release build from a clean workspace increased maybe 1 or 2 seconds (at around 90s total), but the variance was around the same amount as that. >>>>>>>>> b) why this doesn't work for Solaris Studio? >>>>>>>>> >>>>>>>> I didn't put a lot of effort into trying to figure it out. The check used was provided by Kim Barrett, for Linux only. I figured it would be simple enough to get it to work on mac and succeeded there. It should certainly be possible to implement a similar check on Solaris, but is it worth the time to do it? Both development time and increased build time on one of the slower build platforms? >>>>>>> Depends how concerned we are with detecting this problem in OS specific source code? >>>>>>> >>>>>> I investigated this some more. I was able to do it successfully, but the build time cost is way too large here. The culprit is c++filt on Solaris which is incredibly costly, and the gnu version does not demangle Solaris Studio symbols. I don't think we should do this on Solaris. >>>>> I agree, it's not worth it. >>>>> >>>>> Not all programmer's mistakes are reasonable to catch in technical traps. It we *should* spend time on getting automatic tool for keeping code quality up (and, yes, I really do think we should), there's most likely to be much better areas to spend that effort in, in making a lot of prone-to-break scripts for catching a single kind of problem. >>>>> >>>>> /Magnus >>>>> >>>>>> We could grep for the mangled strings for the operators instead, which is super fast. Problem is just figuring out all the possible combinations. >>>>>> >>>>>> /Erik >>>>>>> To be honest I'm not sure this pulls its own weight regardless. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> /Erik >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 21/02/2018 4:05 AM, Erik Joelsson wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> This patch adds a build time check for uses of global operators new and delete in hotspot C++ code. The check is only run with toolchains GCC and Clang (Linux and Macos builds). I have also modified the Oracle devkit on Linux to add the necessary symlink so that objdump will get picked up by configure. >>>>>>>>>> >>>>>>>>>> This change is depending on several fixes removing such uses that are currently in jdk/hs so this change will need to be pushed there as well. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >>>>>>>>>> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >>>>>>>>>> >>>>>>>>>> /Erik > From erik.joelsson at oracle.com Mon Mar 5 20:06:12 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Mar 2018 12:06:12 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> <13C31CF6-8246-4781-844F-673312BEFC57@oracle.com> Message-ID: <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> New webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.04 /Erik On 2018-03-05 12:03, Erik Joelsson wrote: > > On 2018-03-05 11:46, Kim Barrett wrote: >> Old code in toolkit.m4 did the OBJDUMP stuff unconditionally. New >> code makes it conditional on TOOLCHAIN_TYPE. >> That doesn?t seem right.? compare.sh seems to want OBJDUMP for aix >> too, and that?s not in the toolchain list here. > That is a good point. I forgot about aix and was thinking more in the > lines of not windows. Will restore the OBJDUMP code completely. > > /Erik From tim.bell at oracle.com Mon Mar 5 21:58:13 2018 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 05 Mar 2018 13:58:13 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> <13C31CF6-8246-4781-844F-673312BEFC57@oracle.com> <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> Message-ID: <5A9DBD75.7040403@oracle.com> Erik: Looks good. /Tim > New webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.04 > > /Erik > > > On 2018-03-05 12:03, Erik Joelsson wrote: >> >> On 2018-03-05 11:46, Kim Barrett wrote: >>> Old code in toolkit.m4 did the OBJDUMP stuff unconditionally. New >>> code makes it conditional on TOOLCHAIN_TYPE. >>> That doesn?t seem right. compare.sh seems to want OBJDUMP for aix >>> too, and that?s not in the toolchain list here. >> That is a good point. I forgot about aix and was thinking more in the >> lines of not windows. Will restore the OBJDUMP code completely. >> >> /Erik > From kim.barrett at oracle.com Mon Mar 5 22:10:33 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 5 Mar 2018 17:10:33 -0500 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> <13C31CF6-8246-4781-844F-673312BEFC57@oracle.com> <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> Message-ID: <46EEF12E-2F5A-46CB-A18D-7E4A8E019C23@oracle.com> > On Mar 5, 2018, at 3:06 PM, Erik Joelsson wrote: > > New webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.04 Looks good. > > /Erik > > > On 2018-03-05 12:03, Erik Joelsson wrote: >> >> On 2018-03-05 11:46, Kim Barrett wrote: >>> Old code in toolkit.m4 did the OBJDUMP stuff unconditionally. New code makes it conditional on TOOLCHAIN_TYPE. >>> That doesn?t seem right. compare.sh seems to want OBJDUMP for aix too, and that?s not in the toolchain list here. >> That is a good point. I forgot about aix and was thinking more in the lines of not windows. Will restore the OBJDUMP code completely. >> >> /Erik From david.holmes at oracle.com Mon Mar 5 22:17:23 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Mar 2018 08:17:23 +1000 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> <13C31CF6-8246-4781-844F-673312BEFC57@oracle.com> <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> Message-ID: On 6/03/2018 6:06 AM, Erik Joelsson wrote: > New webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.04 Looks good. Thanks, David > /Erik > > > On 2018-03-05 12:03, Erik Joelsson wrote: >> >> On 2018-03-05 11:46, Kim Barrett wrote: >>> Old code in toolkit.m4 did the OBJDUMP stuff unconditionally. New >>> code makes it conditional on TOOLCHAIN_TYPE. >>> That doesn?t seem right.? compare.sh seems to want OBJDUMP for aix >>> too, and that?s not in the toolchain list here. >> That is a good point. I forgot about aix and was thinking more in the >> lines of not windows. Will restore the OBJDUMP code completely. >> >> /Erik > From philip.race at oracle.com Mon Mar 5 22:38:18 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 5 Mar 2018 14:38:18 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers In-Reply-To: <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com> References: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com> <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com> Message-ID: <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com> >I'm not sure what role the "verification" step we had before ever played. >For all the years we've been "verifying" this, we've detected no differences. I think this is useful in the event that you make some changes and regenerate the 64 bit sizes but not 32 bit. For example this old bug similarly reported a breakage on Solaris .. https://bugs.openjdk.java.net/browse/JDK-6804680 ... back in the day when we only had that checked in and the ones used for Linux were being generated on the fly. My reading of the history here is sizes.32 and sizes.64 were added to support cross-compilation, and the verification step meant that all architectures would get checked in some build or other. We care less about 32 bit now .. and even the cross-compilation .. so arguably we could go back to always generating the files, as was the case for Linux before https://bugs.openjdk.java.net/browse/JDK-8004151 But if we say we still want to keep around the possibility of 32 bit support AND cross-compilation, then the verification step still seems useful. If we say we care only about 32 bit or do not care about cross compilation, then why not get rid of the checked in file and calculate these every build ? The clean up of removing the solaris specific seems like it could have been done a long time ago .. I am not sure why was ever only this one case there. I'd have to dig back a very long way. I do agree we do not need to support 32 + 64 bit concurrently, that went away when 64 bit solaris overlay on 32 bit was dropped. -phil. On 03/02/2018 07:23 AM, Erik Joelsson wrote: > Adding 2d-dev in the hopes of getting some input from component team. > Seems like they should be aware of us removing the support for > multiple data models. > > Looks like you left a debug message at line 40 in GensrcX11Wrappers.gmk. > > /Erik > > On 2018-03-02 03:00, Magnus Ihse Bursie wrote: >> On 2018-03-02 00:02, Erik Joelsson wrote: >>> Hello, >>> >>> In xlibtypes.txt comment, should it be sizes-64.txt? >> >> Yes, good catch. >> >>> >>> Generating both 32 and 64 seems a bit outdated at this point. Surely >>> this is a remnant of bundling 64 and 32 bit together on Solaris in >>> the past? Perhaps someone in 2d can answer this? Would be nice to be >>> able to clean up that part as well if possible. >> Yes, you are right. We should clean up that as well. I was just too >> conservative. I've now actually checked what happens when you >> generate both 32 and 64 bit versions, and the result is that instead >> of code like: >> public static int getSize() { return 96; } >> we get code like this: >> public static int getSize() { return ((XlibWrapper.dataModel == >> 32)?(80):(96)); } >> >> Since we do no longer support multiple data models for the same >> build, this is just unnecessary. In fact, that leads to an even >> better cleanup, since we will always need just a single input file. >> >> I also wrapped the tool calls in ExecuteWithLog. >> >> Updated webrev: >> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 >> >> >> /Magnus >> > From magnus.ihse.bursie at oracle.com Mon Mar 5 23:03:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Mar 2018 00:03:15 +0100 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> <13C31CF6-8246-4781-844F-673312BEFC57@oracle.com> <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> Message-ID: <1ec7303b-aff3-0c95-a115-875f64509700@oracle.com> On 2018-03-05 21:06, Erik Joelsson wrote: > New webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.04 Looks good to me. /Magnus > > /Erik > > > On 2018-03-05 12:03, Erik Joelsson wrote: >> >> On 2018-03-05 11:46, Kim Barrett wrote: >>> Old code in toolkit.m4 did the OBJDUMP stuff unconditionally. New >>> code makes it conditional on TOOLCHAIN_TYPE. >>> That doesn?t seem right.? compare.sh seems to want OBJDUMP for aix >>> too, and that?s not in the toolchain list here. >> That is a good point. I forgot about aix and was thinking more in the >> lines of not windows. Will restore the OBJDUMP code completely. >> >> /Erik > From magnus.ihse.bursie at oracle.com Mon Mar 5 23:30:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Mar 2018 00:30:49 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers In-Reply-To: <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com> References: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com> <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com> <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com> Message-ID: On 2018-03-05 23:38, Phil Race wrote: > >I'm not sure what role the "verification" step we had before ever > played. > >For all the years we've been "verifying" this, we've detected no > differences. > > I think this is useful in the event that you make some changes and > regenerate the 64 bit sizes but not 32 bit. That's a good point. I should add a warning message when regenerating the checked-in data files that you need to regenerate the files on both 32 and 64 bit platforms. > > For example this old bug similarly reported a breakage on Solaris .. > https://bugs.openjdk.java.net/browse/JDK-6804680 > > ... back in the day when we only had that checked in and the ones used > for Linux > were being generated on the fly. My reading of the history here is > sizes.32 and sizes.64 > were added to support cross-compilation, and the verification step > meant that? all > architectures would get checked in some build or other. I'd rather say that it was at this time that we stopped run-time generation of the X11 size data. The "verification" step was there more like a comfort thing for the build team, since we was too conservative. > The clean up of removing the solaris specific seems like it could have > been > done a long time ago .. I am not sure why was ever only this one case > there. > I'd have to dig back a very long way. > > I do agree we do not need to support 32 + 64 bit concurrently, that went > away when 64 bit solaris overlay on 32 bit was dropped. Thank you. Updated webrev with warning message about updating for all platforms: http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03 (Only UpdateX11Wrappers.gmk has changed) /Magnus > > -phil. > > On 03/02/2018 07:23 AM, Erik Joelsson wrote: >> Adding 2d-dev in the hopes of getting some input from component team. >> Seems like they should be aware of us removing the support for >> multiple data models. >> >> Looks like you left a debug message at line 40 in GensrcX11Wrappers.gmk. >> >> /Erik >> >> On 2018-03-02 03:00, Magnus Ihse Bursie wrote: >>> On 2018-03-02 00:02, Erik Joelsson wrote: >>>> Hello, >>>> >>>> In xlibtypes.txt comment, should it be sizes-64.txt? >>> >>> Yes, good catch. >>> >>>> >>>> Generating both 32 and 64 seems a bit outdated at this point. >>>> Surely this is a remnant of bundling 64 and 32 bit together on >>>> Solaris in the past? Perhaps someone in 2d can answer this? Would >>>> be nice to be able to clean up that part as well if possible. >>> Yes, you are right. We should clean up that as well. I was just too >>> conservative. I've now actually checked what happens when you >>> generate both 32 and 64 bit versions, and the result is that instead >>> of code like: >>> ??? public static int getSize() { return 96; } >>> we get code like this: >>> ??? public static int getSize() { return ((XlibWrapper.dataModel == >>> 32)?(80):(96)); } >>> >>> Since we do no longer support multiple data models for the same >>> build, this is just unnecessary. In fact, that leads to an even >>> better cleanup, since we will always need just a single input file. >>> >>> I also wrapped the tool calls in ExecuteWithLog. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 >>> >>> >>> /Magnus >>> >> > From magnus.ihse.bursie at oracle.com Mon Mar 5 23:45:12 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Mar 2018 00:45:12 +0100 Subject: RFR: JDK-8199052 Configure broken on aarch64 Message-ID: <6fd80464-5671-8fbc-da91-883b100a4df7@oracle.com> From the bug report: It seems that JDK-8198724 "Refactor FLAGS handling in configure" broke the aarch64 build. The new configure scheme tries to pass the argument "-m64" to the gcc compiler, but that is an x86-only flag. configure:35228: checking whether the C compiler works configure:35250: /usr/bin/gcc -m64 -m64 conftest.c >&5 gcc: error: unrecognized command line option '-m64' gcc: error: unrecognized command line option '-m64' [...] The flags handling is currently in flux. The entire "MACHINE_FLAG" handling is not optimal. But we can't have aarch64 hanging around broken awaiting a proper refactoring, so here's a not-ideal-but-working patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8199052 Patch inline: diff --git a/make/autoconf/flags.m4 b/make/autoconf/flags.m4 --- a/make/autoconf/flags.m4 +++ b/make/autoconf/flags.m4 @@ -236,7 +236,9 @@ ?? if test "x$TOOLCHAIN_TYPE" = xxlc; then ???? MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" ?? elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then -??? MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" +??? if test "x$OPENJDK_TARGET_CPU" != xaarch64; then +????? MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" +??? fi ?? fi ?? # FIXME: global flags are not used yet... /Magnus From philip.race at oracle.com Mon Mar 5 23:53:53 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 5 Mar 2018 15:53:53 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers In-Reply-To: References: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com> <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com> <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com> Message-ID: <5b0e7911-b27d-ce35-abde-a35faaf89693@oracle.com> + $(ECHO) needs to be updated for both 32 and 64 bit platforms. You have now needs -> need. Could we make this easier by trying to generate the 32 bit native binary as well if running on 64 bits ? Looks like this was not normally done on Linux but if you have 32 bit compiler + library support it should work. Or do you consider it easy enough to just kick off a 32 bit build to get the same ? -phil. On 03/05/2018 03:30 PM, Magnus Ihse Bursie wrote: > > On 2018-03-05 23:38, Phil Race wrote: >> >I'm not sure what role the "verification" step we had before ever >> played. >> >For all the years we've been "verifying" this, we've detected no >> differences. >> >> I think this is useful in the event that you make some changes and >> regenerate the 64 bit sizes but not 32 bit. > That's a good point. I should add a warning message when regenerating > the checked-in data files that you need to regenerate the files on > both 32 and 64 bit platforms. >> >> For example this old bug similarly reported a breakage on Solaris .. >> https://bugs.openjdk.java.net/browse/JDK-6804680 >> >> ... back in the day when we only had that checked in and the ones >> used for Linux >> were being generated on the fly. My reading of the history here is >> sizes.32 and sizes.64 >> were added to support cross-compilation, and the verification step >> meant that all >> architectures would get checked in some build or other. > > I'd rather say that it was at this time that we stopped run-time > generation of the X11 size data. The "verification" step was there > more like a comfort thing for the build team, since we was too > conservative. > > >> The clean up of removing the solaris specific seems like it could >> have been >> done a long time ago .. I am not sure why was ever only this one case >> there. >> I'd have to dig back a very long way. >> >> I do agree we do not need to support 32 + 64 bit concurrently, that went >> away when 64 bit solaris overlay on 32 bit was dropped. > > Thank you. > > Updated webrev with warning message about updating for all platforms: > > http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03 > > > (Only UpdateX11Wrappers.gmk has changed) > > /Magnus > >> >> -phil. >> >> On 03/02/2018 07:23 AM, Erik Joelsson wrote: >>> Adding 2d-dev in the hopes of getting some input from component >>> team. Seems like they should be aware of us removing the support for >>> multiple data models. >>> >>> Looks like you left a debug message at line 40 in >>> GensrcX11Wrappers.gmk. >>> >>> /Erik >>> >>> On 2018-03-02 03:00, Magnus Ihse Bursie wrote: >>>> On 2018-03-02 00:02, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> In xlibtypes.txt comment, should it be sizes-64.txt? >>>> >>>> Yes, good catch. >>>> >>>>> >>>>> Generating both 32 and 64 seems a bit outdated at this point. >>>>> Surely this is a remnant of bundling 64 and 32 bit together on >>>>> Solaris in the past? Perhaps someone in 2d can answer this? Would >>>>> be nice to be able to clean up that part as well if possible. >>>> Yes, you are right. We should clean up that as well. I was just too >>>> conservative. I've now actually checked what happens when you >>>> generate both 32 and 64 bit versions, and the result is that >>>> instead of code like: >>>> public static int getSize() { return 96; } >>>> we get code like this: >>>> public static int getSize() { return ((XlibWrapper.dataModel == >>>> 32)?(80):(96)); } >>>> >>>> Since we do no longer support multiple data models for the same >>>> build, this is just unnecessary. In fact, that leads to an even >>>> better cleanup, since we will always need just a single input file. >>>> >>>> I also wrapped the tool calls in ExecuteWithLog. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 >>>> >>>> >>>> /Magnus >>>> >>> >> > From erik.joelsson at oracle.com Mon Mar 5 23:55:29 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Mar 2018 15:55:29 -0800 Subject: RFR: JDK-8199052 Configure broken on aarch64 In-Reply-To: <6fd80464-5671-8fbc-da91-883b100a4df7@oracle.com> References: <6fd80464-5671-8fbc-da91-883b100a4df7@oracle.com> Message-ID: Looks good. /Erik On 2018-03-05 15:45, Magnus Ihse Bursie wrote: > From the bug report: > > It seems that JDK-8198724 "Refactor FLAGS handling in configure" broke > the aarch64 build. > > The new configure scheme tries to pass the argument "-m64" to the gcc > compiler, but that is an x86-only flag. > > configure:35228: checking whether the C compiler works > configure:35250: /usr/bin/gcc -m64 -m64 conftest.c >&5 > gcc: error: unrecognized command line option '-m64' > gcc: error: unrecognized command line option '-m64' > [...] > > The flags handling is currently in flux. The entire "MACHINE_FLAG" > handling is not optimal. But we can't have aarch64 hanging around > broken awaiting a proper refactoring, so here's a > not-ideal-but-working patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199052 > Patch inline: > diff --git a/make/autoconf/flags.m4 b/make/autoconf/flags.m4 > --- a/make/autoconf/flags.m4 > +++ b/make/autoconf/flags.m4 > @@ -236,7 +236,9 @@ > ?? if test "x$TOOLCHAIN_TYPE" = xxlc; then > ???? MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" > ?? elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then > -??? MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" > +??? if test "x$OPENJDK_TARGET_CPU" != xaarch64; then > +????? MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" > +??? fi > ?? fi > > ?? # FIXME: global flags are not used yet... > > /Magnus From magnus.ihse.bursie at oracle.com Tue Mar 6 00:00:03 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Mar 2018 01:00:03 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers In-Reply-To: <5b0e7911-b27d-ce35-abde-a35faaf89693@oracle.com> References: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com> <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com> <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com> <5b0e7911-b27d-ce35-abde-a35faaf89693@oracle.com> Message-ID: <7e270b69-9b1f-81e0-bf28-820e893b66ad@oracle.com> On 2018-03-06 00:53, Phil Race wrote: > + $(ECHO) needs to be updated for both 32 and 64 bit platforms. You > have now needs -> need. Fixed typo. Thanks! (I really hate how I suck at those English plural s'es :-&) > Could we make this easier by trying to generate the 32 bit native > binary as well if running on 64 bits ? Looks like this was not > normally done on Linux but if you have 32 bit compiler + library > support it should work. Or do you consider it easy enough to just kick > off a 32 bit build to get the same ? Yes, I consider that easy enough, given how unlikely it is that this needs ever be done. /Magnus > -phil. > > On 03/05/2018 03:30 PM, Magnus Ihse Bursie wrote: >> >> On 2018-03-05 23:38, Phil Race wrote: >>> >I'm not sure what role the "verification" step we had before ever >>> played. >>> >For all the years we've been "verifying" this, we've detected no >>> differences. >>> >>> I think this is useful in the event that you make some changes and >>> regenerate the 64 bit sizes but not 32 bit. >> That's a good point. I should add a warning message when regenerating >> the checked-in data files that you need to regenerate the files on >> both 32 and 64 bit platforms. >>> >>> For example this old bug similarly reported a breakage on Solaris .. >>> https://bugs.openjdk.java.net/browse/JDK-6804680 >>> >>> ... back in the day when we only had that checked in and the ones >>> used for Linux >>> were being generated on the fly. My reading of the history here is >>> sizes.32 and sizes.64 >>> were added to support cross-compilation, and the verification step >>> meant that? all >>> architectures would get checked in some build or other. >> >> I'd rather say that it was at this time that we stopped run-time >> generation of the X11 size data. The "verification" step was there >> more like a comfort thing for the build team, since we was too >> conservative. >> >> >>> The clean up of removing the solaris specific seems like it could >>> have been >>> done a long time ago .. I am not sure why was ever only this one >>> case there. >>> I'd have to dig back a very long way. >>> >>> I do agree we do not need to support 32 + 64 bit concurrently, that >>> went >>> away when 64 bit solaris overlay on 32 bit was dropped. >> >> Thank you. >> >> Updated webrev with warning message about updating for all platforms: >> >> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03 >> >> >> (Only UpdateX11Wrappers.gmk has changed) >> >> /Magnus >> >>> >>> -phil. >>> >>> On 03/02/2018 07:23 AM, Erik Joelsson wrote: >>>> Adding 2d-dev in the hopes of getting some input from component >>>> team. Seems like they should be aware of us removing the support >>>> for multiple data models. >>>> >>>> Looks like you left a debug message at line 40 in >>>> GensrcX11Wrappers.gmk. >>>> >>>> /Erik >>>> >>>> On 2018-03-02 03:00, Magnus Ihse Bursie wrote: >>>>> On 2018-03-02 00:02, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> In xlibtypes.txt comment, should it be sizes-64.txt? >>>>> >>>>> Yes, good catch. >>>>> >>>>>> >>>>>> Generating both 32 and 64 seems a bit outdated at this point. >>>>>> Surely this is a remnant of bundling 64 and 32 bit together on >>>>>> Solaris in the past? Perhaps someone in 2d can answer this? Would >>>>>> be nice to be able to clean up that part as well if possible. >>>>> Yes, you are right. We should clean up that as well. I was just >>>>> too conservative. I've now actually checked what happens when you >>>>> generate both 32 and 64 bit versions, and the result is that >>>>> instead of code like: >>>>> ??? public static int getSize() { return 96; } >>>>> we get code like this: >>>>> ??? public static int getSize() { return ((XlibWrapper.dataModel >>>>> == 32)?(80):(96)); } >>>>> >>>>> Since we do no longer support multiple data models for the same >>>>> build, this is just unnecessary. In fact, that leads to an even >>>>> better cleanup, since we will always need just a single input file. >>>>> >>>>> I also wrapped the tool calls in ExecuteWithLog. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 >>>>> >>>>> >>>>> /Magnus >>>>> >>>> >>> >> > From philip.race at oracle.com Tue Mar 6 00:04:21 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 5 Mar 2018 16:04:21 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers In-Reply-To: <7e270b69-9b1f-81e0-bf28-820e893b66ad@oracle.com> References: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com> <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com> <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com> <5b0e7911-b27d-ce35-abde-a35faaf89693@oracle.com> <7e270b69-9b1f-81e0-bf28-820e893b66ad@oracle.com> Message-ID: It isn't "unlikely" .. it is just "relatively rare". -phil. On 03/05/2018 04:00 PM, Magnus Ihse Bursie wrote: > > > On 2018-03-06 00:53, Phil Race wrote: >> + $(ECHO) needs to be updated for both 32 and 64 bit platforms. You >> have now needs -> need. > Fixed typo. Thanks! (I really hate how I suck at those English plural > s'es :-&) >> Could we make this easier by trying to generate the 32 bit native >> binary as well if running on 64 bits ? Looks like this was not >> normally done on Linux but if you have 32 bit compiler + library >> support it should work. Or do you consider it easy enough to just >> kick off a 32 bit build to get the same ? > Yes, I consider that easy enough, given how unlikely it is that this > needs ever be done. > > /Magnus > >> -phil. >> >> On 03/05/2018 03:30 PM, Magnus Ihse Bursie wrote: >>> >>> On 2018-03-05 23:38, Phil Race wrote: >>>> >I'm not sure what role the "verification" step we had before ever >>>> played. >>>> >For all the years we've been "verifying" this, we've detected no >>>> differences. >>>> >>>> I think this is useful in the event that you make some changes and >>>> regenerate the 64 bit sizes but not 32 bit. >>> That's a good point. I should add a warning message when >>> regenerating the checked-in data files that you need to regenerate >>> the files on both 32 and 64 bit platforms. >>>> >>>> For example this old bug similarly reported a breakage on Solaris .. >>>> https://bugs.openjdk.java.net/browse/JDK-6804680 >>>> >>>> ... back in the day when we only had that checked in and the ones >>>> used for Linux >>>> were being generated on the fly. My reading of the history here is >>>> sizes.32 and sizes.64 >>>> were added to support cross-compilation, and the verification step >>>> meant that all >>>> architectures would get checked in some build or other. >>> >>> I'd rather say that it was at this time that we stopped run-time >>> generation of the X11 size data. The "verification" step was there >>> more like a comfort thing for the build team, since we was too >>> conservative. >>> >>> >>>> The clean up of removing the solaris specific seems like it could >>>> have been >>>> done a long time ago .. I am not sure why was ever only this one >>>> case there. >>>> I'd have to dig back a very long way. >>>> >>>> I do agree we do not need to support 32 + 64 bit concurrently, that >>>> went >>>> away when 64 bit solaris overlay on 32 bit was dropped. >>> >>> Thank you. >>> >>> Updated webrev with warning message about updating for all platforms: >>> >>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03 >>> >>> >>> (Only UpdateX11Wrappers.gmk has changed) >>> >>> /Magnus >>> >>>> >>>> -phil. >>>> >>>> On 03/02/2018 07:23 AM, Erik Joelsson wrote: >>>>> Adding 2d-dev in the hopes of getting some input from component >>>>> team. Seems like they should be aware of us removing the support >>>>> for multiple data models. >>>>> >>>>> Looks like you left a debug message at line 40 in >>>>> GensrcX11Wrappers.gmk. >>>>> >>>>> /Erik >>>>> >>>>> On 2018-03-02 03:00, Magnus Ihse Bursie wrote: >>>>>> On 2018-03-02 00:02, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> In xlibtypes.txt comment, should it be sizes-64.txt? >>>>>> >>>>>> Yes, good catch. >>>>>> >>>>>>> >>>>>>> Generating both 32 and 64 seems a bit outdated at this point. >>>>>>> Surely this is a remnant of bundling 64 and 32 bit together on >>>>>>> Solaris in the past? Perhaps someone in 2d can answer this? >>>>>>> Would be nice to be able to clean up that part as well if possible. >>>>>> Yes, you are right. We should clean up that as well. I was just >>>>>> too conservative. I've now actually checked what happens when you >>>>>> generate both 32 and 64 bit versions, and the result is that >>>>>> instead of code like: >>>>>> public static int getSize() { return 96; } >>>>>> we get code like this: >>>>>> public static int getSize() { return ((XlibWrapper.dataModel >>>>>> == 32)?(80):(96)); } >>>>>> >>>>>> Since we do no longer support multiple data models for the same >>>>>> build, this is just unnecessary. In fact, that leads to an even >>>>>> better cleanup, since we will always need just a single input file. >>>>>> >>>>>> I also wrapped the tool calls in ExecuteWithLog. >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 >>>>>> >>>>>> >>>>>> /Magnus >>>>>> >>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Tue Mar 6 09:23:12 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Mar 2018 10:23:12 +0100 Subject: RFR: JDK-8199103 Can't use COMPARE_BUILD with PATCH from custom root Message-ID: <353228d1-208b-ceb3-39e2-bce635e43fb1@oracle.com> This fix will enable patch files for COMPARE_BUILD to be hosted in a custom root. Bug: https://bugs.openjdk.java.net/browse/JDK-8199103 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199103-use-PATCH-in-COMPARE_BUILD-custom-root/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Mar 6 13:37:24 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Mar 2018 14:37:24 +0100 Subject: RFR: JDK-8199118 Filtering of filename for microsoft CL broken on newer Cygwin Message-ID: <1477a648-09c6-0234-1d3a-99ab0716dff3@oracle.com> The code in NativeCompilation.gmk that was supposed to filter out CL's printing of the file being compiled has stopped working on modern Cygwin, since Cygwin grep is broken and cannot handle Windows line endings. We've seen this in multiple places, but has not been able to provide a generic solution, so we need to fix it in place for every occasion. Bug: https://bugs.openjdk.java.net/browse/JDK-8199118 Patch inline: diff --git a/make/common/NativeCompilation.gmk b/make/common/NativeCompilation.gmk --- a/make/common/NativeCompilation.gmk +++ b/make/common/NativeCompilation.gmk @@ -321,7 +321,7 @@ ????????? $$(call ExecuteWithLog, $$@, \ ????????????? $$($1_$2_COMP) $$($1_$2_FLAGS) -showIncludes $$($1_$2_DEBUG_OUT_FLAGS) \ ????????????????? $(CC_OUT_OPTION)$$($1_$2_OBJ) $2) \ -???????????? | $(GREP) -v -e "^Note: including file:" \ +???????????? | $(TR) -d '\r' | $(GREP) -v -e "^Note: including file:" \ ????????????????? -e "^$(notdir $2)$$$$" || test "$$$$?" = "1" ; \ ????????? $(ECHO) $$@: \\ > $$($1_$2_DEP) ; \ ????????? $(SED) $(WINDOWS_SHOWINCLUDE_SED_PATTERN) $$($1_$2_OBJ).log \ /Magnus From erik.joelsson at oracle.com Tue Mar 6 14:50:09 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Mar 2018 06:50:09 -0800 Subject: RFR: JDK-8199118 Filtering of filename for microsoft CL broken on newer Cygwin In-Reply-To: <1477a648-09c6-0234-1d3a-99ab0716dff3@oracle.com> References: <1477a648-09c6-0234-1d3a-99ab0716dff3@oracle.com> Message-ID: Looks good. /Erik On 2018-03-06 05:37, Magnus Ihse Bursie wrote: > The code in NativeCompilation.gmk that was supposed to filter out CL's > printing of the file being compiled has stopped working on modern > Cygwin, since Cygwin grep is broken and cannot handle Windows line > endings. We've seen this in multiple places, but has not been able to > provide a generic solution, so we need to fix it in place for every > occasion. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199118 > Patch inline: > diff --git a/make/common/NativeCompilation.gmk > b/make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk > +++ b/make/common/NativeCompilation.gmk > @@ -321,7 +321,7 @@ > ????????? $$(call ExecuteWithLog, $$@, \ > ????????????? $$($1_$2_COMP) $$($1_$2_FLAGS) -showIncludes > $$($1_$2_DEBUG_OUT_FLAGS) \ > ????????????????? $(CC_OUT_OPTION)$$($1_$2_OBJ) $2) \ > -???????????? | $(GREP) -v -e "^Note: including file:" \ > +???????????? | $(TR) -d '\r' | $(GREP) -v -e "^Note: including file:" \ > ????????????????? -e "^$(notdir $2)$$$$" || test "$$$$?" = "1" ; \ > ????????? $(ECHO) $$@: \\ > $$($1_$2_DEP) ; \ > ????????? $(SED) $(WINDOWS_SHOWINCLUDE_SED_PATTERN) $$($1_$2_OBJ).log \ > > /Magnus From erik.joelsson at oracle.com Tue Mar 6 14:59:42 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Mar 2018 06:59:42 -0800 Subject: RFR: JDK-8199103 Can't use COMPARE_BUILD with PATCH from custom root In-Reply-To: <353228d1-208b-ceb3-39e2-bce635e43fb1@oracle.com> References: <353228d1-208b-ceb3-39e2-bce635e43fb1@oracle.com> Message-ID: Looks good. When looking at this patch, I realized that topdir has a different meaning depending on if you are in the HAS_SPEC conditional or not. In the first section, topdir is always the open root dir, but in the else section it is set to CUSTOM_ROOT if available. This is rather confusing. Could we unify the value of this variable? /Erik On 2018-03-06 01:23, Magnus Ihse Bursie wrote: > This fix will enable patch files for COMPARE_BUILD to be hosted in a > custom root. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199103 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199103-use-PATCH-in-COMPARE_BUILD-custom-root/webrev.01 > > /Magnus From erik.joelsson at oracle.com Tue Mar 6 14:49:24 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Mar 2018 06:49:24 -0800 Subject: RFR: JDK-8199103 Can't use COMPARE_BUILD with PATCH from custom root In-Reply-To: <353228d1-208b-ceb3-39e2-bce635e43fb1@oracle.com> References: <353228d1-208b-ceb3-39e2-bce635e43fb1@oracle.com> Message-ID: <234d03e5-09e9-ac99-af21-0f1813f11d3d@oracle.com> Looks good. When looking at this patch, I realized that topdir has a different meaning depending on if you are in the HAS_SPEC conditional or not. In the first section, topdir is always the open root dir, but in the else section it is set to CUSTOM_ROOT if available. This is rather confusing. Could we unify the value of this variable? /Erik On 2018-03-06 01:23, Magnus Ihse Bursie wrote: > This fix will enable patch files for COMPARE_BUILD to be hosted in a > custom root. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199103 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199103-use-PATCH-in-COMPARE_BUILD-custom-root/webrev.01 > > /Magnus From erik.joelsson at oracle.com Tue Mar 6 16:06:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Mar 2018 08:06:47 -0800 Subject: RFR: JDK-8199125: --disable-warnings-as-errors does not work for native jtreg test code Message-ID: In TestFilesCompilation.gmk we still add $(CFLAGS_WARNINGS_ARE_ERRORS) explicitly to CFLAGS. This is both redundant and wrong since we are now handling these flags automatically in the macro SetupNativeCompilation. The consequence is that --disable-warnings-as-errors won't work for jtreg tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8196458 Webrev: http://cr.openjdk.java.net/~erikj/8199125/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Tue Mar 6 16:24:21 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Mar 2018 17:24:21 +0100 Subject: RFR: JDK-8199103 Can't use COMPARE_BUILD with PATCH from custom root In-Reply-To: References: <353228d1-208b-ceb3-39e2-bce635e43fb1@oracle.com> Message-ID: <0c37763c-e3c0-bbb4-3314-4e3e82d19c4a@oracle.com> On 2018-03-06 15:59, Erik Joelsson wrote: > Looks good. > > When looking at this patch, I realized that topdir has a different > meaning depending on if you are in the HAS_SPEC conditional or not. In > the first section, topdir is always the open root dir, but in the else > section it is set to CUSTOM_ROOT if available. This is rather > confusing. Could we unify the value of this variable? I don't think we can unify them, since topdir in the first section is really TOPDIR (i.e. never the custom root), but found out differently than normal. (It is possible that it could be renamed TOPDIR, but I wanted to make it clear that it is not the "normal" value of TOPDIR). The second section has the meaning "TOPDIR or CUSTOM_ROOT", and is used only for COMPARE_BUILD. Do you have any suggestion on a good name? (TOPDIR_OR_CUSTOM_ROOT does not qualify as "good name", imho.) /Magnus > > /Erik > > > On 2018-03-06 01:23, Magnus Ihse Bursie wrote: >> This fix will enable patch files for COMPARE_BUILD to be hosted in a >> custom root. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199103 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8199103-use-PATCH-in-COMPARE_BUILD-custom-root/webrev.01 >> >> /Magnus > From magnus.ihse.bursie at oracle.com Tue Mar 6 16:25:23 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Mar 2018 17:25:23 +0100 Subject: RFR: JDK-8199125: --disable-warnings-as-errors does not work for native jtreg test code In-Reply-To: References: Message-ID: On 2018-03-06 17:06, Erik Joelsson wrote: > In TestFilesCompilation.gmk we still add $(CFLAGS_WARNINGS_ARE_ERRORS) > explicitly to CFLAGS. This is both redundant and wrong since we are > now handling these flags automatically in the macro > SetupNativeCompilation. The consequence is that > --disable-warnings-as-errors won't work for jtreg tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196458 > > Webrev: http://cr.openjdk.java.net/~erikj/8199125/webrev.01/ Looks good to me. /Magnus > > /Erik > From Derek.White at cavium.com Tue Mar 6 17:53:12 2018 From: Derek.White at cavium.com (White, Derek) Date: Tue, 6 Mar 2018 17:53:12 +0000 Subject: RFR: JDK-8199052 Configure broken on aarch64 Message-ID: Thanks for the quick fix Magnus! * Derek White From edward.nevill at gmail.com Wed Mar 7 09:05:00 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 07 Mar 2018 09:05:00 +0000 Subject: RFR: 8199152: Configure broken for arm 32 Message-ID: <1520413500.2363.3.camel@gmail.com> Hi, Please review the following change which fixes broken configuration for arm 32. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8199152 Webrev: http://cr.openjdk.java.net/~enevill/8199152/webrev.00/ The arm 32 configure is broken after the following changes https://bugs.openjdk.java.net/browse/JDK-8198724 http://hg.openjdk.java.net/jdk/jdk/rev/c04d813140dc https://bugs.openjdk.java.net/browse/JDK-8199052 http://hg.openjdk.java.net/jdk/jdk/rev/5d35b6050163 OK to push to jdk/jdk? Thanks, Ed. From magnus.ihse.bursie at oracle.com Wed Mar 7 12:43:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 7 Mar 2018 13:43:15 +0100 Subject: RFR: 8199152: Configure broken for arm 32 In-Reply-To: <1520413500.2363.3.camel@gmail.com> References: <1520413500.2363.3.camel@gmail.com> Message-ID: <6a9dc29c-d505-0ec5-c1d9-57586e6596b1@oracle.com> On 2018-03-07 10:05, Edward Nevill wrote: > Hi, > > Please review the following change which fixes broken configuration for > arm 32. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8199152 > Webrev: http://cr.openjdk.java.net/~enevill/8199152/webrev.00/ > > The arm 32 configure is broken after the following changes > > https://bugs.openjdk.java.net/browse/JDK-8198724 > http://hg.openjdk.java.net/jdk/jdk/rev/c04d813140dc > > https://bugs.openjdk.java.net/browse/JDK-8199052 > http://hg.openjdk.java.net/jdk/jdk/rev/5d35b6050163 > > OK to push to jdk/jdk? Fix looks good. Ok to push to jdk/jdk. I apologize for causing this mess. :( /Magnus > > Thanks, > Ed. > From magnus.ihse.bursie at oracle.com Wed Mar 7 14:02:27 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 7 Mar 2018 15:02:27 +0100 Subject: RFR: JDK-8199224 Refactor add_native_source in SetupNativeCompilation Message-ID: The function add_native_source has been with us since the original version of the build-infra system. It needs to be adapted to modern standards, and to have the flag setting unified so it happens in only one place. I have verified using BUILD_COMPARE that this does not affect the generated output. Bug: https://bugs.openjdk.java.net/browse/JDK-8199224 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199224-refactor-add_native_source/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Mar 7 16:28:13 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Mar 2018 08:28:13 -0800 Subject: RFR: JDK-8199224 Refactor add_native_source in SetupNativeCompilation In-Reply-To: References: Message-ID: <3f3a50ef-638a-41f7-f61f-081130c7627b@oracle.com> Looks good. Nice cleanup! /Erik On 2018-03-07 06:02, Magnus Ihse Bursie wrote: > The function add_native_source has been with us since the original > version of the build-infra system. It needs to be adapted to modern > standards, and to have the flag setting unified so it happens in only > one place. > > I have verified using BUILD_COMPARE that this does not affect the > generated output. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199224 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199224-refactor-add_native_source/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Wed Mar 7 17:06:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Mar 2018 09:06:32 -0800 Subject: RFR: JDK-8199197: Set _NT_SYMBOL_PATH when running tests on windows Message-ID: <7fcc6236-65ad-078f-7269-f8f7ec64022d@oracle.com> When running tests on Windows in a distributed environment we currently don't have access to debug symbols, which causes stack traces in hs_err files to be useless. When running local tests this works because the product under test was built on the same machine and the debug symbols are still available there. For this to work in distributed testing, we need to both provide the symbols bundle as well as setting up the _NT_SYMBOL_PATH environment variable to point to the correct directories. This patch does just that for both the old and new test makefiles. I have verified by running a modified jtreg test in Mach5 that crashes hotspot and verified that the stack trace contains symbols. Bug: https://bugs.openjdk.java.net/browse/JDK-8199197 Webrev: http://cr.openjdk.java.net/~erikj/8199197/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Wed Mar 7 18:19:03 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 7 Mar 2018 19:19:03 +0100 Subject: RFR: JDK-8199197: Set _NT_SYMBOL_PATH when running tests on windows In-Reply-To: <7fcc6236-65ad-078f-7269-f8f7ec64022d@oracle.com> References: <7fcc6236-65ad-078f-7269-f8f7ec64022d@oracle.com> Message-ID: <736dd1be-8007-6e36-8418-945be023334a@oracle.com> On 2018-03-07 18:06, Erik Joelsson wrote: > When running tests on Windows in a distributed environment we > currently don't have access to debug symbols, which causes stack > traces in hs_err files to be useless. When running local tests this > works because the product under test was built on the same machine and > the debug symbols are still available there. For this to work in > distributed testing, we need to both provide the symbols bundle as > well as setting up the _NT_SYMBOL_PATH environment variable to point > to the correct directories. This patch does just that for both the old > and new test makefiles. I have verified by running a modified jtreg > test in Mach5 that crashes hotspot and verified that the stack trace > contains symbols. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199197 > > Webrev: http://cr.openjdk.java.net/~erikj/8199197/webrev.01/ Looks good to me. Just one question: is the test profile already setup to depend on the symbols image? Otherwise I don't really understand how that can be assumed to be present? /Magnus > > /Erik > From erik.joelsson at oracle.com Wed Mar 7 18:42:00 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Mar 2018 10:42:00 -0800 Subject: RFR: JDK-8199197: Set _NT_SYMBOL_PATH when running tests on windows In-Reply-To: <736dd1be-8007-6e36-8418-945be023334a@oracle.com> References: <7fcc6236-65ad-078f-7269-f8f7ec64022d@oracle.com> <736dd1be-8007-6e36-8418-945be023334a@oracle.com> Message-ID: On 2018-03-07 10:19, Magnus Ihse Bursie wrote: > On 2018-03-07 18:06, Erik Joelsson wrote: >> When running tests on Windows in a distributed environment we >> currently don't have access to debug symbols, which causes stack >> traces in hs_err files to be useless. When running local tests this >> works because the product under test was built on the same machine >> and the debug symbols are still available there. For this to work in >> distributed testing, we need to both provide the symbols bundle as >> well as setting up the _NT_SYMBOL_PATH environment variable to point >> to the correct directories. This patch does just that for both the >> old and new test makefiles. I have verified by running a modified >> jtreg test in Mach5 that crashes hotspot and verified that the stack >> trace contains symbols. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199197 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8199197/webrev.01/ > Looks good to me. > > Just one question: is the test profile already setup to depend on the > symbols image? Otherwise I don't really understand how that can be > assumed to be present? > I'm adding the dependency on testedProfile.jdk_symbols if the build OS is Windows. /Erik > /Magnus > >> >> /Erik >> > From christian.tornqvist at oracle.com Wed Mar 7 19:11:37 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 7 Mar 2018 14:11:37 -0500 Subject: RFR: JDK-8199197: Set _NT_SYMBOL_PATH when running tests on windows In-Reply-To: <7fcc6236-65ad-078f-7269-f8f7ec64022d@oracle.com> References: <7fcc6236-65ad-078f-7269-f8f7ec64022d@oracle.com> Message-ID: Hi Erik, This looks good, many thanks for fixing this! Thanks, Christian > On Mar 7, 2018, at 12:06 32PM, Erik Joelsson wrote: > > When running tests on Windows in a distributed environment we currently don't have access to debug symbols, which causes stack traces in hs_err files to be useless. When running local tests this works because the product under test was built on the same machine and the debug symbols are still available there. For this to work in distributed testing, we need to both provide the symbols bundle as well as setting up the _NT_SYMBOL_PATH environment variable to point to the correct directories. This patch does just that for both the old and new test makefiles. I have verified by running a modified jtreg test in Mach5 that crashes hotspot and verified that the stack trace contains symbols. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199197 > > Webrev: http://cr.openjdk.java.net/~erikj/8199197/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Wed Mar 7 19:20:18 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 7 Mar 2018 20:20:18 +0100 Subject: RFR: JDK-8199197: Set _NT_SYMBOL_PATH when running tests on windows In-Reply-To: References: <7fcc6236-65ad-078f-7269-f8f7ec64022d@oracle.com> <736dd1be-8007-6e36-8418-945be023334a@oracle.com> Message-ID: > 7 mars 2018 kl. 19:42 skrev Erik Joelsson : > >> On 2018-03-07 10:19, Magnus Ihse Bursie wrote: >>> On 2018-03-07 18:06, Erik Joelsson wrote: >>> When running tests on Windows in a distributed environment we currently don't have access to debug symbols, which causes stack traces in hs_err files to be useless. When running local tests this works because the product under test was built on the same machine and the debug symbols are still available there. For this to work in distributed testing, we need to both provide the symbols bundle as well as setting up the _NT_SYMBOL_PATH environment variable to point to the correct directories. This patch does just that for both the old and new test makefiles. I have verified by running a modified jtreg test in Mach5 that crashes hotspot and verified that the stack trace contains symbols. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199197 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8199197/webrev.01/ >> Looks good to me. >> >> Just one question: is the test profile already setup to depend on the symbols image? Otherwise I don't really understand how that can be assumed to be present? > I'm adding the dependency on testedProfile.jdk_symbols if the build OS is Windows. So that is enough? I see. I just have this view of jib dependencies being more complicated than they probably really are. :) /Magnus > > /Erik >> /Magnus >> >>> >>> /Erik > From erik.joelsson at oracle.com Wed Mar 7 21:27:14 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Mar 2018 13:27:14 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> <2a55c71e-0df2-c4b9-e924-d36ec86e9582@oracle.com> <58e4c66d-d1e1-a84b-b027-0f50260da718@oracle.com> <069a9c40-ae21-8d65-a05c-6e1d475742e7@oracle.com> <13C31CF6-8246-4781-844F-673312BEFC57@oracle.com> <53b1eea5-aad4-f60e-e4fb-49f7d257312a@oracle.com> Message-ID: Thanks Kim, Tim, David and Magnus for reviews! /Erik On 2018-03-05 12:06, Erik Joelsson wrote: > New webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.04 > > /Erik > > > On 2018-03-05 12:03, Erik Joelsson wrote: >> >> On 2018-03-05 11:46, Kim Barrett wrote: >>> Old code in toolkit.m4 did the OBJDUMP stuff unconditionally. New >>> code makes it conditional on TOOLCHAIN_TYPE. >>> That doesn?t seem right.? compare.sh seems to want OBJDUMP for aix >>> too, and that?s not in the toolchain list here. >> That is a good point. I forgot about aix and was thinking more in the >> lines of not windows. Will restore the OBJDUMP code completely. >> >> /Erik > From erik.joelsson at oracle.com Wed Mar 7 21:24:13 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Mar 2018 13:24:13 -0800 Subject: RFR: JDK-8199266: Update boot and build jdk requirements in configure Message-ID: When we bumped the feature version from 10 to 11, we forgot to also update the required versions of the boot and build jdk. This is an easy mistake to do, so we should make sure it is easy and intuitive to do the update at the same time as updating the version number. This patch changes the check for build jdk to simply compare with the current VERSION_FEATURE. This should always be the correct requirement. The check for boot jdk is a bit more complicated. I initially thought we could calculate it automatically from VERSION_FEATURE-1, but until that version is actually released, we need to also allow VERSION_FEATURE-2. Because of this we will still require manual updating of this setting over time. So instead I moved the set of acceptable boot JDK versions to the version_numbers file. This should make it easy enough to spot and update when changing the DEFAULT_VERSION_FEATURE value. I also updated the build documentation regarding boot JDKs to explain temporary N-2 situation. While at it, I also updated the part about where to get JDK binaries since you can now download OpenJDK builds directly from jdk.java.net. Bug: https://bugs.openjdk.java.net/browse/JDK-8199266 Webrev: http://cr.openjdk.java.net/~erikj/8199266/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Wed Mar 7 22:12:04 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 7 Mar 2018 23:12:04 +0100 Subject: RFR: JDK-8199266: Update boot and build jdk requirements in configure In-Reply-To: References: Message-ID: <7f5b0d87-97c9-e33b-7669-47dd544d1e31@oracle.com> On 2018-03-07 22:24, Erik Joelsson wrote: > When we bumped the feature version from 10 to 11, we forgot to also > update the required versions of the boot and build jdk. This is an > easy mistake to do, so we should make sure it is easy and intuitive to > do the update at the same time as updating the version number. > > This patch changes the check for build jdk to simply compare with the > current VERSION_FEATURE. This should always be the correct requirement. > > The check for boot jdk is a bit more complicated. I initially thought > we could calculate it automatically from VERSION_FEATURE-1, but until > that version is actually released, we need to also allow > VERSION_FEATURE-2. Because of this we will still require manual > updating of this setting over time. So instead I moved the set of > acceptable boot JDK versions to the version_numbers file. This should > make it easy enough to spot and update when changing the > DEFAULT_VERSION_FEATURE value. > > I also updated the build documentation regarding boot JDKs to explain > temporary N-2 situation. While at it, I also updated the part about > where to get JDK binaries since you can now download OpenJDK builds > directly from jdk.java.net. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199266 > > Webrev: http://cr.openjdk.java.net/~erikj/8199266/webrev.01/ Looks good to me. /Magnus > > /Erik > From tim.bell at oracle.com Wed Mar 7 22:44:07 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 07 Mar 2018 14:44:07 -0800 Subject: RFR: JDK-8199266: Update boot and build jdk requirements in configure In-Reply-To: <7f5b0d87-97c9-e33b-7669-47dd544d1e31@oracle.com> References: <7f5b0d87-97c9-e33b-7669-47dd544d1e31@oracle.com> Message-ID: <5AA06B37.3020801@oracle.com> Erik: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199266 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8199266/webrev.01/ > Looks good to me. > > /Magnus Looks good to me as well. /Tim From vladimir.kozlov at oracle.com Wed Mar 7 23:23:28 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Mar 2018 15:23:28 -0800 Subject: [11] RFR(M) 8197235: src/hotspot/share/jvmci/jvmciCompilerToVM.cpp takes 4 minutes to compile on windows Message-ID: http://cr.openjdk.java.net/~kvn/8197235/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8197235 To avoid long compilation time of jvmciCompilerToVM.cpp I moved most expensive methods to new file jvmciCompilerToVMInit.cpp and switch off C++ compiler optimization for it on Windows and Solaris where the problem is seen. Changes are copy+paste of code from one file into an other. I also removed #include which are not required for compilation. The bug contains performance data. Ran pre-integration testing. -- Thanks, Vladimir From erik.joelsson at oracle.com Wed Mar 7 23:58:44 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Mar 2018 15:58:44 -0800 Subject: [11] RFR(M) 8197235: src/hotspot/share/jvmci/jvmciCompilerToVM.cpp takes 4 minutes to compile on windows In-Reply-To: References: Message-ID: Looks good to me. Thanks for fixing this! /Erik On 2018-03-07 15:23, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8197235/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8197235 > > To avoid long compilation time of jvmciCompilerToVM.cpp I moved most > expensive methods to new file jvmciCompilerToVMInit.cpp and switch off > C++ compiler optimization for it on Windows and Solaris where the > problem is seen. > > Changes are copy+paste of code from one file into an other. I also > removed #include which are not required for compilation. > > The bug contains performance data. > > Ran pre-integration testing. > From vladimir.kozlov at oracle.com Thu Mar 8 00:43:39 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Mar 2018 16:43:39 -0800 Subject: [11] RFR(M) 8197235: src/hotspot/share/jvmci/jvmciCompilerToVM.cpp takes 4 minutes to compile on windows In-Reply-To: References: Message-ID: Thank you, Eric Vladimir K On 3/7/18 3:58 PM, Erik Joelsson wrote: > Looks good to me. Thanks for fixing this! > > /Erik > > > On 2018-03-07 15:23, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8197235/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8197235 >> >> To avoid long compilation time of jvmciCompilerToVM.cpp I moved most >> expensive methods to new file jvmciCompilerToVMInit.cpp and switch off >> C++ compiler optimization for it on Windows and Solaris where the >> problem is seen. >> >> Changes are copy+paste of code from one file into an other. I also >> removed #include which are not required for compilation. >> >> The bug contains performance data. >> >> Ran pre-integration testing. >> > From david.holmes at oracle.com Thu Mar 8 05:35:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Mar 2018 15:35:40 +1000 Subject: RFR: JDK-8199266: Update boot and build jdk requirements in configure In-Reply-To: References: Message-ID: On 8/03/2018 7:24 AM, Erik Joelsson wrote: > When we bumped the feature version from 10 to 11, we forgot to also > update the required versions of the boot and build jdk. This is an easy > mistake to do, so we should make sure it is easy and intuitive to do the > update at the same time as updating the version number. We didn't forget to do it at all! It isn't yet possible to update the Boot JDK as you note below so it was left alone. As for the Build JDK ... I don't know what that is defined to be ?? David ----- > This patch changes the check for build jdk to simply compare with the > current VERSION_FEATURE. This should always be the correct requirement. > > The check for boot jdk is a bit more complicated. I initially thought we > could calculate it automatically from VERSION_FEATURE-1, but until that > version is actually released, we need to also allow VERSION_FEATURE-2. > Because of this we will still require manual updating of this setting > over time. So instead I moved the set of acceptable boot JDK versions to > the version_numbers file. This should make it easy enough to spot and > update when changing the DEFAULT_VERSION_FEATURE value. > > I also updated the build documentation regarding boot JDKs to explain > temporary N-2 situation. While at it, I also updated the part about > where to get JDK binaries since you can now download OpenJDK builds > directly from jdk.java.net. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199266 > > Webrev: http://cr.openjdk.java.net/~erikj/8199266/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Thu Mar 8 14:19:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Mar 2018 15:19:25 +0100 Subject: RFR: JDK-8199331 Don't limit debug information for fastdebug JDK native libraries Message-ID: <6F5E3C69-C973-444D-A270-E68630C6279F@oracle.com> Since long time ago, native libraries in JDK has been compiled with -g1 instead of -g, when doing a fastdebug build with gcc. (This does not apply to hotspot which is always compiled with -g.) This means that the debug information generated is limited. The gcc manual says this about level 1: "Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug. This includes descriptions of functions and external variables, and line number tables, but no information about local variables." The reason for doing this is claimed to be concerns over size. However, debug symbols images only increased from 129 MB to 135 MB with -g instead of -g1. This does not seem like a valid concern. As part of a general effort of simplifying and unifying the various options, I'd like to turn this to -g, so we have consistent debug capabilities regardless of build type. Bug: https://bugs.openjdk.java.net/browse/JDK-8199331 Patch inline: diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4 --- a/make/autoconf/flags-cflags.m4 +++ b/make/autoconf/flags-cflags.m4 @@ -108,11 +108,7 @@ [ # Debug symbols if test "x$TOOLCHAIN_TYPE" = xgcc; then - if test "x$OPENJDK_TARGET_CPU_BITS" = "x64" && test "x$DEBUG_LEVEL" = "xfastdebug"; then - CFLAGS_DEBUG_SYMBOLS="-g1" - else - CFLAGS_DEBUG_SYMBOLS="-g" - fi + CFLAGS_DEBUG_SYMBOLS="-g" elif test "x$TOOLCHAIN_TYPE" = xclang; then CFLAGS_DEBUG_SYMBOLS="-g" elif test "x$TOOLCHAIN_TYPE" = xsolstudio; then /Magnus From archana.nogriya at uk.ibm.com Thu Mar 8 14:51:40 2018 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Thu, 8 Mar 2018 14:51:40 +0000 Subject: Contribution to make/Docs.gmk Message-ID: Hi, In "make/Docs.gmk" We have found 2 issues which required to be fixed in OpenJDK, 1) -JDK_MODULES := $(sort $(DOCS_MODULES)) +JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), $(DOCS_MODULES))) ==> This is an OpenJDK bug as this should be filtering out the MODULES_FILTER modules... hence required contribute to OpenJDK... 2) -JVMTI_HTML := $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ FILES := $(JVMTI_HTML), \ DEST := $(DOCS_OUTPUTDIR)/specs, -)) -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) +#JVMTI_HTML := $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html +#$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, +# FILES := $(JVMTI_HTML), +# DEST := $(DOCS_OUTPUTDIR)/specs, +#)) +#JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) ==> We need to be able to unset/filterout the $(COPY_JVMTI_HTML) value in JDK_SPECS_TARGETS, if we get a "post" CustomIncludeExtension added at the end of Docs.gmk we can then the unset/filterout $(COPY_JVMTI_HTML) value. Hence OpenJDK contribution required. Please would like to hear other views on this fix and if we have better way of dealing this. Thanks and Regards Archana Nogriya IBM Java Runtime, Open Java Developer IBM Hursley Tel: Internal - 247073, External - +44 (0) 1962 81 7073 Office Mobile: 07500095480 Email: archana.nogriya at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From magnus.ihse.bursie at oracle.com Thu Mar 8 15:44:10 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Mar 2018 16:44:10 +0100 Subject: RFR: JDK-8199338 Use -g0 on solstudio also for compiling C programs Message-ID: <0AA0E334-CF0A-4136-9E4C-79005181A207@oracle.com> On solstudio, we have used -g for generating debug information when compiling C files, but -g0 when compiling C++ programs. This is due to the fact that -g, when compiling C++ programs, will prohibit inlining. We do not want that, since we build with debug symbols even in release builds, to get a proper debuginfo file per library. So, we must use -g0. And thus we must have different flags for generating debug symbols for C and C++... ... except that the C compiler also accepts -g0, which is an alias for -g. So we can use -g0 everywhere, and have things working like right now, but get the benefit of not having to separate C and C++ flags. I have verified locally using BUILD_COMPARE that we do not get any changes in the resulting binaries using this change on solaris. I am also currently running a compare build on all our platforms to verify that I do not break anything else. Bug: https://bugs.openjdk.java.net/browse/JDK-8199338 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199338-use-g0-on-solstudio-always/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Mar 8 15:48:48 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Mar 2018 07:48:48 -0800 Subject: RFR: JDK-8199266: Update boot and build jdk requirements in configure In-Reply-To: References: Message-ID: <9ca0cba5-2fe4-2784-598d-38d6ecc38185@oracle.com> Hello David, On 2018-03-07 21:35, David Holmes wrote: > On 8/03/2018 7:24 AM, Erik Joelsson wrote: >> When we bumped the feature version from 10 to 11, we forgot to also >> update the required versions of the boot and build jdk. This is an >> easy mistake to do, so we should make sure it is easy and intuitive >> to do the update at the same time as updating the version number. > > We didn't forget to do it at all! It isn't yet possible to update the > Boot JDK as you note below so it was left alone. > First of all, this is not an attack or critique on the version change effort for 11. What I'm trying to say is that the process is too complicated and error prone, and I'm trying to make it simpler. We weren't able to update the requirement for the boot JDK version to be N-1 (i.e. 10), but in configure we need to accept both N-1 and N as valid JDK versions. When bumping the JDK feature version we do need to update the configure check to also accept JDK version N (i.e. 11 in this case). With this change, updating the complete set of acceptable boot jdk versions becomes more obvious and easier to find. In the future, there will be two types of updates needed. When the JDK version is bumped, that number needs to be added to the set of acceptable boot JDK versions. Since that set is now explicitly listed in the same file, remembering to do so should be easy enough. When JDK N-1 is released, version N-2 needs to be removed from the set (along with making sure we switch to using the newly released JDK N-1 as boot everywhere). > As for the Build JDK ... I don't know what that is defined to be ?? > The build JDK is supposed to be the same as the current JDK version. I completely understand that this is not well known. I also forgot about it during the version bump process. This is why I'm making this change to have the build JDK version automatically derived so we don't need to worry about it in the future. /Erik > David > ----- > >> This patch changes the check for build jdk to simply compare with the >> current VERSION_FEATURE. This should always be the correct requirement. >> >> The check for boot jdk is a bit more complicated. I initially thought >> we could calculate it automatically from VERSION_FEATURE-1, but until >> that version is actually released, we need to also allow >> VERSION_FEATURE-2. Because of this we will still require manual >> updating of this setting over time. So instead I moved the set of >> acceptable boot JDK versions to the version_numbers file. This should >> make it easy enough to spot and update when changing the >> DEFAULT_VERSION_FEATURE value. >> >> I also updated the build documentation regarding boot JDKs to explain >> temporary N-2 situation. While at it, I also updated the part about >> where to get JDK binaries since you can now download OpenJDK builds >> directly from jdk.java.net. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199266 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8199266/webrev.01/ >> >> /Erik >> From erik.joelsson at oracle.com Thu Mar 8 16:06:15 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Mar 2018 08:06:15 -0800 Subject: RFR: JDK-8199338 Use -g0 on solstudio also for compiling C programs In-Reply-To: <0AA0E334-CF0A-4136-9E4C-79005181A207@oracle.com> References: <0AA0E334-CF0A-4136-9E4C-79005181A207@oracle.com> Message-ID: Looks good! /Erik On 2018-03-08 07:44, Magnus Ihse Bursie wrote: > On solstudio, we have used -g for generating debug information when compiling C files, but -g0 when compiling C++ programs. > > This is due to the fact that -g, when compiling C++ programs, will prohibit inlining. We do not want that, since we build with debug symbols even in release builds, to get a proper debuginfo file per library. So, we must use -g0. And thus we must have different flags for generating debug symbols for C and C++... > > ... except that the C compiler also accepts -g0, which is an alias for -g. So we can use -g0 everywhere, and have things working like right now, but get the benefit of not having to separate C and C++ flags. > > I have verified locally using BUILD_COMPARE that we do not get any changes in the resulting binaries using this change on solaris. I am also currently running a compare build on all our platforms to verify that I do not break anything else. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199338 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199338-use-g0-on-solstudio-always/webrev.01 > > /Magnus From erik.joelsson at oracle.com Thu Mar 8 16:03:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Mar 2018 08:03:32 -0800 Subject: RFR: JDK-8199331 Don't limit debug information for fastdebug JDK native libraries In-Reply-To: <6F5E3C69-C973-444D-A270-E68630C6279F@oracle.com> References: <6F5E3C69-C973-444D-A270-E68630C6279F@oracle.com> Message-ID: Looks good! /Erik On 2018-03-08 06:19, Magnus Ihse Bursie wrote: > Since long time ago, native libraries in JDK has been compiled with -g1 instead of -g, when doing a fastdebug build with gcc. (This does not apply to hotspot which is always compiled with -g.) > > This means that the debug information generated is limited. The gcc manual says this about level 1: > > "Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug. This includes descriptions of functions and external variables, and line number tables, but no information about local variables." > > The reason for doing this is claimed to be concerns over size. However, debug symbols images only increased from 129 MB to 135 MB with -g instead of -g1. This does not seem like a valid concern. > > As part of a general effort of simplifying and unifying the various options, I'd like to turn this to -g, so we have consistent debug capabilities regardless of build type. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199331 > Patch inline: > diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4 > --- a/make/autoconf/flags-cflags.m4 > +++ b/make/autoconf/flags-cflags.m4 > @@ -108,11 +108,7 @@ > [ > # Debug symbols > if test "x$TOOLCHAIN_TYPE" = xgcc; then > - if test "x$OPENJDK_TARGET_CPU_BITS" = "x64" && test "x$DEBUG_LEVEL" = "xfastdebug"; then > - CFLAGS_DEBUG_SYMBOLS="-g1" > - else > - CFLAGS_DEBUG_SYMBOLS="-g" > - fi > + CFLAGS_DEBUG_SYMBOLS="-g" > elif test "x$TOOLCHAIN_TYPE" = xclang; then > CFLAGS_DEBUG_SYMBOLS="-g" > elif test "x$TOOLCHAIN_TYPE" = xsolstudio; then > > /Magnus From erik.joelsson at oracle.com Thu Mar 8 16:00:44 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Mar 2018 08:00:44 -0800 Subject: Contribution to make/Docs.gmk In-Reply-To: References: Message-ID: <367bd275-76fa-4b6c-b041-98f3b7572a21@oracle.com> Hello, On 2018-03-08 06:51, Archana Nogriya wrote: > Hi, > > In "make/Docs.gmk" We have found 2 issues which required to be fixed in > OpenJDK, > > 1) > -JDK_MODULES := $(sort $(DOCS_MODULES)) > +JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), $(DOCS_MODULES))) > > ==> This is an OpenJDK bug as this should be filtering out the > MODULES_FILTER modules... hence required contribute to OpenJDK... Yes, this makes sense. The filter should apply here too. > 2) > -JVMTI_HTML := > $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html > -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ > > FILES := $(JVMTI_HTML), \ > DEST := $(DOCS_OUTPUTDIR)/specs, > -)) > -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) > +#JVMTI_HTML := > $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html > +#$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, > +# FILES := $(JVMTI_HTML), > +# DEST := $(DOCS_OUTPUTDIR)/specs, > +#)) > +#JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) > > ==> We need to be able to unset/filterout the $(COPY_JVMTI_HTML) value in > JDK_SPECS_TARGETS, if we get a "post" CustomIncludeExtension added at the > end of Docs.gmk we can then the unset/filterout $(COPY_JVMTI_HTML) value. > Hence OpenJDK contribution required. > Adding pre and post hooks to (almost) any .gmk file should not be a problem. It is the preferred solution here. /Erik > Please would like to hear other views on this fix and if we have better > way of dealing this. > > > Thanks and Regards > Archana Nogriya > IBM Java Runtime, Open Java Developer > IBM Hursley > Tel: Internal - 247073, External - +44 (0) 1962 81 7073 > Office Mobile: 07500095480 > Email: archana.nogriya at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From erik.joelsson at oracle.com Thu Mar 8 17:46:04 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Mar 2018 09:46:04 -0800 Subject: RFR: JDK-8199339: JDK-8198859 broke solaris x64 Message-ID: The change in JDK-8198859 unfortunately broke solaris x64. While we (at Oracle) aren't building this platform regularly anymore, we still have a weird dependency on it so need to keep it building for a while more. The simplest fix is to only do the elfedit on sparc. Bug: https://bugs.openjdk.java.net/browse/JDK-8199339 Patch: diff -r 28729cf7e4bc make/hotspot/lib/CompileDtracePostJvm.gmk --- a/make/hotspot/lib/CompileDtracePostJvm.gmk +++ b/make/hotspot/lib/CompileDtracePostJvm.gmk @@ -160,7 +160,9 @@ ???? ??? > $(DTRACE_SUPPORT_DIR)/$(@F).d)) ???? $(call ExecuteWithLog, $@, $(DTRACE) $(DTRACE_FLAGS) -o $@ \ ???? ??? -s $(DTRACE_SUPPORT_DIR)/$(@F).d) -??? $(call ExecuteWithLog, $@.elfedit, $(ELFEDIT) $(call GetElfeditCommands) $@) +??????? ifeq ($(OPENJDK_TARGET_CPU_ARCH), sparc) +??? ? $(call ExecuteWithLog, $@.elfedit, $(ELFEDIT) $(call GetElfeditCommands) $@) +??????? endif ############################################################################ ???? # Build the stand-alone dtrace libraries /Erik From magnus.ihse.bursie at oracle.com Thu Mar 8 17:53:44 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Mar 2018 18:53:44 +0100 Subject: RFR: JDK-8199339: JDK-8198859 broke solaris x64 In-Reply-To: References: Message-ID: <9D5FAA2B-3A10-4FDF-9862-2396C6F42E51@oracle.com> Looks good to me. /Magnus > 8 mars 2018 kl. 18:46 skrev Erik Joelsson : > > The change in JDK-8198859 unfortunately broke solaris x64. While we (at Oracle) aren't building this platform regularly anymore, we still have a weird dependency on it so need to keep it building for a while more. > > The simplest fix is to only do the elfedit on sparc. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199339 > > Patch: > > diff -r 28729cf7e4bc make/hotspot/lib/CompileDtracePostJvm.gmk > --- a/make/hotspot/lib/CompileDtracePostJvm.gmk > +++ b/make/hotspot/lib/CompileDtracePostJvm.gmk > @@ -160,7 +160,9 @@ > > $(DTRACE_SUPPORT_DIR)/$(@F).d)) > $(call ExecuteWithLog, $@, $(DTRACE) $(DTRACE_FLAGS) -o $@ \ > -s $(DTRACE_SUPPORT_DIR)/$(@F).d) > - $(call ExecuteWithLog, $@.elfedit, $(ELFEDIT) $(call GetElfeditCommands) $@) > + ifeq ($(OPENJDK_TARGET_CPU_ARCH), sparc) > + $(call ExecuteWithLog, $@.elfedit, $(ELFEDIT) $(call GetElfeditCommands) $@) > + endif > > ############################################################################ > # Build the stand-alone dtrace libraries > > > /Erik > From jonathan.gibbons at oracle.com Thu Mar 8 21:08:59 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Mar 2018 13:08:59 -0800 Subject: spurious line in output of make Message-ID: <5AA1A66B.3020705@oracle.com> This is in the main JDK repo: notice the second line, "ExecuteWithLog is" -- Jon Building targets 'jdk-image docs-jdk-api' in configuration 'linux-x86_64-normal-server-release' ExecuteWithLog is Finished building targets 'jdk-image docs-jdk-api' in configuration 'linux-x86_64-normal-server-release' From david.holmes at oracle.com Thu Mar 8 21:26:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Mar 2018 07:26:34 +1000 Subject: Contribution to make/Docs.gmk In-Reply-To: References: Message-ID: <602a6b5f-2ac9-615c-c166-1acf3ded9a44@oracle.com> Hi, On 9/03/2018 12:51 AM, Archana Nogriya wrote: > Hi, > > In "make/Docs.gmk" We have found 2 issues which required to be fixed in > OpenJDK, > > 1) > -JDK_MODULES := $(sort $(DOCS_MODULES)) > +JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), $(DOCS_MODULES))) > > ==> This is an OpenJDK bug as this should be filtering out the > MODULES_FILTER modules... hence required contribute to OpenJDK... > > 2) > -JVMTI_HTML := > $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html > -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ > > FILES := $(JVMTI_HTML), \ > DEST := $(DOCS_OUTPUTDIR)/specs, > -)) > -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) > +#JVMTI_HTML := > $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html > +#$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, > +# FILES := $(JVMTI_HTML), > +# DEST := $(DOCS_OUTPUTDIR)/specs, > +#)) > +#JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) > > ==> We need to be able to unset/filterout the $(COPY_JVMTI_HTML) value in > JDK_SPECS_TARGETS, if we get a "post" CustomIncludeExtension added at the > end of Docs.gmk we can then the unset/filterout $(COPY_JVMTI_HTML) value. > Hence OpenJDK contribution required. Why do you think the JVM TI specification should not be part of the JDK_SPECS_TARGET? Is this just because it is in the hotspot part of the source tree? David > Please would like to hear other views on this fix and if we have better > way of dealing this. > > > Thanks and Regards > Archana Nogriya > IBM Java Runtime, Open Java Developer > IBM Hursley > Tel: Internal - 247073, External - +44 (0) 1962 81 7073 > Office Mobile: 07500095480 > Email: archana.nogriya at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From erik.joelsson at oracle.com Thu Mar 8 22:08:12 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Mar 2018 14:08:12 -0800 Subject: RFR: JDK-8199352: The Jib artifact resolver in test lib needs to print better error messages Message-ID: <12e462a0-f0c7-c3eb-3e8f-8959d2fc355a@oracle.com> The Jib artifact resolver is not very good at telling us why things go wrong. The reason is that it swallows exceptions. This patch changes the API from throwing a FileNotFoundException, which I don't really think fits correctly in all cases, to a new API specific exception. I have greped for all uses of this API in the tests and changed the exception type caught at the caller location. I verified that I didn't break anything by compiling all the affected test classes and by running some of them for a bit. With these changes it should be easier to diagnose problems with resolving artifacts in the future. Bug: https://bugs.openjdk.java.net/browse/JDK-8199352 Webrev: http://cr.openjdk.java.net/~erikj/8199352/webrev.01/index.html /Erik From magnus.ihse.bursie at oracle.com Thu Mar 8 22:10:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Mar 2018 23:10:25 +0100 Subject: RFR: JDK-8199347 Always use -Z7 for debug symbols when compiling on Windows Message-ID: <6DE239FD-5B56-487A-AD81-1445A7560B96@oracle.com> For some time, we have used two different ways of handling debug symbols on Windows. Hotspot has been built using -Z7, and the JDK libraries using -Zi. -Z7 is preferable, since it does not create separate .pdb files for each source file; instead debug data is embedded in the .obj file, just like all other compilers do. This aligns better with the rest of the platforms. It also means we get rid of the mspdbsrv process, which serializes access to pdb files, and which has proven to be a bottleneck in certain situations. This does not mean that the end product is different: the linker still generates a .pdb file for the library/executable, and strip the debug information from the library/executable. This will also allow for some well-needed cleanups. With this change, hotspot and JDK libs finally build with the same debug symbol flags, and we can remove the hack that was introduced with the new hotspot build to override the debug symbol flags. Also, now that -Zi is ditched, we don't need the special handling of per-source-file pdb?s. I have verified on our build system using COMPARE_BUILD that this does not affect the generated output. Bug: https://bugs.openjdk.java.net/browse/JDK-8199347 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199347-use-Z7-for-debug-symbols/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Mar 8 22:13:30 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Mar 2018 14:13:30 -0800 Subject: RFR: JDK-8199347 Always use -Z7 for debug symbols when compiling on Windows In-Reply-To: <6DE239FD-5B56-487A-AD81-1445A7560B96@oracle.com> References: <6DE239FD-5B56-487A-AD81-1445A7560B96@oracle.com> Message-ID: Looks good. /Erik On 2018-03-08 14:10, Magnus Ihse Bursie wrote: > For some time, we have used two different ways of handling debug symbols on Windows. Hotspot has been built using -Z7, and the JDK libraries using -Zi. -Z7 is preferable, since it does not create separate .pdb files for each source file; instead debug data is embedded in the .obj file, just like all other compilers do. This aligns better with the rest of the platforms. It also means we get rid of the mspdbsrv process, which serializes access to pdb files, and which has proven to be a bottleneck in certain situations. > > This does not mean that the end product is different: the linker still generates a .pdb file for the library/executable, and strip the debug information from the library/executable. > > This will also allow for some well-needed cleanups. With this change, hotspot and JDK libs finally build with the same debug symbol flags, and we can remove the hack that was introduced with the new hotspot build to override the debug symbol flags. Also, now that -Zi is ditched, we don't need the special handling of per-source-file pdb?s. > > I have verified on our build system using COMPARE_BUILD that this does not affect the generated output. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199347 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199347-use-Z7-for-debug-symbols/webrev.01 > > /Magnus From igor.ignatyev at oracle.com Thu Mar 8 23:24:18 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 8 Mar 2018 15:24:18 -0800 Subject: RFR: JDK-8199352: The Jib artifact resolver in test lib needs to print better error messages In-Reply-To: <12e462a0-f0c7-c3eb-3e8f-8959d2fc355a@oracle.com> References: <12e462a0-f0c7-c3eb-3e8f-8959d2fc355a@oracle.com> Message-ID: Hi Erik, to avoid incompatibility, you could have just made ArtifactResolverException a subclass of java.io.FileNotFoundException. it seems you forgot to add ArtifactResolverException.java file to the repo. a minor nit: in JibArtifactManager::newInstance, you pass "Could not resolve " + JIB_SERVICE_FACTORY to ClassNotFoundException constructor. by the convention, the message in CNFE is the classname. -- Igor > On Mar 8, 2018, at 2:08 PM, Erik Joelsson wrote: > > The Jib artifact resolver is not very good at telling us why things go wrong. The reason is that it swallows exceptions. This patch changes the API from throwing a FileNotFoundException, which I don't really think fits correctly in all cases, to a new API specific exception. > > I have greped for all uses of this API in the tests and changed the exception type caught at the caller location. I verified that I didn't break anything by compiling all the affected test classes and by running some of them for a bit. > > With these changes it should be easier to diagnose problems with resolving artifacts in the future. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199352 > > Webrev: http://cr.openjdk.java.net/~erikj/8199352/webrev.01/index.html > > /Erik > From erik.joelsson at oracle.com Fri Mar 9 00:06:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Mar 2018 16:06:47 -0800 Subject: RFR: JDK-8199352: The Jib artifact resolver in test lib needs to print better error messages In-Reply-To: References: <12e462a0-f0c7-c3eb-3e8f-8959d2fc355a@oracle.com> Message-ID: <5c0f92b5-4f0d-9910-2495-cc5ec6d23b21@oracle.com> On 2018-03-08 15:24, Igor Ignatyev wrote: > Hi Erik, Thanks for looking at this! > to avoid incompatibility, you could have just made ArtifactResolverException a subclass of java.io.FileNotFoundException. This is correct, but I don't think the exception should be of type FileNotFoundException. IMO, this is something different and trying to re-purpose an existing exception type is rarely a good idea. > it seems you forgot to add ArtifactResolverException.java file to the repo. Doh! Added. > a minor nit: in JibArtifactManager::newInstance, you pass "Could not resolve " + JIB_SERVICE_FACTORY to ClassNotFoundException constructor. by the convention, the message in CNFE is the classname. Right, good point, fixed. New Webrev: http://cr.openjdk.java.net/~erikj/8199352/webrev.02/ /Erik > -- Igor > >> On Mar 8, 2018, at 2:08 PM, Erik Joelsson wrote: >> >> The Jib artifact resolver is not very good at telling us why things go wrong. The reason is that it swallows exceptions. This patch changes the API from throwing a FileNotFoundException, which I don't really think fits correctly in all cases, to a new API specific exception. >> >> I have greped for all uses of this API in the tests and changed the exception type caught at the caller location. I verified that I didn't break anything by compiling all the affected test classes and by running some of them for a bit. >> >> With these changes it should be easier to diagnose problems with resolving artifacts in the future. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199352 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8199352/webrev.01/index.html >> >> /Erik >> From igor.ignatyev at oracle.com Fri Mar 9 00:12:08 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 8 Mar 2018 16:12:08 -0800 Subject: RFR: JDK-8199352: The Jib artifact resolver in test lib needs to print better error messages In-Reply-To: <5c0f92b5-4f0d-9910-2495-cc5ec6d23b21@oracle.com> References: <12e462a0-f0c7-c3eb-3e8f-8959d2fc355a@oracle.com> <5c0f92b5-4f0d-9910-2495-cc5ec6d23b21@oracle.com> Message-ID: Looks good to me. -- Igor > On Mar 8, 2018, at 4:06 PM, Erik Joelsson wrote: > > On 2018-03-08 15:24, Igor Ignatyev wrote: >> Hi Erik, > Thanks for looking at this! >> to avoid incompatibility, you could have just made ArtifactResolverException a subclass of java.io.FileNotFoundException. > This is correct, but I don't think the exception should be of type FileNotFoundException. IMO, this is something different and trying to re-purpose an existing exception type is rarely a good idea. >> it seems you forgot to add ArtifactResolverException.java file to the repo. > Doh! Added. >> a minor nit: in JibArtifactManager::newInstance, you pass "Could not resolve " + JIB_SERVICE_FACTORY to ClassNotFoundException constructor. by the convention, the message in CNFE is the classname. > Right, good point, fixed. > > New Webrev: http://cr.openjdk.java.net/~erikj/8199352/webrev.02/ > > /Erik >> -- Igor >> >>> On Mar 8, 2018, at 2:08 PM, Erik Joelsson wrote: >>> >>> The Jib artifact resolver is not very good at telling us why things go wrong. The reason is that it swallows exceptions. This patch changes the API from throwing a FileNotFoundException, which I don't really think fits correctly in all cases, to a new API specific exception. >>> >>> I have greped for all uses of this API in the tests and changed the exception type caught at the caller location. I verified that I didn't break anything by compiling all the affected test classes and by running some of them for a bit. >>> >>> With these changes it should be easier to diagnose problems with resolving artifacts in the future. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199352 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8199352/webrev.01/index.html >>> >>> /Erik >>> > From magnus.ihse.bursie at oracle.com Fri Mar 9 07:53:24 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Mar 2018 08:53:24 +0100 Subject: RFR: JDK-8199352: The Jib artifact resolver in test lib needs to print better error messages In-Reply-To: <5c0f92b5-4f0d-9910-2495-cc5ec6d23b21@oracle.com> References: <12e462a0-f0c7-c3eb-3e8f-8959d2fc355a@oracle.com> <5c0f92b5-4f0d-9910-2495-cc5ec6d23b21@oracle.com> Message-ID: > 9 mars 2018 kl. 01:06 skrev Erik Joelsson : > >> On 2018-03-08 15:24, Igor Ignatyev wrote: >> Hi Erik, > Thanks for looking at this! >> to avoid incompatibility, you could have just made ArtifactResolverException a subclass of java.io.FileNotFoundException. > This is correct, but I don't think the exception should be of type FileNotFoundException. IMO, this is something different and trying to re-purpose an existing exception type is rarely a good idea. I agree. >> it seems you forgot to add ArtifactResolverException.java file to the repo. > Doh! Added. >> a minor nit: in JibArtifactManager::newInstance, you pass "Could not resolve " + JIB_SERVICE_FACTORY to ClassNotFoundException constructor. by the convention, the message in CNFE is the classname. > Right, good point, fixed. > > New Webrev: http://cr.openjdk.java.net/~erikj/8199352/webrev.02/ Looks good to me. /Magnus > > /Erik >> -- Igor >> >>> On Mar 8, 2018, at 2:08 PM, Erik Joelsson wrote: >>> >>> The Jib artifact resolver is not very good at telling us why things go wrong. The reason is that it swallows exceptions. This patch changes the API from throwing a FileNotFoundException, which I don't really think fits correctly in all cases, to a new API specific exception. >>> >>> I have greped for all uses of this API in the tests and changed the exception type caught at the caller location. I verified that I didn't break anything by compiling all the affected test classes and by running some of them for a bit. >>> >>> With these changes it should be easier to diagnose problems with resolving artifacts in the future. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199352 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8199352/webrev.01/index.html >>> >>> /Erik >>> > From magnus.ihse.bursie at oracle.com Fri Mar 9 11:29:57 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Mar 2018 12:29:57 +0100 Subject: RFR: JDK-8199405 Bump lowest supported gcc to 4.8 Message-ID: <8DBBED69-B2B7-4080-8A72-8C6F9179C393@oracle.com> If we bump the lowest supported version of gcc from 4.7 to 4.8, we can remove several checks in the configure script. Bug: https://bugs.openjdk.java.net/browse/JDK-8199405 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199405-bump-gcc-to-v4_8/webrev.01 /Magnus From archana.nogriya at uk.ibm.com Fri Mar 9 13:00:17 2018 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Fri, 9 Mar 2018 13:00:17 +0000 Subject: Contribution to make/Docs.gmk In-Reply-To: <602a6b5f-2ac9-615c-c166-1acf3ded9a44@oracle.com> References: <602a6b5f-2ac9-615c-c166-1acf3ded9a44@oracle.com> Message-ID: Thanks David, Erik for your response. JVMTI is a generic JVM debug specification, J9 has it's own version of it. As per J9 requirement, we might want to be able to do is filter out the above from JDK_SPECS_TARGETS, and add J9 one if it exists currently Docs.gmk I do not see .post custom extension point and to use our own version we need a way of doing it. Thanks and Regards Archana Nogriya IBM Java Runtime, Open Java Developer IBM Hursley Tel: Internal - 247073, External - +44 (0) 1962 81 7073 Office Mobile: 07500095480 Email: archana.nogriya at uk.ibm.com From: David Holmes To: Archana Nogriya , build-dev at openjdk.java.net Date: 08/03/2018 21:26 Subject: Re: Contribution to make/Docs.gmk Hi, On 9/03/2018 12:51 AM, Archana Nogriya wrote: > Hi, > > In "make/Docs.gmk" We have found 2 issues which required to be fixed in > OpenJDK, > > 1) > -JDK_MODULES := $(sort $(DOCS_MODULES)) > +JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), $(DOCS_MODULES))) > > ==> This is an OpenJDK bug as this should be filtering out the > MODULES_FILTER modules... hence required contribute to OpenJDK... > > 2) > -JVMTI_HTML := > $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html > -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ > > FILES := $(JVMTI_HTML), \ > DEST := $(DOCS_OUTPUTDIR)/specs, > -)) > -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) > +#JVMTI_HTML := > $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html > +#$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, > +# FILES := $(JVMTI_HTML), > +# DEST := $(DOCS_OUTPUTDIR)/specs, > +#)) > +#JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) > > ==> We need to be able to unset/filterout the $(COPY_JVMTI_HTML) value in > JDK_SPECS_TARGETS, if we get a "post" CustomIncludeExtension added at the > end of Docs.gmk we can then the unset/filterout $(COPY_JVMTI_HTML) value. > Hence OpenJDK contribution required. Why do you think the JVM TI specification should not be part of the JDK_SPECS_TARGET? Is this just because it is in the hotspot part of the source tree? David > Please would like to hear other views on this fix and if we have better > way of dealing this. > > > Thanks and Regards > Archana Nogriya > IBM Java Runtime, Open Java Developer > IBM Hursley > Tel: Internal - 247073, External - +44 (0) 1962 81 7073 > Office Mobile: 07500095480 > Email: archana.nogriya at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From magnus.ihse.bursie at oracle.com Fri Mar 9 14:37:10 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Mar 2018 15:37:10 +0100 Subject: RFR: JDK-8199403 Require binutils 2.18 or newer Message-ID: We have several checks for the behavior of a very old GNU binutil linker. If we instead require at least version 2.18 of binutils, we can remove these checks. For consistency, I have also added extraction of the linker version to the other toolchains/platforms I have access to. Bug: https://bugs.openjdk.java.net/browse/JDK-8199403 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199403-require-binutils-2_18/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 9 14:43:42 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Mar 2018 15:43:42 +0100 Subject: spurious line in output of make In-Reply-To: <5AA1A66B.3020705@oracle.com> References: <5AA1A66B.3020705@oracle.com> Message-ID: <15639272-5F8C-454C-AA39-102BC4939DDB@oracle.com> > 8 mars 2018 kl. 22:08 skrev Jonathan Gibbons : > > This is in the main JDK repo: notice the second line, "ExecuteWithLog is? My bad. :-( Despite Erik?s remark on the cod review, I missed removing the debug output. I opened https://bugs.openjdk.java.net/browse/JDK-8199416. /Magnus > > -- Jon > > Building targets 'jdk-image docs-jdk-api' in configuration 'linux-x86_64-normal-server-release' > ExecuteWithLog is > Finished building targets 'jdk-image docs-jdk-api' in configuration 'linux-x86_64-normal-server-release' > From magnus.ihse.bursie at oracle.com Fri Mar 9 14:45:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Mar 2018 15:45:35 +0100 Subject: RFR: JDK-8199416 Remove debug output left over since JDK-8198844 Message-ID: <329F8CEB-CEEA-4DF1-B999-72F1FA91F863@oracle.com> In JDK-8198844, I accidentally the whole debug output. Bug: https://bugs.openjdk.java.net/browse/JDK-8199416 Patch inline: diff --git a/make/gensrc/GensrcX11Wrappers.gmk b/make/gensrc/GensrcX11Wrappers.gmk --- a/make/gensrc/GensrcX11Wrappers.gmk +++ b/make/gensrc/GensrcX11Wrappers.gmk @@ -37,8 +37,6 @@ GENSRC_X11WRAPPERS_DATADIR := $(TOPDIR)/make/data/x11wrappergen GENSRC_X11WRAPPERS_DATA := $(GENSRC_X11WRAPPERS_DATADIR)/sizes-$(OPENJDK_TARGET_CPU_BITS).txt -$(info ExecuteWithLog is $(call ExecuteWithLog $(GENSRC_X11WRAPPERS_OUTPUT_TOP)/foobar, CMDLINE)) - # Run the tool on the offset files to generate several Java classes used in awt. $(GENSRC_X11WRAPPERS_MARKER): $(BUILD_TOOLS_JDK) $(GENSRC_X11WRAPPERS_DATA) \ $(GENSRC_X11WRAPPERS_DATADIR)/xlibtypes.txt /Magnus From erik.joelsson at oracle.com Fri Mar 9 15:51:02 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Mar 2018 07:51:02 -0800 Subject: RFR: JDK-8199405 Bump lowest supported gcc to 4.8 In-Reply-To: <8DBBED69-B2B7-4080-8A72-8C6F9179C393@oracle.com> References: <8DBBED69-B2B7-4080-8A72-8C6F9179C393@oracle.com> Message-ID: <7a63eac0-7c97-84a4-a768-07f53c7da209@oracle.com> I think this looks good. Hopefully nobody minds the version requirement bump. /Erik On 2018-03-09 03:29, Magnus Ihse Bursie wrote: > If we bump the lowest supported version of gcc from 4.7 to 4.8, we can remove several checks in the configure script. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199405 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199405-bump-gcc-to-v4_8/webrev.01 > > /Magnus From erik.joelsson at oracle.com Fri Mar 9 15:57:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Mar 2018 07:57:50 -0800 Subject: RFR: JDK-8199416 Remove debug output left over since JDK-8198844 In-Reply-To: <329F8CEB-CEEA-4DF1-B999-72F1FA91F863@oracle.com> References: <329F8CEB-CEEA-4DF1-B999-72F1FA91F863@oracle.com> Message-ID: <349c932a-3293-ed3f-a5b7-2e1e88616fd9@oracle.com> Looks good. /Erik On 2018-03-09 06:45, Magnus Ihse Bursie wrote: > In JDK-8198844, I accidentally the whole debug output. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199416 > Patch inline: > diff --git a/make/gensrc/GensrcX11Wrappers.gmk b/make/gensrc/GensrcX11Wrappers.gmk > --- a/make/gensrc/GensrcX11Wrappers.gmk > +++ b/make/gensrc/GensrcX11Wrappers.gmk > @@ -37,8 +37,6 @@ > GENSRC_X11WRAPPERS_DATADIR := $(TOPDIR)/make/data/x11wrappergen > GENSRC_X11WRAPPERS_DATA := $(GENSRC_X11WRAPPERS_DATADIR)/sizes-$(OPENJDK_TARGET_CPU_BITS).txt > > -$(info ExecuteWithLog is $(call ExecuteWithLog $(GENSRC_X11WRAPPERS_OUTPUT_TOP)/foobar, CMDLINE)) > - > # Run the tool on the offset files to generate several Java classes used in awt. > $(GENSRC_X11WRAPPERS_MARKER): $(BUILD_TOOLS_JDK) $(GENSRC_X11WRAPPERS_DATA) \ > $(GENSRC_X11WRAPPERS_DATADIR)/xlibtypes.txt > > /Magnus From erik.joelsson at oracle.com Fri Mar 9 15:57:30 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Mar 2018 07:57:30 -0800 Subject: RFR: JDK-8199403 Require binutils 2.18 or newer In-Reply-To: References: Message-ID: Looks good. /Erik On 2018-03-09 06:37, Magnus Ihse Bursie wrote: > We have several checks for the behavior of a very old GNU binutil linker. If we instead require at least version 2.18 of binutils, we can remove these checks. > > For consistency, I have also added extraction of the linker version to the other toolchains/platforms I have access to. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199403 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199403-require-binutils-2_18/webrev.01 > > /Magnus From tim.bell at oracle.com Fri Mar 9 16:06:27 2018 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 09 Mar 2018 08:06:27 -0800 Subject: RFR: JDK-8199403 Require binutils 2.18 or newer In-Reply-To: References: Message-ID: <5AA2B103.9020400@oracle.com> On 03/09/18 06:37, Magnus Ihse Bursie wrote: > We have several checks for the behavior of a very old GNU binutil linker. If we instead require at least version 2.18 of binutils, we can remove these checks. > > For consistency, I have also added extraction of the linker version to the other toolchains/platforms I have access to. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199403 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199403-require-binutils-2_18/webrev.01 Looks good. /Tim From erik.joelsson at oracle.com Fri Mar 9 19:32:24 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Mar 2018 11:32:24 -0800 Subject: RFR: JDK-8199423: Create builds-infra Mach5 job Message-ID: The open part of this change adds a few build infra specific Jib build profiles. Bug: https://bugs.openjdk.java.net/browse/JDK-8199423 Webrev: http://cr.openjdk.java.net/~erikj/8199423/webrev.01/ /Erik From tim.bell at oracle.com Fri Mar 9 20:45:53 2018 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 09 Mar 2018 12:45:53 -0800 Subject: RFR: JDK-8199423: Create builds-infra Mach5 job In-Reply-To: References: Message-ID: <5AA2F281.3060101@oracle.com> Erik: > The open part of this change adds a few build infra specific Jib build > profiles. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199423 > > Webrev: http://cr.openjdk.java.net/~erikj/8199423/webrev.01/ Looks good. /Tim From magnus.ihse.bursie at oracle.com Fri Mar 9 21:16:30 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Mar 2018 22:16:30 +0100 Subject: RFR: JDK-8199423: Create builds-infra Mach5 job In-Reply-To: References: Message-ID: > 9 mars 2018 kl. 20:32 skrev Erik Joelsson : > > The open part of this change adds a few build infra specific Jib build profiles. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199423 > > Webrev: http://cr.openjdk.java.net/~erikj/8199423/webrev.01/ Looks good to me. /Magnus > > /Erik > From philip.race at oracle.com Fri Mar 9 22:10:36 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 9 Mar 2018 14:10:36 -0800 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree Message-ID: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html This fix is will make building openjdk somewhat easier as it removes the dependence on an OpenJDK developer on Windows or Mac going off and downloading and building freetype source themselves .. or using XQuartz on Mac etc. It also means it will be somewhat easier for updating official OpenJDK builds to use a more modern freetype. The pre-compiled binary is a pain inside Oracle too. On Linux and Solaris platforms the build will still default to using the system installed freetype library. However this can easily be over-ridden by adding a configure parameter : --with-freetype=bundled The other valid option being "system" which, is of however never not valid on Windows or Mac. So --with-freetype include is no longer a path. The auto-discovery of the location of system library and headers has worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 But just in case it doesn't you can also still use --with-freetype-include and --with-freetype-lib which must both be specified and imply --with-freetype=system The docs have been updated to remove discussion of the obsoleted requirements Sharp eyes will also notice that it now makes Freetype the preferred rasteriser over the closed source T2K, even for Oracle JDK builds : http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html Since freetype != t2k there *will* be some very minor rasterization differences. Such cases are likely not a bug, but a feature :-) Since we previously and now mostly used GDI for LCD text on Windows and also generally defer to CoreText on Mac, the importance of the differences may not be great. But if you see any really bad rendering (I haven't) let me know. make/devkit/createMacosxDevkit6.sh is an empty diff .. I was proposing to remove the devkit references to freetype but it was suggested to leave that alone for now. 99% of the change is simply importing the freetype 2.9 files "as is" The UPDATING.txt file provides some background on the import process. I have built this every-which-way and tested it too .. it is of course possible there's a problem I've missed so try it out yourself if you can. -phil. From erik.joelsson at oracle.com Fri Mar 9 22:26:37 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Mar 2018 14:26:37 -0800 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> Message-ID: Build changes look good. /Erik On 2018-03-09 14:10, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 > Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html > > This fix is will make building openjdk somewhat easier as it removes > the dependence on an OpenJDK developer on Windows or Mac going > off and downloading and building freetype source themselves .. or > using XQuartz on Mac etc. > > It also means it will be somewhat easier for updating official OpenJDK > builds to use a more modern freetype. The pre-compiled binary is a pain > inside Oracle too. > > On Linux and Solaris platforms the build will still default to using > the system installed freetype library. However this can easily be > over-ridden by adding? a configure parameter : --with-freetype=bundled > The other valid option being "system" which, is of however never not > valid > on Windows? or Mac. So --with-freetype include is no longer a path. > The auto-discovery of the location of system library and headers has > worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 > > But just in case it doesn't you can also still use > --with-freetype-include and --with-freetype-lib > which must both be specified and imply --with-freetype=system > > The docs have been updated to remove discussion of the obsoleted > requirements > > Sharp eyes will also notice that it now makes Freetype the preferred > rasteriser > over the closed source T2K, even for Oracle JDK builds : > > http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html > > > Since freetype != t2k there *will* be some very minor rasterization > differences. > Such cases are likely not a bug, but a feature :-) > Since we previously and now mostly used GDI for LCD text on Windows and > also generally defer to CoreText on Mac, the importance of the > differences > may not be great. > But if you see any really bad rendering (I haven't) let me know. > > make/devkit/createMacosxDevkit6.sh is an empty diff? .. I was > proposing to remove the devkit references to freetype but it was > suggested > to leave that alone for now. > > 99% of the change is simply importing the freetype 2.9 files "as is" > The UPDATING.txt file provides some background on the import process. > > I have built this every-which-way and tested it too .. it is of course > possible > there's a problem I've missed so try it out yourself if you can. > > -phil. > > > > > > > From Sergey.Bylokhov at oracle.com Fri Mar 9 23:23:09 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 9 Mar 2018 15:23:09 -0800 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> Message-ID: <925e48d5-5253-7f68-ac59-e90e75e6bf1c@oracle.com> Hi, Phil Headers of the new files refer to LICENSE.TXT. Should we import it as well? On 09/03/2018 14:10, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 > Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html > > This fix is will make building openjdk somewhat easier as it removes > the dependence on an OpenJDK developer on Windows or Mac going > off and downloading and building freetype source themselves .. or > using XQuartz on Mac etc. > > It also means it will be somewhat easier for updating official OpenJDK > builds to use a more modern freetype. The pre-compiled binary is a pain > inside Oracle too. > > On Linux and Solaris platforms the build will still default to using > the system installed freetype library. However this can easily be > over-ridden by adding? a configure parameter : --with-freetype=bundled > The other valid option being "system" which, is of however never not valid > on Windows? or Mac. So --with-freetype include is no longer a path. > The auto-discovery of the location of system library and headers has > worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 > > But just in case it doesn't you can also still use > --with-freetype-include and --with-freetype-lib > which must both be specified and imply --with-freetype=system > > The docs have been updated to remove discussion of the obsoleted > requirements > > Sharp eyes will also notice that it now makes Freetype the preferred > rasteriser > over the closed source T2K, even for Oracle JDK builds : > > http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html > > > Since freetype != t2k there *will* be some very minor rasterization > differences. > Such cases are likely not a bug, but a feature :-) > Since we previously and now mostly used GDI for LCD text on Windows and > also generally defer to CoreText on Mac, the importance of the differences > may not be great. > But if you see any really bad rendering (I haven't) let me know. > > make/devkit/createMacosxDevkit6.sh is an empty diff? .. I was > proposing to remove the devkit references to freetype but it was suggested > to leave that alone for now. > > 99% of the change is simply importing the freetype 2.9 files "as is" > The UPDATING.txt file provides some background on the import process. > > I have built this every-which-way and tested it too .. it is of course > possible > there's a problem I've missed so try it out yourself if you can. > > -phil. > > > > > > > -- Best regards, Sergey. From philip.race at oracle.com Fri Mar 9 23:26:03 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 09 Mar 2018 15:26:03 -0800 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: <925e48d5-5253-7f68-ac59-e90e75e6bf1c@oracle.com> References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> <925e48d5-5253-7f68-ac59-e90e75e6bf1c@oracle.com> Message-ID: <5AA3180B.4000709@oracle.com> No. -phil. On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: > Hi, Phil > Headers of the new files refer to LICENSE.TXT. Should we import it as > well? > > On 09/03/2018 14:10, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 >> Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html >> >> This fix is will make building openjdk somewhat easier as it removes >> the dependence on an OpenJDK developer on Windows or Mac going >> off and downloading and building freetype source themselves .. or >> using XQuartz on Mac etc. >> >> It also means it will be somewhat easier for updating official OpenJDK >> builds to use a more modern freetype. The pre-compiled binary is a pain >> inside Oracle too. >> >> On Linux and Solaris platforms the build will still default to using >> the system installed freetype library. However this can easily be >> over-ridden by adding a configure parameter : --with-freetype=bundled >> The other valid option being "system" which, is of however never not >> valid >> on Windows or Mac. So --with-freetype include is no longer a path. >> The auto-discovery of the location of system library and headers has >> worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 >> >> But just in case it doesn't you can also still use >> --with-freetype-include and --with-freetype-lib >> which must both be specified and imply --with-freetype=system >> >> The docs have been updated to remove discussion of the obsoleted >> requirements >> >> Sharp eyes will also notice that it now makes Freetype the preferred >> rasteriser >> over the closed source T2K, even for Oracle JDK builds : >> >> http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html >> >> >> Since freetype != t2k there *will* be some very minor rasterization >> differences. >> Such cases are likely not a bug, but a feature :-) >> Since we previously and now mostly used GDI for LCD text on Windows and >> also generally defer to CoreText on Mac, the importance of the >> differences >> may not be great. >> But if you see any really bad rendering (I haven't) let me know. >> >> make/devkit/createMacosxDevkit6.sh is an empty diff .. I was >> proposing to remove the devkit references to freetype but it was >> suggested >> to leave that alone for now. >> >> 99% of the change is simply importing the freetype 2.9 files "as is" >> The UPDATING.txt file provides some background on the import process. >> >> I have built this every-which-way and tested it too .. it is of >> course possible >> there's a problem I've missed so try it out yourself if you can. >> >> -phil. >> >> >> >> >> >> >> > > From philip.race at oracle.com Fri Mar 9 23:28:46 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 09 Mar 2018 15:28:46 -0800 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: <5AA3180B.4000709@oracle.com> References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> <925e48d5-5253-7f68-ac59-e90e75e6bf1c@oracle.com> <5AA3180B.4000709@oracle.com> Message-ID: <5AA318AE.7070604@oracle.com> Just to be clear, I mean we don't import it to each of the source files. But it is there in the file legal/freetype.md in this webrev. On 3/9/18, 3:26 PM, Philip Race wrote: > > No. > > -phil. > > On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: >> Hi, Phil >> Headers of the new files refer to LICENSE.TXT. Should we import it as >> well? >> >> On 09/03/2018 14:10, Phil Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 >>> Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html >>> >>> This fix is will make building openjdk somewhat easier as it removes >>> the dependence on an OpenJDK developer on Windows or Mac going >>> off and downloading and building freetype source themselves .. or >>> using XQuartz on Mac etc. >>> >>> It also means it will be somewhat easier for updating official OpenJDK >>> builds to use a more modern freetype. The pre-compiled binary is a pain >>> inside Oracle too. >>> >>> On Linux and Solaris platforms the build will still default to using >>> the system installed freetype library. However this can easily be >>> over-ridden by adding a configure parameter : --with-freetype=bundled >>> The other valid option being "system" which, is of however never not >>> valid >>> on Windows or Mac. So --with-freetype include is no longer a path. >>> The auto-discovery of the location of system library and headers has >>> worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 >>> >>> But just in case it doesn't you can also still use >>> --with-freetype-include and --with-freetype-lib >>> which must both be specified and imply --with-freetype=system >>> >>> The docs have been updated to remove discussion of the obsoleted >>> requirements >>> >>> Sharp eyes will also notice that it now makes Freetype the preferred >>> rasteriser >>> over the closed source T2K, even for Oracle JDK builds : >>> >>> http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html >>> >>> >>> Since freetype != t2k there *will* be some very minor rasterization >>> differences. >>> Such cases are likely not a bug, but a feature :-) >>> Since we previously and now mostly used GDI for LCD text on Windows and >>> also generally defer to CoreText on Mac, the importance of the >>> differences >>> may not be great. >>> But if you see any really bad rendering (I haven't) let me know. >>> >>> make/devkit/createMacosxDevkit6.sh is an empty diff .. I was >>> proposing to remove the devkit references to freetype but it was >>> suggested >>> to leave that alone for now. >>> >>> 99% of the change is simply importing the freetype 2.9 files "as is" >>> The UPDATING.txt file provides some background on the import process. >>> >>> I have built this every-which-way and tested it too .. it is of >>> course possible >>> there's a problem I've missed so try it out yourself if you can. >>> >>> -phil. >>> >>> >>> >>> >>> >>> >>> >> >> From erik.joelsson at oracle.com Fri Mar 9 23:42:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Mar 2018 15:42:59 -0800 Subject: RFR: JDK-8199428: install-file macro fails on filenames with space on Solaris Message-ID: A while back I implemented support for handling filenames with space in them in the macros SetupCopyFiles and install-file. To verify this functionality I added tests to our test-make suite. These tests currently fail on Solaris. We currently don't use this functionality on Solaris, but keeping the tests passing is still preferable. The problem is when using the $(@D) and $(@<) variants to extract the directory or filename of the target or source file in a recipe, we first need to EncodeSpace, as otherwise the ? seems to be evaluating before the implicit $(dir) or $(notdir) is called. This patch adds those EncodeSpace calls and makes all the test-make tests pass on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8199428 Webrev: http://cr.openjdk.java.net/~erikj/8199428/webrev.01/ /Erik From Sergey.Bylokhov at oracle.com Fri Mar 9 23:49:37 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 9 Mar 2018 15:49:37 -0800 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: <5AA318AE.7070604@oracle.com> References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> <925e48d5-5253-7f68-ac59-e90e75e6bf1c@oracle.com> <5AA3180B.4000709@oracle.com> <5AA318AE.7070604@oracle.com> Message-ID: I am not an expert here, but the LICENSE.TXT is a little bit different. It states that "This means that *you* must choose *one* of the two licenses described below,.....". So I do not know should we select the license and provide the text only for one or for both. On 09/03/2018 15:28, Philip Race wrote: > Just to be clear, I mean we don't import it to each of the source files. > But it is there in the file legal/freetype.md in this webrev. > > On 3/9/18, 3:26 PM, Philip Race wrote: >> >> No. >> >> -phil. >> >> On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: >>> Hi, Phil >>> Headers of the new files refer to LICENSE.TXT. Should we import it as >>> well? >>> >>> On 09/03/2018 14:10, Phil Race wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 >>>> Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html >>>> >>>> This fix is will make building openjdk somewhat easier as it removes >>>> the dependence on an OpenJDK developer on Windows or Mac going >>>> off and downloading and building freetype source themselves .. or >>>> using XQuartz on Mac etc. >>>> >>>> It also means it will be somewhat easier for updating official OpenJDK >>>> builds to use a more modern freetype. The pre-compiled binary is a pain >>>> inside Oracle too. >>>> >>>> On Linux and Solaris platforms the build will still default to using >>>> the system installed freetype library. However this can easily be >>>> over-ridden by adding? a configure parameter : --with-freetype=bundled >>>> The other valid option being "system" which, is of however never not >>>> valid >>>> on Windows? or Mac. So --with-freetype include is no longer a path. >>>> The auto-discovery of the location of system library and headers has >>>> worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 >>>> >>>> But just in case it doesn't you can also still use >>>> --with-freetype-include and --with-freetype-lib >>>> which must both be specified and imply --with-freetype=system >>>> >>>> The docs have been updated to remove discussion of the obsoleted >>>> requirements >>>> >>>> Sharp eyes will also notice that it now makes Freetype the preferred >>>> rasteriser >>>> over the closed source T2K, even for Oracle JDK builds : >>>> >>>> http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html >>>> >>>> >>>> Since freetype != t2k there *will* be some very minor rasterization >>>> differences. >>>> Such cases are likely not a bug, but a feature :-) >>>> Since we previously and now mostly used GDI for LCD text on Windows and >>>> also generally defer to CoreText on Mac, the importance of the >>>> differences >>>> may not be great. >>>> But if you see any really bad rendering (I haven't) let me know. >>>> >>>> make/devkit/createMacosxDevkit6.sh is an empty diff? .. I was >>>> proposing to remove the devkit references to freetype but it was >>>> suggested >>>> to leave that alone for now. >>>> >>>> 99% of the change is simply importing the freetype 2.9 files "as is" >>>> The UPDATING.txt file provides some background on the import process. >>>> >>>> I have built this every-which-way and tested it too .. it is of >>>> course possible >>>> there's a problem I've missed so try it out yourself if you can. >>>> >>>> -phil. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- Best regards, Sergey. From philip.race at oracle.com Fri Mar 9 23:52:41 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 09 Mar 2018 15:52:41 -0800 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> <925e48d5-5253-7f68-ac59-e90e75e6bf1c@oracle.com> <5AA3180B.4000709@oracle.com> <5AA318AE.7070604@oracle.com> Message-ID: <5AA31E49.9070002@oracle.com> It is correct as is .. -phil. On 3/9/18, 3:49 PM, Sergey Bylokhov wrote: > I am not an expert here, but the LICENSE.TXT is a little bit different. > It states that "This means that *you* must choose *one* of the two > licenses described below,.....". > So I do not know should we select the license and provide the text > only for one or for both. > > On 09/03/2018 15:28, Philip Race wrote: >> Just to be clear, I mean we don't import it to each of the source files. >> But it is there in the file legal/freetype.md in this webrev. >> >> On 3/9/18, 3:26 PM, Philip Race wrote: >>> >>> No. >>> >>> -phil. >>> >>> On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: >>>> Hi, Phil >>>> Headers of the new files refer to LICENSE.TXT. Should we import it >>>> as well? >>>> >>>> On 09/03/2018 14:10, Phil Race wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 >>>>> Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html >>>>> >>>>> This fix is will make building openjdk somewhat easier as it removes >>>>> the dependence on an OpenJDK developer on Windows or Mac going >>>>> off and downloading and building freetype source themselves .. or >>>>> using XQuartz on Mac etc. >>>>> >>>>> It also means it will be somewhat easier for updating official >>>>> OpenJDK >>>>> builds to use a more modern freetype. The pre-compiled binary is a >>>>> pain >>>>> inside Oracle too. >>>>> >>>>> On Linux and Solaris platforms the build will still default to using >>>>> the system installed freetype library. However this can easily be >>>>> over-ridden by adding a configure parameter : >>>>> --with-freetype=bundled >>>>> The other valid option being "system" which, is of however never >>>>> not valid >>>>> on Windows or Mac. So --with-freetype include is no longer a path. >>>>> The auto-discovery of the location of system library and headers has >>>>> worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 >>>>> >>>>> But just in case it doesn't you can also still use >>>>> --with-freetype-include and --with-freetype-lib >>>>> which must both be specified and imply --with-freetype=system >>>>> >>>>> The docs have been updated to remove discussion of the obsoleted >>>>> requirements >>>>> >>>>> Sharp eyes will also notice that it now makes Freetype the >>>>> preferred rasteriser >>>>> over the closed source T2K, even for Oracle JDK builds : >>>>> >>>>> http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html >>>>> >>>>> >>>>> Since freetype != t2k there *will* be some very minor >>>>> rasterization differences. >>>>> Such cases are likely not a bug, but a feature :-) >>>>> Since we previously and now mostly used GDI for LCD text on >>>>> Windows and >>>>> also generally defer to CoreText on Mac, the importance of the >>>>> differences >>>>> may not be great. >>>>> But if you see any really bad rendering (I haven't) let me know. >>>>> >>>>> make/devkit/createMacosxDevkit6.sh is an empty diff .. I was >>>>> proposing to remove the devkit references to freetype but it was >>>>> suggested >>>>> to leave that alone for now. >>>>> >>>>> 99% of the change is simply importing the freetype 2.9 files "as is" >>>>> The UPDATING.txt file provides some background on the import process. >>>>> >>>>> I have built this every-which-way and tested it too .. it is of >>>>> course possible >>>>> there's a problem I've missed so try it out yourself if you can. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> > > From tim.bell at oracle.com Fri Mar 9 23:50:18 2018 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 09 Mar 2018 15:50:18 -0800 Subject: RFR: JDK-8199428: install-file macro fails on filenames with space on Solaris In-Reply-To: References: Message-ID: <5AA31DBA.90702@oracle.com> Erik: > This patch adds those EncodeSpace calls and makes all the test-make > tests pass on Solaris. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199428 > > Webrev: http://cr.openjdk.java.net/~erikj/8199428/webrev.01/ Looks good. Tim From thomas.stuefe at gmail.com Sat Mar 10 07:55:09 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 10 Mar 2018 08:55:09 +0100 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> Message-ID: Hi Phil, This is a nice change! And will make setting up the windows build env much easier. Change itself seems fine at a cursory glance. I also tested the build on Win7 with VS2013 (before, I used to build with a hand-compiled version of the freetypelib), and it worked fine. I attempted to test the 32bit build but that seems to have bitrotted, I ran into errors not having anything to do with your change. Best Regards, Thomas On Fri, Mar 9, 2018 at 11:10 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 > Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html > > This fix is will make building openjdk somewhat easier as it removes > the dependence on an OpenJDK developer on Windows or Mac going > off and downloading and building freetype source themselves .. or > using XQuartz on Mac etc. > > It also means it will be somewhat easier for updating official OpenJDK > builds to use a more modern freetype. The pre-compiled binary is a pain > inside Oracle too. > > On Linux and Solaris platforms the build will still default to using > the system installed freetype library. However this can easily be > over-ridden by adding a configure parameter : --with-freetype=bundled > The other valid option being "system" which, is of however never not valid > on Windows or Mac. So --with-freetype include is no longer a path. > The auto-discovery of the location of system library and headers has > worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 > > But just in case it doesn't you can also still use > --with-freetype-include and --with-freetype-lib > which must both be specified and imply --with-freetype=system > > The docs have been updated to remove discussion of the obsoleted > requirements > > Sharp eyes will also notice that it now makes Freetype the preferred > rasteriser > over the closed source T2K, even for Oracle JDK builds : > > http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/sha > re/classes/sun/font/FontScaler.java.sdiff.html > > Since freetype != t2k there *will* be some very minor rasterization > differences. > Such cases are likely not a bug, but a feature :-) > Since we previously and now mostly used GDI for LCD text on Windows and > also generally defer to CoreText on Mac, the importance of the differences > may not be great. > But if you see any really bad rendering (I haven't) let me know. > > make/devkit/createMacosxDevkit6.sh is an empty diff .. I was > proposing to remove the devkit references to freetype but it was suggested > to leave that alone for now. > > 99% of the change is simply importing the freetype 2.9 files "as is" > The UPDATING.txt file provides some background on the import process. > > I have built this every-which-way and tested it too .. it is of course > possible > there's a problem I've missed so try it out yourself if you can. > > -phil. > > > > > > > > From thomas.stuefe at gmail.com Sat Mar 10 07:58:09 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 10 Mar 2018 08:58:09 +0100 Subject: win 32bit build: configure cannot resolve 32bit crt. Message-ID: Hi, did anyone build 32bit windows recently? I get the following configure error: .. POSSIBLE_MSVC_DLL /cygdrive/c/Program POSSIBLE_MSVC_DLL Files POSSIBLE_MSVC_DLL (x86)/Microsoft POSSIBLE_MSVC_DLL Visual POSSIBLE_MSVC_DLL Studio POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll configure: Found msvcr120.dll at /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in SYSTEMROOT checking found msvcr120.dll architecture... incorrect, ignoring configure: The file type of the located msvcr120.dll is PE32+ executable (DLL) (GUI) x86-64, for MS Windows configure: Found msvcr120.dll at /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using search of VCINSTALLDIR checking found msvcr120.dll architecture... incorrect, ignoring configure: The file type of the located msvcr120.dll is PE32 executable (DLL) (GUI) ARMv7 Thumb, for MS Windows checking for msvcr120.dll... no configure: error: Could not find msvcr120.dll. Please specify using --with-msvcr-dll. configure exiting with result code 1 ... I am building the jdk-hs repo on WIndows 7 with VS 2013 Premium ed. Update 5. My configure options are: --with-boot-jdk=/cygdrive/c/mine/projects/openjdk/jdks/openjdk9 --with-target-bits=32 --with-debug-level=slowdebug --with-native-debug-symbols=external Kind Regards, Thomas From magnus.ihse.bursie at oracle.com Sat Mar 10 08:46:10 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 10 Mar 2018 09:46:10 +0100 Subject: RFR: JDK-8199428: install-file macro fails on filenames with space on Solaris In-Reply-To: References: Message-ID: Looks good to me. /Magnus > 10 mars 2018 kl. 00:42 skrev Erik Joelsson : > > A while back I implemented support for handling filenames with space in them in the macros SetupCopyFiles and install-file. To verify this functionality I added tests to our test-make suite. These tests currently fail on Solaris. We currently don't use this functionality on Solaris, but keeping the tests passing is still preferable. > > The problem is when using the $(@D) and $(@<) variants to extract the directory or filename of the target or source file in a recipe, we first need to EncodeSpace, as otherwise the ? seems to be evaluating before the implicit $(dir) or $(notdir) is called. > > This patch adds those EncodeSpace calls and makes all the test-make tests pass on Solaris. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199428 > > Webrev: http://cr.openjdk.java.net/~erikj/8199428/webrev.01/ > > /Erik > From philip.race at oracle.com Sat Mar 10 16:35:00 2018 From: philip.race at oracle.com (Philip Race) Date: Sat, 10 Mar 2018 08:35:00 -0800 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> Message-ID: <5AA40934.5010306@oracle.com> This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any platform for the new releases, then there aren't resources or effort being put into making sure it still builds. Our build systems might still support it, but for how long? It might effectively have to become a "port" that someone outside will step up to maintain. Not as different as AIX .. or as much effort perhaps .. but if someone will do that I expect patches would not be refused. -phil. On 3/9/18, 11:55 PM, Thomas St?fe wrote: > I attempted to test the 32bit build but that seems to have bitrotted, > I ran into errors not having anything to do with your change. From david.holmes at oracle.com Mon Mar 12 02:20:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Mar 2018 12:20:01 +1000 Subject: Contribution to make/Docs.gmk In-Reply-To: References: <602a6b5f-2ac9-615c-c166-1acf3ded9a44@oracle.com> Message-ID: <963d41da-904f-1119-cc6c-a2937e66a87e@oracle.com> On 9/03/2018 11:00 PM, Archana Nogriya wrote: > Thanks David, Erik for your response. > > JVMTI is a generic JVM debug specification, J9 has it's own version of it. Not quite sure what you mean there. The JVM TI specification is the JVM TI specification: https://docs.oracle.com/javase/9/docs/specs/jvmti.html Implementations of it can vary and support, or not, different parts, but the spec is the spec. David ----- > As per J9 requirement, we might want to be able to do is filter out the > above from JDK_SPECS_TARGETS, and add J9 one if it exists > currently Docs.gmk I do not see .post custom extension point and to use > our own version we need a way of doing it. > > > > > Thanks and Regards > Archana Nogriya > IBM Java Runtime, Open Java Developer > IBM Hursley > Tel: Internal - 247073, External - +44 (0) 1962 81 7073 > Office Mobile: 07500095480 > Email: archana.nogriya at uk.ibm.com > > > > From: David Holmes > To: Archana Nogriya , > build-dev at openjdk.java.net > Date: 08/03/2018 21:26 > Subject: Re: Contribution to make/Docs.gmk > ------------------------------------------------------------------------ > > > > Hi, > > On 9/03/2018 12:51 AM, Archana Nogriya wrote: >> Hi, >> >> In "make/Docs.gmk" We have found 2 issues which required to be fixed in >> OpenJDK, >> >> 1) >> -JDK_MODULES := $(sort $(DOCS_MODULES)) >> +JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), $(DOCS_MODULES))) >> >> ==> This is an OpenJDK bug as this should be filtering out the >> MODULES_FILTER modules... hence required contribute to OpenJDK... >> >> 2) >> -JVMTI_HTML := >> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html >> -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ >> >> ? ? ? ? ?FILES := $(JVMTI_HTML), \ >> ? ? ? ? ?DEST := $(DOCS_OUTPUTDIR)/specs, >> -)) >> -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) >> +#JVMTI_HTML := >> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html >> +#$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, >> +# FILES := $(JVMTI_HTML), >> +# DEST := $(DOCS_OUTPUTDIR)/specs, >> +#)) >> +#JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) >> >> ==> We need to be able to unset/filterout the $(COPY_JVMTI_HTML) value in >> JDK_SPECS_TARGETS, if we get a "post" CustomIncludeExtension added at the >> end of Docs.gmk we can then the unset/filterout $(COPY_JVMTI_HTML) value. >> Hence OpenJDK contribution required. > > Why do you think the JVM TI specification should not be part of the > JDK_SPECS_TARGET? Is this just because it is in the hotspot part of the > source tree? > > David > >> Please would like to hear other views on this fix and if we have better >> way of dealing this. >> >> >> Thanks and Regards >> Archana Nogriya >> IBM Java Runtime, Open Java Developer >> IBM Hursley >> Tel: Internal - 247073, External - +44 (0) 1962 81 7073 >> Office Mobile: 07500095480 >> Email: archana.nogriya at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From thomas.stuefe at gmail.com Mon Mar 12 07:02:33 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Mar 2018 08:02:33 +0100 Subject: =?UTF-8?Q?jdk_build_fails_due_to_=22warning=3A_=E2=80=98readdir=5Fr=E2=80=99_is_?= =?UTF-8?Q?deprecated=22?= Message-ID: Hi all, maybe someone has an idea: I build on a freshly installed Linux instance (MX17), using gcc 6.3.0. I get this error: Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s) /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c: In function ?read_dir?: /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:83:5: warning: ?readdir_r? is deprecated [-Wdeprecated-declarations] if (readdir_r(dirp, entry, &p) == 0) { ^~ In file included from /shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0, from /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32, from /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:29: /usr/include/dirent.h:183:12: note: declared here extern int readdir_r (DIR *__restrict __dirp, ^~~~~~~~~ I digged and was not able to pin it to any recent change. I also think I never successfully built on this box, so it may be my environment. Could it be that my gcc is too new? Thanks! Thomas From david.holmes at oracle.com Mon Mar 12 07:15:38 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Mar 2018 17:15:38 +1000 Subject: =?UTF-8?Q?Re:_jdk_build_fails_due_to_=22warning:_=e2=80=98readdir?= =?UTF-8?B?X3LigJkgaXMgZGVwcmVjYXRlZCI=?= In-Reply-To: References: Message-ID: Hi Thomas, On 12/03/2018 5:02 PM, Thomas St?fe wrote: > Hi all, > > maybe someone has an idea: > > I build on a freshly installed Linux instance (MX17), using gcc 6.3.0. > > I get this error: > > Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s) > /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c: > In function ?read_dir?: > /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:83:5: > warning: ?readdir_r? is deprecated [-Wdeprecated-declarations] > if (readdir_r(dirp, entry, &p) == 0) { > ^~ > In file included from > /shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0, > from > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32, > from > /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:29: > /usr/include/dirent.h:183:12: note: declared here > extern int readdir_r (DIR *__restrict __dirp, > ^~~~~~~~~ > > I digged and was not able to pin it to any recent change. I also think I > never successfully built on this box, so it may be my environment. > > Could it be that my gcc is too new? We've built with gcc 7 so it can't be that on its own. May be a combination of gcc and glibc version. It was deprecated in glibc 2.24. David > Thanks! Thomas > From thomas.stuefe at gmail.com Mon Mar 12 07:25:07 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Mar 2018 08:25:07 +0100 Subject: =?UTF-8?Q?Re=3A_jdk_build_fails_due_to_=22warning=3A_=E2=80=98readdir=5Fr=E2=80=99?= =?UTF-8?Q?_is_deprecated=22?= In-Reply-To: References: Message-ID: Thank you for the infos, David, I will keep looking. (This is basically a modern Debian breed, I am surprised this gives me trouble...) ..Thomas On Mon, Mar 12, 2018 at 8:15 AM, David Holmes wrote: > Hi Thomas, > > On 12/03/2018 5:02 PM, Thomas St?fe wrote: > >> Hi all, >> >> maybe someone has an idea: >> >> I build on a freshly installed Linux instance (MX17), using gcc 6.3.0. >> >> I get this error: >> >> Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s) >> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un >> ix/native/libmanagement_ext/OperatingSystemImpl.c: >> In function ?read_dir?: >> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un >> ix/native/libmanagement_ext/OperatingSystemImpl.c:83:5: >> warning: ?readdir_r? is deprecated [-Wdeprecated-declarations] >> if (readdir_r(dirp, entry, &p) == 0) { >> ^~ >> In file included from >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/ >> include/jvm_md.h:34:0, >> from >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/inc >> lude/jvm.h:32, >> from >> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un >> ix/native/libmanagement_ext/OperatingSystemImpl.c:29: >> /usr/include/dirent.h:183:12: note: declared here >> extern int readdir_r (DIR *__restrict __dirp, >> ^~~~~~~~~ >> >> I digged and was not able to pin it to any recent change. I also think I >> never successfully built on this box, so it may be my environment. >> >> Could it be that my gcc is too new? >> > > We've built with gcc 7 so it can't be that on its own. May be a > combination of gcc and glibc version. It was deprecated in glibc 2.24. > > David > > Thanks! Thomas >> >> From david.holmes at oracle.com Mon Mar 12 07:26:00 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Mar 2018 17:26:00 +1000 Subject: =?UTF-8?Q?Re:_jdk_build_fails_due_to_=22warning:_=e2=80=98readdir?= =?UTF-8?B?X3LigJkgaXMgZGVwcmVjYXRlZCI=?= In-Reply-To: References: Message-ID: We already dealt with this in the VM: http://hg.openjdk.java.net/jdk10/master/rev/f5f2a2d13775 by disabling the warning. That suggests to me that this warning must have been disabled in the JDK build too. So perhaps recent flag reworking has modified that. ?? David On 12/03/2018 5:15 PM, David Holmes wrote: > Hi Thomas, > > On 12/03/2018 5:02 PM, Thomas St?fe wrote: >> Hi all, >> >> maybe someone has an idea: >> >> I build on a freshly installed Linux instance (MX17), using gcc 6.3.0. >> >> I get this error: >> >> Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s) >> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c: >> >> In function ?read_dir?: >> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:83:5: >> >> warning: ?readdir_r? is deprecated [-Wdeprecated-declarations] >> ????? if (readdir_r(dirp, entry, &p) == 0) { >> ????? ^~ >> In file included from >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0, >> >> ????????????????? from >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32, >> >> ????????????????? from >> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:29: >> >> /usr/include/dirent.h:183:12: note: declared here >> ? extern int readdir_r (DIR *__restrict __dirp, >> ???????????? ^~~~~~~~~ >> >> I digged and was not able to pin it to any recent change. I also think? I >> never successfully built on this box, so it may be my environment. >> >> Could it be that my gcc is too new? > > We've built with gcc 7 so it can't be that on its own. May be a > combination of gcc and glibc version. It was deprecated in glibc 2.24. > > David > >> Thanks! Thomas >> From thomas.stuefe at gmail.com Mon Mar 12 07:45:44 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Mar 2018 08:45:44 +0100 Subject: =?UTF-8?Q?Re=3A_jdk_build_fails_due_to_=22warning=3A_=E2=80=98readdir=5Fr=E2=80=99?= =?UTF-8?Q?_is_deprecated=22?= In-Reply-To: References: Message-ID: Thanks a lot for digging this up! That may very well be. I see that we locally disable the warning in os_linux.inline.hpp. My error happens when compiling the jdk, among others TimeZone_md.c. I do not see that we pass -Wdeprecated-declarations. I am still unsure whether this is a new issue or an existing one I uncovered in by environment. Unfortunately I have to drive to the office now and will then be back in gcc 4.8 land. Have to pick this up again next weekend (or just install a saner Linux). Thank you! Thomas On Mon, Mar 12, 2018 at 8:26 AM, David Holmes wrote: > We already dealt with this in the VM: > > http://hg.openjdk.java.net/jdk10/master/rev/f5f2a2d13775 > > by disabling the warning. > > That suggests to me that this warning must have been disabled in the JDK > build too. So perhaps recent flag reworking has modified that. ?? > > David > > > On 12/03/2018 5:15 PM, David Holmes wrote: > >> Hi Thomas, >> >> On 12/03/2018 5:02 PM, Thomas St?fe wrote: >> >>> Hi all, >>> >>> maybe someone has an idea: >>> >>> I build on a freshly installed Linux instance (MX17), using gcc 6.3.0. >>> >>> I get this error: >>> >>> Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s) >>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un >>> ix/native/libmanagement_ext/OperatingSystemImpl.c: >>> In function ?read_dir?: >>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un >>> ix/native/libmanagement_ext/OperatingSystemImpl.c:83:5: >>> warning: ?readdir_r? is deprecated [-Wdeprecated-declarations] >>> if (readdir_r(dirp, entry, &p) == 0) { >>> ^~ >>> In file included from >>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0, >>> >>> from >>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32, >>> >>> from >>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un >>> ix/native/libmanagement_ext/OperatingSystemImpl.c:29: >>> /usr/include/dirent.h:183:12: note: declared here >>> extern int readdir_r (DIR *__restrict __dirp, >>> ^~~~~~~~~ >>> >>> I digged and was not able to pin it to any recent change. I also think I >>> never successfully built on this box, so it may be my environment. >>> >>> Could it be that my gcc is too new? >>> >> >> We've built with gcc 7 so it can't be that on its own. May be a >> combination of gcc and glibc version. It was deprecated in glibc 2.24. >> >> David >> >> Thanks! Thomas >>> >>> From magnus.ihse.bursie at oracle.com Mon Mar 12 07:50:44 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 08:50:44 +0100 Subject: =?UTF-8?Q?Re:_jdk_build_fails_due_to_=22warning:_=e2=80=98readdir?= =?UTF-8?B?X3LigJkgaXMgZGVwcmVjYXRlZCI=?= In-Reply-To: References: Message-ID: On 2018-03-12 08:02, Thomas St?fe wrote: > Hi all, > > maybe someone has an idea: > > I build on a freshly installed Linux instance (MX17), using gcc 6.3.0. > > I get this error: > > Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s) > /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c: > In function ?read_dir?: > /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:83:5: > warning: ?readdir_r? is deprecated [-Wdeprecated-declarations] > if (readdir_r(dirp, entry, &p) == 0) { > ^~ > In file included from > /shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0, > from > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32, > from > /shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:29: > /usr/include/dirent.h:183:12: note: declared here > extern int readdir_r (DIR *__restrict __dirp, > ^~~~~~~~~ > > I digged and was not able to pin it to any recent change. I also think I > never successfully built on this box, so it may be my environment. > > Could it be that my gcc is too new? Hi Thomas, I also saw this some days ago, when testing a new CFLAG change with multiple gcc versions. I suspect it might be time to add a new DISABLED_WARNINGS_gcc, and open a bug on the corresponding component team(s). As usual, the workaround is "configure --disable-warnings-as-errors". /Magnus > > Thanks! Thomas From magnus.ihse.bursie at oracle.com Mon Mar 12 07:56:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 08:56:25 +0100 Subject: win 32bit build: configure cannot resolve 32bit crt. In-Reply-To: References: Message-ID: On 2018-03-10 08:58, Thomas St?fe wrote: > Hi, > > did anyone build 32bit windows recently? Most likely not. :-) Oracle has stopped doing any 32-bit builds on a regular basis. As far as I know, no-one else has picked up the baton. And without regular testing, things are prone to bit rot. You are welcome to submit a patch, but don't expect things to stay working unless someone starts testing. (You are of course even more welcome to set up regular testing!) > I get the following configure error: > > .. > POSSIBLE_MSVC_DLL /cygdrive/c/Program > POSSIBLE_MSVC_DLL Files > POSSIBLE_MSVC_DLL (x86)/Microsoft > POSSIBLE_MSVC_DLL Visual > POSSIBLE_MSVC_DLL Studio > POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll But that looks seriously broken, like some path including spaces has been split up. :-( That's probably not 32-bit related. /Magnus > configure: Found msvcr120.dll at /cygdrive/c/Windows/system32/msvcr120.dll > using well-known location in SYSTEMROOT > checking found msvcr120.dll architecture... incorrect, ignoring > configure: The file type of the located msvcr120.dll is PE32+ executable > (DLL) (GUI) x86-64, for MS Windows > configure: Found msvcr120.dll at /cygdrive/c/Program Files (x86)/Microsoft > Visual Studio 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using > search of VCINSTALLDIR > checking found msvcr120.dll architecture... incorrect, ignoring > configure: The file type of the located msvcr120.dll is PE32 executable > (DLL) (GUI) ARMv7 Thumb, for MS Windows > checking for msvcr120.dll... no > configure: error: Could not find msvcr120.dll. Please specify using > --with-msvcr-dll. > configure exiting with result code 1 > ... > > I am building the jdk-hs repo on WIndows 7 with VS 2013 Premium ed. Update > 5. > > My configure options > are: --with-boot-jdk=/cygdrive/c/mine/projects/openjdk/jdks/openjdk9 > --with-target-bits=32 --with-debug-level=slowdebug > --with-native-debug-symbols=external > > Kind Regards, Thomas From thomas.stuefe at gmail.com Mon Mar 12 08:15:51 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Mar 2018 09:15:51 +0100 Subject: win 32bit build: configure cannot resolve 32bit crt. In-Reply-To: References: Message-ID: On Mon, Mar 12, 2018 at 8:56 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > On 2018-03-10 08:58, Thomas St?fe wrote: > >> Hi, >> >> did anyone build 32bit windows recently? >> > Most likely not. :-) > Darn :) > Oracle has stopped doing any 32-bit builds on a regular basis. As far as I > know, no-one else has picked up the baton. And without regular testing, > things are prone to bit rot. > > You are welcome to submit a patch, but don't expect things to stay working > unless someone starts testing. (You are of course even more welcome to set > up regular testing!) I may pitch in patches from time to time, similar to zero, but won't be able to do it regurarly. I hope there is enough community interest to drag it along like we do the zero port. > > > I get the following configure error: >> >> .. >> POSSIBLE_MSVC_DLL /cygdrive/c/Program >> POSSIBLE_MSVC_DLL Files >> POSSIBLE_MSVC_DLL (x86)/Microsoft >> POSSIBLE_MSVC_DLL Visual >> POSSIBLE_MSVC_DLL Studio >> POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >> > But that looks seriously broken, like some path including spaces has been > split up. :-( That's probably not 32-bit related. > > Oh! good point. How did I miss this? Thanks for spotting! ..Thomas > /Magnus > > configure: Found msvcr120.dll at /cygdrive/c/Windows/system32/msvcr120.dll >> using well-known location in SYSTEMROOT >> checking found msvcr120.dll architecture... incorrect, ignoring >> configure: The file type of the located msvcr120.dll is PE32+ executable >> (DLL) (GUI) x86-64, for MS Windows >> configure: Found msvcr120.dll at /cygdrive/c/Program Files (x86)/Microsoft >> Visual Studio 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using >> search of VCINSTALLDIR >> checking found msvcr120.dll architecture... incorrect, ignoring >> configure: The file type of the located msvcr120.dll is PE32 executable >> (DLL) (GUI) ARMv7 Thumb, for MS Windows >> checking for msvcr120.dll... no >> configure: error: Could not find msvcr120.dll. Please specify using >> --with-msvcr-dll. >> configure exiting with result code 1 >> ... >> >> I am building the jdk-hs repo on WIndows 7 with VS 2013 Premium ed. Update >> 5. >> >> My configure options >> are: --with-boot-jdk=/cygdrive/c/mine/projects/openjdk/jdks/openjdk9 >> --with-target-bits=32 --with-debug-level=slowdebug >> --with-native-debug-symbols=external >> >> Kind Regards, Thomas >> > > From magnus.ihse.bursie at oracle.com Mon Mar 12 10:08:21 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 11:08:21 +0100 Subject: RFR: JDK-8199451 Create linux-aarch64 cross-compilation devkit, and fix cross-compilation Message-ID: <85871784-443b-a091-2c07-95da29675435@oracle.com> While Oracle no longer actively supports linux-aarch64, it is good to keep the build functioning for cross-compilation. I've created a devkit for cross-compilation from linux-x64 to linux-aarch64, and fixed a recently introduced bug with buildjdk SYSROOT_CFLAGS. Bug: https://bugs.openjdk.java.net/browse/JDK-8199451 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199451-create-linux-aarch64-devkit/webrev.01 /Magnus From aph at redhat.com Mon Mar 12 10:15:28 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 Mar 2018 10:15:28 +0000 Subject: RFR: JDK-8199451 Create linux-aarch64 cross-compilation devkit, and fix cross-compilation In-Reply-To: <85871784-443b-a091-2c07-95da29675435@oracle.com> References: <85871784-443b-a091-2c07-95da29675435@oracle.com> Message-ID: <9f65cd9a-993a-94da-d9c8-a06622f28c9c@redhat.com> On 12/03/18 10:08, Magnus Ihse Bursie wrote: > While Oracle no longer actively supports linux-aarch64, it is good to > keep the build functioning for cross-compilation. > > I've created a devkit for cross-compilation from linux-x64 to > linux-aarch64, and fixed a recently introduced bug with buildjdk > SYSROOT_CFLAGS. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199451 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199451-create-linux-aarch64-devkit/webrev.01 That looks like it my be useful. It's fine, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Mon Mar 12 10:18:04 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 11:18:04 +0100 Subject: Windows: Replace VisualStudio with gcc/clang? In-Reply-To: References: Message-ID: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> Hi Hendrik, This sounds like something that should be discussed on build-dev, rather than jdk-dev. Short answer to your question: There's no technical reason why it would not be possible to use clang or gcc on Windows. However, the code is full of assumptions that "compiling on Windows" == "compiling using the Microsoft toolchain", and it will certainly take a lot of effort to hunt all these down and fix them properly. Personally, I don't think it's worth the effort. It's unlikely that the resulting binary will have any significant change in performance (at least not any positive one), and it is likely to continuously break since people will be adding new code with the "windows" == "microsoft toolchain" assumption. Question: Is the Visual Studio Express (https://www.visualstudio.com/vs/visual-studio-express/) such a hassle to install? /Magnus On 2018-03-06 12:17, Hendrik Schreiber wrote: > Hey, > > inspired by the recent news that Chrome ditched the Microsoft C++ compiler and replaced it with gcc/clang (https://arstechnica.com/gadgets/2018/03/chrome-on-windows-ditches-microsofts-compiler-now-uses-clang/), I?m wondering wether that?s possible and desirable for OpenJDK, too. > > From my point of view: Yes. > > Downloading, installing etc. Visual Studio is a major pain for anybody usually working on another platform. Whenever I encounter a bug that?s Windows specific, I pretty much always give up the idea to create a fix and instead just report a bug. It?s just too much of a hassle to create a working build environment. > > So has migrating to gcc/clang for Windows been evaluated? Is it an option at all? Would it make things easier or harder? What do you think? Besides ease of use, how would such a move affect performance? > > Cheers, > > -hendrik From magnus.ihse.bursie at oracle.com Mon Mar 12 10:31:55 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 11:31:55 +0100 Subject: RFR: JDK-8199451 Create linux-aarch64 cross-compilation devkit, and fix cross-compilation In-Reply-To: <9f65cd9a-993a-94da-d9c8-a06622f28c9c@redhat.com> References: <85871784-443b-a091-2c07-95da29675435@oracle.com> <9f65cd9a-993a-94da-d9c8-a06622f28c9c@redhat.com> Message-ID: <3d60f9e9-ba0c-8559-2e46-d8b715a1c817@oracle.com> If you want to try it, be prepared that the source code currently does not compile without warnings, so you need "configure --disable-warnings-as-errors". I will look into this as a follow-up issue. /Magnus On 2018-03-12 11:15, Andrew Haley wrote: > On 12/03/18 10:08, Magnus Ihse Bursie wrote: >> While Oracle no longer actively supports linux-aarch64, it is good to >> keep the build functioning for cross-compilation. >> >> I've created a devkit for cross-compilation from linux-x64 to >> linux-aarch64, and fixed a recently introduced bug with buildjdk >> SYSROOT_CFLAGS. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199451 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8199451-create-linux-aarch64-devkit/webrev.01 > That looks like it my be useful. It's fine, thanks. > From thomas.stuefe at gmail.com Mon Mar 12 13:26:15 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Mar 2018 14:26:15 +0100 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: <5AA40934.5010306@oracle.com> References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> <5AA40934.5010306@oracle.com> Message-ID: Yes, I am aware :( Long term I hope windows 32bit gets the same occasional love as zero does. I can produce occasional patches if time allows. But in this case the error was in front of the computer, as Magnus pointed, I may just have a broken build env. Thanks for your fix, btw! removing the freetypelib building hassle is a huge step toward an easier windows build setup. ..thomas On Sat, Mar 10, 2018 at 5:35 PM, Philip Race wrote: > This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any > platform for the new releases, then there aren't resources or effort being > put into making sure it still builds. Our build systems might still > support it, but for how long? > It might effectively have to become a "port" that someone outside will > step up to maintain. > Not as different as AIX .. or as much effort perhaps .. but if someone > will do that I expect patches would not be refused. > > -phil. > > > On 3/9/18, 11:55 PM, Thomas St?fe wrote: > >> I attempted to test the 32bit build but that seems to have bitrotted, I >> ran into errors not having anything to do with your change. >> > From volker.simonis at gmail.com Mon Mar 12 13:43:37 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 12 Mar 2018 14:43:37 +0100 Subject: Friendly request: Update "Supported Build Platforms" Wiki page Message-ID: Hi, could somebody please be so kind and update the "Supported Build Platforms" Wiki page [1] for OpenJDK 10 and possibly 11? Thanks a lot, Volker [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms From Sergey.Bylokhov at oracle.com Mon Mar 12 14:15:32 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Mar 2018 07:15:32 -0700 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: <5AA31E49.9070002@oracle.com> References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> <925e48d5-5253-7f68-ac59-e90e75e6bf1c@oracle.com> <5AA3180B.4000709@oracle.com> <5AA318AE.7070604@oracle.com> <5AA31E49.9070002@oracle.com> Message-ID: Ok, looks fine. On 09/03/2018 15:52, Philip Race wrote: > It is correct as is .. > > -phil. > > On 3/9/18, 3:49 PM, Sergey Bylokhov wrote: >> I am not an expert here, but the LICENSE.TXT is a little bit different. >> It states that "This means? that *you* must choose? *one* of the? two >> licenses described below,.....". >> So I do not know should we select the license and provide the text >> only for one or for both. >> >> On 09/03/2018 15:28, Philip Race wrote: >>> Just to be clear, I mean we don't import it to each of the source files. >>> But it is there in the file legal/freetype.md in this webrev. >>> >>> On 3/9/18, 3:26 PM, Philip Race wrote: >>>> >>>> No. >>>> >>>> -phil. >>>> >>>> On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: >>>>> Hi, Phil >>>>> Headers of the new files refer to LICENSE.TXT. Should we import it >>>>> as well? >>>>> >>>>> On 09/03/2018 14:10, Phil Race wrote: >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 >>>>>> Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html >>>>>> >>>>>> This fix is will make building openjdk somewhat easier as it removes >>>>>> the dependence on an OpenJDK developer on Windows or Mac going >>>>>> off and downloading and building freetype source themselves .. or >>>>>> using XQuartz on Mac etc. >>>>>> >>>>>> It also means it will be somewhat easier for updating official >>>>>> OpenJDK >>>>>> builds to use a more modern freetype. The pre-compiled binary is a >>>>>> pain >>>>>> inside Oracle too. >>>>>> >>>>>> On Linux and Solaris platforms the build will still default to using >>>>>> the system installed freetype library. However this can easily be >>>>>> over-ridden by adding? a configure parameter : >>>>>> --with-freetype=bundled >>>>>> The other valid option being "system" which, is of however never >>>>>> not valid >>>>>> on Windows? or Mac. So --with-freetype include is no longer a path. >>>>>> The auto-discovery of the location of system library and headers has >>>>>> worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 >>>>>> >>>>>> But just in case it doesn't you can also still use >>>>>> --with-freetype-include and --with-freetype-lib >>>>>> which must both be specified and imply --with-freetype=system >>>>>> >>>>>> The docs have been updated to remove discussion of the obsoleted >>>>>> requirements >>>>>> >>>>>> Sharp eyes will also notice that it now makes Freetype the >>>>>> preferred rasteriser >>>>>> over the closed source T2K, even for Oracle JDK builds : >>>>>> >>>>>> http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html >>>>>> >>>>>> >>>>>> Since freetype != t2k there *will* be some very minor >>>>>> rasterization differences. >>>>>> Such cases are likely not a bug, but a feature :-) >>>>>> Since we previously and now mostly used GDI for LCD text on >>>>>> Windows and >>>>>> also generally defer to CoreText on Mac, the importance of the >>>>>> differences >>>>>> may not be great. >>>>>> But if you see any really bad rendering (I haven't) let me know. >>>>>> >>>>>> make/devkit/createMacosxDevkit6.sh is an empty diff? .. I was >>>>>> proposing to remove the devkit references to freetype but it was >>>>>> suggested >>>>>> to leave that alone for now. >>>>>> >>>>>> 99% of the change is simply importing the freetype 2.9 files "as is" >>>>>> The UPDATING.txt file provides some background on the import process. >>>>>> >>>>>> I have built this every-which-way and tested it too .. it is of >>>>>> course possible >>>>>> there's a problem I've missed so try it out yourself if you can. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >> >> -- Best regards, Sergey. From erik.joelsson at oracle.com Mon Mar 12 15:36:46 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Mar 2018 08:36:46 -0700 Subject: Windows: Replace VisualStudio with gcc/clang? In-Reply-To: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> References: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> Message-ID: On 2018-03-12 03:18, Magnus Ihse Bursie wrote: > Question: Is the Visual Studio Express > (https://www.visualstudio.com/vs/visual-studio-express/) such a hassle > to install? Just to comment on this. Microsoft has introduced standalone C++ build tools: http://landinghub.visualstudio.com/visual-cpp-build-tools I haven't looked into it yet, but it seems to be a much more lightweight alternative to installing Visual Studio if you just want to be able to build something. We should certainly make sure this works when full support for VS 2017 is in. /Erik From magnus.ihse.bursie at oracle.com Mon Mar 12 15:47:14 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 16:47:14 +0100 Subject: Windows: Replace VisualStudio with gcc/clang? In-Reply-To: References: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> Message-ID: > 12 mars 2018 kl. 16:36 skrev Erik Joelsson : > > >> On 2018-03-12 03:18, Magnus Ihse Bursie wrote: >> Question: Is the Visual Studio Express (https://www.visualstudio.com/vs/visual-studio-express/) such a hassle to install? > Just to comment on this. Microsoft has introduced standalone C++ build tools: > > http://landinghub.visualstudio.com/visual-cpp-build-tools > > I haven't looked into it yet, but it seems to be a much more lightweight alternative to installing Visual Studio if you just want to be able to build something. We should certainly make sure this works when full support for VS 2017 is in. That's nice! I have missed that one. /Magnus > > /Erik From erik.joelsson at oracle.com Mon Mar 12 15:47:16 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Mar 2018 08:47:16 -0700 Subject: RFR: JDK-8199451 Create linux-aarch64 cross-compilation devkit, and fix cross-compilation In-Reply-To: <85871784-443b-a091-2c07-95da29675435@oracle.com> References: <85871784-443b-a091-2c07-95da29675435@oracle.com> Message-ID: <35364592-de93-4582-441b-e255e17c9b46@oracle.com> I think this looks ok. Just a note that the current devkit makefiles (at least used to) support creating a full Canadian cross set of tools and you have made some changes that disables this. For example changing $$host to $(TARGET) in the devkit.info file makes it so that one devkit can only have one target. This is probably fine because that is how we effectively use it today anyway. /Erik On 2018-03-12 03:08, Magnus Ihse Bursie wrote: > While Oracle no longer actively supports linux-aarch64, it is good to > keep the build functioning for cross-compilation. > > I've created a devkit for cross-compilation from linux-x64 to > linux-aarch64, and fixed a recently introduced bug with buildjdk > SYSROOT_CFLAGS. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199451 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199451-create-linux-aarch64-devkit/webrev.01 > > /Magnus From thomas.stuefe at gmail.com Mon Mar 12 16:13:58 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Mar 2018 17:13:58 +0100 Subject: Windows: Replace VisualStudio with gcc/clang? In-Reply-To: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> References: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> Message-ID: I wonder how much of the perceived difficulty of Windows as build platform is really the fault of Visual Studio. I find it quite easy to install. But the required Cygwin install could be better documented: I have a text file somewhere with all required packets, but I do not know if an official documentation exists. Then there is the annoying freetype dependency, which soon will be history thanks to Phil Race (8193017). Also, installing Visual Studio could be easier by making sure that we always can build with the latest community version, early when it comes out. Since it is not so easy to find community/express/whatever downloads for earlier versions of Visual Studio. (Just my 5c). Best Regards, Thomas On Mon, Mar 12, 2018 at 11:18 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > Hi Hendrik, > > This sounds like something that should be discussed on build-dev, rather > than jdk-dev. > > Short answer to your question: There's no technical reason why it would > not be possible to use clang or gcc on Windows. However, the code is full > of assumptions that "compiling on Windows" == "compiling using the > Microsoft toolchain", and it will certainly take a lot of effort to hunt > all these down and fix them properly. > > Personally, I don't think it's worth the effort. It's unlikely that the > resulting binary will have any significant change in performance (at least > not any positive one), and it is likely to continuously break since people > will be adding new code with the "windows" == "microsoft toolchain" > assumption. > > Question: Is the Visual Studio Express (https://www.visualstudio.com/ > vs/visual-studio-express/) such a hassle to install? > > /Magnus > > > On 2018-03-06 12:17, Hendrik Schreiber wrote: > >> Hey, >> >> inspired by the recent news that Chrome ditched the Microsoft C++ >> compiler and replaced it with gcc/clang (https://arstechnica.com/gadge >> ts/2018/03/chrome-on-windows-ditches-microsofts-compiler-now-uses-clang/), >> I?m wondering wether that?s possible and desirable for OpenJDK, too. >> >> From my point of view: Yes. >> >> Downloading, installing etc. Visual Studio is a major pain for anybody >> usually working on another platform. Whenever I encounter a bug that?s >> Windows specific, I pretty much always give up the idea to create a fix and >> instead just report a bug. It?s just too much of a hassle to create a >> working build environment. >> >> So has migrating to gcc/clang for Windows been evaluated? Is it an option >> at all? Would it make things easier or harder? What do you think? Besides >> ease of use, how would such a move affect performance? >> >> Cheers, >> >> -hendrik >> > > From magnus.ihse.bursie at oracle.com Mon Mar 12 16:56:00 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 17:56:00 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> Message-ID: <34f7767b-6302-89f1-9cdd-f2d1d78a6610@oracle.com> On 2018-03-09 23:10, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 > Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html Looks good to me. Thanks for fixing this Phil! Freetype has really been a constant pain in building on all platforms except Linux. For once, I'm actually glad we add third party source code to our repository. ;-) /Magnus > > This fix is will make building openjdk somewhat easier as it removes > the dependence on an OpenJDK developer on Windows or Mac going > off and downloading and building freetype source themselves .. or > using XQuartz on Mac etc. > > It also means it will be somewhat easier for updating official OpenJDK > builds to use a more modern freetype. The pre-compiled binary is a pain > inside Oracle too. > > On Linux and Solaris platforms the build will still default to using > the system installed freetype library. However this can easily be > over-ridden by adding? a configure parameter : --with-freetype=bundled > The other valid option being "system" which, is of however never not > valid > on Windows? or Mac. So --with-freetype include is no longer a path. > The auto-discovery of the location of system library and headers has > worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 > > But just in case it doesn't you can also still use > --with-freetype-include and --with-freetype-lib > which must both be specified and imply --with-freetype=system > > The docs have been updated to remove discussion of the obsoleted > requirements > > Sharp eyes will also notice that it now makes Freetype the preferred > rasteriser > over the closed source T2K, even for Oracle JDK builds : > > http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html > > > Since freetype != t2k there *will* be some very minor rasterization > differences. > Such cases are likely not a bug, but a feature :-) > Since we previously and now mostly used GDI for LCD text on Windows and > also generally defer to CoreText on Mac, the importance of the > differences > may not be great. > But if you see any really bad rendering (I haven't) let me know. > > make/devkit/createMacosxDevkit6.sh is an empty diff? .. I was > proposing to remove the devkit references to freetype but it was > suggested > to leave that alone for now. > > 99% of the change is simply importing the freetype 2.9 files "as is" > The UPDATING.txt file provides some background on the import process. > > I have built this every-which-way and tested it too .. it is of course > possible > there's a problem I've missed so try it out yourself if you can. > > -phil. > > > > > > > From magnus.ihse.bursie at oracle.com Mon Mar 12 16:58:00 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 17:58:00 +0100 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> <5AA40934.5010306@oracle.com> Message-ID: <1af4e6ec-9117-f5d5-a9ae-2335ad8c4c9e@oracle.com> On 2018-03-12 14:26, Thomas St?fe wrote: > Yes, I am aware :( Long term I hope windows 32bit gets the same occasional > love as zero does. I can produce occasional patches if time allows. > > But in this case the error was in front of the computer, as Magnus pointed, > I may just have a broken build env. Actually, that was not what I was trying to say. I think there's a bug in the configure script, but one that perhaps only shows up on 32-bit Windows when it fails to locate the runtime dll in the "normal" places. Probably missing "" somewhere. /Magnus > > Thanks for your fix, btw! removing the freetypelib building hassle is a > huge step toward an easier windows build setup. > > ..thomas > > On Sat, Mar 10, 2018 at 5:35 PM, Philip Race wrote: > >> This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any >> platform for the new releases, then there aren't resources or effort being >> put into making sure it still builds. Our build systems might still >> support it, but for how long? >> It might effectively have to become a "port" that someone outside will >> step up to maintain. >> Not as different as AIX .. or as much effort perhaps .. but if someone >> will do that I expect patches would not be refused. >> >> -phil. >> >> >> On 3/9/18, 11:55 PM, Thomas St?fe wrote: >> >>> I attempted to test the 32bit build but that seems to have bitrotted, I >>> ran into errors not having anything to do with your change. >>> From claes.redestad at oracle.com Mon Mar 12 18:26:59 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 12 Mar 2018 19:26:59 +0100 Subject: RFR: 8199469: Disable generate-jli-classes when building interim-image Message-ID: <8f020b0b-4de7-ea6d-0d60-38d395fc1877@oracle.com> Hi, during build we use an interim image to generate some optimization information, e.g., the input for generate-jli-classes jlink plugin for the real build. Turns out jlinking the interim-image picks up the output from such training runs, which adds to the build time when we run incremental builds, and worse: it might mean we use stale information that could potentially make building the interim-image fail or do some really non-obvious things (an issue I ran into as I was experimenting with allowing the plugin to generate more kinds of LFs). I suggest disabling the generate-jli-classes plugin when building the interim-image, avoiding such cycles: http://cr.openjdk.java.net/~redestad/8199469/open.00/ A trivial one-liner fix, but as this is .gmk then I'm sure some would want to check I've used the proper mix of tabs and spaces... ;-) Thanks! /Claes From erik.joelsson at oracle.com Mon Mar 12 18:28:51 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Mar 2018 11:28:51 -0700 Subject: RFR: 8199469: Disable generate-jli-classes when building interim-image In-Reply-To: <8f020b0b-4de7-ea6d-0d60-38d395fc1877@oracle.com> References: <8f020b0b-4de7-ea6d-0d60-38d395fc1877@oracle.com> Message-ID: Looks good, thanks for finding and fixing this! /Erik On 2018-03-12 11:26, Claes Redestad wrote: > Hi, > > during build we use an interim image to generate some optimization > information, > e.g., the input for generate-jli-classes jlink plugin for the real > build. Turns out > jlinking the interim-image picks up the output from such training > runs, which adds > to the build time when we run incremental builds, and worse: it might > mean we > use stale information that could potentially make building the > interim-image fail > or do some really non-obvious things (an issue I ran into as I was > experimenting > with allowing the plugin to generate more kinds of LFs). > > I suggest disabling the generate-jli-classes plugin when building the > interim-image, > avoiding such cycles: > > http://cr.openjdk.java.net/~redestad/8199469/open.00/ > > A trivial one-liner fix, but as this is .gmk then I'm sure some would > want to check > I've used the proper mix of tabs and spaces... ;-) > > Thanks! > > /Claes From mandy.chung at oracle.com Mon Mar 12 18:29:08 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 12 Mar 2018 11:29:08 -0700 Subject: RFR: 8199469: Disable generate-jli-classes when building interim-image In-Reply-To: <8f020b0b-4de7-ea6d-0d60-38d395fc1877@oracle.com> References: <8f020b0b-4de7-ea6d-0d60-38d395fc1877@oracle.com> Message-ID: <3405bc14-f01f-4659-2107-e543ee57b016@oracle.com> +1 Mandy On 3/12/18 11:26 AM, Claes Redestad wrote: > Hi, > > during build we use an interim image to generate some optimization > information, > e.g., the input for generate-jli-classes jlink plugin for the real > build. Turns out > jlinking the interim-image picks up the output from such training > runs, which adds > to the build time when we run incremental builds, and worse: it might > mean we > use stale information that could potentially make building the > interim-image fail > or do some really non-obvious things (an issue I ran into as I was > experimenting > with allowing the plugin to generate more kinds of LFs). > > I suggest disabling the generate-jli-classes plugin when building the > interim-image, > avoiding such cycles: > > http://cr.openjdk.java.net/~redestad/8199469/open.00/ > > A trivial one-liner fix, but as this is .gmk then I'm sure some would > want to check > I've used the proper mix of tabs and spaces... ;-) > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Mar 12 18:30:16 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 12 Mar 2018 19:30:16 +0100 Subject: RFR: 8199469: Disable generate-jli-classes when building interim-image In-Reply-To: References: <8f020b0b-4de7-ea6d-0d60-38d395fc1877@oracle.com> Message-ID: <2d1ef666-7134-8920-7a85-dfdc4c205924@oracle.com> Erik, Mandy, thanks for reviewing! /Claes On 2018-03-12 19:28, Erik Joelsson wrote: > Looks good, thanks for finding and fixing this! From erik.joelsson at oracle.com Mon Mar 12 18:47:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Mar 2018 11:47:40 -0700 Subject: RFR: Support Visual Studio BuildTools with VS2017 Message-ID: As was recently noted on this list, Microsoft has started offering a smaller download of just the compilers and tools needed to build C++. This can be very convenient for people wanting to just build openjdk without the hassle of installing a full Visual Studio. We aren't quite ready to build all of OpenJDK with Visual Studio 2017, but we are working on it. The build system is already able to configure with it, but currently only for Community, Professional and Enterprise editions. I would like to also add the BuildTools edition to this list. I was able to install BuildTools in addition to the normal install and it ended up in a different sub directory, analogous with the other editions. I've tried to configure with it locally and with this trivial change, I was able to build as far as with the full Visual Studio installation. Bug: https://bugs.openjdk.java.net/browse/JDK-8199473 Patch: diff -r e59941f7247d make/autoconf/toolchain_windows.m4 --- a/make/autoconf/toolchain_windows.m4??????? Fri Mar 09 19:20:19 2018 +0100 +++ b/make/autoconf/toolchain_windows.m4??????? Mon Mar 12 19:44:12 2018 +0100 @@ -77,7 +77,7 @@ ?VS_MSVCP_2017=msvcp140.dll ?VS_ENVVAR_2017="VS150COMNTOOLS" ?VS_VS_INSTALLDIR_2017="Microsoft Visual Studio/2017" -VS_EDITIONS_2017="Community Professional Enterprise" +VS_EDITIONS_2017="BuildTools Community Professional Enterprise" ?VS_SDK_INSTALLDIR_2017= ?VS_VS_PLATFORM_NAME_2017="v141" ?VS_SDK_PLATFORM_NAME_2017= /Erik From magnus.ihse.bursie at oracle.com Mon Mar 12 19:15:03 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 20:15:03 +0100 Subject: RFR: Support Visual Studio BuildTools with VS2017 In-Reply-To: References: Message-ID: <7bb5ed25-5fad-23fd-7bf4-d8213e9bb5e1@oracle.com> On 2018-03-12 19:47, Erik Joelsson wrote: > As was recently noted on this list, Microsoft has started offering a > smaller download of just the compilers and tools needed to build C++. > This can be very convenient for people wanting to just build openjdk > without the hassle of installing a full Visual Studio. > > We aren't quite ready to build all of OpenJDK with Visual Studio 2017, > but we are working on it. The build system is already able to > configure with it, but currently only for Community, Professional and > Enterprise editions. I would like to also add the BuildTools edition > to this list. > > I was able to install BuildTools in addition to the normal install and > it ended up in a different sub directory, analogous with the other > editions. I've tried to configure with it locally and with this > trivial change, I was able to build as far as with the full Visual > Studio installation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199473 > > Patch: > > diff -r e59941f7247d make/autoconf/toolchain_windows.m4 > --- a/make/autoconf/toolchain_windows.m4??????? Fri Mar 09 19:20:19 > 2018 +0100 > +++ b/make/autoconf/toolchain_windows.m4??????? Mon Mar 12 19:44:12 > 2018 +0100 > @@ -77,7 +77,7 @@ > ?VS_MSVCP_2017=msvcp140.dll > ?VS_ENVVAR_2017="VS150COMNTOOLS" > ?VS_VS_INSTALLDIR_2017="Microsoft Visual Studio/2017" > -VS_EDITIONS_2017="Community Professional Enterprise" > +VS_EDITIONS_2017="BuildTools Community Professional Enterprise" > ?VS_SDK_INSTALLDIR_2017= > ?VS_VS_PLATFORM_NAME_2017="v141" > ?VS_SDK_PLATFORM_NAME_2017= Looks good to me. Nice and surprising that it was so smooth! /Magnus > > > /Erik > From magnus.ihse.bursie at oracle.com Mon Mar 12 19:19:26 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 20:19:26 +0100 Subject: Windows: Replace VisualStudio with gcc/clang? In-Reply-To: References: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> Message-ID: <322d5894-8b10-33e7-d6e3-be59602c58e3@oracle.com> On 2018-03-12 17:13, Thomas St?fe wrote: > I wonder how much of the perceived difficulty of Windows as build > platform is really the fault of Visual Studio. I find it quite easy to > install. > > But the required Cygwin install could be better documented: I have a > text file somewhere with all required packets, but I do not know if an > official documentation exists. doc/building.md? I quote: Apart from the basic Cygwin installation, the following packages must also be installed: ? * `autoconf` ? * `make` ? * `zip` ? * `unzip` Often, you can install these packages using the following command line: ``` /setup-x86_64 -q -P autoconf -P make -P unzip -P zip ``` Nowadays, it's actually not more complicated than that. My personal recommendation is btw to install apt-cyg (https://github.com/transcode-open/apt-cyg) to make package installation even more "debian-like"; then you can just do "apt-cyg install autoconf make unzip zip". I might turn this into an official recommendation by including it in the build readme at some time. :-) /Magnus > > Then there is the annoying freetype dependency, which soon will be > history thanks to Phil Race (8193017). > > Also, installing Visual Studio could be easier by making sure that we > always can build with the latest community version, early?when it > comes out. Since it is not so easy to find community/express/whatever > downloads for earlier versions of Visual Studio. > > (Just my 5c). > > Best Regards, Thomas > > > > > On Mon, Mar 12, 2018 at 11:18 AM, Magnus Ihse Bursie > > > wrote: > > Hi Hendrik, > > This sounds like something that should be discussed on build-dev, > rather than jdk-dev. > > Short answer to your question: There's no technical reason why it > would not be possible to use clang or gcc on Windows. However, the > code is full of assumptions that "compiling on Windows" == > "compiling using the Microsoft toolchain", and it will certainly > take a lot of effort to hunt all these down and fix them properly. > > Personally, I don't think it's worth the effort. It's unlikely > that the resulting binary will have any significant change in > performance (at least not any positive one), and it is likely to > continuously break since people will be adding new code with the > "windows" == "microsoft toolchain" assumption. > > Question: Is the Visual Studio Express > (https://www.visualstudio.com/vs/visual-studio-express/ > ) such a > hassle to install? > > /Magnus > > > On 2018-03-06 12:17, Hendrik Schreiber wrote: > > Hey, > > inspired by the recent news that Chrome ditched the Microsoft > C++ compiler and replaced it with gcc/clang > (https://arstechnica.com/gadgets/2018/03/chrome-on-windows-ditches-microsofts-compiler-now-uses-clang/ > ), > I?m wondering wether that?s possible and desirable for > OpenJDK, too. > > ?From my point of view: Yes. > > Downloading, installing etc. Visual Studio is a major pain for > anybody usually working on another platform. Whenever I > encounter a bug that?s Windows specific, I pretty much always > give up the idea to create a fix and instead just report a > bug. It?s just too much of a hassle to create a working build > environment. > > So has migrating to gcc/clang for Windows been evaluated? Is > it an option at all? Would it make things easier or harder? > What do you think? Besides ease of use, how would such a move > affect performance? > > Cheers, > > -hendrik > > > From thomas.stuefe at gmail.com Mon Mar 12 19:23:56 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Mar 2018 19:23:56 +0000 Subject: Windows: Replace VisualStudio with gcc/clang? In-Reply-To: <322d5894-8b10-33e7-d6e3-be59602c58e3@oracle.com> References: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> <322d5894-8b10-33e7-d6e3-be59602c58e3@oracle.com> Message-ID: On Mon 12. Mar 2018 at 20:19, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-03-12 17:13, Thomas St?fe wrote: > > I wonder how much of the perceived difficulty of Windows as build platform > is really the fault of Visual Studio. I find it quite easy to install. > > But the required Cygwin install could be better documented: I have a text > file somewhere with all required packets, but I do not know if an official > documentation exists. > > doc/building.md? > > I quote: > > Apart from the basic Cygwin installation, the following packages must also > be > installed: > > * `autoconf` > * `make` > * `zip` > * `unzip` > > Often, you can install these packages using the following command line: > ``` > /setup-x86_64 -q -P autoconf -P make -P unzip -P zip > ``` > > Nowadays, it's actually not more complicated than that. My personal > recommendation is btw to install apt-cyg ( > https://github.com/transcode-open/apt-cyg) to make package installation > even more "debian-like"; then you can just do "apt-cyg install autoconf > make unzip zip". I might turn this into an official recommendation by > including it in the build readme at some time. :-) > > I did not know that. Very interesting, will try. We should talk more often about these things :) ..Thomas > /Magnus > > > > Then there is the annoying freetype dependency, which soon will be history > thanks to Phil Race (8193017). > > Also, installing Visual Studio could be easier by making sure that we > always can build with the latest community version, early when it comes > out. Since it is not so easy to find community/express/whatever downloads > for earlier versions of Visual Studio. > > (Just my 5c). > > Best Regards, Thomas > > > > > On Mon, Mar 12, 2018 at 11:18 AM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> Hi Hendrik, >> >> This sounds like something that should be discussed on build-dev, rather >> than jdk-dev. >> >> Short answer to your question: There's no technical reason why it would >> not be possible to use clang or gcc on Windows. However, the code is full >> of assumptions that "compiling on Windows" == "compiling using the >> Microsoft toolchain", and it will certainly take a lot of effort to hunt >> all these down and fix them properly. >> >> Personally, I don't think it's worth the effort. It's unlikely that the >> resulting binary will have any significant change in performance (at least >> not any positive one), and it is likely to continuously break since people >> will be adding new code with the "windows" == "microsoft toolchain" >> assumption. >> >> Question: Is the Visual Studio Express ( >> https://www.visualstudio.com/vs/visual-studio-express/) such a hassle to >> install? >> >> /Magnus >> >> >> On 2018-03-06 12:17, Hendrik Schreiber wrote: >> >>> Hey, >>> >>> inspired by the recent news that Chrome ditched the Microsoft C++ >>> compiler and replaced it with gcc/clang ( >>> https://arstechnica.com/gadgets/2018/03/chrome-on-windows-ditches-microsofts-compiler-now-uses-clang/), >>> I?m wondering wether that?s possible and desirable for OpenJDK, too. >>> >>> From my point of view: Yes. >>> >>> Downloading, installing etc. Visual Studio is a major pain for anybody >>> usually working on another platform. Whenever I encounter a bug that?s >>> Windows specific, I pretty much always give up the idea to create a fix and >>> instead just report a bug. It?s just too much of a hassle to create a >>> working build environment. >>> >>> So has migrating to gcc/clang for Windows been evaluated? Is it an >>> option at all? Would it make things easier or harder? What do you think? >>> Besides ease of use, how would such a move affect performance? >>> >>> Cheers, >>> >>> -hendrik >>> >> >> > > From magnus.ihse.bursie at oracle.com Mon Mar 12 20:03:51 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Mar 2018 21:03:51 +0100 Subject: RFR: JDK-8199483 Clean up some non-standard LDFLAGS usage Message-ID: We have a few libraries that, for one reason or another, use non-standard LDFLAGS. There is typically no good reason for this, just historical accidents. This patch fixes several places to remove odd or unneeded LDFLAGS, and to make them conform better to the prevailing standard. This will facilitate even more future cleanups in this area. We still have some "snowflakes" left that have tricky LDFLAGS, but they require more research to figure out the best way to handle. Some comments on the changes: * -machine is not needed, it is autodetected by the linker. * -subsystem:* has no meaning for dlls (and "windows" is default anyway) * -map is always provided by SetupNativeCompilation * -SAFESEH is provided by LDFLAGS_JDKLIB. * The unknown symbols from libsaproc on Solaris was due to the missing link with libproc. * In Windows DEF files, the HEAPSIZE command is equivalent to -heap:. But this is ignored for dlls. (We should not have any linker commands except EXPORTS in def files). I'm running a COMPARE_BUILD set (it's 3/4 finished by now), to verify that there is no significant differences. Bug: https://bugs.openjdk.java.net/browse/JDK-8199483 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199483-simplify-LDFLAGS/webrev.01 /Magnus From tim.bell at oracle.com Mon Mar 12 20:43:36 2018 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 12 Mar 2018 13:43:36 -0700 Subject: RFR: Support Visual Studio BuildTools with VS2017 In-Reply-To: <7bb5ed25-5fad-23fd-7bf4-d8213e9bb5e1@oracle.com> References: <7bb5ed25-5fad-23fd-7bf4-d8213e9bb5e1@oracle.com> Message-ID: <5AA6E678.4070604@oracle.com> Erik- On 03/12/18 12:15, Magnus Ihse Bursie wrote: >> diff -r e59941f7247d make/autoconf/toolchain_windows.m4 >> --- a/make/autoconf/toolchain_windows.m4 Fri Mar 09 19:20:19 >> 2018 +0100 >> +++ b/make/autoconf/toolchain_windows.m4 Mon Mar 12 19:44:12 >> 2018 +0100 >> @@ -77,7 +77,7 @@ >> VS_MSVCP_2017=msvcp140.dll >> VS_ENVVAR_2017="VS150COMNTOOLS" >> VS_VS_INSTALLDIR_2017="Microsoft Visual Studio/2017" >> -VS_EDITIONS_2017="Community Professional Enterprise" >> +VS_EDITIONS_2017="BuildTools Community Professional Enterprise" >> VS_SDK_INSTALLDIR_2017= >> VS_VS_PLATFORM_NAME_2017="v141" >> VS_SDK_PLATFORM_NAME_2017= > Looks good to me. Nice and surprising that it was so smooth! > > /Magnus I agree! Looks good to me as well. Tim From erik.joelsson at oracle.com Mon Mar 12 20:44:33 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Mar 2018 13:44:33 -0700 Subject: RFR: JDK-8199483 Clean up some non-standard LDFLAGS usage In-Reply-To: References: Message-ID: Looks good given that the comparison is clean (for the affected libs). /Erik On 2018-03-12 13:03, Magnus Ihse Bursie wrote: > We have a few libraries that, for one reason or another, use > non-standard LDFLAGS. There is typically no good reason for this, just > historical accidents. > > This patch fixes several places to remove odd or unneeded LDFLAGS, and > to make them conform better to the prevailing standard. This will > facilitate even more future cleanups in this area. > > We still have some "snowflakes" left that have tricky LDFLAGS, but > they require more research to figure out the best way to handle. > > Some comments on the changes: > * -machine is not needed, it is autodetected by the linker. > * -subsystem:* has no meaning for dlls (and "windows" is default anyway) > * -map is always provided by SetupNativeCompilation > * -SAFESEH is provided by LDFLAGS_JDKLIB. > * The unknown symbols from libsaproc on Solaris was due to the missing > link with libproc. > * In Windows DEF files, the HEAPSIZE command is equivalent to > -heap:. But this is ignored for dlls. (We should not have any > linker commands except EXPORTS in def files). > > I'm running a COMPARE_BUILD set (it's 3/4 finished by now), to verify > that there is no significant differences. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199483 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199483-simplify-LDFLAGS/webrev.01 > > /Magnus > From thomas.stuefe at gmail.com Tue Mar 13 08:22:55 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 13 Mar 2018 09:22:55 +0100 Subject: RFR: 8193017: Import freetype sources into OpenJDK source tree In-Reply-To: <1af4e6ec-9117-f5d5-a9ae-2335ad8c4c9e@oracle.com> References: <86fb4093-08ba-abe8-5583-26c617a6342f@oracle.com> <5AA40934.5010306@oracle.com> <1af4e6ec-9117-f5d5-a9ae-2335ad8c4c9e@oracle.com> Message-ID: On Mon, Mar 12, 2018 at 5:58 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > On 2018-03-12 14:26, Thomas St?fe wrote: > >> Yes, I am aware :( Long term I hope windows 32bit gets the same occasional >> love as zero does. I can produce occasional patches if time allows. >> >> But in this case the error was in front of the computer, as Magnus >> pointed, >> I may just have a broken build env. >> > Actually, that was not what I was trying to say. I think there's a bug in > the configure script, but one that perhaps only shows up on 32-bit Windows > when it fails to locate the runtime dll in the "normal" places. Probably > missing "" somewhere. > > Sorry, then I misunderstood you. Yes, this may be. I'll recheck later. ..Thomas > /Magnus > > > > >> Thanks for your fix, btw! removing the freetypelib building hassle is a >> huge step toward an easier windows build setup. >> >> ..thomas >> >> On Sat, Mar 10, 2018 at 5:35 PM, Philip Race >> wrote: >> >> This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any >>> platform for the new releases, then there aren't resources or effort >>> being >>> put into making sure it still builds. Our build systems might still >>> support it, but for how long? >>> It might effectively have to become a "port" that someone outside will >>> step up to maintain. >>> Not as different as AIX .. or as much effort perhaps .. but if someone >>> will do that I expect patches would not be refused. >>> >>> -phil. >>> >>> >>> On 3/9/18, 11:55 PM, Thomas St?fe wrote: >>> >>> I attempted to test the 32bit build but that seems to have bitrotted, I >>>> ran into errors not having anything to do with your change. >>>> >>>> > From magnus.ihse.bursie at oracle.com Tue Mar 13 10:27:21 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 13 Mar 2018 11:27:21 +0100 Subject: RFR: JDK-8199483 Clean up some non-standard LDFLAGS usage In-Reply-To: References: Message-ID: <03e528fc-6bde-1f0c-4263-2e8d6108c13f@oracle.com> On 2018-03-12 21:44, Erik Joelsson wrote: > Looks good given that the comparison is clean (for the affected libs). That depends on what you mean as "clean". Of course there is a difference in deps for libsaproc.so on solaris, since we add a new library to link with. As a side effect, the disassembly also changes somewhat. The "file" command on Windows also reports a difference: ???? other: ./bin/sawindbg.dll: PE32+ executable (DLL) (console) x86-64, for MS Windows ???? this : ./bin/sawindbg.dll: PE32+ executable (DLL) (GUI) x86-64, for MS Windows even though the documentation states that the subsystem selected does not matter for DLLs, just executables. (Possibly the PE format stores this information even if it not used, and "file" is not intelligent enough to discard this for DLLs). Other than that, there are no reported differences. /Magnus > > /Erik > > > On 2018-03-12 13:03, Magnus Ihse Bursie wrote: >> We have a few libraries that, for one reason or another, use >> non-standard LDFLAGS. There is typically no good reason for this, >> just historical accidents. >> >> This patch fixes several places to remove odd or unneeded LDFLAGS, >> and to make them conform better to the prevailing standard. This will >> facilitate even more future cleanups in this area. >> >> We still have some "snowflakes" left that have tricky LDFLAGS, but >> they require more research to figure out the best way to handle. >> >> Some comments on the changes: >> * -machine is not needed, it is autodetected by the linker. >> * -subsystem:* has no meaning for dlls (and "windows" is default anyway) >> * -map is always provided by SetupNativeCompilation >> * -SAFESEH is provided by LDFLAGS_JDKLIB. >> * The unknown symbols from libsaproc on Solaris was due to the >> missing link with libproc. >> * In Windows DEF files, the HEAPSIZE command is equivalent to >> -heap:. But this is ignored for dlls. (We should not have any >> linker commands except EXPORTS in def files). >> >> I'm running a COMPARE_BUILD set (it's 3/4 finished by now), to verify >> that there is no significant differences. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199483 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8199483-simplify-LDFLAGS/webrev.01 >> >> /Magnus >> > From erik.joelsson at oracle.com Tue Mar 13 15:44:37 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 13 Mar 2018 08:44:37 -0700 Subject: RFR: JDK-8199483 Clean up some non-standard LDFLAGS usage In-Reply-To: <03e528fc-6bde-1f0c-4263-2e8d6108c13f@oracle.com> References: <03e528fc-6bde-1f0c-4263-2e8d6108c13f@oracle.com> Message-ID: <264b4594-5b84-cc7a-4a87-262bec920d16@oracle.com> Right, explainable differences are fine of course. Thanks for the report! /Erik On 2018-03-13 03:27, Magnus Ihse Bursie wrote: > On 2018-03-12 21:44, Erik Joelsson wrote: >> Looks good given that the comparison is clean (for the affected libs). > > That depends on what you mean as "clean". Of course there is a > difference in deps for libsaproc.so on solaris, since we add a new > library to link with. As a side effect, the disassembly also changes > somewhat. > > The "file" command on Windows also reports a difference: > ???? other: ./bin/sawindbg.dll: PE32+ executable (DLL) (console) > x86-64, for MS Windows > ???? this : ./bin/sawindbg.dll: PE32+ executable (DLL) (GUI) x86-64, > for MS Windows > even though the documentation states that the subsystem selected does > not matter for DLLs, just executables. (Possibly the PE format stores > this information even if it not used, and "file" is not intelligent > enough to discard this for DLLs). > > Other than that, there are no reported differences. > > /Magnus >> >> /Erik >> >> >> On 2018-03-12 13:03, Magnus Ihse Bursie wrote: >>> We have a few libraries that, for one reason or another, use >>> non-standard LDFLAGS. There is typically no good reason for this, >>> just historical accidents. >>> >>> This patch fixes several places to remove odd or unneeded LDFLAGS, >>> and to make them conform better to the prevailing standard. This >>> will facilitate even more future cleanups in this area. >>> >>> We still have some "snowflakes" left that have tricky LDFLAGS, but >>> they require more research to figure out the best way to handle. >>> >>> Some comments on the changes: >>> * -machine is not needed, it is autodetected by the linker. >>> * -subsystem:* has no meaning for dlls (and "windows" is default >>> anyway) >>> * -map is always provided by SetupNativeCompilation >>> * -SAFESEH is provided by LDFLAGS_JDKLIB. >>> * The unknown symbols from libsaproc on Solaris was due to the >>> missing link with libproc. >>> * In Windows DEF files, the HEAPSIZE command is equivalent to >>> -heap:. But this is ignored for dlls. (We should not have any >>> linker commands except EXPORTS in def files). >>> >>> I'm running a COMPARE_BUILD set (it's 3/4 finished by now), to >>> verify that there is no significant differences. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199483 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8199483-simplify-LDFLAGS/webrev.01 >>> >>> /Magnus >>> >> > From scolebourne at joda.org Tue Mar 13 22:40:01 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 13 Mar 2018 22:40:01 +0000 Subject: Windows: Replace VisualStudio with gcc/clang? In-Reply-To: References: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> Message-ID: On 12 March 2018 at 15:36, Erik Joelsson wrote: > On 2018-03-12 03:18, Magnus Ihse Bursie wrote: > Just to comment on this. Microsoft has introduced standalone C++ build > tools: > > http://landinghub.visualstudio.com/visual-cpp-build-tools > > I haven't looked into it yet, but it seems to be a much more lightweight > alternative to installing Visual Studio if you just want to be able to build > something. We should certainly make sure this works when full support for VS > 2017 is in. >From my perspective, something needs to change, as I found it completely impossible to install the old Visual Studio releases the JDK demands (and it took ages just to find them). Requiring outdated tooling to build the JDK really isn't great. Stephen From thomas.stuefe at gmail.com Wed Mar 14 06:27:13 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 14 Mar 2018 07:27:13 +0100 Subject: Windows: Replace VisualStudio with gcc/clang? In-Reply-To: References: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> Message-ID: On Tue, Mar 13, 2018 at 11:40 PM, Stephen Colebourne wrote: > On 12 March 2018 at 15:36, Erik Joelsson wrote: > > On 2018-03-12 03:18, Magnus Ihse Bursie wrote: > > Just to comment on this. Microsoft has introduced standalone C++ build > > tools: > > > > http://landinghub.visualstudio.com/visual-cpp-build-tools > > > > I haven't looked into it yet, but it seems to be a much more lightweight > > alternative to installing Visual Studio if you just want to be able to > build > > something. We should certainly make sure this works when full support > for VS > > 2017 is in. > > From my perspective, something needs to change, as I found it > completely impossible to install the old Visual Studio releases the > JDK demands (and it took ages just to find them). Requiring outdated > tooling to build the JDK really isn't great. > > Stephen > I agree. This is what I meant when I wrote earlier: "Also, installing Visual Studio could be easier by making sure that we always can build with the latest community version, early when it comes out. Since it is not so easy to find community/express/whatever downloads for earlier versions of Visual Studio. " Unfortunately, this is sometimes a major effort, see e.g. the many VS2017 related patches of the last months. ..Thomas From magnus.ihse.bursie at oracle.com Wed Mar 14 11:17:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Mar 2018 12:17:35 +0100 Subject: RFR: JDK-8199606 Set -lc as global LIBS on solstudio Message-ID: <89fd177e-db85-b015-0672-64fcdbd61bf0@oracle.com> We should always use -lc when linking with solstudio. All other toolchains do this automatically. This also means that -lc is unnecessary for other platforms, where it has been set in some cases (due to the old confusion where "solaris" really meant "unix"). I have tested this using COMPARE_BUILD. Unsurprisingly, there are differences, but they are expected. On macosx and linux, libunpack has disassembly differences (they had previously an explicit -lc). On linux, the same also goes for libjli, libawt_xawt, libfontmanager and libsunec. On solaris there are even more differences. Now all libraries get explicitely linked with -lc, which means binary/disassembly differences in multiple libraries.? We also get a deps difference for libjsig and librmi, which were previously compiled (successfully, for a change! :-)) without -lc. Finally, we get a symbol difference for libjava.We're missing symbols like: "a s_finite.c" and "t finite", and we have one less duplicate of "r two54". I can't say I understand why, but it does seem harmless. Bug: https://bugs.openjdk.java.net/browse/JDK-8199606 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199606-set-lc-as-GLOBAL_LIBS/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Mar 14 11:45:21 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Mar 2018 12:45:21 +0100 Subject: RFR: JDK-8199608 Clean up LDFLAGS for libfontmanager Message-ID: This is the final LDFLAGS cleanup, which required some more work to resolve. Libfontmanager had previously explicitely disabled -z defs, with the result that linking did not complain about missing libraries. To fix this, I had to provide the proper libraries to link with. For linux and solaris, this was libawt_headless. For macosx, this was libawt_lwawt, but also three system frameworks. Note that this patch has a merge conflict with JDK-8199606. The end result of both patches are shown in the patch (that is, with -lc removed). I will make sure to resolve the conflicts properly when committing this patch. I have run COMPARE_BUILDS, with expected results. That is, no changes for Windows, and a deps change for macosx, linux and solaris. I also got a symbol change for linux, since the symbols from libawt_headless changed from e.g. "AWTCharAdvance" to "AWTCharAdvance@@SUNWprivate_1.1". And of course, when you do linking changes, you also end up getting binary/disasm changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8199608 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.01 From hs at tagtraum.com Wed Mar 14 12:23:55 2018 From: hs at tagtraum.com (Hendrik Schreiber) Date: Wed, 14 Mar 2018 13:23:55 +0100 Subject: Windows: Replace VisualStudio with gcc/clang? In-Reply-To: References: <400d7b7a-9d81-2853-1c5b-a969769b0fb3@oracle.com> Message-ID: <8B2F61A6-541B-4B6A-8E12-F65425BCF445@tagtraum.com> >> >> From my perspective, something needs to change, as I found it >> completely impossible to install the old Visual Studio releases the >> JDK demands (and it took ages just to find them). Requiring outdated >> tooling to build the JDK really isn't great. >> >> Stephen >> > > I agree. This is what I meant when I wrote earlier: > > "Also, installing Visual Studio could be easier by making sure that we > always can build with the latest community version, early when it comes > out. Since it is not so easy to find community/express/whatever downloads > for earlier versions of Visual Studio. " I guess, if you have a clean system that you use for nothing else but playing with OpenJDK, it?s relatively easy. But I have found that keeping multiple VS installations in parallel on a single machine is challenging to say the least. Whenever I want to do something for OpenJDK, I fear for other build environments that have different needs. The gcc/clang suggestion was born out of the assumption that they are much easier to manage/choose from the command line. I still remember the hoops one had to jump through to get a 64bit compiler installed under VS. This all may just be ?perceived? difficulties due to unfamiliarity, but they?re still real. The Visual Studio Build Tools may solve most of the issues I have with VS. And perhaps it?s less of a monster to download. -hendrik From chris.hegarty at oracle.com Wed Mar 14 12:56:55 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 14 Mar 2018 12:56:55 +0000 Subject: RFR 8199464 [11] Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass Message-ID: <55f25b38-f5c6-041a-ce18-29e28b164923@oracle.com> This is a review request to remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass. JDK-8179424 removed terminally deprecated jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these references are to the no-args getCallerClass that was removed a long time ago. These should be cleaned up anyway. diff --git a/make/mapfiles/libjava/reorder-sparc b/make/mapfiles/libjava/reorder-sparc --- a/make/mapfiles/libjava/reorder-sparc +++ b/make/mapfiles/libjava/reorder-sparc @@ -26,7 +26,6 @@ text: .text%Java_java_io_FileDescriptor_initIDs; text: .text%Java_java_io_FileOutputStream_initIDs; text: .text%Java_java_lang_System_setIn0; -text: .text%Java_sun_reflect_Reflection_getCallerClass__; text: .text%Java_java_lang_Class_forName0; text: .text%Java_java_lang_Object_getClass; text: .text%Java_sun_reflect_Reflection_getClassAccessFlags; diff --git a/make/mapfiles/libjava/reorder-sparcv9 b/make/mapfiles/libjava/reorder-sparcv9 --- a/make/mapfiles/libjava/reorder-sparcv9 +++ b/make/mapfiles/libjava/reorder-sparcv9 @@ -25,7 +25,6 @@ text: .text%Java_java_io_FileDescriptor_initIDs; text: .text%Java_java_io_FileOutputStream_initIDs; text: .text%Java_java_lang_System_setIn0; -text: .text%Java_sun_reflect_Reflection_getCallerClass__; text: .text%Java_java_lang_Class_forName0; text: .text%Java_java_lang_String_intern; text: .text%Java_java_lang_StringUTF16_isBigEndian; diff --git a/make/mapfiles/libjava/reorder-x86 b/make/mapfiles/libjava/reorder-x86 --- a/make/mapfiles/libjava/reorder-x86 +++ b/make/mapfiles/libjava/reorder-x86 @@ -26,7 +26,6 @@ text: .text%Java_java_io_FileDescriptor_initIDs; text: .text%Java_java_io_FileOutputStream_initIDs; text: .text%Java_java_lang_System_setIn0; -text: .text%Java_sun_reflect_Reflection_getCallerClass__; text: .text%Java_java_lang_Class_forName0; text: .text%Java_java_lang_String_intern; text: .text%Java_java_lang_StringUTF16_isBigEndian; -Chris. From christoph.langer at sap.com Wed Mar 14 13:02:42 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 14 Mar 2018 13:02:42 +0000 Subject: RFR 8199464 [11] Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass In-Reply-To: <55f25b38-f5c6-041a-ce18-29e28b164923@oracle.com> References: <55f25b38-f5c6-041a-ce18-29e28b164923@oracle.com> Message-ID: <5542b73fd80246aaadd437e6dd17037e@sap.com> Looks good, Chris. > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Chris Hegarty > Sent: Mittwoch, 14. M?rz 2018 13:57 > To: build-dev ; Core-Libs-Dev dev at openjdk.java.net> > Subject: RFR 8199464 [11] Remove remaining vestiges of > Java_sun_reflect_Reflection_getCallerClass > > This is a review request to remove remaining vestiges of > Java_sun_reflect_Reflection_getCallerClass. > > JDK-8179424 removed terminally deprecated > jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these > references are to the no-args getCallerClass that was removed a long > time ago. These should be cleaned up anyway. > > > diff --git a/make/mapfiles/libjava/reorder-sparc > b/make/mapfiles/libjava/reorder-sparc > --- a/make/mapfiles/libjava/reorder-sparc > +++ b/make/mapfiles/libjava/reorder-sparc > @@ -26,7 +26,6 @@ > text: .text%Java_java_io_FileDescriptor_initIDs; > text: .text%Java_java_io_FileOutputStream_initIDs; > text: .text%Java_java_lang_System_setIn0; > -text: .text%Java_sun_reflect_Reflection_getCallerClass__; > text: .text%Java_java_lang_Class_forName0; > text: .text%Java_java_lang_Object_getClass; > text: .text%Java_sun_reflect_Reflection_getClassAccessFlags; > diff --git a/make/mapfiles/libjava/reorder-sparcv9 > b/make/mapfiles/libjava/reorder-sparcv9 > --- a/make/mapfiles/libjava/reorder-sparcv9 > +++ b/make/mapfiles/libjava/reorder-sparcv9 > @@ -25,7 +25,6 @@ > text: .text%Java_java_io_FileDescriptor_initIDs; > text: .text%Java_java_io_FileOutputStream_initIDs; > text: .text%Java_java_lang_System_setIn0; > -text: .text%Java_sun_reflect_Reflection_getCallerClass__; > text: .text%Java_java_lang_Class_forName0; > text: .text%Java_java_lang_String_intern; > text: .text%Java_java_lang_StringUTF16_isBigEndian; > diff --git a/make/mapfiles/libjava/reorder-x86 > b/make/mapfiles/libjava/reorder-x86 > --- a/make/mapfiles/libjava/reorder-x86 > +++ b/make/mapfiles/libjava/reorder-x86 > @@ -26,7 +26,6 @@ > text: .text%Java_java_io_FileDescriptor_initIDs; > text: .text%Java_java_io_FileOutputStream_initIDs; > text: .text%Java_java_lang_System_setIn0; > -text: .text%Java_sun_reflect_Reflection_getCallerClass__; > text: .text%Java_java_lang_Class_forName0; > text: .text%Java_java_lang_String_intern; > text: .text%Java_java_lang_StringUTF16_isBigEndian; > > > -Chris. From Alan.Bateman at oracle.com Wed Mar 14 13:08:46 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Mar 2018 13:08:46 +0000 Subject: RFR 8199464 [11] Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass In-Reply-To: <55f25b38-f5c6-041a-ce18-29e28b164923@oracle.com> References: <55f25b38-f5c6-041a-ce18-29e28b164923@oracle.com> Message-ID: On 14/03/2018 12:56, Chris Hegarty wrote: > This is a review request to remove remaining vestiges of > Java_sun_reflect_Reflection_getCallerClass. > > JDK-8179424 removed terminally deprecated > jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these > references are to the no-args getCallerClass that was removed a long > time ago. These should be cleaned up anyway. Looks okay to me. AFAIK, the reorder- files are essentially obsolete, at least I haven't seen any updates promoted by startup benchmarks in a long time. -Alan From chris.hegarty at oracle.com Wed Mar 14 13:18:21 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 14 Mar 2018 13:18:21 +0000 Subject: RFR 8199464 [11] Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass In-Reply-To: References: <55f25b38-f5c6-041a-ce18-29e28b164923@oracle.com> Message-ID: <0e2a54a6-283e-814c-6e6a-bbcfb8e1b660@oracle.com> On 14/03/18 13:08, Alan Bateman wrote: > On 14/03/2018 12:56, Chris Hegarty wrote: >> This is a review request to remove remaining vestiges of >> Java_sun_reflect_Reflection_getCallerClass. >> >> JDK-8179424 removed terminally deprecated >> jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these >> references are to the no-args getCallerClass that was removed a long >> time ago. These should be cleaned up anyway. > Looks okay to me. AFAIK, the reorder- files are essentially > obsolete, at least I haven't seen any updates promoted by startup > benchmarks in a long time. The following warning was noted recently in 8179424, so I decided to just remove these. Somebody must be still using them :-( ld: warning: mapfile: text segment: section '.text%Java_sun_reflect_Reflection_getCallerClass__' does not appear in any input file -Chris. From erik.joelsson at oracle.com Wed Mar 14 14:43:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Mar 2018 07:43:40 -0700 Subject: RFR: JDK-8199606 Set -lc as global LIBS on solstudio In-Reply-To: <89fd177e-db85-b015-0672-64fcdbd61bf0@oracle.com> References: <89fd177e-db85-b015-0672-64fcdbd61bf0@oracle.com> Message-ID: <98d9563b-4aab-6186-2662-ddc55d5a2b69@oracle.com> Hello, Nice to see this cleaned up! The differences you mention were the reason I meticulously kept all the -lc in the exact same places as the old build did way back when we rewrote the build system. I highly doubt they matter, but they needed to be eliminated for a clean switch of build systems. This change should however be fine as it's controlled and we know what we are changing. libraries.m4: 153: This line is now redundant. Otherwise this looks good. /Erik On 2018-03-14 04:17, Magnus Ihse Bursie wrote: > We should always use -lc when linking with solstudio. All other > toolchains do this automatically. This also means that -lc is > unnecessary for other platforms, where it has been set in some cases > (due to the old confusion where "solaris" really meant "unix"). > > I have tested this using COMPARE_BUILD. Unsurprisingly, there are > differences, but they are expected. On macosx and linux, libunpack has > disassembly differences (they had previously an explicit -lc). On > linux, the same also goes for libjli, libawt_xawt, libfontmanager and > libsunec. > > On solaris there are even more differences. Now all libraries get > explicitely linked with -lc, which means binary/disassembly > differences in multiple libraries.? We also get a deps difference for > libjsig and librmi, which were previously compiled (successfully, for > a change! :-)) without -lc. Finally, we get a symbol difference for > libjava.We're missing symbols like: "a s_finite.c" and "t finite", and > we have one less duplicate of "r two54". I can't say I understand why, > but it does seem harmless. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199606 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199606-set-lc-as-GLOBAL_LIBS/webrev.01 > > /Magnus From erik.joelsson at oracle.com Wed Mar 14 14:59:46 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Mar 2018 07:59:46 -0700 Subject: RFR: JDK-8199608 Clean up LDFLAGS for libfontmanager In-Reply-To: References: Message-ID: This change is unfortunately not correct for Linux and Solaris. We cannot link libfontmanager explicitly against either libawt_xawt or libawt_headless. See https://bugs.openjdk.java.net/browse/JDK-8196516 for my suggestion on a better fix than we currently have. I was hoping for Severin to check it out and pick it up, but he is away for a bit so that hasn't happened. The reason we cannot link explicitly is that we need to decide at runtime whether to pull in the headful or headless libraries. If one or the other is already pulled in, and we explicitly load the other, the runtime linker will lookup the common symbols in one or the other in an unpredictable way. Some users get the correct behavior, some get the wrong behavior. We recently had discussions around this on this list if you want to dive deeper into it. Also see https://bugs.openjdk.java.net/browse/JDK-8194870 for one of the consequences of explicit linking here. I think the mac part is ok though, but Phil has to have a look. For Linux and Solaris, if you could remove the -lawt_headless and add "-Xlinker --unresolved-symbols=ignore-all" to LDFLAGS for linux I think we should be good. /Erik On 2018-03-14 04:45, Magnus Ihse Bursie wrote: > This is the final LDFLAGS cleanup, which required some more work to > resolve. > > Libfontmanager had previously explicitely disabled -z defs, with the > result that linking did not complain about missing libraries. To fix > this, I had to provide the proper libraries to link with. For linux > and solaris, this was libawt_headless. For macosx, this was > libawt_lwawt, but also three system frameworks. > > Note that this patch has a merge conflict with JDK-8199606. The end > result of both patches are shown in the patch (that is, with -lc > removed). I will make sure to resolve the conflicts properly when > committing this patch. > > I have run COMPARE_BUILDS, with expected results. That is, no changes > for Windows, and a deps change for macosx, linux and solaris. I also > got a symbol change for linux, since the symbols from libawt_headless > changed from e.g. "AWTCharAdvance" to > "AWTCharAdvance@@SUNWprivate_1.1". And of course, when you do linking > changes, you also end up getting binary/disasm changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199608 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.01 > From mandy.chung at oracle.com Wed Mar 14 15:48:28 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 14 Mar 2018 08:48:28 -0700 Subject: RFR 8199464 [11] Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass In-Reply-To: <55f25b38-f5c6-041a-ce18-29e28b164923@oracle.com> References: <55f25b38-f5c6-041a-ce18-29e28b164923@oracle.com> Message-ID: Looks okay. Mandy On 3/14/18 5:56 AM, Chris Hegarty wrote: > This is a review request to remove remaining vestiges of > Java_sun_reflect_Reflection_getCallerClass. > > JDK-8179424 removed terminally deprecated > jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these > references are to the no-args getCallerClass that was removed a long > time ago. These should be cleaned up anyway. > > > diff --git a/make/mapfiles/libjava/reorder-sparc > b/make/mapfiles/libjava/reorder-sparc > --- a/make/mapfiles/libjava/reorder-sparc > +++ b/make/mapfiles/libjava/reorder-sparc > @@ -26,7 +26,6 @@ > ?text: .text%Java_java_io_FileDescriptor_initIDs; > ?text: .text%Java_java_io_FileOutputStream_initIDs; > ?text: .text%Java_java_lang_System_setIn0; > -text: .text%Java_sun_reflect_Reflection_getCallerClass__; > ?text: .text%Java_java_lang_Class_forName0; > ?text: .text%Java_java_lang_Object_getClass; > ?text: .text%Java_sun_reflect_Reflection_getClassAccessFlags; > diff --git a/make/mapfiles/libjava/reorder-sparcv9 > b/make/mapfiles/libjava/reorder-sparcv9 > --- a/make/mapfiles/libjava/reorder-sparcv9 > +++ b/make/mapfiles/libjava/reorder-sparcv9 > @@ -25,7 +25,6 @@ > ?text: .text%Java_java_io_FileDescriptor_initIDs; > ?text: .text%Java_java_io_FileOutputStream_initIDs; > ?text: .text%Java_java_lang_System_setIn0; > -text: .text%Java_sun_reflect_Reflection_getCallerClass__; > ?text: .text%Java_java_lang_Class_forName0; > ?text: .text%Java_java_lang_String_intern; > ?text: .text%Java_java_lang_StringUTF16_isBigEndian; > diff --git a/make/mapfiles/libjava/reorder-x86 > b/make/mapfiles/libjava/reorder-x86 > --- a/make/mapfiles/libjava/reorder-x86 > +++ b/make/mapfiles/libjava/reorder-x86 > @@ -26,7 +26,6 @@ > ?text: .text%Java_java_io_FileDescriptor_initIDs; > ?text: .text%Java_java_io_FileOutputStream_initIDs; > ?text: .text%Java_java_lang_System_setIn0; > -text: .text%Java_sun_reflect_Reflection_getCallerClass__; > ?text: .text%Java_java_lang_Class_forName0; > ?text: .text%Java_java_lang_String_intern; > ?text: .text%Java_java_lang_StringUTF16_isBigEndian; > > > -Chris. From philip.race at oracle.com Wed Mar 14 16:23:00 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 14 Mar 2018 09:23:00 -0700 Subject: RFR: JDK-8199606 Set -lc as global LIBS on solstudio In-Reply-To: <89fd177e-db85-b015-0672-64fcdbd61bf0@oracle.com> References: <89fd177e-db85-b015-0672-64fcdbd61bf0@oracle.com> Message-ID: <3bbfd84f-be54-0fb8-1382-d6b7ae0e520e@oracle.com> I suppose you re-applied this patch after merging with my freetype changes but have not fixed up that new section since I still see .. 612 LIBS_solaris := -lc, \ .. which I had to add .. to my surprise .. so this patch is welcome but it presumably can remove line 612 too ? -phil. On 03/14/2018 04:17 AM, Magnus Ihse Bursie wrote: > We should always use -lc when linking with solstudio. All other > toolchains do this automatically. This also means that -lc is > unnecessary for other platforms, where it has been set in some cases > (due to the old confusion where "solaris" really meant "unix"). > > I have tested this using COMPARE_BUILD. Unsurprisingly, there are > differences, but they are expected. On macosx and linux, libunpack has > disassembly differences (they had previously an explicit -lc). On > linux, the same also goes for libjli, libawt_xawt, libfontmanager and > libsunec. > > On solaris there are even more differences. Now all libraries get > explicitely linked with -lc, which means binary/disassembly > differences in multiple libraries. We also get a deps difference for > libjsig and librmi, which were previously compiled (successfully, for > a change! :-)) without -lc. Finally, we get a symbol difference for > libjava.We're missing symbols like: "a s_finite.c" and "t finite", and > we have one less duplicate of "r two54". I can't say I understand why, > but it does seem harmless. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199606 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199606-set-lc-as-GLOBAL_LIBS/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Wed Mar 14 18:14:58 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Mar 2018 19:14:58 +0100 Subject: RFR: JDK-8199606 Set -lc as global LIBS on solstudio In-Reply-To: <3bbfd84f-be54-0fb8-1382-d6b7ae0e520e@oracle.com> References: <89fd177e-db85-b015-0672-64fcdbd61bf0@oracle.com> <3bbfd84f-be54-0fb8-1382-d6b7ae0e520e@oracle.com> Message-ID: On 2018-03-14 17:23, Phil Race wrote: > I suppose you re-applied this patch after merging with my freetype > changes > but have not fixed up that new section since I still see .. > ?612?????? LIBS_solaris := -lc, \ > > .. which I had to add .. to my surprise .. so this patch is welcome > but it presumably can remove line 612 too ? Yes, I noticed that when I rebased my patch to the latest changes. Thank you anyway for pointing it out to me! I updated the patch to remove the new -lc for libfreetype as well. /Magnus > > -phil. > > On 03/14/2018 04:17 AM, Magnus Ihse Bursie wrote: >> We should always use -lc when linking with solstudio. All other >> toolchains do this automatically. This also means that -lc is >> unnecessary for other platforms, where it has been set in some cases >> (due to the old confusion where "solaris" really meant "unix"). >> >> I have tested this using COMPARE_BUILD. Unsurprisingly, there are >> differences, but they are expected. On macosx and linux, libunpack >> has disassembly differences (they had previously an explicit -lc). On >> linux, the same also goes for libjli, libawt_xawt, libfontmanager and >> libsunec. >> >> On solaris there are even more differences. Now all libraries get >> explicitely linked with -lc, which means binary/disassembly >> differences in multiple libraries.? We also get a deps difference for >> libjsig and librmi, which were previously compiled (successfully, for >> a change! :-)) without -lc. Finally, we get a symbol difference for >> libjava.We're missing symbols like: "a s_finite.c" and "t finite", >> and we have one less duplicate of "r two54". I can't say I understand >> why, but it does seem harmless. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199606 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8199606-set-lc-as-GLOBAL_LIBS/webrev.01 >> >> /Magnus > From magnus.ihse.bursie at oracle.com Wed Mar 14 20:22:19 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Mar 2018 21:22:19 +0100 Subject: RFR: JDK-8199608 Clean up LDFLAGS for libfontmanager In-Reply-To: References: Message-ID: <7291e911-5aff-36b4-ebef-c1210d9da284@oracle.com> On 2018-03-14 15:59, Erik Joelsson wrote: > This change is unfortunately not correct for Linux and Solaris. We > cannot link libfontmanager explicitly against either libawt_xawt or > libawt_headless. See https://bugs.openjdk.java.net/browse/JDK-8196516 > for my suggestion on a better fix than we currently have. I was hoping > for Severin to check it out and pick it up, but he is away for a bit > so that hasn't happened. > > The reason we cannot link explicitly is that we need to decide at > runtime whether to pull in the headful or headless libraries. If one > or the other is already pulled in, and we explicitly load the other, > the runtime linker will lookup the common symbols in one or the other > in an unpredictable way. Some users get the correct behavior, some get > the wrong behavior. We recently had discussions around this on this > list if you want to dive deeper into it. > > Also see https://bugs.openjdk.java.net/browse/JDK-8194870 for one of > the consequences of explicit linking here. > > I think the mac part is ok though, but Phil has to have a look. For > Linux and Solaris, if you could remove the -lawt_headless and add > "-Xlinker --unresolved-symbols=ignore-all" to LDFLAGS for linux I > think we should be good. Oh, this seems like a fine mess. :-( I see we used to link with libawt_headless for solaris, but removed it in JDK-8194870. Phil remarked in that bug: "We linked against headless before then but allowed undefined symbols JDK 9 switched this to libawt_headless when headless apps failed." but I'm not sure I understand what this really means. I agree it seems likely that the macosx changes is correct. I could probably add -Wl,--unresolved-symbols=ignore-all for gcc on linux, but that is unlikely to work on solstudio. :-( So I'm afraid we're still stuck with the need to remove -z defs for some builds. :-( Question to Phil: Would it be possible to rewrite the code to load and reference the symbols dynamically, using libdl? The problem here is that the functions are declared extern, instead of loaded into a function pointer at runtime. That's how you typically use this kind of runtime-determined dynamic loading. /Magnus > > /Erik > > On 2018-03-14 04:45, Magnus Ihse Bursie wrote: >> This is the final LDFLAGS cleanup, which required some more work to >> resolve. >> >> Libfontmanager had previously explicitely disabled -z defs, with the >> result that linking did not complain about missing libraries. To fix >> this, I had to provide the proper libraries to link with. For linux >> and solaris, this was libawt_headless. For macosx, this was >> libawt_lwawt, but also three system frameworks. >> >> Note that this patch has a merge conflict with JDK-8199606. The end >> result of both patches are shown in the patch (that is, with -lc >> removed). I will make sure to resolve the conflicts properly when >> committing this patch. >> >> I have run COMPARE_BUILDS, with expected results. That is, no changes >> for Windows, and a deps change for macosx, linux and solaris. I also >> got a symbol change for linux, since the symbols from libawt_headless >> changed from e.g. "AWTCharAdvance" to >> "AWTCharAdvance@@SUNWprivate_1.1". And of course, when you do linking >> changes, you also end up getting binary/disasm changes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199608 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.01 >> > From erik.joelsson at oracle.com Wed Mar 14 20:44:18 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Mar 2018 13:44:18 -0700 Subject: RFR: JDK-8199608 Clean up LDFLAGS for libfontmanager In-Reply-To: <7291e911-5aff-36b4-ebef-c1210d9da284@oracle.com> References: <7291e911-5aff-36b4-ebef-c1210d9da284@oracle.com> Message-ID: <9beb7967-722c-e6fb-5e44-0d6de38210cb@oracle.com> On 2018-03-14 13:22, Magnus Ihse Bursie wrote: > On 2018-03-14 15:59, Erik Joelsson wrote: >> This change is unfortunately not correct for Linux and Solaris. We >> cannot link libfontmanager explicitly against either libawt_xawt or >> libawt_headless. See https://bugs.openjdk.java.net/browse/JDK-8196516 >> for my suggestion on a better fix than we currently have. I was >> hoping for Severin to check it out and pick it up, but he is away for >> a bit so that hasn't happened. >> >> The reason we cannot link explicitly is that we need to decide at >> runtime whether to pull in the headful or headless libraries. If one >> or the other is already pulled in, and we explicitly load the other, >> the runtime linker will lookup the common symbols in one or the other >> in an unpredictable way. Some users get the correct behavior, some >> get the wrong behavior. We recently had discussions around this on >> this list if you want to dive deeper into it. >> >> Also see https://bugs.openjdk.java.net/browse/JDK-8194870 for one of >> the consequences of explicit linking here. >> >> I think the mac part is ok though, but Phil has to have a look. For >> Linux and Solaris, if you could remove the -lawt_headless and add >> "-Xlinker --unresolved-symbols=ignore-all" to LDFLAGS for linux I >> think we should be good. > Oh, this seems like a fine mess. :-( > > I see we used to link with libawt_headless for solaris, but removed it > in JDK-8194870. Phil remarked in that bug: "We linked against headless > before then but allowed undefined symbols JDK 9 switched this to > libawt_headless when headless apps failed." but I'm not sure I > understand what this really means. I think he means that we linked with xawt before, but switch to headless at some point. If you run on a machine without X11 present, then if you load xawt, you get a runtime linker error. That was the reason for switching to linking with headless instead. > > I agree it seems likely that the macosx changes is correct. I could > probably add -Wl,--unresolved-symbols=ignore-all for gcc on linux, but > that is unlikely to work on solstudio. :-( So I'm afraid we're still > stuck with the need to remove -z defs for some builds. :-( > On solaris we should be able to override -Wl,-z,defs with -Wl,-z,nodefs later on the link line I think. Perhaps that works on Linux as well. I didn't find nodefs on the Linux man page, but coming to think about it, the "no" prefix should be universal. > Question to Phil: Would it be possible to rewrite the code to load and > reference the symbols dynamically, using libdl? The problem here is > that the functions are declared extern, instead of loaded into a > function pointer at runtime. That's how you typically use this kind of > runtime-determined dynamic loading. > That sounds like a better long term solution. /Erik > /Magnus >> >> /Erik >> >> On 2018-03-14 04:45, Magnus Ihse Bursie wrote: >>> This is the final LDFLAGS cleanup, which required some more work to >>> resolve. >>> >>> Libfontmanager had previously explicitely disabled -z defs, with the >>> result that linking did not complain about missing libraries. To fix >>> this, I had to provide the proper libraries to link with. For linux >>> and solaris, this was libawt_headless. For macosx, this was >>> libawt_lwawt, but also three system frameworks. >>> >>> Note that this patch has a merge conflict with JDK-8199606. The end >>> result of both patches are shown in the patch (that is, with -lc >>> removed). I will make sure to resolve the conflicts properly when >>> committing this patch. >>> >>> I have run COMPARE_BUILDS, with expected results. That is, no >>> changes for Windows, and a deps change for macosx, linux and >>> solaris. I also got a symbol change for linux, since the symbols >>> from libawt_headless changed from e.g. "AWTCharAdvance" to >>> "AWTCharAdvance@@SUNWprivate_1.1". And of course, when you do >>> linking changes, you also end up getting binary/disasm changes. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199608 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.01 >>> >> > From magnus.ihse.bursie at oracle.com Wed Mar 14 20:59:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Mar 2018 21:59:25 +0100 Subject: RFR: JDK-8199608 Clean up LDFLAGS for libfontmanager In-Reply-To: <9beb7967-722c-e6fb-5e44-0d6de38210cb@oracle.com> References: <7291e911-5aff-36b4-ebef-c1210d9da284@oracle.com> <9beb7967-722c-e6fb-5e44-0d6de38210cb@oracle.com> Message-ID: On 2018-03-14 21:44, Erik Joelsson wrote: > On 2018-03-14 13:22, Magnus Ihse Bursie wrote: >> On 2018-03-14 15:59, Erik Joelsson wrote: >>> This change is unfortunately not correct for Linux and Solaris. We >>> cannot link libfontmanager explicitly against either libawt_xawt or >>> libawt_headless. See >>> https://bugs.openjdk.java.net/browse/JDK-8196516 for my suggestion >>> on a better fix than we currently have. I was hoping for Severin to >>> check it out and pick it up, but he is away for a bit so that hasn't >>> happened. >>> >>> The reason we cannot link explicitly is that we need to decide at >>> runtime whether to pull in the headful or headless libraries. If one >>> or the other is already pulled in, and we explicitly load the other, >>> the runtime linker will lookup the common symbols in one or the >>> other in an unpredictable way. Some users get the correct behavior, >>> some get the wrong behavior. We recently had discussions around this >>> on this list if you want to dive deeper into it. >>> >>> Also see https://bugs.openjdk.java.net/browse/JDK-8194870 for one of >>> the consequences of explicit linking here. >>> >>> I think the mac part is ok though, but Phil has to have a look. For >>> Linux and Solaris, if you could remove the -lawt_headless and add >>> "-Xlinker --unresolved-symbols=ignore-all" to LDFLAGS for linux I >>> think we should be good. >> Oh, this seems like a fine mess. :-( >> >> I see we used to link with libawt_headless for solaris, but removed >> it in JDK-8194870. Phil remarked in that bug: "We linked against >> headless before then but allowed undefined symbols JDK 9 switched >> this to libawt_headless when headless apps failed." but I'm not sure >> I understand what this really means. > I think he means that we linked with xawt before, but switch to > headless at some point. If you run on a machine without X11 present, > then if you load xawt, you get a runtime linker error. That was the > reason for switching to linking with headless instead. >> >> I agree it seems likely that the macosx changes is correct. I could >> probably add -Wl,--unresolved-symbols=ignore-all for gcc on linux, >> but that is unlikely to work on solstudio. :-( So I'm afraid we're >> still stuck with the need to remove -z defs for some builds. :-( >> > On solaris we should be able to override -Wl,-z,defs with > -Wl,-z,nodefs later on the link line I think. Unfortunately, that gives the error "-z defs and -z nodefs are mutually exclusive", or something like that. :-( > Perhaps that works on Linux as well. I didn't find nodefs on the Linux > man page, but coming to think about it, the "no" prefix should be > universal. >> Question to Phil: Would it be possible to rewrite the code to load >> and reference the symbols dynamically, using libdl? The problem here >> is that the functions are declared extern, instead of loaded into a >> function pointer at runtime. That's how you typically use this kind >> of runtime-determined dynamic loading. >> > That sounds like a better long term solution. The problem here is the "long" in "long term". :-( What I'm trying to accomplish here is to make sure that all JDK libraries use the LDFLAGS_JDKLIB for linking (and possibly additional flags), not a version with some parts subst:ed out. :( I can't really find a way to accomplish this for solstudio short of fixing this to use proper dynamic linking. /Magnus > > /Erik >> /Magnus >>> >>> /Erik >>> >>> On 2018-03-14 04:45, Magnus Ihse Bursie wrote: >>>> This is the final LDFLAGS cleanup, which required some more work to >>>> resolve. >>>> >>>> Libfontmanager had previously explicitely disabled -z defs, with >>>> the result that linking did not complain about missing libraries. >>>> To fix this, I had to provide the proper libraries to link with. >>>> For linux and solaris, this was libawt_headless. For macosx, this >>>> was libawt_lwawt, but also three system frameworks. >>>> >>>> Note that this patch has a merge conflict with JDK-8199606. The end >>>> result of both patches are shown in the patch (that is, with -lc >>>> removed). I will make sure to resolve the conflicts properly when >>>> committing this patch. >>>> >>>> I have run COMPARE_BUILDS, with expected results. That is, no >>>> changes for Windows, and a deps change for macosx, linux and >>>> solaris. I also got a symbol change for linux, since the symbols >>>> from libawt_headless changed from e.g. "AWTCharAdvance" to >>>> "AWTCharAdvance@@SUNWprivate_1.1". And of course, when you do >>>> linking changes, you also end up getting binary/disasm changes. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199608 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.01 >>>> >>> >> > From philip.race at oracle.com Wed Mar 14 21:05:06 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 14 Mar 2018 14:05:06 -0700 Subject: RFR: JDK-8199608 Clean up LDFLAGS for libfontmanager In-Reply-To: <7291e911-5aff-36b4-ebef-c1210d9da284@oracle.com> References: <7291e911-5aff-36b4-ebef-c1210d9da284@oracle.com> Message-ID: <5e0871d1-41c8-a0bb-cecb-dbb084934b27@oracle.com> >I see we used to link with libawt_headless for solaris, but removed it in >JDK-8194870. Phil remarked in that bug: "We linked against headless before then >but allowed undefined symbols JDK 9 switched this to libawt_headless when >headless apps failed." but I'm not sure I understand what this really means. It means that there is a long and sordid history. When we introduced this code it was as it is now. Some time in JDK 8 (?) it started to link against one of these libs. I'd have to go back and check which one, but definitely in JDK 9 a bug popped up with headless because of explicit linking to xawt .. which pulls in X11. At that time the fix was to switch it to link against headless but that was the wrong fix now as it is then. Somehow it worked OK though as had the xawt linking so long as you had X11 .. until JDK-8194870 and we realised the error. Now we are back to how it was intended in JDK 1.5 (I think). > Question to Phil: Would it be possible to rewrite the code to load and reference the symbols dynamically Whilst it probably is possible, I really don't want to do that it is not really in the spirit of what is intended here as well as being a fair amount of work. This is not an "optional" library. It has to be there. We just don't know which one until runtime. What I'd really like here is a build linker option that at build time verifies that the dependencies are actually satisfied by each of xawt and headless in turn but in neither case writes that library into the produced image as a dependency. For the macos changes, I am supposing you mean you had to add this + LIBS_macosx := -lawt_lwawt -framework CoreText -framework CoreFoundation \ because you removed this - LDFLAGS_macosx := -undefined dynamic_lookup, \ If it builds *and runs* its probably fine :-) Only Solaris + Linux have separate libraries for headful + headless. -phil. On 03/14/2018 01:22 PM, Magnus Ihse Bursie wrote: > On 2018-03-14 15:59, Erik Joelsson wrote: >> This change is unfortunately not correct for Linux and Solaris. We >> cannot link libfontmanager explicitly against either libawt_xawt or >> libawt_headless. See https://bugs.openjdk.java.net/browse/JDK-8196516 >> for my suggestion on a better fix than we currently have. I was >> hoping for Severin to check it out and pick it up, but he is away for >> a bit so that hasn't happened. >> >> The reason we cannot link explicitly is that we need to decide at >> runtime whether to pull in the headful or headless libraries. If one >> or the other is already pulled in, and we explicitly load the other, >> the runtime linker will lookup the common symbols in one or the other >> in an unpredictable way. Some users get the correct behavior, some >> get the wrong behavior. We recently had discussions around this on >> this list if you want to dive deeper into it. >> >> Also see https://bugs.openjdk.java.net/browse/JDK-8194870 for one of >> the consequences of explicit linking here. >> >> I think the mac part is ok though, but Phil has to have a look. For >> Linux and Solaris, if you could remove the -lawt_headless and add >> "-Xlinker --unresolved-symbols=ignore-all" to LDFLAGS for linux I >> think we should be good. > Oh, this seems like a fine mess. :-( > > I see we used to link with libawt_headless for solaris, but removed it > in JDK-8194870. Phil remarked in that bug: "We linked against headless > before then but allowed undefined symbols JDK 9 switched this to > libawt_headless when headless apps failed." but I'm not sure I > understand what this really means. > > I agree it seems likely that the macosx changes is correct. I could > probably add -Wl,--unresolved-symbols=ignore-all for gcc on linux, but > that is unlikely to work on solstudio. :-( So I'm afraid we're still > stuck with the need to remove -z defs for some builds. :-( > > Question to Phil: Would it be possible to rewrite the code to load and > reference the symbols dynamically, using libdl? The problem here is > that the functions are declared extern, instead of loaded into a > function pointer at runtime. That's how you typically use this kind of > runtime-determined dynamic loading. > > /Magnus >> >> /Erik >> >> On 2018-03-14 04:45, Magnus Ihse Bursie wrote: >>> This is the final LDFLAGS cleanup, which required some more work to >>> resolve. >>> >>> Libfontmanager had previously explicitely disabled -z defs, with the >>> result that linking did not complain about missing libraries. To fix >>> this, I had to provide the proper libraries to link with. For linux >>> and solaris, this was libawt_headless. For macosx, this was >>> libawt_lwawt, but also three system frameworks. >>> >>> Note that this patch has a merge conflict with JDK-8199606. The end >>> result of both patches are shown in the patch (that is, with -lc >>> removed). I will make sure to resolve the conflicts properly when >>> committing this patch. >>> >>> I have run COMPARE_BUILDS, with expected results. That is, no >>> changes for Windows, and a deps change for macosx, linux and >>> solaris. I also got a symbol change for linux, since the symbols >>> from libawt_headless changed from e.g. "AWTCharAdvance" to >>> "AWTCharAdvance@@SUNWprivate_1.1". And of course, when you do >>> linking changes, you also end up getting binary/disasm changes. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199608 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.01 >>> >> > From magnus.ihse.bursie at oracle.com Wed Mar 14 21:17:24 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Mar 2018 22:17:24 +0100 Subject: RFR: JDK-8199608 Clean up LDFLAGS for libfontmanager In-Reply-To: <5e0871d1-41c8-a0bb-cecb-dbb084934b27@oracle.com> References: <7291e911-5aff-36b4-ebef-c1210d9da284@oracle.com> <5e0871d1-41c8-a0bb-cecb-dbb084934b27@oracle.com> Message-ID: <9ffc644d-1a2e-b4f0-4cf9-873e9b384bcf@oracle.com> On 2018-03-14 22:05, Phil Race wrote: > > >I see we used to link with libawt_headless for solaris, but removed > it in >JDK-8194870. Phil remarked in that bug: "We linked against > headless before then >but allowed undefined symbols JDK 9 switched > this to libawt_headless when >headless apps failed." but I'm not sure > I understand what this really means. > > It means that there is a long and sordid history. > When we introduced this code it was as it is now. > Some time in JDK 8 (?) it started to link against one of these libs. > I'd have to go back and check which one, but definitely in JDK 9 a bug > popped up with headless because of explicit linking to xawt .. which > pulls in X11. At that time the fix was to switch it to link against > headless > but that was the wrong fix now as it is then. Somehow it worked OK though > as had the xawt linking so long as you had X11 .. until JDK-8194870 and > we realised the error. Now we are back to how it was intended in JDK > 1.5 (I think). Thank you for the explanation! I will think about this fix for a while, and see what I can do about it. For now, consider the review request cancelled. /Magnus > > > Question to Phil: Would it be possible to rewrite the code to load > and reference the symbols dynamically > > Whilst it probably is possible, I really don't want to do that it is not > really in the spirit of what is intended here as well as being a fair > amount of work. > This is not an "optional" library. It has to be there. We just don't > know which one > until runtime. > What I'd really like here is a build linker option that at build time > verifies > that the dependencies are actually satisfied by each of xawt and > headless in turn > but in neither case writes that library into the produced image as a > dependency. > > For the macos changes, I am supposing you mean you had to add this > + LIBS_macosx := -lawt_lwawt -framework CoreText -framework > CoreFoundation \ > > because you removed this > > - LDFLAGS_macosx := -undefined dynamic_lookup, \ > > If it builds *and runs* its probably fine :-) > > Only Solaris + Linux have separate libraries for headful + headless. > > -phil. > > On 03/14/2018 01:22 PM, Magnus Ihse Bursie wrote: >> On 2018-03-14 15:59, Erik Joelsson wrote: >>> This change is unfortunately not correct for Linux and Solaris. We >>> cannot link libfontmanager explicitly against either libawt_xawt or >>> libawt_headless. See >>> https://bugs.openjdk.java.net/browse/JDK-8196516 for my suggestion >>> on a better fix than we currently have. I was hoping for Severin to >>> check it out and pick it up, but he is away for a bit so that hasn't >>> happened. >>> >>> The reason we cannot link explicitly is that we need to decide at >>> runtime whether to pull in the headful or headless libraries. If one >>> or the other is already pulled in, and we explicitly load the other, >>> the runtime linker will lookup the common symbols in one or the >>> other in an unpredictable way. Some users get the correct behavior, >>> some get the wrong behavior. We recently had discussions around this >>> on this list if you want to dive deeper into it. >>> >>> Also see https://bugs.openjdk.java.net/browse/JDK-8194870 for one of >>> the consequences of explicit linking here. >>> >>> I think the mac part is ok though, but Phil has to have a look. For >>> Linux and Solaris, if you could remove the -lawt_headless and add >>> "-Xlinker --unresolved-symbols=ignore-all" to LDFLAGS for linux I >>> think we should be good. >> Oh, this seems like a fine mess. :-( >> >> I see we used to link with libawt_headless for solaris, but removed >> it in JDK-8194870. Phil remarked in that bug: "We linked against >> headless before then but allowed undefined symbols JDK 9 switched >> this to libawt_headless when headless apps failed." but I'm not sure >> I understand what this really means. >> >> I agree it seems likely that the macosx changes is correct. I could >> probably add -Wl,--unresolved-symbols=ignore-all for gcc on linux, >> but that is unlikely to work on solstudio. :-( So I'm afraid we're >> still stuck with the need to remove -z defs for some builds. :-( >> >> Question to Phil: Would it be possible to rewrite the code to load >> and reference the symbols dynamically, using libdl? The problem here >> is that the functions are declared extern, instead of loaded into a >> function pointer at runtime. That's how you typically use this kind >> of runtime-determined dynamic loading. >> >> /Magnus >>> >>> /Erik >>> >>> On 2018-03-14 04:45, Magnus Ihse Bursie wrote: >>>> This is the final LDFLAGS cleanup, which required some more work to >>>> resolve. >>>> >>>> Libfontmanager had previously explicitely disabled -z defs, with >>>> the result that linking did not complain about missing libraries. >>>> To fix this, I had to provide the proper libraries to link with. >>>> For linux and solaris, this was libawt_headless. For macosx, this >>>> was libawt_lwawt, but also three system frameworks. >>>> >>>> Note that this patch has a merge conflict with JDK-8199606. The end >>>> result of both patches are shown in the patch (that is, with -lc >>>> removed). I will make sure to resolve the conflicts properly when >>>> committing this patch. >>>> >>>> I have run COMPARE_BUILDS, with expected results. That is, no >>>> changes for Windows, and a deps change for macosx, linux and >>>> solaris. I also got a symbol change for linux, since the symbols >>>> from libawt_headless changed from e.g. "AWTCharAdvance" to >>>> "AWTCharAdvance@@SUNWprivate_1.1". And of course, when you do >>>> linking changes, you also end up getting binary/disasm changes. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199608 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.01 >>>> >>> >> > From magnus.ihse.bursie at oracle.com Wed Mar 14 21:50:48 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Mar 2018 22:50:48 +0100 Subject: RFR: JDK-8199636 Unify naming for jaas_unix and jaas_nt Message-ID: <0c202e34-28f6-4187-22bf-86308c7a17b8@oracle.com> For some odd reason, the native library compiled for jdk.security.auth is called jaas_unix on unix and jaas_nt on windows. There's no good reason for this, and it breaks with the common practice in OpenJDK. This patch renames both libraries to the basename "jaas" (that is, libjaas.so, libjaas.dylib or jaas.dll, depending on OS). Bug: https://bugs.openjdk.java.net/browse/JDK-8199636 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199636-rename-libjaas/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Mar 14 23:18:10 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 00:18:10 +0100 Subject: RFR: JDK-8199640 Split up BUILD_LIBKRB5 into the two, unrelated compilations it consists of Message-ID: <0d4f4ca2-822a-6cc6-0de0-3f135193e48f@oracle.com> BUILD_LIBKRB5 is currently a strange chimera between compiling w2k_lsa_auth on windows, and osxkrb5 on macos. They do not share source code, name or compilation options. This patch separates them into two separate compilations, one for each platform, so that they then can follow the normal JDK pattern for compiling libs. Bug: https://bugs.openjdk.java.net/browse/JDK-8199640 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199640-split-up-BUILD_LIBJRB5/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Mar 14 23:24:35 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Mar 2018 16:24:35 -0700 Subject: RFR: JDK-8199636 Unify naming for jaas_unix and jaas_nt In-Reply-To: <0c202e34-28f6-4187-22bf-86308c7a17b8@oracle.com> References: <0c202e34-28f6-4187-22bf-86308c7a17b8@oracle.com> Message-ID: <65dea355-7865-3170-8ab4-24cc98529be0@oracle.com> Looks good. /Erik On 2018-03-14 14:50, Magnus Ihse Bursie wrote: > For some odd reason, the native library compiled for jdk.security.auth > is called jaas_unix on unix and jaas_nt on windows. There's no good > reason for this, and it breaks with the common practice in OpenJDK. > > This patch renames both libraries to the basename "jaas" (that is, > libjaas.so, libjaas.dylib or jaas.dll, depending on OS). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199636 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199636-rename-libjaas/webrev.01 > > /Magnus From erik.joelsson at oracle.com Wed Mar 14 23:25:35 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Mar 2018 16:25:35 -0700 Subject: RFR: JDK-8199640 Split up BUILD_LIBKRB5 into the two, unrelated compilations it consists of In-Reply-To: <0d4f4ca2-822a-6cc6-0de0-3f135193e48f@oracle.com> References: <0d4f4ca2-822a-6cc6-0de0-3f135193e48f@oracle.com> Message-ID: <51ccdc51-354e-4230-098f-65d8b07fda73@oracle.com> Looks good. /Erik On 2018-03-14 16:18, Magnus Ihse Bursie wrote: > BUILD_LIBKRB5 is currently a strange chimera between compiling > w2k_lsa_auth on windows, and osxkrb5 on macos. They do not share > source code, name or compilation options. > > This patch separates them into two separate compilations, one for each > platform, so that they then can follow the normal JDK pattern for > compiling libs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199640 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199640-split-up-BUILD_LIBJRB5/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Wed Mar 14 23:34:37 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 00:34:37 +0100 Subject: RFR: JDK-8199639 Introduce SetupJdkLibrary and SetupJdkExecutable Message-ID: We have a lot of code duplication in all our calls to SetupNativeCompilation. This patch introduces a pair of functions, SetupJdkLibrary and SetupJdkExecutable, which wraps SetupNativeCompilation and sets up typical default values for our JDK libraries. The long-term idea here is that even more functionality (e.g. basic LDFLAGS and CFLAGS) should move into these two functions, but for simplicity, this patch just does the most basic cleanup. Not all compilations were easily converted. Those were left behind at using SetupNativeCompilation, just as before. If possible, they should be fixed and converted at a later date. I have run a BUILD_COMPARE test on this change. It passes completely clean on linux and solaris. On macosx, I get "binary" differences on libosxkrb5, libjaas_unix and a handful of lauchers. I can't say why, there's no change in symbols, deps, or disasm. On windows, I get a minor disasm change in sawindbg. Bug: https://bugs.openjdk.java.net/browse/JDK-8199639 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199639-introduce-SetupJdkLibrary/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Mar 14 23:51:04 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Mar 2018 16:51:04 -0700 Subject: RFR: JDK-8199639 Introduce SetupJdkLibrary and SetupJdkExecutable In-Reply-To: References: Message-ID: Hello, The diff in sawindbg is likely that it now has RC_FLAGS. Should it? I would guess yes, it should be treated just as all the others. Otherwise this looks good. /Erik On 2018-03-14 16:34, Magnus Ihse Bursie wrote: > We have a lot of code duplication in all our calls to > SetupNativeCompilation. This patch introduces a pair of functions, > SetupJdkLibrary and SetupJdkExecutable, which wraps > SetupNativeCompilation and sets up typical default values for our JDK > libraries. > > The long-term idea here is that even more functionality (e.g. basic > LDFLAGS and CFLAGS) should move into these two functions, but for > simplicity, this patch just does the most basic cleanup. > > Not all compilations were easily converted. Those were left behind at > using SetupNativeCompilation, just as before. If possible, they should > be fixed and converted at a later date. > > I have run a BUILD_COMPARE test on this change. It passes completely > clean on linux and solaris. On macosx, I get "binary" differences on > libosxkrb5, libjaas_unix and a handful of lauchers. I can't say why, > there's no change in symbols, deps, or disasm. On windows, I get a > minor disasm change in sawindbg. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199639 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199639-introduce-SetupJdkLibrary/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Thu Mar 15 00:20:18 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 01:20:18 +0100 Subject: RFR: JDK-8199639 Introduce SetupJdkLibrary and SetupJdkExecutable In-Reply-To: References: Message-ID: <2c466600-f2c1-4a51-50f7-fcf84719b4fb@oracle.com> On 2018-03-15 00:51, Erik Joelsson wrote: > Hello, > > The diff in sawindbg is likely that it now has RC_FLAGS. Should it? I > would guess yes, it should be treated just as all the others. Of course! Yes, it should definitely have them. It's the historical baggage for sawindbg that has caused it not to have it. > > Otherwise this looks good. Thanks! /Magnus > > /Erik > > > On 2018-03-14 16:34, Magnus Ihse Bursie wrote: >> We have a lot of code duplication in all our calls to >> SetupNativeCompilation. This patch introduces a pair of functions, >> SetupJdkLibrary and SetupJdkExecutable, which wraps >> SetupNativeCompilation and sets up typical default values for our JDK >> libraries. >> >> The long-term idea here is that even more functionality (e.g. basic >> LDFLAGS and CFLAGS) should move into these two functions, but for >> simplicity, this patch just does the most basic cleanup. >> >> Not all compilations were easily converted. Those were left behind at >> using SetupNativeCompilation, just as before. If possible, they >> should be fixed and converted at a later date. >> >> I have run a BUILD_COMPARE test on this change. It passes completely >> clean on linux and solaris. On macosx, I get "binary" differences on >> libosxkrb5, libjaas_unix and a handful of lauchers. I can't say why, >> there's no change in symbols, deps, or disasm. On windows, I get a >> minor disasm change in sawindbg. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199639 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8199639-introduce-SetupJdkLibrary/webrev.01 >> >> /Magnus > From magnus.ihse.bursie at oracle.com Thu Mar 15 01:07:54 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 02:07:54 +0100 Subject: RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure Message-ID: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> From the bug description: Moving this to a separate bug from JDK-8055190. In SoundLibraries.gmk, the source code splitting is not complete. The directory libjsound is used to build not only libjsound but libjsoundalsa and libjsoundds, and thus needs a complex include/exclude system like before. I have tested this using COMPARE_BUILD. Windows and solaris are completely clean. On macosx, there's a binary diff (but nothing else) on libjsound.dylib. On linux, some offset seems to have changed, which caused a slight change in disass and fulldump for libjsound.so. I'm not quite sure what's causing it, but I'm convinced it's harmless. Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Thu Mar 15 01:12:14 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 02:12:14 +0100 Subject: RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> Message-ID: I forgot to add the client mailing lists as recipients. Sorry. (Not sure if "sounds" belong to "awt" or "2d".) /Magnus On 2018-03-15 02:07, Magnus Ihse Bursie wrote: > From the bug description: > > Moving this to a separate bug from JDK-8055190. In SoundLibraries.gmk, > the source code splitting is not complete. The directory libjsound is > used to build not only libjsound but libjsoundalsa and libjsoundds, > and thus needs a complex include/exclude system like before. > > I have tested this using COMPARE_BUILD. Windows and solaris are > completely clean. On macosx, there's a binary diff (but nothing else) > on libjsound.dylib. On linux, some offset seems to have changed, which > caused a slight change in disass and fulldump for libjsound.so. I'm > not quite sure what's causing it, but I'm convinced it's harmless. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 > > /Magnus > From magnus.ihse.bursie at oracle.com Thu Mar 15 08:59:55 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 09:59:55 +0100 Subject: RFR: JDK-8199668 make/lib cleanup Message-ID: <3dc2005b-c0d4-ee47-8ea0-cced80836548@oracle.com> We have a lot of odd, small files in make/lib, from an attempt to separate libraries that predates the modularization of jigsaw. They do not make sense to keep separate anymore. Also, the library definitions for linux and solaris for jdk.net are virtually identical and should be unified. As the library stanzas continue to shrink with the continuing SetupJdkLibrary patches, I could very well see a future where CoreLibraries and Awt2D/Sound is inlined in java.base and java.desktop, as well. The main reason for splitting them out was to make the files less unwieldy. Bug: https://bugs.openjdk.java.net/browse/JDK-8199668 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199668-make_lib-cleanup/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Thu Mar 15 13:01:36 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 14:01:36 +0100 Subject: RFR: JDK-8199681 Remove boilerplate code from creating native jtreg tests Message-ID: <938bcf1c-ed79-0679-cc43-8a7bc948731f@oracle.com> There's currently a lot of boilerplate code needed to setup a new native jtreg test. This was never the way it was intended to work -- the idea was that you basically should just add the file and then things should work automatically, unless you had special requirements. This patch will make it so once more. I have tested this using COMPARE_BUILD. I get some spurious binary differences on macosx. I can't really say why, but then again, we have never verified the test image by a clean "back-to-back" null comparison either, so I'm not worried. Apart from that, it looks green. Bug: https://bugs.openjdk.java.net/browse/JDK-8199681 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199681-remote-native-test-boilerplate/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Mar 15 14:26:30 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Mar 2018 07:26:30 -0700 Subject: RFR: JDK-8199681 Remove boilerplate code from creating native jtreg tests In-Reply-To: <938bcf1c-ed79-0679-cc43-8a7bc948731f@oracle.com> References: <938bcf1c-ed79-0679-cc43-8a7bc948731f@oracle.com> Message-ID: <7867189a-217f-6c6d-da29-c33f8aa6c731@oracle.com> Looks good. /Erik On 2018-03-15 06:01, Magnus Ihse Bursie wrote: > There's currently a lot of boilerplate code needed to setup a new > native jtreg test. This was never the way it was intended to work -- > the idea was that you basically should just add the file and then > things should work automatically, unless you had special requirements. > > This patch will make it so once more. > > I have tested this using COMPARE_BUILD. I get some spurious binary > differences on macosx. I can't really say why, but then again, we have > never verified the test image by a clean "back-to-back" null > comparison either, so I'm not worried. Apart from that, it looks green. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199681 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199681-remote-native-test-boilerplate/webrev.01 > > /Magnus From erik.joelsson at oracle.com Thu Mar 15 14:22:42 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Mar 2018 07:22:42 -0700 Subject: RFR: JDK-8199668 make/lib cleanup In-Reply-To: <3dc2005b-c0d4-ee47-8ea0-cced80836548@oracle.com> References: <3dc2005b-c0d4-ee47-8ea0-cced80836548@oracle.com> Message-ID: Looks good! /Erik On 2018-03-15 01:59, Magnus Ihse Bursie wrote: > We have a lot of odd, small files in make/lib, from an attempt to > separate libraries that predates the modularization of jigsaw. They do > not make sense to keep separate anymore. > > Also, the library definitions for linux and solaris for jdk.net are > virtually identical and should be unified. > > As the library stanzas continue to shrink with the continuing > SetupJdkLibrary patches, I could very well see a future where > CoreLibraries and Awt2D/Sound is inlined in java.base and > java.desktop, as well. The main reason for splitting them out was to > make the files less unwieldy. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199668 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199668-make_lib-cleanup/webrev.01 > > /Magnus From erik.joelsson at oracle.com Thu Mar 15 14:20:38 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Mar 2018 07:20:38 -0700 Subject: RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> Message-ID: <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> Looks good to me. I tried cleaning this up before but failed to find a reasonable split, but this seems like a good split between common and library specific. /Erik On 2018-03-14 18:12, Magnus Ihse Bursie wrote: > I forgot to add the client mailing lists as recipients. Sorry. (Not > sure if "sounds" belong to "awt" or "2d".) > > /Magnus > > On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >> From the bug description: >> >> Moving this to a separate bug from JDK-8055190. In >> SoundLibraries.gmk, the source code splitting is not complete. The >> directory libjsound is used to build not only libjsound but >> libjsoundalsa and libjsoundds, and thus needs a complex >> include/exclude system like before. >> >> I have tested this using COMPARE_BUILD. Windows and solaris are >> completely clean. On macosx, there's a binary diff (but nothing else) >> on libjsound.dylib. On linux, some offset seems to have changed, >> which caused a slight change in disass and fulldump for libjsound.so. >> I'm not quite sure what's causing it, but I'm convinced it's harmless. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >> >> /Magnus >> > From philip.race at oracle.com Thu Mar 15 16:53:39 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 15 Mar 2018 09:53:39 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> Message-ID: <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> It is very hard to follow all the moved around files, but one thing that sticks out is there is a "bsd" directory created and I can't work out how the files in there are used. If they are for a BSD port of OpenJDK where is rest of the support for that ? On 03/15/2018 07:20 AM, Erik Joelsson wrote: > Looks good to me. I tried cleaning this up before but failed to find a > reasonable split, but this seems like a good split between common and > library specific. > > /Erik > > > On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >> I forgot to add the client mailing lists as recipients. Sorry. (Not >> sure if "sounds" belong to "awt" or "2d".) In fact, there is a sound-specific list, which I've added. -phil. >> >> /Magnus >> >> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>> From the bug description: >>> >>> Moving this to a separate bug from JDK-8055190. In >>> SoundLibraries.gmk, the source code splitting is not complete. The >>> directory libjsound is used to build not only libjsound but >>> libjsoundalsa and libjsoundds, and thus needs a complex >>> include/exclude system like before. >>> >>> I have tested this using COMPARE_BUILD. Windows and solaris are >>> completely clean. On macosx, there's a binary diff (but nothing >>> else) on libjsound.dylib. On linux, some offset seems to have >>> changed, which caused a slight change in disass and fulldump for >>> libjsound.so. I'm not quite sure what's causing it, but I'm >>> convinced it's harmless. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>> >>> /Magnus >>> >> > From erik.joelsson at oracle.com Thu Mar 15 17:21:14 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Mar 2018 10:21:14 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> Message-ID: <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> Digging a bit, those files came with the initial Macosx support. It doesn't look like they were ever used. /Erik On 2018-03-15 09:53, Phil Race wrote: > It is very hard to follow all the moved around files, but one thing > that sticks out is there is a "bsd" directory created and I can't > work out how the files in there are used. > If they are for a BSD port of OpenJDK where is rest of the support for > that ? > > On 03/15/2018 07:20 AM, Erik Joelsson wrote: >> Looks good to me. I tried cleaning this up before but failed to find >> a reasonable split, but this seems like a good split between common >> and library specific. >> >> /Erik >> >> >> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>> I forgot to add the client mailing lists as recipients. Sorry. (Not >>> sure if "sounds" belong to "awt" or "2d".) > > In fact, there is a sound-specific list, which I've added. > > -phil. >>> >>> /Magnus >>> >>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>> From the bug description: >>>> >>>> Moving this to a separate bug from JDK-8055190. In >>>> SoundLibraries.gmk, the source code splitting is not complete. The >>>> directory libjsound is used to build not only libjsound but >>>> libjsoundalsa and libjsoundds, and thus needs a complex >>>> include/exclude system like before. >>>> >>>> I have tested this using COMPARE_BUILD. Windows and solaris are >>>> completely clean. On macosx, there's a binary diff (but nothing >>>> else) on libjsound.dylib. On linux, some offset seems to have >>>> changed, which caused a slight change in disass and fulldump for >>>> libjsound.so. I'm not quite sure what's causing it, but I'm >>>> convinced it's harmless. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>> >>>> /Magnus >>>> >>> >> > From philip.race at oracle.com Thu Mar 15 17:23:19 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 15 Mar 2018 10:23:19 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> Message-ID: I wondered if that might be the case since it was a "BSD" port .. using X11 .. Maybe we should be getting rid of them ? -phil. On 03/15/2018 10:21 AM, Erik Joelsson wrote: > Digging a bit, those files came with the initial Macosx support. It > doesn't look like they were ever used. > > /Erik > > > On 2018-03-15 09:53, Phil Race wrote: >> It is very hard to follow all the moved around files, but one thing >> that sticks out is there is a "bsd" directory created and I can't >> work out how the files in there are used. >> If they are for a BSD port of OpenJDK where is rest of the support >> for that ? >> >> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>> Looks good to me. I tried cleaning this up before but failed to find >>> a reasonable split, but this seems like a good split between common >>> and library specific. >>> >>> /Erik >>> >>> >>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>> I forgot to add the client mailing lists as recipients. Sorry. (Not >>>> sure if "sounds" belong to "awt" or "2d".) >> >> In fact, there is a sound-specific list, which I've added. >> >> -phil. >>>> >>>> /Magnus >>>> >>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>> From the bug description: >>>>> >>>>> Moving this to a separate bug from JDK-8055190. In >>>>> SoundLibraries.gmk, the source code splitting is not complete. The >>>>> directory libjsound is used to build not only libjsound but >>>>> libjsoundalsa and libjsoundds, and thus needs a complex >>>>> include/exclude system like before. >>>>> >>>>> I have tested this using COMPARE_BUILD. Windows and solaris are >>>>> completely clean. On macosx, there's a binary diff (but nothing >>>>> else) on libjsound.dylib. On linux, some offset seems to have >>>>> changed, which caused a slight change in disass and fulldump for >>>>> libjsound.so. I'm not quite sure what's causing it, but I'm >>>>> convinced it's harmless. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>> >>>>> /Magnus >>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Thu Mar 15 18:13:51 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 19:13:51 +0100 Subject: RFR: JDK-8199703 Update platform.policy after JDK-8199636 Message-ID: <27A1F5C7-D60A-4EF4-A483-70EFF58B7258@oracle.com> It turned out that the jaas_nt/jaas_unix names were hardcoded in a test. Following JDK-8199636, this test must also be updated. Bug: https://bugs.openjdk.java.net/browse/JDK-8199703 Patch inline: diff --git a/closed/test/jdk/com/sun/security/auth/module/PlatformLoginModule/platform.policy b/closed/test/jdk/com/sun/security/auth/module/PlatformLoginModule/platform.policy --- a/closed/test/jdk/com/sun/security/auth/module/PlatformLoginModule/platform.policy +++ b/closed/test/jdk/com/sun/security/auth/module/PlatformLoginModule/platform.policy @@ -4,6 +4,5 @@ grant codebase "file:./platform.jar" { - permission java.lang.RuntimePermission "loadLibrary.jaas_unix"; - permission java.lang.RuntimePermission "loadLibrary.jaas_nt"; + permission java.lang.RuntimePermission "loadLibrary.jaas"; }; /Magnus From erik.joelsson at oracle.com Thu Mar 15 18:15:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Mar 2018 11:15:43 -0700 Subject: RFR: JDK-8199703 Update platform.policy after JDK-8199636 In-Reply-To: <27A1F5C7-D60A-4EF4-A483-70EFF58B7258@oracle.com> References: <27A1F5C7-D60A-4EF4-A483-70EFF58B7258@oracle.com> Message-ID: Looks good. /Erik On 2018-03-15 11:13, Magnus Ihse Bursie wrote: > It turned out that the jaas_nt/jaas_unix names were hardcoded in a test. Following JDK-8199636, this test must also be updated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199703 > Patch inline: > diff --git a/closed/test/jdk/com/sun/security/auth/module/PlatformLoginModule/platform.policy b/closed/test/jdk/com/sun/security/auth/module/PlatformLoginModule/platform.policy > --- a/closed/test/jdk/com/sun/security/auth/module/PlatformLoginModule/platform.policy > +++ b/closed/test/jdk/com/sun/security/auth/module/PlatformLoginModule/platform.policy > @@ -4,6 +4,5 @@ > > grant codebase "file:./platform.jar" { > > - permission java.lang.RuntimePermission "loadLibrary.jaas_unix"; > - permission java.lang.RuntimePermission "loadLibrary.jaas_nt"; > + permission java.lang.RuntimePermission "loadLibrary.jaas"; > }; > > /Magnus From magnus.ihse.bursie at oracle.com Thu Mar 15 18:22:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 19:22:17 +0100 Subject: RFR: JDK-8199682 Clean up building the saproc library Message-ID: The saproc library has historically been built in quite odd ways on almost all platforms. When the old build system was converted, this was not changed. However, now the time has come to streamline this and build this library just as any other. The most visible change, perhaps, is that the library is now named saproc on all platforms, even Windows. Other changes include: * Don't set flags that is already set by the default flags. * Don't set flags that do not have anny effect. * Don't subst away the WIN32_LEAN_AND_MEAN definition, it's perfectly okay to have it. * Don't set CXX linker on solaris -- this was not needed so no reason to do it. * Cleaned up some old hooks for closed code that is no longer needed. I have verified this using COMPARE_BUILD. This shows only the expected differences: * On all platforms: class file changes for WindbgDebuggerLocal.java. * On solaris: some minor symbol differences, since the linker now uses C framework functions instead of C++. (And with symbol changes always comes disasm changes.) * On linux: a binary difference for libsaproc.so, but no size/symbol/deps/disasm change. * On macosx: no changes at all. * On windows: sawindbg.dll is renamed to saproc.dll. When I made a manual comparison between the two files, I found no significant differences. Bug: https://bugs.openjdk.java.net/browse/JDK-8199682 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199682-clean-up-saproc/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Mar 15 18:39:42 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Mar 2018 11:39:42 -0700 Subject: RFR: JDK-8199682 Clean up building the saproc library In-Reply-To: References: Message-ID: <39fbd44c-030d-582f-f4f9-9bc9f3e53c42@oracle.com> Looks good to me. The removed source files, are those some kind of tests? /Erik On 2018-03-15 11:22, Magnus Ihse Bursie wrote: > The saproc library has historically been built in quite odd ways on > almost all platforms. When the old build system was converted, this > was not changed. > > However, now the time has come to streamline this and build this > library just as any other. > > The most visible change, perhaps, is that the library is now named > saproc on all platforms, even Windows. Other changes include: > * Don't set flags that is already set by the default flags. > * Don't set flags that do not have anny effect. > * Don't subst away the WIN32_LEAN_AND_MEAN definition, it's perfectly > okay to have it. > * Don't set CXX linker on solaris -- this was not needed so no reason > to do it. > * Cleaned up some old hooks for closed code that is no longer needed. > > I have verified this using COMPARE_BUILD. This shows only the expected > differences: > * On all platforms: class file changes for WindbgDebuggerLocal.java. > * On solaris: some minor symbol differences, since the linker now uses > C framework functions instead of C++. (And with symbol changes always > comes disasm changes.) > * On linux: a binary difference for libsaproc.so, but no > size/symbol/deps/disasm change. > * On macosx: no changes at all. > * On windows: sawindbg.dll is renamed to saproc.dll. When I made a > manual comparison between the two files, I found no significant > differences. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199682 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199682-clean-up-saproc/webrev.01 > > /Magnus > From magnus.ihse.bursie at oracle.com Thu Mar 15 18:44:46 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 19:44:46 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> Message-ID: <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> On 2018-03-15 18:23, Phil Race wrote: > I wondered if that might be the case since it was a "BSD" port .. > using X11 .. > > Maybe we should be getting rid of them ? I agree, we should delete them. I just shuffled them around in the hope that they would be useful for a potential future bsd port, but if/when that happens, we can dig them out from mercurial. A short explanation of how the files moved. The sound library is apparently composed of either a single library (solaris and macosx) or two libraries (linux and windows). Two building blocks, MIDI + ports and DirectAudio is used for all platforms, but they go into either the main library (libjsound) or the helper library. For Windows, MIDI+Ports go into libjsound, and DirectAudio go into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio go into the main libjsound. I have no idea why this split is necessary, but this is how the libraries de facto is compiled, and the code needs to match that. If it would be possible to move libjsoundds and libjsoundalsa into libjsound directly, things would be greatly simplified. /Magnus > > -phil. > > On 03/15/2018 10:21 AM, Erik Joelsson wrote: >> Digging a bit, those files came with the initial Macosx support. It >> doesn't look like they were ever used. >> >> /Erik >> >> >> On 2018-03-15 09:53, Phil Race wrote: >>> It is very hard to follow all the moved around files, but one thing >>> that sticks out is there is a "bsd" directory created and I can't >>> work out how the files in there are used. >>> If they are for a BSD port of OpenJDK where is rest of the support >>> for that ? >>> >>> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>>> Looks good to me. I tried cleaning this up before but failed to >>>> find a reasonable split, but this seems like a good split between >>>> common and library specific. >>>> >>>> /Erik >>>> >>>> >>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>>> I forgot to add the client mailing lists as recipients. Sorry. >>>>> (Not sure if "sounds" belong to "awt" or "2d".) >>> >>> In fact, there is a sound-specific list, which I've added. >>> >>> -phil. >>>>> >>>>> /Magnus >>>>> >>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>>> From the bug description: >>>>>> >>>>>> Moving this to a separate bug from JDK-8055190. In >>>>>> SoundLibraries.gmk, the source code splitting is not complete. >>>>>> The directory libjsound is used to build not only libjsound but >>>>>> libjsoundalsa and libjsoundds, and thus needs a complex >>>>>> include/exclude system like before. >>>>>> >>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are >>>>>> completely clean. On macosx, there's a binary diff (but nothing >>>>>> else) on libjsound.dylib. On linux, some offset seems to have >>>>>> changed, which caused a slight change in disass and fulldump for >>>>>> libjsound.so. I'm not quite sure what's causing it, but I'm >>>>>> convinced it's harmless. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>>> WebRev: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>>> >>>>>> /Magnus >>>>>> >>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Thu Mar 15 18:49:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 19:49:25 +0100 Subject: RFR: JDK-8199682 Clean up building the saproc library In-Reply-To: <39fbd44c-030d-582f-f4f9-9bc9f3e53c42@oracle.com> References: <39fbd44c-030d-582f-f4f9-9bc9f3e53c42@oracle.com> Message-ID: On 2018-03-15 19:39, Erik Joelsson wrote: > Looks good to me. > > The removed source files, are those some kind of tests? I don't really know; they have been excluded from the build for all time. My guess is that the Bsd* stuff is, like in the case of the sound libraries, bsd-based stuff that arrived with the mac port (but disabled). The test.c is a trivial main() method which looks more like a left-over adhoc testing from the initial developer. Perhaps someone wants to turn it into a proper test, but it seems like it's not much even to start with. (And hopefully we have much better real test coverage of this now.) /Magnus > > /Erik > > > On 2018-03-15 11:22, Magnus Ihse Bursie wrote: >> The saproc library has historically been built in quite odd ways on >> almost all platforms. When the old build system was converted, this >> was not changed. >> >> However, now the time has come to streamline this and build this >> library just as any other. >> >> The most visible change, perhaps, is that the library is now named >> saproc on all platforms, even Windows. Other changes include: >> * Don't set flags that is already set by the default flags. >> * Don't set flags that do not have anny effect. >> * Don't subst away the WIN32_LEAN_AND_MEAN definition, it's perfectly >> okay to have it. >> * Don't set CXX linker on solaris -- this was not needed so no reason >> to do it. >> * Cleaned up some old hooks for closed code that is no longer needed. >> >> I have verified this using COMPARE_BUILD. This shows only the >> expected differences: >> * On all platforms: class file changes for WindbgDebuggerLocal.java. >> * On solaris: some minor symbol differences, since the linker now >> uses C framework functions instead of C++. (And with symbol changes >> always comes disasm changes.) >> * On linux: a binary difference for libsaproc.so, but no >> size/symbol/deps/disasm change. >> * On macosx: no changes at all. >> * On windows: sawindbg.dll is renamed to saproc.dll. When I made a >> manual comparison between the two files, I found no significant >> differences. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199682 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8199682-clean-up-saproc/webrev.01 >> >> /Magnus >> > From alexey.menkov at oracle.com Thu Mar 15 19:06:30 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 15 Mar 2018 12:06:30 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> Message-ID: On 03/15/2018 11:44, Magnus Ihse Bursie wrote: > On 2018-03-15 18:23, Phil Race wrote: >> I wondered if that might be the case since it was a "BSD" port .. >> using X11 .. >> >> Maybe we should be getting rid of them ? > I agree, we should delete them. I just shuffled them around in the hope > that they would be useful for a potential future bsd port, but if/when > that happens, we can dig them out from mercurial. > > A short explanation of how the files moved. The sound library is > apparently composed of either a single library (solaris and macosx) or > two libraries (linux and windows). Two building blocks, MIDI + ports and > DirectAudio is used for all platforms, but they go into either the main > library (libjsound) or the helper library. > > For Windows, MIDI+Ports go into libjsound, and DirectAudio go into > libjsoundds. On Linux, MIDI+Ports and DirectAudio go into libjsoundalsa. > On Macosx and Solaris, MIDI+Ports and DirectAudio go into the main > libjsound. > > I have no idea why this split is necessary, but this is how the > libraries de facto is compiled, and the code needs to match that. If it > would be possible to move libjsoundds and libjsoundalsa into libjsound > directly, things would be greatly simplified. As far as I know the split was made to dynamically load ALSA/DirectSound stuff. If it's not available (or old unsupported version is installed), libjsound stuff continues to work (in pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS on Linux). For now Windows (DirectSound) libjsoundds stuff can be merged into libjsound, but I'm not sure we can rely on ALSA is always available on Linux (but most likely if ALSA is not available, libjsound does not provide any functionality, so I suppose libjsoundalsa stuff can be moved to libjsound as well) --alex > > /Magnus > >> >> -phil. >> >> On 03/15/2018 10:21 AM, Erik Joelsson wrote: >>> Digging a bit, those files came with the initial Macosx support. It >>> doesn't look like they were ever used. >>> >>> /Erik >>> >>> >>> On 2018-03-15 09:53, Phil Race wrote: >>>> It is very hard to follow all the moved around files, but one thing >>>> that sticks out is there is a "bsd" directory created and I can't >>>> work out how the files in there are used. >>>> If they are for a BSD port of OpenJDK where is rest of the support >>>> for that ? >>>> >>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>>>> Looks good to me. I tried cleaning this up before but failed to >>>>> find a reasonable split, but this seems like a good split between >>>>> common and library specific. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>>>> I forgot to add the client mailing lists as recipients. Sorry. >>>>>> (Not sure if "sounds" belong to "awt" or "2d".) >>>> >>>> In fact, there is a sound-specific list, which I've added. >>>> >>>> -phil. >>>>>> >>>>>> /Magnus >>>>>> >>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>>>> From the bug description: >>>>>>> >>>>>>> Moving this to a separate bug from JDK-8055190. In >>>>>>> SoundLibraries.gmk, the source code splitting is not complete. >>>>>>> The directory libjsound is used to build not only libjsound but >>>>>>> libjsoundalsa and libjsoundds, and thus needs a complex >>>>>>> include/exclude system like before. >>>>>>> >>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are >>>>>>> completely clean. On macosx, there's a binary diff (but nothing >>>>>>> else) on libjsound.dylib. On linux, some offset seems to have >>>>>>> changed, which caused a slight change in disass and fulldump for >>>>>>> libjsound.so. I'm not quite sure what's causing it, but I'm >>>>>>> convinced it's harmless. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>>>> WebRev: >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>>>> >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>> >>>>> >>>> >>> >> > From philip.race at oracle.com Thu Mar 15 19:13:12 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 15 Mar 2018 12:13:12 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> Message-ID: <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com> > As far as I know the split was made to dynamically load ALSA/DirectSound stuff Yes, I think it is something like that for Linux ie if at runtime a dependent-but-not-essential .so was not installed it was not fatal. I don't know to what extent this is no longer a possible issue, or one that matters. -phil. On 03/15/2018 12:06 PM, Alex Menkov wrote: > > > On 03/15/2018 11:44, Magnus Ihse Bursie wrote: >> On 2018-03-15 18:23, Phil Race wrote: >>> I wondered if that might be the case since it was a "BSD" port .. >>> using X11 .. >>> >>> Maybe we should be getting rid of them ? >> I agree, we should delete them. I just shuffled them around in the >> hope that they would be useful for a potential future bsd port, but >> if/when that happens, we can dig them out from mercurial. >> >> A short explanation of how the files moved. The sound library is >> apparently composed of either a single library (solaris and macosx) >> or two libraries (linux and windows). Two building blocks, MIDI + >> ports and DirectAudio is used for all platforms, but they go into >> either the main library (libjsound) or the helper library. >> >> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into >> libjsoundds. On Linux, MIDI+Ports and DirectAudio go into >> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio go >> into the main libjsound. >> >> I have no idea why this split is necessary, but this is how the >> libraries de facto is compiled, and the code needs to match that. If >> it would be possible to move libjsoundds and libjsoundalsa into >> libjsound directly, things would be greatly simplified. > > As far as I know the split was made to dynamically load > ALSA/DirectSound stuff. If it's not available (or old unsupported > version is installed), libjsound stuff continues to work (in > pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS on > Linux). > For now Windows (DirectSound) libjsoundds stuff can be merged into > libjsound, but I'm not sure we can rely on ALSA is always available on > Linux (but most likely if ALSA is not available, libjsound does not > provide any functionality, so I suppose libjsoundalsa stuff can be > moved to libjsound as well) > > --alex > >> >> /Magnus >> >>> >>> -phil. >>> >>> On 03/15/2018 10:21 AM, Erik Joelsson wrote: >>>> Digging a bit, those files came with the initial Macosx support. It >>>> doesn't look like they were ever used. >>>> >>>> /Erik >>>> >>>> >>>> On 2018-03-15 09:53, Phil Race wrote: >>>>> It is very hard to follow all the moved around files, but one thing >>>>> that sticks out is there is a "bsd" directory created and I can't >>>>> work out how the files in there are used. >>>>> If they are for a BSD port of OpenJDK where is rest of the support >>>>> for that ? >>>>> >>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>>>>> Looks good to me. I tried cleaning this up before but failed to >>>>>> find a reasonable split, but this seems like a good split between >>>>>> common and library specific. >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>>>>> I forgot to add the client mailing lists as recipients. Sorry. >>>>>>> (Not sure if "sounds" belong to "awt" or "2d".) >>>>> >>>>> In fact, there is a sound-specific list, which I've added. >>>>> >>>>> -phil. >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>>>>> From the bug description: >>>>>>>> >>>>>>>> Moving this to a separate bug from JDK-8055190. In >>>>>>>> SoundLibraries.gmk, the source code splitting is not complete. >>>>>>>> The directory libjsound is used to build not only libjsound but >>>>>>>> libjsoundalsa and libjsoundds, and thus needs a complex >>>>>>>> include/exclude system like before. >>>>>>>> >>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are >>>>>>>> completely clean. On macosx, there's a binary diff (but nothing >>>>>>>> else) on libjsound.dylib. On linux, some offset seems to have >>>>>>>> changed, which caused a slight change in disass and fulldump >>>>>>>> for libjsound.so. I'm not quite sure what's causing it, but I'm >>>>>>>> convinced it's harmless. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>>>>> WebRev: >>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>>>>> >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From magnus.ihse.bursie at oracle.com Thu Mar 15 20:09:06 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Mar 2018 21:09:06 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com> Message-ID: <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com> > 15 mars 2018 kl. 20:13 skrev Phil Race : > > > > As far as I know the split was made to dynamically load ALSA/DirectSound stuff > > Yes, I think it is something like that for Linux > ie if at runtime a dependent-but-not-essential .so was not > installed it was not fatal. I don't know to what extent this is no longer a > possible issue, or one that matters. I have not heard of any mainstream Linux distro in years that was lacking ALSA. If ALSA was not present, will the libraries fall back to OSS, or will there be just no sound available? In any case, I think that whatever Linux distros we're targeting as supported, ALSA will be present. Alex, did I understand you correctly that in any case, a separate Windows library is always unnecessary, since we can rely on DirectAudio always being present in our supported versions of Windows? /Magnus > > -phil. > >> On 03/15/2018 12:06 PM, Alex Menkov wrote: >> >> >>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote: >>>> On 2018-03-15 18:23, Phil Race wrote: >>>> I wondered if that might be the case since it was a "BSD" port .. using X11 .. >>>> >>>> Maybe we should be getting rid of them ? >>> I agree, we should delete them. I just shuffled them around in the hope that they would be useful for a potential future bsd port, but if/when that happens, we can dig them out from mercurial. >>> >>> A short explanation of how the files moved. The sound library is apparently composed of either a single library (solaris and macosx) or two libraries (linux and windows). Two building blocks, MIDI + ports and DirectAudio is used for all platforms, but they go into either the main library (libjsound) or the helper library. >>> >>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio go into the main libjsound. >>> >>> I have no idea why this split is necessary, but this is how the libraries de facto is compiled, and the code needs to match that. If it would be possible to move libjsoundds and libjsoundalsa into libjsound directly, things would be greatly simplified. >> >> As far as I know the split was made to dynamically load ALSA/DirectSound stuff. If it's not available (or old unsupported version is installed), libjsound stuff continues to work (in pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS on Linux). >> For now Windows (DirectSound) libjsoundds stuff can be merged into libjsound, but I'm not sure we can rely on ALSA is always available on Linux (but most likely if ALSA is not available, libjsound does not provide any functionality, so I suppose libjsoundalsa stuff can be moved to libjsound as well) >> >> --alex >> >>> >>> /Magnus >>> >>>> >>>> -phil. >>>> >>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote: >>>>> Digging a bit, those files came with the initial Macosx support. It doesn't look like they were ever used. >>>>> >>>>> /Erik >>>>> >>>>> >>>>>> On 2018-03-15 09:53, Phil Race wrote: >>>>>> It is very hard to follow all the moved around files, but one thing >>>>>> that sticks out is there is a "bsd" directory created and I can't >>>>>> work out how the files in there are used. >>>>>> If they are for a BSD port of OpenJDK where is rest of the support for that ? >>>>>> >>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>>>>>> Looks good to me. I tried cleaning this up before but failed to find a reasonable split, but this seems like a good split between common and library specific. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>>>>>> I forgot to add the client mailing lists as recipients. Sorry. (Not sure if "sounds" belong to "awt" or "2d".) >>>>>> >>>>>> In fact, there is a sound-specific list, which I've added. >>>>>> >>>>>> -phil. >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>>>>>> From the bug description: >>>>>>>>> >>>>>>>>> Moving this to a separate bug from JDK-8055190. In SoundLibraries.gmk, the source code splitting is not complete. The directory libjsound is used to build not only libjsound but libjsoundalsa and libjsoundds, and thus needs a complex include/exclude system like before. >>>>>>>>> >>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are completely clean. On macosx, there's a binary diff (but nothing else) on libjsound.dylib. On linux, some offset seems to have changed, which caused a slight change in disass and fulldump for libjsound.so. I'm not quite sure what's causing it, but I'm convinced it's harmless. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>>>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>>>>>> >>>>>>>>> /Magnus > From david.holmes at oracle.com Fri Mar 16 02:48:29 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Mar 2018 12:48:29 +1000 Subject: RFR: JDK-8199681 Remove boilerplate code from creating native jtreg tests In-Reply-To: <938bcf1c-ed79-0679-cc43-8a7bc948731f@oracle.com> References: <938bcf1c-ed79-0679-cc43-8a7bc948731f@oracle.com> Message-ID: <5c5d58a9-a026-f40d-c1f3-dfa57e03f09c@oracle.com> Hi Magnus, Removing boilerplate is good but the exclude mechanism seems rather awkward compared to the previous include. It's much more obvious when writing a platform specific native test to include it for that platform, rather than exclude it for all other platforms. You run the risk of having excludes spread all over the place, or not knowing where you should put them. I thought the opt-in approach of just adding the test directory to the list of native test directories was simple and worked well. (The need to add the extra link instructions wasn't good though, :) ) Also having to exclude on the file level is more awkward than using the directory level. 49 BUILD_HOTSPOT_JTREG_IMAGE_DIR := $(TEST_IMAGE_DIR)/hotspot/jtreg I thought you'd changed something here then noticed that we end up doing: 94 DEST := $(TEST_IMAGE_DIR)/hotspot/jtreg/native, \ and BUILD_HOTSPOT_JTREG_IMAGE_DIR is actually unused. Thanks, David On 15/03/2018 11:01 PM, Magnus Ihse Bursie wrote: > There's currently a lot of boilerplate code needed to setup a new native > jtreg test. This was never the way it was intended to work -- the idea > was that you basically should just add the file and then things should > work automatically, unless you had special requirements. > > This patch will make it so once more. > > I have tested this using COMPARE_BUILD. I get some spurious binary > differences on macosx. I can't really say why, but then again, we have > never verified the test image by a clean "back-to-back" null comparison > either, so I'm not worried. Apart from that, it looks green. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199681 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199681-remote-native-test-boilerplate/webrev.01 > > > /Magnus From david.holmes at oracle.com Fri Mar 16 03:13:00 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Mar 2018 13:13:00 +1000 Subject: RFR: JDK-8199682 Clean up building the saproc library In-Reply-To: References: Message-ID: <927e4b35-3174-90aa-857f-d27d2f90ad3c@oracle.com> Hi Magnus, Overall this seems okay. On 16/03/2018 4:22 AM, Magnus Ihse Bursie wrote: > The saproc library has historically been built in quite odd ways on > almost all platforms. When the old build system was converted, this was > not changed. > > However, now the time has come to streamline this and build this library > just as any other. > > The most visible change, perhaps, is that the library is now named > saproc on all platforms, even Windows. Other changes include: That could have repercussions elsewhere. sawindbg.dll is probably a well known name for deployment systems. > * Don't set flags that is already set by the default flags. > * Don't set flags that do not have anny effect. > * Don't subst away the WIN32_LEAN_AND_MEAN definition, it's perfectly > okay to have it. > * Don't set CXX linker on solaris -- this was not needed so no reason to > do it. > * Cleaned up some old hooks for closed code that is no longer needed. Right - we could have deleted that when our ARM ports went open. > I have verified this using COMPARE_BUILD. This shows only the expected > differences: > * On all platforms: class file changes for WindbgDebuggerLocal.java. > * On solaris: some minor symbol differences, since the linker now uses C > framework functions instead of C++. (And with symbol changes always > comes disasm changes.) > * On linux: a binary difference for libsaproc.so, but no > size/symbol/deps/disasm change. > * On macosx: no changes at all. > * On windows: sawindbg.dll is renamed to saproc.dll. When I made a > manual comparison between the two files, I found no significant > differences. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199682 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8199682-clean-up-saproc/webrev.01 The deleted OSX files seem okay. This just seems like another case where the original port copied every Linux file across to the bsd directory. Not sure about the Solaris saproc_audit.cpp or the test.c files ?? Thanks, David > /Magnus > From mvala at redhat.com Fri Mar 16 10:48:49 2018 From: mvala at redhat.com (Michal Vala) Date: Fri, 16 Mar 2018 11:48:49 +0100 Subject: RFR: build pragma error with gcc 4.4.7 Message-ID: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com> Hi, I've been trying to build latest jdk with gcc 4.4.7 and I hit compile error due to pragma used in function: /mnt/ramdisk/openjdk/src/hotspot/os/linux/os_linux.inline.hpp:103: error: #pragma GCC diagnostic not allowed inside functions I'm sending little patch that fixes the issue by wrapping whole function. I've also created a macro for ignoring deprecated declaration inside compilerWarnings.hpp to line up with others. Can someone please review? If it's ok, I would also need a sponsor. diff -r 422615764e12 src/hotspot/os/linux/os_linux.inline.hpp --- a/src/hotspot/os/linux/os_linux.inline.hpp Thu Mar 15 14:54:10 2018 -0700 +++ b/src/hotspot/os/linux/os_linux.inline.hpp Fri Mar 16 10:50:24 2018 +0100 @@ -96,13 +96,12 @@ return ::ftruncate64(fd, length); } -inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) -{ // readdir_r has been deprecated since glibc 2.24. // See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details. -#pragma GCC diagnostic push -#pragma GCC diagnostic ignored "-Wdeprecated-declarations" - +PRAGMA_DIAG_PUSH +PRAGMA_DEPRECATED_IGNORED +inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) +{ dirent* p; int status; assert(dirp != NULL, "just checking"); @@ -114,11 +113,11 @@ if((status = ::readdir_r(dirp, dbuf, &p)) != 0) { errno = status; return NULL; - } else + } else { return p; - -#pragma GCC diagnostic pop + } } +PRAGMA_DIAG_POP inline int os::closedir(DIR *dirp) { assert(dirp != NULL, "argument is NULL"); diff -r 422615764e12 src/hotspot/share/utilities/compilerWarnings.hpp --- a/src/hotspot/share/utilities/compilerWarnings.hpp Thu Mar 15 14:54:10 2018 -0700 +++ b/src/hotspot/share/utilities/compilerWarnings.hpp Fri Mar 16 10:50:24 2018 +0100 @@ -48,6 +48,7 @@ #define PRAGMA_FORMAT_NONLITERAL_IGNORED _Pragma("GCC diagnostic ignored \"-Wformat-nonliteral\"") \ _Pragma("GCC diagnostic ignored \"-Wformat-security\"") #define PRAGMA_FORMAT_IGNORED _Pragma("GCC diagnostic ignored \"-Wformat\"") +#define PRAGMA_DEPRECATED_IGNORED _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"") #if defined(__clang_major__) && \ (__clang_major__ >= 4 || \ Thanks! -- Michal Vala OpenJDK QE Red Hat Czech From david.holmes at oracle.com Fri Mar 16 11:05:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Mar 2018 21:05:15 +1000 Subject: RFR: build pragma error with gcc 4.4.7 In-Reply-To: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com> References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com> Message-ID: <2dd2d37c-e0d7-ad13-6da6-92196ab6749d@oracle.com> Hi Michal, On 16/03/2018 8:48 PM, Michal Vala wrote: > Hi, > > I've been trying to build latest jdk with gcc 4.4.7 and I hit compile > error due to pragma used in function: That's a very old gcc. Our "official" version is 4.9.2 but we're working on getting gcc 7.x working as well. This code causes no problem on 4.9.2+ so to make any change we'd have to know it will continue to work on later versions. Also a google search indicates the "pragma diagnostic push" and pop weren't added until gcc 4.6 ?? David ----- > /mnt/ramdisk/openjdk/src/hotspot/os/linux/os_linux.inline.hpp:103: > error: #pragma GCC diagnostic not allowed inside functions > > > I'm sending little patch that fixes the issue by wrapping whole > function. I've also created a macro for ignoring deprecated declaration > inside compilerWarnings.hpp to line up with others. > > Can someone please review? If it's ok, I would also need a sponsor. > > > diff -r 422615764e12 src/hotspot/os/linux/os_linux.inline.hpp > --- a/src/hotspot/os/linux/os_linux.inline.hpp??? Thu Mar 15 14:54:10 > 2018 -0700 > +++ b/src/hotspot/os/linux/os_linux.inline.hpp??? Fri Mar 16 10:50:24 > 2018 +0100 > @@ -96,13 +96,12 @@ > ?? return ::ftruncate64(fd, length); > ?} > > -inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) > -{ > ?// readdir_r has been deprecated since glibc 2.24. > ?// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more > details. > -#pragma GCC diagnostic push > -#pragma GCC diagnostic ignored "-Wdeprecated-declarations" > - > +PRAGMA_DIAG_PUSH > +PRAGMA_DEPRECATED_IGNORED > +inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) > +{ > ?? dirent* p; > ?? int status; > ?? assert(dirp != NULL, "just checking"); > @@ -114,11 +113,11 @@ > ?? if((status = ::readdir_r(dirp, dbuf, &p)) != 0) { > ???? errno = status; > ???? return NULL; > -? } else > +? } else { > ???? return p; > - > -#pragma GCC diagnostic pop > +? } > ?} > +PRAGMA_DIAG_POP > > ?inline int os::closedir(DIR *dirp) { > ?? assert(dirp != NULL, "argument is NULL"); > diff -r 422615764e12 src/hotspot/share/utilities/compilerWarnings.hpp > --- a/src/hotspot/share/utilities/compilerWarnings.hpp??? Thu Mar 15 > 14:54:10 2018 -0700 > +++ b/src/hotspot/share/utilities/compilerWarnings.hpp??? Fri Mar 16 > 10:50:24 2018 +0100 > @@ -48,6 +48,7 @@ > ?#define PRAGMA_FORMAT_NONLITERAL_IGNORED _Pragma("GCC diagnostic > ignored \"-Wformat-nonliteral\"") \ > ????????????????????????????????????????? _Pragma("GCC diagnostic > ignored \"-Wformat-security\"") > ?#define PRAGMA_FORMAT_IGNORED _Pragma("GCC diagnostic ignored > \"-Wformat\"") > +#define PRAGMA_DEPRECATED_IGNORED _Pragma("GCC diagnostic ignored > \"-Wdeprecated-declarations\"") > > ?#if defined(__clang_major__) && \ > ?????? (__clang_major__ >= 4 || \ > > > Thanks! > From magnus.ihse.bursie at oracle.com Fri Mar 16 11:36:23 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 16 Mar 2018 12:36:23 +0100 Subject: RFR: build pragma error with gcc 4.4.7 In-Reply-To: <2dd2d37c-e0d7-ad13-6da6-92196ab6749d@oracle.com> References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com> <2dd2d37c-e0d7-ad13-6da6-92196ab6749d@oracle.com> Message-ID: <0221bde4-1313-31d7-65fa-e4f4ebed4200@oracle.com> On 2018-03-16 12:05, David Holmes wrote: > Hi Michal, > > On 16/03/2018 8:48 PM, Michal Vala wrote: >> Hi, >> >> I've been trying to build latest jdk with gcc 4.4.7 and I hit compile >> error due to pragma used in function: I don't think gcc 4.4.7 is likely to work at all. Configure will complain (but continue) if you use a gcc prior to 4.7 (very recently raised to 4.8). You can try getting past this error, but you are likely to hit more issues down the road. Do you have any specific reasons for using such an old compiler? /Magnus > > That's a very old gcc. Our "official" version is 4.9.2 but we're > working on getting gcc 7.x working as well. This code causes no > problem on 4.9.2+ so to make any change we'd have to know it will > continue to work on later versions. > > Also a google search indicates the "pragma diagnostic push" and pop > weren't added until gcc 4.6 ?? > > David > ----- > >> /mnt/ramdisk/openjdk/src/hotspot/os/linux/os_linux.inline.hpp:103: >> error: #pragma GCC diagnostic not allowed inside functions >> >> >> I'm sending little patch that fixes the issue by wrapping whole >> function. I've also created a macro for ignoring deprecated >> declaration inside compilerWarnings.hpp to line up with others. >> >> Can someone please review? If it's ok, I would also need a sponsor. >> >> >> diff -r 422615764e12 src/hotspot/os/linux/os_linux.inline.hpp >> --- a/src/hotspot/os/linux/os_linux.inline.hpp??? Thu Mar 15 14:54:10 >> 2018 -0700 >> +++ b/src/hotspot/os/linux/os_linux.inline.hpp??? Fri Mar 16 10:50:24 >> 2018 +0100 >> @@ -96,13 +96,12 @@ >> ??? return ::ftruncate64(fd, length); >> ??} >> >> -inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) >> -{ >> ??// readdir_r has been deprecated since glibc 2.24. >> ??// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for >> more details. >> -#pragma GCC diagnostic push >> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations" >> - >> +PRAGMA_DIAG_PUSH >> +PRAGMA_DEPRECATED_IGNORED >> +inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) >> +{ >> ??? dirent* p; >> ??? int status; >> ??? assert(dirp != NULL, "just checking"); >> @@ -114,11 +113,11 @@ >> ??? if((status = ::readdir_r(dirp, dbuf, &p)) != 0) { >> ????? errno = status; >> ????? return NULL; >> -? } else >> +? } else { >> ????? return p; >> - >> -#pragma GCC diagnostic pop >> +? } >> ??} >> +PRAGMA_DIAG_POP >> >> ??inline int os::closedir(DIR *dirp) { >> ??? assert(dirp != NULL, "argument is NULL"); >> diff -r 422615764e12 src/hotspot/share/utilities/compilerWarnings.hpp >> --- a/src/hotspot/share/utilities/compilerWarnings.hpp??? Thu Mar 15 >> 14:54:10 2018 -0700 >> +++ b/src/hotspot/share/utilities/compilerWarnings.hpp??? Fri Mar 16 >> 10:50:24 2018 +0100 >> @@ -48,6 +48,7 @@ >> ??#define PRAGMA_FORMAT_NONLITERAL_IGNORED _Pragma("GCC diagnostic >> ignored \"-Wformat-nonliteral\"") \ >> ?????????????????????????????????????????? _Pragma("GCC diagnostic >> ignored \"-Wformat-security\"") >> ??#define PRAGMA_FORMAT_IGNORED _Pragma("GCC diagnostic ignored >> \"-Wformat\"") >> +#define PRAGMA_DEPRECATED_IGNORED _Pragma("GCC diagnostic ignored >> \"-Wdeprecated-declarations\"") >> >> ??#if defined(__clang_major__) && \ >> ??????? (__clang_major__ >= 4 || \ >> >> >> Thanks! >> From magnus.ihse.bursie at oracle.com Fri Mar 16 11:43:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 16 Mar 2018 12:43:08 +0100 Subject: RFR: JDK-8199681 Remove boilerplate code from creating native jtreg tests In-Reply-To: <5c5d58a9-a026-f40d-c1f3-dfa57e03f09c@oracle.com> References: <938bcf1c-ed79-0679-cc43-8a7bc948731f@oracle.com> <5c5d58a9-a026-f40d-c1f3-dfa57e03f09c@oracle.com> Message-ID: <4ca4f5b4-8a34-7cd3-39f1-d002dcde3983@oracle.com> On 2018-03-16 03:48, David Holmes wrote: > Hi Magnus, > > Removing boilerplate is good but the exclude mechanism seems rather > awkward compared to the previous include. It's much more obvious when > writing a platform specific native test to include it for that > platform, rather than exclude it for all other platforms. You run the > risk of having excludes spread all over the place, or not knowing > where you should put them. I thought the opt-in approach of just > adding the test directory to the list of native test directories was > simple and worked well. (The need to add the extra link instructions > wasn't good though, :) ) Previously you had to write like: ifeq ($(OPENJDK_TARGET_OS), windows) SRC += mytest endif Now you have to write ifneq ($(OPENJDK_TARGET_OS), windows) EXCLUDE += mytest endif Seriously, that's not much harder. But the latter has the extremely important benefit that for all multi-platform tests (which comprise the absolute majority), you don't have to modify the makefiles at all. > Also having to exclude on the file level is more awkward than using > the directory level. I can of course change that. I chose the file level due to these reasons: * We have a requirement of filename uniqueness across all tests (since they compile to object files in a single directory); however we do not have a requirement of directory name uniqueness. * Basing this on filenames allows you to single out individual tests that are, for logical reasons, grouped together in a single directory. * And it was easier to implement in make scripts. :-) As a suggestion, I can add a PATTERN_EXCLUDE. This way it will work about the same as the Setup*Compilation functions, were you can exclude based on file name or pattern matching. Do you want me to do that? I think with the current number of excludes, it's not really worth it, but if it is important to you, I can fix it. > > > 49 BUILD_HOTSPOT_JTREG_IMAGE_DIR := $(TEST_IMAGE_DIR)/hotspot/jtreg > > I thought you'd changed something here then noticed that we end up doing: > > ?94???? DEST := $(TEST_IMAGE_DIR)/hotspot/jtreg/native, \ > > and BUILD_HOTSPOT_JTREG_IMAGE_DIR is actually unused. *duh* I have already pushed the patch. I will fix this in a follow-up bug. Let me know if you want to have a directory-based or pattern- based exclusion mechanism in that as well. /Magnus > > Thanks, > David > > On 15/03/2018 11:01 PM, Magnus Ihse Bursie wrote: >> There's currently a lot of boilerplate code needed to setup a new >> native jtreg test. This was never the way it was intended to work -- >> the idea was that you basically should just add the file and then >> things should work automatically, unless you had special requirements. >> >> This patch will make it so once more. >> >> I have tested this using COMPARE_BUILD. I get some spurious binary >> differences on macosx. I can't really say why, but then again, we >> have never verified the test image by a clean "back-to-back" null >> comparison either, so I'm not worried. Apart from that, it looks green. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199681 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8199681-remote-native-test-boilerplate/webrev.01 >> >> >> /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 16 11:49:05 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 16 Mar 2018 12:49:05 +0100 Subject: RFR: JDK-8199682 Clean up building the saproc library In-Reply-To: <927e4b35-3174-90aa-857f-d27d2f90ad3c@oracle.com> References: <927e4b35-3174-90aa-857f-d27d2f90ad3c@oracle.com> Message-ID: On 2018-03-16 04:13, David Holmes wrote: > Hi Magnus, > > Overall this seems okay. Thanks! > > On 16/03/2018 4:22 AM, Magnus Ihse Bursie wrote: >> The saproc library has historically been built in quite odd ways on >> almost all platforms. When the old build system was converted, this >> was not changed. >> >> However, now the time has come to streamline this and build this >> library just as any other. >> >> The most visible change, perhaps, is that the library is now named >> saproc on all platforms, even Windows. Other changes include: > > That could have repercussions elsewhere. sawindbg.dll is probably a > well known name for deployment systems. You mean other classes than WindbgDebuggerLocal.java, out in the wild, might load sawindbg.dll directly and call into it? If they do so, they must also be prepared that this is not an exported interface and can change at any time. > >> * Don't set flags that is already set by the default flags. >> * Don't set flags that do not have anny effect. >> * Don't subst away the WIN32_LEAN_AND_MEAN definition, it's perfectly >> okay to have it. >> * Don't set CXX linker on solaris -- this was not needed so no reason >> to do it. >> * Cleaned up some old hooks for closed code that is no longer needed. > > Right - we could have deleted that when our ARM ports went open. > >> I have verified this using COMPARE_BUILD. This shows only the >> expected differences: >> * On all platforms: class file changes for WindbgDebuggerLocal.java. >> * On solaris: some minor symbol differences, since the linker now >> uses C framework functions instead of C++. (And with symbol changes >> always comes disasm changes.) >> * On linux: a binary difference for libsaproc.so, but no >> size/symbol/deps/disasm change. >> * On macosx: no changes at all. >> * On windows: sawindbg.dll is renamed to saproc.dll. When I made a >> manual comparison between the two files, I found no significant >> differences. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199682 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8199682-clean-up-saproc/webrev.01 > > The deleted OSX files seem okay. This just seems like another case > where the original port copied every Linux file across to the bsd > directory. > > Not sure about the Solaris saproc_audit.cpp or the test.c files ?? I don't know either. :) As I said to Erik, the test files looked like stupid adhoc testing just left in place. The saproc_audit.cpp looks legit, but has not been compiled for years. Someone must have "removed" the file by excluding it from compilation, rather than deleting it. Could have happened back in the bad old days when "solaris" didn't mean solaris but "unix", and nobody understood the consequences of deleting files there. As always, the file is still in the repository, if someone wants to revive it. /Magnus > > Thanks, > David > >> /Magnus >> From david.holmes at oracle.com Fri Mar 16 12:47:20 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Mar 2018 22:47:20 +1000 Subject: RFR: JDK-8199682 Clean up building the saproc library In-Reply-To: References: <927e4b35-3174-90aa-857f-d27d2f90ad3c@oracle.com> Message-ID: <8306d8e1-c0a1-c41d-56f7-073a0899a630@oracle.com> On 16/03/2018 9:49 PM, Magnus Ihse Bursie wrote: > On 2018-03-16 04:13, David Holmes wrote: >> Hi Magnus, >> >> Overall this seems okay. > Thanks! > >> >> On 16/03/2018 4:22 AM, Magnus Ihse Bursie wrote: >>> The saproc library has historically been built in quite odd ways on >>> almost all platforms. When the old build system was converted, this >>> was not changed. >>> >>> However, now the time has come to streamline this and build this >>> library just as any other. >>> >>> The most visible change, perhaps, is that the library is now named >>> saproc on all platforms, even Windows. Other changes include: >> >> That could have repercussions elsewhere. sawindbg.dll is probably a >> well known name for deployment systems. > You mean other classes than WindbgDebuggerLocal.java, out in the wild, > might load sawindbg.dll directly and call into it? If they do so, they > must also be prepared that this is not an exported interface and can > change at any time. No I mean deployment systems, like an upstream RPM manager, or Oracle's own installer process, may know the name of the file and have to be modified if the name changes. Though as Sundar said "proc" isn't really the right name. David ----- >> >>> * Don't set flags that is already set by the default flags. >>> * Don't set flags that do not have anny effect. >>> * Don't subst away the WIN32_LEAN_AND_MEAN definition, it's perfectly >>> okay to have it. >>> * Don't set CXX linker on solaris -- this was not needed so no reason >>> to do it. >>> * Cleaned up some old hooks for closed code that is no longer needed. >> >> Right - we could have deleted that when our ARM ports went open. >> >>> I have verified this using COMPARE_BUILD. This shows only the >>> expected differences: >>> * On all platforms: class file changes for WindbgDebuggerLocal.java. >>> * On solaris: some minor symbol differences, since the linker now >>> uses C framework functions instead of C++. (And with symbol changes >>> always comes disasm changes.) >>> * On linux: a binary difference for libsaproc.so, but no >>> size/symbol/deps/disasm change. >>> * On macosx: no changes at all. >>> * On windows: sawindbg.dll is renamed to saproc.dll. When I made a >>> manual comparison between the two files, I found no significant >>> differences. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199682 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8199682-clean-up-saproc/webrev.01 >> >> The deleted OSX files seem okay. This just seems like another case >> where the original port copied every Linux file across to the bsd >> directory. >> >> Not sure about the Solaris saproc_audit.cpp or the test.c files ?? > I don't know either. :) As I said to Erik, the test files looked like > stupid adhoc testing just left in place. The saproc_audit.cpp looks > legit, but has not been compiled for years. Someone must have "removed" > the file by excluding it from compilation, rather than deleting it. > Could have happened back in the bad old days when "solaris" didn't mean > solaris but "unix", and nobody understood the consequences of deleting > files there. > > As always, the file is still in the repository, if someone wants to > revive it. > > /Magnus > >> >> Thanks, >> David >> >>> /Magnus >>> > From david.holmes at oracle.com Fri Mar 16 13:06:43 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Mar 2018 23:06:43 +1000 Subject: RFR: JDK-8199681 Remove boilerplate code from creating native jtreg tests In-Reply-To: <4ca4f5b4-8a34-7cd3-39f1-d002dcde3983@oracle.com> References: <938bcf1c-ed79-0679-cc43-8a7bc948731f@oracle.com> <5c5d58a9-a026-f40d-c1f3-dfa57e03f09c@oracle.com> <4ca4f5b4-8a34-7cd3-39f1-d002dcde3983@oracle.com> Message-ID: On 16/03/2018 9:43 PM, Magnus Ihse Bursie wrote: > On 2018-03-16 03:48, David Holmes wrote: >> Hi Magnus, >> >> Removing boilerplate is good but the exclude mechanism seems rather >> awkward compared to the previous include. It's much more obvious when >> writing a platform specific native test to include it for that >> platform, rather than exclude it for all other platforms. You run the >> risk of having excludes spread all over the place, or not knowing >> where you should put them. I thought the opt-in approach of just >> adding the test directory to the list of native test directories was >> simple and worked well. (The need to add the extra link instructions >> wasn't good though, :) ) > > Previously you had to write like: > ifeq ($(OPENJDK_TARGET_OS), windows) > SRC += mytest > endif > > Now you have to write > ifneq ($(OPENJDK_TARGET_OS), windows) > EXCLUDE += mytest > endif > > Seriously, that's not much harder. True. It just doesn't look that clean in the actual file. > But the latter has the extremely important benefit that for all > multi-platform tests (which comprise the absolute majority), you don't > have to modify the makefiles at all. True. >> Also having to exclude on the file level is more awkward than using >> the directory level. > I can of course change that. I chose the file level due to these reasons: > * We have a requirement of filename uniqueness across all tests (since > they compile to object files in a single directory); however we do not > have a requirement of directory name uniqueness. Given we used to include directories it seems natural to me that we now exclude directories. Though I suppose files does give more fine grained control if we were to need it. > * Basing this on filenames allows you to single out individual tests > that are, for logical reasons, grouped together in a single directory. > * And it was easier to implement in make scripts. :-) > > As a suggestion, I can add a PATTERN_EXCLUDE. This way it will work > about the same as the Setup*Compilation functions, were you can exclude > based on file name or pattern matching. Do you want me to do that? I > think with the current number of excludes, it's not really worth it, but > if it is important to you, I can fix it. Let's just see how it goes, as you've already pushed it. Thanks, David >> >> >> 49 BUILD_HOTSPOT_JTREG_IMAGE_DIR := $(TEST_IMAGE_DIR)/hotspot/jtreg >> >> I thought you'd changed something here then noticed that we end up doing: >> >> ?94???? DEST := $(TEST_IMAGE_DIR)/hotspot/jtreg/native, \ >> >> and BUILD_HOTSPOT_JTREG_IMAGE_DIR is actually unused. > > *duh* > > I have already pushed the patch. I will fix this in a follow-up bug. Let > me know if you want to have a directory-based or pattern- based > exclusion mechanism in that as well. > > /Magnus > >> >> Thanks, >> David >> >> On 15/03/2018 11:01 PM, Magnus Ihse Bursie wrote: >>> There's currently a lot of boilerplate code needed to setup a new >>> native jtreg test. This was never the way it was intended to work -- >>> the idea was that you basically should just add the file and then >>> things should work automatically, unless you had special requirements. >>> >>> This patch will make it so once more. >>> >>> I have tested this using COMPARE_BUILD. I get some spurious binary >>> differences on macosx. I can't really say why, but then again, we >>> have never verified the test image by a clean "back-to-back" null >>> comparison either, so I'm not worried. Apart from that, it looks green. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199681 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8199681-remote-native-test-boilerplate/webrev.01 >>> >>> >>> /Magnus > From mvala at redhat.com Fri Mar 16 13:48:37 2018 From: mvala at redhat.com (Michal Vala) Date: Fri, 16 Mar 2018 14:48:37 +0100 Subject: RFR: build pragma error with gcc 4.4.7 In-Reply-To: <0221bde4-1313-31d7-65fa-e4f4ebed4200@oracle.com> References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com> <2dd2d37c-e0d7-ad13-6da6-92196ab6749d@oracle.com> <0221bde4-1313-31d7-65fa-e4f4ebed4200@oracle.com> Message-ID: On 03/16/2018 12:36 PM, Magnus Ihse Bursie wrote: > > On 2018-03-16 12:05, David Holmes wrote: >> Hi Michal, >> >> On 16/03/2018 8:48 PM, Michal Vala wrote: >>> Hi, >>> >>> I've been trying to build latest jdk with gcc 4.4.7 and I hit compile error >>> due to pragma used in function: > I don't think gcc 4.4.7 is likely to work at all. Configure will complain (but > continue) if you use a gcc prior to 4.7 (very recently raised to 4.8). > > You can try getting past this error, but you are likely to hit more issues down > the road. > > Do you have any specific reasons for using such an old compiler? Yes, I'm targeting RHEL6 where 4.4.7 is base gcc. With patch I've posted I'm able to compile. Configure is complaining with warning, but otherwise it's ok. Few more warnings during the build but no errors. We'd like to keep it 'compilable' in RHEL6 with code as close as possible to upstream. -- Michal Vala OpenJDK QE Red Hat Czech From alexey.menkov at oracle.com Fri Mar 16 16:49:22 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 16 Mar 2018 09:49:22 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com> <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com> Message-ID: <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com> On 03/15/2018 13:09, Magnus Ihse Bursie wrote: > >> 15 mars 2018 kl. 20:13 skrev Phil Race : >> >> >>> As far as I know the split was made to dynamically load ALSA/DirectSound stuff >> >> Yes, I think it is something like that for Linux >> ie if at runtime a dependent-but-not-essential .so was not >> installed it was not fatal. I don't know to what extent this is no longer a >> possible issue, or one that matters. > > I have not heard of any mainstream Linux distro in years that was lacking ALSA. > > If ALSA was not present, will the libraries fall back to OSS, or will there be just no sound available? No sound. OSS support was dropped many years ago (IIRC in jdk7) > In any case, I think that whatever Linux distros we're targeting as supported, ALSA will be present. > > Alex, did I understand you correctly that in any case, a separate Windows library is always unnecessary, since we can rely on DirectAudio always being present in our supported versions of Windows? Yes, that's right. Windows always has DirectSound pre-installed and its version is greater than required (IIRC javasoundds requires DirectX 5). For now failure of libjsound loading is fatal (see com.sun.media.sound.Platform.loadLibraries()), loading of extra libs is non-fatal. I believe libjsound loading failure should be made non-fatal, then all the functionality will remain the same as we have now. --alex > > /Magnus > >> >> -phil. >> >>> On 03/15/2018 12:06 PM, Alex Menkov wrote: >>> >>> >>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote: >>>>> On 2018-03-15 18:23, Phil Race wrote: >>>>> I wondered if that might be the case since it was a "BSD" port .. using X11 .. >>>>> >>>>> Maybe we should be getting rid of them ? >>>> I agree, we should delete them. I just shuffled them around in the hope that they would be useful for a potential future bsd port, but if/when that happens, we can dig them out from mercurial. >>>> >>>> A short explanation of how the files moved. The sound library is apparently composed of either a single library (solaris and macosx) or two libraries (linux and windows). Two building blocks, MIDI + ports and DirectAudio is used for all platforms, but they go into either the main library (libjsound) or the helper library. >>>> >>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio go into the main libjsound. >>>> >>>> I have no idea why this split is necessary, but this is how the libraries de facto is compiled, and the code needs to match that. If it would be possible to move libjsoundds and libjsoundalsa into libjsound directly, things would be greatly simplified. >>> >>> As far as I know the split was made to dynamically load ALSA/DirectSound stuff. If it's not available (or old unsupported version is installed), libjsound stuff continues to work (in pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS on Linux). >>> For now Windows (DirectSound) libjsoundds stuff can be merged into libjsound, but I'm not sure we can rely on ALSA is always available on Linux (but most likely if ALSA is not available, libjsound does not provide any functionality, so I suppose libjsoundalsa stuff can be moved to libjsound as well) >>> >>> --alex >>> >>>> >>>> /Magnus >>>> >>>>> >>>>> -phil. >>>>> >>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote: >>>>>> Digging a bit, those files came with the initial Macosx support. It doesn't look like they were ever used. >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>>> On 2018-03-15 09:53, Phil Race wrote: >>>>>>> It is very hard to follow all the moved around files, but one thing >>>>>>> that sticks out is there is a "bsd" directory created and I can't >>>>>>> work out how the files in there are used. >>>>>>> If they are for a BSD port of OpenJDK where is rest of the support for that ? >>>>>>> >>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>>>>>>> Looks good to me. I tried cleaning this up before but failed to find a reasonable split, but this seems like a good split between common and library specific. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>>>>>>> I forgot to add the client mailing lists as recipients. Sorry. (Not sure if "sounds" belong to "awt" or "2d".) >>>>>>> >>>>>>> In fact, there is a sound-specific list, which I've added. >>>>>>> >>>>>>> -phil. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>>>>>>> From the bug description: >>>>>>>>>> >>>>>>>>>> Moving this to a separate bug from JDK-8055190. In SoundLibraries.gmk, the source code splitting is not complete. The directory libjsound is used to build not only libjsound but libjsoundalsa and libjsoundds, and thus needs a complex include/exclude system like before. >>>>>>>>>> >>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are completely clean. On macosx, there's a binary diff (but nothing else) on libjsound.dylib. On linux, some offset seems to have changed, which caused a slight change in disass and fulldump for libjsound.so. I'm not quite sure what's causing it, but I'm convinced it's harmless. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>>>>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>>>>>>> >>>>>>>>>> /Magnus >> > From magnus.ihse.bursie at oracle.com Fri Mar 16 18:12:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 16 Mar 2018 19:12:08 +0100 Subject: RFR: JDK-8199682 Clean up building the saproc library In-Reply-To: <5AAB52D1.6040707@oracle.com> References: <39fbd44c-030d-582f-f4f9-9bc9f3e53c42@oracle.com> <5AAB52D1.6040707@oracle.com> Message-ID: Hi Sundar, I almost missed your mail, since you removed both me and build-dev from the cc list... > 16 mars 2018 kl. 06:14 skrev Sundararajan Athijegannathan : > > Renaming sawindbg as saproc sounds odd. For Linux, Solaris/Unix, we either use /proc & libproc, so calling saproc for those makes sense. But Windows? We have a separate debugger class to load platform specific native library. What is the reason for uniform naming? This is the only library in the JDK that has a different name on different platform. This clashes with the design of the build system, and requires a clunky workaround. For the upcoming changes in the build system, this goes from an annoyance to a blocker. No other components have their names based on the OS functionality they use, even if they use vastly different APIs on different platforms; rather they are named after the services they provide to the JDK. My assumption was that ?saproc? meant ?serviceability agent process handling?, and that this was a reasonable name for all platforms. Also, the source code for all platforms reside in the ?libsaproc? directory, which is consistent with the JDK standard for matching source code to native library. But if you believe this is an inappropriate name, let?s work together to find a name that works for all platforms. This of course will lead to new names for the current libsaproc.* libraries, and the source code directories. /Magnus > > -Sundar > > On 16/03/18, 12:19 AM, Magnus Ihse Bursie wrote: >> >> >> On 2018-03-15 19:39, Erik Joelsson wrote: >>> Looks good to me. >>> >>> The removed source files, are those some kind of tests? >> I don't really know; they have been excluded from the build for all time. My guess is that the Bsd* stuff is, like in the case of the sound libraries, bsd-based stuff that arrived with the mac port (but disabled). The test.c is a trivial main() method which looks more like a left-over adhoc testing from the initial developer. Perhaps someone wants to turn it into a proper test, but it seems like it's not much even to start with. (And hopefully we have much better real test coverage of this now.) >> >> /Magnus >>> >>> /Erik >>> >>> >>> On 2018-03-15 11:22, Magnus Ihse Bursie wrote: >>>> The saproc library has historically been built in quite odd ways on almost all platforms. When the old build system was converted, this was not changed. >>>> >>>> However, now the time has come to streamline this and build this library just as any other. >>>> >>>> The most visible change, perhaps, is that the library is now named saproc on all platforms, even Windows. Other changes include: >>>> * Don't set flags that is already set by the default flags. >>>> * Don't set flags that do not have anny effect. >>>> * Don't subst away the WIN32_LEAN_AND_MEAN definition, it's perfectly okay to have it. >>>> * Don't set CXX linker on solaris -- this was not needed so no reason to do it. >>>> * Cleaned up some old hooks for closed code that is no longer needed. >>>> >>>> I have verified this using COMPARE_BUILD. This shows only the expected differences: >>>> * On all platforms: class file changes for WindbgDebuggerLocal.java. >>>> * On solaris: some minor symbol differences, since the linker now uses C framework functions instead of C++. (And with symbol changes always comes disasm changes.) >>>> * On linux: a binary difference for libsaproc.so, but no size/symbol/deps/disasm change. >>>> * On macosx: no changes at all. >>>> * On windows: sawindbg.dll is renamed to saproc.dll. When I made a manual comparison between the two files, I found no significant differences. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199682 >>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199682-clean-up-saproc/webrev.01 >>>> >>>> /Magnus >>>> >>> >> From erik.joelsson at oracle.com Fri Mar 16 18:52:01 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 16 Mar 2018 11:52:01 -0700 Subject: RFR: JDK-8199745: JDK-8199668 introduced a build race on macosx Message-ID: <0d380d89-0965-5c41-380e-5a72a38615b7@oracle.com> Hello, JDK-8199668 introduced a race in the macosx build. The library libawt_lawt links against libosxapp. Before the change, the declaration of libosxapp happened before libawt_lawt, but in that change the order reversed. This makes the dependency declaration between them no longer functioning. To fix this I changed the relevant instances of $(BUILD_LIBFOO) to $(call FindLib, module, foo). The problem with using BUILD_LIBFOO is that it is only defined in the same makefile context and after the call to SetupNativeCompilation for it. The FindLib macro can be used anywhere. While fixing this I found more similar broken dependency declarations and fixed those as well including some cleanup. I did not replace all instances. Maybe we should, but I assume this will get handled differently with the further cleanups in this area. Bug: https://bugs.openjdk.java.net/browse/JDK-8199745 Webrev: http://cr.openjdk.java.net/~erikj/8199745/webrev.01/ /Erik From tim.bell at oracle.com Fri Mar 16 19:13:08 2018 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 16 Mar 2018 12:13:08 -0700 Subject: RFR: JDK-8199745: JDK-8199668 introduced a build race on macosx In-Reply-To: <0d380d89-0965-5c41-380e-5a72a38615b7@oracle.com> References: <0d380d89-0965-5c41-380e-5a72a38615b7@oracle.com> Message-ID: <5AAC1744.9080601@oracle.com> Erik: > Bug: https://bugs.openjdk.java.net/browse/JDK-8199745 > > Webrev: http://cr.openjdk.java.net/~erikj/8199745/webrev.01/ Looks good. Tim From erik.joelsson at oracle.com Fri Mar 16 23:16:02 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 16 Mar 2018 16:16:02 -0700 Subject: RFR: JDK-8199749: Debug symbols are not copied to exploded image on Mac Message-ID: Debug symbols are by default external and the idea is that we copy them to the exploded image together with the native libraries, to have them available for debugging. This logic fails on Windows and Mac due to some intricate make dependency complications. On Windows this fails on the initial build already, on Mac the problem only appears if you make a change to a source file and rebuild incrementally. On both, if you rebuild again, the files get copied. On Solaris and Linux we symlink these files instead of copying, so after the first build, the symlinks do not need to be recreated, which is why this isn't an issue there. The underlying cause for this is that we are trying to trick make into correctly tracking dependencies when a rule has multiple targets. The link rule creates both the native library as well as the debuginfo files. A rule like that is always causing trouble in some way but various workarounds exist. Currently we work around it by adding this declaration: $$($1_DEBUGINFO_FILES): $$($1_TARGET) This trips up make if DEBUGINFO_FILES already exists, since there is no recipe, make will not consider DEBUGINFO to have been updated just because TARGET was rebuilt. If we add a recipe, make will consider DEBUGINFO to have changed. The obvious recipe is a simple touch on DEBUGINFO. That way we also guarantee that the DEBUGINFO is newer than TARGET so the rule doesn't get executed again on the next run. This whole type of workaround for dealing with multiple files created by the same rule has a flaw. If something external deletes a DEBUGINFO file, it would currently not be recreated. In the new solution it would be touched as an empty file, which is even worse. To fix this, I've added a parse time check on the DEBUGINFO files and if either of them are gone, the TARGET is explicitly deleted. This forces a rebuild of both TARGET and DEBUGINFO. While at it, I noticed that the import library on Windows suffers from the same problem so applied the same fix there. Bug: https://bugs.openjdk.java.net/browse/JDK-8199749 Webrev: http://cr.openjdk.java.net/~erikj/8199749/webrev.01/index.html /Erik From edward.nevill at gmail.com Sat Mar 17 19:02:40 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Sat, 17 Mar 2018 19:02:40 +0000 Subject: RFR: 8199138: Add RISC-V support to Zero Message-ID: <1521313360.26308.4.camel@gmail.com> Hi, Please review the following webrev Bugid: https://bugs.openjdk.java.net/browse/JDK-8199138 Webrev: http://cr.openjdk.java.net/~enevill/8199138/webrev.00 This webrev add Zero support for RISC-V I propose to set up a project to develop template interpreter, C1 & C2 support for RISC-V and I will file a JEP for that work. This patch just gets RISC-V building with Zero. Many thanks, Ed. From aph at redhat.com Sun Mar 18 14:37:17 2018 From: aph at redhat.com (Andrew Haley) Date: Sun, 18 Mar 2018 14:37:17 +0000 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <1521313360.26308.4.camel@gmail.com> References: <1521313360.26308.4.camel@gmail.com> Message-ID: On 03/17/2018 07:02 PM, Edward Nevill wrote: > Webrev: http://cr.openjdk.java.net/~enevill/8199138/webrev.00 > > This webrev add Zero support for RISC-V What happens with atomics? Do we fall back to GCC builtins for everything? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From edward.nevill at gmail.com Sun Mar 18 20:19:11 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Sun, 18 Mar 2018 20:19:11 +0000 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: References: <1521313360.26308.4.camel@gmail.com> Message-ID: <1521404351.3951.7.camel@gmail.com> On Sun, 2018-03-18 at 14:37 +0000, Andrew Haley wrote: > On 03/17/2018 07:02 PM, Edward Nevill wrote: > > Webrev: http://cr.openjdk.java.net/~enevill/8199138/webrev.00 > > > > This webrev add Zero support for RISC-V > > What happens with atomics? Do we fall back to GCC builtins for everything? > Pretty much. The only atomic operation which doesn't used GCC builtins is os::atomic_copy64. For RISC-V this just does the same as all other 64 bit CPUs. *(jlong *) dst = *(const jlong *) src; Interestingly, there is no implementation of atomic_copy64 for ARM32. I guess it just relies on the compiler generating LDRD/STRD correctly and doesn't support earlier ARM32 archs. I'll do a bit of investigation. For reference here is the implementation of atomic_copy64. Regards, Ed. --- CUT --- static void atomic_copy64(const volatile void *src, volatile void *dst) { #if defined(PPC32) && !defined(__SPE__) double tmp; asm volatile ("lfd %0, %2\n" "stfd %0, %1\n" : "=&f"(tmp), "=Q"(*(volatile double*)dst) : "Q"(*(volatile double*)src)); #elif defined(PPC32) && defined(__SPE__) long tmp; asm volatile ("evldd %0, %2\n" "evstdd %0, %1\n" : "=&r"(tmp), "=Q"(*(volatile long*)dst) : "Q"(*(volatile long*)src)); #elif defined(S390) && !defined(_LP64) double tmp; asm volatile ("ld %0, 0(%1)\n" "std %0, 0(%2)\n" : "=r"(tmp) : "a"(src), "a"(dst)); #else *(jlong *) dst = *(const jlong *) src; #endif --- CUT --- From aph at redhat.com Mon Mar 19 09:40:53 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 19 Mar 2018 09:40:53 +0000 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <1521404351.3951.7.camel@gmail.com> References: <1521313360.26308.4.camel@gmail.com> <1521404351.3951.7.camel@gmail.com> Message-ID: On 03/18/2018 08:19 PM, Edward Nevill wrote: > Pretty much. The only atomic operation which doesn't used GCC builtins is os::atomic_copy64. For RISC-V this just does the same as all other 64 bit CPUs. > > *(jlong *) dst = *(const jlong *) src; That's probably wrong, but it'll do for now. We'll need something better in the future. GCC's __atomic_{load,store} (__ATOMIC_RELAXED) would do it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Mon Mar 19 13:27:39 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 19 Mar 2018 14:27:39 +0100 Subject: RFR: JDK-8199749: Debug symbols are not copied to exploded image on Mac In-Reply-To: References: Message-ID: <71DC664D-DDD2-41D2-A36C-B346B4EA03F4@oracle.com> > 17 mars 2018 kl. 00:16 skrev Erik Joelsson : > > Debug symbols are by default external and the idea is that we copy them to the exploded image together with the native libraries, to have them available for debugging. This logic fails on Windows and Mac due to some intricate make dependency complications. On Windows this fails on the initial build already, on Mac the problem only appears if you make a change to a source file and rebuild incrementally. On both, if you rebuild again, the files get copied. > > On Solaris and Linux we symlink these files instead of copying, so after the first build, the symlinks do not need to be recreated, which is why this isn't an issue there. > > The underlying cause for this is that we are trying to trick make into correctly tracking dependencies when a rule has multiple targets. The link rule creates both the native library as well as the debuginfo files. A rule like that is always causing trouble in some way but various workarounds exist. Currently we work around it by adding this declaration: > > $$($1_DEBUGINFO_FILES): $$($1_TARGET) > > This trips up make if DEBUGINFO_FILES already exists, since there is no recipe, make will not consider DEBUGINFO to have been updated just because TARGET was rebuilt. If we add a recipe, make will consider DEBUGINFO to have changed. The obvious recipe is a simple touch on DEBUGINFO. That way we also guarantee that the DEBUGINFO is newer than TARGET so the rule doesn't get executed again on the next run. > > This whole type of workaround for dealing with multiple files created by the same rule has a flaw. If something external deletes a DEBUGINFO file, it would currently not be recreated. In the new solution it would be touched as an empty file, which is even worse. To fix this, I've added a parse time check on the DEBUGINFO files and if either of them are gone, the TARGET is explicitly deleted. This forces a rebuild of both TARGET and DEBUGINFO. > > While at it, I noticed that the import library on Windows suffers from the same problem so applied the same fix there. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199749 > > Webrev: http://cr.openjdk.java.net/~erikj/8199749/webrev.01/index.html Looks good to me. /Magnus > > /Erik > From erik.joelsson at oracle.com Mon Mar 19 15:56:29 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 19 Mar 2018 08:56:29 -0700 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <1521313360.26308.4.camel@gmail.com> References: <1521313360.26308.4.camel@gmail.com> Message-ID: <8d312e6e-2466-847c-57f7-77eb3fdc1e2e@oracle.com> Build changes look ok to me. /Erik On 2018-03-17 12:02, Edward Nevill wrote: > Hi, > > Please review the following webrev > > Bugid: https://bugs.openjdk.java.net/browse/JDK-8199138 > Webrev: http://cr.openjdk.java.net/~enevill/8199138/webrev.00 > > This webrev add Zero support for RISC-V > > I propose to set up a project to develop template interpreter, C1 & C2 > support for RISC-V and I will file a JEP for that work. This patch just > gets RISC-V building with Zero. > > Many thanks, > Ed. From kim.barrett at oracle.com Mon Mar 19 23:23:58 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 19 Mar 2018 19:23:58 -0400 Subject: RFR: build pragma error with gcc 4.4.7 In-Reply-To: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com> References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com> Message-ID: <01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com> > On Mar 16, 2018, at 6:48 AM, Michal Vala wrote: > > Hi, > > I've been trying to build latest jdk with gcc 4.4.7 and I hit compile error due to pragma used in function: > > /mnt/ramdisk/openjdk/src/hotspot/os/linux/os_linux.inline.hpp:103: error: #pragma GCC diagnostic not allowed inside functions > > > I'm sending little patch that fixes the issue by wrapping whole function. I've also created a macro for ignoring deprecated declaration inside compilerWarnings.hpp to line up with others. > > Can someone please review? If it's ok, I would also need a sponsor. > > > diff -r 422615764e12 src/hotspot/os/linux/os_linux.inline.hpp > --- a/src/hotspot/os/linux/os_linux.inline.hpp Thu Mar 15 14:54:10 2018 -0700 > +++ b/src/hotspot/os/linux/os_linux.inline.hpp Fri Mar 16 10:50:24 2018 +0100 > @@ -96,13 +96,12 @@ > return ::ftruncate64(fd, length); > } > > -inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) > -{ > // readdir_r has been deprecated since glibc 2.24. > // See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details. > -#pragma GCC diagnostic push > -#pragma GCC diagnostic ignored "-Wdeprecated-declarations" > - > +PRAGMA_DIAG_PUSH > +PRAGMA_DEPRECATED_IGNORED > +inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) > +{ > dirent* p; > int status; > assert(dirp != NULL, "just checking"); > @@ -114,11 +113,11 @@ > if((status = ::readdir_r(dirp, dbuf, &p)) != 0) { > errno = status; > return NULL; > - } else > + } else { > return p; > - > -#pragma GCC diagnostic pop > + } > } > +PRAGMA_DIAG_POP > > inline int os::closedir(DIR *dirp) { > assert(dirp != NULL, "argument is NULL"); > diff -r 422615764e12 src/hotspot/share/utilities/compilerWarnings.hpp > --- a/src/hotspot/share/utilities/compilerWarnings.hpp Thu Mar 15 14:54:10 2018 -0700 > +++ b/src/hotspot/share/utilities/compilerWarnings.hpp Fri Mar 16 10:50:24 2018 +0100 > @@ -48,6 +48,7 @@ > #define PRAGMA_FORMAT_NONLITERAL_IGNORED _Pragma("GCC diagnostic ignored \"-Wformat-nonliteral\"") \ > _Pragma("GCC diagnostic ignored \"-Wformat-security\"") > #define PRAGMA_FORMAT_IGNORED _Pragma("GCC diagnostic ignored \"-Wformat\"") > +#define PRAGMA_DEPRECATED_IGNORED _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"") > > #if defined(__clang_major__) && \ > (__clang_major__ >= 4 || \ > > > Thanks! > > -- > Michal Vala > OpenJDK QE > Red Hat Czech Given that there seem to be no callers of os::readdir that share the DIR* among multiple threads, it would seem easier to just replace the use of ::readdir_r with ::readdir. That seems to be the intent in the deprecation decision; use ::readdir, and either don't share a DIR* among threads, or use external locking when doing so. There are also problems with the patch as provided. (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this change is being made in support of, the warning would be disabled for all following code in any translation unit that includes this file. That doesn't seem good. (2) The default empty definition for PRAGMA_DEPRECATED_IGNORED is missing. That means the macro can't be used in shared code, in which case having defined in (shared) compilerWarnings.hpp is questionable. From mvala at redhat.com Tue Mar 20 09:45:40 2018 From: mvala at redhat.com (Michal Vala) Date: Tue, 20 Mar 2018 10:45:40 +0100 Subject: RFR: build pragma error with gcc 4.4.7 In-Reply-To: <01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com> References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com> <01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com> Message-ID: <8698f94a-43fe-014f-6627-1cd88c4a1963@redhat.com> On 03/20/2018 12:23 AM, Kim Barrett wrote: > > Given that there seem to be no callers of os::readdir that share the > DIR* among multiple threads, it would seem easier to just replace the > use of ::readdir_r with ::readdir. That seems to be the intent in the > deprecation decision; use ::readdir, and either don't share a DIR* > among threads, or use external locking when doing so. > > There are also problems with the patch as provided. > > (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this > change is being made in support of, the warning would be disabled for > all following code in any translation unit that includes this file. > That doesn't seem good. > > (2) The default empty definition for PRAGMA_DEPRECATED_IGNORED is > missing. That means the macro can't be used in shared code, in which > case having defined in (shared) compilerWarnings.hpp is questionable. > Thanks for the review, these are valid comments. I'll prepare new patch replacing ::readdir_r with ::readdir. -- Michal Vala OpenJDK QE Red Hat Czech From magnus.ihse.bursie at oracle.com Tue Mar 20 11:24:39 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 20 Mar 2018 12:24:39 +0100 Subject: RFR: JDK-8199682 Clean up building the saproc library In-Reply-To: References: <39fbd44c-030d-582f-f4f9-9bc9f3e53c42@oracle.com> <5AAB52D1.6040707@oracle.com> Message-ID: <2d26e786-5394-7bdf-a0f5-95ea7b36247b@oracle.com> On 2018-03-16 19:12, Magnus Ihse Bursie wrote: > Hi Sundar, > > I almost missed your mail, since you removed both me and build-dev from the cc list... > >> 16 mars 2018 kl. 06:14 skrev Sundararajan Athijegannathan : >> >> Renaming sawindbg as saproc sounds odd. For Linux, Solaris/Unix, we either use /proc & libproc, so calling saproc for those makes sense. But Windows? We have a separate debugger class to load platform specific native library. What is the reason for uniform naming? > This is the only library in the JDK that has a different name on different platform. This clashes with the design of the build system, and requires a clunky workaround. For the upcoming changes in the build system, this goes from an annoyance to a blocker. > > No other components have their names based on the OS functionality they use, even if they use vastly different APIs on different platforms; rather they are named after the services they provide to the JDK. > > My assumption was that ?saproc? meant ?serviceability agent process handling?, and that this was a reasonable name for all platforms. Also, the source code for all platforms reside in the ?libsaproc? directory, which is consistent with the JDK standard for matching source code to native library. > > But if you believe this is an inappropriate name, let?s work together to find a name that works for all platforms. This of course will lead to new names for the current libsaproc.* libraries, and the source code directories. Hi Sundar, Are you okay with this rationale for changing to saproc, or do you want to discuss this further? /Magnus > > /Magnus > >> -Sundar >> >> On 16/03/18, 12:19 AM, Magnus Ihse Bursie wrote: >>> >>> On 2018-03-15 19:39, Erik Joelsson wrote: >>>> Looks good to me. >>>> >>>> The removed source files, are those some kind of tests? >>> I don't really know; they have been excluded from the build for all time. My guess is that the Bsd* stuff is, like in the case of the sound libraries, bsd-based stuff that arrived with the mac port (but disabled). The test.c is a trivial main() method which looks more like a left-over adhoc testing from the initial developer. Perhaps someone wants to turn it into a proper test, but it seems like it's not much even to start with. (And hopefully we have much better real test coverage of this now.) >>> >>> /Magnus >>>> /Erik >>>> >>>> >>>> On 2018-03-15 11:22, Magnus Ihse Bursie wrote: >>>>> The saproc library has historically been built in quite odd ways on almost all platforms. When the old build system was converted, this was not changed. >>>>> >>>>> However, now the time has come to streamline this and build this library just as any other. >>>>> >>>>> The most visible change, perhaps, is that the library is now named saproc on all platforms, even Windows. Other changes include: >>>>> * Don't set flags that is already set by the default flags. >>>>> * Don't set flags that do not have anny effect. >>>>> * Don't subst away the WIN32_LEAN_AND_MEAN definition, it's perfectly okay to have it. >>>>> * Don't set CXX linker on solaris -- this was not needed so no reason to do it. >>>>> * Cleaned up some old hooks for closed code that is no longer needed. >>>>> >>>>> I have verified this using COMPARE_BUILD. This shows only the expected differences: >>>>> * On all platforms: class file changes for WindbgDebuggerLocal.java. >>>>> * On solaris: some minor symbol differences, since the linker now uses C framework functions instead of C++. (And with symbol changes always comes disasm changes.) >>>>> * On linux: a binary difference for libsaproc.so, but no size/symbol/deps/disasm change. >>>>> * On macosx: no changes at all. >>>>> * On windows: sawindbg.dll is renamed to saproc.dll. When I made a manual comparison between the two files, I found no significant differences. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199682 >>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8199682-clean-up-saproc/webrev.01 >>>>> >>>>> /Magnus >>>>> From matthias.baesken at sap.com Tue Mar 20 13:12:53 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 20 Mar 2018 13:12:53 +0000 Subject: [XXS] 8199858 : solaris-x86_64 : unpack200 fails linking with SS12u4 Message-ID: <834e13c4dc364e7f9221ea7cc9dd7aa1@sap.com> Hello , could you please review this small fix for Solaris x86_64 ? We were running into build errors for unpack200 on Solaris x86_64 because of missing symbol "environ" . The patch adds environ to the mapfile . ( seems this is a similar / same problem already solved for Solaris Sparc with https://bugs.openjdk.java.net/browse/JDK-8172548 JDK-8172548 : unpack200 fails linking with new update of SS12u4 ) Bug : https://bugs.openjdk.java.net/browse/JDK-8199858 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8199858/ Thanks, Matthias From edward.nevill at gmail.com Tue Mar 20 13:54:15 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 20 Mar 2018 13:54:15 +0000 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <259e05b8-dbb1-4aa4-f451-6b7078eeb2ff@oracle.com> References: <1521313360.26308.4.camel@gmail.com> <259e05b8-dbb1-4aa4-f451-6b7078eeb2ff@oracle.com> Message-ID: <1521554055.3029.4.camel@gmail.com> On Tue, 2018-03-20 at 08:39 +0100, Erik Helin wrote: > Please review the following webrev > > > > Bugid: https://bugs.openjdk.java.net/browse/JDK-8199138 > > Webrev: http://cr.openjdk.java.net/~enevill/8199138/webrev.00 > > 32 # First, filter out everything that doesn't begin with "aarch64-" > 33 if ! echo $* | grep '^aarch64-\|^riscv64-' >/dev/null ; then > > Could you please update the comment on line 32 to say the same thing as > the code? > Hi Eirk, Thanks for this. I have updated the webrev with the above comment. http://cr.openjdk.java.net/~enevill/8199138/webrev.01 I have also fixed a problem encountered with the submit-hs repo where the build machine had older headers which did not define EM_RISCV. The solution is to define EM_RISCV if not already defined as is done for aarch64. IE. #ifndef EM_AARCH64 #define EM_AARCH64 183 /* ARM AARCH64 */ #endif +#ifndef EM_RISCV + #define EM_RISCV 243 +#endif This now passes the submit-hs tests. Does this look OK to push now? Thanks, Ed. From volker.simonis at gmail.com Tue Mar 20 14:27:12 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 20 Mar 2018 15:27:12 +0100 Subject: [XXS] 8199858 : solaris-x86_64 : unpack200 fails linking with SS12u4 In-Reply-To: <834e13c4dc364e7f9221ea7cc9dd7aa1@sap.com> References: <834e13c4dc364e7f9221ea7cc9dd7aa1@sap.com> Message-ID: Hi Matthias, the change looks good. Can you please also update the copyright year before pushing (no need for a new webrev). Thanks, Volker On Tue, Mar 20, 2018 at 2:12 PM, Baesken, Matthias wrote: > Hello , could you please review this small fix for Solaris x86_64 ? > > We were running into build errors for unpack200 on Solaris x86_64 because of missing symbol "environ" . > The patch adds environ to the mapfile . > > ( seems this is a similar / same problem already solved for Solaris Sparc with > > https://bugs.openjdk.java.net/browse/JDK-8172548 > > JDK-8172548 : unpack200 fails linking with new update of SS12u4 ) > > > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8199858 > > > Webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8199858/ > > > > Thanks, Matthias From sundararajan.athijegannathan at oracle.com Tue Mar 20 15:09:47 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Mar 2018 20:39:47 +0530 Subject: RFR: JDK-8199682 Clean up building the saproc library In-Reply-To: <2d26e786-5394-7bdf-a0f5-95ea7b36247b@oracle.com> References: <39fbd44c-030d-582f-f4f9-9bc9f3e53c42@oracle.com> <5AAB52D1.6040707@oracle.com> <2d26e786-5394-7bdf-a0f5-95ea7b36247b@oracle.com> Message-ID: <5AB1243B.1020807@oracle.com> Hi, Sounds good - so long as we don't have scripts that depend on the old name. Or if those could be fixed... -Sundar On 20/03/18, 4:54 PM, Magnus Ihse Bursie wrote: > > On 2018-03-16 19:12, Magnus Ihse Bursie wrote: >> Hi Sundar, >> >> I almost missed your mail, since you removed both me and build-dev >> from the cc list... >> >>> 16 mars 2018 kl. 06:14 skrev Sundararajan Athijegannathan >>> : >>> >>> Renaming sawindbg as saproc sounds odd. For Linux, Solaris/Unix, we >>> either use /proc & libproc, so calling saproc for those makes sense. >>> But Windows? We have a separate debugger class to load platform >>> specific native library. What is the reason for uniform naming? >> This is the only library in the JDK that has a different name on >> different platform. This clashes with the design of the build system, >> and requires a clunky workaround. For the upcoming changes in the >> build system, this goes from an annoyance to a blocker. >> >> No other components have their names based on the OS functionality >> they use, even if they use vastly different APIs on different >> platforms; rather they are named after the services they provide to >> the JDK. >> >> My assumption was that ?saproc? meant ?serviceability agent process >> handling?, and that this was a reasonable name for all platforms. >> Also, the source code for all platforms reside in the ?libsaproc? >> directory, which is consistent with the JDK standard for matching >> source code to native library. >> >> But if you believe this is an inappropriate name, let?s work together >> to find a name that works for all platforms. This of course will lead >> to new names for the current libsaproc.* libraries, and the source >> code directories. > Hi Sundar, > > Are you okay with this rationale for changing to saproc, or do you > want to discuss this further? > > /Magnus >> >> /Magnus >> >>> -Sundar >>> >>> On 16/03/18, 12:19 AM, Magnus Ihse Bursie wrote: >>>> >>>> On 2018-03-15 19:39, Erik Joelsson wrote: >>>>> Looks good to me. >>>>> >>>>> The removed source files, are those some kind of tests? >>>> I don't really know; they have been excluded from the build for all >>>> time. My guess is that the Bsd* stuff is, like in the case of the >>>> sound libraries, bsd-based stuff that arrived with the mac port >>>> (but disabled). The test.c is a trivial main() method which looks >>>> more like a left-over adhoc testing from the initial developer. >>>> Perhaps someone wants to turn it into a proper test, but it seems >>>> like it's not much even to start with. (And hopefully we have much >>>> better real test coverage of this now.) >>>> >>>> /Magnus >>>>> /Erik >>>>> >>>>> >>>>> On 2018-03-15 11:22, Magnus Ihse Bursie wrote: >>>>>> The saproc library has historically been built in quite odd ways >>>>>> on almost all platforms. When the old build system was converted, >>>>>> this was not changed. >>>>>> >>>>>> However, now the time has come to streamline this and build this >>>>>> library just as any other. >>>>>> >>>>>> The most visible change, perhaps, is that the library is now >>>>>> named saproc on all platforms, even Windows. Other changes include: >>>>>> * Don't set flags that is already set by the default flags. >>>>>> * Don't set flags that do not have anny effect. >>>>>> * Don't subst away the WIN32_LEAN_AND_MEAN definition, it's >>>>>> perfectly okay to have it. >>>>>> * Don't set CXX linker on solaris -- this was not needed so no >>>>>> reason to do it. >>>>>> * Cleaned up some old hooks for closed code that is no longer >>>>>> needed. >>>>>> >>>>>> I have verified this using COMPARE_BUILD. This shows only the >>>>>> expected differences: >>>>>> * On all platforms: class file changes for WindbgDebuggerLocal.java. >>>>>> * On solaris: some minor symbol differences, since the linker now >>>>>> uses C framework functions instead of C++. (And with symbol >>>>>> changes always comes disasm changes.) >>>>>> * On linux: a binary difference for libsaproc.so, but no >>>>>> size/symbol/deps/disasm change. >>>>>> * On macosx: no changes at all. >>>>>> * On windows: sawindbg.dll is renamed to saproc.dll. When I made >>>>>> a manual comparison between the two files, I found no significant >>>>>> differences. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199682 >>>>>> WebRev: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8199682-clean-up-saproc/webrev.01 >>>>>> >>>>>> >>>>>> /Magnus >>>>>> > From erik.joelsson at oracle.com Tue Mar 20 15:38:10 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Mar 2018 08:38:10 -0700 Subject: [XXS] 8199858 : solaris-x86_64 : unpack200 fails linking with SS12u4 In-Reply-To: <834e13c4dc364e7f9221ea7cc9dd7aa1@sap.com> References: <834e13c4dc364e7f9221ea7cc9dd7aa1@sap.com> Message-ID: Looks good. /Erik On 2018-03-20 06:12, Baesken, Matthias wrote: > Hello , could you please review this small fix for Solaris x86_64 ? > > We were running into build errors for unpack200 on Solaris x86_64 because of missing symbol "environ" . > The patch adds environ to the mapfile . > > ( seems this is a similar / same problem already solved for Solaris Sparc with > > https://bugs.openjdk.java.net/browse/JDK-8172548 > > JDK-8172548 : unpack200 fails linking with new update of SS12u4 ) > > > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8199858 > > > Webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8199858/ > > > > Thanks, Matthias From erik.joelsson at oracle.com Tue Mar 20 19:05:09 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Mar 2018 12:05:09 -0700 Subject: RFR: JDK-8199884: JDK-8199749 broke build with make 3.81 Message-ID: <5daee40c-64a9-6187-f2fe-1c08e24af1ba@oracle.com> My consistency check in JDK-8199749 broke the build if using make 3.81. We use make 4.0 most of the time internally so I didn't test with older make versions. The typical error looks like this: lib/CompileLibjsig.gmk:92: *** /Users/erik/hg/jdk-make381/open/build/macosx-x86_64-normal-server-release/support/modules_libs/java.base/libjsig.dylib.dSYM/Contents/Info.plist was not created for /Users/erik/hg/jdk-make381/open/build/macosx-x86_64-normal-server-release/support/modules_libs/java.base/libjsig.dylib. Stop. make[2]: *** [hotspot-jsig] Error 2 My proposed fix adds a condition around these safety checks so that they are only performed on known working versions of make. Webrev: http://cr.openjdk.java.net/~erikj/8199884/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8199884 /Erik From tim.bell at oracle.com Tue Mar 20 22:17:56 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 20 Mar 2018 15:17:56 -0700 Subject: RFR: JDK-8199884: JDK-8199749 broke build with make 3.81 In-Reply-To: <5daee40c-64a9-6187-f2fe-1c08e24af1ba@oracle.com> References: <5daee40c-64a9-6187-f2fe-1c08e24af1ba@oracle.com> Message-ID: <5AB18894.2070105@oracle.com> Erik: > My consistency check in JDK-8199749 broke the build if using make 3.81. > We use make 4.0 most of the time internally so I didn't test with older > make versions. The typical error looks like this: > > lib/CompileLibjsig.gmk:92: *** > /Users/erik/hg/jdk-make381/open/build/macosx-x86_64-normal-server-release/support/modules_libs/java.base/libjsig.dylib.dSYM/Contents/Info.plist > was not created for > /Users/erik/hg/jdk-make381/open/build/macosx-x86_64-normal-server-release/support/modules_libs/java.base/libjsig.dylib. > Stop. > make[2]: *** [hotspot-jsig] Error 2 > > My proposed fix adds a condition around these safety checks so that they > are only performed on known working versions of make. > > Webrev: http://cr.openjdk.java.net/~erikj/8199884/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199884 Looks good. /Tim From glaubitz at physik.fu-berlin.de Wed Mar 21 09:17:47 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 21 Mar 2018 18:17:47 +0900 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <1521404351.3951.7.camel@gmail.com> References: <1521313360.26308.4.camel@gmail.com> <1521404351.3951.7.camel@gmail.com> Message-ID: On 03/19/2018 05:19 AM, Edward Nevill wrote: > Interestingly, there is no implementation of atomic_copy64 for ARM32. I guess it just relies on the compiler generating LDRD/STRD correctly and doesn't support earlier ARM32 archs. I'll do a bit of investigation. I am planning to add arch-specific implementations for m68k and sh in the near future. From the current build logs in Debian, it seems that the JVM is actually hanging on these architectures from time to time and I think this could probably be related to atomic_copy64 actually not being 100% atomic. I already added the one for PowerPCSPE. It's also interesting that there is no implementation for 32-Bit MIPS either. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From erik.helin at oracle.com Wed Mar 21 13:21:11 2018 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 21 Mar 2018 14:21:11 +0100 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <1521554055.3029.4.camel@gmail.com> References: <1521313360.26308.4.camel@gmail.com> <259e05b8-dbb1-4aa4-f451-6b7078eeb2ff@oracle.com> <1521554055.3029.4.camel@gmail.com> Message-ID: <4fcbfbe2-4a05-6968-6ba2-0f8900970336@oracle.com> On 03/20/2018 02:54 PM, Edward Nevill wrote: > On Tue, 2018-03-20 at 08:39 +0100, Erik Helin wrote: >> Please review the following webrev >>> >>> Bugid: https://bugs.openjdk.java.net/browse/JDK-8199138 >>> Webrev: http://cr.openjdk.java.net/~enevill/8199138/webrev.00 >> >> 32 # First, filter out everything that doesn't begin with "aarch64-" >> 33 if ! echo $* | grep '^aarch64-\|^riscv64-' >/dev/null ; then >> >> Could you please update the comment on line 32 to say the same thing as >> the code? >> > > Hi Eirk, > > Thanks for this. I have updated the webrev with the above comment. > > http://cr.openjdk.java.net/~enevill/8199138/webrev.01 Please also update the error message at line 1802 - 1804: 1802 #error Method os::dll_load requires that one of following is defined:\ 1803 AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, __powerpc__, __powerpc64__, S390, SH, __sparc 1804 #endif > I have also fixed a problem encountered with the submit-hs repo where the build machine had older headers which did not define EM_RISCV. > > The solution is to define EM_RISCV if not already defined as is done for aarch64. > > IE. > > #ifndef EM_AARCH64 > #define EM_AARCH64 183 /* ARM AARCH64 */ > #endif > +#ifndef EM_RISCV > + #define EM_RISCV 243 > +#endif Maybe add a corresponding /* RISC-V */ comment to use the same style as the other defines? > This now passes the submit-hs tests. Ok, good. > Does this look OK to push now? Please send out a final webrev first. Thanks, Erik > Thanks, > Ed. > From magnus.ihse.bursie at oracle.com Wed Mar 21 14:09:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 21 Mar 2018 15:09:52 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com> <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com> <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com> Message-ID: <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com> On 2018-03-16 17:49, Alex Menkov wrote: > > > On 03/15/2018 13:09, Magnus Ihse Bursie wrote: >> >>> 15 mars 2018 kl. 20:13 skrev Phil Race : >>> >>> >>>> As far as I know the split was made to dynamically load >>>> ALSA/DirectSound stuff >>> >>> Yes, I think it is something like that for Linux >>> ie if at runtime a dependent-but-not-essential .so was not >>> installed it was not fatal. I don't know to what extent this is no >>> longer a >>> possible issue, or one that matters. >> >> I have not heard of any mainstream Linux distro in years that was >> lacking ALSA. >> >> If ALSA was not present, will the libraries fall back to OSS, or will >> there be just no sound available? > > No sound. > OSS support was dropped many years ago (IIRC in jdk7) > >> In any case, I think that whatever Linux distros we're targeting as >> supported, ALSA will be present. >> >> Alex, did I understand you correctly that in any case, a separate >> Windows library is always unnecessary, since we can rely on >> DirectAudio always being present in our supported versions of Windows? > > Yes, that's right. > Windows always has DirectSound pre-installed and its version is > greater than required (IIRC javasoundds requires DirectX 5). > > For now failure of libjsound loading is fatal (see > com.sun.media.sound.Platform.loadLibraries()), loading of extra libs > is non-fatal. > I believe libjsound loading failure should be made non-fatal, then all > the functionality will remain the same as we have now. Ok. Here is an updated webrev. I have made the following changes: * libjavasoundalsa and libjavasoundds is now folded into the main libjavasound native library, so there's exactly one library built on all platforms. * Loading of libjsound is made non-fatal. * I have cleaned out all obvious parts of the code that handle multiple libraries. Since loading the native library is now a all-or-nothing situation, the checks for various subsystems have been turned into a generic check if the native library is loaded. There is a lot of defines like USE_DSOUND which are always true. This could probably be cleaned up further, but it is not a build issue so I'm leaving that to the client team to handle. I have tested the following: ?* COMPARE_BUILD shows me just the expected changes in the build. ?* On my linux machine, failure to load libjsound.so was not fatal. ?* I have looked for sound tests. I found the test/jdk/javax/sound suite, which was included in tier3. So I've run tier3 testing on all platforms using our internal test system, and all tests pass. I don't know if there is any other tests I should run. If so, let me know. Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03 /Magnus > > --alex > >> >> /Magnus >> >>> >>> -phil. >>> >>>> On 03/15/2018 12:06 PM, Alex Menkov wrote: >>>> >>>> >>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote: >>>>>> On 2018-03-15 18:23, Phil Race wrote: >>>>>> I wondered if that might be the case since it was a "BSD" port .. >>>>>> using X11 .. >>>>>> >>>>>> Maybe we should be getting rid of them ? >>>>> I agree, we should delete them. I just shuffled them around in the >>>>> hope that they would be useful for a potential future bsd port, >>>>> but if/when that happens, we can dig them out from mercurial. >>>>> >>>>> A short explanation of how the files moved. The sound library is >>>>> apparently composed of either a single library (solaris and >>>>> macosx) or two libraries (linux and windows). Two building blocks, >>>>> MIDI + ports and DirectAudio is used for all platforms, but they >>>>> go into either the main library (libjsound) or the helper library. >>>>> >>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into >>>>> libjsoundds. On Linux, MIDI+Ports and DirectAudio go into >>>>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio >>>>> go into the main libjsound. >>>>> >>>>> I have no idea why this split is necessary, but this is how the >>>>> libraries de facto is compiled, and the code needs to match that. >>>>> If it would be possible to move libjsoundds and libjsoundalsa into >>>>> libjsound directly, things would be greatly simplified. >>>> >>>> As far as I know the split was made to dynamically load >>>> ALSA/DirectSound stuff. If it's not available (or old unsupported >>>> version is installed), libjsound stuff continues to work (in >>>> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS >>>> on Linux). >>>> For now Windows (DirectSound) libjsoundds stuff can be merged into >>>> libjsound, but I'm not sure we can rely on ALSA is always available >>>> on Linux (but most likely if ALSA is not available, libjsound does >>>> not provide any functionality, so I suppose libjsoundalsa stuff can >>>> be moved to libjsound as well) >>>> >>>> --alex >>>> >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> -phil. >>>>>> >>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote: >>>>>>> Digging a bit, those files came with the initial Macosx support. >>>>>>> It doesn't look like they were ever used. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>>>> On 2018-03-15 09:53, Phil Race wrote: >>>>>>>> It is very hard to follow all the moved around files, but one >>>>>>>> thing >>>>>>>> that sticks out is there is a "bsd" directory created and I can't >>>>>>>> work out how the files in there are used. >>>>>>>> If they are for a BSD port of OpenJDK where is rest of the >>>>>>>> support for that ? >>>>>>>> >>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>>>>>>>> Looks good to me. I tried cleaning this up before but failed >>>>>>>>> to find a reasonable split, but this seems like a good split >>>>>>>>> between common and library specific. >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>>>>>>>> I forgot to add the client mailing lists as recipients. >>>>>>>>>> Sorry. (Not sure if "sounds" belong to "awt" or "2d".) >>>>>>>> >>>>>>>> In fact, there is a sound-specific list, which I've added. >>>>>>>> >>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>>>>>>>> ?From the bug description: >>>>>>>>>>> >>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In >>>>>>>>>>> SoundLibraries.gmk, the source code splitting is not >>>>>>>>>>> complete. The directory libjsound is used to build not only >>>>>>>>>>> libjsound but libjsoundalsa and libjsoundds, and thus needs >>>>>>>>>>> a complex include/exclude system like before. >>>>>>>>>>> >>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris >>>>>>>>>>> are completely clean. On macosx, there's a binary diff (but >>>>>>>>>>> nothing else) on libjsound.dylib. On linux, some offset >>>>>>>>>>> seems to have changed, which caused a slight change in >>>>>>>>>>> disass and fulldump for libjsound.so. I'm not quite sure >>>>>>>>>>> what's causing it, but I'm convinced it's harmless. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>>>>>>>> WebRev: >>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>>>>>>>> >>>>>>>>>>> /Magnus >>> >> From erik.joelsson at oracle.com Wed Mar 21 15:22:15 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 21 Mar 2018 08:22:15 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com> <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com> <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com> <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com> Message-ID: Build changes look good. /Erik On 2018-03-21 07:09, Magnus Ihse Bursie wrote: > On 2018-03-16 17:49, Alex Menkov wrote: >> >> >> On 03/15/2018 13:09, Magnus Ihse Bursie wrote: >>> >>>> 15 mars 2018 kl. 20:13 skrev Phil Race : >>>> >>>> >>>>> As far as I know the split was made to dynamically load >>>>> ALSA/DirectSound stuff >>>> >>>> Yes, I think it is something like that for Linux >>>> ie if at runtime a dependent-but-not-essential .so was not >>>> installed it was not fatal. I don't know to what extent this is no >>>> longer a >>>> possible issue, or one that matters. >>> >>> I have not heard of any mainstream Linux distro in years that was >>> lacking ALSA. >>> >>> If ALSA was not present, will the libraries fall back to OSS, or >>> will there be just no sound available? >> >> No sound. >> OSS support was dropped many years ago (IIRC in jdk7) >> >>> In any case, I think that whatever Linux distros we're targeting as >>> supported, ALSA will be present. >>> >>> Alex, did I understand you correctly that in any case, a separate >>> Windows library is always unnecessary, since we can rely on >>> DirectAudio always being present in our supported versions of Windows? >> >> Yes, that's right. >> Windows always has DirectSound pre-installed and its version is >> greater than required (IIRC javasoundds requires DirectX 5). >> >> For now failure of libjsound loading is fatal (see >> com.sun.media.sound.Platform.loadLibraries()), loading of extra libs >> is non-fatal. >> I believe libjsound loading failure should be made non-fatal, then >> all the functionality will remain the same as we have now. > > Ok. > > Here is an updated webrev. I have made the following changes: > * libjavasoundalsa and libjavasoundds is now folded into the main > libjavasound native library, so there's exactly one library built on > all platforms. > * Loading of libjsound is made non-fatal. > * I have cleaned out all obvious parts of the code that handle > multiple libraries. Since loading the native library is now a > all-or-nothing situation, the checks for various subsystems have been > turned into a generic check if the native library is loaded. > > There is a lot of defines like USE_DSOUND which are always true. This > could probably be cleaned up further, but it is not a build issue so > I'm leaving that to the client team to handle. > > I have tested the following: > ?* COMPARE_BUILD shows me just the expected changes in the build. > ?* On my linux machine, failure to load libjsound.so was not fatal. > ?* I have looked for sound tests. I found the test/jdk/javax/sound > suite, which was included in tier3. So I've run tier3 testing on all > platforms using our internal test system, and all tests pass. > > I don't know if there is any other tests I should run. If so, let me > know. > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03 > > /Magnus > >> >> --alex >> >>> >>> /Magnus >>> >>>> >>>> -phil. >>>> >>>>> On 03/15/2018 12:06 PM, Alex Menkov wrote: >>>>> >>>>> >>>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote: >>>>>>> On 2018-03-15 18:23, Phil Race wrote: >>>>>>> I wondered if that might be the case since it was a "BSD" port >>>>>>> .. using X11 .. >>>>>>> >>>>>>> Maybe we should be getting rid of them ? >>>>>> I agree, we should delete them. I just shuffled them around in >>>>>> the hope that they would be useful for a potential future bsd >>>>>> port, but if/when that happens, we can dig them out from mercurial. >>>>>> >>>>>> A short explanation of how the files moved. The sound library is >>>>>> apparently composed of either a single library (solaris and >>>>>> macosx) or two libraries (linux and windows). Two building >>>>>> blocks, MIDI + ports and DirectAudio is used for all platforms, >>>>>> but they go into either the main library (libjsound) or the >>>>>> helper library. >>>>>> >>>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go >>>>>> into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into >>>>>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio >>>>>> go into the main libjsound. >>>>>> >>>>>> I have no idea why this split is necessary, but this is how the >>>>>> libraries de facto is compiled, and the code needs to match that. >>>>>> If it would be possible to move libjsoundds and libjsoundalsa >>>>>> into libjsound directly, things would be greatly simplified. >>>>> >>>>> As far as I know the split was made to dynamically load >>>>> ALSA/DirectSound stuff. If it's not available (or old unsupported >>>>> version is installed), libjsound stuff continues to work (in >>>>> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS >>>>> on Linux). >>>>> For now Windows (DirectSound) libjsoundds stuff can be merged into >>>>> libjsound, but I'm not sure we can rely on ALSA is always >>>>> available on Linux (but most likely if ALSA is not available, >>>>> libjsound does not provide any functionality, so I suppose >>>>> libjsoundalsa stuff can be moved to libjsound as well) >>>>> >>>>> --alex >>>>> >>>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote: >>>>>>>> Digging a bit, those files came with the initial Macosx >>>>>>>> support. It doesn't look like they were ever used. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>>> On 2018-03-15 09:53, Phil Race wrote: >>>>>>>>> It is very hard to follow all the moved around files, but one >>>>>>>>> thing >>>>>>>>> that sticks out is there is a "bsd" directory created and I can't >>>>>>>>> work out how the files in there are used. >>>>>>>>> If they are for a BSD port of OpenJDK where is rest of the >>>>>>>>> support for that ? >>>>>>>>> >>>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>>>>>>>>> Looks good to me. I tried cleaning this up before but failed >>>>>>>>>> to find a reasonable split, but this seems like a good split >>>>>>>>>> between common and library specific. >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>>>>>>>>> I forgot to add the client mailing lists as recipients. >>>>>>>>>>> Sorry. (Not sure if "sounds" belong to "awt" or "2d".) >>>>>>>>> >>>>>>>>> In fact, there is a sound-specific list, which I've added. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>>>>>>>>> ?From the bug description: >>>>>>>>>>>> >>>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In >>>>>>>>>>>> SoundLibraries.gmk, the source code splitting is not >>>>>>>>>>>> complete. The directory libjsound is used to build not only >>>>>>>>>>>> libjsound but libjsoundalsa and libjsoundds, and thus needs >>>>>>>>>>>> a complex include/exclude system like before. >>>>>>>>>>>> >>>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris >>>>>>>>>>>> are completely clean. On macosx, there's a binary diff (but >>>>>>>>>>>> nothing else) on libjsound.dylib. On linux, some offset >>>>>>>>>>>> seems to have changed, which caused a slight change in >>>>>>>>>>>> disass and fulldump for libjsound.so. I'm not quite sure >>>>>>>>>>>> what's causing it, but I'm convinced it's harmless. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>>>>>>>>> WebRev: >>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>>>>>>>>> >>>>>>>>>>>> /Magnus >>>> >>> > From alexey.menkov at oracle.com Wed Mar 21 18:08:07 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 21 Mar 2018 11:08:07 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com> <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com> <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com> <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com> Message-ID: <5860c201-7084-9903-8f9d-73ba7a28ca68@oracle.com> Hi Magnus, > I have tested the following: > * On my linux machine, failure to load libjsound.so was not fatal. In Platform.java: 54 loadLibraries(); 55 readProperties(); and readProperties calls native nIsBigEndian if libjsound loading fails I'd expect nIsBigEndian fails too. --alex On 03/21/2018 07:09, Magnus Ihse Bursie wrote: > On 2018-03-16 17:49, Alex Menkov wrote: >> >> >> On 03/15/2018 13:09, Magnus Ihse Bursie wrote: >>> >>>> 15 mars 2018 kl. 20:13 skrev Phil Race : >>>> >>>> >>>>> As far as I know the split was made to dynamically load >>>>> ALSA/DirectSound stuff >>>> >>>> Yes, I think it is something like that for Linux >>>> ie if at runtime a dependent-but-not-essential .so was not >>>> installed it was not fatal. I don't know to what extent this is no >>>> longer a >>>> possible issue, or one that matters. >>> >>> I have not heard of any mainstream Linux distro in years that was >>> lacking ALSA. >>> >>> If ALSA was not present, will the libraries fall back to OSS, or will >>> there be just no sound available? >> >> No sound. >> OSS support was dropped many years ago (IIRC in jdk7) >> >>> In any case, I think that whatever Linux distros we're targeting as >>> supported, ALSA will be present. >>> >>> Alex, did I understand you correctly that in any case, a separate >>> Windows library is always unnecessary, since we can rely on >>> DirectAudio always being present in our supported versions of Windows? >> >> Yes, that's right. >> Windows always has DirectSound pre-installed and its version is >> greater than required (IIRC javasoundds requires DirectX 5). >> >> For now failure of libjsound loading is fatal (see >> com.sun.media.sound.Platform.loadLibraries()), loading of extra libs >> is non-fatal. >> I believe libjsound loading failure should be made non-fatal, then all >> the functionality will remain the same as we have now. > > Ok. > > Here is an updated webrev. I have made the following changes: > * libjavasoundalsa and libjavasoundds is now folded into the main > libjavasound native library, so there's exactly one library built on all > platforms. > * Loading of libjsound is made non-fatal. > * I have cleaned out all obvious parts of the code that handle multiple > libraries. Since loading the native library is now a all-or-nothing > situation, the checks for various subsystems have been turned into a > generic check if the native library is loaded. > > There is a lot of defines like USE_DSOUND which are always true. This > could probably be cleaned up further, but it is not a build issue so I'm > leaving that to the client team to handle. > > I have tested the following: > ?* COMPARE_BUILD shows me just the expected changes in the build. > ?* On my linux machine, failure to load libjsound.so was not fatal. > ?* I have looked for sound tests. I found the test/jdk/javax/sound > suite, which was included in tier3. So I've run tier3 testing on all > platforms using our internal test system, and all tests pass. > > I don't know if there is any other tests I should run. If so, let me know. > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03 > > /Magnus > >> >> --alex >> >>> >>> /Magnus >>> >>>> >>>> -phil. >>>> >>>>> On 03/15/2018 12:06 PM, Alex Menkov wrote: >>>>> >>>>> >>>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote: >>>>>>> On 2018-03-15 18:23, Phil Race wrote: >>>>>>> I wondered if that might be the case since it was a "BSD" port .. >>>>>>> using X11 .. >>>>>>> >>>>>>> Maybe we should be getting rid of them ? >>>>>> I agree, we should delete them. I just shuffled them around in the >>>>>> hope that they would be useful for a potential future bsd port, >>>>>> but if/when that happens, we can dig them out from mercurial. >>>>>> >>>>>> A short explanation of how the files moved. The sound library is >>>>>> apparently composed of either a single library (solaris and >>>>>> macosx) or two libraries (linux and windows). Two building blocks, >>>>>> MIDI + ports and DirectAudio is used for all platforms, but they >>>>>> go into either the main library (libjsound) or the helper library. >>>>>> >>>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into >>>>>> libjsoundds. On Linux, MIDI+Ports and DirectAudio go into >>>>>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio >>>>>> go into the main libjsound. >>>>>> >>>>>> I have no idea why this split is necessary, but this is how the >>>>>> libraries de facto is compiled, and the code needs to match that. >>>>>> If it would be possible to move libjsoundds and libjsoundalsa into >>>>>> libjsound directly, things would be greatly simplified. >>>>> >>>>> As far as I know the split was made to dynamically load >>>>> ALSA/DirectSound stuff. If it's not available (or old unsupported >>>>> version is installed), libjsound stuff continues to work (in >>>>> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS >>>>> on Linux). >>>>> For now Windows (DirectSound) libjsoundds stuff can be merged into >>>>> libjsound, but I'm not sure we can rely on ALSA is always available >>>>> on Linux (but most likely if ALSA is not available, libjsound does >>>>> not provide any functionality, so I suppose libjsoundalsa stuff can >>>>> be moved to libjsound as well) >>>>> >>>>> --alex >>>>> >>>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote: >>>>>>>> Digging a bit, those files came with the initial Macosx support. >>>>>>>> It doesn't look like they were ever used. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>>> On 2018-03-15 09:53, Phil Race wrote: >>>>>>>>> It is very hard to follow all the moved around files, but one >>>>>>>>> thing >>>>>>>>> that sticks out is there is a "bsd" directory created and I can't >>>>>>>>> work out how the files in there are used. >>>>>>>>> If they are for a BSD port of OpenJDK where is rest of the >>>>>>>>> support for that ? >>>>>>>>> >>>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>>>>>>>>> Looks good to me. I tried cleaning this up before but failed >>>>>>>>>> to find a reasonable split, but this seems like a good split >>>>>>>>>> between common and library specific. >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>>>>>>>>> I forgot to add the client mailing lists as recipients. >>>>>>>>>>> Sorry. (Not sure if "sounds" belong to "awt" or "2d".) >>>>>>>>> >>>>>>>>> In fact, there is a sound-specific list, which I've added. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>>>>>>>>> ?From the bug description: >>>>>>>>>>>> >>>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In >>>>>>>>>>>> SoundLibraries.gmk, the source code splitting is not >>>>>>>>>>>> complete. The directory libjsound is used to build not only >>>>>>>>>>>> libjsound but libjsoundalsa and libjsoundds, and thus needs >>>>>>>>>>>> a complex include/exclude system like before. >>>>>>>>>>>> >>>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris >>>>>>>>>>>> are completely clean. On macosx, there's a binary diff (but >>>>>>>>>>>> nothing else) on libjsound.dylib. On linux, some offset >>>>>>>>>>>> seems to have changed, which caused a slight change in >>>>>>>>>>>> disass and fulldump for libjsound.so. I'm not quite sure >>>>>>>>>>>> what's causing it, but I'm convinced it's harmless. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>>>>>>>>> WebRev: >>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /Magnus >>>> >>> > From erik.joelsson at oracle.com Wed Mar 21 21:51:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 21 Mar 2018 14:51:50 -0700 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 Message-ID: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> Now that JDK 10 has been officially released we can update the boot jdk requirement for JDK 11. Cross posting this to jdk-dev to raise awareness of this rather disruptive change. This patch changes the requirement on boot jdk version in configure (and updates the configuration that controls what JDK to use as boot in Oracle's internal build system). Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 /Erik From erik.joelsson at oracle.com Wed Mar 21 22:05:48 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 21 Mar 2018 15:05:48 -0700 Subject: RFR: JDK-8198652: Stop linking with -base:0x8000000 on Windows Message-ID: <7adcdebe-5586-e1d4-8813-d4327de1db94@oracle.com> On Windows, we have been linking libjvm.so with -base:0x8000000 since forever. This may have been a good idea on earlier versions of windows, but with VS2017 it generates a warning and with ASLR, the address a given binary is loaded at will vary between runs anyway, so there is little point setting this linker option anymore (since Windows Vista). So I propose we just remove it. Bug: https://bugs.openjdk.java.net/browse/JDK-8198652 Webrev: http://cr.openjdk.java.net/~erikj/8198652/webrev.01/ /Erik From martinrb at google.com Wed Mar 21 22:07:45 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 Mar 2018 15:07:45 -0700 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> Message-ID: Now that we are releasing jdks an order of magnitude faster than before, we should reconsider the N-1 boot jdk policy. The primary beneficiaries of this are compiler-dev, who might like to code using the very features they are implementing. But for users, being able to bootstrap with an ancient jdk is definitely convenient. A good compromise might be to be able to bootstrap with the most recent LTS release (jdk 8) but it might already be too late for that. On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson wrote: > Now that JDK 10 has been officially released we can update the boot jdk > requirement for JDK 11. Cross posting this to jdk-dev to raise awareness of > this rather disruptive change. > > This patch changes the requirement on boot jdk version in configure (and > updates the configuration that controls what JDK to use as boot in Oracle's > internal build system). > > Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 > > /Erik > > From jonathan.gibbons at oracle.com Wed Mar 21 22:20:33 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 21 Mar 2018 15:20:33 -0700 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> Message-ID: <5AB2DAB1.503@oracle.com> Holding javac and related tools back to the latest LTS would indeed be somewhat onerous. -- Jon On 03/21/2018 03:07 PM, Martin Buchholz wrote: > Now that we are releasing jdks an order of magnitude faster than before, we > should reconsider the N-1 boot jdk policy. > > The primary beneficiaries of this are compiler-dev, who might like to code > using the very features they are implementing. > > But for users, being able to bootstrap with an ancient jdk is definitely > convenient. > > A good compromise might be to be able to bootstrap with the most recent LTS > release (jdk 8) but it might already be too late for that. > > On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson > wrote: > >> Now that JDK 10 has been officially released we can update the boot jdk >> requirement for JDK 11. Cross posting this to jdk-dev to raise awareness of >> this rather disruptive change. >> >> This patch changes the requirement on boot jdk version in configure (and >> updates the configuration that controls what JDK to use as boot in Oracle's >> internal build system). >> >> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 >> >> /Erik >> >> From glaubitz at physik.fu-berlin.de Wed Mar 21 22:41:29 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 22 Mar 2018 07:41:29 +0900 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> Message-ID: On 03/22/2018 07:07 AM, Martin Buchholz wrote: > But for users, being able to bootstrap with an ancient jdk is definitely > convenient. Convenient is an understatement. Always enforcing the N-1 version to be used can be quite painful for downstream distributions. Rust upstream does the same thing and it becomes very frustrating when bootstrapping the compiler. When, for example, an architecture has fallen back a couple of releases of OpenJDK, I would have to go through the whole chain of 8->9->10->11 to get the latest OpenJDK. I know that cross-compiling is possible, but it's not always the easiest option. So, from a downstream perspective, allowing the oldest possible version is always a desirable feature to have. I do understand it though when OpenJDK 11 requires features from OpenJDK 10 which would rule out older versions completely. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From tim.bell at oracle.com Wed Mar 21 23:36:36 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 21 Mar 2018 16:36:36 -0700 Subject: RFR: JDK-8198652: Stop linking with -base:0x8000000 on Windows In-Reply-To: <7adcdebe-5586-e1d4-8813-d4327de1db94@oracle.com> References: <7adcdebe-5586-e1d4-8813-d4327de1db94@oracle.com> Message-ID: <5AB2EC84.4030006@oracle.com> Erik: > On Windows, we have been linking libjvm.so with -base:0x8000000 since > forever. This may have been a good idea on earlier versions of windows, > but with VS2017 it generates a warning and with ASLR, the address a > given binary is loaded at will vary between runs anyway, so there is > little point setting this linker option anymore (since Windows Vista). > So I propose we just remove it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198652 > > Webrev: http://cr.openjdk.java.net/~erikj/8198652/webrev.01/ Looks good. /Tim From vladimir.kozlov at oracle.com Thu Mar 22 01:04:51 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Mar 2018 18:04:51 -0700 Subject: [11] RFR(XS) 8199896: [Graal] build Graal on all x86 platforms In-Reply-To: <53d0725a-ad8e-7d52-8fc5-b0c674fcbcd8@oracle.com> References: <53d0725a-ad8e-7d52-8fc5-b0c674fcbcd8@oracle.com> Message-ID: <18b854dc-d9a1-e1d0-7d80-2e9509cb0352@oracle.com> Forgot to CC to build-dev. Note, this change does not have effect unless you disable AOT build. We are already building Graal on all x64 platforms as part of AOT build currently. Vladimir On 3/20/18 6:15 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8199896 > > Extend Graal build to all x64 platforms. > > diff -r 7fa5375fa6fd make/autoconf/hotspot.m4 > --- a/make/autoconf/hotspot.m4 > +++ b/make/autoconf/hotspot.m4 > @@ -347,11 +347,10 @@ > ???? fi > ???? INCLUDE_GRAAL="true" > ?? else > -??? # By default enable graal build on linux-x64 or where AOT is available. > +??? # By default enable graal build on x64 or where AOT is available. > ???? # graal build requires jvmci. > ???? if test "x$JVM_FEATURES_jvmci" = "xjvmci" && \ > -??????? (test "x$OPENJDK_TARGET_CPU" = "xx86_64" && \ > -???????? test "x$OPENJDK_TARGET_OS" = "xlinux" || \ > +??????? (test "x$OPENJDK_TARGET_CPU" = "xx86_64" || \ > ???????? test "x$ENABLE_AOT" = "xtrue") ; then > ?????? AC_MSG_RESULT([yes]) > ?????? JVM_FEATURES_graal="graal" > > Thanks, > Vladimir From bhavesh.x.patel at oracle.com Thu Mar 22 04:36:59 2018 From: bhavesh.x.patel at oracle.com (Bhavesh Patel) Date: Wed, 21 Mar 2018 21:36:59 -0700 Subject: RFR: 8199705: Docs.gmk needs to be updated to remove the -html5 option Message-ID: <8a982c39-4818-8554-8dcb-ca2c8d05b1dd@oracle.com> Hi, ??? This is a simple fix to Docs.gmk. A fix for JDK-8182765 was pushed recently to javadoc enabling it to generate HTML 5 output by default. This makes the "-html5" option, defined in the initial set of javadoc options in Docs.gmk, redundant. I have removed the -html5? option. Please review this fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8199705 Webrev: http://cr.openjdk.java.net/~bpatel/8199705/webrev.00/ From thomas.stuefe at gmail.com Thu Mar 22 05:48:23 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Mar 2018 06:48:23 +0100 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> Message-ID: For what it is worth, I very much agree with Marting and Adrian. It would make matters easier for downstream consumers if we could at least retain N-2 compatibility, if compatibility to LTS is too much of a hassle for Oracle. Best Regards, Thomas On Wed, Mar 21, 2018 at 11:41 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > On 03/22/2018 07:07 AM, Martin Buchholz wrote: > > But for users, being able to bootstrap with an ancient jdk is definitely > > convenient. > > Convenient is an understatement. Always enforcing the N-1 version to be > used can be quite painful for downstream distributions. Rust upstream > does the same thing and it becomes very frustrating when bootstrapping > the compiler. > > When, for example, an architecture has fallen back a couple of releases > of OpenJDK, I would have to go through the whole chain of 8->9->10->11 > to get the latest OpenJDK. I know that cross-compiling is possible, but > it's not always the easiest option. > > So, from a downstream perspective, allowing the oldest possible version > is always a desirable feature to have. I do understand it though when > OpenJDK 11 requires features from OpenJDK 10 which would rule out older > versions completely. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From magnus.ihse.bursie at oracle.com Thu Mar 22 06:10:00 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 22 Mar 2018 07:10:00 +0100 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: <5AB2DAB1.503@oracle.com> References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <5AB2DAB1.503@oracle.com> Message-ID: Jon, > 21 mars 2018 kl. 23:20 skrev Jonathan Gibbons : > > Holding javac and related tools back to the latest LTS would indeed be somewhat onerous. Can we use the interim JDK build to get around this? Something like, if we can build a interim JDK with somewhat older tools, it can then be used to compile the javac proper? I can see that how with the increased release cadence, the assumptions behind the old N-1 scheme might not be valid anymore. /Magnus > > -- Jon > >> On 03/21/2018 03:07 PM, Martin Buchholz wrote: >> Now that we are releasing jdks an order of magnitude faster than before, we >> should reconsider the N-1 boot jdk policy. >> >> The primary beneficiaries of this are compiler-dev, who might like to code >> using the very features they are implementing. >> >> But for users, being able to bootstrap with an ancient jdk is definitely >> convenient. >> >> A good compromise might be to be able to bootstrap with the most recent LTS >> release (jdk 8) but it might already be too late for that. >> >> On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson >> wrote: >> >>> Now that JDK 10 has been officially released we can update the boot jdk >>> requirement for JDK 11. Cross posting this to jdk-dev to raise awareness of >>> this rather disruptive change. >>> >>> This patch changes the requirement on boot jdk version in configure (and >>> updates the configuration that controls what JDK to use as boot in Oracle's >>> internal build system). >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 >>> >>> /Erik >>> >>> > From aoqi at loongson.cn Thu Mar 22 06:24:35 2018 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 22 Mar 2018 14:24:35 +0800 Subject: [NEW BUG]: Configure broken on MIPS Message-ID: Hi, I found configure of http://hg.openjdk.java.net/jdk/jdk was broken on MIPS. the output of configure: ... configure: Using default toolchain gcc (GNU Compiler Collection) checking for gcc... /usr/bin/gcc checking resolved symbolic links for CC... /usr/bin/mips64el-linux-gnuabi64-gcc-6 configure: Using gcc C compiler version 6.3.0 [gcc (Debian 6.3.0-18) 6.3.0 20170516] checking whether the C compiler works... no configure: error: in `/home/loongson/aoqi/jdk': configure: error: C compiler cannot create executables See `config.log' for more details configure exiting with result code 77 ... the related content of config.log: ... configure:35256: checking whether the C compiler works configure:35278: /usr/bin/gcc -m64 -m64 conftest.c >&5 gcc: error: unrecognized command line option '-m64' gcc: error: unrecognized command line option '-m64' configure:35282: $? = 1 configure:35320: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk9" | #define PACKAGE_STRING "OpenJDK jdk9" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:35325: error: in `/home/loongson/aoqi/jdk': configure:35327: error: C compiler cannot create executables See `config.log' for more details ... I made a small patch to pass the configure: $ hg diff make/autoconf/flags.m4 diff -r 3acb379b8672 make/autoconf/flags.m4 --- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 2018 +0800 +++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 2018 +0800 @@ -237,7 +237,11 @@ MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then if test "x$OPENJDK_TARGET_CPU" != xaarch64 && - test "x$OPENJDK_TARGET_CPU" != xarm; then + test "x$OPENJDK_TARGET_CPU" != xarm && + test "x$OPENJDK_TARGET_CPU" != xmips && + test "x$OPENJDK_TARGET_CPU" != xmipsel && + test "x$OPENJDK_TARGET_CPU" != xmips64 && + test "x$OPENJDK_TARGET_CPU" != xmips64el; then MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" fi fi I think this is the same problem with bug 8199052 and 8199152. Could someone help to review the change? Thanks, Ao Qi From aoqi at loongson.cn Thu Mar 22 06:37:40 2018 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 22 Mar 2018 14:37:40 +0800 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> Message-ID: 2018-03-22 6:41 GMT+08:00 John Paul Adrian Glaubitz : > On 03/22/2018 07:07 AM, Martin Buchholz wrote: >> But for users, being able to bootstrap with an ancient jdk is definitely >> convenient. > > Convenient is an understatement. Always enforcing the N-1 version to be > used can be quite painful for downstream distributions. Rust upstream > does the same thing and it becomes very frustrating when bootstrapping > the compiler. > > When, for example, an architecture has fallen back a couple of releases > of OpenJDK, I would have to go through the whole chain of 8->9->10->11 > to get the latest OpenJDK. I know that cross-compiling is possible, but > it's not always the easiest option. > Indeed. I was trying to build OpenJDK 11 zero on MIPS. Because I only had OpenJDK 8 binary as boot JDK, I have to build OpenJDK 9 first. It is even more painful when I build OpenJDK 11 32 bits zero. Because I only have 32-bit OpenJDK 6 as boot JDK, I have to build 7, 8, 9 and then 11. > So, from a downstream perspective, allowing the oldest possible version > is always a desirable feature to have. I do understand it though when > OpenJDK 11 requires features from OpenJDK 10 which would rule out older > versions completely. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Thu Mar 22 07:09:31 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Mar 2018 08:09:31 +0100 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> Message-ID: On Thu, Mar 22, 2018 at 7:37 AM, Ao Qi wrote: > 2018-03-22 6:41 GMT+08:00 John Paul Adrian Glaubitz > : > > On 03/22/2018 07:07 AM, Martin Buchholz wrote: > >> But for users, being able to bootstrap with an ancient jdk is definitely > >> convenient. > > > > Convenient is an understatement. Always enforcing the N-1 version to be > > used can be quite painful for downstream distributions. Rust upstream > > does the same thing and it becomes very frustrating when bootstrapping > > the compiler. > > > > When, for example, an architecture has fallen back a couple of releases > > of OpenJDK, I would have to go through the whole chain of 8->9->10->11 > > to get the latest OpenJDK. I know that cross-compiling is possible, but > > it's not always the easiest option. > > > > Indeed. I was trying to build OpenJDK 11 zero on MIPS. Because I only had > OpenJDK 8 binary as boot JDK, I have to build OpenJDK 9 first. > It is even more painful when I build OpenJDK 11 32 bits zero. Because I > only > have 32-bit OpenJDK 6 as boot JDK, I have to build 7, 8, 9 and then 11. > > And the build is not blindingly fast with a zero VM as boot jdk :) > > So, from a downstream perspective, allowing the oldest possible version > > is always a desirable feature to have. I do understand it though when > > OpenJDK 11 requires features from OpenJDK 10 which would rule out older > > versions completely. > > > > Adrian > > > > -- > > .''`. John Paul Adrian Glaubitz > > : :' : Debian Developer - glaubitz at debian.org > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From magnus.ihse.bursie at oracle.com Thu Mar 22 07:41:27 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 22 Mar 2018 08:41:27 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: <5860c201-7084-9903-8f9d-73ba7a28ca68@oracle.com> References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com> <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com> <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com> <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com> <5860c201-7084-9903-8f9d-73ba7a28ca68@oracle.com> Message-ID: On 2018-03-21 19:08, Alex Menkov wrote: > Hi Magnus, > > > I have tested the following: > >?? * On my linux machine, failure to load libjsound.so was not fatal. > > In Platform.java: > ? 54???????? loadLibraries(); > ? 55???????? readProperties(); > > and readProperties calls native nIsBigEndian > > if libjsound loading fails I'd expect nIsBigEndian fails too. You are absolutely correct. I managed to publish a half-ass fix of Platform.java. :-( Here is the correct version: http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.04 /Magnus > > --alex > > On 03/21/2018 07:09, Magnus Ihse Bursie wrote: >> On 2018-03-16 17:49, Alex Menkov wrote: >>> >>> >>> On 03/15/2018 13:09, Magnus Ihse Bursie wrote: >>>> >>>>> 15 mars 2018 kl. 20:13 skrev Phil Race : >>>>> >>>>> >>>>>> As far as I know the split was made to dynamically load >>>>>> ALSA/DirectSound stuff >>>>> >>>>> Yes, I think it is something like that for Linux >>>>> ie if at runtime a dependent-but-not-essential .so was not >>>>> installed it was not fatal. I don't know to what extent this is no >>>>> longer a >>>>> possible issue, or one that matters. >>>> >>>> I have not heard of any mainstream Linux distro in years that was >>>> lacking ALSA. >>>> >>>> If ALSA was not present, will the libraries fall back to OSS, or >>>> will there be just no sound available? >>> >>> No sound. >>> OSS support was dropped many years ago (IIRC in jdk7) >>> >>>> In any case, I think that whatever Linux distros we're targeting as >>>> supported, ALSA will be present. >>>> >>>> Alex, did I understand you correctly that in any case, a separate >>>> Windows library is always unnecessary, since we can rely on >>>> DirectAudio always being present in our supported versions of Windows? >>> >>> Yes, that's right. >>> Windows always has DirectSound pre-installed and its version is >>> greater than required (IIRC javasoundds requires DirectX 5). >>> >>> For now failure of libjsound loading is fatal (see >>> com.sun.media.sound.Platform.loadLibraries()), loading of extra libs >>> is non-fatal. >>> I believe libjsound loading failure should be made non-fatal, then >>> all the functionality will remain the same as we have now. >> >> Ok. >> >> Here is an updated webrev. I have made the following changes: >> * libjavasoundalsa and libjavasoundds is now folded into the main >> libjavasound native library, so there's exactly one library built on >> all platforms. >> * Loading of libjsound is made non-fatal. >> * I have cleaned out all obvious parts of the code that handle >> multiple libraries. Since loading the native library is now a >> all-or-nothing situation, the checks for various subsystems have been >> turned into a generic check if the native library is loaded. >> >> There is a lot of defines like USE_DSOUND which are always true. This >> could probably be cleaned up further, but it is not a build issue so >> I'm leaving that to the client team to handle. >> >> I have tested the following: >> ??* COMPARE_BUILD shows me just the expected changes in the build. >> ??* On my linux machine, failure to load libjsound.so was not fatal. >> ??* I have looked for sound tests. I found the test/jdk/javax/sound >> suite, which was included in tier3. So I've run tier3 testing on all >> platforms using our internal test system, and all tests pass. >> >> I don't know if there is any other tests I should run. If so, let me >> know. >> >> Updated webrev: >> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03 >> >> /Magnus >> >>> >>> --alex >>> >>>> >>>> /Magnus >>>> >>>>> >>>>> -phil. >>>>> >>>>>> On 03/15/2018 12:06 PM, Alex Menkov wrote: >>>>>> >>>>>> >>>>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote: >>>>>>>> On 2018-03-15 18:23, Phil Race wrote: >>>>>>>> I wondered if that might be the case since it was a "BSD" port >>>>>>>> .. using X11 .. >>>>>>>> >>>>>>>> Maybe we should be getting rid of them ? >>>>>>> I agree, we should delete them. I just shuffled them around in >>>>>>> the hope that they would be useful for a potential future bsd >>>>>>> port, but if/when that happens, we can dig them out from mercurial. >>>>>>> >>>>>>> A short explanation of how the files moved. The sound library is >>>>>>> apparently composed of either a single library (solaris and >>>>>>> macosx) or two libraries (linux and windows). Two building >>>>>>> blocks, MIDI + ports and DirectAudio is used for all platforms, >>>>>>> but they go into either the main library (libjsound) or the >>>>>>> helper library. >>>>>>> >>>>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go >>>>>>> into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into >>>>>>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio >>>>>>> go into the main libjsound. >>>>>>> >>>>>>> I have no idea why this split is necessary, but this is how the >>>>>>> libraries de facto is compiled, and the code needs to match >>>>>>> that. If it would be possible to move libjsoundds and >>>>>>> libjsoundalsa into libjsound directly, things would be greatly >>>>>>> simplified. >>>>>> >>>>>> As far as I know the split was made to dynamically load >>>>>> ALSA/DirectSound stuff. If it's not available (or old unsupported >>>>>> version is installed), libjsound stuff continues to work (in >>>>>> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS >>>>>> on Linux). >>>>>> For now Windows (DirectSound) libjsoundds stuff can be merged >>>>>> into libjsound, but I'm not sure we can rely on ALSA is always >>>>>> available on Linux (but most likely if ALSA is not available, >>>>>> libjsound does not provide any functionality, so I suppose >>>>>> libjsoundalsa stuff can be moved to libjsound as well) >>>>>> >>>>>> --alex >>>>>> >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote: >>>>>>>>> Digging a bit, those files came with the initial Macosx >>>>>>>>> support. It doesn't look like they were ever used. >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-03-15 09:53, Phil Race wrote: >>>>>>>>>> It is very hard to follow all the moved around files, but one >>>>>>>>>> thing >>>>>>>>>> that sticks out is there is a "bsd" directory created and I >>>>>>>>>> can't >>>>>>>>>> work out how the files in there are used. >>>>>>>>>> If they are for a BSD port of OpenJDK where is rest of the >>>>>>>>>> support for that ? >>>>>>>>>> >>>>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>>>>>>>>>> Looks good to me. I tried cleaning this up before but failed >>>>>>>>>>> to find a reasonable split, but this seems like a good split >>>>>>>>>>> between common and library specific. >>>>>>>>>>> >>>>>>>>>>> /Erik >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>>>>>>>>>> I forgot to add the client mailing lists as recipients. >>>>>>>>>>>> Sorry. (Not sure if "sounds" belong to "awt" or "2d".) >>>>>>>>>> >>>>>>>>>> In fact, there is a sound-specific list, which I've added. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> /Magnus >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> ?From the bug description: >>>>>>>>>>>>> >>>>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In >>>>>>>>>>>>> SoundLibraries.gmk, the source code splitting is not >>>>>>>>>>>>> complete. The directory libjsound is used to build not >>>>>>>>>>>>> only libjsound but libjsoundalsa and libjsoundds, and thus >>>>>>>>>>>>> needs a complex include/exclude system like before. >>>>>>>>>>>>> >>>>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and >>>>>>>>>>>>> solaris are completely clean. On macosx, there's a binary >>>>>>>>>>>>> diff (but nothing else) on libjsound.dylib. On linux, some >>>>>>>>>>>>> offset seems to have changed, which caused a slight change >>>>>>>>>>>>> in disass and fulldump for libjsound.so. I'm not quite >>>>>>>>>>>>> sure what's causing it, but I'm convinced it's harmless. >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>>>>>>>>>> WebRev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> /Magnus >>>>> >>>> >> From thomas.stuefe at gmail.com Thu Mar 22 07:53:52 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Mar 2018 08:53:52 +0100 Subject: RFR: JDK-8198652: Stop linking with -base:0x8000000 on Windows In-Reply-To: <7adcdebe-5586-e1d4-8813-d4327de1db94@oracle.com> References: <7adcdebe-5586-e1d4-8813-d4327de1db94@oracle.com> Message-ID: Hi Erik, makes sense and looks fine. ..Thomas On Wed, Mar 21, 2018 at 11:05 PM, Erik Joelsson wrote: > On Windows, we have been linking libjvm.so with -base:0x8000000 since > forever. This may have been a good idea on earlier versions of windows, but > with VS2017 it generates a warning and with ASLR, the address a given > binary is loaded at will vary between runs anyway, so there is little point > setting this linker option anymore (since Windows Vista). So I propose we > just remove it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198652 > > Webrev: http://cr.openjdk.java.net/~erikj/8198652/webrev.01/ > > /Erik > > From magnus.ihse.bursie at oracle.com Thu Mar 22 10:06:41 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 22 Mar 2018 11:06:41 +0100 Subject: RFR: JDK-8198652: Stop linking with -base:0x8000000 on Windows In-Reply-To: <7adcdebe-5586-e1d4-8813-d4327de1db94@oracle.com> References: <7adcdebe-5586-e1d4-8813-d4327de1db94@oracle.com> Message-ID: <6606336e-7cef-6ab0-ffe1-60973b5a8108@oracle.com> On 2018-03-21 23:05, Erik Joelsson wrote: > On Windows, we have been linking libjvm.so with -base:0x8000000 since > forever. This may have been a good idea on earlier versions of > windows, but with VS2017 it generates a warning and with ASLR, the > address a given binary is loaded at will vary between runs anyway, so > there is little point setting this linker option anymore (since > Windows Vista). So I propose we just remove it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198652 > > Webrev: http://cr.openjdk.java.net/~erikj/8198652/webrev.01/ Looks good to me. Thanks for fixing this! /Magnus > > /Erik > From erik.joelsson at oracle.com Thu Mar 22 14:07:38 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Mar 2018 07:07:38 -0700 Subject: [11] RFR(XS) 8199896: [Graal] build Graal on all x86 platforms In-Reply-To: <18b854dc-d9a1-e1d0-7d80-2e9509cb0352@oracle.com> References: <53d0725a-ad8e-7d52-8fc5-b0c674fcbcd8@oracle.com> <18b854dc-d9a1-e1d0-7d80-2e9509cb0352@oracle.com> Message-ID: <20a5339f-f765-008d-841a-734d32f51f72@oracle.com> Looks good. /Erik On 2018-03-21 18:04, Vladimir Kozlov wrote: > Forgot to CC to build-dev. > > Note, this change does not have effect unless you disable AOT build. > We are already building Graal on all x64 platforms as part of AOT > build currently. > > Vladimir > > On 3/20/18 6:15 PM, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8199896 >> >> Extend Graal build to all x64 platforms. >> >> diff -r 7fa5375fa6fd make/autoconf/hotspot.m4 >> --- a/make/autoconf/hotspot.m4 >> +++ b/make/autoconf/hotspot.m4 >> @@ -347,11 +347,10 @@ >> ????? fi >> ????? INCLUDE_GRAAL="true" >> ??? else >> -??? # By default enable graal build on linux-x64 or where AOT is >> available. >> +??? # By default enable graal build on x64 or where AOT is available. >> ????? # graal build requires jvmci. >> ????? if test "x$JVM_FEATURES_jvmci" = "xjvmci" && \ >> -??????? (test "x$OPENJDK_TARGET_CPU" = "xx86_64" && \ >> -???????? test "x$OPENJDK_TARGET_OS" = "xlinux" || \ >> +??????? (test "x$OPENJDK_TARGET_CPU" = "xx86_64" || \ >> ????????? test "x$ENABLE_AOT" = "xtrue") ; then >> ??????? AC_MSG_RESULT([yes]) >> ??????? JVM_FEATURES_graal="graal" >> >> Thanks, >> Vladimir From erik.joelsson at oracle.com Thu Mar 22 14:08:19 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Mar 2018 07:08:19 -0700 Subject: RFR: 8199705: Docs.gmk needs to be updated to remove the -html5 option In-Reply-To: <8a982c39-4818-8554-8dcb-ca2c8d05b1dd@oracle.com> References: <8a982c39-4818-8554-8dcb-ca2c8d05b1dd@oracle.com> Message-ID: Looks good. /Erik On 2018-03-21 21:36, Bhavesh Patel wrote: > Hi, > > ??? This is a simple fix to Docs.gmk. A fix for JDK-8182765 > was pushed recently > to javadoc enabling it to generate HTML 5 output by default. This > makes the "-html5" option, defined in the initial set of javadoc > options in Docs.gmk, redundant. I have removed the -html5? option. > Please review this fix. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199705 > > Webrev: http://cr.openjdk.java.net/~bpatel/8199705/webrev.00/ > > From erik.joelsson at oracle.com Thu Mar 22 14:13:14 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Mar 2018 07:13:14 -0700 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: References: Message-ID: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> Hello, The fix looks correct, but I'm starting to think that maybe the conditional should be inverted and instead list the architectures that actually use -m64? It seems a whole lot of them don't. /Erik On 2018-03-21 23:24, Ao Qi wrote: > Hi, > > I found configure of http://hg.openjdk.java.net/jdk/jdk was broken on MIPS. > > the output of configure: > ... > configure: Using default toolchain gcc (GNU Compiler Collection) > checking for gcc... /usr/bin/gcc > checking resolved symbolic links for CC... > /usr/bin/mips64el-linux-gnuabi64-gcc-6 > configure: Using gcc C compiler version 6.3.0 [gcc (Debian 6.3.0-18) > 6.3.0 20170516] > checking whether the C compiler works... no > configure: error: in `/home/loongson/aoqi/jdk': > configure: error: C compiler cannot create executables > See `config.log' for more details > configure exiting with result code 77 > ... > > the related content of config.log: > ... > configure:35256: checking whether the C compiler works > configure:35278: /usr/bin/gcc -m64 -m64 conftest.c >&5 > gcc: error: unrecognized command line option '-m64' > gcc: error: unrecognized command line option '-m64' > configure:35282: $? = 1 > configure:35320: result: no > configure: failed program was: > | /* confdefs.h */ > | #define PACKAGE_NAME "OpenJDK" > | #define PACKAGE_TARNAME "openjdk" > | #define PACKAGE_VERSION "jdk9" > | #define PACKAGE_STRING "OpenJDK jdk9" > | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" > | #define PACKAGE_URL "http://openjdk.java.net" > | /* end confdefs.h. */ > | > | int > | main () > | { > | > | ; > | return 0; > | } > configure:35325: error: in `/home/loongson/aoqi/jdk': > configure:35327: error: C compiler cannot create executables > See `config.log' for more details > ... > > > I made a small patch to pass the configure: > > $ hg diff make/autoconf/flags.m4 > diff -r 3acb379b8672 make/autoconf/flags.m4 > --- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 2018 +0800 > +++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 2018 +0800 > @@ -237,7 +237,11 @@ > MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" > elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then > if test "x$OPENJDK_TARGET_CPU" != xaarch64 && > - test "x$OPENJDK_TARGET_CPU" != xarm; then > + test "x$OPENJDK_TARGET_CPU" != xarm && > + test "x$OPENJDK_TARGET_CPU" != xmips && > + test "x$OPENJDK_TARGET_CPU" != xmipsel && > + test "x$OPENJDK_TARGET_CPU" != xmips64 && > + test "x$OPENJDK_TARGET_CPU" != xmips64el; then > MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" > fi > fi > > > I think this is the same problem with bug 8199052 and 8199152. Could > someone help to review the change? > > Thanks, > Ao Qi From erik.joelsson at oracle.com Thu Mar 22 14:18:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Mar 2018 07:18:32 -0700 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <5AB2DAB1.503@oracle.com> Message-ID: On 2018-03-21 23:10, Magnus Ihse Bursie wrote: > Jon, > >> 21 mars 2018 kl. 23:20 skrev Jonathan Gibbons : >> >> Holding javac and related tools back to the latest LTS would indeed be somewhat onerous. > Can we use the interim JDK build to get around this? Something like, if we can build a interim JDK with somewhat older tools, it can then be used to compile the javac proper? No, I can't see how that could work for simplifying anything here. /Erik > I can see that how with the increased release cadence, the assumptions behind the old N-1 scheme might not be valid anymore. > > /Magnus > >> -- Jon >> >>> On 03/21/2018 03:07 PM, Martin Buchholz wrote: >>> Now that we are releasing jdks an order of magnitude faster than before, we >>> should reconsider the N-1 boot jdk policy. >>> >>> The primary beneficiaries of this are compiler-dev, who might like to code >>> using the very features they are implementing. >>> >>> But for users, being able to bootstrap with an ancient jdk is definitely >>> convenient. >>> >>> A good compromise might be to be able to bootstrap with the most recent LTS >>> release (jdk 8) but it might already be too late for that. >>> >>> On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson >>> wrote: >>> >>>> Now that JDK 10 has been officially released we can update the boot jdk >>>> requirement for JDK 11. Cross posting this to jdk-dev to raise awareness of >>>> this rather disruptive change. >>>> >>>> This patch changes the requirement on boot jdk version in configure (and >>>> updates the configuration that controls what JDK to use as boot in Oracle's >>>> internal build system). >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 >>>> >>>> /Erik >>>> >>>> From erik.joelsson at oracle.com Thu Mar 22 14:54:10 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Mar 2018 07:54:10 -0700 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> Message-ID: Hello, On 2018-03-21 15:07, Martin Buchholz wrote: > Now that we are releasing jdks an order of magnitude faster than > before, we should reconsider the N-1 boot jdk policy. > > The primary beneficiaries of this are compiler-dev, who might like to > code using the very features they are implementing. > Not just, we have had numerous tedious workarounds in the build for supporting different bootjdk versions (for just N and N-1) already and by adding more versions to that list, that kind of logic will balloon greatly. Maintaining a build that supports many different environments is hard, so being able to limit any variable helps. In practice there will still be the one version of boot jdk used by the automated build farms at Oracle and other places, which means any other boot jdk version is bound to break at times (as we already see for bootjdk version N often enough). It adds a complexity to the test matrix of the build that I think few OpenJDK developers are interested in keeping up with (as in, your change worked fine in your environment, but broke when building with bootjdk N-2.). > But for users, being able to bootstrap with an ancient jdk is > definitely convenient. > There are different classes of users here. OpenJDK developers who have to build OpenJDK all day long every day. OpenJDK binary distributors who set up automated build environments for producing binaries at regular intervals. OpenJDK users who download the source to build it once for their own system. These are the ones I can think of right now. For the developer, downloading the latest released version of the product they are developing every 6 months can hardly be such a big hassle. Most I know create their own convenience scripts to wrap the build with the configure parameters they commonly use so can easily automate setting up builds for building various versions of JDK N. For the binary distributor, again downloading the latest released version, or using the latest version you built yourself for the previous release can't be that hard. They are (hopefully) setting up automation and this is just part of it. Left are the users, who just wants to download and build from source to use it. I agree that we should strive for making OpenJDK as easy as possible to build for such users. However, getting any recent version of OpenJDK is pretty easy. Since JDK 9 you can even get OpenJDK binaries directly from jdk.java.net for the common main platforms. Other people on this thread complained about building on more esoteric platforms where they only had older JDKs available and general downloads aren't available. Yes, having to build each JDK in succession would then take time, but surely this is a one time cost if you just keep the binaries around for released versions of the JDK. Also, we try to maintain reasonable cross compiling support in the build system. I recommend leveraging that. > A good compromise might be to be able to bootstrap with the most > recent LTS release (jdk 8) but it might already be too late for that. > Reintroducing support for bootjdk 8 when building JDK 11 will not happen. We removed all the ugly workarounds needed for using a pre 9 bootjdk for 10 long ago. Long term though, perhaps this idea would be reasonable given the limited life time of non LTS. The required bootjdk would essentially be EOL long long before the LTS JDK N is. On the other hand, that would still be true for any bootjdk N-1 compared to JDK N. So given that, I'm still against. /Erik > On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson > > wrote: > > Now that JDK 10 has been officially released we can update the > boot jdk requirement for JDK 11. Cross posting this to jdk-dev to > raise awareness of this rather disruptive change. > > This patch changes the requirement on boot jdk version in > configure (and updates the configuration that controls what JDK to > use as boot in Oracle's internal build system). > > Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 > > > /Erik > > From jonathan.gibbons at oracle.com Thu Mar 22 15:13:23 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 22 Mar 2018 08:13:23 -0700 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <5AB2DAB1.503@oracle.com> Message-ID: Magnus, There has always been a desire that most of JDK is free to use the latest language and API features, meaning we must use the latest javac to compile most most of JDK.?? That is where the "interim javac" comes in. The interim JDK relies on javac and related tools being compilable by the boot JDK.? This imposes a restriction that the source code of those tools must be conformant to the source version supported by the boot JDK, meaning no use of any newer features. The javac team have always lived with and accepted the N-1 restriction that this imposes. With a more rapid cadence, it might be appropriate to revisit the N-1 rule. But since a "last LTS" rule may imply N-5 or N-6 or so, that seems like too much. I note that this is not just an issue for javac source code.? If we were currently on a "last LTS" rule, that implies JDK 8, which means the build would still have to be bimodal and support both (boot)classpath and modular builds. OK, that window is closing, but the general point is that supporting older versions may affect more than just the javac team. -- Jon On 3/21/18 11:10 PM, Magnus Ihse Bursie wrote: > Jon, > >> 21 mars 2018 kl. 23:20 skrev Jonathan Gibbons : >> >> Holding javac and related tools back to the latest LTS would indeed be somewhat onerous. > Can we use the interim JDK build to get around this? Something like, if we can build a interim JDK with somewhat older tools, it can then be used to compile the javac proper? > > I can see that how with the increased release cadence, the assumptions behind the old N-1 scheme might not be valid anymore. > > /Magnus > >> -- Jon >> >>> On 03/21/2018 03:07 PM, Martin Buchholz wrote: >>> Now that we are releasing jdks an order of magnitude faster than before, we >>> should reconsider the N-1 boot jdk policy. >>> >>> The primary beneficiaries of this are compiler-dev, who might like to code >>> using the very features they are implementing. >>> >>> But for users, being able to bootstrap with an ancient jdk is definitely >>> convenient. >>> >>> A good compromise might be to be able to bootstrap with the most recent LTS >>> release (jdk 8) but it might already be too late for that. >>> >>> On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson >>> wrote: >>> >>>> Now that JDK 10 has been officially released we can update the boot jdk >>>> requirement for JDK 11. Cross posting this to jdk-dev to raise awareness of >>>> this rather disruptive change. >>>> >>>> This patch changes the requirement on boot jdk version in configure (and >>>> updates the configuration that controls what JDK to use as boot in Oracle's >>>> internal build system). >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 >>>> >>>> /Erik >>>> >>>> From vladimir.kozlov at oracle.com Thu Mar 22 17:37:49 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 22 Mar 2018 10:37:49 -0700 Subject: [11] RFR(XS) 8199896: [Graal] build Graal on all x86 platforms In-Reply-To: <20a5339f-f765-008d-841a-734d32f51f72@oracle.com> References: <53d0725a-ad8e-7d52-8fc5-b0c674fcbcd8@oracle.com> <18b854dc-d9a1-e1d0-7d80-2e9509cb0352@oracle.com> <20a5339f-f765-008d-841a-734d32f51f72@oracle.com> Message-ID: <42e48e0e-42cf-f728-7278-8339ee620d0c@oracle.com> Thank you, Erik Vladimir On 3/22/18 7:07 AM, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2018-03-21 18:04, Vladimir Kozlov wrote: >> Forgot to CC to build-dev. >> >> Note, this change does not have effect unless you disable AOT build. We are already building Graal >> on all x64 platforms as part of AOT build currently. >> >> Vladimir >> >> On 3/20/18 6:15 PM, Vladimir Kozlov wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8199896 >>> >>> Extend Graal build to all x64 platforms. >>> >>> diff -r 7fa5375fa6fd make/autoconf/hotspot.m4 >>> --- a/make/autoconf/hotspot.m4 >>> +++ b/make/autoconf/hotspot.m4 >>> @@ -347,11 +347,10 @@ >>> ????? fi >>> ????? INCLUDE_GRAAL="true" >>> ??? else >>> -??? # By default enable graal build on linux-x64 or where AOT is available. >>> +??? # By default enable graal build on x64 or where AOT is available. >>> ????? # graal build requires jvmci. >>> ????? if test "x$JVM_FEATURES_jvmci" = "xjvmci" && \ >>> -??????? (test "x$OPENJDK_TARGET_CPU" = "xx86_64" && \ >>> -???????? test "x$OPENJDK_TARGET_OS" = "xlinux" || \ >>> +??????? (test "x$OPENJDK_TARGET_CPU" = "xx86_64" || \ >>> ????????? test "x$ENABLE_AOT" = "xtrue") ; then >>> ??????? AC_MSG_RESULT([yes]) >>> ??????? JVM_FEATURES_graal="graal" >>> >>> Thanks, >>> Vladimir > From alexey.menkov at oracle.com Thu Mar 22 18:50:57 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 22 Mar 2018 11:50:57 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure In-Reply-To: References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com> <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com> <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com> <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com> <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com> <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com> <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com> <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com> <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com> <5860c201-7084-9903-8f9d-73ba7a28ca68@oracle.com> Message-ID: <0f62757f-4976-3edd-9e13-f9197afd96f6@oracle.com> Hi Magnus, the fix looks good to me. --alex On 03/22/2018 00:41, Magnus Ihse Bursie wrote: > On 2018-03-21 19:08, Alex Menkov wrote: >> Hi Magnus, >> >> > I have tested the following: >> >?? * On my linux machine, failure to load libjsound.so was not fatal. >> >> In Platform.java: >> ? 54???????? loadLibraries(); >> ? 55???????? readProperties(); >> >> and readProperties calls native nIsBigEndian >> >> if libjsound loading fails I'd expect nIsBigEndian fails too. > > You are absolutely correct. I managed to publish a half-ass fix of > Platform.java. :-( > > Here is the correct version: > http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.04 > > /Magnus > > >> >> --alex >> >> On 03/21/2018 07:09, Magnus Ihse Bursie wrote: >>> On 2018-03-16 17:49, Alex Menkov wrote: >>>> >>>> >>>> On 03/15/2018 13:09, Magnus Ihse Bursie wrote: >>>>> >>>>>> 15 mars 2018 kl. 20:13 skrev Phil Race : >>>>>> >>>>>> >>>>>>> As far as I know the split was made to dynamically load >>>>>>> ALSA/DirectSound stuff >>>>>> >>>>>> Yes, I think it is something like that for Linux >>>>>> ie if at runtime a dependent-but-not-essential .so was not >>>>>> installed it was not fatal. I don't know to what extent this is no >>>>>> longer a >>>>>> possible issue, or one that matters. >>>>> >>>>> I have not heard of any mainstream Linux distro in years that was >>>>> lacking ALSA. >>>>> >>>>> If ALSA was not present, will the libraries fall back to OSS, or >>>>> will there be just no sound available? >>>> >>>> No sound. >>>> OSS support was dropped many years ago (IIRC in jdk7) >>>> >>>>> In any case, I think that whatever Linux distros we're targeting as >>>>> supported, ALSA will be present. >>>>> >>>>> Alex, did I understand you correctly that in any case, a separate >>>>> Windows library is always unnecessary, since we can rely on >>>>> DirectAudio always being present in our supported versions of Windows? >>>> >>>> Yes, that's right. >>>> Windows always has DirectSound pre-installed and its version is >>>> greater than required (IIRC javasoundds requires DirectX 5). >>>> >>>> For now failure of libjsound loading is fatal (see >>>> com.sun.media.sound.Platform.loadLibraries()), loading of extra libs >>>> is non-fatal. >>>> I believe libjsound loading failure should be made non-fatal, then >>>> all the functionality will remain the same as we have now. >>> >>> Ok. >>> >>> Here is an updated webrev. I have made the following changes: >>> * libjavasoundalsa and libjavasoundds is now folded into the main >>> libjavasound native library, so there's exactly one library built on >>> all platforms. >>> * Loading of libjsound is made non-fatal. >>> * I have cleaned out all obvious parts of the code that handle >>> multiple libraries. Since loading the native library is now a >>> all-or-nothing situation, the checks for various subsystems have been >>> turned into a generic check if the native library is loaded. >>> >>> There is a lot of defines like USE_DSOUND which are always true. This >>> could probably be cleaned up further, but it is not a build issue so >>> I'm leaving that to the client team to handle. >>> >>> I have tested the following: >>> ??* COMPARE_BUILD shows me just the expected changes in the build. >>> ??* On my linux machine, failure to load libjsound.so was not fatal. >>> ??* I have looked for sound tests. I found the test/jdk/javax/sound >>> suite, which was included in tier3. So I've run tier3 testing on all >>> platforms using our internal test system, and all tests pass. >>> >>> I don't know if there is any other tests I should run. If so, let me >>> know. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03 >>> >>> >>> /Magnus >>> >>>> >>>> --alex >>>> >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> -phil. >>>>>> >>>>>>> On 03/15/2018 12:06 PM, Alex Menkov wrote: >>>>>>> >>>>>>> >>>>>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote: >>>>>>>>> On 2018-03-15 18:23, Phil Race wrote: >>>>>>>>> I wondered if that might be the case since it was a "BSD" port >>>>>>>>> .. using X11 .. >>>>>>>>> >>>>>>>>> Maybe we should be getting rid of them ? >>>>>>>> I agree, we should delete them. I just shuffled them around in >>>>>>>> the hope that they would be useful for a potential future bsd >>>>>>>> port, but if/when that happens, we can dig them out from mercurial. >>>>>>>> >>>>>>>> A short explanation of how the files moved. The sound library is >>>>>>>> apparently composed of either a single library (solaris and >>>>>>>> macosx) or two libraries (linux and windows). Two building >>>>>>>> blocks, MIDI + ports and DirectAudio is used for all platforms, >>>>>>>> but they go into either the main library (libjsound) or the >>>>>>>> helper library. >>>>>>>> >>>>>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go >>>>>>>> into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into >>>>>>>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio >>>>>>>> go into the main libjsound. >>>>>>>> >>>>>>>> I have no idea why this split is necessary, but this is how the >>>>>>>> libraries de facto is compiled, and the code needs to match >>>>>>>> that. If it would be possible to move libjsoundds and >>>>>>>> libjsoundalsa into libjsound directly, things would be greatly >>>>>>>> simplified. >>>>>>> >>>>>>> As far as I know the split was made to dynamically load >>>>>>> ALSA/DirectSound stuff. If it's not available (or old unsupported >>>>>>> version is installed), libjsound stuff continues to work (in >>>>>>> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS >>>>>>> on Linux). >>>>>>> For now Windows (DirectSound) libjsoundds stuff can be merged >>>>>>> into libjsound, but I'm not sure we can rely on ALSA is always >>>>>>> available on Linux (but most likely if ALSA is not available, >>>>>>> libjsound does not provide any functionality, so I suppose >>>>>>> libjsoundalsa stuff can be moved to libjsound as well) >>>>>>> >>>>>>> --alex >>>>>>> >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote: >>>>>>>>>> Digging a bit, those files came with the initial Macosx >>>>>>>>>> support. It doesn't look like they were ever used. >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-03-15 09:53, Phil Race wrote: >>>>>>>>>>> It is very hard to follow all the moved around files, but one >>>>>>>>>>> thing >>>>>>>>>>> that sticks out is there is a "bsd" directory created and I >>>>>>>>>>> can't >>>>>>>>>>> work out how the files in there are used. >>>>>>>>>>> If they are for a BSD port of OpenJDK where is rest of the >>>>>>>>>>> support for that ? >>>>>>>>>>> >>>>>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote: >>>>>>>>>>>> Looks good to me. I tried cleaning this up before but failed >>>>>>>>>>>> to find a reasonable split, but this seems like a good split >>>>>>>>>>>> between common and library specific. >>>>>>>>>>>> >>>>>>>>>>>> /Erik >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> I forgot to add the client mailing lists as recipients. >>>>>>>>>>>>> Sorry. (Not sure if "sounds" belong to "awt" or "2d".) >>>>>>>>>>> >>>>>>>>>>> In fact, there is a sound-specific list, which I've added. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>>>> >>>>>>>>>>>>> /Magnus >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>> ?From the bug description: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In >>>>>>>>>>>>>> SoundLibraries.gmk, the source code splitting is not >>>>>>>>>>>>>> complete. The directory libjsound is used to build not >>>>>>>>>>>>>> only libjsound but libjsoundalsa and libjsoundds, and thus >>>>>>>>>>>>>> needs a complex include/exclude system like before. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and >>>>>>>>>>>>>> solaris are completely clean. On macosx, there's a binary >>>>>>>>>>>>>> diff (but nothing else) on libjsound.dylib. On linux, some >>>>>>>>>>>>>> offset seems to have changed, which caused a slight change >>>>>>>>>>>>>> in disass and fulldump for libjsound.so. I'm not quite >>>>>>>>>>>>>> sure what's causing it, but I'm convinced it's harmless. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469 >>>>>>>>>>>>>> WebRev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Magnus >>>>>> >>>>> >>> > From david.holmes at oracle.com Thu Mar 22 21:04:35 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Mar 2018 07:04:35 +1000 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> Message-ID: <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> On 23/03/2018 12:13 AM, Erik Joelsson wrote: > Hello, > > The fix looks correct, but I'm starting to think that maybe the > conditional should be inverted and instead list the architectures that > actually use -m64? It seems a whole lot of them don't. Magnus indicated he was working on a better solution when he put in the quick-fix check for Aarch64. Yes this should only add -m64 on compilers and platforms that support it. David ----- > /Erik > > > On 2018-03-21 23:24, Ao Qi wrote: >> Hi, >> >> I found configure of http://hg.openjdk.java.net/jdk/jdk was broken on >> MIPS. >> >> the output of configure: >> ... >> configure: Using default toolchain gcc (GNU Compiler Collection) >> checking for gcc... /usr/bin/gcc >> checking resolved symbolic links for CC... >> /usr/bin/mips64el-linux-gnuabi64-gcc-6 >> configure: Using gcc C compiler version 6.3.0 [gcc (Debian 6.3.0-18) >> 6.3.0 20170516] >> checking whether the C compiler works... no >> configure: error: in `/home/loongson/aoqi/jdk': >> configure: error: C compiler cannot create executables >> See `config.log' for more details >> configure exiting with result code 77 >> ... >> >> the related content of config.log: >> ... >> configure:35256: checking whether the C compiler works >> configure:35278: /usr/bin/gcc -m64??? -m64?? conftest.c? >&5 >> gcc: error: unrecognized command line option '-m64' >> gcc: error: unrecognized command line option '-m64' >> configure:35282: $? = 1 >> configure:35320: result: no >> configure: failed program was: >> | /* confdefs.h */ >> | #define PACKAGE_NAME "OpenJDK" >> | #define PACKAGE_TARNAME "openjdk" >> | #define PACKAGE_VERSION "jdk9" >> | #define PACKAGE_STRING "OpenJDK jdk9" >> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" >> | #define PACKAGE_URL "http://openjdk.java.net" >> | /* end confdefs.h.? */ >> | >> | int >> | main () >> | { >> | >> |?? ; >> |?? return 0; >> | } >> configure:35325: error: in `/home/loongson/aoqi/jdk': >> configure:35327: error: C compiler cannot create executables >> See `config.log' for more details >> ... >> >> >> I made a small patch to pass the configure: >> >> $ hg diff make/autoconf/flags.m4 >> diff -r 3acb379b8672 make/autoconf/flags.m4 >> --- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 2018 +0800 >> +++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 2018 +0800 >> @@ -237,7 +237,11 @@ >> ????? MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" >> ??? elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then >> ????? if test "x$OPENJDK_TARGET_CPU" != xaarch64 && >> -??????? test "x$OPENJDK_TARGET_CPU" != xarm; then >> +??????? test "x$OPENJDK_TARGET_CPU" != xarm && >> +??????? test "x$OPENJDK_TARGET_CPU" != xmips && >> +??????? test "x$OPENJDK_TARGET_CPU" != xmipsel && >> +??????? test "x$OPENJDK_TARGET_CPU" != xmips64 && >> +??????? test "x$OPENJDK_TARGET_CPU" != xmips64el; then >> ??????? MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" >> ????? fi >> ??? fi >> >> >> I think this is the same problem with bug 8199052 and 8199152. Could >> someone help to review the change? >> >> Thanks, >> Ao Qi > From aoqi at loongson.cn Fri Mar 23 01:33:07 2018 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 23 Mar 2018 09:33:07 +0800 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> Message-ID: So what should be the next? Is that another problem, or should the MIPS broken configure be fixed together? 2018-03-23 5:04 GMT+08:00 David Holmes : > On 23/03/2018 12:13 AM, Erik Joelsson wrote: >> >> Hello, >> >> The fix looks correct, but I'm starting to think that maybe the >> conditional should be inverted and instead list the architectures that >> actually use -m64? It seems a whole lot of them don't. > > > Magnus indicated he was working on a better solution when he put in the > quick-fix check for Aarch64. Yes this should only add -m64 on compilers and > platforms that support it. > > David > ----- > > >> /Erik >> >> >> On 2018-03-21 23:24, Ao Qi wrote: >>> >>> Hi, >>> >>> I found configure of http://hg.openjdk.java.net/jdk/jdk was broken on >>> MIPS. >>> >>> the output of configure: >>> ... >>> configure: Using default toolchain gcc (GNU Compiler Collection) >>> checking for gcc... /usr/bin/gcc >>> checking resolved symbolic links for CC... >>> /usr/bin/mips64el-linux-gnuabi64-gcc-6 >>> configure: Using gcc C compiler version 6.3.0 [gcc (Debian 6.3.0-18) >>> 6.3.0 20170516] >>> checking whether the C compiler works... no >>> configure: error: in `/home/loongson/aoqi/jdk': >>> configure: error: C compiler cannot create executables >>> See `config.log' for more details >>> configure exiting with result code 77 >>> ... >>> >>> the related content of config.log: >>> ... >>> configure:35256: checking whether the C compiler works >>> configure:35278: /usr/bin/gcc -m64 -m64 conftest.c >&5 >>> gcc: error: unrecognized command line option '-m64' >>> gcc: error: unrecognized command line option '-m64' >>> configure:35282: $? = 1 >>> configure:35320: result: no >>> configure: failed program was: >>> | /* confdefs.h */ >>> | #define PACKAGE_NAME "OpenJDK" >>> | #define PACKAGE_TARNAME "openjdk" >>> | #define PACKAGE_VERSION "jdk9" >>> | #define PACKAGE_STRING "OpenJDK jdk9" >>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" >>> | #define PACKAGE_URL "http://openjdk.java.net" >>> | /* end confdefs.h. */ >>> | >>> | int >>> | main () >>> | { >>> | >>> | ; >>> | return 0; >>> | } >>> configure:35325: error: in `/home/loongson/aoqi/jdk': >>> configure:35327: error: C compiler cannot create executables >>> See `config.log' for more details >>> ... >>> >>> >>> I made a small patch to pass the configure: >>> >>> $ hg diff make/autoconf/flags.m4 >>> diff -r 3acb379b8672 make/autoconf/flags.m4 >>> --- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 2018 +0800 >>> +++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 2018 +0800 >>> @@ -237,7 +237,11 @@ >>> MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" >>> elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then >>> if test "x$OPENJDK_TARGET_CPU" != xaarch64 && >>> - test "x$OPENJDK_TARGET_CPU" != xarm; then >>> + test "x$OPENJDK_TARGET_CPU" != xarm && >>> + test "x$OPENJDK_TARGET_CPU" != xmips && >>> + test "x$OPENJDK_TARGET_CPU" != xmipsel && >>> + test "x$OPENJDK_TARGET_CPU" != xmips64 && >>> + test "x$OPENJDK_TARGET_CPU" != xmips64el; then >>> MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" >>> fi >>> fi >>> >>> >>> I think this is the same problem with bug 8199052 and 8199152. Could >>> someone help to review the change? >>> >>> Thanks, >>> Ao Qi >> >> > From david.holmes at oracle.com Fri Mar 23 01:37:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Mar 2018 11:37:40 +1000 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> Message-ID: <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> On 23/03/2018 11:33 AM, Ao Qi wrote: > So what should be the next? Is that another problem, or should the > MIPS broken configure be fixed together? There should be one proper fix to cover all affected platforms. David > 2018-03-23 5:04 GMT+08:00 David Holmes : >> On 23/03/2018 12:13 AM, Erik Joelsson wrote: >>> >>> Hello, >>> >>> The fix looks correct, but I'm starting to think that maybe the >>> conditional should be inverted and instead list the architectures that >>> actually use -m64? It seems a whole lot of them don't. >> >> >> Magnus indicated he was working on a better solution when he put in the >> quick-fix check for Aarch64. Yes this should only add -m64 on compilers and >> platforms that support it. >> >> David >> ----- >> >> >>> /Erik >>> >>> >>> On 2018-03-21 23:24, Ao Qi wrote: >>>> >>>> Hi, >>>> >>>> I found configure of http://hg.openjdk.java.net/jdk/jdk was broken on >>>> MIPS. >>>> >>>> the output of configure: >>>> ... >>>> configure: Using default toolchain gcc (GNU Compiler Collection) >>>> checking for gcc... /usr/bin/gcc >>>> checking resolved symbolic links for CC... >>>> /usr/bin/mips64el-linux-gnuabi64-gcc-6 >>>> configure: Using gcc C compiler version 6.3.0 [gcc (Debian 6.3.0-18) >>>> 6.3.0 20170516] >>>> checking whether the C compiler works... no >>>> configure: error: in `/home/loongson/aoqi/jdk': >>>> configure: error: C compiler cannot create executables >>>> See `config.log' for more details >>>> configure exiting with result code 77 >>>> ... >>>> >>>> the related content of config.log: >>>> ... >>>> configure:35256: checking whether the C compiler works >>>> configure:35278: /usr/bin/gcc -m64 -m64 conftest.c >&5 >>>> gcc: error: unrecognized command line option '-m64' >>>> gcc: error: unrecognized command line option '-m64' >>>> configure:35282: $? = 1 >>>> configure:35320: result: no >>>> configure: failed program was: >>>> | /* confdefs.h */ >>>> | #define PACKAGE_NAME "OpenJDK" >>>> | #define PACKAGE_TARNAME "openjdk" >>>> | #define PACKAGE_VERSION "jdk9" >>>> | #define PACKAGE_STRING "OpenJDK jdk9" >>>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" >>>> | #define PACKAGE_URL "http://openjdk.java.net" >>>> | /* end confdefs.h. */ >>>> | >>>> | int >>>> | main () >>>> | { >>>> | >>>> | ; >>>> | return 0; >>>> | } >>>> configure:35325: error: in `/home/loongson/aoqi/jdk': >>>> configure:35327: error: C compiler cannot create executables >>>> See `config.log' for more details >>>> ... >>>> >>>> >>>> I made a small patch to pass the configure: >>>> >>>> $ hg diff make/autoconf/flags.m4 >>>> diff -r 3acb379b8672 make/autoconf/flags.m4 >>>> --- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 2018 +0800 >>>> +++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 2018 +0800 >>>> @@ -237,7 +237,11 @@ >>>> MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" >>>> elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then >>>> if test "x$OPENJDK_TARGET_CPU" != xaarch64 && >>>> - test "x$OPENJDK_TARGET_CPU" != xarm; then >>>> + test "x$OPENJDK_TARGET_CPU" != xarm && >>>> + test "x$OPENJDK_TARGET_CPU" != xmips && >>>> + test "x$OPENJDK_TARGET_CPU" != xmipsel && >>>> + test "x$OPENJDK_TARGET_CPU" != xmips64 && >>>> + test "x$OPENJDK_TARGET_CPU" != xmips64el; then >>>> MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" >>>> fi >>>> fi >>>> >>>> >>>> I think this is the same problem with bug 8199052 and 8199152. Could >>>> someone help to review the change? >>>> >>>> Thanks, >>>> Ao Qi >>> >>> >> From thomas.stuefe at gmail.com Fri Mar 23 04:55:59 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Mar 2018 05:55:59 +0100 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> Message-ID: Hi David, would it not be pragmatic to accept Ao's patch - it looks fine to me - since it certainly would not make matters worse. And let Magnus follow up with a cleanup change later? Best Regards, Thomas On Fri, Mar 23, 2018 at 2:37 AM, David Holmes wrote: > On 23/03/2018 11:33 AM, Ao Qi wrote: > >> So what should be the next? Is that another problem, or should the >> MIPS broken configure be fixed together? >> > > There should be one proper fix to cover all affected platforms. > > David > > > 2018-03-23 5:04 GMT+08:00 David Holmes : >> >>> On 23/03/2018 12:13 AM, Erik Joelsson wrote: >>> >>>> >>>> Hello, >>>> >>>> The fix looks correct, but I'm starting to think that maybe the >>>> conditional should be inverted and instead list the architectures that >>>> actually use -m64? It seems a whole lot of them don't. >>>> >>> >>> >>> Magnus indicated he was working on a better solution when he put in the >>> quick-fix check for Aarch64. Yes this should only add -m64 on compilers >>> and >>> platforms that support it. >>> >>> David >>> ----- >>> >>> >>> /Erik >>>> >>>> >>>> On 2018-03-21 23:24, Ao Qi wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> I found configure of http://hg.openjdk.java.net/jdk/jdk was broken on >>>>> MIPS. >>>>> >>>>> the output of configure: >>>>> ... >>>>> configure: Using default toolchain gcc (GNU Compiler Collection) >>>>> checking for gcc... /usr/bin/gcc >>>>> checking resolved symbolic links for CC... >>>>> /usr/bin/mips64el-linux-gnuabi64-gcc-6 >>>>> configure: Using gcc C compiler version 6.3.0 [gcc (Debian 6.3.0-18) >>>>> 6.3.0 20170516] >>>>> checking whether the C compiler works... no >>>>> configure: error: in `/home/loongson/aoqi/jdk': >>>>> configure: error: C compiler cannot create executables >>>>> See `config.log' for more details >>>>> configure exiting with result code 77 >>>>> ... >>>>> >>>>> the related content of config.log: >>>>> ... >>>>> configure:35256: checking whether the C compiler works >>>>> configure:35278: /usr/bin/gcc -m64 -m64 conftest.c >&5 >>>>> gcc: error: unrecognized command line option '-m64' >>>>> gcc: error: unrecognized command line option '-m64' >>>>> configure:35282: $? = 1 >>>>> configure:35320: result: no >>>>> configure: failed program was: >>>>> | /* confdefs.h */ >>>>> | #define PACKAGE_NAME "OpenJDK" >>>>> | #define PACKAGE_TARNAME "openjdk" >>>>> | #define PACKAGE_VERSION "jdk9" >>>>> | #define PACKAGE_STRING "OpenJDK jdk9" >>>>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" >>>>> | #define PACKAGE_URL "http://openjdk.java.net" >>>>> | /* end confdefs.h. */ >>>>> | >>>>> | int >>>>> | main () >>>>> | { >>>>> | >>>>> | ; >>>>> | return 0; >>>>> | } >>>>> configure:35325: error: in `/home/loongson/aoqi/jdk': >>>>> configure:35327: error: C compiler cannot create executables >>>>> See `config.log' for more details >>>>> ... >>>>> >>>>> >>>>> I made a small patch to pass the configure: >>>>> >>>>> $ hg diff make/autoconf/flags.m4 >>>>> diff -r 3acb379b8672 make/autoconf/flags.m4 >>>>> --- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 2018 +0800 >>>>> +++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 2018 +0800 >>>>> @@ -237,7 +237,11 @@ >>>>> MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" >>>>> elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then >>>>> if test "x$OPENJDK_TARGET_CPU" != xaarch64 && >>>>> - test "x$OPENJDK_TARGET_CPU" != xarm; then >>>>> + test "x$OPENJDK_TARGET_CPU" != xarm && >>>>> + test "x$OPENJDK_TARGET_CPU" != xmips && >>>>> + test "x$OPENJDK_TARGET_CPU" != xmipsel && >>>>> + test "x$OPENJDK_TARGET_CPU" != xmips64 && >>>>> + test "x$OPENJDK_TARGET_CPU" != xmips64el; then >>>>> MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" >>>>> fi >>>>> fi >>>>> >>>>> >>>>> I think this is the same problem with bug 8199052 and 8199152. Could >>>>> someone help to review the change? >>>>> >>>>> Thanks, >>>>> Ao Qi >>>>> >>>> >>>> >>>> >>> From david.holmes at oracle.com Fri Mar 23 05:22:03 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Mar 2018 15:22:03 +1000 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> Message-ID: <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> Hi Thomas, On 23/03/2018 2:55 PM, Thomas St?fe wrote: > Hi David, > > would it not be pragmatic to accept Ao's patch - it looks fine to me - > since it certainly would not make matters worse. And let Magnus follow > up with a cleanup change later? Well I hope Magnus's change is forthcoming. AFAICS it's as easy to write this only for x86 as it is to exclude it for non x86. Honestly I don't know why the Aarch64 patch was done the way it was - there must be some subtlety here that I'm not aware of. Ao has the fix locally and I'm assuming we don't have a large number of MIPS users waiting for this urgently (and they can trivially patch it locally anyway). Otherwise there's just more bug processing overhead. David > Best Regards, Thomas > > On Fri, Mar 23, 2018 at 2:37 AM, David Holmes > wrote: > > On 23/03/2018 11:33 AM, Ao Qi wrote: > > So what should be the next? Is that another problem, or should the > MIPS broken configure be fixed together? > > > There should be one proper fix to cover all affected platforms. > > David > > > 2018-03-23 5:04 GMT+08:00 David Holmes >: > > On 23/03/2018 12:13 AM, Erik Joelsson wrote: > > > Hello, > > The fix looks correct, but I'm starting to think that > maybe the > conditional should be inverted and instead list the > architectures that > actually use -m64? It seems a whole lot of them don't. > > > > Magnus indicated he was working on a better solution when he > put in the > quick-fix check for Aarch64. Yes this should only add -m64 > on compilers and > platforms that support it. > > David > ----- > > > /Erik > > > On 2018-03-21 23:24, Ao Qi wrote: > > > Hi, > > I found configure of > http://hg.openjdk.java.net/jdk/jdk > was broken on > MIPS. > > the output of configure: > ... > configure: Using default toolchain gcc (GNU Compiler > Collection) > checking for gcc... /usr/bin/gcc > checking resolved symbolic links for CC... > /usr/bin/mips64el-linux-gnuabi64-gcc-6 > configure: Using gcc C compiler version 6.3.0 [gcc > (Debian 6.3.0-18) > 6.3.0 20170516] > checking whether the C compiler works... no > configure: error: in `/home/loongson/aoqi/jdk': > configure: error: C compiler cannot create executables > See `config.log' for more details > configure exiting with result code 77 > ... > > the related content of config.log: > ... > configure:35256: checking whether the C compiler works > configure:35278: /usr/bin/gcc -m64? ? -m64 > ?conftest.c? >&5 > gcc: error: unrecognized command line option '-m64' > gcc: error: unrecognized command line option '-m64' > configure:35282: $? = 1 > configure:35320: result: no > configure: failed program was: > | /* confdefs.h */ > | #define PACKAGE_NAME "OpenJDK" > | #define PACKAGE_TARNAME "openjdk" > | #define PACKAGE_VERSION "jdk9" > | #define PACKAGE_STRING "OpenJDK jdk9" > | #define PACKAGE_BUGREPORT > "build-dev at openjdk.java.net > " > | #define PACKAGE_URL "http://openjdk.java.net" > | /* end confdefs.h.? */ > | > | int > | main () > | { > | > |? ?; > |? ?return 0; > | } > configure:35325: error: in `/home/loongson/aoqi/jdk': > configure:35327: error: C compiler cannot create > executables > See `config.log' for more details > ... > > > I made a small patch to pass the configure: > > $ hg diff make/autoconf/flags.m4 > diff -r 3acb379b8672 make/autoconf/flags.m4 > --- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 > 2018 +0800 > +++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 > 2018 +0800 > @@ -237,7 +237,11 @@ > ? ? ? ?MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" > ? ? ?elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then > ? ? ? ?if test "x$OPENJDK_TARGET_CPU" != xaarch64 && > -? ? ? ? test "x$OPENJDK_TARGET_CPU" != xarm; then > +? ? ? ? test "x$OPENJDK_TARGET_CPU" != xarm && > +? ? ? ? test "x$OPENJDK_TARGET_CPU" != xmips && > +? ? ? ? test "x$OPENJDK_TARGET_CPU" != xmipsel && > +? ? ? ? test "x$OPENJDK_TARGET_CPU" != xmips64 && > +? ? ? ? test "x$OPENJDK_TARGET_CPU" != xmips64el; then > ? ? ? ? ?MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" > ? ? ? ?fi > ? ? ?fi > > > I think this is the same problem with bug 8199052 > and 8199152. Could > someone help to review the change? > > Thanks, > Ao Qi > > > > > From thomas.stuefe at gmail.com Fri Mar 23 05:33:55 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Mar 2018 06:33:55 +0100 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> Message-ID: On Fri, Mar 23, 2018 at 6:22 AM, David Holmes wrote: > Hi Thomas, > > On 23/03/2018 2:55 PM, Thomas St?fe wrote: > >> Hi David, >> >> would it not be pragmatic to accept Ao's patch - it looks fine to me - >> since it certainly would not make matters worse. And let Magnus follow up >> with a cleanup change later? >> > > Well I hope Magnus's change is forthcoming. AFAICS it's as easy to write > this only for x86 as it is to exclude it for non x86. Honestly I don't know > why the Aarch64 patch was done the way it was - there must be some subtlety > here that I'm not aware of. > > Ao has the fix locally and I'm assuming we don't have a large number of > MIPS users waiting for this urgently (and they can trivially patch it > locally anyway). Otherwise there's just more bug processing overhead. > > Okay, I see your point. ..Thomas > David > > Best Regards, Thomas >> >> On Fri, Mar 23, 2018 at 2:37 AM, David Holmes > > wrote: >> >> On 23/03/2018 11:33 AM, Ao Qi wrote: >> >> So what should be the next? Is that another problem, or should the >> MIPS broken configure be fixed together? >> >> >> There should be one proper fix to cover all affected platforms. >> >> David >> >> >> 2018-03-23 5:04 GMT+08:00 David Holmes > >: >> >> >> On 23/03/2018 12:13 AM, Erik Joelsson wrote: >> >> >> Hello, >> >> The fix looks correct, but I'm starting to think that >> maybe the >> conditional should be inverted and instead list the >> architectures that >> actually use -m64? It seems a whole lot of them don't. >> >> >> >> Magnus indicated he was working on a better solution when he >> put in the >> quick-fix check for Aarch64. Yes this should only add -m64 >> on compilers and >> platforms that support it. >> >> David >> ----- >> >> >> /Erik >> >> >> On 2018-03-21 23:24, Ao Qi wrote: >> >> >> Hi, >> >> I found configure of >> http://hg.openjdk.java.net/jdk/jdk >> was broken on >> MIPS. >> >> the output of configure: >> ... >> configure: Using default toolchain gcc (GNU Compiler >> Collection) >> checking for gcc... /usr/bin/gcc >> checking resolved symbolic links for CC... >> /usr/bin/mips64el-linux-gnuabi64-gcc-6 >> configure: Using gcc C compiler version 6.3.0 [gcc >> (Debian 6.3.0-18) >> 6.3.0 20170516] >> checking whether the C compiler works... no >> configure: error: in `/home/loongson/aoqi/jdk': >> configure: error: C compiler cannot create executables >> See `config.log' for more details >> configure exiting with result code 77 >> ... >> >> the related content of config.log: >> ... >> configure:35256: checking whether the C compiler works >> configure:35278: /usr/bin/gcc -m64 -m64 >> conftest.c >&5 >> gcc: error: unrecognized command line option '-m64' >> gcc: error: unrecognized command line option '-m64' >> configure:35282: $? = 1 >> configure:35320: result: no >> configure: failed program was: >> | /* confdefs.h */ >> | #define PACKAGE_NAME "OpenJDK" >> | #define PACKAGE_TARNAME "openjdk" >> | #define PACKAGE_VERSION "jdk9" >> | #define PACKAGE_STRING "OpenJDK jdk9" >> | #define PACKAGE_BUGREPORT >> "build-dev at openjdk.java.net >> " >> >> | #define PACKAGE_URL "http://openjdk.java.net" >> | /* end confdefs.h. */ >> | >> | int >> | main () >> | { >> | >> | ; >> | return 0; >> | } >> configure:35325: error: in `/home/loongson/aoqi/jdk': >> configure:35327: error: C compiler cannot create >> executables >> See `config.log' for more details >> ... >> >> >> I made a small patch to pass the configure: >> >> $ hg diff make/autoconf/flags.m4 >> diff -r 3acb379b8672 make/autoconf/flags.m4 >> --- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 >> 2018 +0800 >> +++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 >> 2018 +0800 >> @@ -237,7 +237,11 @@ >> MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" >> elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then >> if test "x$OPENJDK_TARGET_CPU" != xaarch64 && >> - test "x$OPENJDK_TARGET_CPU" != xarm; then >> + test "x$OPENJDK_TARGET_CPU" != xarm && >> + test "x$OPENJDK_TARGET_CPU" != xmips && >> + test "x$OPENJDK_TARGET_CPU" != xmipsel && >> + test "x$OPENJDK_TARGET_CPU" != xmips64 && >> + test "x$OPENJDK_TARGET_CPU" != xmips64el; >> then >> MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" >> fi >> fi >> >> >> I think this is the same problem with bug 8199052 >> and 8199152. Could >> someone help to review the change? >> >> Thanks, >> Ao Qi >> >> >> >> >> >> From magnus.ihse.bursie at oracle.com Fri Mar 23 08:46:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 09:46:49 +0100 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> Message-ID: <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> On 2018-03-23 06:22, David Holmes wrote: > Hi Thomas, > > On 23/03/2018 2:55 PM, Thomas St?fe wrote: >> Hi David, >> >> would it not be pragmatic to accept Ao's patch - it looks fine to me >> - since it certainly would not make matters worse. And let Magnus >> follow up with a cleanup change later? > > Well I hope Magnus's change is forthcoming. It might be some time still. I'm working on a complete overhaul of all CFLAGS and LDFLAGS, where this is a part of that picture, but I was not planning on addressing just this thing urgently. So, I think this patch will do for now. It solves the immediate problem for MIPS, and I can come back and make a cleaner solution later on. > AFAICS it's as easy to write this only for x86 as it is to exclude it > for non x86. Honestly I don't know why the Aarch64 patch was done the > way it was - there must be some subtlety here that I'm not aware of. I think it was just the smallest patch that worked for the aarch64 platform. I didn't spend time arguing about the fix, since it is supposed to be short-lived anyway. /Magnus From david.holmes at oracle.com Fri Mar 23 08:55:39 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Mar 2018 18:55:39 +1000 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> Message-ID: On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote: > > On 2018-03-23 06:22, David Holmes wrote: >> Hi Thomas, >> >> On 23/03/2018 2:55 PM, Thomas St?fe wrote: >>> Hi David, >>> >>> would it not be pragmatic to accept Ao's patch - it looks fine to me >>> - since it certainly would not make matters worse. And let Magnus >>> follow up with a cleanup change later? >> >> Well I hope Magnus's change is forthcoming. > It might be some time still. I'm working on a complete overhaul of all > CFLAGS and LDFLAGS, where this is a part of that picture, but I was not > planning on addressing just this thing urgently. > > So, I think this patch will do for now. It solves the immediate problem > for MIPS, and I can come back and make a cleaner solution later on. Isn't the best quick fix one that only adds -m64 for x86? I recall a report that arm32 is similarly broken. David ----- >> AFAICS it's as easy to write this only for x86 as it is to exclude it >> for non x86. Honestly I don't know why the Aarch64 patch was done the >> way it was - there must be some subtlety here that I'm not aware of. > I think it was just the smallest patch that worked for the aarch64 > platform. I didn't spend time arguing about the fix, since it is > supposed to be short-lived anyway. > > /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 23 09:54:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 10:54:40 +0100 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> Message-ID: <20ff592c-bfd6-4430-f2a7-a08eb3241477@oracle.com> On 2018-03-23 09:55, David Holmes wrote: > On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote: >> >> On 2018-03-23 06:22, David Holmes wrote: >>> Hi Thomas, >>> >>> On 23/03/2018 2:55 PM, Thomas St?fe wrote: >>>> Hi David, >>>> >>>> would it not be pragmatic to accept Ao's patch - it looks fine to >>>> me - since it certainly would not make matters worse. And let >>>> Magnus follow up with a cleanup change later? >>> >>> Well I hope Magnus's change is forthcoming. >> It might be some time still. I'm working on a complete overhaul of >> all CFLAGS and LDFLAGS, where this is a part of that picture, but I >> was not planning on addressing just this thing urgently. >> >> So, I think this patch will do for now. It solves the immediate >> problem for MIPS, and I can come back and make a cleaner solution >> later on. > > Isn't the best quick fix one that only adds -m64 for x86? I recall? a > report that arm32 is similarly broken. Not really, because this is also needed on some other platforms, at least s390x, as I recall. (This was the reason it was originally added.) /Magnus > > David > ----- > >>> AFAICS it's as easy to write this only for x86 as it is to exclude >>> it for non x86. Honestly I don't know why the Aarch64 patch was done >>> the way it was - there must be some subtlety here that I'm not aware >>> of. >> I think it was just the smallest patch that worked for the aarch64 >> platform. I didn't spend time arguing about the fix, since it is >> supposed to be short-lived anyway. >> >> /Magnus From aoqi at loongson.cn Fri Mar 23 10:04:09 2018 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 23 Mar 2018 18:04:09 +0800 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> Message-ID: >> >> It might be some time still. I'm working on a complete overhaul of all >> CFLAGS and LDFLAGS, where this is a part of that picture, but I was not >> planning on addressing just this thing urgently. >> >> So, I think this patch will do for now. It solves the immediate problem >> for MIPS, and I can come back and make a cleaner solution later on. > > > Isn't the best quick fix one that only adds -m64 for x86? I recall a report > that arm32 is similarly broken. I had a look at man gcc. It seems that at least -m64 is for S/390 and zSeries, SPARC , RS/6000 and PowerPC, and x86. > > David > ----- > > From david.holmes at oracle.com Fri Mar 23 10:05:14 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Mar 2018 20:05:14 +1000 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <20ff592c-bfd6-4430-f2a7-a08eb3241477@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> <20ff592c-bfd6-4430-f2a7-a08eb3241477@oracle.com> Message-ID: <4e165850-8bf5-baed-bb5d-4d5d0b6224f7@oracle.com> On 23/03/2018 7:54 PM, Magnus Ihse Bursie wrote: > > On 2018-03-23 09:55, David Holmes wrote: >> On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote: >>> >>> On 2018-03-23 06:22, David Holmes wrote: >>>> Hi Thomas, >>>> >>>> On 23/03/2018 2:55 PM, Thomas St?fe wrote: >>>>> Hi David, >>>>> >>>>> would it not be pragmatic to accept Ao's patch - it looks fine to >>>>> me - since it certainly would not make matters worse. And let >>>>> Magnus follow up with a cleanup change later? >>>> >>>> Well I hope Magnus's change is forthcoming. >>> It might be some time still. I'm working on a complete overhaul of >>> all CFLAGS and LDFLAGS, where this is a part of that picture, but I >>> was not planning on addressing just this thing urgently. >>> >>> So, I think this patch will do for now. It solves the immediate >>> problem for MIPS, and I can come back and make a cleaner solution >>> later on. >> >> Isn't the best quick fix one that only adds -m64 for x86? I recall? a >> report that arm32 is similarly broken. > Not really, because this is also needed on some other platforms, at > least s390x, as I recall. (This was the reason it was originally added.) According to gcc docs there are 4 archs that use m64 and we only care about 2 of them: m64: SPARC Options m64: S/390 and zSeries Options m64: RS/6000 and PowerPC Options m64: i386 and x86-64 Options But you need to know whether you are dealing with S390 or S390x as m64 implies zSeries. Ao will need a sponsor to create a bug etc regardless of which way this goes. My week is over. :) Cheers, David > /Magnus > >> >> David >> ----- >> >>>> AFAICS it's as easy to write this only for x86 as it is to exclude >>>> it for non x86. Honestly I don't know why the Aarch64 patch was done >>>> the way it was - there must be some subtlety here that I'm not aware >>>> of. >>> I think it was just the smallest patch that worked for the aarch64 >>> platform. I didn't spend time arguing about the fix, since it is >>> supposed to be short-lived anyway. >>> >>> /Magnus > From magnus.ihse.bursie at oracle.com Fri Mar 23 11:59:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 12:59:49 +0100 Subject: RFR: JDK-8200174 compare.sh improvements Message-ID: <0c4c9165-ef47-730b-f6c6-560bc4cfae16@oracle.com> This patch contains two larger improvements to compare.sh: * Start by doing the binary comparison. This is often the most interesting part, and for interactive sessions, much time is saved is this is done first (after the quick sanity check of the file tree). * Allow not all parts (like the JRE image and sec-bin.zip) to be present. This also speeds up tests by making "make jdk-image" as the prerequisite for running comparison. A fix for the hex disasm filter on solstudio is also included. Bug: https://bugs.openjdk.java.net/browse/JDK-8200174 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200174-compare-sh-improvements/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 23 13:56:34 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 14:56:34 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries Message-ID: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or __declspec(dllexport)) to control symbol visibility, directly in the source code. This has historically not been present on all compilers, so we had to resort to using mapfiles (also known as linker scripts). This is no longer the case. Now all compilers we use support symbol visibility directives, in one form or another. We should start using this. Since this has been the only way to control symbol visibility on Windows, for most of the shared code, we already have proper JNIEXPORT decorations in place. If we fix the remaining platform-specific files to have proper JNIEXPORT tagging, then we can finally get rid of mapfiles. This fix removed mapfiles for all JDK libraries. It does not touch hotspot libraries nor JDK executables; they will have to wait for a future fix -- this was complex enough. This change will not have any impact on macosx, since we do not use mapfiles there, but instead export all symbols. (This is not a good idea, but I'll address that separately.) This change will also have a minimal impact on Windows. The only reason Windows is impacted at all, is that some changes needed by Solaris and Linux were simpler to fix for all platforms. I have strived for this change to have no impact on the actual generated code. Unfortunately, this was not possible to fully achieve. I do not believe that these changes will have any actual impact on the product, though. I will present the differences more in detail further down. Those who are not interested can probably skip that. The patch has passed tier1 testing and is currently running tier2 and tier3. Since the running code is more or less (see caveat below) unmodified, I don't expect any testing issues. Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 Details on changes: Most of the source code changes are (unsurprisingly) in java.base and java.desktop. Remaining changes are in jdk.crypto.ucrypto, jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. Source code changes does almost to 100% consists in decorating an exported function with JNIEXPORT. I have also followed the long-standing convention of adding JNICALL. This is a no-op on non-Windows platforms, so for most of the changes this is purely cosmetic (and possibly adding in robustness, should the function ever be used on Windows in the future). I have also followed the stylistic convention of putting "JNIEXPORT JNICALL" on a separate line. For some functions, however, this might cause a change in calling convention on Windows. Since this can not apply to exported functions on Windows (otherwise they would already have had JNIEXPORT), I do not think this matters anything. A few libraries did not have a mapfile, on Linux and/or Solaris. This actually meant that all symbols were exported. It is highly unclear if this was known and intended by the original make rule writer. I have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, we can remove this flag and fix proper exported symbols in the future. I have run the complete build using COMPARE_BUILD, and made a thourough analysis of the differences for Linux and Solaris. All native libraries have symbol differences, but most of them are trivial and/or harmless. As a result, most libraries have disasm differences as well, but these too seem trivial and harmless. The differences in symbols that are common to all libraries include: ?* Internal symbols such as __bss_start, _edata, _end and _fini are now global. (They are imported as such from the compiler libraries/archives, and we have no linker script to override this behavior). ?* The versioning tag SUNWprivate_1.1 is not included, and thus neither the .gnu.version_d symbol. ?* There are a few differences in the symbol and/or mangling of some local functions. I'm not sure what's causing this, but it's unlikely to have any effect on the product. Another common source for change in symbols is due to previous platform differences. For instance, if we had "JNIEXPORT int JNICALL do_foo() { ... }", but do_foo was not in the mapfile, the symbol was exported on Windows but not on Linux and Solaris. (Presumable since it was not needed there, even though it was compiled for those platforms as well.) Now, with the mapfiles gone, do_foo() will be exported on all platforms. And contrary, functions that are compiled on all platforms, and were exported in mapfiles, but now have gotten an JNIEXPORT decoration, will now be visible even on Windows. (This accounts for half of the noticed symbol differences on Windows.) I could have made the JNIEXPORT conditional on OS, but I didn't think the mess in source code were worth the keeping of binary confidence with the old build. A third common source for change in symbols is due to exported functions "leaking" across library borders. For instance, some functions in java.desktop is compiled in both libawt_xawt and libawt_headless, but they were previously only included in the mapfile for one of these libraries. Now, since the visibility is determined by the source code itself, it gets exported in both libraries. A variant of this is when a library depends on another JDK library, and includes the header file from that other library, which in turn declares a function as JNIEXPORT. This will cause the including library to also export the function. This accounts for the other half of the changes on Windows. A typical example of this is that multiple libraries now re-export hotspot symbols from libjvm.so, like jio_fprintf. (I have not listed the libjvm re-exports below.) Note that? Java_java_io_FileOutputStream_close0 in java.base/unix/native/libjava/FileOutputStream_md.c is no longer exported, and can probably be removed. Here is a detailed table showing and accounting for all the remaining differences found on Linux and Solaris: java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is now also exported on unix platforms due to JNIEXPORT. java.base/jspawnlauncher: On solaris, we also include libjava/childproc.o, which now exports less functions than it used to (it used to export all functions, now it is compiled with visibility=hidden). java.base/java(w).exe: Is now also exporting the following symbols due to added JNIEXPORT in libjli on Windows: (Yes, executables can export symbols on Windows. Confusing, I know.) ?JLI_AddArgsFromEnvVar ?JLI_CmdToArgs ?JLI_GetAppArgIndex ?JLI_GetStdArgc ?JLI_GetStdArgs ?JLI_InitArgProcessing ?JLI_Launch ?JLI_List_add ?JLI_List_new ?JLI_ManifestIterate ?JLI_MemAlloc ?JLI_MemFree ?JLI_PreprocessArg ?JLI_ReportErrorMessage ?JLI_ReportErrorMessageSys ?JLI_ReportExceptionDescription ?JLI_ReportMessage ?JLI_SetTraceLauncher ?JLI_StringDup java.desktop:/libawt_xawt: The following symbols are now also exported on linux and solaris due to JNIEXPORT: ?awt_DrawingSurface_FreeDrawingSurfaceInfo ?awt_DrawingSurface_GetDrawingSurfaceInfo ?awt_DrawingSurface_Lock ?awt_DrawingSurface_Unlock ?awt_GetColor The following symbols are now also exported on linux and solaris due to JNIEXPORT (they were previously ?exported only in libawt): ?Java_sun_awt_DebugSettings_setCTracingOn__Z ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I ?Java_sun_awt_X11GraphicsConfig_getNumColors java.desktop:/libawt_headless: The following symbols are now also exported due to JNIEXPORT (they were previously ?exported only in libawt_xawt and/or libawt): ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable ?X11SurfaceData_GetOps java.desktop/libawt: The following symbols are now also exported on Windows, due to added JNIEXPORT: ?SurfaceData_InitOps ?mul8table ?div8table ?doDrawPath ?doFillPath ?g_CMpDataID ?initInverseGrayLut ?make_dither_arrays ?make_uns_ordered_dither_array ?path2DFloatCoordsID ?path2DNumTypesID ?path2DTypesID ?path2DWindingRuleID ?sg2dStrokeHintID ?std_img_oda_blue ?std_img_oda_green ?std_img_oda_red ?std_odas_computed ?sunHints_INTVAL_STROKE_PURE java.desktop/libawt on solaris: A number of "#pragma weak" directives was previously overridden by the mapfile. Now these directives are respected, so these symbols are now weak instead of local: ?ByteGrayToIntArgbPreConvert_F ?ByteGrayToIntArgbPreScaleConvert_F ?IntArgbBmToFourByteAbgrPreScaleXparOver_F ?IntArgbToIntRgbXorBlit_F ?IntBgrToIntBgrAlphaMaskBlit_F java.desktop/libawt on solaris: These are now also exported due to JNIEXPORT in libmlib_image. ?j2d_mlib_ImageCreate ?j2d_mlib_ImageCreateStruct ?j2d_mlib_ImageDelete java.desktop/libawt on solaris: This is now also exported due to JNIEXPORT: ?GrPrim_CompGetXorColor ?SurfaceData_GetOpsNoSetup ?SurfaceData_IntersectBoundsXYWH ?SurfaceData_SetOps ?Transform_GetInfo ?Transform_transform java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and solaris due to JNIEXPORT. libspashscreen also had JNIEXPORT (actually a pure _declspec(dllexport)) but no JNICALL, which I added as a part of converting to JNIEXPORT. The same goes for libmlib_image . jdk.sctp/libsctp: handleSocketError is now exported on linux and solaris due to JNIEXPORT in libnio. java.instrument:/libinstrument: Agent_OnUnload is now also exported on linux and solaris platforms due to JNIEXPORT. JLI_ManifestIterate is now also exported on Windows, due to added JNIEXPORT in libjli. jdk.management/libmanagement_ext: Java_com_sun_management_internal_Flag_setDoubleValue is now also exported on linux and solaris platforms due to JNIEXPORT. /Magnus From erik.joelsson at oracle.com Fri Mar 23 13:58:13 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 Mar 2018 06:58:13 -0700 Subject: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h In-Reply-To: References: <7F114FA8-59F0-42F1-A0B8-33D8C22DE81A@oracle.com> Message-ID: <52afd5ec-e136-b924-8127-d3e33bf04428@oracle.com> I think this looks good, but Magnus is currently refactoring the flags handling in configure so better get his input as well. (adding build-dev) /Erik On 2018-03-23 05:37, Robin Westberg wrote: > Hi Kim & Erik, > > Certainly makes sense to define it from the build system, I?ve updated > the patch accordingly: > > Full: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/ > > > (Not quite sure if the definition belongs where I put it or a bit > later where most other windows-specific JVM flags are defined, but > seemed reasonable to put it close to where it is defined for the JDK > libraries). > > Best regards, > Robin > >> On 22 Mar 2018, at 16:52, Kim Barrett > > wrote: >> >>> On Mar 22, 2018, at 10:34 AM, Robin Westberg >>> > wrote: >>> >>> Hi all, >>> >>> Please review the following change that defines WIN32_LEAN_AND_MEAN >>> [1] before including windows.h. This marginally improves build >>> times, and makes it possible to include winsock2.h. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199736 >>> >>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/ >>> >>> >> > >>> Testing: hs-tier1 >>> >>> Best regards, >>> Robin >>> >>> [1] >>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745%28v=vs.85%29.aspx#faster_builds_with_smaller_header_files >>> >> > >> >> I think the addition of the WIN32_LEAN_AND_MEAN definition should be >> done through the build >> system, so that it applies everywhere. >> > From erik.joelsson at oracle.com Fri Mar 23 14:06:44 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 Mar 2018 07:06:44 -0700 Subject: RFR: JDK-8200174 compare.sh improvements In-Reply-To: <0c4c9165-ef47-730b-f6c6-560bc4cfae16@oracle.com> References: <0c4c9165-ef47-730b-f6c6-560bc4cfae16@oracle.com> Message-ID: <293b3f82-2959-f1c0-56f2-658ddee8edd2@oracle.com> Looks ok. Note that you can filter what checks are done with command line options. I usually add -libs when working specifically with native library differences. /Erik On 2018-03-23 04:59, Magnus Ihse Bursie wrote: > This patch contains two larger improvements to compare.sh: > * Start by doing the binary comparison. This is often the most > interesting part, and for interactive sessions, much time is saved is > this is done first (after the quick sanity check of the file tree). > * Allow not all parts (like the JRE image and sec-bin.zip) to be > present. This also speeds up tests by making "make jdk-image" as the > prerequisite for running comparison. > > A fix for the hex disasm filter on solstudio is also included. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200174 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200174-compare-sh-improvements/webrev.01 > > /Magnus From erik.joelsson at oracle.com Fri Mar 23 14:30:14 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 Mar 2018 07:30:14 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> Message-ID: <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> I have looked at the build changes and they look good. Will you file followups for each component team to look over their exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical debt laying around here. /Erik On 2018-03-23 06:56, Magnus Ihse Bursie wrote: > With modern compilers, we can use compiler directives (such as > _attribute__((visibility("default"))), or __declspec(dllexport)) to > control symbol visibility, directly in the source code. This has > historically not been present on all compilers, so we had to resort to > using mapfiles (also known as linker scripts). > > This is no longer the case. Now all compilers we use support symbol > visibility directives, in one form or another. We should start using > this. Since this has been the only way to control symbol visibility on > Windows, for most of the shared code, we already have proper JNIEXPORT > decorations in place. > > If we fix the remaining platform-specific files to have proper > JNIEXPORT tagging, then we can finally get rid of mapfiles. > > This fix removed mapfiles for all JDK libraries. It does not touch > hotspot libraries nor JDK executables; they will have to wait for a > future fix -- this was complex enough. This change will not have any > impact on macosx, since we do not use mapfiles there, but instead > export all symbols. (This is not a good idea, but I'll address that > separately.) This change will also have a minimal impact on Windows. > The only reason Windows is impacted at all, is that some changes > needed by Solaris and Linux were simpler to fix for all platforms. > > I have strived for this change to have no impact on the actual > generated code. Unfortunately, this was not possible to fully achieve. > I do not believe that these changes will have any actual impact on the > product, though. I will present the differences more in detail further > down. Those who are not interested can probably skip that. > > The patch has passed tier1 testing and is currently running tier2 and > tier3. Since the running code is more or less (see caveat below) > unmodified, I don't expect any testing issues. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 > > Details on changes: > Most of the source code changes are (unsurprisingly) in java.base and > java.desktop. Remaining changes are in jdk.crypto.ucrypto, > jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. > > Source code changes does almost to 100% consists in decorating an > exported function with JNIEXPORT. I have also followed the > long-standing convention of adding JNICALL. This is a no-op on > non-Windows platforms, so for most of the changes this is purely > cosmetic (and possibly adding in robustness, should the function ever > be used on Windows in the future). I have also followed the stylistic > convention of putting "JNIEXPORT JNICALL" on a separate > line. For some functions, however, this might cause a change in > calling convention on Windows. Since this can not apply to exported > functions on Windows (otherwise they would already have had > JNIEXPORT), I do not think this matters anything. > > A few libraries did not have a mapfile, on Linux and/or Solaris. This > actually meant that all symbols were exported. It is highly unclear if > this was known and intended by the original make rule writer. I have > emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these > libraries. Hopefully, we can remove this flag and fix proper exported > symbols in the future. > > I have run the complete build using COMPARE_BUILD, and made a > thourough analysis of the differences for Linux and Solaris. All > native libraries have symbol differences, but most of them are trivial > and/or harmless. As a result, most libraries have disasm differences > as well, but these too seem trivial and harmless. The differences in > symbols that are common to all libraries include: > ?* Internal symbols such as __bss_start, _edata, _end and _fini are > now global. (They are imported as such from the compiler > libraries/archives, and we have no linker script to override this > behavior). > ?* The versioning tag SUNWprivate_1.1 is not included, and thus > neither the .gnu.version_d symbol. > ?* There are a few differences in the symbol and/or mangling of some > local functions. I'm not sure what's causing this, > but it's unlikely to have any effect on the product. > > Another common source for change in symbols is due to previous > platform differences. For instance, if we had "JNIEXPORT int JNICALL > do_foo() { ... }", but do_foo was not in the mapfile, the symbol was > exported on Windows but not on Linux and Solaris. (Presumable since it > was not needed there, even though it was compiled for those platforms > as well.) Now, with the mapfiles gone, do_foo() will be exported on > all platforms. And contrary, functions that are compiled on all > platforms, and were exported in mapfiles, but now have gotten an > JNIEXPORT decoration, will now be visible even on Windows. (This > accounts for half of the noticed symbol differences on Windows.) I > could have made the JNIEXPORT conditional on OS, but I didn't think > the mess in source code were worth the keeping of binary confidence > with the old build. > > A third common source for change in symbols is due to exported > functions "leaking" across library borders. For instance, some > functions in java.desktop is compiled in both libawt_xawt and > libawt_headless, but they were previously only included in the mapfile > for one of these libraries. Now, since the visibility is determined by > the source code itself, it gets exported in both libraries. A variant > of this is when a library depends on another JDK library, and includes > the header file from that other library, which in turn declares a > function as JNIEXPORT. This will cause the including library to also > export the function. This accounts for the other half of the changes > on Windows. A typical example of this is that multiple libraries now > re-export hotspot symbols from libjvm.so, like jio_fprintf. (I have > not listed the libjvm re-exports below.) > > Note that? Java_java_io_FileOutputStream_close0 in > java.base/unix/native/libjava/FileOutputStream_md.c is no longer > exported, > and can probably be removed. > > Here is a detailed table showing and accounting for all the remaining > differences found on Linux and Solaris: > java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is > now also exported on unix platforms due to JNIEXPORT. > > java.base/jspawnlauncher: On solaris, we also include > libjava/childproc.o, which > now exports less functions than it used to (it used to export all > functions, now it is compiled with visibility=hidden). > > java.base/java(w).exe: Is now also exporting the following symbols due > to added JNIEXPORT in libjli on Windows: > (Yes, executables can export symbols on Windows. Confusing, I know.) > ?JLI_AddArgsFromEnvVar > ?JLI_CmdToArgs > ?JLI_GetAppArgIndex > ?JLI_GetStdArgc > ?JLI_GetStdArgs > ?JLI_InitArgProcessing > ?JLI_Launch > ?JLI_List_add > ?JLI_List_new > ?JLI_ManifestIterate > ?JLI_MemAlloc > ?JLI_MemFree > ?JLI_PreprocessArg > ?JLI_ReportErrorMessage > ?JLI_ReportErrorMessageSys > ?JLI_ReportExceptionDescription > ?JLI_ReportMessage > ?JLI_SetTraceLauncher > ?JLI_StringDup > > java.desktop:/libawt_xawt: The following symbols are now also exported > on linux and solaris due to JNIEXPORT: > ?awt_DrawingSurface_FreeDrawingSurfaceInfo > ?awt_DrawingSurface_GetDrawingSurfaceInfo > ?awt_DrawingSurface_Lock > ?awt_DrawingSurface_Unlock > ?awt_GetColor > > The following symbols are now also exported on linux and solaris due > to JNIEXPORT (they were previously > ?exported only in libawt): > ?Java_sun_awt_DebugSettings_setCTracingOn__Z > ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 > ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I > ?Java_sun_awt_X11GraphicsConfig_getNumColors > > java.desktop:/libawt_headless: The following symbols are now also > exported due to JNIEXPORT (they were previously > ?exported only in libawt_xawt and/or libawt): > ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo > ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities > ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask > ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable > ?X11SurfaceData_GetOps > > java.desktop/libawt: The following symbols are now also exported on > Windows, due to added > JNIEXPORT: > ?SurfaceData_InitOps > ?mul8table > ?div8table > ?doDrawPath > ?doFillPath > ?g_CMpDataID > ?initInverseGrayLut > ?make_dither_arrays > ?make_uns_ordered_dither_array > ?path2DFloatCoordsID > ?path2DNumTypesID > ?path2DTypesID > ?path2DWindingRuleID > ?sg2dStrokeHintID > ?std_img_oda_blue > ?std_img_oda_green > ?std_img_oda_red > ?std_odas_computed > ?sunHints_INTVAL_STROKE_PURE > > java.desktop/libawt on solaris: > A number of "#pragma weak" directives was previously overridden by the > mapfile. > Now these directives are respected, so these symbols are now weak > instead of local: > ?ByteGrayToIntArgbPreConvert_F > ?ByteGrayToIntArgbPreScaleConvert_F > ?IntArgbBmToFourByteAbgrPreScaleXparOver_F > ?IntArgbToIntRgbXorBlit_F > ?IntBgrToIntBgrAlphaMaskBlit_F > > java.desktop/libawt on solaris: These are now also exported due to > JNIEXPORT in libmlib_image. > ?j2d_mlib_ImageCreate > ?j2d_mlib_ImageCreateStruct > ?j2d_mlib_ImageDelete > > java.desktop/libawt on solaris: This is now also exported due to > JNIEXPORT: > ?GrPrim_CompGetXorColor > ?SurfaceData_GetOpsNoSetup > ?SurfaceData_IntersectBoundsXYWH > ?SurfaceData_SetOps > ?Transform_GetInfo > ?Transform_transform > > java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and > solaris due to JNIEXPORT. > libspashscreen also had JNIEXPORT (actually a pure > _declspec(dllexport)) but no JNICALL, which I added as > a part of converting to JNIEXPORT. The same goes for libmlib_image . > > jdk.sctp/libsctp: handleSocketError is now exported on linux and > solaris due to JNIEXPORT in libnio. > > java.instrument:/libinstrument: Agent_OnUnload is now also exported on > linux and solaris platforms due to JNIEXPORT. > JLI_ManifestIterate is now also exported on Windows, due to added > JNIEXPORT in libjli. > > jdk.management/libmanagement_ext: > Java_com_sun_management_internal_Flag_setDoubleValue is now also > exported on linux and solaris platforms due to JNIEXPORT. > > /Magnus > > From Alan.Bateman at oracle.com Fri Mar 23 14:45:09 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Mar 2018 14:45:09 +0000 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> Message-ID: <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com> On 23/03/2018 13:56, Magnus Ihse Bursie wrote: > With modern compilers, we can use compiler directives (such as > _attribute__((visibility("default"))), or __declspec(dllexport)) to > control symbol visibility, directly in the source code. This has > historically not been present on all compilers, so we had to resort to > using mapfiles (also known as linker scripts). > > This is no longer the case. Now all compilers we use support symbol > visibility directives, in one form or another. We should start using > this. Since this has been the only way to control symbol visibility on > Windows, for most of the shared code, we already have proper JNIEXPORT > decorations in place. > > If we fix the remaining platform-specific files to have proper > JNIEXPORT tagging, then we can finally get rid of mapfiles. This seems like a great cleanup as the mapfile have always been a pain to maintain. Also shines a light on some technical debt too. handleSocketError in libnio is a surprise, this should not be exported and should not have been in the map file.? I suspect the issue is that jdk.sctp is missing a function prototype from its header file (it has its own handleSocketError in SctpNet.c). NET_Wait in libnet is another one, I can't tell why this was listed in the map file. I'm also surprised with java.dll exporting handleRead, winHandleRead, and handleLSeek. I didn't see them mentioned in your mail so I'm curious what might be using those. -Alan From igor.ignatyev at oracle.com Fri Mar 23 15:13:35 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 23 Mar 2018 08:13:35 -0700 Subject: RFR(XXS) : 8200180 : fix a typo in run-test framework documentation Message-ID: http://cr.openjdk.java.net/~iignatyev//8200180/webrev.00/index.html > 3 lines changed: 0 ins; 0 del; 3 mod; Hi all, could you please review this small fix for run-test framework documentation? VM_OTIONS was used instead of VM_OPTIONS at several places, the fix is obvious s/VM_OTIONS/VM_OPTIONS/ . webrev: http://cr.openjdk.java.net/~iignatyev//8200180/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8200180 Thanks, -- Igor From magnus.ihse.bursie at oracle.com Fri Mar 23 15:15:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 16:15:35 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com> Message-ID: > 23 mars 2018 kl. 15:45 skrev Alan Bateman : > >> On 23/03/2018 13:56, Magnus Ihse Bursie wrote: >> With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or __declspec(dllexport)) to control symbol visibility, directly in the source code. This has historically not been present on all compilers, so we had to resort to using mapfiles (also known as linker scripts). >> >> This is no longer the case. Now all compilers we use support symbol visibility directives, in one form or another. We should start using this. Since this has been the only way to control symbol visibility on Windows, for most of the shared code, we already have proper JNIEXPORT decorations in place. >> >> If we fix the remaining platform-specific files to have proper JNIEXPORT tagging, then we can finally get rid of mapfiles. > This seems like a great cleanup as the mapfile have always been a pain to maintain. Also shines a light on some technical debt too. Very much so, yes. I've found a lot of dubious exports, everything from global variables (yuck!) to functions that does not seem to be used anymore, to lots of strange exports. > handleSocketError in libnio is a surprise, this should not be exported and should not have been in the map file. I suspect the issue is that jdk.sctp is missing a function prototype from its header file (it has its own handleSocketError in SctpNet.c). That might be so, yes. > NET_Wait in libnet is another one, I can't tell why this was listed in the map file. Neither can I. :-) Once again, my goal with this patch was to keep the produced binaries as similar to before with the mapfiles. I'll be happy to file follow-up bugs listing all suspicious symbol handling I've encountered, but I'd rather not change anything about that in this patch. > I'm also surprised with java.dll exporting handleRead, winHandleRead, and handleLSeek. I didn't see them mentioned in your mail so I'm curious what might be using those. They were previously exported using -export: on the command line for the Microsoft linker. This was the case for a couple other libraries as well. Yeah, I forgot to write about that, sorry. :( Been a lot to keep track of, and it went away when I cleaned up my notes. Can I consider this a review? /Magnus > > -Alan From erik.joelsson at oracle.com Fri Mar 23 15:25:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 Mar 2018 08:25:36 -0700 Subject: RFR(XXS) : 8200180 : fix a typo in run-test framework documentation In-Reply-To: References: Message-ID: Hello Igor, This looks good, but please also run "make update-build-docs" so that the html file also gets regenerated before pushing. /Erik On 2018-03-23 08:13, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8200180/webrev.00/index.html >> 3 lines changed: 0 ins; 0 del; 3 mod; > > Hi all, > > could you please review this small fix for run-test framework documentation? VM_OTIONS was used instead of VM_OPTIONS at several places, the fix is obvious s/VM_OTIONS/VM_OPTIONS/ . > > webrev: http://cr.openjdk.java.net/~iignatyev//8200180/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8200180 > > Thanks, > -- Igor > From magnus.ihse.bursie at oracle.com Fri Mar 23 15:30:57 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 16:30:57 +0100 Subject: RFR(XXS) : 8200180 : fix a typo in run-test framework documentation In-Reply-To: References: Message-ID: <6571124F-9127-42E5-A13C-D2F51D98911D@oracle.com> > 23 mars 2018 kl. 16:25 skrev Erik Joelsson : > > Hello Igor, > > This looks good, but please also run "make update-build-docs" so that the html file also gets regenerated before pushing. Looks good to me too. /Magnus > > /Erik > > >> On 2018-03-23 08:13, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8200180/webrev.00/index.html >>> 3 lines changed: 0 ins; 0 del; 3 mod; >> >> Hi all, >> >> could you please review this small fix for run-test framework documentation? VM_OTIONS was used instead of VM_OPTIONS at several places, the fix is obvious s/VM_OTIONS/VM_OPTIONS/ . >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8200180/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8200180 >> >> Thanks, >> -- Igor >> > From magnus.ihse.bursie at oracle.com Fri Mar 23 15:43:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 16:43:13 +0100 Subject: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h In-Reply-To: <52afd5ec-e136-b924-8127-d3e33bf04428@oracle.com> References: <7F114FA8-59F0-42F1-A0B8-33D8C22DE81A@oracle.com> <52afd5ec-e136-b924-8127-d3e33bf04428@oracle.com> Message-ID: This looks good to me. /Magnus > 23 mars 2018 kl. 14:58 skrev Erik Joelsson : > > I think this looks good, but Magnus is currently refactoring the flags handling in configure so better get his input as well. (adding build-dev) > > /Erik > > >> On 2018-03-23 05:37, Robin Westberg wrote: >> Hi Kim & Erik, >> >> Certainly makes sense to define it from the build system, I?ve updated the patch accordingly: >> >> Full: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/ >> Incremental: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/ >> >> (Not quite sure if the definition belongs where I put it or a bit later where most other windows-specific JVM flags are defined, but seemed reasonable to put it close to where it is defined for the JDK libraries). >> >> Best regards, >> Robin >> >>>>> On 22 Mar 2018, at 16:52, Kim Barrett > wrote: >>>> >>>> On Mar 22, 2018, at 10:34 AM, Robin Westberg > wrote: >>>> >>>> Hi all, >>>> >>>> Please review the following change that defines WIN32_LEAN_AND_MEAN [1] before including windows.h. This marginally improves build times, and makes it possible to include winsock2.h. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199736 >>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/ > >>>> Testing: hs-tier1 >>>> >>>> Best regards, >>>> Robin >>>> >>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745%28v=vs.85%29.aspx#faster_builds_with_smaller_header_files > >>> >>> I think the addition of the WIN32_LEAN_AND_MEAN definition should be done through the build >>> system, so that it applies everywhere. >>> >> > From magnus.ihse.bursie at oracle.com Fri Mar 23 15:58:19 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 16:58:19 +0100 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <4e165850-8bf5-baed-bb5d-4d5d0b6224f7@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> <20ff592c-bfd6-4430-f2a7-a08eb3241477@oracle.com> <4e165850-8bf5-baed-bb5d-4d5d0b6224f7@oracle.com> Message-ID: <94759ec3-2584-4c9d-d2eb-00f326196a50@oracle.com> On 2018-03-23 11:05, David Holmes wrote: > On 23/03/2018 7:54 PM, Magnus Ihse Bursie wrote: >> >> On 2018-03-23 09:55, David Holmes wrote: >>> On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote: >>>> >>>> On 2018-03-23 06:22, David Holmes wrote: >>>>> Hi Thomas, >>>>> >>>>> On 23/03/2018 2:55 PM, Thomas St?fe wrote: >>>>>> Hi David, >>>>>> >>>>>> would it not be pragmatic to accept Ao's patch - it looks fine to >>>>>> me - since it certainly would not make matters worse. And let >>>>>> Magnus follow up with a cleanup change later? >>>>> >>>>> Well I hope Magnus's change is forthcoming. >>>> It might be some time still. I'm working on a complete overhaul of >>>> all CFLAGS and LDFLAGS, where this is a part of that picture, but I >>>> was not planning on addressing just this thing urgently. >>>> >>>> So, I think this patch will do for now. It solves the immediate >>>> problem for MIPS, and I can come back and make a cleaner solution >>>> later on. >>> >>> Isn't the best quick fix one that only adds -m64 for x86? I recall? >>> a report that arm32 is similarly broken. >> Not really, because this is also needed on some other platforms, at >> least s390x, as I recall. (This was the reason it was originally added.) > > According to gcc docs there are 4 archs that use m64 and we only care > about 2 of them: > > m64: SPARC Options > m64: S/390 and zSeries Options > m64: RS/6000 and PowerPC Options > m64: i386 and x86-64 Options > Note that this logic also applies to the xlc compiler, not only gcc. I also believe that solstudio requires it on sparcv9, but I'm not 100% sure. > But you need to know whether you are dealing with S390 or S390x as m64 > implies zSeries. We only support s390x (64-bit), not s390. And OpenJDK still support ppc64, even if Oracle does not test it. So I'd say that we need -m64 on all those platforms listed. So then the question is, is it easier to check if it's one of four, or not one of tree known CPU architectures. (For mips, we shouldn't test OPENJDK_TARGET_CPU for a lot of mips*, but OPENJDK_TARGET_CPU_ARCH for mips). For me, it's like, whatever. I'll probably rewrite this from the ground up anywhat. What we're trying to express here is that some flags are needed as CFLAGS always, even when running configure checks. It has really nothing to do with the number of CPU bits. /Magnus > > Ao will need a sponsor to create a bug etc regardless of which way > this goes. > > My week is over. :) > > Cheers, > David > >> /Magnus >> >>> >>> David >>> ----- >>> >>>>> AFAICS it's as easy to write this only for x86 as it is to exclude >>>>> it for non x86. Honestly I don't know why the Aarch64 patch was >>>>> done the way it was - there must be some subtlety here that I'm >>>>> not aware of. >>>> I think it was just the smallest patch that worked for the aarch64 >>>> platform. I didn't spend time arguing about the fix, since it is >>>> supposed to be short-lived anyway. >>>> >>>> /Magnus >> From Alan.Bateman at oracle.com Fri Mar 23 16:04:12 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Mar 2018 16:04:12 +0000 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com> Message-ID: <810a6225-15af-6858-8bea-2c3122ac1c5d@oracle.com> On 23/03/2018 15:15, Magnus Ihse Bursie wrote: > : > Very much so, yes. I've found a lot of dubious exports, everything from global variables (yuck!) to functions that does not seem to be used anymore, to lots of strange exports. The changes looks good to me and I think we should follow this up with a few JIRA issues (as you suggested) for the symbols that don't make sense to export. -Alan From mandy.chung at oracle.com Fri Mar 23 16:05:23 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 23 Mar 2018 09:05:23 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> Message-ID: <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> This is a very good change and no more mapfile to maintain!! Please do file JBS issues for the component teams to clean up their exports. Mandy On 3/23/18 7:30 AM, Erik Joelsson wrote: > I have looked at the build changes and they look good. > > Will you file followups for each component team to look over their > exported symbols, at least for the libraries with > $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical debt > laying around here. > > /Erik > > > On 2018-03-23 06:56, Magnus Ihse Bursie wrote: >> With modern compilers, we can use compiler directives (such as >> _attribute__((visibility("default"))), or __declspec(dllexport)) to >> control symbol visibility, directly in the source code. This has >> historically not been present on all compilers, so we had to resort >> to using mapfiles (also known as linker scripts). >> >> This is no longer the case. Now all compilers we use support symbol >> visibility directives, in one form or another. We should start using >> this. Since this has been the only way to control symbol visibility >> on Windows, for most of the shared code, we already have proper >> JNIEXPORT decorations in place. >> >> If we fix the remaining platform-specific files to have proper >> JNIEXPORT tagging, then we can finally get rid of mapfiles. >> >> This fix removed mapfiles for all JDK libraries. It does not touch >> hotspot libraries nor JDK executables; they will have to wait for a >> future fix -- this was complex enough. This change will not have any >> impact on macosx, since we do not use mapfiles there, but instead >> export all symbols. (This is not a good idea, but I'll address that >> separately.) This change will also have a minimal impact on Windows. >> The only reason Windows is impacted at all, is that some changes >> needed by Solaris and Linux were simpler to fix for all platforms. >> >> I have strived for this change to have no impact on the actual >> generated code. Unfortunately, this was not possible to fully >> achieve. I do not believe that these changes will have any actual >> impact on the product, though. I will present the differences more in >> detail further down. Those who are not interested can probably skip >> that. >> >> The patch has passed tier1 testing and is currently running tier2 and >> tier3. Since the running code is more or less (see caveat below) >> unmodified, I don't expect any testing issues. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >> >> Details on changes: >> Most of the source code changes are (unsurprisingly) in java.base and >> java.desktop. Remaining changes are in jdk.crypto.ucrypto, >> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >> >> Source code changes does almost to 100% consists in decorating an >> exported function with JNIEXPORT. I have also followed the >> long-standing convention of adding JNICALL. This is a no-op on >> non-Windows platforms, so for most of the changes this is purely >> cosmetic (and possibly adding in robustness, should the function ever >> be used on Windows in the future). I have also followed the stylistic >> convention of putting "JNIEXPORT JNICALL" on a separate >> line. For some functions, however, this might cause a change in >> calling convention on Windows. Since this can not apply to exported >> functions on Windows (otherwise they would already have had >> JNIEXPORT), I do not think this matters anything. >> >> A few libraries did not have a mapfile, on Linux and/or Solaris. This >> actually meant that all symbols were exported. It is highly unclear >> if this was known and intended by the original make rule writer. I >> have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these >> libraries. Hopefully, we can remove this flag and fix proper exported >> symbols in the future. >> >> I have run the complete build using COMPARE_BUILD, and made a >> thourough analysis of the differences for Linux and Solaris. All >> native libraries have symbol differences, but most of them are >> trivial and/or harmless. As a result, most libraries have disasm >> differences as well, but these too seem trivial and harmless. The >> differences in symbols that are common to all libraries include: >> ?* Internal symbols such as __bss_start, _edata, _end and _fini are >> now global. (They are imported as such from the compiler >> libraries/archives, and we have no linker script to override this >> behavior). >> ?* The versioning tag SUNWprivate_1.1 is not included, and thus >> neither the .gnu.version_d symbol. >> ?* There are a few differences in the symbol and/or mangling of some >> local functions. I'm not sure what's causing this, >> but it's unlikely to have any effect on the product. >> >> Another common source for change in symbols is due to previous >> platform differences. For instance, if we had "JNIEXPORT int JNICALL >> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was >> exported on Windows but not on Linux and Solaris. (Presumable since >> it was not needed there, even though it was compiled for those >> platforms as well.) Now, with the mapfiles gone, do_foo() will be >> exported on all platforms. And contrary, functions that are compiled >> on all platforms, and were exported in mapfiles, but now have gotten >> an JNIEXPORT decoration, will now be visible even on Windows. (This >> accounts for half of the noticed symbol differences on Windows.) I >> could have made the JNIEXPORT conditional on OS, but I didn't think >> the mess in source code were worth the keeping of binary confidence >> with the old build. >> >> A third common source for change in symbols is due to exported >> functions "leaking" across library borders. For instance, some >> functions in java.desktop is compiled in both libawt_xawt and >> libawt_headless, but they were previously only included in the >> mapfile for one of these libraries. Now, since the visibility is >> determined by the source code itself, it gets exported in both >> libraries. A variant of this is when a library depends on another JDK >> library, and includes the header file from that other library, which >> in turn declares a function as JNIEXPORT. This will cause the >> including library to also export the function. This accounts for the >> other half of the changes on Windows. A typical example of this is >> that multiple libraries now re-export hotspot symbols from libjvm.so, >> like jio_fprintf. (I have not listed the libjvm re-exports below.) >> >> Note that? Java_java_io_FileOutputStream_close0 in >> java.base/unix/native/libjava/FileOutputStream_md.c is no longer >> exported, >> and can probably be removed. >> >> Here is a detailed table showing and accounting for all the remaining >> differences found on Linux and Solaris: >> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 >> is now also exported on unix platforms due to JNIEXPORT. >> >> java.base/jspawnlauncher: On solaris, we also include >> libjava/childproc.o, which >> now exports less functions than it used to (it used to export all >> functions, now it is compiled with visibility=hidden). >> >> java.base/java(w).exe: Is now also exporting the following symbols >> due to added JNIEXPORT in libjli on Windows: >> (Yes, executables can export symbols on Windows. Confusing, I know.) >> ?JLI_AddArgsFromEnvVar >> ?JLI_CmdToArgs >> ?JLI_GetAppArgIndex >> ?JLI_GetStdArgc >> ?JLI_GetStdArgs >> ?JLI_InitArgProcessing >> ?JLI_Launch >> ?JLI_List_add >> ?JLI_List_new >> ?JLI_ManifestIterate >> ?JLI_MemAlloc >> ?JLI_MemFree >> ?JLI_PreprocessArg >> ?JLI_ReportErrorMessage >> ?JLI_ReportErrorMessageSys >> ?JLI_ReportExceptionDescription >> ?JLI_ReportMessage >> ?JLI_SetTraceLauncher >> ?JLI_StringDup >> >> java.desktop:/libawt_xawt: The following symbols are now also >> exported on linux and solaris due to JNIEXPORT: >> ?awt_DrawingSurface_FreeDrawingSurfaceInfo >> ?awt_DrawingSurface_GetDrawingSurfaceInfo >> ?awt_DrawingSurface_Lock >> ?awt_DrawingSurface_Unlock >> ?awt_GetColor >> >> The following symbols are now also exported on linux and solaris due >> to JNIEXPORT (they were previously >> ?exported only in libawt): >> ?Java_sun_awt_DebugSettings_setCTracingOn__Z >> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >> ?Java_sun_awt_X11GraphicsConfig_getNumColors >> >> java.desktop:/libawt_headless: The following symbols are now also >> exported due to JNIEXPORT (they were previously >> ?exported only in libawt_xawt and/or libawt): >> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >> ?X11SurfaceData_GetOps >> >> java.desktop/libawt: The following symbols are now also exported on >> Windows, due to added >> JNIEXPORT: >> ?SurfaceData_InitOps >> ?mul8table >> ?div8table >> ?doDrawPath >> ?doFillPath >> ?g_CMpDataID >> ?initInverseGrayLut >> ?make_dither_arrays >> ?make_uns_ordered_dither_array >> ?path2DFloatCoordsID >> ?path2DNumTypesID >> ?path2DTypesID >> ?path2DWindingRuleID >> ?sg2dStrokeHintID >> ?std_img_oda_blue >> ?std_img_oda_green >> ?std_img_oda_red >> ?std_odas_computed >> ?sunHints_INTVAL_STROKE_PURE >> >> java.desktop/libawt on solaris: >> A number of "#pragma weak" directives was previously overridden by >> the mapfile. >> Now these directives are respected, so these symbols are now weak >> instead of local: >> ?ByteGrayToIntArgbPreConvert_F >> ?ByteGrayToIntArgbPreScaleConvert_F >> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F >> ?IntArgbToIntRgbXorBlit_F >> ?IntBgrToIntBgrAlphaMaskBlit_F >> >> java.desktop/libawt on solaris: These are now also exported due to >> JNIEXPORT in libmlib_image. >> ?j2d_mlib_ImageCreate >> ?j2d_mlib_ImageCreateStruct >> ?j2d_mlib_ImageDelete >> >> java.desktop/libawt on solaris: This is now also exported due to >> JNIEXPORT: >> ?GrPrim_CompGetXorColor >> ?SurfaceData_GetOpsNoSetup >> ?SurfaceData_IntersectBoundsXYWH >> ?SurfaceData_SetOps >> ?Transform_GetInfo >> ?Transform_transform >> >> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and >> solaris due to JNIEXPORT. >> libspashscreen also had JNIEXPORT (actually a pure >> _declspec(dllexport)) but no JNICALL, which I added as >> a part of converting to JNIEXPORT. The same goes for libmlib_image . >> >> jdk.sctp/libsctp: handleSocketError is now exported on linux and >> solaris due to JNIEXPORT in libnio. >> >> java.instrument:/libinstrument: Agent_OnUnload is now also exported >> on linux and solaris platforms due to JNIEXPORT. >> JLI_ManifestIterate is now also exported on Windows, due to added >> JNIEXPORT in libjli. >> >> jdk.management/libmanagement_ext: >> Java_com_sun_management_internal_Flag_setDoubleValue is now also >> exported on linux and solaris platforms due to JNIEXPORT. >> >> /Magnus >> >> > From magnus.ihse.bursie at oracle.com Fri Mar 23 16:07:55 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 17:07:55 +0100 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <5AB2DAB1.503@oracle.com> Message-ID: <9a99f67c-98ee-2daa-4c17-290496d3ab29@oracle.com> On 2018-03-22 16:13, Jonathan Gibbons wrote: > Magnus, > > There has always been a desire that most of JDK is free to use the > latest language and API features, meaning we must use the latest javac > to compile most most of JDK.?? That is where the "interim javac" comes > in. > > The interim JDK relies on javac and related tools being compilable by > the boot JDK.? This imposes a restriction that the source code of > those tools must be conformant to the source version supported by the > boot JDK, meaning no use of any newer features. The javac team have > always lived with and accepted the N-1 restriction that this imposes. > With a more rapid cadence, it might be appropriate to revisit the N-1 > rule. But since a "last LTS" rule may imply N-5 or N-6 or so, that > seems like too much. > > I note that this is not just an issue for javac source code.? If we > were currently on a "last LTS" rule, that implies JDK 8, which means > the build would still have to be bimodal and support both > (boot)classpath and modular builds. OK, that window is closing, but > the general point is that supporting older versions may affect more > than just the javac team. I would not propose a "last LTS" scheme, that seems far to infrequent to be reasonable. But maybe "N-2" might be an acceptable compromise? Just to be clear: As far as I understand, the balance to strike here is between: 1) on one hand, giving developers more time to adjust their build system to a newly available boot JDK. 2) on the other hand, allowing developers of javac access to new JDK features. In keeping with the N-1 rule, we are nominally doing the same thing, but practically shifting things towards 2). That might still be the right thing to do, but we will then need to acknowledge that this is what we're doing. Personally, I don't have any strong opinion either way. I agree with Erik's idea to keep the test matrix minimal, but on the other hand, there's a huge number of possible configurations to build OpenJDK on which is not regularly tested by Oracle's build system, and that works fine in most cases. If someone from the community needs it and it is broken, they can submit a patch. I could live with stating that "N-1" is officially supported and is guaranteed to work, but we will also support "N-2" but you'll have to test it yourself and submit bug fixes if it does not work. But if javac developers are seriously hindered in their effort to enhance Java due to this, then maybe developer convenience is not as important. /Magnus > > -- Jon > > > On 3/21/18 11:10 PM, Magnus Ihse Bursie wrote: >> Jon, >> >>> 21 mars 2018 kl. 23:20 skrev Jonathan Gibbons >>> : >>> >>> Holding javac and related tools back to the latest LTS would indeed >>> be somewhat onerous. >> Can we use the interim JDK build to get around this? Something like, >> if we can build a interim JDK with somewhat older tools, it can then >> be used to compile the javac proper? >> >> I can see that how with the increased release cadence, the >> assumptions behind the old N-1 scheme might not be valid anymore. >> >> /Magnus >> >>> -- Jon >>> >>>> On 03/21/2018 03:07 PM, Martin Buchholz wrote: >>>> Now that we are releasing jdks an order of magnitude faster than >>>> before, we >>>> should reconsider the N-1 boot jdk policy. >>>> >>>> The primary beneficiaries of this are compiler-dev, who might like >>>> to code >>>> using the very features they are implementing. >>>> >>>> But for users, being able to bootstrap with an ancient jdk is >>>> definitely >>>> convenient. >>>> >>>> A good compromise might be to be able to bootstrap with the most >>>> recent LTS >>>> release (jdk 8) but it might already be too late for that. >>>> >>>> On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson >>>> >>>> wrote: >>>> >>>>> Now that JDK 10 has been officially released we can update the >>>>> boot jdk >>>>> requirement for JDK 11. Cross posting this to jdk-dev to raise >>>>> awareness of >>>>> this rather disruptive change. >>>>> >>>>> This patch changes the requirement on boot jdk version in >>>>> configure (and >>>>> updates the configuration that controls what JDK to use as boot in >>>>> Oracle's >>>>> internal build system). >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 >>>>> >>>>> /Erik >>>>> >>>>> > From igor.ignatyev at oracle.com Fri Mar 23 16:10:42 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 23 Mar 2018 09:10:42 -0700 Subject: RFR(XXS) : 8200180 : fix a typo in run-test framework documentation In-Reply-To: <6571124F-9127-42E5-A13C-D2F51D98911D@oracle.com> References: <6571124F-9127-42E5-A13C-D2F51D98911D@oracle.com> Message-ID: Magnus, Erik, thanks for your review. -- Igor > On Mar 23, 2018, at 8:30 AM, Magnus Ihse Bursie wrote: > > >> 23 mars 2018 kl. 16:25 skrev Erik Joelsson : >> >> Hello Igor, >> >> This looks good, but please also run "make update-build-docs" so that the html file also gets regenerated before pushing. > > Looks good to me too. > > /Magnus > >> >> /Erik >> >> >>> On 2018-03-23 08:13, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8200180/webrev.00/index.html >>>> 3 lines changed: 0 ins; 0 del; 3 mod; >>> >>> Hi all, >>> >>> could you please review this small fix for run-test framework documentation? VM_OTIONS was used instead of VM_OPTIONS at several places, the fix is obvious s/VM_OTIONS/VM_OPTIONS/ . >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8200180/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8200180 >>> >>> Thanks, >>> -- Igor >>> >> > From joe.darcy at oracle.com Fri Mar 23 16:58:27 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 23 Mar 2018 09:58:27 -0700 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: <9a99f67c-98ee-2daa-4c17-290496d3ab29@oracle.com> References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <5AB2DAB1.503@oracle.com> <9a99f67c-98ee-2daa-4c17-290496d3ab29@oracle.com> Message-ID: In addition, the APIs in the java.compiler module are bootstrapped along with javac. Therefore, these APIs also have to abide by the same (N-k)? language feature policy as javac. If the bootstrap is older than necessary, maintenance of these APIs would be overly constrained. -Joe On 3/23/2018 9:07 AM, Magnus Ihse Bursie wrote: > On 2018-03-22 16:13, Jonathan Gibbons wrote: >> Magnus, >> >> There has always been a desire that most of JDK is free to use the >> latest language and API features, meaning we must use the latest >> javac to compile most most of JDK.?? That is where the "interim >> javac" comes in. >> >> The interim JDK relies on javac and related tools being compilable by >> the boot JDK.? This imposes a restriction that the source code of >> those tools must be conformant to the source version supported by the >> boot JDK, meaning no use of any newer features. The javac team have >> always lived with and accepted the N-1 restriction that this imposes. >> With a more rapid cadence, it might be appropriate to revisit the N-1 >> rule. But since a "last LTS" rule may imply N-5 or N-6 or so, that >> seems like too much. >> >> I note that this is not just an issue for javac source code.? If we >> were currently on a "last LTS" rule, that implies JDK 8, which means >> the build would still have to be bimodal and support both >> (boot)classpath and modular builds. OK, that window is closing, but >> the general point is that supporting older versions may affect more >> than just the javac team. > > I would not propose a "last LTS" scheme, that seems far to infrequent > to be reasonable. But maybe "N-2" might be an acceptable compromise? > > Just to be clear: As far as I understand, the balance to strike here > is between: > 1) on one hand, giving developers more time to adjust their build > system to a newly available boot JDK. > 2) on the other hand, allowing developers of javac access to new JDK > features. > > In keeping with the N-1 rule, we are nominally doing the same thing, > but practically shifting things towards 2). That might still be the > right thing to do, but we will then need to acknowledge that this is > what we're doing. > > Personally, I don't have any strong opinion either way. I agree with > Erik's idea to keep the test matrix minimal, but on the other hand, > there's a huge number of possible configurations to build OpenJDK on > which is not regularly tested by Oracle's build system, and that works > fine in most cases. If someone from the community needs it and it is > broken, they can submit a patch. I could live with stating that "N-1" > is officially supported and is guaranteed to work, but we will also > support "N-2" but you'll have to test it yourself and submit bug fixes > if it does not work. > > But if javac developers are seriously hindered in their effort to > enhance Java due to this, then maybe developer convenience is not as > important. > > /Magnus > > >> >> -- Jon >> >> >> On 3/21/18 11:10 PM, Magnus Ihse Bursie wrote: >>> Jon, >>> >>>> 21 mars 2018 kl. 23:20 skrev Jonathan Gibbons >>>> : >>>> >>>> Holding javac and related tools back to the latest LTS would indeed >>>> be somewhat onerous. >>> Can we use the interim JDK build to get around this? Something like, >>> if we can build a interim JDK with somewhat older tools, it can then >>> be used to compile the javac proper? >>> >>> I can see that how with the increased release cadence, the >>> assumptions behind the old N-1 scheme might not be valid anymore. >>> >>> /Magnus >>> >>>> -- Jon >>>> >>>>> On 03/21/2018 03:07 PM, Martin Buchholz wrote: >>>>> Now that we are releasing jdks an order of magnitude faster than >>>>> before, we >>>>> should reconsider the N-1 boot jdk policy. >>>>> >>>>> The primary beneficiaries of this are compiler-dev, who might like >>>>> to code >>>>> using the very features they are implementing. >>>>> >>>>> But for users, being able to bootstrap with an ancient jdk is >>>>> definitely >>>>> convenient. >>>>> >>>>> A good compromise might be to be able to bootstrap with the most >>>>> recent LTS >>>>> release (jdk 8) but it might already be too late for that. >>>>> >>>>> On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson >>>>> >>>>> wrote: >>>>> >>>>>> Now that JDK 10 has been officially released we can update the >>>>>> boot jdk >>>>>> requirement for JDK 11. Cross posting this to jdk-dev to raise >>>>>> awareness of >>>>>> this rather disruptive change. >>>>>> >>>>>> This patch changes the requirement on boot jdk version in >>>>>> configure (and >>>>>> updates the configuration that controls what JDK to use as boot >>>>>> in Oracle's >>>>>> internal build system). >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 >>>>>> >>>>>> /Erik >>>>>> >>>>>> >> > From volker.simonis at gmail.com Fri Mar 23 17:24:24 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 23 Mar 2018 18:24:24 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> Message-ID: Hi Magnus, thanks for addressing this long standing issue! I haven't looked at the changes, but just want to share some general and historical notes: - Compiling with "-fvisibility=hidden" which hides all symbols expect the ones explicitly exported with "__attribute__((visibility("default")))" has been requested by SAP back in 2007 even before we had OpenJDK (see "Use -fvisibility=hidden for gcc compiles" https://bugs.openjdk.java.net/browse/JDK-6588413) and finally pushed into the OpenJKD around 2010. - "-fvisibility=hidden" gave us performance improvements of about 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and 0,5% (JVM98) on Linux/PPC64 because the compiler could use faster calls for non exported symbols. This improvement was only very small on x86 tough. - "-fvisibility=hidden"/"__attribute__((visibility("default")))" applies BEFORE using the map files in the linking step (i.e. hidden symbols can't be exported any more even if mentioned in the map file) - because of the performance improvements we got by using "-fvisibility=hidden" it was worth while using it even though we had the mapfiles at the end of the process. Then we had several mail threads (which you probably remember because you were involved :) where we discussed to either remove the map files completely or instead generate them automatically during the build: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12412 http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12628 The main arguments against removing the map files at that time were: 1. the danger to re-export all symbols of statically linked libraries (notably libstdc++ at that time) 2. loosing exports of compiler generated symbols like vtables which are required by the Serviceability Agent Point 1 is not a problem today, because I don't think we do any static linking any more. If we still do it under some circumstances, this problem should be re-evaluated. Point 2 is only relevant for HotSpot. But because of "8034065: GCC 4.3 and later doesn't export vtable symbols any more which seem to be needed by SA" (https://bugs.openjdk.java.net/browse/JDK-8034065), exporting such symbols trough a map files doesn't work any more anyway. So this isn't a problem either. So to cut a long story short - I think the time is ripe to get rid of the map files. Thumbs up from me (meant as moral support, not as a concrete review :) Regards, Volker On Fri, Mar 23, 2018 at 5:05 PM, mandy chung wrote: > This is a very good change and no more mapfile to maintain!! > > Please do file JBS issues for the component teams to clean up their exports. > > Mandy > > > On 3/23/18 7:30 AM, Erik Joelsson wrote: >> >> I have looked at the build changes and they look good. >> >> Will you file followups for each component team to look over their >> exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It >> sure looks like there is some technical debt laying around here. >> >> /Erik >> >> >> On 2018-03-23 06:56, Magnus Ihse Bursie wrote: >>> >>> With modern compilers, we can use compiler directives (such as >>> _attribute__((visibility("default"))), or __declspec(dllexport)) to control >>> symbol visibility, directly in the source code. This has historically not >>> been present on all compilers, so we had to resort to using mapfiles (also >>> known as linker scripts). >>> >>> This is no longer the case. Now all compilers we use support symbol >>> visibility directives, in one form or another. We should start using this. >>> Since this has been the only way to control symbol visibility on Windows, >>> for most of the shared code, we already have proper JNIEXPORT decorations in >>> place. >>> >>> If we fix the remaining platform-specific files to have proper JNIEXPORT >>> tagging, then we can finally get rid of mapfiles. >>> >>> This fix removed mapfiles for all JDK libraries. It does not touch >>> hotspot libraries nor JDK executables; they will have to wait for a future >>> fix -- this was complex enough. This change will not have any impact on >>> macosx, since we do not use mapfiles there, but instead export all symbols. >>> (This is not a good idea, but I'll address that separately.) This change >>> will also have a minimal impact on Windows. The only reason Windows is >>> impacted at all, is that some changes needed by Solaris and Linux were >>> simpler to fix for all platforms. >>> >>> I have strived for this change to have no impact on the actual generated >>> code. Unfortunately, this was not possible to fully achieve. I do not >>> believe that these changes will have any actual impact on the product, >>> though. I will present the differences more in detail further down. Those >>> who are not interested can probably skip that. >>> >>> The patch has passed tier1 testing and is currently running tier2 and >>> tier3. Since the running code is more or less (see caveat below) unmodified, >>> I don't expect any testing issues. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >>> >>> Details on changes: >>> Most of the source code changes are (unsurprisingly) in java.base and >>> java.desktop. Remaining changes are in jdk.crypto.ucrypto, >>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >>> >>> Source code changes does almost to 100% consists in decorating an >>> exported function with JNIEXPORT. I have also followed the long-standing >>> convention of adding JNICALL. This is a no-op on non-Windows platforms, so >>> for most of the changes this is purely cosmetic (and possibly adding in >>> robustness, should the function ever be used on Windows in the future). I >>> have also followed the stylistic convention of putting "JNIEXPORT >> type> JNICALL" on a separate line. For some functions, however, this might >>> cause a change in calling convention on Windows. Since this can not apply to >>> exported functions on Windows (otherwise they would already have had >>> JNIEXPORT), I do not think this matters anything. >>> >>> A few libraries did not have a mapfile, on Linux and/or Solaris. This >>> actually meant that all symbols were exported. It is highly unclear if this >>> was known and intended by the original make rule writer. I have emulated >>> this by adding the flag $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, >>> we can remove this flag and fix proper exported symbols in the future. >>> >>> I have run the complete build using COMPARE_BUILD, and made a thourough >>> analysis of the differences for Linux and Solaris. All native libraries have >>> symbol differences, but most of them are trivial and/or harmless. As a >>> result, most libraries have disasm differences as well, but these too seem >>> trivial and harmless. The differences in symbols that are common to all >>> libraries include: >>> * Internal symbols such as __bss_start, _edata, _end and _fini are now >>> global. (They are imported as such from the compiler libraries/archives, and >>> we have no linker script to override this behavior). >>> * The versioning tag SUNWprivate_1.1 is not included, and thus neither >>> the .gnu.version_d symbol. >>> * There are a few differences in the symbol and/or mangling of some >>> local functions. I'm not sure what's causing this, >>> but it's unlikely to have any effect on the product. >>> >>> Another common source for change in symbols is due to previous platform >>> differences. For instance, if we had "JNIEXPORT int JNICALL do_foo() { ... >>> }", but do_foo was not in the mapfile, the symbol was exported on Windows >>> but not on Linux and Solaris. (Presumable since it was not needed there, >>> even though it was compiled for those platforms as well.) Now, with the >>> mapfiles gone, do_foo() will be exported on all platforms. And contrary, >>> functions that are compiled on all platforms, and were exported in mapfiles, >>> but now have gotten an JNIEXPORT decoration, will now be visible even on >>> Windows. (This accounts for half of the noticed symbol differences on >>> Windows.) I could have made the JNIEXPORT conditional on OS, but I didn't >>> think the mess in source code were worth the keeping of binary confidence >>> with the old build. >>> >>> A third common source for change in symbols is due to exported functions >>> "leaking" across library borders. For instance, some functions in >>> java.desktop is compiled in both libawt_xawt and libawt_headless, but they >>> were previously only included in the mapfile for one of these libraries. >>> Now, since the visibility is determined by the source code itself, it gets >>> exported in both libraries. A variant of this is when a library depends on >>> another JDK library, and includes the header file from that other library, >>> which in turn declares a function as JNIEXPORT. This will cause the >>> including library to also export the function. This accounts for the other >>> half of the changes on Windows. A typical example of this is that multiple >>> libraries now re-export hotspot symbols from libjvm.so, like jio_fprintf. (I >>> have not listed the libjvm re-exports below.) >>> >>> Note that Java_java_io_FileOutputStream_close0 in >>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer exported, >>> and can probably be removed. >>> >>> Here is a detailed table showing and accounting for all the remaining >>> differences found on Linux and Solaris: >>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is >>> now also exported on unix platforms due to JNIEXPORT. >>> >>> java.base/jspawnlauncher: On solaris, we also include >>> libjava/childproc.o, which >>> now exports less functions than it used to (it used to export all >>> functions, now it is compiled with visibility=hidden). >>> >>> java.base/java(w).exe: Is now also exporting the following symbols due to >>> added JNIEXPORT in libjli on Windows: >>> (Yes, executables can export symbols on Windows. Confusing, I know.) >>> JLI_AddArgsFromEnvVar >>> JLI_CmdToArgs >>> JLI_GetAppArgIndex >>> JLI_GetStdArgc >>> JLI_GetStdArgs >>> JLI_InitArgProcessing >>> JLI_Launch >>> JLI_List_add >>> JLI_List_new >>> JLI_ManifestIterate >>> JLI_MemAlloc >>> JLI_MemFree >>> JLI_PreprocessArg >>> JLI_ReportErrorMessage >>> JLI_ReportErrorMessageSys >>> JLI_ReportExceptionDescription >>> JLI_ReportMessage >>> JLI_SetTraceLauncher >>> JLI_StringDup >>> >>> java.desktop:/libawt_xawt: The following symbols are now also exported on >>> linux and solaris due to JNIEXPORT: >>> awt_DrawingSurface_FreeDrawingSurfaceInfo >>> awt_DrawingSurface_GetDrawingSurfaceInfo >>> awt_DrawingSurface_Lock >>> awt_DrawingSurface_Unlock >>> awt_GetColor >>> >>> The following symbols are now also exported on linux and solaris due to >>> JNIEXPORT (they were previously >>> exported only in libawt): >>> Java_sun_awt_DebugSettings_setCTracingOn__Z >>> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >>> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >>> Java_sun_awt_X11GraphicsConfig_getNumColors >>> >>> java.desktop:/libawt_headless: The following symbols are now also >>> exported due to JNIEXPORT (they were previously >>> exported only in libawt_xawt and/or libawt): >>> Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >>> Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >>> Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >>> Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >>> X11SurfaceData_GetOps >>> >>> java.desktop/libawt: The following symbols are now also exported on >>> Windows, due to added >>> JNIEXPORT: >>> SurfaceData_InitOps >>> mul8table >>> div8table >>> doDrawPath >>> doFillPath >>> g_CMpDataID >>> initInverseGrayLut >>> make_dither_arrays >>> make_uns_ordered_dither_array >>> path2DFloatCoordsID >>> path2DNumTypesID >>> path2DTypesID >>> path2DWindingRuleID >>> sg2dStrokeHintID >>> std_img_oda_blue >>> std_img_oda_green >>> std_img_oda_red >>> std_odas_computed >>> sunHints_INTVAL_STROKE_PURE >>> >>> java.desktop/libawt on solaris: >>> A number of "#pragma weak" directives was previously overridden by the >>> mapfile. >>> Now these directives are respected, so these symbols are now weak instead >>> of local: >>> ByteGrayToIntArgbPreConvert_F >>> ByteGrayToIntArgbPreScaleConvert_F >>> IntArgbBmToFourByteAbgrPreScaleXparOver_F >>> IntArgbToIntRgbXorBlit_F >>> IntBgrToIntBgrAlphaMaskBlit_F >>> >>> java.desktop/libawt on solaris: These are now also exported due to >>> JNIEXPORT in libmlib_image. >>> j2d_mlib_ImageCreate >>> j2d_mlib_ImageCreateStruct >>> j2d_mlib_ImageDelete >>> >>> java.desktop/libawt on solaris: This is now also exported due to >>> JNIEXPORT: >>> GrPrim_CompGetXorColor >>> SurfaceData_GetOpsNoSetup >>> SurfaceData_IntersectBoundsXYWH >>> SurfaceData_SetOps >>> Transform_GetInfo >>> Transform_transform >>> >>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and >>> solaris due to JNIEXPORT. >>> libspashscreen also had JNIEXPORT (actually a pure _declspec(dllexport)) >>> but no JNICALL, which I added as >>> a part of converting to JNIEXPORT. The same goes for libmlib_image . >>> >>> jdk.sctp/libsctp: handleSocketError is now exported on linux and solaris >>> due to JNIEXPORT in libnio. >>> >>> java.instrument:/libinstrument: Agent_OnUnload is now also exported on >>> linux and solaris platforms due to JNIEXPORT. >>> JLI_ManifestIterate is now also exported on Windows, due to added >>> JNIEXPORT in libjli. >>> >>> jdk.management/libmanagement_ext: >>> Java_com_sun_management_internal_Flag_setDoubleValue is now also exported on >>> linux and solaris platforms due to JNIEXPORT. >>> >>> /Magnus >>> >>> >> > From magnus.ihse.bursie at oracle.com Fri Mar 23 17:26:18 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 18:26:18 +0100 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <1521554055.3029.4.camel@gmail.com> References: <1521313360.26308.4.camel@gmail.com> <259e05b8-dbb1-4aa4-f451-6b7078eeb2ff@oracle.com> <1521554055.3029.4.camel@gmail.com> Message-ID: On 2018-03-20 14:54, Edward Nevill wrote: > On Tue, 2018-03-20 at 08:39 +0100, Erik Helin wrote: >> Please review the following webrev >>> Bugid: https://bugs.openjdk.java.net/browse/JDK-8199138 >>> Webrev: http://cr.openjdk.java.net/~enevill/8199138/webrev.00 >> 32 # First, filter out everything that doesn't begin with "aarch64-" >> 33 if ! echo $* | grep '^aarch64-\|^riscv64-' >/dev/null ; then >> >> Could you please update the comment on line 32 to say the same thing as >> the code? >> > Hi Eirk, > > Thanks for this. I have updated the webrev with the above comment. > > http://cr.openjdk.java.net/~enevill/8199138/webrev.01 I note that in platform.m4 (sorry I didn't say this earlier), you set the CPU_ARCH to riscv64 as well, and not just riscv. Now I don't know how likely it is that OpenJDK will ever support the 32-bit version of riscv, but it seems like it would make more sense to define the CPU_ARCH as "riscv", and the CPU as "riscv64". It's just a minor thing, if you like it the way it is, keep it. /Magnus > > I have also fixed a problem encountered with the submit-hs repo where the build machine had older headers which did not define EM_RISCV. > > The solution is to define EM_RISCV if not already defined as is done for aarch64. > > IE. > > #ifndef EM_AARCH64 > #define EM_AARCH64 183 /* ARM AARCH64 */ > #endif > +#ifndef EM_RISCV > + #define EM_RISCV 243 > +#endif > > This now passes the submit-hs tests. > > Does this look OK to push now? > > Thanks, > Ed. > From philip.race at oracle.com Fri Mar 23 17:33:55 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Mar 2018 10:33:55 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> Message-ID: <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> There are a lot of changes in the desktop libraries. Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those since only tier3 has any UI tests and it barely uses anything that's touched here. So since testing seems to be wise, then I think you should do a jtreg desktop group run on Linux & Windows. You can probably skip Mac since it is unaffected and I think Linux will cover Solaris here. You should also do some headless testing. It could take some time to review this properly and decide what changes are OK, what changes are something we should clean up later, and what changes are something that ought to be addressed now .. I think I'd be mainly concerned that something fails due to a missing symbol, or that for newly exported symbols if we ended up with duplicate symbols as a result. The results of a test run will add confidence here. BTW I don't think you are right that java.desktop:/libawt_headless: The following symbols are now also exported due to JNIEXPORT (they were previously .. X11SurfaceData_GetOps It looks to me like it was previously exported. -phil. On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote: > With modern compilers, we can use compiler directives (such as > _attribute__((visibility("default"))), or __declspec(dllexport)) to > control symbol visibility, directly in the source code. This has > historically not been present on all compilers, so we had to resort to > using mapfiles (also known as linker scripts). > > This is no longer the case. Now all compilers we use support symbol > visibility directives, in one form or another. We should start using > this. Since this has been the only way to control symbol visibility on > Windows, for most of the shared code, we already have proper JNIEXPORT > decorations in place. > > If we fix the remaining platform-specific files to have proper > JNIEXPORT tagging, then we can finally get rid of mapfiles. > > This fix removed mapfiles for all JDK libraries. It does not touch > hotspot libraries nor JDK executables; they will have to wait for a > future fix -- this was complex enough. This change will not have any > impact on macosx, since we do not use mapfiles there, but instead > export all symbols. (This is not a good idea, but I'll address that > separately.) This change will also have a minimal impact on Windows. > The only reason Windows is impacted at all, is that some changes > needed by Solaris and Linux were simpler to fix for all platforms. > > I have strived for this change to have no impact on the actual > generated code. Unfortunately, this was not possible to fully achieve. > I do not believe that these changes will have any actual impact on the > product, though. I will present the differences more in detail further > down. Those who are not interested can probably skip that. > > The patch has passed tier1 testing and is currently running tier2 and > tier3. Since the running code is more or less (see caveat below) > unmodified, I don't expect any testing issues. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 > > Details on changes: > Most of the source code changes are (unsurprisingly) in java.base and > java.desktop. Remaining changes are in jdk.crypto.ucrypto, > jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. > > Source code changes does almost to 100% consists in decorating an > exported function with JNIEXPORT. I have also followed the > long-standing convention of adding JNICALL. This is a no-op on > non-Windows platforms, so for most of the changes this is purely > cosmetic (and possibly adding in robustness, should the function ever > be used on Windows in the future). I have also followed the stylistic > convention of putting "JNIEXPORT JNICALL" on a separate > line. For some functions, however, this might cause a change in > calling convention on Windows. Since this can not apply to exported > functions on Windows (otherwise they would already have had > JNIEXPORT), I do not think this matters anything. > > A few libraries did not have a mapfile, on Linux and/or Solaris. This > actually meant that all symbols were exported. It is highly unclear if > this was known and intended by the original make rule writer. I have > emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these > libraries. Hopefully, we can remove this flag and fix proper exported > symbols in the future. > > I have run the complete build using COMPARE_BUILD, and made a > thourough analysis of the differences for Linux and Solaris. All > native libraries have symbol differences, but most of them are trivial > and/or harmless. As a result, most libraries have disasm differences > as well, but these too seem trivial and harmless. The differences in > symbols that are common to all libraries include: > * Internal symbols such as __bss_start, _edata, _end and _fini are > now global. (They are imported as such from the compiler > libraries/archives, and we have no linker script to override this > behavior). > * The versioning tag SUNWprivate_1.1 is not included, and thus > neither the .gnu.version_d symbol. > * There are a few differences in the symbol and/or mangling of some > local functions. I'm not sure what's causing this, > but it's unlikely to have any effect on the product. > > Another common source for change in symbols is due to previous > platform differences. For instance, if we had "JNIEXPORT int JNICALL > do_foo() { ... }", but do_foo was not in the mapfile, the symbol was > exported on Windows but not on Linux and Solaris. (Presumable since it > was not needed there, even though it was compiled for those platforms > as well.) Now, with the mapfiles gone, do_foo() will be exported on > all platforms. And contrary, functions that are compiled on all > platforms, and were exported in mapfiles, but now have gotten an > JNIEXPORT decoration, will now be visible even on Windows. (This > accounts for half of the noticed symbol differences on Windows.) I > could have made the JNIEXPORT conditional on OS, but I didn't think > the mess in source code were worth the keeping of binary confidence > with the old build. > > A third common source for change in symbols is due to exported > functions "leaking" across library borders. For instance, some > functions in java.desktop is compiled in both libawt_xawt and > libawt_headless, but they were previously only included in the mapfile > for one of these libraries. Now, since the visibility is determined by > the source code itself, it gets exported in both libraries. A variant > of this is when a library depends on another JDK library, and includes > the header file from that other library, which in turn declares a > function as JNIEXPORT. This will cause the including library to also > export the function. This accounts for the other half of the changes > on Windows. A typical example of this is that multiple libraries now > re-export hotspot symbols from libjvm.so, like jio_fprintf. (I have > not listed the libjvm re-exports below.) > > Note that Java_java_io_FileOutputStream_close0 in > java.base/unix/native/libjava/FileOutputStream_md.c is no longer > exported, > and can probably be removed. > > Here is a detailed table showing and accounting for all the remaining > differences found on Linux and Solaris: > java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is > now also exported on unix platforms due to JNIEXPORT. > > java.base/jspawnlauncher: On solaris, we also include > libjava/childproc.o, which > now exports less functions than it used to (it used to export all > functions, now it is compiled with visibility=hidden). > > java.base/java(w).exe: Is now also exporting the following symbols due > to added JNIEXPORT in libjli on Windows: > (Yes, executables can export symbols on Windows. Confusing, I know.) > JLI_AddArgsFromEnvVar > JLI_CmdToArgs > JLI_GetAppArgIndex > JLI_GetStdArgc > JLI_GetStdArgs > JLI_InitArgProcessing > JLI_Launch > JLI_List_add > JLI_List_new > JLI_ManifestIterate > JLI_MemAlloc > JLI_MemFree > JLI_PreprocessArg > JLI_ReportErrorMessage > JLI_ReportErrorMessageSys > JLI_ReportExceptionDescription > JLI_ReportMessage > JLI_SetTraceLauncher > JLI_StringDup > > java.desktop:/libawt_xawt: The following symbols are now also exported > on linux and solaris due to JNIEXPORT: > awt_DrawingSurface_FreeDrawingSurfaceInfo > awt_DrawingSurface_GetDrawingSurfaceInfo > awt_DrawingSurface_Lock > awt_DrawingSurface_Unlock > awt_GetColor > > The following symbols are now also exported on linux and solaris due > to JNIEXPORT (they were previously > exported only in libawt): > Java_sun_awt_DebugSettings_setCTracingOn__Z > Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 > Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I > Java_sun_awt_X11GraphicsConfig_getNumColors > > java.desktop:/libawt_headless: The following symbols are now also > exported due to JNIEXPORT (they were previously > exported only in libawt_xawt and/or libawt): > Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo > Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities > Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask > Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable > X11SurfaceData_GetOps > > java.desktop/libawt: The following symbols are now also exported on > Windows, due to added > JNIEXPORT: > SurfaceData_InitOps > mul8table > div8table > doDrawPath > doFillPath > g_CMpDataID > initInverseGrayLut > make_dither_arrays > make_uns_ordered_dither_array > path2DFloatCoordsID > path2DNumTypesID > path2DTypesID > path2DWindingRuleID > sg2dStrokeHintID > std_img_oda_blue > std_img_oda_green > std_img_oda_red > std_odas_computed > sunHints_INTVAL_STROKE_PURE > > java.desktop/libawt on solaris: > A number of "#pragma weak" directives was previously overridden by the > mapfile. > Now these directives are respected, so these symbols are now weak > instead of local: > ByteGrayToIntArgbPreConvert_F > ByteGrayToIntArgbPreScaleConvert_F > IntArgbBmToFourByteAbgrPreScaleXparOver_F > IntArgbToIntRgbXorBlit_F > IntBgrToIntBgrAlphaMaskBlit_F > > java.desktop/libawt on solaris: These are now also exported due to > JNIEXPORT in libmlib_image. > j2d_mlib_ImageCreate > j2d_mlib_ImageCreateStruct > j2d_mlib_ImageDelete > > java.desktop/libawt on solaris: This is now also exported due to > JNIEXPORT: > GrPrim_CompGetXorColor > SurfaceData_GetOpsNoSetup > SurfaceData_IntersectBoundsXYWH > SurfaceData_SetOps > Transform_GetInfo > Transform_transform > > java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and > solaris due to JNIEXPORT. > libspashscreen also had JNIEXPORT (actually a pure > _declspec(dllexport)) but no JNICALL, which I added as > a part of converting to JNIEXPORT. The same goes for libmlib_image . > > jdk.sctp/libsctp: handleSocketError is now exported on linux and > solaris due to JNIEXPORT in libnio. > > java.instrument:/libinstrument: Agent_OnUnload is now also exported on > linux and solaris platforms due to JNIEXPORT. > JLI_ManifestIterate is now also exported on Windows, due to added > JNIEXPORT in libjli. > > jdk.management/libmanagement_ext: > Java_com_sun_management_internal_Flag_setDoubleValue is now also > exported on linux and solaris platforms due to JNIEXPORT. > > /Magnus > > From philip.race at oracle.com Fri Mar 23 18:01:34 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Mar 2018 11:01:34 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> Message-ID: <96a6b8d6-d979-9cc9-6d51-7c6f0926bf97@oracle.com> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h.udiff.html The variable definitions here are now misaligned. ..and added 2d-dev since many of these native changes are in 2d. -phil. On 03/23/2018 10:33 AM, Phil Race wrote: > There are a lot of changes in the desktop libraries. > Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those > since > only tier3 has any UI tests and it barely uses anything that's touched > here. > So since testing seems to be wise, then I think you should do a > jtreg desktop group run on Linux & Windows. > You can probably skip Mac since it is unaffected and I think Linux > will cover Solaris here. > You should also do some headless testing. > > It could take some time to review this properly and decide what > changes are OK, > what changes are something we should clean up later, and what changes > are something > that ought to be addressed now .. > > I think I'd be mainly concerned that something fails due to a missing > symbol, or > that for newly exported symbols if we ended up with duplicate symbols > as a result. > > The results of a test run will add confidence here. > > BTW I don't think you are right that > java.desktop:/libawt_headless: The following symbols are now also > exported due to JNIEXPORT (they were previously > .. > X11SurfaceData_GetOps > > It looks to me like it was previously exported. > > > -phil. > > > > On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote: >> With modern compilers, we can use compiler directives (such as >> _attribute__((visibility("default"))), or __declspec(dllexport)) to >> control symbol visibility, directly in the source code. This has >> historically not been present on all compilers, so we had to resort >> to using mapfiles (also known as linker scripts). >> >> This is no longer the case. Now all compilers we use support symbol >> visibility directives, in one form or another. We should start using >> this. Since this has been the only way to control symbol visibility >> on Windows, for most of the shared code, we already have proper >> JNIEXPORT decorations in place. >> >> If we fix the remaining platform-specific files to have proper >> JNIEXPORT tagging, then we can finally get rid of mapfiles. >> >> This fix removed mapfiles for all JDK libraries. It does not touch >> hotspot libraries nor JDK executables; they will have to wait for a >> future fix -- this was complex enough. This change will not have any >> impact on macosx, since we do not use mapfiles there, but instead >> export all symbols. (This is not a good idea, but I'll address that >> separately.) This change will also have a minimal impact on Windows. >> The only reason Windows is impacted at all, is that some changes >> needed by Solaris and Linux were simpler to fix for all platforms. >> >> I have strived for this change to have no impact on the actual >> generated code. Unfortunately, this was not possible to fully >> achieve. I do not believe that these changes will have any actual >> impact on the product, though. I will present the differences more in >> detail further down. Those who are not interested can probably skip >> that. >> >> The patch has passed tier1 testing and is currently running tier2 and >> tier3. Since the running code is more or less (see caveat below) >> unmodified, I don't expect any testing issues. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >> >> Details on changes: >> Most of the source code changes are (unsurprisingly) in java.base and >> java.desktop. Remaining changes are in jdk.crypto.ucrypto, >> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >> >> Source code changes does almost to 100% consists in decorating an >> exported function with JNIEXPORT. I have also followed the >> long-standing convention of adding JNICALL. This is a no-op on >> non-Windows platforms, so for most of the changes this is purely >> cosmetic (and possibly adding in robustness, should the function ever >> be used on Windows in the future). I have also followed the stylistic >> convention of putting "JNIEXPORT JNICALL" on a separate >> line. For some functions, however, this might cause a change in >> calling convention on Windows. Since this can not apply to exported >> functions on Windows (otherwise they would already have had >> JNIEXPORT), I do not think this matters anything. >> >> A few libraries did not have a mapfile, on Linux and/or Solaris. This >> actually meant that all symbols were exported. It is highly unclear >> if this was known and intended by the original make rule writer. I >> have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these >> libraries. Hopefully, we can remove this flag and fix proper exported >> symbols in the future. >> >> I have run the complete build using COMPARE_BUILD, and made a >> thourough analysis of the differences for Linux and Solaris. All >> native libraries have symbol differences, but most of them are >> trivial and/or harmless. As a result, most libraries have disasm >> differences as well, but these too seem trivial and harmless. The >> differences in symbols that are common to all libraries include: >> * Internal symbols such as __bss_start, _edata, _end and _fini are >> now global. (They are imported as such from the compiler >> libraries/archives, and we have no linker script to override this >> behavior). >> * The versioning tag SUNWprivate_1.1 is not included, and thus >> neither the .gnu.version_d symbol. >> * There are a few differences in the symbol and/or mangling of some >> local functions. I'm not sure what's causing this, >> but it's unlikely to have any effect on the product. >> >> Another common source for change in symbols is due to previous >> platform differences. For instance, if we had "JNIEXPORT int JNICALL >> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was >> exported on Windows but not on Linux and Solaris. (Presumable since >> it was not needed there, even though it was compiled for those >> platforms as well.) Now, with the mapfiles gone, do_foo() will be >> exported on all platforms. And contrary, functions that are compiled >> on all platforms, and were exported in mapfiles, but now have gotten >> an JNIEXPORT decoration, will now be visible even on Windows. (This >> accounts for half of the noticed symbol differences on Windows.) I >> could have made the JNIEXPORT conditional on OS, but I didn't think >> the mess in source code were worth the keeping of binary confidence >> with the old build. >> >> A third common source for change in symbols is due to exported >> functions "leaking" across library borders. For instance, some >> functions in java.desktop is compiled in both libawt_xawt and >> libawt_headless, but they were previously only included in the >> mapfile for one of these libraries. Now, since the visibility is >> determined by the source code itself, it gets exported in both >> libraries. A variant of this is when a library depends on another JDK >> library, and includes the header file from that other library, which >> in turn declares a function as JNIEXPORT. This will cause the >> including library to also export the function. This accounts for the >> other half of the changes on Windows. A typical example of this is >> that multiple libraries now re-export hotspot symbols from libjvm.so, >> like jio_fprintf. (I have not listed the libjvm re-exports below.) >> >> Note that Java_java_io_FileOutputStream_close0 in >> java.base/unix/native/libjava/FileOutputStream_md.c is no longer >> exported, >> and can probably be removed. >> >> Here is a detailed table showing and accounting for all the remaining >> differences found on Linux and Solaris: >> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 >> is now also exported on unix platforms due to JNIEXPORT. >> >> java.base/jspawnlauncher: On solaris, we also include >> libjava/childproc.o, which >> now exports less functions than it used to (it used to export all >> functions, now it is compiled with visibility=hidden). >> >> java.base/java(w).exe: Is now also exporting the following symbols >> due to added JNIEXPORT in libjli on Windows: >> (Yes, executables can export symbols on Windows. Confusing, I know.) >> JLI_AddArgsFromEnvVar >> JLI_CmdToArgs >> JLI_GetAppArgIndex >> JLI_GetStdArgc >> JLI_GetStdArgs >> JLI_InitArgProcessing >> JLI_Launch >> JLI_List_add >> JLI_List_new >> JLI_ManifestIterate >> JLI_MemAlloc >> JLI_MemFree >> JLI_PreprocessArg >> JLI_ReportErrorMessage >> JLI_ReportErrorMessageSys >> JLI_ReportExceptionDescription >> JLI_ReportMessage >> JLI_SetTraceLauncher >> JLI_StringDup >> >> java.desktop:/libawt_xawt: The following symbols are now also >> exported on linux and solaris due to JNIEXPORT: >> awt_DrawingSurface_FreeDrawingSurfaceInfo >> awt_DrawingSurface_GetDrawingSurfaceInfo >> awt_DrawingSurface_Lock >> awt_DrawingSurface_Unlock >> awt_GetColor >> >> The following symbols are now also exported on linux and solaris due >> to JNIEXPORT (they were previously >> exported only in libawt): >> Java_sun_awt_DebugSettings_setCTracingOn__Z >> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >> Java_sun_awt_X11GraphicsConfig_getNumColors >> >> java.desktop:/libawt_headless: The following symbols are now also >> exported due to JNIEXPORT (they were previously >> exported only in libawt_xawt and/or libawt): >> Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >> Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >> Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >> Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >> X11SurfaceData_GetOps >> >> java.desktop/libawt: The following symbols are now also exported on >> Windows, due to added >> JNIEXPORT: >> SurfaceData_InitOps >> mul8table >> div8table >> doDrawPath >> doFillPath >> g_CMpDataID >> initInverseGrayLut >> make_dither_arrays >> make_uns_ordered_dither_array >> path2DFloatCoordsID >> path2DNumTypesID >> path2DTypesID >> path2DWindingRuleID >> sg2dStrokeHintID >> std_img_oda_blue >> std_img_oda_green >> std_img_oda_red >> std_odas_computed >> sunHints_INTVAL_STROKE_PURE >> >> java.desktop/libawt on solaris: >> A number of "#pragma weak" directives was previously overridden by >> the mapfile. >> Now these directives are respected, so these symbols are now weak >> instead of local: >> ByteGrayToIntArgbPreConvert_F >> ByteGrayToIntArgbPreScaleConvert_F >> IntArgbBmToFourByteAbgrPreScaleXparOver_F >> IntArgbToIntRgbXorBlit_F >> IntBgrToIntBgrAlphaMaskBlit_F >> >> java.desktop/libawt on solaris: These are now also exported due to >> JNIEXPORT in libmlib_image. >> j2d_mlib_ImageCreate >> j2d_mlib_ImageCreateStruct >> j2d_mlib_ImageDelete >> >> java.desktop/libawt on solaris: This is now also exported due to >> JNIEXPORT: >> GrPrim_CompGetXorColor >> SurfaceData_GetOpsNoSetup >> SurfaceData_IntersectBoundsXYWH >> SurfaceData_SetOps >> Transform_GetInfo >> Transform_transform >> >> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and >> solaris due to JNIEXPORT. >> libspashscreen also had JNIEXPORT (actually a pure >> _declspec(dllexport)) but no JNICALL, which I added as >> a part of converting to JNIEXPORT. The same goes for libmlib_image . >> >> jdk.sctp/libsctp: handleSocketError is now exported on linux and >> solaris due to JNIEXPORT in libnio. >> >> java.instrument:/libinstrument: Agent_OnUnload is now also exported >> on linux and solaris platforms due to JNIEXPORT. >> JLI_ManifestIterate is now also exported on Windows, due to added >> JNIEXPORT in libjli. >> >> jdk.management/libmanagement_ext: >> Java_com_sun_management_internal_Flag_setDoubleValue is now also >> exported on linux and solaris platforms due to JNIEXPORT. >> >> /Magnus >> >> > From martinrb at google.com Fri Mar 23 18:09:42 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 23 Mar 2018 11:09:42 -0700 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <5AB2DAB1.503@oracle.com> Message-ID: On Thu, Mar 22, 2018 at 8:13 AM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > The interim JDK relies on javac and related tools being compilable by the > boot JDK. This imposes a restriction that the source code of those tools > must be conformant to the source version supported by the boot JDK, meaning > no use of any newer features. The javac team have always lived with and > accepted the N-1 restriction that this imposes. With a more rapid cadence, > it might be appropriate to revisit the N-1 rule. But since a "last LTS" > rule may imply N-5 or N-6 or so, that seems like too much. > Historically, major java releases came out about once every 3 years, which aligns pretty well with a "last LTS" rule. Non-LTS releases such as jdk9 see cascading lack of support and hence lack of adoption - your OS vendor may be reluctant to ship such a jdk. From magnus.ihse.bursie at oracle.com Fri Mar 23 20:36:29 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 21:36:29 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <96a6b8d6-d979-9cc9-6d51-7c6f0926bf97@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> <96a6b8d6-d979-9cc9-6d51-7c6f0926bf97@oracle.com> Message-ID: <2db2ec37-b561-3f93-623b-14ddbc615381@oracle.com> On 2018-03-23 19:01, Phil Race wrote: > > http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h.udiff.html > > > The variable definitions here are now misaligned. No, they are not. That's just an artifact of webrev, which filters out whitespace changes in the diff view. :-( To see the proper changes, including whitespace, you need to download the patch file. I've gone to great pains to mimick the existing style in the source codes I've made changes to. /Magnus > > ..and added 2d-dev since many of these native changes are in 2d. > > -phil. > > On 03/23/2018 10:33 AM, Phil Race wrote: >> There are a lot of changes in the desktop libraries. >> Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those >> since >> only tier3 has any UI tests and it barely uses anything that's >> touched here. >> So since testing seems to be wise, then I think you should do a >> jtreg desktop group run on Linux & Windows. >> You can probably skip Mac since it is unaffected and I think Linux >> will cover Solaris here. >> You should also do some headless testing. >> >> It could take some time to review this properly and decide what >> changes are OK, >> what changes are something we should clean up later, and what changes >> are something >> that ought to be addressed now .. >> >> I think I'd be mainly concerned that something fails due to a missing >> symbol, or >> that for newly exported symbols if we ended up with duplicate symbols >> as a result. >> >> The results of a test run will add confidence here. >> >> BTW I don't think you are right that >> java.desktop:/libawt_headless: The following symbols are now also >> exported due to JNIEXPORT (they were previously >> .. >> ?X11SurfaceData_GetOps >> >> It looks to me like it was previously exported. >> >> >> -phil. >> >> >> >> On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote: >>> With modern compilers, we can use compiler directives (such as >>> _attribute__((visibility("default"))), or __declspec(dllexport)) to >>> control symbol visibility, directly in the source code. This has >>> historically not been present on all compilers, so we had to resort >>> to using mapfiles (also known as linker scripts). >>> >>> This is no longer the case. Now all compilers we use support symbol >>> visibility directives, in one form or another. We should start using >>> this. Since this has been the only way to control symbol visibility >>> on Windows, for most of the shared code, we already have proper >>> JNIEXPORT decorations in place. >>> >>> If we fix the remaining platform-specific files to have proper >>> JNIEXPORT tagging, then we can finally get rid of mapfiles. >>> >>> This fix removed mapfiles for all JDK libraries. It does not touch >>> hotspot libraries nor JDK executables; they will have to wait for a >>> future fix -- this was complex enough. This change will not have any >>> impact on macosx, since we do not use mapfiles there, but instead >>> export all symbols. (This is not a good idea, but I'll address that >>> separately.) This change will also have a minimal impact on Windows. >>> The only reason Windows is impacted at all, is that some changes >>> needed by Solaris and Linux were simpler to fix for all platforms. >>> >>> I have strived for this change to have no impact on the actual >>> generated code. Unfortunately, this was not possible to fully >>> achieve. I do not believe that these changes will have any actual >>> impact on the product, though. I will present the differences more >>> in detail further down. Those who are not interested can probably >>> skip that. >>> >>> The patch has passed tier1 testing and is currently running tier2 >>> and tier3. Since the running code is more or less (see caveat below) >>> unmodified, I don't expect any testing issues. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >>> >>> Details on changes: >>> Most of the source code changes are (unsurprisingly) in java.base >>> and java.desktop. Remaining changes are in jdk.crypto.ucrypto, >>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >>> >>> Source code changes does almost to 100% consists in decorating an >>> exported function with JNIEXPORT. I have also followed the >>> long-standing convention of adding JNICALL. This is a no-op on >>> non-Windows platforms, so for most of the changes this is purely >>> cosmetic (and possibly adding in robustness, should the function >>> ever be used on Windows in the future). I have also followed the >>> stylistic convention of putting "JNIEXPORT JNICALL" on >>> a separate line. For some functions, however, this might cause a >>> change in calling convention on Windows. Since this can not apply to >>> exported functions on Windows (otherwise they would already have had >>> JNIEXPORT), I do not think this matters anything. >>> >>> A few libraries did not have a mapfile, on Linux and/or Solaris. >>> This actually meant that all symbols were exported. It is highly >>> unclear if this was known and intended by the original make rule >>> writer. I have emulated this by adding the flag >>> $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, we can remove >>> this flag and fix proper exported symbols in the future. >>> >>> I have run the complete build using COMPARE_BUILD, and made a >>> thourough analysis of the differences for Linux and Solaris. All >>> native libraries have symbol differences, but most of them are >>> trivial and/or harmless. As a result, most libraries have disasm >>> differences as well, but these too seem trivial and harmless. The >>> differences in symbols that are common to all libraries include: >>> ?* Internal symbols such as __bss_start, _edata, _end and _fini are >>> now global. (They are imported as such from the compiler >>> libraries/archives, and we have no linker script to override this >>> behavior). >>> ?* The versioning tag SUNWprivate_1.1 is not included, and thus >>> neither the .gnu.version_d symbol. >>> ?* There are a few differences in the symbol and/or mangling of some >>> local functions. I'm not sure what's causing this, >>> but it's unlikely to have any effect on the product. >>> >>> Another common source for change in symbols is due to previous >>> platform differences. For instance, if we had "JNIEXPORT int JNICALL >>> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was >>> exported on Windows but not on Linux and Solaris. (Presumable since >>> it was not needed there, even though it was compiled for those >>> platforms as well.) Now, with the mapfiles gone, do_foo() will be >>> exported on all platforms. And contrary, functions that are compiled >>> on all platforms, and were exported in mapfiles, but now have gotten >>> an JNIEXPORT decoration, will now be visible even on Windows. (This >>> accounts for half of the noticed symbol differences on Windows.) I >>> could have made the JNIEXPORT conditional on OS, but I didn't think >>> the mess in source code were worth the keeping of binary confidence >>> with the old build. >>> >>> A third common source for change in symbols is due to exported >>> functions "leaking" across library borders. For instance, some >>> functions in java.desktop is compiled in both libawt_xawt and >>> libawt_headless, but they were previously only included in the >>> mapfile for one of these libraries. Now, since the visibility is >>> determined by the source code itself, it gets exported in both >>> libraries. A variant of this is when a library depends on another >>> JDK library, and includes the header file from that other library, >>> which in turn declares a function as JNIEXPORT. This will cause the >>> including library to also export the function. This accounts for the >>> other half of the changes on Windows. A typical example of this is >>> that multiple libraries now re-export hotspot symbols from >>> libjvm.so, like jio_fprintf. (I have not listed the libjvm >>> re-exports below.) >>> >>> Note that? Java_java_io_FileOutputStream_close0 in >>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer >>> exported, >>> and can probably be removed. >>> >>> Here is a detailed table showing and accounting for all the >>> remaining differences found on Linux and Solaris: >>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 >>> is now also exported on unix platforms due to JNIEXPORT. >>> >>> java.base/jspawnlauncher: On solaris, we also include >>> libjava/childproc.o, which >>> now exports less functions than it used to (it used to export all >>> functions, now it is compiled with visibility=hidden). >>> >>> java.base/java(w).exe: Is now also exporting the following symbols >>> due to added JNIEXPORT in libjli on Windows: >>> (Yes, executables can export symbols on Windows. Confusing, I know.) >>> ?JLI_AddArgsFromEnvVar >>> ?JLI_CmdToArgs >>> ?JLI_GetAppArgIndex >>> ?JLI_GetStdArgc >>> ?JLI_GetStdArgs >>> ?JLI_InitArgProcessing >>> ?JLI_Launch >>> ?JLI_List_add >>> ?JLI_List_new >>> ?JLI_ManifestIterate >>> ?JLI_MemAlloc >>> ?JLI_MemFree >>> ?JLI_PreprocessArg >>> ?JLI_ReportErrorMessage >>> ?JLI_ReportErrorMessageSys >>> ?JLI_ReportExceptionDescription >>> ?JLI_ReportMessage >>> ?JLI_SetTraceLauncher >>> ?JLI_StringDup >>> >>> java.desktop:/libawt_xawt: The following symbols are now also >>> exported on linux and solaris due to JNIEXPORT: >>> ?awt_DrawingSurface_FreeDrawingSurfaceInfo >>> ?awt_DrawingSurface_GetDrawingSurfaceInfo >>> ?awt_DrawingSurface_Lock >>> ?awt_DrawingSurface_Unlock >>> ?awt_GetColor >>> >>> The following symbols are now also exported on linux and solaris due >>> to JNIEXPORT (they were previously >>> ?exported only in libawt): >>> ?Java_sun_awt_DebugSettings_setCTracingOn__Z >>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >>> ?Java_sun_awt_X11GraphicsConfig_getNumColors >>> >>> java.desktop:/libawt_headless: The following symbols are now also >>> exported due to JNIEXPORT (they were previously >>> ?exported only in libawt_xawt and/or libawt): >>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >>> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >>> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >>> ?X11SurfaceData_GetOps >>> >>> java.desktop/libawt: The following symbols are now also exported on >>> Windows, due to added >>> JNIEXPORT: >>> ?SurfaceData_InitOps >>> ?mul8table >>> ?div8table >>> ?doDrawPath >>> ?doFillPath >>> ?g_CMpDataID >>> ?initInverseGrayLut >>> ?make_dither_arrays >>> ?make_uns_ordered_dither_array >>> ?path2DFloatCoordsID >>> ?path2DNumTypesID >>> ?path2DTypesID >>> ?path2DWindingRuleID >>> ?sg2dStrokeHintID >>> ?std_img_oda_blue >>> ?std_img_oda_green >>> ?std_img_oda_red >>> ?std_odas_computed >>> ?sunHints_INTVAL_STROKE_PURE >>> >>> java.desktop/libawt on solaris: >>> A number of "#pragma weak" directives was previously overridden by >>> the mapfile. >>> Now these directives are respected, so these symbols are now weak >>> instead of local: >>> ?ByteGrayToIntArgbPreConvert_F >>> ?ByteGrayToIntArgbPreScaleConvert_F >>> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F >>> ?IntArgbToIntRgbXorBlit_F >>> ?IntBgrToIntBgrAlphaMaskBlit_F >>> >>> java.desktop/libawt on solaris: These are now also exported due to >>> JNIEXPORT in libmlib_image. >>> ?j2d_mlib_ImageCreate >>> ?j2d_mlib_ImageCreateStruct >>> ?j2d_mlib_ImageDelete >>> >>> java.desktop/libawt on solaris: This is now also exported due to >>> JNIEXPORT: >>> ?GrPrim_CompGetXorColor >>> ?SurfaceData_GetOpsNoSetup >>> ?SurfaceData_IntersectBoundsXYWH >>> ?SurfaceData_SetOps >>> ?Transform_GetInfo >>> ?Transform_transform >>> >>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux >>> and solaris due to JNIEXPORT. >>> libspashscreen also had JNIEXPORT (actually a pure >>> _declspec(dllexport)) but no JNICALL, which I added as >>> a part of converting to JNIEXPORT. The same goes for libmlib_image . >>> >>> jdk.sctp/libsctp: handleSocketError is now exported on linux and >>> solaris due to JNIEXPORT in libnio. >>> >>> java.instrument:/libinstrument: Agent_OnUnload is now also exported >>> on linux and solaris platforms due to JNIEXPORT. >>> JLI_ManifestIterate is now also exported on Windows, due to added >>> JNIEXPORT in libjli. >>> >>> jdk.management/libmanagement_ext: >>> Java_com_sun_management_internal_Flag_setDoubleValue is now also >>> exported on linux and solaris platforms due to JNIEXPORT. >>> >>> /Magnus >>> >>> >> > From magnus.ihse.bursie at oracle.com Fri Mar 23 21:08:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 22:08:35 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <359e997c-6f49-218b-a1e6-81888135242b@oracle.com> Message-ID: On 2018-03-23 18:33, Phil Race wrote: > There are a lot of changes in the desktop libraries. Well, yes and no. While there are multiple touched files, the resulting native shared libraries that are built have very minimal changes in them. (That's the view point from the build guy, you know :)) > Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those > since > only tier3 has any UI tests and it barely uses anything that's touched > here. > So since testing seems to be wise, then I think you should do a > jtreg desktop group run on Linux & Windows. There is next to *no* difference for java.desktop on Windows. The only, very subtle, difference, is that awt.dll now exports 18 more functions (totalling 800, instead of 782). I can't even begin to imagine how anything could fail due to this additional exporting. Not even the disassembly of the machine code of awt.dll is different from before, not a single byte. So I don't buy it that I need to do extensive client testing on Windows. > You can probably skip Mac since it is unaffected and I think Linux > will cover Solaris here. > You should also do some headless testing. I agree that it seems prudent to do some Linux/Solaris testing, since changes there are more wide spread. Could you please point me to some guidance on how to run these tests? (You can do it off list) > It could take some time to review this properly and decide what > changes are OK, > what changes are something we should clean up later, and what changes > are something > that ought to be addressed now .. As I said, I am going to file follow-up bugs for suspicious handling of exported symbols. These follow-up bugs will be separated per component team, unlike this fix, which by necessity addresses all JDK libraries at once. So you will get plenty of time to consider ways of cleaning up any exports handling that you do not like. It would be a pity if this entire checkin was delayed since the client team could not accept the changes needed in client libraries. :-( And frankly, I believe the java.desktop libs needs some serious refactoring to get to grip with the exported symbols situation. The major cause of problems is, I believe, rooted in a non-optimal split of functionality between libawt, libawt_xawt and libawt_headless. This is not likely something that can be addressed in this change. > I think I'd be mainly concerned that something fails due to a missing > symbol, or > that for newly exported symbols if we ended up with duplicate symbols > as a result. Once again, I've run the COMPARE_BUILD script on this patch. Let me explain a bit more in detail what it does, since that might be known only to us in the build team. This script analyses the build result, the jmods, the lib*.so files, etc. The basic idea here is that a change in the build system, which does not produce a change in the build result, is "transparent" to the product. There is e.g. no reason to run any further testing, since we're in effect testing the same bits. For many changes in the build system, we hold this as the gold standard. For this particular change, to achieve this kind of fidelity would have come with a too high price in code complexity, so I have allowed certain small deviations. These are really minimal, and should in most cases be undetectable by the product. The changes in Linux and Solaris that have occured, is those that I listed in my review mail. Basically, for some libraries, additional symbols are exported. I could fix this, but only at the expense of more complex code. While it's a good thing to minimize the functions exported, a handful extra symbols is not a disaster. (We have more important issues to address in our native libraries.) For the AWT libraries, most of the duplicates are coming from the source code that are shared between libraries, in java.desktop/share/native/common. This means that the same function is compiled into -- and now also exported from -- multiple libraries. This is not a big deal. Even if we were to link with two libraries defining the same symbol, the dynamic linker will arbitrarily chose one of them, but since they are identical, it does not matter. (It's another thing if they implement different functions, as you noted yourself in the bugs about linking with awt_xawt vs doing a runtime linking to awt_headless). Also, I guarantee you that in no way are there missing symbols in the refactored build. I've checked, double-checked and triple-checked that. > The results of a test run will add confidence here. > > BTW I don't think you are right that > java.desktop:/libawt_headless: The following symbols are now also > exported due to JNIEXPORT (they were previously > .. > ?X11SurfaceData_GetOps > > It looks to me like it was previously exported. You are correct, it was previously exported in libawt_headless. I meant that it is now also exported for libawt_xawt due to the JNIEXPORT. Sorry for mixing this up. /Magnus > > > -phil. > > > > On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote: >> With modern compilers, we can use compiler directives (such as >> _attribute__((visibility("default"))), or __declspec(dllexport)) to >> control symbol visibility, directly in the source code. This has >> historically not been present on all compilers, so we had to resort >> to using mapfiles (also known as linker scripts). >> >> This is no longer the case. Now all compilers we use support symbol >> visibility directives, in one form or another. We should start using >> this. Since this has been the only way to control symbol visibility >> on Windows, for most of the shared code, we already have proper >> JNIEXPORT decorations in place. >> >> If we fix the remaining platform-specific files to have proper >> JNIEXPORT tagging, then we can finally get rid of mapfiles. >> >> This fix removed mapfiles for all JDK libraries. It does not touch >> hotspot libraries nor JDK executables; they will have to wait for a >> future fix -- this was complex enough. This change will not have any >> impact on macosx, since we do not use mapfiles there, but instead >> export all symbols. (This is not a good idea, but I'll address that >> separately.) This change will also have a minimal impact on Windows. >> The only reason Windows is impacted at all, is that some changes >> needed by Solaris and Linux were simpler to fix for all platforms. >> >> I have strived for this change to have no impact on the actual >> generated code. Unfortunately, this was not possible to fully >> achieve. I do not believe that these changes will have any actual >> impact on the product, though. I will present the differences more in >> detail further down. Those who are not interested can probably skip >> that. >> >> The patch has passed tier1 testing and is currently running tier2 and >> tier3. Since the running code is more or less (see caveat below) >> unmodified, I don't expect any testing issues. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >> >> Details on changes: >> Most of the source code changes are (unsurprisingly) in java.base and >> java.desktop. Remaining changes are in jdk.crypto.ucrypto, >> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >> >> Source code changes does almost to 100% consists in decorating an >> exported function with JNIEXPORT. I have also followed the >> long-standing convention of adding JNICALL. This is a no-op on >> non-Windows platforms, so for most of the changes this is purely >> cosmetic (and possibly adding in robustness, should the function ever >> be used on Windows in the future). I have also followed the stylistic >> convention of putting "JNIEXPORT JNICALL" on a separate >> line. For some functions, however, this might cause a change in >> calling convention on Windows. Since this can not apply to exported >> functions on Windows (otherwise they would already have had >> JNIEXPORT), I do not think this matters anything. >> >> A few libraries did not have a mapfile, on Linux and/or Solaris. This >> actually meant that all symbols were exported. It is highly unclear >> if this was known and intended by the original make rule writer. I >> have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these >> libraries. Hopefully, we can remove this flag and fix proper exported >> symbols in the future. >> >> I have run the complete build using COMPARE_BUILD, and made a >> thourough analysis of the differences for Linux and Solaris. All >> native libraries have symbol differences, but most of them are >> trivial and/or harmless. As a result, most libraries have disasm >> differences as well, but these too seem trivial and harmless. The >> differences in symbols that are common to all libraries include: >> ?* Internal symbols such as __bss_start, _edata, _end and _fini are >> now global. (They are imported as such from the compiler >> libraries/archives, and we have no linker script to override this >> behavior). >> ?* The versioning tag SUNWprivate_1.1 is not included, and thus >> neither the .gnu.version_d symbol. >> ?* There are a few differences in the symbol and/or mangling of some >> local functions. I'm not sure what's causing this, >> but it's unlikely to have any effect on the product. >> >> Another common source for change in symbols is due to previous >> platform differences. For instance, if we had "JNIEXPORT int JNICALL >> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was >> exported on Windows but not on Linux and Solaris. (Presumable since >> it was not needed there, even though it was compiled for those >> platforms as well.) Now, with the mapfiles gone, do_foo() will be >> exported on all platforms. And contrary, functions that are compiled >> on all platforms, and were exported in mapfiles, but now have gotten >> an JNIEXPORT decoration, will now be visible even on Windows. (This >> accounts for half of the noticed symbol differences on Windows.) I >> could have made the JNIEXPORT conditional on OS, but I didn't think >> the mess in source code were worth the keeping of binary confidence >> with the old build. >> >> A third common source for change in symbols is due to exported >> functions "leaking" across library borders. For instance, some >> functions in java.desktop is compiled in both libawt_xawt and >> libawt_headless, but they were previously only included in the >> mapfile for one of these libraries. Now, since the visibility is >> determined by the source code itself, it gets exported in both >> libraries. A variant of this is when a library depends on another JDK >> library, and includes the header file from that other library, which >> in turn declares a function as JNIEXPORT. This will cause the >> including library to also export the function. This accounts for the >> other half of the changes on Windows. A typical example of this is >> that multiple libraries now re-export hotspot symbols from libjvm.so, >> like jio_fprintf. (I have not listed the libjvm re-exports below.) >> >> Note that? Java_java_io_FileOutputStream_close0 in >> java.base/unix/native/libjava/FileOutputStream_md.c is no longer >> exported, >> and can probably be removed. >> >> Here is a detailed table showing and accounting for all the remaining >> differences found on Linux and Solaris: >> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 >> is now also exported on unix platforms due to JNIEXPORT. >> >> java.base/jspawnlauncher: On solaris, we also include >> libjava/childproc.o, which >> now exports less functions than it used to (it used to export all >> functions, now it is compiled with visibility=hidden). >> >> java.base/java(w).exe: Is now also exporting the following symbols >> due to added JNIEXPORT in libjli on Windows: >> (Yes, executables can export symbols on Windows. Confusing, I know.) >> ?JLI_AddArgsFromEnvVar >> ?JLI_CmdToArgs >> ?JLI_GetAppArgIndex >> ?JLI_GetStdArgc >> ?JLI_GetStdArgs >> ?JLI_InitArgProcessing >> ?JLI_Launch >> ?JLI_List_add >> ?JLI_List_new >> ?JLI_ManifestIterate >> ?JLI_MemAlloc >> ?JLI_MemFree >> ?JLI_PreprocessArg >> ?JLI_ReportErrorMessage >> ?JLI_ReportErrorMessageSys >> ?JLI_ReportExceptionDescription >> ?JLI_ReportMessage >> ?JLI_SetTraceLauncher >> ?JLI_StringDup >> >> java.desktop:/libawt_xawt: The following symbols are now also >> exported on linux and solaris due to JNIEXPORT: >> ?awt_DrawingSurface_FreeDrawingSurfaceInfo >> ?awt_DrawingSurface_GetDrawingSurfaceInfo >> ?awt_DrawingSurface_Lock >> ?awt_DrawingSurface_Unlock >> ?awt_GetColor >> >> The following symbols are now also exported on linux and solaris due >> to JNIEXPORT (they were previously >> ?exported only in libawt): >> ?Java_sun_awt_DebugSettings_setCTracingOn__Z >> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >> ?Java_sun_awt_X11GraphicsConfig_getNumColors >> >> java.desktop:/libawt_headless: The following symbols are now also >> exported due to JNIEXPORT (they were previously >> ?exported only in libawt_xawt and/or libawt): >> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >> ?X11SurfaceData_GetOps >> >> java.desktop/libawt: The following symbols are now also exported on >> Windows, due to added >> JNIEXPORT: >> ?SurfaceData_InitOps >> ?mul8table >> ?div8table >> ?doDrawPath >> ?doFillPath >> ?g_CMpDataID >> ?initInverseGrayLut >> ?make_dither_arrays >> ?make_uns_ordered_dither_array >> ?path2DFloatCoordsID >> ?path2DNumTypesID >> ?path2DTypesID >> ?path2DWindingRuleID >> ?sg2dStrokeHintID >> ?std_img_oda_blue >> ?std_img_oda_green >> ?std_img_oda_red >> ?std_odas_computed >> ?sunHints_INTVAL_STROKE_PURE >> >> java.desktop/libawt on solaris: >> A number of "#pragma weak" directives was previously overridden by >> the mapfile. >> Now these directives are respected, so these symbols are now weak >> instead of local: >> ?ByteGrayToIntArgbPreConvert_F >> ?ByteGrayToIntArgbPreScaleConvert_F >> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F >> ?IntArgbToIntRgbXorBlit_F >> ?IntBgrToIntBgrAlphaMaskBlit_F >> >> java.desktop/libawt on solaris: These are now also exported due to >> JNIEXPORT in libmlib_image. >> ?j2d_mlib_ImageCreate >> ?j2d_mlib_ImageCreateStruct >> ?j2d_mlib_ImageDelete >> >> java.desktop/libawt on solaris: This is now also exported due to >> JNIEXPORT: >> ?GrPrim_CompGetXorColor >> ?SurfaceData_GetOpsNoSetup >> ?SurfaceData_IntersectBoundsXYWH >> ?SurfaceData_SetOps >> ?Transform_GetInfo >> ?Transform_transform >> >> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and >> solaris due to JNIEXPORT. >> libspashscreen also had JNIEXPORT (actually a pure >> _declspec(dllexport)) but no JNICALL, which I added as >> a part of converting to JNIEXPORT. The same goes for libmlib_image . >> >> jdk.sctp/libsctp: handleSocketError is now exported on linux and >> solaris due to JNIEXPORT in libnio. >> >> java.instrument:/libinstrument: Agent_OnUnload is now also exported >> on linux and solaris platforms due to JNIEXPORT. >> JLI_ManifestIterate is now also exported on Windows, due to added >> JNIEXPORT in libjli. >> >> jdk.management/libmanagement_ext: >> Java_com_sun_management_internal_Flag_setDoubleValue is now also >> exported on linux and solaris platforms due to JNIEXPORT. >> >> /Magnus >> >> > From magnus.ihse.bursie at oracle.com Fri Mar 23 21:31:36 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 22:31:36 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> Message-ID: <278836b5-b49b-2409-f1b5-e05fdc0d2b30@oracle.com> On 2018-03-23 18:24, Volker Simonis wrote: > Hi Magnus, > > thanks for addressing this long standing issue! I haven't looked at > the changes, but just want to share some general and historical notes: > > - Compiling with "-fvisibility=hidden" which hides all symbols expect > the ones explicitly exported with > "__attribute__((visibility("default")))" has been requested by SAP > back in 2007 even before we had OpenJDK (see "Use -fvisibility=hidden > for gcc compiles" https://bugs.openjdk.java.net/browse/JDK-6588413) > and finally pushed into the OpenJKD around 2010. > - "-fvisibility=hidden" gave us performance improvements of about 5% > (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and 0,5% > (JVM98) on Linux/PPC64 because the compiler could use faster calls for > non exported symbols. This improvement was only very small on x86 > tough. That's a nice side effect! Although my main purpose here is maintainability, gaining performance is nothing I say no to. :) > - "-fvisibility=hidden"/"__attribute__((visibility("default")))" > applies BEFORE using the map files in the linking step (i.e. hidden > symbols can't be exported any more even if mentioned in the map file) > - because of the performance improvements we got by using > "-fvisibility=hidden" it was worth while using it even though we had > the mapfiles at the end of the process. > > Then we had several mail threads (which you probably remember because > you were involved :) where we discussed to either remove the map files > completely or instead generate them automatically during the build: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12412 > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12628 > > The main arguments against removing the map files at that time were: > > 1. the danger to re-export all symbols of statically linked libraries > (notably libstdc++ at that time) > 2. loosing exports of compiler generated symbols like vtables which > are required by the Serviceability Agent > > Point 1 is not a problem today, because I don't think we do any static > linking any more. If we still do it under some circumstances, this > problem should be re-evaluated. Well, we do static linking with libstdc++ on linux, in certain circumstances. See "--with-stdc++lib=,,". Fortunately, this is not a problem. The linker can be told not to include symbols from statically linked libraries, which is exactly what I do with LDFLAGS_JDKLIB += -Wl,--exclude-libs,ALL. The corresponding feature does not exist for the solstudio linker, but fortunately we do not use statically linked libraries there. > Point 2 is only relevant for HotSpot. But because of "8034065: GCC 4.3 > and later doesn't export vtable symbols any more which seem to be > needed by SA" (https://bugs.openjdk.java.net/browse/JDK-8034065), > exporting such symbols trough a map files doesn't work any more > anyway. So this isn't a problem either. In any case, that's a question for another day. :) There were reasons I left Hotspot out of this fix, and the question about the SA agent is one of them. :) As you say, I think they do not apply anymore, but I'll return to consider Hotspot later on. > So to cut a long story short - I think the time is ripe to get rid of > the map files. Thumbs up from me (meant as moral support, not as a > concrete review :) Thanks for the kind words! /Magnus > > Regards, > Volker > > On Fri, Mar 23, 2018 at 5:05 PM, mandy chung wrote: >> This is a very good change and no more mapfile to maintain!! >> >> Please do file JBS issues for the component teams to clean up their exports. >> >> Mandy >> >> >> On 3/23/18 7:30 AM, Erik Joelsson wrote: >>> I have looked at the build changes and they look good. >>> >>> Will you file followups for each component team to look over their >>> exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It >>> sure looks like there is some technical debt laying around here. >>> >>> /Erik >>> >>> >>> On 2018-03-23 06:56, Magnus Ihse Bursie wrote: >>>> With modern compilers, we can use compiler directives (such as >>>> _attribute__((visibility("default"))), or __declspec(dllexport)) to control >>>> symbol visibility, directly in the source code. This has historically not >>>> been present on all compilers, so we had to resort to using mapfiles (also >>>> known as linker scripts). >>>> >>>> This is no longer the case. Now all compilers we use support symbol >>>> visibility directives, in one form or another. We should start using this. >>>> Since this has been the only way to control symbol visibility on Windows, >>>> for most of the shared code, we already have proper JNIEXPORT decorations in >>>> place. >>>> >>>> If we fix the remaining platform-specific files to have proper JNIEXPORT >>>> tagging, then we can finally get rid of mapfiles. >>>> >>>> This fix removed mapfiles for all JDK libraries. It does not touch >>>> hotspot libraries nor JDK executables; they will have to wait for a future >>>> fix -- this was complex enough. This change will not have any impact on >>>> macosx, since we do not use mapfiles there, but instead export all symbols. >>>> (This is not a good idea, but I'll address that separately.) This change >>>> will also have a minimal impact on Windows. The only reason Windows is >>>> impacted at all, is that some changes needed by Solaris and Linux were >>>> simpler to fix for all platforms. >>>> >>>> I have strived for this change to have no impact on the actual generated >>>> code. Unfortunately, this was not possible to fully achieve. I do not >>>> believe that these changes will have any actual impact on the product, >>>> though. I will present the differences more in detail further down. Those >>>> who are not interested can probably skip that. >>>> >>>> The patch has passed tier1 testing and is currently running tier2 and >>>> tier3. Since the running code is more or less (see caveat below) unmodified, >>>> I don't expect any testing issues. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >>>> >>>> Details on changes: >>>> Most of the source code changes are (unsurprisingly) in java.base and >>>> java.desktop. Remaining changes are in jdk.crypto.ucrypto, >>>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >>>> >>>> Source code changes does almost to 100% consists in decorating an >>>> exported function with JNIEXPORT. I have also followed the long-standing >>>> convention of adding JNICALL. This is a no-op on non-Windows platforms, so >>>> for most of the changes this is purely cosmetic (and possibly adding in >>>> robustness, should the function ever be used on Windows in the future). I >>>> have also followed the stylistic convention of putting "JNIEXPORT >>> type> JNICALL" on a separate line. For some functions, however, this might >>>> cause a change in calling convention on Windows. Since this can not apply to >>>> exported functions on Windows (otherwise they would already have had >>>> JNIEXPORT), I do not think this matters anything. >>>> >>>> A few libraries did not have a mapfile, on Linux and/or Solaris. This >>>> actually meant that all symbols were exported. It is highly unclear if this >>>> was known and intended by the original make rule writer. I have emulated >>>> this by adding the flag $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, >>>> we can remove this flag and fix proper exported symbols in the future. >>>> >>>> I have run the complete build using COMPARE_BUILD, and made a thourough >>>> analysis of the differences for Linux and Solaris. All native libraries have >>>> symbol differences, but most of them are trivial and/or harmless. As a >>>> result, most libraries have disasm differences as well, but these too seem >>>> trivial and harmless. The differences in symbols that are common to all >>>> libraries include: >>>> * Internal symbols such as __bss_start, _edata, _end and _fini are now >>>> global. (They are imported as such from the compiler libraries/archives, and >>>> we have no linker script to override this behavior). >>>> * The versioning tag SUNWprivate_1.1 is not included, and thus neither >>>> the .gnu.version_d symbol. >>>> * There are a few differences in the symbol and/or mangling of some >>>> local functions. I'm not sure what's causing this, >>>> but it's unlikely to have any effect on the product. >>>> >>>> Another common source for change in symbols is due to previous platform >>>> differences. For instance, if we had "JNIEXPORT int JNICALL do_foo() { ... >>>> }", but do_foo was not in the mapfile, the symbol was exported on Windows >>>> but not on Linux and Solaris. (Presumable since it was not needed there, >>>> even though it was compiled for those platforms as well.) Now, with the >>>> mapfiles gone, do_foo() will be exported on all platforms. And contrary, >>>> functions that are compiled on all platforms, and were exported in mapfiles, >>>> but now have gotten an JNIEXPORT decoration, will now be visible even on >>>> Windows. (This accounts for half of the noticed symbol differences on >>>> Windows.) I could have made the JNIEXPORT conditional on OS, but I didn't >>>> think the mess in source code were worth the keeping of binary confidence >>>> with the old build. >>>> >>>> A third common source for change in symbols is due to exported functions >>>> "leaking" across library borders. For instance, some functions in >>>> java.desktop is compiled in both libawt_xawt and libawt_headless, but they >>>> were previously only included in the mapfile for one of these libraries. >>>> Now, since the visibility is determined by the source code itself, it gets >>>> exported in both libraries. A variant of this is when a library depends on >>>> another JDK library, and includes the header file from that other library, >>>> which in turn declares a function as JNIEXPORT. This will cause the >>>> including library to also export the function. This accounts for the other >>>> half of the changes on Windows. A typical example of this is that multiple >>>> libraries now re-export hotspot symbols from libjvm.so, like jio_fprintf. (I >>>> have not listed the libjvm re-exports below.) >>>> >>>> Note that Java_java_io_FileOutputStream_close0 in >>>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer exported, >>>> and can probably be removed. >>>> >>>> Here is a detailed table showing and accounting for all the remaining >>>> differences found on Linux and Solaris: >>>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is >>>> now also exported on unix platforms due to JNIEXPORT. >>>> >>>> java.base/jspawnlauncher: On solaris, we also include >>>> libjava/childproc.o, which >>>> now exports less functions than it used to (it used to export all >>>> functions, now it is compiled with visibility=hidden). >>>> >>>> java.base/java(w).exe: Is now also exporting the following symbols due to >>>> added JNIEXPORT in libjli on Windows: >>>> (Yes, executables can export symbols on Windows. Confusing, I know.) >>>> JLI_AddArgsFromEnvVar >>>> JLI_CmdToArgs >>>> JLI_GetAppArgIndex >>>> JLI_GetStdArgc >>>> JLI_GetStdArgs >>>> JLI_InitArgProcessing >>>> JLI_Launch >>>> JLI_List_add >>>> JLI_List_new >>>> JLI_ManifestIterate >>>> JLI_MemAlloc >>>> JLI_MemFree >>>> JLI_PreprocessArg >>>> JLI_ReportErrorMessage >>>> JLI_ReportErrorMessageSys >>>> JLI_ReportExceptionDescription >>>> JLI_ReportMessage >>>> JLI_SetTraceLauncher >>>> JLI_StringDup >>>> >>>> java.desktop:/libawt_xawt: The following symbols are now also exported on >>>> linux and solaris due to JNIEXPORT: >>>> awt_DrawingSurface_FreeDrawingSurfaceInfo >>>> awt_DrawingSurface_GetDrawingSurfaceInfo >>>> awt_DrawingSurface_Lock >>>> awt_DrawingSurface_Unlock >>>> awt_GetColor >>>> >>>> The following symbols are now also exported on linux and solaris due to >>>> JNIEXPORT (they were previously >>>> exported only in libawt): >>>> Java_sun_awt_DebugSettings_setCTracingOn__Z >>>> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >>>> Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >>>> Java_sun_awt_X11GraphicsConfig_getNumColors >>>> >>>> java.desktop:/libawt_headless: The following symbols are now also >>>> exported due to JNIEXPORT (they were previously >>>> exported only in libawt_xawt and/or libawt): >>>> Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >>>> Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >>>> Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >>>> Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >>>> X11SurfaceData_GetOps >>>> >>>> java.desktop/libawt: The following symbols are now also exported on >>>> Windows, due to added >>>> JNIEXPORT: >>>> SurfaceData_InitOps >>>> mul8table >>>> div8table >>>> doDrawPath >>>> doFillPath >>>> g_CMpDataID >>>> initInverseGrayLut >>>> make_dither_arrays >>>> make_uns_ordered_dither_array >>>> path2DFloatCoordsID >>>> path2DNumTypesID >>>> path2DTypesID >>>> path2DWindingRuleID >>>> sg2dStrokeHintID >>>> std_img_oda_blue >>>> std_img_oda_green >>>> std_img_oda_red >>>> std_odas_computed >>>> sunHints_INTVAL_STROKE_PURE >>>> >>>> java.desktop/libawt on solaris: >>>> A number of "#pragma weak" directives was previously overridden by the >>>> mapfile. >>>> Now these directives are respected, so these symbols are now weak instead >>>> of local: >>>> ByteGrayToIntArgbPreConvert_F >>>> ByteGrayToIntArgbPreScaleConvert_F >>>> IntArgbBmToFourByteAbgrPreScaleXparOver_F >>>> IntArgbToIntRgbXorBlit_F >>>> IntBgrToIntBgrAlphaMaskBlit_F >>>> >>>> java.desktop/libawt on solaris: These are now also exported due to >>>> JNIEXPORT in libmlib_image. >>>> j2d_mlib_ImageCreate >>>> j2d_mlib_ImageCreateStruct >>>> j2d_mlib_ImageDelete >>>> >>>> java.desktop/libawt on solaris: This is now also exported due to >>>> JNIEXPORT: >>>> GrPrim_CompGetXorColor >>>> SurfaceData_GetOpsNoSetup >>>> SurfaceData_IntersectBoundsXYWH >>>> SurfaceData_SetOps >>>> Transform_GetInfo >>>> Transform_transform >>>> >>>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and >>>> solaris due to JNIEXPORT. >>>> libspashscreen also had JNIEXPORT (actually a pure _declspec(dllexport)) >>>> but no JNICALL, which I added as >>>> a part of converting to JNIEXPORT. The same goes for libmlib_image . >>>> >>>> jdk.sctp/libsctp: handleSocketError is now exported on linux and solaris >>>> due to JNIEXPORT in libnio. >>>> >>>> java.instrument:/libinstrument: Agent_OnUnload is now also exported on >>>> linux and solaris platforms due to JNIEXPORT. >>>> JLI_ManifestIterate is now also exported on Windows, due to added >>>> JNIEXPORT in libjli. >>>> >>>> jdk.management/libmanagement_ext: >>>> Java_com_sun_management_internal_Flag_setDoubleValue is now also exported on >>>> linux and solaris platforms due to JNIEXPORT. >>>> >>>> /Magnus >>>> >>>> From magnus.ihse.bursie at oracle.com Fri Mar 23 22:03:59 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Mar 2018 23:03:59 +0100 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> Message-ID: <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com> On 2018-03-23 17:05, mandy chung wrote: > This is a very good change and no more mapfile to maintain!! Thank you! > > Please do file JBS issues for the component teams to clean up their > exports. I have now filed: https://bugs.openjdk.java.net/browse/JDK-8200191 -- for java.base https://bugs.openjdk.java.net/browse/JDK-8200192 -- for java.desktop https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth /Magnus > > Mandy > > On 3/23/18 7:30 AM, Erik Joelsson wrote: >> I have looked at the build changes and they look good. >> >> Will you file followups for each component team to look over their >> exported symbols, at least for the libraries with >> $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical >> debt laying around here. >> >> /Erik >> >> >> On 2018-03-23 06:56, Magnus Ihse Bursie wrote: >>> With modern compilers, we can use compiler directives (such as >>> _attribute__((visibility("default"))), or __declspec(dllexport)) to >>> control symbol visibility, directly in the source code. This has >>> historically not been present on all compilers, so we had to resort >>> to using mapfiles (also known as linker scripts). >>> >>> This is no longer the case. Now all compilers we use support symbol >>> visibility directives, in one form or another. We should start using >>> this. Since this has been the only way to control symbol visibility >>> on Windows, for most of the shared code, we already have proper >>> JNIEXPORT decorations in place. >>> >>> If we fix the remaining platform-specific files to have proper >>> JNIEXPORT tagging, then we can finally get rid of mapfiles. >>> >>> This fix removed mapfiles for all JDK libraries. It does not touch >>> hotspot libraries nor JDK executables; they will have to wait for a >>> future fix -- this was complex enough. This change will not have any >>> impact on macosx, since we do not use mapfiles there, but instead >>> export all symbols. (This is not a good idea, but I'll address that >>> separately.) This change will also have a minimal impact on Windows. >>> The only reason Windows is impacted at all, is that some changes >>> needed by Solaris and Linux were simpler to fix for all platforms. >>> >>> I have strived for this change to have no impact on the actual >>> generated code. Unfortunately, this was not possible to fully >>> achieve. I do not believe that these changes will have any actual >>> impact on the product, though. I will present the differences more >>> in detail further down. Those who are not interested can probably >>> skip that. >>> >>> The patch has passed tier1 testing and is currently running tier2 >>> and tier3. Since the running code is more or less (see caveat below) >>> unmodified, I don't expect any testing issues. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01 >>> >>> Details on changes: >>> Most of the source code changes are (unsurprisingly) in java.base >>> and java.desktop. Remaining changes are in jdk.crypto.ucrypto, >>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent. >>> >>> Source code changes does almost to 100% consists in decorating an >>> exported function with JNIEXPORT. I have also followed the >>> long-standing convention of adding JNICALL. This is a no-op on >>> non-Windows platforms, so for most of the changes this is purely >>> cosmetic (and possibly adding in robustness, should the function >>> ever be used on Windows in the future). I have also followed the >>> stylistic convention of putting "JNIEXPORT JNICALL" on >>> a separate line. For some functions, however, this might cause a >>> change in calling convention on Windows. Since this can not apply to >>> exported functions on Windows (otherwise they would already have had >>> JNIEXPORT), I do not think this matters anything. >>> >>> A few libraries did not have a mapfile, on Linux and/or Solaris. >>> This actually meant that all symbols were exported. It is highly >>> unclear if this was known and intended by the original make rule >>> writer. I have emulated this by adding the flag >>> $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, we can remove >>> this flag and fix proper exported symbols in the future. >>> >>> I have run the complete build using COMPARE_BUILD, and made a >>> thourough analysis of the differences for Linux and Solaris. All >>> native libraries have symbol differences, but most of them are >>> trivial and/or harmless. As a result, most libraries have disasm >>> differences as well, but these too seem trivial and harmless. The >>> differences in symbols that are common to all libraries include: >>> ?* Internal symbols such as __bss_start, _edata, _end and _fini are >>> now global. (They are imported as such from the compiler >>> libraries/archives, and we have no linker script to override this >>> behavior). >>> ?* The versioning tag SUNWprivate_1.1 is not included, and thus >>> neither the .gnu.version_d symbol. >>> ?* There are a few differences in the symbol and/or mangling of some >>> local functions. I'm not sure what's causing this, >>> but it's unlikely to have any effect on the product. >>> >>> Another common source for change in symbols is due to previous >>> platform differences. For instance, if we had "JNIEXPORT int JNICALL >>> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was >>> exported on Windows but not on Linux and Solaris. (Presumable since >>> it was not needed there, even though it was compiled for those >>> platforms as well.) Now, with the mapfiles gone, do_foo() will be >>> exported on all platforms. And contrary, functions that are compiled >>> on all platforms, and were exported in mapfiles, but now have gotten >>> an JNIEXPORT decoration, will now be visible even on Windows. (This >>> accounts for half of the noticed symbol differences on Windows.) I >>> could have made the JNIEXPORT conditional on OS, but I didn't think >>> the mess in source code were worth the keeping of binary confidence >>> with the old build. >>> >>> A third common source for change in symbols is due to exported >>> functions "leaking" across library borders. For instance, some >>> functions in java.desktop is compiled in both libawt_xawt and >>> libawt_headless, but they were previously only included in the >>> mapfile for one of these libraries. Now, since the visibility is >>> determined by the source code itself, it gets exported in both >>> libraries. A variant of this is when a library depends on another >>> JDK library, and includes the header file from that other library, >>> which in turn declares a function as JNIEXPORT. This will cause the >>> including library to also export the function. This accounts for the >>> other half of the changes on Windows. A typical example of this is >>> that multiple libraries now re-export hotspot symbols from >>> libjvm.so, like jio_fprintf. (I have not listed the libjvm >>> re-exports below.) >>> >>> Note that? Java_java_io_FileOutputStream_close0 in >>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer >>> exported, >>> and can probably be removed. >>> >>> Here is a detailed table showing and accounting for all the >>> remaining differences found on Linux and Solaris: >>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 >>> is now also exported on unix platforms due to JNIEXPORT. >>> >>> java.base/jspawnlauncher: On solaris, we also include >>> libjava/childproc.o, which >>> now exports less functions than it used to (it used to export all >>> functions, now it is compiled with visibility=hidden). >>> >>> java.base/java(w).exe: Is now also exporting the following symbols >>> due to added JNIEXPORT in libjli on Windows: >>> (Yes, executables can export symbols on Windows. Confusing, I know.) >>> ?JLI_AddArgsFromEnvVar >>> ?JLI_CmdToArgs >>> ?JLI_GetAppArgIndex >>> ?JLI_GetStdArgc >>> ?JLI_GetStdArgs >>> ?JLI_InitArgProcessing >>> ?JLI_Launch >>> ?JLI_List_add >>> ?JLI_List_new >>> ?JLI_ManifestIterate >>> ?JLI_MemAlloc >>> ?JLI_MemFree >>> ?JLI_PreprocessArg >>> ?JLI_ReportErrorMessage >>> ?JLI_ReportErrorMessageSys >>> ?JLI_ReportExceptionDescription >>> ?JLI_ReportMessage >>> ?JLI_SetTraceLauncher >>> ?JLI_StringDup >>> >>> java.desktop:/libawt_xawt: The following symbols are now also >>> exported on linux and solaris due to JNIEXPORT: >>> ?awt_DrawingSurface_FreeDrawingSurfaceInfo >>> ?awt_DrawingSurface_GetDrawingSurfaceInfo >>> ?awt_DrawingSurface_Lock >>> ?awt_DrawingSurface_Unlock >>> ?awt_GetColor >>> >>> The following symbols are now also exported on linux and solaris due >>> to JNIEXPORT (they were previously >>> ?exported only in libawt): >>> ?Java_sun_awt_DebugSettings_setCTracingOn__Z >>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2 >>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I >>> ?Java_sun_awt_X11GraphicsConfig_getNumColors >>> >>> java.desktop:/libawt_headless: The following symbols are now also >>> exported due to JNIEXPORT (they were previously >>> ?exported only in libawt_xawt and/or libawt): >>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo >>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities >>> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask >>> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable >>> ?X11SurfaceData_GetOps >>> >>> java.desktop/libawt: The following symbols are now also exported on >>> Windows, due to added >>> JNIEXPORT: >>> ?SurfaceData_InitOps >>> ?mul8table >>> ?div8table >>> ?doDrawPath >>> ?doFillPath >>> ?g_CMpDataID >>> ?initInverseGrayLut >>> ?make_dither_arrays >>> ?make_uns_ordered_dither_array >>> ?path2DFloatCoordsID >>> ?path2DNumTypesID >>> ?path2DTypesID >>> ?path2DWindingRuleID >>> ?sg2dStrokeHintID >>> ?std_img_oda_blue >>> ?std_img_oda_green >>> ?std_img_oda_red >>> ?std_odas_computed >>> ?sunHints_INTVAL_STROKE_PURE >>> >>> java.desktop/libawt on solaris: >>> A number of "#pragma weak" directives was previously overridden by >>> the mapfile. >>> Now these directives are respected, so these symbols are now weak >>> instead of local: >>> ?ByteGrayToIntArgbPreConvert_F >>> ?ByteGrayToIntArgbPreScaleConvert_F >>> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F >>> ?IntArgbToIntRgbXorBlit_F >>> ?IntBgrToIntBgrAlphaMaskBlit_F >>> >>> java.desktop/libawt on solaris: These are now also exported due to >>> JNIEXPORT in libmlib_image. >>> ?j2d_mlib_ImageCreate >>> ?j2d_mlib_ImageCreateStruct >>> ?j2d_mlib_ImageDelete >>> >>> java.desktop/libawt on solaris: This is now also exported due to >>> JNIEXPORT: >>> ?GrPrim_CompGetXorColor >>> ?SurfaceData_GetOpsNoSetup >>> ?SurfaceData_IntersectBoundsXYWH >>> ?SurfaceData_SetOps >>> ?Transform_GetInfo >>> ?Transform_transform >>> >>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux >>> and solaris due to JNIEXPORT. >>> libspashscreen also had JNIEXPORT (actually a pure >>> _declspec(dllexport)) but no JNICALL, which I added as >>> a part of converting to JNIEXPORT. The same goes for libmlib_image . >>> >>> jdk.sctp/libsctp: handleSocketError is now exported on linux and >>> solaris due to JNIEXPORT in libnio. >>> >>> java.instrument:/libinstrument: Agent_OnUnload is now also exported >>> on linux and solaris platforms due to JNIEXPORT. >>> JLI_ManifestIterate is now also exported on Windows, due to added >>> JNIEXPORT in libjli. >>> >>> jdk.management/libmanagement_ext: >>> Java_com_sun_management_internal_Flag_setDoubleValue is now also >>> exported on linux and solaris platforms due to JNIEXPORT. >>> >>> /Magnus >>> >>> >> > From david.holmes at oracle.com Sat Mar 24 00:00:09 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 24 Mar 2018 10:00:09 +1000 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <94759ec3-2584-4c9d-d2eb-00f326196a50@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> <20ff592c-bfd6-4430-f2a7-a08eb3241477@oracle.com> <4e165850-8bf5-baed-bb5d-4d5d0b6224f7@oracle.com> <94759ec3-2584-4c9d-d2eb-00f326196a50@oracle.com> Message-ID: <5a178b76-6b30-df59-c466-ae7620524915@oracle.com> On 24/03/2018 1:58 AM, Magnus Ihse Bursie wrote: > > On 2018-03-23 11:05, David Holmes wrote: >> On 23/03/2018 7:54 PM, Magnus Ihse Bursie wrote: >>> >>> On 2018-03-23 09:55, David Holmes wrote: >>>> On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote: >>>>> >>>>> On 2018-03-23 06:22, David Holmes wrote: >>>>>> Hi Thomas, >>>>>> >>>>>> On 23/03/2018 2:55 PM, Thomas St?fe wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> would it not be pragmatic to accept Ao's patch - it looks fine to >>>>>>> me - since it certainly would not make matters worse. And let >>>>>>> Magnus follow up with a cleanup change later? >>>>>> >>>>>> Well I hope Magnus's change is forthcoming. >>>>> It might be some time still. I'm working on a complete overhaul of >>>>> all CFLAGS and LDFLAGS, where this is a part of that picture, but I >>>>> was not planning on addressing just this thing urgently. >>>>> >>>>> So, I think this patch will do for now. It solves the immediate >>>>> problem for MIPS, and I can come back and make a cleaner solution >>>>> later on. >>>> >>>> Isn't the best quick fix one that only adds -m64 for x86? I recall a >>>> report that arm32 is similarly broken. >>> Not really, because this is also needed on some other platforms, at >>> least s390x, as I recall. (This was the reason it was originally added.) >> >> According to gcc docs there are 4 archs that use m64 and we only care >> about 2 of them: >> >> m64: SPARC Options >> m64: S/390 and zSeries Options >> m64: RS/6000 and PowerPC Options >> m64: i386 and x86-64 Options >> > Note that this logic also applies to the xlc compiler, not only gcc. I > also believe that solstudio requires it on sparcv9, but I'm not 100% sure. > >> But you need to know whether you are dealing with S390 or S390x as m64 >> implies zSeries. > We only support s390x (64-bit), not s390. > > And OpenJDK still support ppc64, even if Oracle does not test it. So I'd > say that we need -m64 on all those platforms listed. So then the > question is, is it easier to check if it's one of four, or not one of > tree known CPU architectures. (For mips, we shouldn't test > OPENJDK_TARGET_CPU for a lot of mips*, but OPENJDK_TARGET_CPU_ARCH for > mips). For me, it's like, whatever. I'll probably rewrite this from the > ground up anywhat. What we're trying to express here is that some flags > are needed as CFLAGS always, even when running configure checks. It has > really nothing to do with the number of CPU bits. My recollection for x86 was we only needed to specify -m64 to ensure a 64-bit build if the compiler was not configured to do that by default. Very much tied to the number of CPU bits we wanted to build for. In any case isn't the whole point of configure that you can check if a compiler has a flag before you use it ?? David > /Magnus > >> >> Ao will need a sponsor to create a bug etc regardless of which way >> this goes. >> >> My week is over. :) >> >> Cheers, >> David >> >>> /Magnus >>> >>>> >>>> David >>>> ----- >>>> >>>>>> AFAICS it's as easy to write this only for x86 as it is to exclude >>>>>> it for non x86. Honestly I don't know why the Aarch64 patch was >>>>>> done the way it was - there must be some subtlety here that I'm >>>>>> not aware of. >>>>> I think it was just the smallest patch that worked for the aarch64 >>>>> platform. I didn't spend time arguing about the fix, since it is >>>>> supposed to be short-lived anyway. >>>>> >>>>> /Magnus >>> > From magnus.ihse.bursie at oracle.com Sat Mar 24 00:03:11 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 24 Mar 2018 01:03:11 +0100 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <5a178b76-6b30-df59-c466-ae7620524915@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> <20ff592c-bfd6-4430-f2a7-a08eb3241477@oracle.com> <4e165850-8bf5-baed-bb5d-4d5d0b6224f7@oracle.com> <94759ec3-2584-4c9d-d2eb-00f326196a50@oracle.com> <5a178b76-6b30-df59-c466-ae7620524915@oracle.com> Message-ID: <72048097-3f41-b416-39c8-cd87e1c98987@oracle.com> On 2018-03-24 01:00, David Holmes wrote: > On 24/03/2018 1:58 AM, Magnus Ihse Bursie wrote: >> >> On 2018-03-23 11:05, David Holmes wrote: >>> On 23/03/2018 7:54 PM, Magnus Ihse Bursie wrote: >>>> >>>> On 2018-03-23 09:55, David Holmes wrote: >>>>> On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote: >>>>>> >>>>>> On 2018-03-23 06:22, David Holmes wrote: >>>>>>> Hi Thomas, >>>>>>> >>>>>>> On 23/03/2018 2:55 PM, Thomas St?fe wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> would it not be pragmatic to accept Ao's patch - it looks fine >>>>>>>> to me - since it certainly would not make matters worse. And >>>>>>>> let Magnus follow up with a cleanup change later? >>>>>>> >>>>>>> Well I hope Magnus's change is forthcoming. >>>>>> It might be some time still. I'm working on a complete overhaul >>>>>> of all CFLAGS and LDFLAGS, where this is a part of that picture, >>>>>> but I was not planning on addressing just this thing urgently. >>>>>> >>>>>> So, I think this patch will do for now. It solves the immediate >>>>>> problem for MIPS, and I can come back and make a cleaner solution >>>>>> later on. >>>>> >>>>> Isn't the best quick fix one that only adds -m64 for x86? I recall >>>>> a report that arm32 is similarly broken. >>>> Not really, because this is also needed on some other platforms, at >>>> least s390x, as I recall. (This was the reason it was originally >>>> added.) >>> >>> According to gcc docs there are 4 archs that use m64 and we only >>> care about 2 of them: >>> >>> m64: SPARC Options >>> m64: S/390 and zSeries Options >>> m64: RS/6000 and PowerPC Options >>> m64: i386 and x86-64 Options >>> >> Note that this logic also applies to the xlc compiler, not only gcc. >> I also believe that solstudio requires it on sparcv9, but I'm not >> 100% sure. >> >>> But you need to know whether you are dealing with S390 or S390x as >>> m64 implies zSeries. >> We only support s390x (64-bit), not s390. >> >> And OpenJDK still support ppc64, even if Oracle does not test it. So >> I'd say that we need -m64 on all those platforms listed. So then the >> question is, is it easier to check if it's one of four, or not one of >> tree known CPU architectures. (For mips, we shouldn't test >> OPENJDK_TARGET_CPU for a lot of mips*, but OPENJDK_TARGET_CPU_ARCH >> for mips). For me, it's like, whatever. I'll probably rewrite this >> from the ground up anywhat. What we're trying to express here is that >> some flags are needed as CFLAGS always, even when running configure >> checks. It has really nothing to do with the number of CPU bits. > > My recollection for x86 was we only needed to specify -m64 to ensure a > 64-bit build if the compiler was not configured to do that by default. > Very much tied to the number of CPU bits we wanted to build for. > > In any case isn't the whole point of configure that you can check if a > compiler has a flag before you use it ?? Good point, the correct long term fix is probably to just check if -m is a supported option, instead of hardcoding platforms. I'll make a mental note of it. /Magnus > > David > >> /Magnus >> >>> >>> Ao will need a sponsor to create a bug etc regardless of which way >>> this goes. >>> >>> My week is over. :) >>> >>> Cheers, >>> David >>> >>>> /Magnus >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>>> AFAICS it's as easy to write this only for x86 as it is to >>>>>>> exclude it for non x86. Honestly I don't know why the Aarch64 >>>>>>> patch was done the way it was - there must be some subtlety here >>>>>>> that I'm not aware of. >>>>>> I think it was just the smallest patch that worked for the >>>>>> aarch64 platform. I didn't spend time arguing about the fix, >>>>>> since it is supposed to be short-lived anyway. >>>>>> >>>>>> /Magnus >>>> >> From glaubitz at physik.fu-berlin.de Sat Mar 24 00:15:24 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 24 Mar 2018 09:15:24 +0900 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> Message-ID: <3D849C10-B7F2-4DA4-9ED1-76A999219B66@physik.fu-berlin.de> On Mar 23, 2018, at 7:04 PM, Ao Qi wrote: >>> >>> It might be some time still. I'm working on a complete overhaul of all >>> CFLAGS and LDFLAGS, where this is a part of that picture, but I was not >>> planning on addressing just this thing urgently. >>> >>> So, I think this patch will do for now. It solves the immediate problem >>> for MIPS, and I can come back and make a cleaner solution later on. >> >> >> Isn't the best quick fix one that only adds -m64 for x86? I recall a report >> that arm32 is similarly broken. > > I had a look at man gcc. It seems that at least -m64 is for S/390 and > zSeries, SPARC , RS/6000 and PowerPC, and x86. I hope you don?t break architectures like m68k which don?t support that flag. Adrian From glaubitz at physik.fu-berlin.de Sat Mar 24 02:13:33 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 24 Mar 2018 11:13:33 +0900 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: <9a99f67c-98ee-2daa-4c17-290496d3ab29@oracle.com> References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <5AB2DAB1.503@oracle.com> <9a99f67c-98ee-2daa-4c17-290496d3ab29@oracle.com> Message-ID: <794e45e4-e081-2674-a3f4-23ee3accfb68@physik.fu-berlin.de> On 03/24/2018 01:07 AM, Magnus Ihse Bursie wrote: > But if javac developers are seriously hindered in their effort to enhance Java due to this, then maybe developer convenience is not as important. But is using the latest Java features really so important for OpenJDK development? I mean, do people seriously say "Oh, we have type inference for variables now. We have to use it immediately, it's making the code so much better and faster!!!" (sorry, couldn't resist the hyperbole). I mean, in the end, OpenJDK is developed for users and not for the OpenJDK developers sake to use Java, isn't it? So, I think the project should always keep users and downstream interests in mind. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From Sergey.Bylokhov at oracle.com Sat Mar 24 06:03:51 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Mar 2018 23:03:51 -0700 Subject: [11] Review Request: 8200198 javah man pages were not removed by JDK-8191054 Message-ID: Hello. Please review fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8200198 Webrev can be found at: http://cr.openjdk.java.net/~serb/8200198/webrev.00 The man pages related to javah tool were removed from the ws in the same way as it was done for policytool and for tools related to CORBA. The usage of these files were removed in JDK-8193512[1] http://hg.openjdk.java.net/jdk/jdk10/rev/26b47ea4c77d -- Best regards, Sergey. From Alan.Bateman at oracle.com Sat Mar 24 07:32:59 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 24 Mar 2018 07:32:59 +0000 Subject: [11] Review Request: 8200198 javah man pages were not removed by JDK-8191054 In-Reply-To: References: Message-ID: On 24/03/2018 06:03, Sergey Bylokhov wrote: > Hello. > Please review fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200198 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8200198/webrev.00 > This looks okay. Are we sure we've got everything now? (as this will be the fourth change to remove pieces of javah). -Alan From glaubitz at physik.fu-berlin.de Sun Mar 25 11:14:26 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sun, 25 Mar 2018 20:14:26 +0900 Subject: RFR: 8200203: Missing platform definitions for ia64 Message-ID: Hi! Please review this small change to the build system which adds the platform definitions for ia64. This is one of two changes that is necessary to get OpenJDK to build on ia64 (Zero variant). Thanks, Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8200203/webrev.01/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Sun Mar 25 12:54:38 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 25 Mar 2018 22:54:38 +1000 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <3D849C10-B7F2-4DA4-9ED1-76A999219B66@physik.fu-berlin.de> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> <3D849C10-B7F2-4DA4-9ED1-76A999219B66@physik.fu-berlin.de> Message-ID: <566e8d69-8158-62b1-329c-74998a2ef7d2@oracle.com> On 24/03/2018 10:15 AM, John Paul Adrian Glaubitz wrote: > On Mar 23, 2018, at 7:04 PM, Ao Qi wrote: > >>>> >>>> It might be some time still. I'm working on a complete overhaul of all >>>> CFLAGS and LDFLAGS, where this is a part of that picture, but I was not >>>> planning on addressing just this thing urgently. >>>> >>>> So, I think this patch will do for now. It solves the immediate problem >>>> for MIPS, and I can come back and make a cleaner solution later on. >>> >>> >>> Isn't the best quick fix one that only adds -m64 for x86? I recall a report >>> that arm32 is similarly broken. >> >> I had a look at man gcc. It seems that at least -m64 is for S/390 and >> zSeries, SPARC , RS/6000 and PowerPC, and x86. > > I hope you don?t break architectures like m68k which don?t support that flag. I think they are already broken. As I understand it -m64 is being added to everything except Aarch64 presently. David > Adrian > From david.holmes at oracle.com Sun Mar 25 23:08:35 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Mar 2018 09:08:35 +1000 Subject: RFR: 8200203: Missing platform definitions for ia64 In-Reply-To: References: Message-ID: Hi Adrian, On 25/03/2018 9:14 PM, John Paul Adrian Glaubitz wrote: > Hi! > > Please review this small change to the build system which adds the > platform definitions for ia64. This is one of two changes that is > necessary to get OpenJDK to build on ia64 (Zero variant). > > Thanks, > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8200203/webrev.01/ Everytime I see these zero-only platform definitions it makes we think we really should have these isolated into a zero-specific file. At the moment this can paint a false picture that all these platforms have full OpenJDK ports available. I also wonder if the values here can be reliably obtained via uname/sysconf or some such utility so that we don't have to list every single platform individually? Thanks, David From Sergey.Bylokhov at oracle.com Sun Mar 25 23:44:37 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 25 Mar 2018 16:44:37 -0700 Subject: [11] Review Request: 8200198 javah man pages were not removed by JDK-8191054 In-Reply-To: References: Message-ID: On 24/03/2018 00:32, Alan Bateman wrote: > This looks okay. Are we sure we've got everything now? (as this will be > the fourth change to remove pieces of javah). Fix updated, there were some links to javah from other man pages: http://cr.openjdk.java.net/~serb/8200198/webrev.01 Also it looks like "open/test/langtools/Makefile" should be updated, because it references a list of old tools like apt and javah: -- Best regards, Sergey. From glaubitz at physik.fu-berlin.de Mon Mar 26 01:06:26 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 26 Mar 2018 10:06:26 +0900 Subject: RFR: 8200203: Missing platform definitions for ia64 In-Reply-To: References: Message-ID: On 03/26/2018 08:08 AM, David Holmes wrote: > Everytime I see these zero-only platform definitions it makes we think we really > should have these isolated into a zero-specific file. At the moment this can > paint a false picture that all these platforms have full OpenJDK ports available. Is that really the case though? If someone is reading the platform.m4 file, they might think that but simply trying to build the server variant for ia64 would fail very quickly anyway and people would realize it's not supported. In the end, I think the extended portability OpenJDK highly outweighs your reservations above. Someone who doesn't understand the difference between Zero and the official ports, is also unlikely to try building OpenJDK from source themselves. > I also wonder if the values here can be reliably obtained via uname/sysconf > or some such utility so that we don't have to list every single platform > individually? I think autoconf normally has support for this, yes. It's rather unusual having to add targets manually. But you will need the mapping to VAR_CPU, for example. I will have a look at it anyway. For the time being, it would be nice if I can get this and a second follow-up change for ia64 merged so downstream (currently Debian and Gentoo for ia64) doesn't have to carry any additional patches anymore. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Mon Mar 26 01:19:37 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Mar 2018 11:19:37 +1000 Subject: RFR: 8200203: Missing platform definitions for ia64 In-Reply-To: References: Message-ID: <10f6cca1-5046-68da-26f1-a3d9c1648258@oracle.com> On 26/03/2018 11:06 AM, John Paul Adrian Glaubitz wrote: > On 03/26/2018 08:08 AM, David Holmes wrote: >> Everytime I see these zero-only platform definitions it makes we think we really >> should have these isolated into a zero-specific file. At the moment this can >> paint a false picture that all these platforms have full OpenJDK ports available. > > Is that really the case though? If someone is reading the platform.m4 file, they > might think that but simply trying to build the server variant for ia64 would > fail very quickly anyway and people would realize it's not supported. It's not so much that (though there have been cases!) but people just looking in that file can't tell a full platform from a zero-only platform. The general rule is that OpenJDK doesn't accept platform specific patches unless there is a fully supported port of that platform. But zero is the exception to that rule. So I just think, as a separate RFE, it would be good to split these out into platforms-zero.m4 which can then be included in platforms.m4 > In the end, I think the extended portability OpenJDK highly outweighs your > reservations above. Someone who doesn't understand the difference between Zero > and the official ports, is also unlikely to try building OpenJDK from source > themselves. > >> I also wonder if the values here can be reliably obtained via uname/sysconf >> or some such utility so that we don't have to list every single platform >> individually? > > I think autoconf normally has support for this, yes. It's rather unusual > having to add targets manually. But you will need the mapping to VAR_CPU, > for example. I will have a look at it anyway. > > For the time being, it would be nice if I can get this and a second follow-up > change for ia64 merged so downstream (currently Debian and Gentoo for ia64) > doesn't have to carry any additional patches anymore. I don't have a concern with this going in as-is for now. But wait for Magnus or Erik to give the okay. Thanks, David > Thanks, > Adrian > From aoqi at loongson.cn Mon Mar 26 02:50:58 2018 From: aoqi at loongson.cn (Ao Qi) Date: Mon, 26 Mar 2018 10:50:58 +0800 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: <4e165850-8bf5-baed-bb5d-4d5d0b6224f7@oracle.com> References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> <20ff592c-bfd6-4430-f2a7-a08eb3241477@oracle.com> <4e165850-8bf5-baed-bb5d-4d5d0b6224f7@oracle.com> Message-ID: 2018-03-23 18:05 GMT+08:00 David Holmes : > On 23/03/2018 7:54 PM, Magnus Ihse Bursie wrote: >> >> >> On 2018-03-23 09:55, David Holmes wrote: >>> >>> On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-03-23 06:22, David Holmes wrote: >>>>> >>>>> Hi Thomas, >>>>> >>>>> On 23/03/2018 2:55 PM, Thomas St?fe wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> would it not be pragmatic to accept Ao's patch - it looks fine to me - >>>>>> since it certainly would not make matters worse. And let Magnus follow up >>>>>> with a cleanup change later? >>>>> >>>>> >>>>> Well I hope Magnus's change is forthcoming. >>>> >>>> It might be some time still. I'm working on a complete overhaul of all >>>> CFLAGS and LDFLAGS, where this is a part of that picture, but I was not >>>> planning on addressing just this thing urgently. >>>> >>>> So, I think this patch will do for now. It solves the immediate problem >>>> for MIPS, and I can come back and make a cleaner solution later on. >>> >>> >>> Isn't the best quick fix one that only adds -m64 for x86? I recall a >>> report that arm32 is similarly broken. >> >> Not really, because this is also needed on some other platforms, at least >> s390x, as I recall. (This was the reason it was originally added.) > > > According to gcc docs there are 4 archs that use m64 and we only care about > 2 of them: > > m64: SPARC Options > m64: S/390 and zSeries Options > m64: RS/6000 and PowerPC Options > m64: i386 and x86-64 Options > > But you need to know whether you are dealing with S390 or S390x as m64 > implies zSeries. > > Ao will need a sponsor to create a bug etc regardless of which way this > goes. > Is it possible to accept my patch first (before a perfect all-platform solution is made)? If yes, could someone help to create a bug etc? Thanks! > My week is over. :) > > Cheers, > David > > >> /Magnus >> >>> >>> David >>> ----- >>> >>>>> AFAICS it's as easy to write this only for x86 as it is to exclude it >>>>> for non x86. Honestly I don't know why the Aarch64 patch was done the way it >>>>> was - there must be some subtlety here that I'm not aware of. >>>> >>>> I think it was just the smallest patch that worked for the aarch64 >>>> platform. I didn't spend time arguing about the fix, since it is supposed to >>>> be short-lived anyway. >>>> >>>> /Magnus >> >> > From david.holmes at oracle.com Mon Mar 26 04:38:48 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Mar 2018 14:38:48 +1000 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> <20ff592c-bfd6-4430-f2a7-a08eb3241477@oracle.com> <4e165850-8bf5-baed-bb5d-4d5d0b6224f7@oracle.com> Message-ID: https://bugs.openjdk.java.net/browse/JDK-8200213 Sponsoring. David ----- On 26/03/2018 12:50 PM, Ao Qi wrote: > 2018-03-23 18:05 GMT+08:00 David Holmes : >> On 23/03/2018 7:54 PM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-03-23 09:55, David Holmes wrote: >>>> >>>> On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-03-23 06:22, David Holmes wrote: >>>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> On 23/03/2018 2:55 PM, Thomas St?fe wrote: >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> would it not be pragmatic to accept Ao's patch - it looks fine to me - >>>>>>> since it certainly would not make matters worse. And let Magnus follow up >>>>>>> with a cleanup change later? >>>>>> >>>>>> >>>>>> Well I hope Magnus's change is forthcoming. >>>>> >>>>> It might be some time still. I'm working on a complete overhaul of all >>>>> CFLAGS and LDFLAGS, where this is a part of that picture, but I was not >>>>> planning on addressing just this thing urgently. >>>>> >>>>> So, I think this patch will do for now. It solves the immediate problem >>>>> for MIPS, and I can come back and make a cleaner solution later on. >>>> >>>> >>>> Isn't the best quick fix one that only adds -m64 for x86? I recall a >>>> report that arm32 is similarly broken. >>> >>> Not really, because this is also needed on some other platforms, at least >>> s390x, as I recall. (This was the reason it was originally added.) >> >> >> According to gcc docs there are 4 archs that use m64 and we only care about >> 2 of them: >> >> m64: SPARC Options >> m64: S/390 and zSeries Options >> m64: RS/6000 and PowerPC Options >> m64: i386 and x86-64 Options >> >> But you need to know whether you are dealing with S390 or S390x as m64 >> implies zSeries. >> >> Ao will need a sponsor to create a bug etc regardless of which way this >> goes. >> > > Is it possible to accept my patch first (before a perfect all-platform > solution is made)? If yes, could someone help to create a bug etc? > Thanks! > >> My week is over. :) >> >> Cheers, >> David >> >> >>> /Magnus >>> >>>> >>>> David >>>> ----- >>>> >>>>>> AFAICS it's as easy to write this only for x86 as it is to exclude it >>>>>> for non x86. Honestly I don't know why the Aarch64 patch was done the way it >>>>>> was - there must be some subtlety here that I'm not aware of. >>>>> >>>>> I think it was just the smallest patch that worked for the aarch64 >>>>> platform. I didn't spend time arguing about the fix, since it is supposed to >>>>> be short-lived anyway. >>>>> >>>>> /Magnus >>> >>> >> From thomas.stuefe at gmail.com Mon Mar 26 06:55:51 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 26 Mar 2018 08:55:51 +0200 Subject: RFR: 8200203: Missing platform definitions for ia64 In-Reply-To: References: Message-ID: Hi Adrian, On Sun, Mar 25, 2018 at 1:14 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hi! > > Please review this small change to the build system which adds the > platform definitions for ia64. This is one of two changes that is > necessary to get OpenJDK to build on ia64 (Zero variant). > > Thanks, > Adrian > > > [1] http://cr.openjdk.java.net/~glaubitz/8200203/webrev.01/ > > Looks good to me. ..Thomas > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From thomas.stuefe at gmail.com Mon Mar 26 06:56:21 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 26 Mar 2018 08:56:21 +0200 Subject: RFR: 8200203: Missing platform definitions for ia64 In-Reply-To: <10f6cca1-5046-68da-26f1-a3d9c1648258@oracle.com> References: <10f6cca1-5046-68da-26f1-a3d9c1648258@oracle.com> Message-ID: On Mon, Mar 26, 2018 at 3:19 AM, David Holmes wrote: > On 26/03/2018 11:06 AM, John Paul Adrian Glaubitz wrote: > >> On 03/26/2018 08:08 AM, David Holmes wrote: >> >>> Everytime I see these zero-only platform definitions it makes we think >>> we really >>> should have these isolated into a zero-specific file. At the moment this >>> can >>> paint a false picture that all these platforms have full OpenJDK ports >>> available. >>> >> >> Is that really the case though? If someone is reading the platform.m4 >> file, they >> might think that but simply trying to build the server variant for ia64 >> would >> fail very quickly anyway and people would realize it's not supported. >> > > It's not so much that (though there have been cases!) but people just > looking in that file can't tell a full platform from a zero-only platform. > The general rule is that OpenJDK doesn't accept platform specific patches > unless there is a fully supported port of that platform. But zero is the > exception to that rule. So I just think, as a separate RFE, it would be > good to split these out into platforms-zero.m4 which can then be included > in platforms.m4 > > This sounds reasonable. > In the end, I think the extended portability OpenJDK highly outweighs your >> reservations above. Someone who doesn't understand the difference between >> Zero >> and the official ports, is also unlikely to try building OpenJDK from >> source >> themselves. >> >> I also wonder if the values here can be reliably obtained via >>> uname/sysconf >>> or some such utility so that we don't have to list every single platform >>> individually? >>> >> >> I think autoconf normally has support for this, yes. It's rather unusual >> having to add targets manually. But you will need the mapping to VAR_CPU, >> for example. I will have a look at it anyway. >> >> For the time being, it would be nice if I can get this and a second >> follow-up >> change for ia64 merged so downstream (currently Debian and Gentoo for >> ia64) >> doesn't have to carry any additional patches anymore. >> > > I don't have a concern with this going in as-is for now. But wait for > Magnus or Erik to give the okay. > > Thanks, > David > > Thanks, >> Adrian >> >> Thanks, Thomas From aoqi at loongson.cn Mon Mar 26 07:24:49 2018 From: aoqi at loongson.cn (Ao Qi) Date: Mon, 26 Mar 2018 15:24:49 +0800 Subject: [NEW BUG]: Configure broken on MIPS In-Reply-To: References: <070f2f2e-7a7e-4d72-3d18-c95bcd54d3c2@oracle.com> <3959aef8-8a49-7ace-7b88-4f663ea80717@oracle.com> <1326705d-8874-017d-bb31-2b1aee7f1f9d@oracle.com> <70782da8-ce62-49a7-78f8-783a5ff4dd98@oracle.com> <6f63e1c5-7d00-3e97-3559-3e147510356c@oracle.com> <20ff592c-bfd6-4430-f2a7-a08eb3241477@oracle.com> <4e165850-8bf5-baed-bb5d-4d5d0b6224f7@oracle.com> Message-ID: Thank you very much David:) 2018-03-26 12:38 GMT+08:00 David Holmes : > https://bugs.openjdk.java.net/browse/JDK-8200213 > > Sponsoring. > > David > ----- > > > On 26/03/2018 12:50 PM, Ao Qi wrote: >> >> 2018-03-23 18:05 GMT+08:00 David Holmes : >>> >>> On 23/03/2018 7:54 PM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> >>>> On 2018-03-23 09:55, David Holmes wrote: >>>>> >>>>> >>>>> On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 2018-03-23 06:22, David Holmes wrote: >>>>>>> >>>>>>> >>>>>>> Hi Thomas, >>>>>>> >>>>>>> On 23/03/2018 2:55 PM, Thomas St?fe wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> would it not be pragmatic to accept Ao's patch - it looks fine to me >>>>>>>> - >>>>>>>> since it certainly would not make matters worse. And let Magnus >>>>>>>> follow up >>>>>>>> with a cleanup change later? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Well I hope Magnus's change is forthcoming. >>>>>> >>>>>> >>>>>> It might be some time still. I'm working on a complete overhaul of all >>>>>> CFLAGS and LDFLAGS, where this is a part of that picture, but I was >>>>>> not >>>>>> planning on addressing just this thing urgently. >>>>>> >>>>>> So, I think this patch will do for now. It solves the immediate >>>>>> problem >>>>>> for MIPS, and I can come back and make a cleaner solution later on. >>>>> >>>>> >>>>> >>>>> Isn't the best quick fix one that only adds -m64 for x86? I recall a >>>>> report that arm32 is similarly broken. >>>> >>>> >>>> Not really, because this is also needed on some other platforms, at >>>> least >>>> s390x, as I recall. (This was the reason it was originally added.) >>> >>> >>> >>> According to gcc docs there are 4 archs that use m64 and we only care >>> about >>> 2 of them: >>> >>> m64: SPARC Options >>> m64: S/390 and zSeries Options >>> m64: RS/6000 and PowerPC Options >>> m64: i386 and x86-64 Options >>> >>> But you need to know whether you are dealing with S390 or S390x as m64 >>> implies zSeries. >>> >>> Ao will need a sponsor to create a bug etc regardless of which way this >>> goes. >>> >> >> Is it possible to accept my patch first (before a perfect all-platform >> solution is made)? If yes, could someone help to create a bug etc? >> Thanks! >> >>> My week is over. :) >>> >>> Cheers, >>> David >>> >>> >>>> /Magnus >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>>> AFAICS it's as easy to write this only for x86 as it is to exclude it >>>>>>> for non x86. Honestly I don't know why the Aarch64 patch was done the >>>>>>> way it >>>>>>> was - there must be some subtlety here that I'm not aware of. >>>>>> >>>>>> >>>>>> I think it was just the smallest patch that worked for the aarch64 >>>>>> platform. I didn't spend time arguing about the fix, since it is >>>>>> supposed to >>>>>> be short-lived anyway. >>>>>> >>>>>> /Magnus >>>> >>>> >>>> >>> > From magnus.ihse.bursie at oracle.com Mon Mar 26 07:44:09 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 26 Mar 2018 09:44:09 +0200 Subject: RFR: 8200203: Missing platform definitions for ia64 In-Reply-To: References: Message-ID: On 2018-03-26 03:06, John Paul Adrian Glaubitz wrote: > On 03/26/2018 08:08 AM, David Holmes wrote: >> Everytime I see these zero-only platform definitions it makes we think we really >> should have these isolated into a zero-specific file. At the moment this can >> paint a false picture that all these platforms have full OpenJDK ports available. > Is that really the case though? If someone is reading the platform.m4 file, they > might think that but simply trying to build the server variant for ia64 would > fail very quickly anyway and people would realize it's not supported. > > In the end, I think the extended portability OpenJDK highly outweighs your > reservations above. Someone who doesn't understand the difference between Zero > and the official ports, is also unlikely to try building OpenJDK from source > themselves. I agree. I don't think it's a problem that we list the zero platforms in platform.m4. > >> I also wonder if the values here can be reliably obtained via uname/sysconf >> or some such utility so that we don't have to list every single platform >> individually? > I think autoconf normally has support for this, yes. It's rather unusual > having to add targets manually. But you will need the mapping to VAR_CPU, > for example. I will have a look at it anyway. You can consider platform.m4 (amongst other thing) to be a "translation" between whatever autoconf calls a platform, and what OpenJDK has traditionally used. For some platforms, this is a no-brainer, but for other, there are unfortunately multiple, well-accepted names (amd64, x86_64, x64), and the choice OpenJDK made in the past was not always aligned with the uname/sysconf/autoconf name. Despite our best efforts, we are still plagued by having different names in different places. We could perhaps try to make a "generic" section that maps OpenJDK names and values directly to what's given by the system, and use it whereever it applies. I'm not sure how to extract the endianness, though.. > For the time being, it would be nice if I can get this and a second follow-up > change for ia64 merged so downstream (currently Debian and Gentoo for ia64) > doesn't have to carry any additional patches anymore. Your patch looks good to me. /Magnus > > Thanks, > Adrian > From Alan.Bateman at oracle.com Mon Mar 26 07:45:58 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Mar 2018 08:45:58 +0100 Subject: [11] Review Request: 8200198 javah man pages were not removed by JDK-8191054 In-Reply-To: References: Message-ID: On 26/03/2018 00:44, Sergey Bylokhov wrote: > On 24/03/2018 00:32, Alan Bateman wrote: >> This looks okay. Are we sure we've got everything now? (as this will >> be the fourth change to remove pieces of javah). > > Fix updated, there were some links to javah from other man pages: > http://cr.openjdk.java.net/~serb/8200198/webrev.01 > > Also it looks like "open/test/langtools/Makefile" should be updated, > because it references a list of old tools like apt and javah: > This looks okay to me although I suspect these were originally generated so these references might come back if these were are ever refreshed. -Alan From glaubitz at physik.fu-berlin.de Mon Mar 26 08:07:54 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 26 Mar 2018 17:07:54 +0900 Subject: RFR: 8200203: Missing platform definitions for ia64 In-Reply-To: References: Message-ID: On 03/26/2018 04:44 PM, Magnus Ihse Bursie wrote: >> For the time being, it would be nice if I can get this and a second follow-up >> change for ia64 merged so downstream (currently Debian and Gentoo for ia64) >> doesn't have to carry any additional patches anymore. > Your patch looks good to me. Thank you. I just pushed it. I hope I did everything correctly being it my second push on my own. Added Thomas and you as reviewers and ran "hg jcheck" before pushing. Still a bit nervous when pushing to master. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From magnus.ihse.bursie at oracle.com Mon Mar 26 09:21:01 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 26 Mar 2018 11:21:01 +0200 Subject: RFR: JDK-8200229 Simplify building of libjsig Message-ID: Libjsig implements a wrapper library is supposed to be LD_PRELOADed by user code that wants to mix signals with calling the JVM. It is a very simple library; it's just a single file. Nevertheless, it has historically been built in a somewhat quirky way. This is mostly due to how it was part of the Hotspot makefiles, were it was something of an odd bird. There's no reason for any of this quirkiness. It can be built just like a normal JDK library, and it can be built by the java.base module, rather than hotspot. (After all, since the repo consolidation, the code already resides in java.base/.../libjsig). The only "odd" thing that remains is that, due to backwards compatibility, we need to put symlinks in each hotspot variant directory, since user code might expect to find the library there. Previously, we also symlinked to the debuginfo files, but there's really no reason to do that, it just complicates the makefile. Note that there is a conflict with JDK-8200178 (remove mapfiles for jdk libs), wherein the mapfile for libjsig was not removed. Depending on which of these patches gets pushed first, I need to respin the second one. (JDK-8200178 is currently on hold for running the huge java.desktop test suite.) Bug: https://bugs.openjdk.java.net/browse/JDK-8200229 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200229-simplify-building-of-libjsig/webrev.01 /Magnus From dalibor.topic at oracle.com Mon Mar 26 12:20:11 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 26 Mar 2018 14:20:11 +0200 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: <794e45e4-e081-2674-a3f4-23ee3accfb68@physik.fu-berlin.de> References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <5AB2DAB1.503@oracle.com> <9a99f67c-98ee-2daa-4c17-290496d3ab29@oracle.com> <794e45e4-e081-2674-a3f4-23ee3accfb68@physik.fu-berlin.de> Message-ID: <5db94b23-5bda-3308-bd85-756d28b39ab1@oracle.com> On 24.03.2018 03:13, John Paul Adrian Glaubitz wrote: > But is using the latest Java features really so important for OpenJDK > development? Generally speaking, being able to use the latest features is important because they typically reduce cost of both development (short term) & maintenance (long term). For a non-obvious example, having to support two ways of doing something because one way was deprecated and removed, but one is stuck with some old baseline where it still wasn't adds non-trivial cost to design, decision making, maintenance, etc. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From matthias.baesken at sap.com Mon Mar 26 14:55:17 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 26 Mar 2018 14:55:17 +0000 Subject: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl Message-ID: <16201e338dda41b0913bbd16286b6e2d@sap.com> Hello, after recent adjustments of src/hotspot/share/trace/traceEventClasses.xsl in jdk/hs ( see 8196337: Add commit methods that take all event properties as argument ) the AIX build fails. The xlC compiler is not happy with using TraceEvent::commit; in traceEventClasses.xsl (looks like correct C++ but xlc 12.1 refuses to compile ). Error messages : /nightly/output-jdk-hs/hotspot/variant-server/gensrc/tracefiles/traceEventClasses.hpp", line 226.9: 1540-1113 (S) The class template name "TraceEvent" must be followed by a < in this context. Bug : https://bugs.openjdk.java.net/browse/JDK-8200246 Adding the template parameter to TraceEvent makes xlc happy too. http://cr.openjdk.java.net/~mbaesken/webrevs/8200246/ Are you fine with this change ? Best regards, Matthias From robin.westberg at oracle.com Mon Mar 26 15:00:15 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Mon, 26 Mar 2018 17:00:15 +0200 Subject: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h In-Reply-To: <52afd5ec-e136-b924-8127-d3e33bf04428@oracle.com> References: <7F114FA8-59F0-42F1-A0B8-33D8C22DE81A@oracle.com> <52afd5ec-e136-b924-8127-d3e33bf04428@oracle.com> Message-ID: Hi Erik, Thanks for reviewing! Best regards, Robin > On 23 Mar 2018, at 14:58, Erik Joelsson wrote: > > I think this looks good, but Magnus is currently refactoring the flags handling in configure so better get his input as well. (adding build-dev) > /Erik > > On 2018-03-23 05:37, Robin Westberg wrote: >> Hi Kim & Erik, >> >> Certainly makes sense to define it from the build system, I?ve updated the patch accordingly: >> >> Full: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/ >> Incremental: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/ >> >> (Not quite sure if the definition belongs where I put it or a bit later where most other windows-specific JVM flags are defined, but seemed reasonable to put it close to where it is defined for the JDK libraries). >> >> Best regards, >> Robin >> >>> On 22 Mar 2018, at 16:52, Kim Barrett > wrote: >>> >>>> On Mar 22, 2018, at 10:34 AM, Robin Westberg > wrote: >>>> >>>> Hi all, >>>> >>>> Please review the following change that defines WIN32_LEAN_AND_MEAN [1] before including windows.h. This marginally improves build times, and makes it possible to include winsock2.h. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199736 > >>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/ > >>>> Testing: hs-tier1 >>>> >>>> Best regards, >>>> Robin >>>> >>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745%28v=vs.85%29.aspx#faster_builds_with_smaller_header_files > >>> >>> I think the addition of the WIN32_LEAN_AND_MEAN definition should be done through the build >>> system, so that it applies everywhere. >>> >> > From robin.westberg at oracle.com Mon Mar 26 15:00:44 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Mon, 26 Mar 2018 17:00:44 +0200 Subject: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h In-Reply-To: References: <7F114FA8-59F0-42F1-A0B8-33D8C22DE81A@oracle.com> <52afd5ec-e136-b924-8127-d3e33bf04428@oracle.com> Message-ID: <8BF38F0F-59E6-4BAF-8A1E-E5D26B23A9C3@oracle.com> Hi Magnus, Thanks for the review! Best regards, Robin > On 23 Mar 2018, at 16:43, Magnus Ihse Bursie wrote: > > This looks good to me. > > /Magnus > >> 23 mars 2018 kl. 14:58 skrev Erik Joelsson : >> >> I think this looks good, but Magnus is currently refactoring the flags handling in configure so better get his input as well. (adding build-dev) >> >> /Erik >> >> >>> On 2018-03-23 05:37, Robin Westberg wrote: >>> Hi Kim & Erik, >>> >>> Certainly makes sense to define it from the build system, I?ve updated the patch accordingly: >>> >>> Full: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/ >>> Incremental: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/ >>> >>> (Not quite sure if the definition belongs where I put it or a bit later where most other windows-specific JVM flags are defined, but seemed reasonable to put it close to where it is defined for the JDK libraries). >>> >>> Best regards, >>> Robin >>> >>>>>> On 22 Mar 2018, at 16:52, Kim Barrett > wrote: >>>>> >>>>> On Mar 22, 2018, at 10:34 AM, Robin Westberg > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Please review the following change that defines WIN32_LEAN_AND_MEAN [1] before including windows.h. This marginally improves build times, and makes it possible to include winsock2.h. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199736 >>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/ > >>>>> Testing: hs-tier1 >>>>> >>>>> Best regards, >>>>> Robin >>>>> >>>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745%28v=vs.85%29.aspx#faster_builds_with_smaller_header_files > >>>> >>>> I think the addition of the WIN32_LEAN_AND_MEAN definition should be done through the build >>>> system, so that it applies everywhere. >>>> >>> >> > From robin.westberg at oracle.com Mon Mar 26 15:01:10 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Mon, 26 Mar 2018 17:01:10 +0200 Subject: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h In-Reply-To: References: <7F114FA8-59F0-42F1-A0B8-33D8C22DE81A@oracle.com> Message-ID: <9DA6FFD9-1DD0-4C39-9D81-DF6FA49EDF45@oracle.com> Hi David, Thanks for taking a look! > On 26 Mar 2018, at 01:03, David Holmes wrote: > > Hi Robin, > > On 23/03/2018 10:37 PM, Robin Westberg wrote: >> Hi Kim & Erik, >> Certainly makes sense to define it from the build system, I?ve updated the patch accordingly: >> Full: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/ >> Incremental: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/ > > I'm a little unclear on the hotspot changes. If we define WIN32_LEAN_AND_MEAN then certain APIs like sockets are excluded from windows.h so we then have to include the specific header files like winsock2.h - is that right? Yep that?s correct, headers like winsock, dde, ole, shellapi and a few other uncommon ones are no longer included from windows.h when this is defined. > src/hotspot/share/interpreter/bytecodes.cpp > > I'm curious about this change. u_short comes from types.h on non-Windows, is it simply missing on Windows (at least once we have WIN32_LEAN_AND_MEAN defined) ? Yeah, on Windows these comes from winsock(2).h: /* * Basic system type definitions, taken from the BSD file sys/types.h. */ typedef unsigned char u_char; typedef unsigned short u_short; typedef unsigned int u_int; typedef unsigned long u_long; I noticed that one of these (u_char) is also defined in globalDefinitions.hpp so could perhaps define u_short there, or include winsock2.h globally again. But since it was only used in a single place in the existing code it seemed simple enough to just expand the typedef there. > src/hotspot/share/utilities/ostream.cpp > > 1029 #endif > 1030 #if defined(_WINDOWS) > > Using elif could be marginally faster given the two sets of conditions are mutually exclusive. Good point, will change it. I also had to move the flag definition to adapt to the latest changes in the hs repo, cc?ing build-dev again to make sure I got it right. Updated webrev (full): http://cr.openjdk.java.net/~rwestberg/8199736/webrev.02/ Updated webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01-02/ Best regards, Robin > > Thanks, > David > >> (Not quite sure if the definition belongs where I put it or a bit later where most other windows-specific JVM flags are defined, but seemed reasonable to put it close to where it is defined for the JDK libraries). >> Best regards, >> Robin >>> On 22 Mar 2018, at 16:52, Kim Barrett wrote: >>> >>>> On Mar 22, 2018, at 10:34 AM, Robin Westberg wrote: >>>> >>>> Hi all, >>>> >>>> Please review the following change that defines WIN32_LEAN_AND_MEAN [1] before including windows.h. This marginally improves build times, and makes it possible to include winsock2.h. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199736 >>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/ >>>> Testing: hs-tier1 >>>> >>>> Best regards, >>>> Robin >>>> >>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745%28v=vs.85%29.aspx#faster_builds_with_smaller_header_files >>> >>> I think the addition of the WIN32_LEAN_AND_MEAN definition should be done through the build >>> system, so that it applies everywhere. >>> From robin.westberg at oracle.com Mon Mar 26 15:01:19 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Mon, 26 Mar 2018 17:01:19 +0200 Subject: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX Message-ID: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> Hi all, Please review this small change that defines the NOMINMAX macro when building HotSpot on Windows. Issue: https://bugs.openjdk.java.net/browse/JDK-8199619 Webrev: http://cr.openjdk.java.net/~rwestberg/8199619/webrev.00/ Testing: building with/without precompiled headers, hs-tier1 Best regards, Robin From erik.joelsson at oracle.com Mon Mar 26 15:17:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 26 Mar 2018 08:17:57 -0700 Subject: [11] Review Request: 8200198 javah man pages were not removed by JDK-8191054 In-Reply-To: References: Message-ID: <910954fd-f4f6-7805-c5f3-f2ceec71a79a@oracle.com> Looks good to me. I doubt these will ever get regenerated from the same sources again. /Erik On 2018-03-26 00:45, Alan Bateman wrote: > > > On 26/03/2018 00:44, Sergey Bylokhov wrote: >> On 24/03/2018 00:32, Alan Bateman wrote: >>> This looks okay. Are we sure we've got everything now? (as this will >>> be the fourth change to remove pieces of javah). >> >> Fix updated, there were some links to javah from other man pages: >> http://cr.openjdk.java.net/~serb/8200198/webrev.01 >> >> Also it looks like "open/test/langtools/Makefile" should be updated, >> because it references a list of old tools like apt and javah: >> > This looks okay to me although I suspect these were originally > generated so these references might come back if these were are ever > refreshed. > > -Alan From erik.joelsson at oracle.com Mon Mar 26 15:32:19 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 26 Mar 2018 08:32:19 -0700 Subject: RFR: JDK-8200229 Simplify building of libjsig In-Reply-To: References: Message-ID: <6337e113-6a22-b97a-c629-71b5648c83cb@oracle.com> Nice cleanup, looks good! /Erik On 2018-03-26 02:21, Magnus Ihse Bursie wrote: > Libjsig implements a wrapper library is supposed to be LD_PRELOADed by > user code that wants to mix signals with calling the JVM. > > It is a very simple library; it's just a single file. Nevertheless, it > has historically been built in a somewhat quirky way. This is mostly > due to how it was part of the Hotspot makefiles, were it was something > of an odd bird. > > There's no reason for any of this quirkiness. It can be built just > like a normal JDK library, and it can be built by the java.base > module, rather than hotspot. (After all, since the repo consolidation, > the code already resides in java.base/.../libjsig). > > The only "odd" thing that remains is that, due to backwards > compatibility, we need to put symlinks in each hotspot variant > directory, since user code might expect to find the library there. > > Previously, we also symlinked to the debuginfo files, but there's > really no reason to do that, it just complicates the makefile. > > Note that there is a conflict with JDK-8200178 (remove mapfiles for > jdk libs), wherein the mapfile for libjsig was not removed. Depending > on which of these patches gets pushed first, I need to respin the > second one. (JDK-8200178 is currently on hold for running the huge > java.desktop test suite.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200229 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200229-simplify-building-of-libjsig/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Mon Mar 26 15:28:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 26 Mar 2018 08:28:40 -0700 Subject: RFR: 8200203: Missing platform definitions for ia64 In-Reply-To: References: Message-ID: <2d2791b8-167f-dc3d-3cb1-fc7766c8f90e@oracle.com> On 2018-03-26 00:44, Magnus Ihse Bursie wrote: > > On 2018-03-26 03:06, John Paul Adrian Glaubitz wrote: >> On 03/26/2018 08:08 AM, David Holmes wrote: >>> I also wonder if the values here can be reliably obtained via >>> uname/sysconf >>> or some such utility so that we don't have to list every single >>> platform >>> individually? >> I think autoconf normally has support for this, yes. It's rather unusual >> having to add targets manually. But you will need the mapping to >> VAR_CPU, >> for example. I will have a look at it anyway. > You can consider platform.m4 (amongst other thing) to be a > "translation" between whatever autoconf calls a platform, and what > OpenJDK has traditionally used. For some platforms, this is a > no-brainer, but for other, there are unfortunately multiple, > well-accepted names (amd64, x86_64, x64), and the choice OpenJDK made > in the past was not always aligned with the uname/sysconf/autoconf name. > > Despite our best efforts, we are still plagued by having different > names in different places. > > We could perhaps try to make a "generic" section that maps OpenJDK > names and values directly to what's given by the system, and use it > whereever it applies. I'm not sure how to extract the endianness, > though.. > I think this makes sense. Couldn't we just ask the preprocessor about 32/64-bit and endian order? I realize there will be some ordering complications for the tests in configure so not completely trivial to implement. /Erik From erik.joelsson at oracle.com Mon Mar 26 15:49:49 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 26 Mar 2018 08:49:49 -0700 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: <794e45e4-e081-2674-a3f4-23ee3accfb68@physik.fu-berlin.de> References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <5AB2DAB1.503@oracle.com> <9a99f67c-98ee-2daa-4c17-290496d3ab29@oracle.com> <794e45e4-e081-2674-a3f4-23ee3accfb68@physik.fu-berlin.de> Message-ID: <4f0d1a3b-ba97-caf6-597d-f582ed7f745a@oracle.com> Please note that it's not just language features, I would say it's more about library APIs that jdk.compiler uses. The most obvious such change in the past is the modules API. In JDK 9, we had to keep the jdk.compiler modules (with friends) compatible with both a pre modules and post modules environment. Being able to scrap all those extra workarounds (reflective access, duplicate implementations, filtered classes at compile time etc) already in 10 made development and maintenance of that source much simpler. I agree that OpenJDK is mainly for users, but my view of users is mainly the people using OpenJDK, not the ones building it. Sure, it is an open source project and as such a user is free to download and build from source on their own. However, the vast majority is downloading prebuilt binaries. Given that, I see the main conflict in this case rather being between OpenJDK developers and the package maintainers/distributors who regularly have to build it. I don't really think it's fair that the OpenJDK developers should have to pay a heavy development and maintenance tax just to make it a little bit more convenient to build the product from source. /Erik On 2018-03-23 19:13, John Paul Adrian Glaubitz wrote: > On 03/24/2018 01:07 AM, Magnus Ihse Bursie wrote: >> But if javac developers are seriously hindered in their effort to enhance Java due to this, then maybe developer convenience is not as important. > But is using the latest Java features really so important for OpenJDK > development? I mean, do people seriously say "Oh, we have type inference > for variables now. We have to use it immediately, it's making the code so > much better and faster!!!" (sorry, couldn't resist the hyperbole). > > I mean, in the end, OpenJDK is developed for users and not for the OpenJDK > developers sake to use Java, isn't it? So, I think the project should always > keep users and downstream interests in mind. > > Adrian > From erik.joelsson at oracle.com Mon Mar 26 15:50:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 26 Mar 2018 08:50:40 -0700 Subject: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX In-Reply-To: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> References: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> Message-ID: <7e318372-2c04-be32-dd0d-7c0fe092c98f@oracle.com> Looks good. /Erik On 2018-03-26 08:01, Robin Westberg wrote: > Hi all, > > Please review this small change that defines the NOMINMAX macro when building HotSpot on Windows. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8199619 > Webrev: http://cr.openjdk.java.net/~rwestberg/8199619/webrev.00/ > Testing: building with/without precompiled headers, hs-tier1 > > Best regards, > Robin From kim.barrett at oracle.com Mon Mar 26 16:34:15 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 26 Mar 2018 12:34:15 -0400 Subject: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX In-Reply-To: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> References: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> Message-ID: <446F6608-6FC0-4962-AAD3-CC8CF36F60F7@oracle.com> > On Mar 26, 2018, at 11:01 AM, Robin Westberg wrote: > > Hi all, > > Please review this small change that defines the NOMINMAX macro when building HotSpot on Windows. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8199619 > Webrev: http://cr.openjdk.java.net/~rwestberg/8199619/webrev.00/ > Testing: building with/without precompiled headers, hs-tier1 > > Best regards, > Robin Looks good. This change will have a (easy to resolve) merge conflict with your fix for JDK-8199736, right? From thomas.stuefe at gmail.com Mon Mar 26 18:13:47 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 26 Mar 2018 20:13:47 +0200 Subject: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl In-Reply-To: <16201e338dda41b0913bbd16286b6e2d@sap.com> References: <16201e338dda41b0913bbd16286b6e2d@sap.com> Message-ID: Hi Matthias, thanks for fixing this! Patch works and looks ok. Best Regards, Thomas On Mon, Mar 26, 2018 at 4:55 PM, Baesken, Matthias wrote: > Hello, after recent adjustments of src/hotspot/share/trace/ > traceEventClasses.xsl > in jdk/hs ( see 8196337: Add commit methods that take all event > properties as argument ) the AIX build fails. > > The xlC compiler is not happy with > > using TraceEvent::commit; > > in traceEventClasses.xsl (looks like correct C++ but xlc 12.1 refuses to > compile ). > Error messages : > > /nightly/output-jdk-hs/hotspot/variant-server/gensrc/ > tracefiles/traceEventClasses.hpp", line 226.9: 1540-1113 (S) The class > template name "TraceEvent" must be followed by a < in this context. > > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8200246 > > Adding the template parameter to TraceEvent makes xlc happy too. > > http://cr.openjdk.java.net/~mbaesken/webrevs/8200246/ > > > Are you fine with this change ? > > Best regards, Matthias > > From magnus.ihse.bursie at oracle.com Mon Mar 26 21:24:10 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 26 Mar 2018 23:24:10 +0200 Subject: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX In-Reply-To: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> References: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> Message-ID: On 2018-03-26 17:01, Robin Westberg wrote: > Hi all, > > Please review this small change that defines the NOMINMAX macro when building HotSpot on Windows. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8199619 > Webrev: http://cr.openjdk.java.net/~rwestberg/8199619/webrev.00/ Looks good to me. /Magnus > Testing: building with/without precompiled headers, hs-tier1 > > Best regards, > Robin From david.holmes at oracle.com Tue Mar 27 00:57:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Mar 2018 10:57:42 +1000 Subject: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h In-Reply-To: <9DA6FFD9-1DD0-4C39-9D81-DF6FA49EDF45@oracle.com> References: <7F114FA8-59F0-42F1-A0B8-33D8C22DE81A@oracle.com> <9DA6FFD9-1DD0-4C39-9D81-DF6FA49EDF45@oracle.com> Message-ID: <29b9be70-5855-fa0d-e1b2-73565e76d052@oracle.com> Looks good to me. Thanks, David On 27/03/2018 1:01 AM, Robin Westberg wrote: > Hi David, > > Thanks for taking a look! > >> On 26 Mar 2018, at 01:03, David Holmes > > wrote: >> >> Hi Robin, >> >> On 23/03/2018 10:37 PM, Robin Westberg wrote: >>> Hi Kim & Erik, >>> Certainly makes sense to define it from the build system, I?ve >>> updated the patch accordingly: >>> Full: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/ >>> >> >> I'm a little unclear on the hotspot changes. If we define >> WIN32_LEAN_AND_MEAN then certain APIs like sockets are excluded from >> windows.h so we then have to include the specific header files like >> winsock2.h - is that right? > > Yep that?s correct, headers like winsock, dde, ole, shellapi and a few > other uncommon ones are no longer included from windows.h when this is > defined. > >> src/hotspot/share/interpreter/bytecodes.cpp >> >> I'm curious about this change. u_short comes from types.h on >> non-Windows, is it simply missing on Windows (at least once we have >> WIN32_LEAN_AND_MEAN defined) ? > > Yeah, on Windows these comes from winsock(2).h: > > /* > ?* Basic system type definitions, taken from the BSD file sys/types.h. > ?*/ > typedef unsigned char ? u_char; > typedef unsigned short ?u_short; > typedef unsigned int ? ?u_int; > typedef unsigned long ? u_long; > > I noticed that one of these (u_char) is also defined in > globalDefinitions.hpp so could perhaps define u_short there, or include > winsock2.h globally again. But since it was only used in a single place > in the existing code it seemed simple enough to just expand the typedef > there. > >> src/hotspot/share/utilities/ostream.cpp >> >> 1029 #endif >> 1030 #if defined(_WINDOWS) >> >> Using elif could be marginally faster given the two sets of conditions >> are mutually exclusive. > > Good point, will change it. > > I also had to move the flag definition to adapt to the latest changes in > the hs repo, cc?ing build-dev again to make sure I got it right. > > Updated webrev (full): > http://cr.openjdk.java.net/~rwestberg/8199736/webrev.02/ > Updated webrev (incremental): > http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01-02/ > > Best regards, > Robin > >> >> Thanks, >> David >> >>> (Not quite sure if the definition belongs where I put it or a bit >>> later where most other windows-specific JVM flags are defined, but >>> seemed reasonable to put it close to where it is defined for the JDK >>> libraries). >>> Best regards, >>> Robin >>>> On 22 Mar 2018, at 16:52, Kim Barrett >>> > wrote: >>>> >>>>> On Mar 22, 2018, at 10:34 AM, Robin Westberg >>>>> > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Please review the following change that defines WIN32_LEAN_AND_MEAN >>>>> [1] before including windows.h. This marginally improves build >>>>> times, and makes it possible to include winsock2.h. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199736 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/ >>>>> >>>>> Testing: hs-tier1 >>>>> >>>>> Best regards, >>>>> Robin >>>>> >>>>> [1] >>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745%28v=vs.85%29.aspx#faster_builds_with_smaller_header_files >>>>> >>>> >>>> I think the addition of the WIN32_LEAN_AND_MEAN definition should be >>>> done through the build >>>> system, so that it applies everywhere. >>>> > From glaubitz at physik.fu-berlin.de Tue Mar 27 05:10:31 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 27 Mar 2018 14:10:31 +0900 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: References: <1521313360.26308.4.camel@gmail.com> <259e05b8-dbb1-4aa4-f451-6b7078eeb2ff@oracle.com> <1521554055.3029.4.camel@gmail.com> Message-ID: <9b675cad-0aec-dfbe-1540-15417b58aaea@physik.fu-berlin.de> On 03/24/2018 02:26 AM, Magnus Ihse Bursie wrote: > > On 2018-03-20 14:54, Edward Nevill wrote: >> Thanks for this. I have updated the webrev with the above comment. >> >> http://cr.openjdk.java.net/~enevill/8199138/webrev.01 > I note that in platform.m4 (sorry I didn't say this earlier), you set the CPU_ARCH to riscv64 as well, and not just riscv. Now I don't know how likely it is > that OpenJDK will ever support the 32-bit version of riscv, but it seems like it would make more sense to define the CPU_ARCH as "riscv", and the CPU as "riscv64". > > It's just a minor thing, if you like it the way it is, keep it. I agree, this is a bit odd. @Edward: Is this correct as it currently is? Would be great if this changeset could finally get merged as Debian just recently bootstrapped riscv64 and is now building packages on real hardware with 10 build machines running: > https://buildd.debian.org/status/architecture.php?a=riscv64&suite=sid I assume the build dependencies for OpenJDK in Debian will be built in around a week or so. Until I then, we should have sorted this patch out so I can add a (backported) patch to Debian's openjdk-8/9/10/11 packages. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From matthias.baesken at sap.com Tue Mar 27 07:22:38 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 27 Mar 2018 07:22:38 +0000 Subject: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl In-Reply-To: References: <16201e338dda41b0913bbd16286b6e2d@sap.com> Message-ID: <2fdb6d8d1a8748f5b6c3798a17f1d14d@sap.com> Hi Thomas , thanks for the review . Can I have a second review please ? Best regards, Matthias From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Montag, 26. M?rz 2018 20:14 To: Baesken, Matthias Cc: build-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Simonis, Volker ; Doerr, Martin Subject: Re: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl Hi Matthias, thanks for fixing this! Patch works and looks ok. Best Regards, Thomas On Mon, Mar 26, 2018 at 4:55 PM, Baesken, Matthias > wrote: Hello, after recent adjustments of src/hotspot/share/trace/traceEventClasses.xsl in jdk/hs ( see 8196337: Add commit methods that take all event properties as argument ) the AIX build fails. The xlC compiler is not happy with using TraceEvent::commit; in traceEventClasses.xsl (looks like correct C++ but xlc 12.1 refuses to compile ). Error messages : /nightly/output-jdk-hs/hotspot/variant-server/gensrc/tracefiles/traceEventClasses.hpp", line 226.9: 1540-1113 (S) The class template name "TraceEvent" must be followed by a < in this context. Bug : https://bugs.openjdk.java.net/browse/JDK-8200246 Adding the template parameter to TraceEvent makes xlc happy too. http://cr.openjdk.java.net/~mbaesken/webrevs/8200246/ Are you fine with this change ? Best regards, Matthias From christoph.langer at sap.com Tue Mar 27 07:33:21 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 27 Mar 2018 07:33:21 +0000 Subject: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl In-Reply-To: <2fdb6d8d1a8748f5b6c3798a17f1d14d@sap.com> References: <16201e338dda41b0913bbd16286b6e2d@sap.com> <2fdb6d8d1a8748f5b6c3798a17f1d14d@sap.com> Message-ID: <2cd633e5431345cf92c9eb5ef1795efb@sap.com> Hi Matthias, looks good to me, too. Best regards Christoph From: Baesken, Matthias Sent: Dienstag, 27. M?rz 2018 09:23 To: Thomas St?fe Cc: build-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Simonis, Volker ; Doerr, Martin ; Langer, Christoph Subject: RE: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl Hi Thomas , thanks for the review . Can I have a second review please ? Best regards, Matthias From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Montag, 26. M?rz 2018 20:14 To: Baesken, Matthias > Cc: build-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Simonis, Volker >; Doerr, Martin > Subject: Re: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl Hi Matthias, thanks for fixing this! Patch works and looks ok. Best Regards, Thomas On Mon, Mar 26, 2018 at 4:55 PM, Baesken, Matthias > wrote: Hello, after recent adjustments of src/hotspot/share/trace/traceEventClasses.xsl in jdk/hs ( see 8196337: Add commit methods that take all event properties as argument ) the AIX build fails. The xlC compiler is not happy with using TraceEvent::commit; in traceEventClasses.xsl (looks like correct C++ but xlc 12.1 refuses to compile ). Error messages : /nightly/output-jdk-hs/hotspot/variant-server/gensrc/tracefiles/traceEventClasses.hpp", line 226.9: 1540-1113 (S) The class template name "TraceEvent" must be followed by a < in this context. Bug : https://bugs.openjdk.java.net/browse/JDK-8200246 Adding the template parameter to TraceEvent makes xlc happy too. http://cr.openjdk.java.net/~mbaesken/webrevs/8200246/ Are you fine with this change ? Best regards, Matthias From edward.nevill at gmail.com Tue Mar 27 08:23:59 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 27 Mar 2018 09:23:59 +0100 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <9b675cad-0aec-dfbe-1540-15417b58aaea@physik.fu-berlin.de> References: <1521313360.26308.4.camel@gmail.com> <259e05b8-dbb1-4aa4-f451-6b7078eeb2ff@oracle.com> <1521554055.3029.4.camel@gmail.com> <9b675cad-0aec-dfbe-1540-15417b58aaea@physik.fu-berlin.de> Message-ID: <1522139039.7098.11.camel@gmail.com> Hi, On Tue, 2018-03-27 at 14:10 +0900, John Paul Adrian Glaubitz wrote: > On 03/24/2018 02:26 AM, Magnus Ihse Bursie wrote: > > > > On 2018-03-20 14:54, Edward Nevill wrote: > > > Thanks for this. I have updated the webrev with the above comment. > > > > > > http://cr.openjdk.java.net/~enevill/8199138/webrev.01 > > > > I note that in platform.m4 (sorry I didn't say this earlier), you set the CPU_ARCH to riscv64 as well, and not just riscv. Now I don't know how likely it is > > that OpenJDK will ever support the 32-bit version of riscv, but it seems like it would make more sense to define the CPU_ARCH as "riscv", and the CPU as "riscv64". > > > > It's just a minor thing, if you like it the way it is, keep it. > > I agree, this is a bit odd. > > @Edward: Is this correct as it currently is? Would be great if this changeset > could finally get merged as Debian just recently bootstrapped riscv64 and > is now building packages on real hardware with 10 build machines running: > Sorry for the delay. I was doing another test build on qemu which takes about 3 days. Please review the following webrev http://cr.openjdk.java.net/~enevill/8199138/webrev.02 This has the following additional changes over the previous webrev 1) Add comment in os_linux.cpp @@ -1733,6 +1733,9 @@ #ifndef EM_AARCH64 #define EM_AARCH64 183 /* ARM AARCH64 */ #endif +#ifndef EM_RISCV /* RISCV */ + #define EM_RISCV 243 +#endif static const arch_t arch_array[]={ {EM_386, EM_386, ELFCLASS32, ELFDATA2LSB, (char*)"IA 32"}, 2) Add RISCV to the #error list in os_linux.cpp @@ -1794,7 +1800,7 @@ static Elf32_Half running_arch_code=EM_SH; #else #error Method os::dll_load requires that one of following is defined:\ - AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, __powerpc__, __powerpc64__, S390, SH, __sparc + AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, __powerpc__, __powerpc64__, S390, SH, __sparc, RISCV #endif // Identify compatability class for VM's architecture and library's architecture 3) Use 'riscv' instead of 'riscv64' for VAR_CPU_ARCH in platform.m4 @@ -114,6 +114,12 @@ VAR_CPU_BITS=64 VAR_CPU_ENDIAN=little ;; + riscv64) + VAR_CPU=riscv64 + VAR_CPU_ARCH=riscv + VAR_CPU_BITS=64 + VAR_CPU_ENDIAN=little + ;; 4) Add riscv to the list of arch which do not have -m64 in flags.m4 @@ -237,7 +237,8 @@ MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}" elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then if test "x$OPENJDK_TARGET_CPU" != xaarch64 && - test "x$OPENJDK_TARGET_CPU" != xarm; then + test "x$OPENJDK_TARGET_CPU" != xarm && + test "x$OPENJDK_TARGET_CPU" != xriscv64; then MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" fi fi (This is necessary to get it building again. The previous webrev was based on a rev which did not have the -m64 problem) I have run this through submit-hs with no problems and as mentioned have also done a complete rebuild under qemu for riscv. Thanks for your patience, Ed. From glaubitz at physik.fu-berlin.de Tue Mar 27 08:46:11 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 27 Mar 2018 17:46:11 +0900 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <1522139039.7098.11.camel@gmail.com> References: <1521313360.26308.4.camel@gmail.com> <259e05b8-dbb1-4aa4-f451-6b7078eeb2ff@oracle.com> <1521554055.3029.4.camel@gmail.com> <9b675cad-0aec-dfbe-1540-15417b58aaea@physik.fu-berlin.de> <1522139039.7098.11.camel@gmail.com> Message-ID: <62079618-0fdd-af0b-a3ee-3134555326bb@physik.fu-berlin.de> On 03/27/2018 05:23 PM, Edward Nevill wrote: > Sorry for the delay. I was doing another test build on qemu which takes about 3 days. > > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8199138/webrev.02 > > This has the following additional changes over the previous webrev > > 1) Add comment in os_linux.cpp > > @@ -1733,6 +1733,9 @@ > #ifndef EM_AARCH64 > #define EM_AARCH64 183 /* ARM AARCH64 */ > #endif > +#ifndef EM_RISCV /* RISCV */ > + #define EM_RISCV 243 > +#endif What confuses me: Why RISCV here and not RISCV64? In particular this hunk: @@ -1758,6 +1761,7 @@ {EM_PARISC, EM_PARISC, ELFCLASS32, ELFDATA2MSB, (char*)"PARISC"}, {EM_68K, EM_68K, ELFCLASS32, ELFDATA2MSB, (char*)"M68k"}, {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"}, + {EM_RISCV, EM_RISCV, ELFCLASS64, ELFDATA2LSB, (char*)"RISCV"}, }; I know there is already 32-bit RISC-V and there are actually plans for using it. So, it looks to me you would be breaking 32-bit RISC-V here. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From magnus.ihse.bursie at oracle.com Tue Mar 27 09:42:31 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 27 Mar 2018 11:42:31 +0200 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c Message-ID: When I was about to update jsig.c, I noticed that the four copies for aix, linux, macosx and solaris were basically the same, with only small differences. Some of the differences were not even well motivated, but were likely the result of this code duplication causing the code to diverge. A better solution is to unify them all into a single unix version, with the few platform-specific changes handled on a per-platform basis. I've made the following notable changes: * I have removed the version check for Solaris. All other platforms seem to do fine without it, and in general, we don't mistrust other JDK libraries. An alternative is to add this version check to all other platforms instead. If you think this is the correct course of action, let me know and I'll fix it. * Solaris used to have a dynamically allocated sact, instead of a statically allocated array as all other platforms have. It's not likely to be large, and the size is known at compile time, so there seems to be no good reason for this. * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for jvmsigs, as aix and solaris do. This is a less robust solution, and the added checks show that it has failed in the past. Now all platforms use sigset_t/sigismember(). Also worth noting: * Solaris is not using pthreads, but it's own thread library, which accounts for most of the #ifdef SOLARIS. * In general, if an implementation was needed on one platform, but has no effect or is harmless on others, I've kept it on all platforms instead of sprinkling the code with #ifdefs. To facilitate code review, here is a specially crafted webrev that shows the differences compared to each of the individual, original per-OS versions of jsig.c: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 /Magnus From glaubitz at physik.fu-berlin.de Tue Mar 27 09:54:22 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 27 Mar 2018 18:54:22 +0900 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: References: Message-ID: <41c1cfce-9146-8091-4acb-ce51c894db10@physik.fu-berlin.de> On 03/27/2018 06:42 PM, Magnus Ihse Bursie wrote: > * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for jvmsigs, as aix and solaris do. This is a less robust solution, and the added checks show > that it has failed in the past. Now all platforms use sigset_t/sigismember(). Ah, this is great. I guess Debian can then drop this patch we have for the MIPS targets [1, 2]. This patch is necessary because MIPS has 128 signals and uint64_t is not enough for that. I will test whether your change makes this particular Debian patch obsolete. Adrian > [1] https://sources.debian.org/src/openjdk-11/11%7E5-1/debian/patches/mips-sigset.diff/ > [2] https://sources.debian.org/src/openjdk-9/9.0.4+12-3/debian/patches/mips-sigset.diff/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Tue Mar 27 10:38:20 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Mar 2018 20:38:20 +1000 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: References: Message-ID: Hi Magnus, I will take a look at this tomorrow. There are some open bugs on jsig regarding the number of signals it can handle on different platforms IIRC. Also the Solaris differences may not be needed as the pthread functions can be used without any concern in most cases. Thanks, David On 27/03/2018 7:42 PM, Magnus Ihse Bursie wrote: > When I was about to update jsig.c, I noticed that the four copies for > aix, linux, macosx and solaris were basically the same, with only small > differences. Some of the differences were not even well motivated, but > were likely the result of this code duplication causing the code to > diverge. > > A better solution is to unify them all into a single unix version, with > the few platform-specific changes handled on a per-platform basis. > > I've made the following notable changes: > > * I have removed the version check for Solaris. All other platforms seem > to do fine without it, and in general, we don't mistrust other JDK > libraries. An alternative is to add this version check to all other > platforms instead. If you think this is the correct course of action, > let me know and I'll fix it. > > * Solaris used to have a dynamically allocated sact, instead of a > statically allocated array as all other platforms have. It's not likely > to be large, and the size is known at compile time, so there seems to be > no good reason for this. > > * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for > jvmsigs, as aix and solaris do. This is a less robust solution, and the > added checks show that it has failed in the past. Now all platforms use > sigset_t/sigismember(). > > Also worth noting: > > * Solaris is not using pthreads, but it's own thread library, which > accounts for most of the #ifdef SOLARIS. > > * In general, if an implementation was needed on one platform, but has > no effect or is harmless on others, I've kept it on all platforms > instead of sprinkling the code with #ifdefs. > > To facilitate code review, here is a specially crafted webrev that shows > the differences compared to each of the individual, original per-OS > versions of jsig.c: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 > > /Magnus From matthias.baesken at sap.com Tue Mar 27 12:46:21 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 27 Mar 2018 12:46:21 +0000 Subject: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl In-Reply-To: References: <16201e338dda41b0913bbd16286b6e2d@sap.com> Message-ID: <4026c422f2ae4a068d8632e8d55243f3@sap.com> Thanks Leo . We have tested the same here locally in our OpenJDK night builds . Best regards, Matthias > -----Original Message----- > From: Leo Korinth [mailto:leo.korinth at oracle.com] > Sent: Dienstag, 27. M?rz 2018 14:02 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' ; 'hotspot- > dev at openjdk.java.net' > Cc: Simonis, Volker > Subject: Re: 8200246 : AIX build fails after adjustments of > src/hotspot/share/trace/traceEventClasses.xsl > > > > > Adding the template parameter to TraceEvent makes xlc happy too. > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8200246/ > > > > > > Are you fine with this change ? > > Observe that this is not a review. I have tested that your fix should > compile on linux, solaris, windows and mac. > > Thanks, > Leo > > Best regards, Matthias > > From edward.nevill at gmail.com Tue Mar 27 13:47:32 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 27 Mar 2018 14:47:32 +0100 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <62079618-0fdd-af0b-a3ee-3134555326bb@physik.fu-berlin.de> References: <1521313360.26308.4.camel@gmail.com> <259e05b8-dbb1-4aa4-f451-6b7078eeb2ff@oracle.com> <1521554055.3029.4.camel@gmail.com> <9b675cad-0aec-dfbe-1540-15417b58aaea@physik.fu-berlin.de> <1522139039.7098.11.camel@gmail.com> <62079618-0fdd-af0b-a3ee-3134555326bb@physik.fu-berlin.de> Message-ID: <1522158452.7098.16.camel@gmail.com> On Tue, 2018-03-27 at 17:46 +0900, John Paul Adrian Glaubitz wrote: > On 03/27/2018 05:23 PM, Edward Nevill wrote: > > @@ -1733,6 +1733,9 @@ > > #ifndef EM_AARCH64 > > #define EM_AARCH64 183 /* ARM AARCH64 */ > > #endif > > +#ifndef EM_RISCV /* RISCV */ > > + #define EM_RISCV 243 > > +#endif > > What confuses me: Why RISCV here and not RISCV64? > > In particular this hunk: > > @@ -1758,6 +1761,7 @@ > {EM_PARISC, EM_PARISC, ELFCLASS32, ELFDATA2MSB, > (char*)"PARISC"}, > {EM_68K, EM_68K, ELFCLASS32, ELFDATA2MSB, > (char*)"M68k"}, > {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, > (char*)"AARCH64"}, > + {EM_RISCV, EM_RISCV, ELFCLASS64, ELFDATA2LSB, > (char*)"RISCV"}, > }; > > I know there is already 32-bit RISC-V and there are actually plans > for > using it. So, it looks to me you would be breaking 32-bit RISC-V > here. > Because that is what is defined in elf.h >From /usr/include/elf.h #define EM_RISCV 243 /* RISC-V */ There is no EM_RISCV32 or EM_RISCV64 in elf.h All the best, Ed. From erik.joelsson at oracle.com Tue Mar 27 15:48:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 27 Mar 2018 08:48:57 -0700 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: References: Message-ID: Build change looks good. I will let someone more informed look at the code changes. /Erik On 2018-03-27 02:42, Magnus Ihse Bursie wrote: > When I was about to update jsig.c, I noticed that the four copies for > aix, linux, macosx and solaris were basically the same, with only > small differences. Some of the differences were not even well > motivated, but were likely the result of this code duplication causing > the code to diverge. > > A better solution is to unify them all into a single unix version, > with the few platform-specific changes handled on a per-platform basis. > > I've made the following notable changes: > > * I have removed the version check for Solaris. All other platforms > seem to do fine without it, and in general, we don't mistrust other > JDK libraries. An alternative is to add this version check to all > other platforms instead. If you think this is the correct course of > action, let me know and I'll fix it. > > * Solaris used to have a dynamically allocated sact, instead of a > statically allocated array as all other platforms have. It's not > likely to be large, and the size is known at compile time, so there > seems to be no good reason for this. > > * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for > jvmsigs, as aix and solaris do. This is a less robust solution, and > the added checks show that it has failed in the past. Now all > platforms use sigset_t/sigismember(). > > Also worth noting: > > * Solaris is not using pthreads, but it's own thread library, which > accounts for most of the #ifdef SOLARIS. > > * In general, if an implementation was needed on one platform, but has > no effect or is harmless on others, I've kept it on all platforms > instead of sprinkling the code with #ifdefs. > > To facilitate code review, here is a specially crafted webrev that > shows the differences compared to each of the individual, original > per-OS versions of jsig.c: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 > > /Magnus From thomas.stuefe at gmail.com Tue Mar 27 16:24:32 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 27 Mar 2018 18:24:32 +0200 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: References: Message-ID: Hi Magnus, just a cursory look, will look in greater detail tomorrow. This is good, thanks for doing this. As I wrote offlist, please remove the painfully wrong AIX "workarounds". I do not know why we did this - the original code is quite old - my assumption is that dlsym(RTLD_NEXT) was not working as expected on older AIX versions. Well, it should work now according to IBMs manpages. Will test later. __thread is not Posix. I would prefer pthread_get/set_specific instead, which is more portable. Thanks! Thomas On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > When I was about to update jsig.c, I noticed that the four copies for aix, > linux, macosx and solaris were basically the same, with only small > differences. Some of the differences were not even well motivated, but were > likely the result of this code duplication causing the code to diverge. > > A better solution is to unify them all into a single unix version, with > the few platform-specific changes handled on a per-platform basis. > > I've made the following notable changes: > > * I have removed the version check for Solaris. All other platforms seem > to do fine without it, and in general, we don't mistrust other JDK > libraries. An alternative is to add this version check to all other > platforms instead. If you think this is the correct course of action, let > me know and I'll fix it. > > * Solaris used to have a dynamically allocated sact, instead of a > statically allocated array as all other platforms have. It's not likely to > be large, and the size is known at compile time, so there seems to be no > good reason for this. > > * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for > jvmsigs, as aix and solaris do. This is a less robust solution, and the > added checks show that it has failed in the past. Now all platforms use > sigset_t/sigismember(). > > Also worth noting: > > * Solaris is not using pthreads, but it's own thread library, which > accounts for most of the #ifdef SOLARIS. > > * In general, if an implementation was needed on one platform, but has no > effect or is harmless on others, I've kept it on all platforms instead of > sprinkling the code with #ifdefs. > > To facilitate code review, here is a specially crafted webrev that shows > the differences compared to each of the individual, original per-OS > versions of jsig.c: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/ > webrev.03 > > /Magnus > From edward.nevill at gmail.com Tue Mar 27 18:12:02 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 27 Mar 2018 19:12:02 +0100 Subject: RFR: 8199138: Add RISC-V support to Zero In-Reply-To: <62079618-0fdd-af0b-a3ee-3134555326bb@physik.fu-berlin.de> References: <1521313360.26308.4.camel@gmail.com> <259e05b8-dbb1-4aa4-f451-6b7078eeb2ff@oracle.com> <1521554055.3029.4.camel@gmail.com> <9b675cad-0aec-dfbe-1540-15417b58aaea@physik.fu-berlin.de> <1522139039.7098.11.camel@gmail.com> <62079618-0fdd-af0b-a3ee-3134555326bb@physik.fu-berlin.de> Message-ID: <1522174322.23521.4.camel@gmail.com> On Tue, 2018-03-27 at 17:46 +0900, John Paul Adrian Glaubitz wrote: > On 03/27/2018 05:23 PM, Edward Nevill wrote: > > Sorry for the delay. I was doing another test build on qemu which takes about 3 days. > > > > > What confuses me: Why RISCV here and not RISCV64? > > In particular this hunk: > > @@ -1758,6 +1761,7 @@ > {EM_PARISC, EM_PARISC, ELFCLASS32, ELFDATA2MSB, (char*)"PARISC"}, > {EM_68K, EM_68K, ELFCLASS32, ELFDATA2MSB, (char*)"M68k"}, > {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"}, > + {EM_RISCV, EM_RISCV, ELFCLASS64, ELFDATA2LSB, (char*)"RISCV"}, > }; > > I know there is already 32-bit RISC-V and there are actually plans for > using it. So, it looks to me you would be breaking 32-bit RISC-V here. > We could do something like {EM_RISCV, EM_RISCV, LP64_ONLY(ELFCLASS64) NOT_LP64(ELFCLASS32), ELFDATA2LSB, (char*)"RISCV"}, Would this work? All the best, Ed. From martinrb at google.com Tue Mar 27 19:35:46 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 27 Mar 2018 12:35:46 -0700 Subject: a.out left in root directory when configuring --with-toolchain-type=clang Message-ID: I notice that running bash ./configure ... leaves an a.out file in the root directory of the jdk, but only after adding configure flags --with-toolchain-type=clang --with-toolchain-path=/usr/lib/llvm-3.9/bin (i.e. not when building with default gcc) Probably there's a test compilation whose output does not go into the build/ directory, and whose output is not cleaned up. From erik.joelsson at oracle.com Tue Mar 27 20:11:28 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 27 Mar 2018 13:11:28 -0700 Subject: a.out left in root directory when configuring --with-toolchain-type=clang In-Reply-To: References: Message-ID: <5b3e29c0-be0f-c39e-417d-d65f542328dc@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8200267 On 2018-03-27 12:35, Martin Buchholz wrote: > I notice that running bash ./configure ... leaves an a.out file in the root > directory of the jdk, but only after adding configure flags > > --with-toolchain-type=clang --with-toolchain-path=/usr/lib/llvm-3.9/bin > > (i.e. not when building with default gcc) > > Probably there's a test compilation whose output does not go into the > build/ directory, and whose output is not cleaned up. From david.holmes at oracle.com Tue Mar 27 23:03:31 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Mar 2018 09:03:31 +1000 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: References: Message-ID: <822a1e8e-9fc9-9475-7a11-b56eaa291184@oracle.com> Hi Magnus, I appreciate what you are trying to do here but there are reasons this kind of cleanup keeps getting deferred :) - it's not trivial and deals with really old code that isn't always clear. You may have bitten off more than you want to chew here. (And I'm strapped for time to work through this with you - sorry.) On the positive side you can use the pthread functions on Solaris so no need to special case for that. However there are still a number of issues: 52 #ifndef NSIG 53 #define NSIG SIGRTMAX 54 #endif SIGRTMAX is Solaris only, but even on Solaris NSIG might be defined (it's conditional in sys/signal.h but I don't know when the conditions are enabled). 56 static struct sigaction sact[NSIG]; SIGRTMAX is a macro not a constant so you can't declare a static array using it. You would need to malloc the array as done on Solaris. 58 static __thread bool reentry = false; /* prevent reentry deadlock (per-thread) */ I didn't realize this was in the OSX version as we don't unconditionally use compiler-based thread locals. I would make this field and its use OSX specific 148 #ifdef SOLARIS 149 sact[sig].sa_flags = SA_NODEFER; 150 if (sig != SIGILL && sig != SIGTRAP && sig != SIGPWR) { 151 sact[sig].sa_flags |= SA_RESETHAND; 152 } 153 #else I'd have to do some research to see why this is needed so best to keep it. 178 #ifdef SOLARIS 179 if (is_sigset && sigblocked) { 180 /* We won't honor the SIG_HOLD request to change the signal mask */ 181 oldhandler = SIG_HOLD; 182 } 183 #endif Ditto. More below ... On 27/03/2018 7:42 PM, Magnus Ihse Bursie wrote: > When I was about to update jsig.c, I noticed that the four copies for > aix, linux, macosx and solaris were basically the same, with only small > differences. Some of the differences were not even well motivated, but > were likely the result of this code duplication causing the code to > diverge. > > A better solution is to unify them all into a single unix version, with > the few platform-specific changes handled on a per-platform basis. > > I've made the following notable changes: > > * I have removed the version check for Solaris. All other platforms seem > to do fine without it, and in general, we don't mistrust other JDK > libraries. An alternative is to add this version check to all other > platforms instead. If you think this is the correct course of action, > let me know and I'll fix it. That's fine. I actually thought this had gone. Or it may be we have a bug to clean this up. Which reminds me - there may be a number of existing bugs that get handled by the changes you're making. But there may still be open bugs that need fixing. > * Solaris used to have a dynamically allocated sact, instead of a > statically allocated array as all other platforms have. It's not likely > to be large, and the size is known at compile time, so there seems to be > no good reason for this. See above. If you didn't get a compile-time error here then it's likely NSIG was already defined. > cat sig.c #include static int sigs[SIGRTMAX]; int main(int argc, char* argv[]) { sigs[0] = 1; } > CC -c sig.c "sig.c", line 3: Error: An integer constant expression is required within the array subscript operator. 1 Error(s) detected. > * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for > jvmsigs, as aix and solaris do. This is a less robust solution, and the > added checks show that it has failed in the past. Now all platforms use > sigset_t/sigismember(). Probably historical (macosx copied linux) and a good change to make. That said I have to wonder why we didn't make it when we put in the guards on the size. > Also worth noting: > > * Solaris is not using pthreads, but it's own thread library, which > accounts for most of the #ifdef SOLARIS. Not needed as above. > * In general, if an implementation was needed on one platform, but has > no effect or is harmless on others, I've kept it on all platforms > instead of sprinkling the code with #ifdefs. That depends on your own knowledge/assumptions about the behaviour. I'd want to check each such case to verify that is the case. As above the use of __thread with "reentry" is not something to use unconditionally without closer examination. > To facilitate code review, here is a specially crafted webrev that shows > the differences compared to each of the individual, original per-OS > versions of jsig.c: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 Appreciated, but still very hard to see when a feature from one OS is now being used by all. I'd be less concerned if we had extensive testing here but I don't think we do, so any issues only turn up when something that's been working since Java 1.4 suddenly stops working. What testing was done? Thanks, David ----- > Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 > > /Magnus From weijun.wang at oracle.com Tue Mar 27 23:52:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 28 Mar 2018 07:52:40 +0800 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com> Message-ID: > On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie wrote: > > https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth There is only one function to export and it already has JNIEXPORT, so you can just remove the new $(LIBJAAS_CFLAGS) [1]. Are you going to update your webrev? Thanks Max [1] http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html From magnus.ihse.bursie at oracle.com Wed Mar 28 09:14:47 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Mar 2018 11:14:47 +0200 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: <822a1e8e-9fc9-9475-7a11-b56eaa291184@oracle.com> References: <822a1e8e-9fc9-9475-7a11-b56eaa291184@oracle.com> Message-ID: <76a473b8-276c-2228-84b9-55cc25d36ff1@oracle.com> On 2018-03-28 01:03, David Holmes wrote: > Hi Magnus, > > I appreciate what you are trying to do here but there are reasons this > kind of cleanup keeps getting deferred :) - it's not trivial and deals > with really old code that isn't always clear. You may have bitten off > more than you want to chew here. (And I'm strapped for time to work > through this with you - sorry.) *sighs* Yeah, I'm starting to realize that. I thought it was more or less trivial, and I didn't want to add new duplicated code. Let's see if I can give reasonable answers to your questions here, but if that's not enough, I'll drop this. > On the positive side you can use the pthread functions on Solaris so > no need to special case for that. Ok! > > However there are still a number of issues: > > ? 52 #ifndef NSIG > ? 53?? #define NSIG SIGRTMAX > ? 54 #endif > > SIGRTMAX is Solaris only, but even on Solaris NSIG might be defined > (it's conditional in sys/signal.h but I don't know when the conditions > are enabled). > > ?56 static struct sigaction sact[NSIG]; > > SIGRTMAX is a macro not a constant so you can't declare a static array > using it. You would need to malloc the array as done on Solaris. Ah, I see. That explains the special code in Solaris. > > ?58 static __thread bool reentry = false; /* prevent reentry deadlock > (per-thread) */ > > I didn't realize this was in the OSX version as we don't > unconditionally use compiler-based thread locals. I would make this > field and its use OSX specific Ok. > > 148 #ifdef SOLARIS > ?149???? sact[sig].sa_flags = SA_NODEFER; > ?150???? if (sig != SIGILL && sig != SIGTRAP && sig != SIGPWR) { > ?151?????? sact[sig].sa_flags |= SA_RESETHAND; > ?152???? } > ?153 #else > > I'd have to do some research to see why this is needed so best to keep > it. > > 178 #ifdef SOLARIS > ?179???? if (is_sigset && sigblocked) { > ?180?????? /* We won't honor the SIG_HOLD request to change the signal > mask */ > ?181?????? oldhandler = SIG_HOLD; > ?182???? } > ?183 #endif > > Ditto. > > More below ... > > On 27/03/2018 7:42 PM, Magnus Ihse Bursie wrote: >> When I was about to update jsig.c, I noticed that the four copies for >> aix, linux, macosx and solaris were basically the same, with only >> small differences. Some of the differences were not even well >> motivated, but were likely the result of this code duplication >> causing the code to diverge. >> >> A better solution is to unify them all into a single unix version, >> with the few platform-specific changes handled on a per-platform basis. >> >> I've made the following notable changes: >> >> * I have removed the version check for Solaris. All other platforms >> seem to do fine without it, and in general, we don't mistrust other >> JDK libraries. An alternative is to add this version check to all >> other platforms instead. If you think this is the correct course of >> action, let me know and I'll fix it. > > That's fine. I actually thought this had gone. Or it may be we have a > bug to clean this up. Which reminds me - there may be a number of > existing bugs that get handled by the changes you're making. But there > may still be open bugs that need fixing. I searched JBS for "jsig" and "libjsig". Then I screened all hits, and filtered out all bugs where this was just mentioned in passing. In the end, I found only this which has bearing to the current changes: https://bugs.openjdk.java.net/browse/JDK-8170639 "[Linux] jsig is limited to a maximum of 64 signals" I also found a couple of bugs related to build (JDK-8164790, JDK-8146563) and a discussion about using __thread (JDK-8137018). JDK-8170639 will be fixed by the propsed patch. > >> * Solaris used to have a dynamically allocated sact, instead of a >> statically allocated array as all other platforms have. It's not >> likely to be large, and the size is known at compile time, so there >> seems to be no good reason for this. > > See above. If you didn't get a compile-time error here then it's > likely NSIG was already defined. > > > cat sig.c > #include > > static int sigs[SIGRTMAX]; > > int main(int argc, char* argv[]) { > ? sigs[0] = 1; > } > > ?> CC -c sig.c > "sig.c", line 3: Error: An integer constant expression is required > within the array subscript operator. > 1 Error(s) detected. Yes, you are right, NSIG is defined when I compile on Solaris. I looked into the conditionals, but I could not either easily determine when they are true. But maybe that's not really necessary to do? Most of the system provided functions are guarded by feature tests, but we don't normally verify that we fulfill the proper conditions, but just use them, and if it works, we're happy. (That said, we should probably be more prudent on how we use feature/standard defines...) > >> * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for >> jvmsigs, as aix and solaris do. This is a less robust solution, and >> the added checks show that it has failed in the past. Now all >> platforms use sigset_t/sigismember(). > > Probably historical (macosx copied linux) and a good change to make. > That said I have to wonder why we didn't make it when we put in the > guards on the size. Maybe the developer putting in the guards didn't know about sigismember()? And since it was not obvious how this was done on other platform, that probably seemed like a good idea given the pre-existing code on linux. > >> Also worth noting: >> >> * Solaris is not using pthreads, but it's own thread library, which >> accounts for most of the #ifdef SOLARIS. > > Not needed as above. > >> * In general, if an implementation was needed on one platform, but >> has no effect or is harmless on others, I've kept it on all platforms >> instead of sprinkling the code with #ifdefs. > > That depends on your own knowledge/assumptions about the behaviour. Of course. :-) > I'd want to check each such case to verify that is the case. Sure. I'll list them here: * booleans were handled differently. On macosx, stdbool.h was included, other platforms used? #define bool int. I researched stdbool.h, and it is part of the C99 requirement, so I replaced it with: #if (__STDC_VERSION__ >= 199901L) #include #else #define bool int #define true 1 #define false 0 #endif on all platforms. On macosx, the combinations of flags we're sending to clang makes it C99 compatible. (I have not looked into detail on why/how this is so. The only thing I know from memory is that on solstudio we explicitly forbid it from being C99.) * The reentry code was only used on macosx. I'll return it to macosx specific with ifdefs. * On AIX, the type "signal_t" was already used in signal.h, so they had to rename it. I renamed it across all platforms, to "signal_function_t". * On solaris, save_signal_handler() needed an additional argument is_sigset. I'm passing this argument on all platform, even if it's not needed. * Only solaris needed the sigblocked test in set_signal. I kept the #ifdef around the code that set the oldhandler to SIG_HOLD, but the actual test for setting sigblocked needed to be done earlier: if (is_sigset) { sigblocked = sigismember(&(sact[sig].sa_mask), sig); } While useless on other platforms, I didn't think it was worth clogging the code with more #ifdefs. > As above the use of __thread with "reentry" is not something to use > unconditionally without closer examination. Sure. I'll make them macosx specific again. > >> To facilitate code review, here is a specially crafted webrev that >> shows the differences compared to each of the individual, original >> per-OS versions of jsig.c: >> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 > > Appreciated, but still very hard to see when a feature from one OS is > now being used by all. > > I'd be less concerned if we had extensive testing here but I don't > think we do, so any issues only turn up when something that's been > working since Java 1.4 suddenly stops working. What testing was done? I've run hotspot/jtreg/runtime/XCheckJniJsig, and the closed Oracle tests that test libjsig, on all platforms. (mach5 --job hs-tier5-rt,hs-tier1) I have not looked in detail into these tests, so I cannot say how well they test libjsig. I just searched the tests for whatever used libjsig. /Magnus > > Thanks, > David > ----- > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 >> >> /Magnus From magnus.ihse.bursie at oracle.com Wed Mar 28 10:15:03 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Mar 2018 12:15:03 +0200 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: References: Message-ID: <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com> On 2018-03-27 18:24, Thomas St?fe wrote: > Hi Magnus, > > just a cursory look, will look in greater detail tomorrow. > > This is good, thanks for doing this. > > As I wrote offlist, please remove the painfully wrong AIX > "workarounds". I do not know why we did this - the original code is > quite old - my assumption is that dlsym(RTLD_NEXT) was not working as > expected on older AIX versions. Well, it should work now according to > IBMs manpages. Will test later. Ok. > > __thread is not Posix. I would prefer pthread_get/set_specific > instead, which is more portable. I have surrounded this code with #ifdef MACOSX now. Here is an updated webrev. It includes the changes requested by you and David: * No more AIX workarounds * Solaris use pthreads * The "reentry" code is #ifdef MACOSX. I also assumed that NSIG is available and working on Solaris. I'll let David decide if he is happy with that. The alternative is to go back to the Solaris-specific code that allocates sact on the heap. Webrev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05 Once again, here is also a webrev that shows the difference between the original files and the new, unified file. Even if it's hard to read, it shows what the effects will be for each platform. Webrev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/ /Magnus > > Thanks! > > Thomas > > > > > > On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie > > > wrote: > > When I was about to update jsig.c, I noticed that the four copies > for aix, linux, macosx and solaris were basically the same, with > only small differences. Some of the differences were not even well > motivated, but were likely the result of this code duplication > causing the code to diverge. > > A better solution is to unify them all into a single unix version, > with the few platform-specific changes handled on a per-platform > basis. > > I've made the following notable changes: > > * I have removed the version check for Solaris. All other > platforms seem to do fine without it, and in general, we don't > mistrust other JDK libraries. An alternative is to add this > version check to all other platforms instead. If you think this is > the correct course of action, let me know and I'll fix it. > > * Solaris used to have a dynamically allocated sact, instead of a > statically allocated array as all other platforms have. It's not > likely to be large, and the size is known at compile time, so > there seems to be no good reason for this. > > * Linux and macosx used a uint32_t/uint64_t instead of sigset_t > for jvmsigs, as aix and solaris do. This is a less robust > solution, and the added checks show that it has failed in the > past. Now all platforms use sigset_t/sigismember(). > > Also worth noting: > > * Solaris is not using pthreads, but it's own thread library, > which accounts for most of the #ifdef SOLARIS. > > * In general, if an implementation was needed on one platform, but > has no effect or is harmless on others, I've kept it on all > platforms instead of sprinkling the code with #ifdefs. > > To facilitate code review, here is a specially crafted webrev that > shows the differences compared to each of the individual, original > per-OS versions of jsig.c: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 > > > /Magnus > > From magnus.ihse.bursie at oracle.com Wed Mar 28 10:31:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Mar 2018 12:31:49 +0200 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com> Message-ID: <3fce1a22-39e4-b8ba-0713-03cd013a6709@oracle.com> On 2018-03-28 01:52, Weijun Wang wrote: > >> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth > There is only one function to export and it already has JNIEXPORT, so you can just remove the new $(LIBJAAS_CFLAGS) [1]. Ok, thanks Max! > Are you going to update your webrev? Here is a new webrev. It includes your recommended change in Lib-jdk.security.auth.gmk. It is also updated to keep track of changes in shared native libraries that has happend in the mainline since my first webrev. Most notably is the addition of libjsig. For now, I have just added the JNIEXPORT markers for the platforms that need it. Hopefully we can unify libjsig across all platforms, but that seems to be more complicated than I thought, so that'll have to wait. I have also recieved word from Phil Race that there were no testing issues for client, so he's happy as well. Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.03 /Magnus > > Thanks > Max > > [1] http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html From magnus.ihse.bursie at oracle.com Wed Mar 28 10:46:43 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Mar 2018 12:46:43 +0200 Subject: RFR: JDK-8200357 Inline SoundLibraries.gmk into Lib-java.desktop.gmk Message-ID: <6b143a0e-dca2-f93f-ff68-6c98e9ea22cd@oracle.com> With some further simplifications, the code for building libjsound is very small. There is no longer any reason to have that in a separate file. Instead it should be inlined into Lib-java.desktop.gmk. This patch also includes code to stop building libjsig on AIX, as requested by Thomas St?fe. Bug: https://bugs.openjdk.java.net/browse/JDK-8200357 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200357-inline-SoundLibraries/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Mar 28 11:08:28 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Mar 2018 13:08:28 +0200 Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables Message-ID: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> This patch removes mapfiles for the JDK executables (launchers). There's really no reason to have mapfiles in the first place for executables. Since no-one is linking to them, what symbols they export is immaterial. Bug: https://bugs.openjdk.java.net/browse/JDK-8200358 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.01 /Magnus From martinrb at google.com Wed Mar 28 12:19:44 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Mar 2018 05:19:44 -0700 Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables In-Reply-To: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> Message-ID: I'm not sure about this. IIRC the AIX linker is able to use executables as a build-time input. Maybe our AIX maintainers have some expertise here. I think the _dynamic_ linker will see symbols in the executable. Resolving them is likely to be strictly more work at startup, and it is likely that the symbols are visible to dlsym(NULL ...) We have local patches at Google that involve adding symbols to these mapfiles to increase visibility to dlsym. Maintaining mapfiles is no fun, but the precise definition of symbol visibility seems in the Spirit of Java. On Wed, Mar 28, 2018 at 4:08 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > This patch removes mapfiles for the JDK executables (launchers). There's > really no reason to have mapfiles in the first place for executables. Since > no-one is linking to them, what symbols they export is immaterial. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200358 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher > -mapfiles/webrev.01 > > /Magnus > > From thomas.stuefe at gmail.com Wed Mar 28 13:19:43 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 28 Mar 2018 15:19:43 +0200 Subject: RFR: JDK-8200357 Inline SoundLibraries.gmk into Lib-java.desktop.gmk In-Reply-To: <6b143a0e-dca2-f93f-ff68-6c98e9ea22cd@oracle.com> References: <6b143a0e-dca2-f93f-ff68-6c98e9ea22cd@oracle.com> Message-ID: Thanks Magnus, this fixes AIX (in the sense that it does not attempt anymore to build libjsound). Best Regards, Thomas On Wed, Mar 28, 2018 at 12:46 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > With some further simplifications, the code for building libjsound is very > small. There is no longer any reason to have that in a separate file. > Instead it should be inlined into Lib-java.desktop.gmk. > > This patch also includes code to stop building libjsig on AIX, as > requested by Thomas St?fe. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200357 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200357-inline-SoundLib > raries/webrev.01 > > /Magnus > > From robin.westberg at oracle.com Wed Mar 28 13:43:02 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 28 Mar 2018 15:43:02 +0200 Subject: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX In-Reply-To: References: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> Message-ID: <8C4AC71F-25E8-4DD2-9DBC-D452118464C6@oracle.com> Hi Magnus, Thanks for the review! Best regards, Robin > On 26 Mar 2018, at 23:24, Magnus Ihse Bursie wrote: > > On 2018-03-26 17:01, Robin Westberg wrote: >> Hi all, >> >> Please review this small change that defines the NOMINMAX macro when building HotSpot on Windows. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8199619 >> Webrev: http://cr.openjdk.java.net/~rwestberg/8199619/webrev.00/ > Looks good to me. > > /Magnus > >> Testing: building with/without precompiled headers, hs-tier1 >> >> Best regards, >> Robin > From robin.westberg at oracle.com Wed Mar 28 13:43:07 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 28 Mar 2018 15:43:07 +0200 Subject: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX In-Reply-To: <7e318372-2c04-be32-dd0d-7c0fe092c98f@oracle.com> References: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> <7e318372-2c04-be32-dd0d-7c0fe092c98f@oracle.com> Message-ID: <08B716A1-C16E-494D-9C14-11FA4A81387F@oracle.com> Hi Erik, Thanks for reviewing! Best regards, Robin > On 26 Mar 2018, at 17:50, Erik Joelsson wrote: > > Looks good. > > /Erik > > > On 2018-03-26 08:01, Robin Westberg wrote: >> Hi all, >> >> Please review this small change that defines the NOMINMAX macro when building HotSpot on Windows. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8199619 >> Webrev: http://cr.openjdk.java.net/~rwestberg/8199619/webrev.00/ >> Testing: building with/without precompiled headers, hs-tier1 >> >> Best regards, >> Robin > From robin.westberg at oracle.com Wed Mar 28 13:43:13 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 28 Mar 2018 15:43:13 +0200 Subject: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX In-Reply-To: <446F6608-6FC0-4962-AAD3-CC8CF36F60F7@oracle.com> References: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> <446F6608-6FC0-4962-AAD3-CC8CF36F60F7@oracle.com> Message-ID: Hi Kim, > On 26 Mar 2018, at 18:34, Kim Barrett wrote: > >> On Mar 26, 2018, at 11:01 AM, Robin Westberg wrote: >> >> Hi all, >> >> Please review this small change that defines the NOMINMAX macro when building HotSpot on Windows. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8199619 >> Webrev: http://cr.openjdk.java.net/~rwestberg/8199619/webrev.00/ >> Testing: building with/without precompiled headers, hs-tier1 >> >> Best regards, >> Robin > > Looks good. Thanks for reviewing! > This change will have a (easy to resolve) merge conflict with your fix for JDK-8199736, right? Indeed, the flag definitions should go on a single line I think. I?ll try to get this one in first and rebase 8199736 afterwards. So, if anyone would be willing to sponsor this change, here?s an updated webrev with a proper mercurial changeset (no other changes): http://cr.openjdk.java.net/~rwestberg/8199619/webrev.01/ Best regards, Robin From robin.westberg at oracle.com Wed Mar 28 13:43:22 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 28 Mar 2018 15:43:22 +0200 Subject: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including windows.h In-Reply-To: <29b9be70-5855-fa0d-e1b2-73565e76d052@oracle.com> References: <7F114FA8-59F0-42F1-A0B8-33D8C22DE81A@oracle.com> <9DA6FFD9-1DD0-4C39-9D81-DF6FA49EDF45@oracle.com> <29b9be70-5855-fa0d-e1b2-73565e76d052@oracle.com> Message-ID: <6CE48055-3AEA-4766-9C90-E0071CCEDB58@oracle.com> Hi David, Thanks for reviewing! I?ll delay progressing this one a bit until 8199619 is integrated. Best regards, Robin > On 27 Mar 2018, at 02:57, David Holmes wrote: > > Looks good to me. > > Thanks, > David > > On 27/03/2018 1:01 AM, Robin Westberg wrote: >> Hi David, >> Thanks for taking a look! >>> On 26 Mar 2018, at 01:03, David Holmes > wrote: >>> >>> Hi Robin, >>> >>> On 23/03/2018 10:37 PM, Robin Westberg wrote: >>>> Hi Kim & Erik, >>>> Certainly makes sense to define it from the build system, I?ve updated the patch accordingly: >>>> Full: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/ >>>> Incremental: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/ >>> >>> I'm a little unclear on the hotspot changes. If we define WIN32_LEAN_AND_MEAN then certain APIs like sockets are excluded from windows.h so we then have to include the specific header files like winsock2.h - is that right? >> Yep that?s correct, headers like winsock, dde, ole, shellapi and a few other uncommon ones are no longer included from windows.h when this is defined. >>> src/hotspot/share/interpreter/bytecodes.cpp >>> >>> I'm curious about this change. u_short comes from types.h on non-Windows, is it simply missing on Windows (at least once we have WIN32_LEAN_AND_MEAN defined) ? >> Yeah, on Windows these comes from winsock(2).h: >> /* >> * Basic system type definitions, taken from the BSD file sys/types.h. >> */ >> typedef unsigned char u_char; >> typedef unsigned short u_short; >> typedef unsigned int u_int; >> typedef unsigned long u_long; >> I noticed that one of these (u_char) is also defined in globalDefinitions.hpp so could perhaps define u_short there, or include winsock2.h globally again. But since it was only used in a single place in the existing code it seemed simple enough to just expand the typedef there. >>> src/hotspot/share/utilities/ostream.cpp >>> >>> 1029 #endif >>> 1030 #if defined(_WINDOWS) >>> >>> Using elif could be marginally faster given the two sets of conditions are mutually exclusive. >> Good point, will change it. >> I also had to move the flag definition to adapt to the latest changes in the hs repo, cc?ing build-dev again to make sure I got it right. >> Updated webrev (full): http://cr.openjdk.java.net/~rwestberg/8199736/webrev.02/ >> Updated webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01-02/ >> Best regards, >> Robin >>> >>> Thanks, >>> David >>> >>>> (Not quite sure if the definition belongs where I put it or a bit later where most other windows-specific JVM flags are defined, but seemed reasonable to put it close to where it is defined for the JDK libraries). >>>> Best regards, >>>> Robin >>>>> On 22 Mar 2018, at 16:52, Kim Barrett > wrote: >>>>> >>>>>> On Mar 22, 2018, at 10:34 AM, Robin Westberg > wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Please review the following change that defines WIN32_LEAN_AND_MEAN [1] before including windows.h. This marginally improves build times, and makes it possible to include winsock2.h. >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199736 >>>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/ >>>>>> Testing: hs-tier1 >>>>>> >>>>>> Best regards, >>>>>> Robin >>>>>> >>>>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745%28v=vs.85%29.aspx#faster_builds_with_smaller_header_files >>>>> >>>>> I think the addition of the WIN32_LEAN_AND_MEAN definition should be done through the build >>>>> system, so that it applies everywhere. >>>>> From thomas.stuefe at gmail.com Wed Mar 28 14:56:42 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 28 Mar 2018 16:56:42 +0200 Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables In-Reply-To: References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> Message-ID: On Wed, Mar 28, 2018 at 2:19 PM, Martin Buchholz wrote: > I'm not sure about this. > > IIRC the AIX linker is able to use executables as a build-time input. > Maybe our AIX maintainers have some expertise here. > > I am quite sure we do not do that in the VM. I'm running a test build with your patch. Thanks, Thomas > I think the _dynamic_ linker will see symbols in the executable. Resolving > them is likely to be strictly more work at startup, and it is likely that > the symbols are visible to dlsym(NULL ...) > > We have local patches at Google that involve adding symbols to these > mapfiles to increase visibility to dlsym. Maintaining mapfiles is no fun, > but the precise definition of symbol visibility seems in the Spirit of > Java. > > On Wed, Mar 28, 2018 at 4:08 AM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > > > This patch removes mapfiles for the JDK executables (launchers). There's > > really no reason to have mapfiles in the first place for executables. > Since > > no-one is linking to them, what symbols they export is immaterial. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200358 > > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher > > -mapfiles/webrev.01 > > > > /Magnus > > > > > From erik.joelsson at oracle.com Wed Mar 28 15:45:06 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Mar 2018 08:45:06 -0700 Subject: RFR: JDK-8200357 Inline SoundLibraries.gmk into Lib-java.desktop.gmk In-Reply-To: <6b143a0e-dca2-f93f-ff68-6c98e9ea22cd@oracle.com> References: <6b143a0e-dca2-f93f-ff68-6c98e9ea22cd@oracle.com> Message-ID: <3c98feb3-e2d5-10a0-d98e-170d7452603b@oracle.com> Looks good to me. /Erik On 2018-03-28 03:46, Magnus Ihse Bursie wrote: > With some further simplifications, the code for building libjsound is > very small. There is no longer any reason to have that in a separate > file. Instead it should be inlined into Lib-java.desktop.gmk. > > This patch also includes code to stop building libjsig on AIX, as > requested by Thomas St?fe. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200357 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200357-inline-SoundLibraries/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Wed Mar 28 15:47:13 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Mar 2018 08:47:13 -0700 Subject: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX In-Reply-To: References: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> <446F6608-6FC0-4962-AAD3-CC8CF36F60F7@oracle.com> Message-ID: I will sponsor the change. /Erik On 2018-03-28 06:43, Robin Westberg wrote: > Hi Kim, > >> On 26 Mar 2018, at 18:34, Kim Barrett wrote: >> >>> On Mar 26, 2018, at 11:01 AM, Robin Westberg wrote: >>> >>> Hi all, >>> >>> Please review this small change that defines the NOMINMAX macro when building HotSpot on Windows. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199619 >>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199619/webrev.00/ >>> Testing: building with/without precompiled headers, hs-tier1 >>> >>> Best regards, >>> Robin >> Looks good. > Thanks for reviewing! > >> This change will have a (easy to resolve) merge conflict with your fix for JDK-8199736, right? > Indeed, the flag definitions should go on a single line I think. I?ll try to get this one in first and rebase 8199736 afterwards. > > So, if anyone would be willing to sponsor this change, here?s an updated webrev with a proper mercurial changeset (no other changes): > http://cr.openjdk.java.net/~rwestberg/8199619/webrev.01/ > > Best regards, > Robin > From thomas.stuefe at gmail.com Wed Mar 28 17:47:12 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 28 Mar 2018 19:47:12 +0200 Subject: RFR: JDK-8200357 Inline SoundLibraries.gmk into Lib-java.desktop.gmk In-Reply-To: References: <6b143a0e-dca2-f93f-ff68-6c98e9ea22cd@oracle.com> Message-ID: Oh, change also looks fine to me. ..Thomas On Wed, Mar 28, 2018 at 3:19 PM, Thomas St?fe wrote: > Thanks Magnus, > > this fixes AIX (in the sense that it does not attempt anymore to build > libjsound). > > Best Regards, Thomas > > On Wed, Mar 28, 2018 at 12:46 PM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> With some further simplifications, the code for building libjsound is >> very small. There is no longer any reason to have that in a separate file. >> Instead it should be inlined into Lib-java.desktop.gmk. >> >> This patch also includes code to stop building libjsig on AIX, as >> requested by Thomas St?fe. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200357 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200357-inline-SoundLib >> raries/webrev.01 >> >> /Magnus >> >> > From magnus.ihse.bursie at oracle.com Wed Mar 28 19:07:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Mar 2018 21:07:35 +0200 Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables In-Reply-To: References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> Message-ID: On 2018-03-28 14:19, Martin Buchholz wrote: > I'm not sure about this. > > IIRC the AIX linker is able to use executables as a build-time input.? > Maybe our AIX maintainers have some expertise here. As you heard from Thomas, this does not seem to be a problem. > > I think the _dynamic_ linker will see symbols in the executable.? > Resolving them is likely to be strictly more work at startup, and it > is likely that the symbols are visible to dlsym(NULL ...) > > We have local patches at Google that involve adding symbols to these > mapfiles to increase visibility to dlsym. Maintaining mapfiles is no > fun, but the precise definition of symbol visibility seems in the > Spirit of Java. Maintaining map files is no fun. Yes indeed. I don't think the current presense of mapfiles is intended to be the "Spirit of Java", but rather "everything in the build sucked back when Java was created" (or perhaps "Everthing in the build was designed from how the programmers thought that you should do things on Solaris" -- which may or may not mean the same thing as the previous sentense ;-)). Are you loading symbols from *executables* at Google? You sure about that? Anyway, with this patch all symbols in executables will be visible, so there should be no problem anyway. /Magnus > > On Wed, Mar 28, 2018 at 4:08 AM, Magnus Ihse Bursie > > > wrote: > > This patch removes mapfiles for the JDK executables (launchers). > There's really no reason to have mapfiles in the first place for > executables. Since no-one is linking to them, what symbols they > export is immaterial. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200358 > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.01 > > > /Magnus > > From thomas.stuefe at gmail.com Wed Mar 28 19:21:06 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 28 Mar 2018 21:21:06 +0200 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com> References: <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com> Message-ID: Hi Magnus, I had a closer look at the changes, especially at jsig.c. It all comes slowly back. The AIX version has been almost comically wrong. About NSIG, I remember that we had coding in our port which needed to know the max number of signals, and this was surprisingly hard since on some platforms. Sometimes NSIG does not contain the real time signals. Or it did not even exist. I think we ended up hardcoding an own max signal limit . So wherever you access sact with a signal number as index, I'd like to see a bounds check. Or at least an assert - since this is plain C, a C-assert would do for me (see http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html). This also would guard against user parameter error. I also wonder whether this coding could not be simplified quite a bit by not calling the OS versions of signal() at all but instead doing all signal work via OS sigaction: after all, signal() can be implemented in terms of sigaction() (with the flag SA_SIGINFO cleared), and so can sigset(). This would remove the necessity of reentry-handling for macos, and also remove the need for save_signal_handler(). I will test this version on AIX tomorrow. After that, I'll have some vacation, but maybe someone else from my team will take over. I like this work, this is a good simplification. Thanks, Thomas On Wed, Mar 28, 2018 at 12:15 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > On 2018-03-27 18:24, Thomas St?fe wrote: > > Hi Magnus, > > just a cursory look, will look in greater detail tomorrow. > > This is good, thanks for doing this. > > As I wrote offlist, please remove the painfully wrong AIX "workarounds". I > do not know why we did this - the original code is quite old - my > assumption is that dlsym(RTLD_NEXT) was not working as expected on older > AIX versions. Well, it should work now according to IBMs manpages. Will > test later. > > Ok. > > > __thread is not Posix. I would prefer pthread_get/set_specific instead, > which is more portable. > > > I have surrounded this code with #ifdef MACOSX now. > > Here is an updated webrev. It includes the changes requested by you and > David: > > * No more AIX workarounds > * Solaris use pthreads > * The "reentry" code is #ifdef MACOSX. > > I also assumed that NSIG is available and working on Solaris. I'll let > David decide if he is happy with that. The alternative is to go back to the > Solaris-specific code that allocates sact on the heap. > > Webrev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify- > libjsig/webrev.05 > > Once again, here is also a webrev that shows the difference between the > original files and the new, unified file. Even if it's hard to read, it > shows what the effects will be for each platform. > > Webrev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify- > libjsig/webrev.04/ > > /Magnus > > > Thanks! > > Thomas > > > > > > On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> When I was about to update jsig.c, I noticed that the four copies for >> aix, linux, macosx and solaris were basically the same, with only small >> differences. Some of the differences were not even well motivated, but were >> likely the result of this code duplication causing the code to diverge. >> >> A better solution is to unify them all into a single unix version, with >> the few platform-specific changes handled on a per-platform basis. >> >> I've made the following notable changes: >> >> * I have removed the version check for Solaris. All other platforms seem >> to do fine without it, and in general, we don't mistrust other JDK >> libraries. An alternative is to add this version check to all other >> platforms instead. If you think this is the correct course of action, let >> me know and I'll fix it. >> >> * Solaris used to have a dynamically allocated sact, instead of a >> statically allocated array as all other platforms have. It's not likely to >> be large, and the size is known at compile time, so there seems to be no >> good reason for this. >> >> * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for >> jvmsigs, as aix and solaris do. This is a less robust solution, and the >> added checks show that it has failed in the past. Now all platforms use >> sigset_t/sigismember(). >> >> Also worth noting: >> >> * Solaris is not using pthreads, but it's own thread library, which >> accounts for most of the #ifdef SOLARIS. >> >> * In general, if an implementation was needed on one platform, but has no >> effect or is harmless on others, I've kept it on all platforms instead of >> sprinkling the code with #ifdefs. >> >> To facilitate code review, here is a specially crafted webrev that shows >> the differences compared to each of the individual, original per-OS >> versions of jsig.c: >> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/w >> ebrev.03 >> >> /Magnus >> > > > From erik.joelsson at oracle.com Wed Mar 28 20:13:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Mar 2018 13:13:47 -0700 Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables In-Reply-To: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> Message-ID: Looks good from a build perspective. /Erik On 2018-03-28 04:08, Magnus Ihse Bursie wrote: > This patch removes mapfiles for the JDK executables (launchers). > There's really no reason to have mapfiles in the first place for > executables. Since no-one is linking to them, what symbols they export > is immaterial. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200358 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Wed Mar 28 20:17:39 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Mar 2018 13:17:39 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <3fce1a22-39e4-b8ba-0713-03cd013a6709@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com> <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com> <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com> <3fce1a22-39e4-b8ba-0713-03cd013a6709@oracle.com> Message-ID: Build changes still look good to me. /Erik On 2018-03-28 03:31, Magnus Ihse Bursie wrote: > On 2018-03-28 01:52, Weijun Wang wrote: >> >>> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie >>> wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8200193 -- for >>> jdk.security.auth >> There is only one function to export and it already has JNIEXPORT, so >> you can just remove the new $(LIBJAAS_CFLAGS) [1]. > Ok, thanks Max! >> Are you going to update your webrev? > Here is a new webrev. It includes your recommended change in > Lib-jdk.security.auth.gmk. > > It is also updated to keep track of changes in shared native libraries > that has happend in the mainline since my first webrev. Most notably > is the addition of libjsig. For now, I have just added the JNIEXPORT > markers for the platforms that need it. Hopefully we can unify libjsig > across all platforms, but that seems to be more complicated than I > thought, so that'll have to wait. > > I have also recieved word from Phil Race that there were no testing > issues for client, so he's happy as well. > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.03 > > /Magnus > >> >> Thanks >> Max >> >> [1] >> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html > From martinrb at google.com Wed Mar 28 20:39:59 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Mar 2018 13:39:59 -0700 Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables In-Reply-To: References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> Message-ID: On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > Anyway, with this patch all symbols in executables will be visible, so > there should be no problem anyway. > The symbols visible in the main executable are a sort-of-public interface. The difference is visible via e.g. nm -D, or any native code that does dlsym(NULL, symbolName) (yes, we do this!). The behavior of native code is likely to be affected if there is a symbol conflict. The larger the exported symbol table, the more overhead there will be at startup (probably). The theory is that changing an interface requires a CSR. Exporting all symbols from a binary makes the product slightly less annoying to maintain while making the end product slightly worse, which is not usually what Java is about. From vladimir.kozlov at oracle.com Wed Mar 28 21:01:22 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Mar 2018 14:01:22 -0700 Subject: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions Message-ID: http://cr.openjdk.java.net/~kvn/8200383/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8200383 Changes for JDK-8200303 added calls to log2f() math function and it hit problem building Hotspot on SPARC - it can't find this function. For Hotspot build on Solaris we had hack to support old Solaris versions which did not have libm.so.2: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/a74480137e6e/make/solaris/makefiles/vm.make#l102 We don't support Solaris 8 and 9 anymore and it is safe to remove the hack. Tested with tier1 Builds and Hotspot testing (similar to submit-hs). -- Thanks, Vladimir From erik.joelsson at oracle.com Wed Mar 28 21:10:41 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Mar 2018 14:10:41 -0700 Subject: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions In-Reply-To: References: Message-ID: <1e2ce416-53b1-c9f4-49d9-84dbd61c64f3@oracle.com> Looks good. /Erik On 2018-03-28 14:01, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8200383/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8200383 > > Changes for JDK-8200303 added calls to log2f() math function and it > hit problem building Hotspot on SPARC - it can't find this function. > > For Hotspot build on Solaris we had hack to support old Solaris > versions which did not have libm.so.2: > > http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/a74480137e6e/make/solaris/makefiles/vm.make#l102 > > > We don't support Solaris 8 and 9 anymore and it is safe to remove the > hack. > > Tested with tier1 Builds and Hotspot testing (similar to submit-hs). > From vladimir.kozlov at oracle.com Wed Mar 28 21:13:10 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Mar 2018 14:13:10 -0700 Subject: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions In-Reply-To: <1e2ce416-53b1-c9f4-49d9-84dbd61c64f3@oracle.com> References: <1e2ce416-53b1-c9f4-49d9-84dbd61c64f3@oracle.com> Message-ID: <168ddf24-a8a3-f86d-a0c9-f49103cd29cc@oracle.com> Thank you, Erik Vladimir On 3/28/18 2:10 PM, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2018-03-28 14:01, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8200383/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8200383 >> >> Changes for JDK-8200303 added calls to log2f() math function and it >> hit problem building Hotspot on SPARC - it can't find this function. >> >> For Hotspot build on Solaris we had hack to support old Solaris >> versions which did not have libm.so.2: >> >> http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/a74480137e6e/make/solaris/makefiles/vm.make#l102 >> >> >> We don't support Solaris 8 and 9 anymore and it is safe to remove the >> hack. >> >> Tested with tier1 Builds and Hotspot testing (similar to submit-hs). >> > From magnus.ihse.bursie at oracle.com Wed Mar 28 21:48:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Mar 2018 23:48:49 +0200 Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables In-Reply-To: References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> Message-ID: On 2018-03-28 22:39, Martin Buchholz wrote: > > > On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie > > > wrote: > > > Anyway, with this patch all symbols in executables will be > visible, so there should be no problem anyway. > > > The symbols visible in the main executable are a sort-of-public > interface.? The difference is visible via e.g. nm -D, or any native > code that does dlsym(NULL, symbolName) (yes, we do this!).? The > behavior of native code is likely to be affected if there is a symbol > conflict.? The larger the exported symbol table, the more overhead > there will be at startup (probably). The theory is that changing an > interface requires a CSR. If I understand your objections correctly, you are claiming (correct me if I'm misunderstanding you): 1) Removing the mapfiles will affect performance negatively 2) The exported symbols from executables are a public API and the change therefore require a CSR. To this I reply: 1) While theoretically this might affect startup time, I can't for the life of me think this would even be measurable. I think any uncertainities in the measurement of the startup of "java" will dwarf any changes due to loading with a different set of exported symbols, in several orders of magnitude. If you claim otherwise, I challenge you to do the measurements. 2) If this is a public API, then show me the documentation. If there is no documentation, then this is not a public interface. Just the fact that you might have used "nm" to locate symbols in a native file and use it, does not mean it's a public interface that requires a CSR to change. If that would be the case, then we could not ever do any change to any native file without filing a CSR, which is obviously absurd. If you have code that are dependent on a certain set of symbols or whatnot, and you want it to keep functioning, then I recommend that you file a bug and submit a patch to get it into mainline. If you're just collecting a bunch of downstream patches, and this change make your life harder, well, then, sorry, that's not my problem. /Magnus From magnus.ihse.bursie at oracle.com Wed Mar 28 21:51:02 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Mar 2018 23:51:02 +0200 Subject: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions In-Reply-To: References: Message-ID: On 2018-03-28 23:01, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8200383/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8200383 > > Changes for JDK-8200303 added calls to log2f() math function and it > hit problem building Hotspot on SPARC - it can't find this function. > > For Hotspot build on Solaris we had hack to support old Solaris > versions which did not have libm.so.2: > > http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/a74480137e6e/make/solaris/makefiles/vm.make#l102 > > > We don't support Solaris 8 and 9 anymore and it is safe to remove the > hack. > > Tested with tier1 Builds and Hotspot testing (similar to submit-hs). Yay, that's wonderful to get it cleaned out! However, there's a similar hack in Awt2dLibraries.gmk: LDFLAGS_solaris := /usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2 Maybe you can/should remove that as well? /Magnus From martinrb at google.com Wed Mar 28 21:53:10 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Mar 2018 14:53:10 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> Message-ID: I can't find any documentation for what JNIEXPORT and friends actually do. People including myself have been cargo-culting JNIEXPORT and JNICALL for decades. Why aren't they in the JNI spec? --- It's fishy that the attribute externally_visible (which seems very interesting!) is ARM specific. #ifdef ARM #define JNIEXPORT __attribute__((externally_visible,visibility("default"))) #define JNIIMPORT __attribute__((externally_visible,visibility("default"))) #else #define JNIEXPORT __attribute__((visibility("default"))) #define JNIIMPORT __attribute__((visibility("default"))) #endif From magnus.ihse.bursie at oracle.com Wed Mar 28 22:14:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 29 Mar 2018 00:14:13 +0200 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> Message-ID: <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com> On 2018-03-28 23:53, Martin Buchholz wrote: > I can't find any documentation for what JNIEXPORT and friends actually do. > People including myself have been cargo-culting JNIEXPORT and JNICALL > for decades. > Why aren't they in the JNI spec? That surprises me. I'm quite certain that javah (or rather, java -h nowadays) generate header files with JNIEXPORT and JNICALL. As you can see in the jni.h and jni_md.h files, JNIEXPORT equals __attribute__((visibility("default"))) for compilers that support it (gcc and friends), and __declspec(dllexport) for Windows. This means, that the symbol should be exported. (And it's ignored if you use mapfiles aka linker scripts.) As for JNICALL, it's empty on most compilers, but evaluates to __stdcall on Windows. This defines the calling convention to use. This is required for JNI calls from Java. (Ask the JVM team why.) While it's not technically required for calling from one dll to another, it's good practice to use it all time to be consistent. In any way, it doesn't hurt us. > > --- > > It's fishy that the attribute externally_visible (which seems very > interesting!) is ARM specific. > > ? #ifdef ARM > ? ? #define JNIEXPORT > ?__attribute__((externally_visible,visibility("default"))) > ? ? #define JNIIMPORT > ?__attribute__((externally_visible,visibility("default"))) Yeah, this is broken on so many levels. :-( The ARM here goes back to the old Oracle proprietary arm32 port. This used lto, link time optimization, to get an absolutely minimal runtime, at expense of a extremely long built time. (I think linking libjvm took like 20 minutes.) But when using lto, you also need to decorate your functions with the externally_visible attribute. So this was added to get hotspot to export the proper symbols (since they, too, used the jni.h file). So, in short, we should: 1) have used a special, local jni.h file for the proprietary arm port, and/or 2) added the externally_visible attribute not based on platform, but on the existence of lto. At this point in time, we're not building the old 32-bit arm port, and I doubt anyone does. And even if so, we could probably remove the lto part, and thus remove this from jni_md.h. If you want, please file a bug. /Magnus > ? #else > ? ? #define JNIEXPORT ?__attribute__((visibility("default"))) > ? ? #define JNIIMPORT ?__attribute__((visibility("default"))) > ? #endif > From mikhailo.seledtsov at oracle.com Wed Mar 28 22:15:14 2018 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Wed, 28 Mar 2018 15:15:14 -0700 Subject: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests In-Reply-To: <637d6d9e-e59a-165f-c9ba-ca1ffa85933d@oracle.com> References: <5ABAF57B.6050005@oracle.com> <637d6d9e-e59a-165f-c9ba-ca1ffa85933d@oracle.com> Message-ID: Hi David, ? Thank you for reviewing the change. Please see my comments inline. On 03/27/2018 07:23 PM, David Holmes wrote: > Hi Misha, > > For the benefit of the broader community these are very old tests > related to the use of ligjsig, that were recently converted to be > jtreg tests in preparation for open sourcing them. If there were to be > written from scratch today I expect they would be in a somewhat > different form, but the aim here is to open source them, not rewrite > them. Thank you for details about the background. > > Also note that these tests would only fail by crashing (shouldn't > happen) or "hanging". If the signal is not delivered then the test > will wait for it until eventually being timed-out by jtreg. > On 28/03/2018 11:52 AM, Mikhailo Seledtsov wrote: >> Please review: open sourcing vm signal tests. >> >> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8200126 >> ???? Webrev: http://cr.openjdk.java.net/~mseledtsov/8200126.00.open/ > > All of the signal tests should work everywhere except Windows, so I > think the @requires should just exclude windows. In particular I would > expect them to also run on AIX. OK, will do. > > --- > > ?make/test/JtregNativeHotspot.gmk > > I think you need to rebase your changes as the build logic for native > tests has completely changed recently. Thank you, I was not aware of that. I will ask the make experts on how to do this. Also, since I changed the make file, adding build-dev at openjdk.java.net > > --- > > test/hotspot/jtreg/TEST.groups > > I agree with Christian that we don't need a hotspot_signal group. > > I'm also unclear why these tests are left to tier 4(?), though tier 3 > seems fine given we have constraints on what we can jam into tiers 1 > and 2. I will remove the group, and add the signal test directory to tier3. > > --- > > test/hotspot/jtreg/runtime/signal/exesigtest.c > > Can you please fix the typo in the name of the "sig_recieved" variable. Will do. > > Can you confirm that all the printf output actually appears in the > jtreg test log please. OK, I will check that. > >> ???? Testing: >> ???????? 1. Linux-x64: >> ??????????? make run-test TEST=hotspot_signal >> ??????????? All tests PASS >> ???????? 2. Multi-platform automated testing: Linux-x64, Win-x64, MAC >> ??????????? hotspot_signal, hs-tier1, hs-tier2 - in progress > > Must be tested on Solaris as well. Will add Solaris for testing also. Thank you, Misha > > Thanks, > David > >> Thank you, >> Misha >> >> From magnus.ihse.bursie at oracle.com Wed Mar 28 22:26:29 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 29 Mar 2018 00:26:29 +0200 Subject: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests In-Reply-To: References: <5ABAF57B.6050005@oracle.com> <637d6d9e-e59a-165f-c9ba-ca1ffa85933d@oracle.com> Message-ID: On 2018-03-29 00:15, mikhailo wrote: > Hi David, > > ? Thank you for reviewing the change. Please see my comments inline. > > > On 03/27/2018 07:23 PM, David Holmes wrote: >> Hi Misha, >> >> For the benefit of the broader community these are very old tests >> related to the use of ligjsig, that were recently converted to be >> jtreg tests in preparation for open sourcing them. If there were to >> be written from scratch today I expect they would be in a somewhat >> different form, but the aim here is to open source them, not rewrite >> them. > Thank you for details about the background. >> >> Also note that these tests would only fail by crashing (shouldn't >> happen) or "hanging". If the signal is not delivered then the test >> will wait for it until eventually being timed-out by jtreg. >> On 28/03/2018 11:52 AM, Mikhailo Seledtsov wrote: >>> Please review: open sourcing vm signal tests. >>> >>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8200126 >>> ???? Webrev: http://cr.openjdk.java.net/~mseledtsov/8200126.00.open/ >> >> All of the signal tests should work everywhere except Windows, so I >> think the @requires should just exclude windows. In particular I >> would expect them to also run on AIX. > OK, will do. >> >> --- >> >> ?make/test/JtregNativeHotspot.gmk >> >> I think you need to rebase your changes as the build logic for native >> tests has completely changed recently. > Thank you, I was not aware of that. I will ask the make experts on how > to do this. Also, since I changed the make file, adding > build-dev at openjdk.java.net Yes, you seem to have based this off an old version of JtregNativeHotspot.gmk. If you update the file I think you see how you should do it, but I'll give you some help: ifeq ($(OPENJDK_TARGET_OS), windows) ? BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT ? BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c endif /Magnus >> >> --- >> >> test/hotspot/jtreg/TEST.groups >> >> I agree with Christian that we don't need a hotspot_signal group. >> >> I'm also unclear why these tests are left to tier 4(?), though tier 3 >> seems fine given we have constraints on what we can jam into tiers 1 >> and 2. > I will remove the group, and add the signal test directory to tier3. >> >> --- >> >> test/hotspot/jtreg/runtime/signal/exesigtest.c >> >> Can you please fix the typo in the name of the "sig_recieved" variable. > Will do. >> >> Can you confirm that all the printf output actually appears in the >> jtreg test log please. > OK, I will check that. >> >>> ???? Testing: >>> ???????? 1. Linux-x64: >>> ??????????? make run-test TEST=hotspot_signal >>> ??????????? All tests PASS >>> ???????? 2. Multi-platform automated testing: Linux-x64, Win-x64, MAC >>> ??????????? hotspot_signal, hs-tier1, hs-tier2 - in progress >> >> Must be tested on Solaris as well. > Will add Solaris for testing also. > > > Thank you, > Misha >> >> Thanks, >> David >> >>> Thank you, >>> Misha >>> >>> > From vladimir.kozlov at oracle.com Wed Mar 28 22:35:28 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Mar 2018 15:35:28 -0700 Subject: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions In-Reply-To: References: Message-ID: <992f56d6-2a85-9a81-8acb-2cd69fe81033@oracle.com> On 3/28/18 2:51 PM, Magnus Ihse Bursie wrote: > On 2018-03-28 23:01, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8200383/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8200383 >> >> Changes for JDK-8200303 added calls to log2f() math function and it >> hit problem building Hotspot on SPARC - it can't find this function. >> >> For Hotspot build on Solaris we had hack to support old Solaris >> versions which did not have libm.so.2: >> >> http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/a74480137e6e/make/solaris/makefiles/vm.make#l102 >> >> >> We don't support Solaris 8 and 9 anymore and it is safe to remove the >> hack. >> >> Tested with tier1 Builds and Hotspot testing (similar to submit-hs). > > Yay, that's wonderful to get it cleaned out! Thank you. > > However, there's a similar hack in Awt2dLibraries.gmk: > LDFLAGS_solaris := /usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2 Based on history it was done for 6307603 in 2010 and reason is the same: http://hg.openjdk.java.net/jdk/hs/rev/1a5e995a710b Is next fix correct?: make/lib/Awt2dLibraries.gmk @@ -409,8 +409,8 @@ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ - LDFLAGS_solaris := /usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2, \ LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS), \ + LIBS_solaris := $(LIBM), \ LIBS_linux := $(LIBM), \ LIBS_macosx := $(LIBM), \ LIBS_aix := $(LIBM),\ or make/lib/Awt2dLibraries.gmk @@ -409,11 +409,7 @@ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ - LDFLAGS_solaris := /usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2, \ - LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS), \ - LIBS_linux := $(LIBM), \ - LIBS_macosx := $(LIBM), \ - LIBS_aix := $(LIBM),\ + LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS) $(LIBM), \ LIBS_windows := $(WIN_AWT_LIB) $(WIN_JAVA_LIB), \ )) Thanks, Vladimir > > Maybe you can/should remove that as well? > > /Magnus > From magnus.ihse.bursie at oracle.com Wed Mar 28 22:37:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 29 Mar 2018 00:37:17 +0200 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: References: <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com> Message-ID: On 2018-03-28 21:21, Thomas St?fe wrote: > Hi Magnus, > > I had a closer look at the changes, especially at jsig.c. It all comes > slowly back. The AIX version has been almost comically wrong. > > About NSIG, I remember that we had coding in our port which needed to > know the max number of signals, and this was surprisingly hard since > on some platforms. Sometimes NSIG does not contain the real time > signals. Or it did not even exist. I think we ended up hardcoding an > own max signal limit . > > So wherever you access sact with a signal number as index, I'd like to > see a bounds check. Or at least an assert - since this is plain C, a > C-assert would do for me (see > http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html). > This also would guard against user parameter error. That's probably a good improvement. Do you think it could be handled as a follow-up bug? > > I also wonder whether this coding could not be simplified quite a bit > by not calling the OS versions of signal() at all but instead doing > all signal work via OS sigaction: after all, signal() can be > implemented in terms of sigaction() (with the flag SA_SIGINFO > cleared), and so can sigset(). This would remove the necessity of > reentry-handling for macos, and also remove the need for > save_signal_handler(). That also sounds like an excellent suggestion. Do you think it could be handled as a follow-up bug? > > I will test this version on AIX tomorrow. After that, I'll have some > vacation, but maybe someone else from my team will take over. > > I like this work, this is a good simplification. Thanks. :) However, it's a bit outside what I normally do. :) Not that I dislike writing some good old C for a change, but I'm really trying to focus on cleaning up the flag handling in the build system. This was just a side-track when I was going to make a change in the jsig.c files (for adding JNIEXPORT) and realized it was four almost identical copies. I thought it would be trivial to unify them, and if it's trivial, it's better to do it yourself right away, than to file a bug on someone else, or so my motto goes. :) However, it turned out to be more work than I expected, and I'm losing interest in pushing this any further. Still, it would be a shame if the work I've done so far go to waste, but I'd really prefer it if someone else could pick up this patch and finish it. /Magnus > > Thanks, Thomas > > > > > On Wed, Mar 28, 2018 at 12:15 PM, Magnus Ihse Bursie > > > wrote: > > > On 2018-03-27 18:24, Thomas St?fe wrote: >> Hi Magnus, >> >> just a cursory look, will look in greater detail tomorrow. >> >> This is good, thanks for doing this. >> >> As I wrote offlist, please remove the painfully wrong AIX >> "workarounds". I do not know why we did this - the original code >> is quite old - my assumption is that dlsym(RTLD_NEXT) was not >> working as expected on older AIX versions. Well, it should work >> now according to IBMs manpages. Will test later. > Ok. >> >> __thread is not Posix. I would prefer pthread_get/set_specific >> instead, which is more portable. > > I have surrounded this code with #ifdef MACOSX now. > > Here is an updated webrev. It includes the changes requested by > you and David: > > * No more AIX workarounds > * Solaris use pthreads > * The "reentry" code is #ifdef MACOSX. > > I also assumed that NSIG is available and working on Solaris. I'll > let David decide if he is happy with that. The alternative is to > go back to the Solaris-specific code that allocates sact on the heap. > > Webrev: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05 > > > Once again, here is also a webrev that shows the difference > between the original files and the new, unified file. Even if it's > hard to read, it shows what the effects will be for each platform. > > Webrev: > http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/ > > > /Magnus > >> >> Thanks! >> >> Thomas >> >> >> >> >> >> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie >> > > wrote: >> >> When I was about to update jsig.c, I noticed that the four >> copies for aix, linux, macosx and solaris were basically the >> same, with only small differences. Some of the differences >> were not even well motivated, but were likely the result of >> this code duplication causing the code to diverge. >> >> A better solution is to unify them all into a single unix >> version, with the few platform-specific changes handled on a >> per-platform basis. >> >> I've made the following notable changes: >> >> * I have removed the version check for Solaris. All other >> platforms seem to do fine without it, and in general, we >> don't mistrust other JDK libraries. An alternative is to add >> this version check to all other platforms instead. If you >> think this is the correct course of action, let me know and >> I'll fix it. >> >> * Solaris used to have a dynamically allocated sact, instead >> of a statically allocated array as all other platforms have. >> It's not likely to be large, and the size is known at compile >> time, so there seems to be no good reason for this. >> >> * Linux and macosx used a uint32_t/uint64_t instead of >> sigset_t for jvmsigs, as aix and solaris do. This is a less >> robust solution, and the added checks show that it has failed >> in the past. Now all platforms use sigset_t/sigismember(). >> >> Also worth noting: >> >> * Solaris is not using pthreads, but it's own thread library, >> which accounts for most of the #ifdef SOLARIS. >> >> * In general, if an implementation was needed on one >> platform, but has no effect or is harmless on others, I've >> kept it on all platforms instead of sprinkling the code with >> #ifdefs. >> >> To facilitate code review, here is a specially crafted webrev >> that shows the differences compared to each of the >> individual, original per-OS versions of jsig.c: >> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 >> >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 >> >> >> /Magnus >> >> > > From erik.joelsson at oracle.com Wed Mar 28 22:48:27 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Mar 2018 15:48:27 -0700 Subject: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions In-Reply-To: <992f56d6-2a85-9a81-8acb-2cd69fe81033@oracle.com> References: <992f56d6-2a85-9a81-8acb-2cd69fe81033@oracle.com> Message-ID: On 2018-03-28 15:35, Vladimir Kozlov wrote: > Based on history it was done for 6307603 in 2010 and reason is the same: > > http://hg.openjdk.java.net/jdk/hs/rev/1a5e995a710b > > Is next fix correct?: > > make/lib/Awt2dLibraries.gmk > @@ -409,8 +409,8 @@ > ???? LDFLAGS := $(LDFLAGS_JDKLIB) \ > ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ > ???? LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > -??? LDFLAGS_solaris := /usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2, \ > ???? LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS), \ > +??? LIBS_solaris := $(LIBM), \ > ???? LIBS_linux := $(LIBM), \ > ???? LIBS_macosx := $(LIBM), \ > ???? LIBS_aix := $(LIBM),\ > > or > > make/lib/Awt2dLibraries.gmk > @@ -409,11 +409,7 @@ > ???? LDFLAGS := $(LDFLAGS_JDKLIB) \ > ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ > ???? LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > -??? LDFLAGS_solaris := /usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2, \ > -??? LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS), \ > -??? LIBS_linux := $(LIBM), \ > -??? LIBS_macosx := $(LIBM), \ > -??? LIBS_aix := $(LIBM),\ > +??? LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS) $(LIBM), \ > ???? LIBS_windows := $(WIN_AWT_LIB) $(WIN_JAVA_LIB), \ > ?)) > I would say the second one is better. Thanks, /Erik > Thanks, > Vladimir > >> >> Maybe you can/should remove that as well? >> >> /Magnus >> From magnus.ihse.bursie at oracle.com Wed Mar 28 22:50:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 29 Mar 2018 00:50:40 +0200 Subject: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions In-Reply-To: References: <992f56d6-2a85-9a81-8acb-2cd69fe81033@oracle.com> Message-ID: <4894301a-2750-8ce1-5a0e-1da13533c637@oracle.com> On 2018-03-29 00:48, Erik Joelsson wrote: > > > On 2018-03-28 15:35, Vladimir Kozlov wrote: >> Based on history it was done for 6307603 in 2010 and reason is the same: >> >> http://hg.openjdk.java.net/jdk/hs/rev/1a5e995a710b >> >> Is next fix correct?: >> >> make/lib/Awt2dLibraries.gmk >> @@ -409,8 +409,8 @@ >> ???? LDFLAGS := $(LDFLAGS_JDKLIB) \ >> ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ >> ???? LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ >> -??? LDFLAGS_solaris := >> /usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2, \ >> ???? LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS), \ >> +??? LIBS_solaris := $(LIBM), \ >> ???? LIBS_linux := $(LIBM), \ >> ???? LIBS_macosx := $(LIBM), \ >> ???? LIBS_aix := $(LIBM),\ >> >> or >> >> make/lib/Awt2dLibraries.gmk >> @@ -409,11 +409,7 @@ >> ???? LDFLAGS := $(LDFLAGS_JDKLIB) \ >> ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ >> ???? LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ >> -??? LDFLAGS_solaris := >> /usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2, \ >> -??? LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS), \ >> -??? LIBS_linux := $(LIBM), \ >> -??? LIBS_macosx := $(LIBM), \ >> -??? LIBS_aix := $(LIBM),\ >> +??? LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS) $(LIBM), \ >> ???? LIBS_windows := $(WIN_AWT_LIB) $(WIN_JAVA_LIB), \ >> ?)) >> > I would say the second one is better. Agree. With this, the fix looks good to me too. /Magnus > Thanks, > /Erik >> Thanks, >> Vladimir >> >>> >>> Maybe you can/should remove that as well? >>> >>> /Magnus >>> > From vladimir.kozlov at oracle.com Wed Mar 28 22:52:34 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Mar 2018 15:52:34 -0700 Subject: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions In-Reply-To: <4894301a-2750-8ce1-5a0e-1da13533c637@oracle.com> References: <992f56d6-2a85-9a81-8acb-2cd69fe81033@oracle.com> <4894301a-2750-8ce1-5a0e-1da13533c637@oracle.com> Message-ID: <2a89a050-15ba-0b3a-d638-f73b44475acb@oracle.com> Thank you. I will use second version and do testing again before push. Vladimir On 3/28/18 3:50 PM, Magnus Ihse Bursie wrote: > On 2018-03-29 00:48, Erik Joelsson wrote: >> >> >> On 2018-03-28 15:35, Vladimir Kozlov wrote: >>> Based on history it was done for 6307603 in 2010 and reason is the same: >>> >>> http://hg.openjdk.java.net/jdk/hs/rev/1a5e995a710b >>> >>> Is next fix correct?: >>> >>> make/lib/Awt2dLibraries.gmk >>> @@ -409,8 +409,8 @@ >>> ???? LDFLAGS := $(LDFLAGS_JDKLIB) \ >>> ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ >>> ???? LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ >>> -??? LDFLAGS_solaris := >>> /usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2, \ >>> ???? LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS), \ >>> +??? LIBS_solaris := $(LIBM), \ >>> ???? LIBS_linux := $(LIBM), \ >>> ???? LIBS_macosx := $(LIBM), \ >>> ???? LIBS_aix := $(LIBM),\ >>> >>> or >>> >>> make/lib/Awt2dLibraries.gmk >>> @@ -409,11 +409,7 @@ >>> ???? LDFLAGS := $(LDFLAGS_JDKLIB) \ >>> ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ >>> ???? LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ >>> -??? LDFLAGS_solaris := >>> /usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2, \ >>> -??? LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS), \ >>> -??? LIBS_linux := $(LIBM), \ >>> -??? LIBS_macosx := $(LIBM), \ >>> -??? LIBS_aix := $(LIBM),\ >>> +??? LIBS_unix := -lawt -ljvm -ljava $(LCMS_LIBS) $(LIBM), \ >>> ???? LIBS_windows := $(WIN_AWT_LIB) $(WIN_JAVA_LIB), \ >>> ?)) >>> >> I would say the second one is better. > Agree. With this, the fix looks good to me too. > > /Magnus > >> Thanks, >> /Erik >>> Thanks, >>> Vladimir >>> >>>> >>>> Maybe you can/should remove that as well? >>>> >>>> /Magnus >>>> >> > From leo.korinth at oracle.com Tue Mar 27 12:01:45 2018 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 27 Mar 2018 14:01:45 +0200 Subject: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl In-Reply-To: <16201e338dda41b0913bbd16286b6e2d@sap.com> References: <16201e338dda41b0913bbd16286b6e2d@sap.com> Message-ID: > > Adding the template parameter to TraceEvent makes xlc happy too. > > http://cr.openjdk.java.net/~mbaesken/webrevs/8200246/ > > > Are you fine with this change ? Observe that this is not a review. I have tested that your fix should compile on linux, solaris, windows and mac. Thanks, Leo > Best regards, Matthias > From dangersd at gmail.com Tue Mar 27 13:40:49 2018 From: dangersd at gmail.com (Alireza Mohamadi) Date: Tue, 27 Mar 2018 18:10:49 +0430 Subject: Problem building openjdk using cygwin Message-ID: Hi. I wanted to build OpenJDK in windows using cygwin, and I set VC compiler path, but due to whitespaces in the path I can't build, with the following error: ``` configure: Rewriting CC to "/cygdrive/c/progra~2/microsoft visual studio/2017/community/vc/tools/msvc/14.13.26128/bin/hostx86/x64/cl" checking resolved symbolic links for CC... no symlink configure: The C compiler (located as /cygdrive/c/progra~2/microsoft visual studio/2017/community/vc/tools/msvc/14.13.26128/bin/hostx86/x64/cl) does not seem to be the required microsoft compiler.configure: error: A microsoft compiler is reconfigure: The result from running it was: "/home/SuNova/jdk/build/.configure-support/generated-configure.sh: line 35050: /cygdrive/c/progra~2/microsoft: No such file or directory" configure exiting with result code 1 ``` Well it's not in my hands to set compiler path while installing VS2017 and it does this automatically, so what can I do in this case? -- Sometimes the best results can be achieved in the worst conditions Wish you the bests :) Alireza From martinrb at google.com Thu Mar 29 05:48:07 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Mar 2018 22:48:07 -0700 Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables In-Reply-To: References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> Message-ID: On Wed, Mar 28, 2018 at 2:48 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-03-28 22:39, Martin Buchholz wrote: > > > > On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> >> Anyway, with this patch all symbols in executables will be visible, so >> there should be no problem anyway. >> > > The symbols visible in the main executable are a sort-of-public > interface. The difference is visible via e.g. nm -D, or any native code > that does dlsym(NULL, symbolName) (yes, we do this!). The behavior of > native code is likely to be affected if there is a symbol conflict. The > larger the exported symbol table, the more overhead there will be at > startup (probably). The theory is that changing an interface requires a CSR. > > > If I understand your objections correctly, you are claiming (correct me if > I'm misunderstanding you): > > 1) Removing the mapfiles will affect performance negatively > > 2) The exported symbols from executables are a public API and the change > therefore require a CSR. > > To this I reply: > > 1) While theoretically this might affect startup time, I can't for the > life of me think this would even be measurable. I think any uncertainities > in the measurement of the startup of "java" will dwarf any changes due to > loading with a different set of exported symbols, in several orders of > magnitude. If you claim otherwise, I challenge you to do the measurements. > It's true the performance loss here is very small - every java program might be a microsecond slower to start up. > 2) If this is a public API, then show me the documentation. If there is no > documentation, then this is not a public interface. Just the fact that you > might have used "nm" to locate symbols in a native file and use it, does > not mean it's a public interface that requires a CSR to change. If that > would be the case, then we could not ever do any change to any native file > without filing a CSR, which is obviously absurd. > > Jigsaw team just spent 10 years working to prevent people from accessing Java internals. But here the proposal for ELF symbols is "just make everything public" Every ELF symbol that is needlessly exported is something that someone might build a dependency on or might cause a name conflict. ELF files don't have much encapsulation - all they have is public and private. > If you have code that are dependent on a certain set of symbols or > whatnot, and you want it to keep functioning, then I recommend that you > file a bug and submit a patch to get it into mainline. If you're just > collecting a bunch of downstream patches, and this change make your life > harder, well, then, sorry, that's not my problem. > No, actually making everything public/exporting all symbols will probably make Google local changes easier to maintain - no map files! I would prefer if build team worked on generating map files with minimal symbols exported, instead of removing them entirely. From martinrb at google.com Thu Mar 29 06:04:32 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Mar 2018 23:04:32 -0700 Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables In-Reply-To: References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> Message-ID: >From https://gcc.gnu.org/wiki/Visibility Why is the new C++ visibility support so useful? Put simply, it hides most of the ELF symbols which would have previously (and unnecessarily) been public. This means: - *It very substantially improves load times of your DSO (Dynamic Shared Object).* For example, a huge C++ template-based library which was tested (the TnFOX Boost.Python bindings library) now loads in eight seconds rather than over six minutes! - *It lets the optimiser produce better code.* PLT indirections (when a function call or variable access must be looked up via the Global Offset Table such as in PIC code) can be completely avoided, thus substantially avoiding pipeline stalls on modern processors and thus much faster code. Furthermore when most of the symbols are bound locally, they can be safely elided (removed) completely through the entire DSO. This gives greater latitude especially to the inliner which no longer needs to keep an entry point around "just in case". - *It reduces the size of your DSO by 5-20%.* ELF's exported symbol table format is quite a space hog, giving the complete mangled symbol name which with heavy template usage can average around 1000 bytes. C++ templates spew out a huge amount of symbols and a typical C++ library can easily surpass 30,000 symbols which is around 5-6Mb! Therefore if you cut out the 60-80% of unnecessary symbols, your DSO can be megabytes smaller! - *Much lower chance of symbol collision.* The old woe of two libraries internally using the same symbol for different things is finally behind us with this patch. Hallelujah! From martinrb at google.com Thu Mar 29 06:16:18 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Mar 2018 23:16:18 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com> Message-ID: On Wed, Mar 28, 2018 at 3:14 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-03-28 23:53, Martin Buchholz wrote: > > I can't find any documentation for what JNIEXPORT and friends actually do. > People including myself have been cargo-culting JNIEXPORT and JNICALL for > decades. > Why aren't they in the JNI spec? > > That surprises me. I'm quite certain that javah (or rather, java -h > nowadays) generate header files with JNIEXPORT and JNICALL. > > As you can see in the jni.h and jni_md.h files, JNIEXPORT equals > __attribute__((visibility("default"))) for compilers that support it (gcc > and friends), and __declspec(dllexport) for Windows. This means, that the > symbol should be exported. (And it's ignored if you use mapfiles aka linker > scripts.) > > As for JNICALL, it's empty on most compilers, but evaluates to __stdcall > on Windows. This defines the calling convention to use. This is required > for JNI calls from Java. (Ask the JVM team why.) While it's not technically > required for calling from one dll to another, it's good practice to use it > all time to be consistent. In any way, it doesn't hurt us. > Sure, I can see how JNIEXPORT and JNICALL are implemented, but what do they *mean?* For example, one might expect from the JNI prefix that these macros are exclusively for use by JNI linking, i.e. unsupported except in the output of javac -h. But of course in practice they are used with arbitrary symbols to communicate between components of user native code, not just to communicate with the JVM. Is that a bug? From thomas.stuefe at gmail.com Thu Mar 29 06:47:50 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 29 Mar 2018 08:47:50 +0200 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: References: <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com> Message-ID: On Thu, Mar 29, 2018 at 12:37 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-03-28 21:21, Thomas St?fe wrote: > > Hi Magnus, > > I had a closer look at the changes, especially at jsig.c. It all comes > slowly back. The AIX version has been almost comically wrong. > > About NSIG, I remember that we had coding in our port which needed to know > the max number of signals, and this was surprisingly hard since on some > platforms. Sometimes NSIG does not contain the real time signals. Or it did > not even exist. I think we ended up hardcoding an own max signal limit . > > So wherever you access sact with a signal number as index, I'd like to see > a bounds check. Or at least an assert - since this is plain C, a C-assert > would do for me (see http://pubs.opengroup.org/onlinepubs/009695399/ > functions/assert.html). This also would guard against user parameter > error. > > That's probably a good improvement. Do you think it could be handled as a > follow-up bug? > > A simple bounds check would suffice for me. At the start of the external sigaction() and sigset(), just do a: if (sig < 0 || sig >= NSIG) { return -1; } In the external signal(), do a: if (sig < 0 || sig >= NSIG) { return SIGERR; } > I also wonder whether this coding could not be simplified quite a bit by > not calling the OS versions of signal() at all but instead doing all signal > work via OS sigaction: after all, signal() can be implemented in terms of > sigaction() (with the flag SA_SIGINFO cleared), and so can sigset(). This > would remove the necessity of reentry-handling for macos, and also remove > the need for save_signal_handler(). > > That also sounds like an excellent suggestion. Do you think it could be > handled as a follow-up bug? > Sure! > > I will test this version on AIX tomorrow. After that, I'll have some > vacation, but maybe someone else from my team will take over. > > I like this work, this is a good simplification. > > Thanks. :) > > However, it's a bit outside what I normally do. :) Not that I dislike > writing some good old C for a change, but I'm really trying to focus on > cleaning up the flag handling in the build system. This was just a > side-track when I was going to make a change in the jsig.c files (for > adding JNIEXPORT) and realized it was four almost identical copies. I > thought it would be trivial to unify them, and if it's trivial, it's better > to do it yourself right away, than to file a bug on someone else, or so my > motto goes. :) > > However, it turned out to be more work than I expected, and I'm losing > interest in pushing this any further. Still, it would be a shame if the > work I've done so far go to waste, but I'd really prefer it if someone else > could pick up this patch and finish it. > > You are almost there. Lets finish this. The source looks good to me, if you add above mentioned bounds checks. I'll build it on AIX later today (I just found out your 8200357 - which I need to build on AIX - does not apply to hs, and I need to switch to jdk/jdk. Sigh. The unification of hs/jdk cannot come too early.) ..Thomas > /Magnus > > > > Thanks, Thomas > > > > > On Wed, Mar 28, 2018 at 12:15 PM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> >> On 2018-03-27 18:24, Thomas St?fe wrote: >> >> Hi Magnus, >> >> just a cursory look, will look in greater detail tomorrow. >> >> This is good, thanks for doing this. >> >> As I wrote offlist, please remove the painfully wrong AIX "workarounds". >> I do not know why we did this - the original code is quite old - my >> assumption is that dlsym(RTLD_NEXT) was not working as expected on older >> AIX versions. Well, it should work now according to IBMs manpages. Will >> test later. >> >> Ok. >> >> >> __thread is not Posix. I would prefer pthread_get/set_specific instead, >> which is more portable. >> >> >> I have surrounded this code with #ifdef MACOSX now. >> >> Here is an updated webrev. It includes the changes requested by you and >> David: >> >> * No more AIX workarounds >> * Solaris use pthreads >> * The "reentry" code is #ifdef MACOSX. >> >> I also assumed that NSIG is available and working on Solaris. I'll let >> David decide if he is happy with that. The alternative is to go back to the >> Solaris-specific code that allocates sact on the heap. >> >> Webrev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/ >> webrev.05 >> >> Once again, here is also a webrev that shows the difference between the >> original files and the new, unified file. Even if it's hard to read, it >> shows what the effects will be for each platform. >> >> Webrev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/ >> webrev.04/ >> >> /Magnus >> >> >> Thanks! >> >> Thomas >> >> >> >> >> >> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie < >> magnus.ihse.bursie at oracle.com> wrote: >> >>> When I was about to update jsig.c, I noticed that the four copies for >>> aix, linux, macosx and solaris were basically the same, with only small >>> differences. Some of the differences were not even well motivated, but were >>> likely the result of this code duplication causing the code to diverge. >>> >>> A better solution is to unify them all into a single unix version, with >>> the few platform-specific changes handled on a per-platform basis. >>> >>> I've made the following notable changes: >>> >>> * I have removed the version check for Solaris. All other platforms seem >>> to do fine without it, and in general, we don't mistrust other JDK >>> libraries. An alternative is to add this version check to all other >>> platforms instead. If you think this is the correct course of action, let >>> me know and I'll fix it. >>> >>> * Solaris used to have a dynamically allocated sact, instead of a >>> statically allocated array as all other platforms have. It's not likely to >>> be large, and the size is known at compile time, so there seems to be no >>> good reason for this. >>> >>> * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for >>> jvmsigs, as aix and solaris do. This is a less robust solution, and the >>> added checks show that it has failed in the past. Now all platforms use >>> sigset_t/sigismember(). >>> >>> Also worth noting: >>> >>> * Solaris is not using pthreads, but it's own thread library, which >>> accounts for most of the #ifdef SOLARIS. >>> >>> * In general, if an implementation was needed on one platform, but has >>> no effect or is harmless on others, I've kept it on all platforms instead >>> of sprinkling the code with #ifdefs. >>> >>> To facilitate code review, here is a specially crafted webrev that shows >>> the differences compared to each of the individual, original per-OS >>> versions of jsig.c: >>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/w >>> ebrev.03 >>> >>> /Magnus >>> >> >> >> > > From Alan.Bateman at oracle.com Thu Mar 29 06:56:20 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Mar 2018 07:56:20 +0100 Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables In-Reply-To: References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com> Message-ID: <5e2fc428-1b6d-25c7-ade0-566f0dde82a1@oracle.com> On 28/03/2018 22:48, Magnus Ihse Bursie wrote: > > > 2) The exported symbols from executables are a public API and the > change therefore require a CSR. I don't think there are any supported/documented interfaces here. It would be nice if the launchers were linked without any exported symbols, that would avoid any misunderstanding but I don't think that is necessary. -Alan From volker.simonis at gmail.com Thu Mar 29 07:25:39 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 29 Mar 2018 07:25:39 +0000 Subject: Problem building openjdk using cygwin In-Reply-To: References: Message-ID: Hi Alireza, it seems you don?t have short file names enabled for the ?Program Files? directory. Notice that you have short file names enabled for ?c:\? (i.e. you have ?progra~2?). You have to first enable short file names for the ?Program Files? directory (see for example https://superuser.com/questions/681330/how-to-force-short-name-8dot3-generation ). Afterwards you must copy ?microsoft visual studio? to a temporary directory and finally copy it back to ?microsoft visual studio?. This should create a short name for that directory. Regards, Volker Alireza Mohamadi schrieb am Do. 29. M?rz 2018 um 06:08: > Hi. I wanted to build OpenJDK in windows using cygwin, and I set VC > compiler path, but due to whitespaces in the path I can't build, with the > following error: > ``` > configure: Rewriting CC to "/cygdrive/c/progra~2/microsoft visual > studio/2017/community/vc/tools/msvc/14.13.26128/bin/hostx86/x64/cl" > checking resolved symbolic links for CC... no symlink > configure: The C compiler (located as /cygdrive/c/progra~2/microsoft visual > studio/2017/community/vc/tools/msvc/14.13.26128/bin/hostx86/x64/cl) does > not seem to be the required microsoft compiler.configure: error: A > microsoft compiler is reconfigure: The result from running it was: > "/home/SuNova/jdk/build/.configure-support/generated-configure.sh: line > 35050: /cygdrive/c/progra~2/microsoft: No such file or directory" > configure exiting with result code 1 > ``` > Well it's not in my hands to set compiler path while installing VS2017 and > it does this automatically, so what can I do in this case? > > > -- > Sometimes the best results can be achieved in the worst conditions > Wish you the bests :) > Alireza > From thomas.stuefe at gmail.com Thu Mar 29 12:51:56 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 29 Mar 2018 14:51:56 +0200 Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c In-Reply-To: References: <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com> Message-ID: Hi Magnus, On Thu, Mar 29, 2018 at 8:47 AM, Thomas St?fe wrote: > > > On Thu, Mar 29, 2018 at 12:37 AM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> On 2018-03-28 21:21, Thomas St?fe wrote: >> >> Hi Magnus, >> >> I had a closer look at the changes, especially at jsig.c. It all comes >> slowly back. The AIX version has been almost comically wrong. >> >> About NSIG, I remember that we had coding in our port which needed to >> know the max number of signals, and this was surprisingly hard since on >> some platforms. Sometimes NSIG does not contain the real time signals. Or >> it did not even exist. I think we ended up hardcoding an own max signal >> limit . >> >> So wherever you access sact with a signal number as index, I'd like to >> see a bounds check. Or at least an assert - since this is plain C, a >> C-assert would do for me (see http://pubs.opengroup.org/onli >> nepubs/009695399/functions/assert.html). This also would guard against >> user parameter error. >> >> That's probably a good improvement. Do you think it could be handled as a >> follow-up bug? >> >> > A simple bounds check would suffice for me. At the start of the external > sigaction() and sigset(), just do a: > > if (sig < 0 || sig >= NSIG) { > return -1; > } > > In the external signal(), do a: > > if (sig < 0 || sig >= NSIG) { > return SIGERR; > } > > >> I also wonder whether this coding could not be simplified quite a bit by >> not calling the OS versions of signal() at all but instead doing all signal >> work via OS sigaction: after all, signal() can be implemented in terms of >> sigaction() (with the flag SA_SIGINFO cleared), and so can sigset(). >> This would remove the necessity of reentry-handling for macos, and also >> remove the need for save_signal_handler(). >> >> That also sounds like an excellent suggestion. Do you think it could be >> handled as a follow-up bug? >> > > Sure! > >> >> I will test this version on AIX tomorrow. After that, I'll have some >> vacation, but maybe someone else from my team will take over. >> >> I like this work, this is a good simplification. >> >> Thanks. :) >> >> However, it's a bit outside what I normally do. :) Not that I dislike >> writing some good old C for a change, but I'm really trying to focus on >> cleaning up the flag handling in the build system. This was just a >> side-track when I was going to make a change in the jsig.c files (for >> adding JNIEXPORT) and realized it was four almost identical copies. I >> thought it would be trivial to unify them, and if it's trivial, it's better >> to do it yourself right away, than to file a bug on someone else, or so my >> motto goes. :) >> >> > However, it turned out to be more work than I expected, and I'm losing >> interest in pushing this any further. Still, it would be a shame if the >> work I've done so far go to waste, but I'd really prefer it if someone else >> could pick up this patch and finish it. >> >> > You are almost there. Lets finish this. > > The source looks good to me, if you add above mentioned bounds checks. > I'll build it on AIX later today (I just found out your 8200357 - which I > need to build on AIX - does not apply to hs, and I need to switch to > jdk/jdk. Sigh. The unification of hs/jdk cannot come too early.) > > I'm about to give up. I cannot build jdk/jdk on AIX since it misses a number of fixes for all include changes which happened in hotspot lately. On jdk/hs your libjsig change won't apply. So I am stuck here and a bit out of time. If you want to press it, go on push it and we fix any follow up errors on AIX after easter. I am fine with the look of the change (modulo the sig bounds check mentioned earlier). Best Regards, Thomas > ..Thomas > > > >> /Magnus >> >> >> >> Thanks, Thomas >> >> >> >> >> On Wed, Mar 28, 2018 at 12:15 PM, Magnus Ihse Bursie < >> magnus.ihse.bursie at oracle.com> wrote: >> >>> >>> On 2018-03-27 18:24, Thomas St?fe wrote: >>> >>> Hi Magnus, >>> >>> just a cursory look, will look in greater detail tomorrow. >>> >>> This is good, thanks for doing this. >>> >>> As I wrote offlist, please remove the painfully wrong AIX "workarounds". >>> I do not know why we did this - the original code is quite old - my >>> assumption is that dlsym(RTLD_NEXT) was not working as expected on older >>> AIX versions. Well, it should work now according to IBMs manpages. Will >>> test later. >>> >>> Ok. >>> >>> >>> __thread is not Posix. I would prefer pthread_get/set_specific instead, >>> which is more portable. >>> >>> >>> I have surrounded this code with #ifdef MACOSX now. >>> >>> Here is an updated webrev. It includes the changes requested by you and >>> David: >>> >>> * No more AIX workarounds >>> * Solaris use pthreads >>> * The "reentry" code is #ifdef MACOSX. >>> >>> I also assumed that NSIG is available and working on Solaris. I'll let >>> David decide if he is happy with that. The alternative is to go back to the >>> Solaris-specific code that allocates sact on the heap. >>> >>> Webrev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/w >>> ebrev.05 >>> >>> Once again, here is also a webrev that shows the difference between the >>> original files and the new, unified file. Even if it's hard to read, it >>> shows what the effects will be for each platform. >>> >>> Webrev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/w >>> ebrev.04/ >>> >>> /Magnus >>> >>> >>> Thanks! >>> >>> Thomas >>> >>> >>> >>> >>> >>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie < >>> magnus.ihse.bursie at oracle.com> wrote: >>> >>>> When I was about to update jsig.c, I noticed that the four copies for >>>> aix, linux, macosx and solaris were basically the same, with only small >>>> differences. Some of the differences were not even well motivated, but were >>>> likely the result of this code duplication causing the code to diverge. >>>> >>>> A better solution is to unify them all into a single unix version, with >>>> the few platform-specific changes handled on a per-platform basis. >>>> >>>> I've made the following notable changes: >>>> >>>> * I have removed the version check for Solaris. All other platforms >>>> seem to do fine without it, and in general, we don't mistrust other JDK >>>> libraries. An alternative is to add this version check to all other >>>> platforms instead. If you think this is the correct course of action, let >>>> me know and I'll fix it. >>>> >>>> * Solaris used to have a dynamically allocated sact, instead of a >>>> statically allocated array as all other platforms have. It's not likely to >>>> be large, and the size is known at compile time, so there seems to be no >>>> good reason for this. >>>> >>>> * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for >>>> jvmsigs, as aix and solaris do. This is a less robust solution, and the >>>> added checks show that it has failed in the past. Now all platforms use >>>> sigset_t/sigismember(). >>>> >>>> Also worth noting: >>>> >>>> * Solaris is not using pthreads, but it's own thread library, which >>>> accounts for most of the #ifdef SOLARIS. >>>> >>>> * In general, if an implementation was needed on one platform, but has >>>> no effect or is harmless on others, I've kept it on all platforms instead >>>> of sprinkling the code with #ifdefs. >>>> >>>> To facilitate code review, here is a specially crafted webrev that >>>> shows the differences compared to each of the individual, original per-OS >>>> versions of jsig.c: >>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200298 >>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/w >>>> ebrev.03 >>>> >>>> /Magnus >>>> >>> >>> >>> >> >> > From erik.joelsson at oracle.com Thu Mar 29 14:18:04 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 29 Mar 2018 07:18:04 -0700 Subject: (urgent) RFR: JDK-8200409: jdk11 nightly solaris sparc build failure Message-ID: <98523676-2929-9d12-4c44-3715e8077b17@oracle.com> The removal of mapfiles didn't completely work out. On Solaris we now get the following build error: "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", line 181: error: redeclaration must have the same or more restrictive linker scoping: signal "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", line 186: error: redeclaration must have the same or more restrictive linker scoping: sigset "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", line 203: error: redeclaration must have the same or more restrictive linker scoping: sigaction cc: acomp failed for /localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c As a quick fix I have reverted the mapfile removal for libjsig on Solaris. With the following changes the build works again. Hopefully Magnus will be able to figure out the proper fix next week (after the Swedish Easter holidays). Webrev: http://cr.openjdk.java.net/~erikj/8200409/webrev.01/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8200409 Please note that I'm on vacation today and will soon get in a car for a long drive. I urge someone else to pick this up and push it as soon as it is reviewed (or find a better solution) so that a promoted build can be produced this week. /Erik From Alan.Bateman at oracle.com Thu Mar 29 14:23:57 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Mar 2018 15:23:57 +0100 Subject: (urgent) RFR: JDK-8200409: jdk11 nightly solaris sparc build failure In-Reply-To: <98523676-2929-9d12-4c44-3715e8077b17@oracle.com> References: <98523676-2929-9d12-4c44-3715e8077b17@oracle.com> Message-ID: <589e5895-5fbf-8672-add2-56b24822d427@oracle.com> This revert looks okay to me. I see Tim is going to push it for you. -Alan On 29/03/2018 15:18, Erik Joelsson wrote: > The removal of mapfiles didn't completely work out. On Solaris we now > get the following build error: > > "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", > line 181: error: redeclaration must have the same or more restrictive > linker scoping: signal > "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", > line 186: error: redeclaration must have the same or more restrictive > linker scoping: sigset > "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", > line 203: error: redeclaration must have the same or more restrictive > linker scoping: sigaction > cc: acomp failed for > /localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c > > As a quick fix I have reverted the mapfile removal for libjsig on > Solaris. With the following changes the build works again. Hopefully > Magnus will be able to figure out the proper fix next week (after the > Swedish Easter holidays). > > Webrev: http://cr.openjdk.java.net/~erikj/8200409/webrev.01/index.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200409 > > Please note that I'm on vacation today and will soon get in a car for > a long drive. I urge someone else to pick this up and push it as soon > as it is reviewed (or find a better solution) so that a promoted build > can be produced this week. > > /Erik > From tim.bell at oracle.com Thu Mar 29 14:37:56 2018 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 29 Mar 2018 07:37:56 -0700 Subject: (urgent) RFR: JDK-8200409: jdk11 nightly solaris sparc build failure In-Reply-To: <589e5895-5fbf-8672-add2-56b24822d427@oracle.com> References: <98523676-2929-9d12-4c44-3715e8077b17@oracle.com> <589e5895-5fbf-8672-add2-56b24822d427@oracle.com> Message-ID: <5ABCFA44.3060103@oracle.com> Looks good to me as well. I am submitting the patch for testing now. If builds work on all platforms, I will push it for Erik. Tim On 03/29/18 07:23, Alan Bateman wrote: > This revert looks okay to me. I see Tim is going to push it for you. > > -Alan > > On 29/03/2018 15:18, Erik Joelsson wrote: >> The removal of mapfiles didn't completely work out. On Solaris we now >> get the following build error: >> >> "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", line >> 181: error: redeclaration must have the same or more restrictive >> linker scoping: signal >> "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", line >> 186: error: redeclaration must have the same or more restrictive >> linker scoping: sigset >> "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", line >> 203: error: redeclaration must have the same or more restrictive >> linker scoping: sigaction >> cc: acomp failed for >> /localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c >> >> As a quick fix I have reverted the mapfile removal for libjsig on >> Solaris. With the following changes the build works again. Hopefully >> Magnus will be able to figure out the proper fix next week (after the >> Swedish Easter holidays). >> >> Webrev: http://cr.openjdk.java.net/~erikj/8200409/webrev.01/index.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200409 >> >> Please note that I'm on vacation today and will soon get in a car for >> a long drive. I urge someone else to pick this up and push it as soon >> as it is reviewed (or find a better solution) so that a promoted build >> can be produced this week. >> >> /Erik >> > From magnus.ihse.bursie at oracle.com Thu Mar 29 17:41:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 29 Mar 2018 19:41:13 +0200 Subject: (urgent) RFR: JDK-8200409: jdk11 nightly solaris sparc build failure In-Reply-To: <98523676-2929-9d12-4c44-3715e8077b17@oracle.com> References: <98523676-2929-9d12-4c44-3715e8077b17@oracle.com> Message-ID: <8FE3F506-2C67-453A-8B08-BB186BED01DF@oracle.com> If I understand the fix correctly, it will resolve the build issue. However, libjsig will not work, since we will not export any symbols at all. For this to work, we also need to filter out the fvisibility/xldscope flags from CFLAGS. I apologize for the mess I created. :-( /Magnus > 29 mars 2018 kl. 16:18 skrev Erik Joelsson : > > The removal of mapfiles didn't completely work out. On Solaris we now get the following build error: > > "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", line 181: error: redeclaration must have the same or more restrictive linker scoping: signal > "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", line 186: error: redeclaration must have the same or more restrictive linker scoping: sigset > "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", line 203: error: redeclaration must have the same or more restrictive linker scoping: sigaction > cc: acomp failed for /localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c > > As a quick fix I have reverted the mapfile removal for libjsig on Solaris. With the following changes the build works again. Hopefully Magnus will be able to figure out the proper fix next week (after the Swedish Easter holidays). > > Webrev: http://cr.openjdk.java.net/~erikj/8200409/webrev.01/index.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200409 > > Please note that I'm on vacation today and will soon get in a car for a long drive. I urge someone else to pick this up and push it as soon as it is reviewed (or find a better solution) so that a promoted build can be produced this week. > > /Erik > From robin.westberg at oracle.com Thu Mar 29 18:38:32 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Thu, 29 Mar 2018 20:38:32 +0200 Subject: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX In-Reply-To: References: <7545A83F-E296-40B1-9C15-358A999D1AAF@oracle.com> <446F6608-6FC0-4962-AAD3-CC8CF36F60F7@oracle.com> Message-ID: <6AC02BE6-42E6-465A-A3BF-B800DB28155B@oracle.com> Thanks Erik! Best regards, Robin > On 28 Mar 2018, at 17:47, Erik Joelsson wrote: > > I will sponsor the change. > > /Erik > > > On 2018-03-28 06:43, Robin Westberg wrote: >> Hi Kim, >> >>> On 26 Mar 2018, at 18:34, Kim Barrett wrote: >>> >>>> On Mar 26, 2018, at 11:01 AM, Robin Westberg wrote: >>>> >>>> Hi all, >>>> >>>> Please review this small change that defines the NOMINMAX macro when building HotSpot on Windows. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199619 >>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199619/webrev.00/ >>>> Testing: building with/without precompiled headers, hs-tier1 >>>> >>>> Best regards, >>>> Robin >>> Looks good. >> Thanks for reviewing! >> >>> This change will have a (easy to resolve) merge conflict with your fix for JDK-8199736, right? >> Indeed, the flag definitions should go on a single line I think. I?ll try to get this one in first and rebase 8199736 afterwards. >> >> So, if anyone would be willing to sponsor this change, here?s an updated webrev with a proper mercurial changeset (no other changes): >> http://cr.openjdk.java.net/~rwestberg/8199619/webrev.01/ >> >> Best regards, >> Robin >> > From mikhailo.seledtsov at oracle.com Thu Mar 29 21:49:31 2018 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Thu, 29 Mar 2018 14:49:31 -0700 Subject: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests In-Reply-To: References: <5ABAF57B.6050005@oracle.com> <637d6d9e-e59a-165f-c9ba-ca1ffa85933d@oracle.com> Message-ID: <21376b33-cf1e-5690-40f5-a3bfd1da0afc@oracle.com> Magnus, Thank you for advice. I have updated the makefile accordingly. Will post updated webrev shortly. Misha On 03/28/2018 03:26 PM, Magnus Ihse Bursie wrote: > Yes, you seem to have based this off an old version of > JtregNativeHotspot.gmk. > > If you update the file I think you see how you should do it, but I'll > give you some help: > > ifeq ($(OPENJDK_TARGET_OS), windows) > ? BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT > ? BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c > endif From mikhailo.seledtsov at oracle.com Thu Mar 29 23:00:30 2018 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Thu, 29 Mar 2018 16:00:30 -0700 Subject: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests In-Reply-To: <21376b33-cf1e-5690-40f5-a3bfd1da0afc@oracle.com> References: <5ABAF57B.6050005@oracle.com> <637d6d9e-e59a-165f-c9ba-ca1ffa85933d@oracle.com> <21376b33-cf1e-5690-40f5-a3bfd1da0afc@oracle.com> Message-ID: <6ec5e0b0-c550-5918-3671-47dfa2e966cc@oracle.com> I have addressed feedback from Christian, David and Magnus. Here is the updated webrev: http://cr.openjdk.java.net/~mseledtsov/8200126.01.open/index.html I have also confirmed that output from exesigtest.c printf() is logged into .jtr files. ????? Grepped for "signal", I can see the output such as: ????????? TestSigxfsz.jtr:SIGXFSZ: signal handler using function 'sigset' has been set ????????? TestSigxfsz.jtr:SIGXFSZ: signal handler for signal 25 has been processed ????????? TestSigxfsz.jtr:SIGXFSZ: signal has been sent successfully ????????? TestSigxfsz.jtr:SIGXFSZ: signal has been received ????? Also can see other output from the printf, such as all initVM logs. Thank you, Misha On 03/29/2018 02:49 PM, mikhailo wrote: > Magnus, > > Thank you for advice. I have updated the makefile accordingly. Will > post updated webrev shortly. > > > Misha > > > On 03/28/2018 03:26 PM, Magnus Ihse Bursie wrote: >> Yes, you seem to have based this off an old version of >> JtregNativeHotspot.gmk. >> >> If you update the file I think you see how you should do it, but I'll >> give you some help: >> >> ifeq ($(OPENJDK_TARGET_OS), windows) >> ? BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT >> ? BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c >> endif > From iris.clark at oracle.com Fri Mar 30 02:08:22 2018 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 29 Mar 2018 19:08:22 -0700 (PDT) Subject: RFR(XS): 8200469: Update link to license in Docs.gmk Message-ID: <4ed799a3-402a-44ae-ac93-3c5a6c3bd859@default> Please review this small change to update the link to the Specification license referenced by the JavaDoc API. To avoid the need for future updates based on the version number, we should use $(VERSION_NUMBER) instead of a specific version number. Bug: 8200469: Update link to license in Docs.gmk https://bugs.openjdk.java.net/browse/JDK-8200469 webrev: http://cr.openjdk.java.net/~iris/8200469/webrev/ Thanks, Iris From mikhailo.seledtsov at oracle.com Fri Mar 30 02:41:04 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Thu, 29 Mar 2018 19:41:04 -0700 Subject: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests In-Reply-To: <6ec5e0b0-c550-5918-3671-47dfa2e966cc@oracle.com> References: <5ABAF57B.6050005@oracle.com> <637d6d9e-e59a-165f-c9ba-ca1ffa85933d@oracle.com> <21376b33-cf1e-5690-40f5-a3bfd1da0afc@oracle.com> <6ec5e0b0-c550-5918-3671-47dfa2e966cc@oracle.com> Message-ID: <5ABDA3C0.8050902@oracle.com> While testing I discovered build errors on Mac and Solaris. The following statement " BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exesigtest := -ljvm" was added to a Linux-only block. I have updated the make file to add this for any platform w/o conditions; the " exesigtest.c" is excluded from Windows anyway down below in the make file. I am not 100% sure this is the correct way to modify the make file; if not please advise the correct way. With this fix all 4 builds pass. Here is the updated webrev: http://cr.openjdk.java.net/~mseledtsov/8200126.02.open/index.html Thank you, Misha On 3/29/18, 4:00 PM, mikhailo wrote: > I have addressed feedback from Christian, David and Magnus. Here is > the updated webrev: > > http://cr.openjdk.java.net/~mseledtsov/8200126.01.open/index.html > > > I have also confirmed that output from exesigtest.c printf() is logged > into .jtr files. > > Grepped for "signal", I can see the output such as: > TestSigxfsz.jtr:SIGXFSZ: signal handler using function > 'sigset' has been set > TestSigxfsz.jtr:SIGXFSZ: signal handler for signal 25 has > been processed > TestSigxfsz.jtr:SIGXFSZ: signal has been sent successfully > TestSigxfsz.jtr:SIGXFSZ: signal has been received > Also can see other output from the printf, such as all initVM logs. > > > Thank you, > Misha > > On 03/29/2018 02:49 PM, mikhailo wrote: >> Magnus, >> >> Thank you for advice. I have updated the makefile accordingly. Will >> post updated webrev shortly. >> >> >> Misha >> >> >> On 03/28/2018 03:26 PM, Magnus Ihse Bursie wrote: >>> Yes, you seem to have based this off an old version of >>> JtregNativeHotspot.gmk. >>> >>> If you update the file I think you see how you should do it, but >>> I'll give you some help: >>> >>> ifeq ($(OPENJDK_TARGET_OS), windows) >>> BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT >>> BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c >>> endif >> > From tim.bell at oracle.com Fri Mar 30 04:11:25 2018 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 29 Mar 2018 21:11:25 -0700 Subject: RFR(XS): 8200469: Update link to license in Docs.gmk In-Reply-To: <4ed799a3-402a-44ae-ac93-3c5a6c3bd859@default> References: <4ed799a3-402a-44ae-ac93-3c5a6c3bd859@default> Message-ID: <5ABDB8ED.7010305@oracle.com> Iris: > Bug: > > 8200469: Update link to license in Docs.gmk > https://bugs.openjdk.java.net/browse/JDK-8200469 > > webrev: > > http://cr.openjdk.java.net/~iris/8200469/webrev/ Looks good. Tim From iris.clark at oracle.com Fri Mar 30 16:43:58 2018 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 30 Mar 2018 16:43:58 +0000 (UTC) Subject: RFR(XS): 8200469: Update link to license in Docs.gmk In-Reply-To: <5ABDB8ED.7010305@oracle.com> References: <4ed799a3-402a-44ae-ac93-3c5a6c3bd859@default> <5ABDB8ED.7010305@oracle.com> Message-ID: <66646309-d6e7-4477-ad6c-fe3a0c45900d@default> Thanks, Tim! Pushed. iris -----Original Message----- From: Tim Bell Sent: Thursday, March 29, 2018 9:11 PM To: Iris Clark Cc: build-dev Subject: Re: RFR(XS): 8200469: Update link to license in Docs.gmk Iris: > Bug: > > 8200469: Update link to license in Docs.gmk > https://bugs.openjdk.java.net/browse/JDK-8200469 > > webrev: > > http://cr.openjdk.java.net/~iris/8200469/webrev/ Looks good. Tim From igor.ignatyev at ORACLE.COM Fri Mar 30 22:10:06 2018 From: igor.ignatyev at ORACLE.COM (Igor Ignatyev) Date: Fri, 30 Mar 2018 15:10:06 -0700 Subject: RFR(XXS) : 8200538 : cl : Command line warning D9014 : invalid value '2220' for '/wd' Message-ID: <27B6D243-F391-4C9D-BED2-10C7AE67C81B@oracle.com> http://cr.openjdk.java.net/~iignatyev/8200538/webrev.00/ > 1 line changed: 0 ins; 0 del; 1 mod; Hi all, could you please review this one-liner change which removes C2220 from disabled warning on windows? C2220 is "warning treated as error" compiler error, which isn't a real compiler warning/error, so it can't be used in /wd as a result, we get warning D9014. webrev: http://cr.openjdk.java.net/~iignatyev/8200538/webrev.00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8200538 testing: built windows, windows-debug (including open only) and grepped for D9014 in log Thanks, -- Igor From Sergey.Bylokhov at oracle.com Fri Mar 30 22:52:13 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Mar 2018 15:52:13 -0700 Subject: [11] Review Request: 8200146 Remove the appletviewer launcher Message-ID: <419d6585-fa7f-f14a-bac8-3129ceb53c8b@oracle.com> Hello. Please review fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8200146 Webrev can be found at: http://cr.openjdk.java.net/~serb/8200146/webrev.00 CSR: https://bugs.openjdk.java.net/browse/JDK-8200549 Fix description: - The appletviewer launcher was removed from jdk/bin - The man pages were removed - Two tests which used appletviewer launcher directly were removed Note that the appletviewer was deprecated in in jdk9: https://bugs.openjdk.java.net/browse/JDK-8074165 -- Best regards, Sergey. From johnson.peter at gmail.com Fri Mar 30 06:36:57 2018 From: johnson.peter at gmail.com (Peter Johnson) Date: Thu, 29 Mar 2018 23:36:57 -0700 Subject: space.inline.hpp build failure Message-ID: When cross compiling either 9 or 10 to ARM with gcc 5.5.0, I get the following linker error: /tmp/cc7TKVtK.ltrans2.ltrans.o: In function `OffsetTableContigSpace::block_start_const(void const*) const': :(.text+0x26e4): undefined reference to `BlockOffsetTable::block_start(void const*) const' /tmp/cc7TKVtK.ltrans13.ltrans.o: In function `OffsetTableContigSpace::verify() const': :(.text+0x2ca6): undefined reference to `BlockOffsetTable::block_start(void const*) const' collect2: error: ld returned 1 exit status This appears to be due to a missing include in space.inline.hpp. Applying the following patch fixes the build for me. Thanks, Peter diff -r 5ab7a67bc155 src/share/vm/gc/shared/space.inline.hpp --- a/src/share/vm/gc/shared/space.inline.hpp Fri Sep 08 18:24:18 2017 +0000 +++ b/src/share/vm/gc/shared/space.inline.hpp Thu Mar 29 23:25:25 2018 -0700 @@ -26,6 +26,7 @@ #define SHARE_VM_GC_SHARED_SPACE_INLINE_HPP #include "gc/serial/markSweep.inline.hpp" +#include "gc/shared/blockOffsetTable.inline.hpp" #include "gc/shared/collectedHeap.hpp" #include "gc/shared/generation.hpp" #include "gc/shared/space.hpp" From david.holmes at oracle.com Sat Mar 31 07:30:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 31 Mar 2018 17:30:51 +1000 Subject: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests In-Reply-To: <5ABDA3C0.8050902@oracle.com> References: <5ABAF57B.6050005@oracle.com> <637d6d9e-e59a-165f-c9ba-ca1ffa85933d@oracle.com> <21376b33-cf1e-5690-40f5-a3bfd1da0afc@oracle.com> <6ec5e0b0-c550-5918-3671-47dfa2e966cc@oracle.com> <5ABDA3C0.8050902@oracle.com> Message-ID: <5b97f219-e3ea-d7cf-dd99-8d2f5c860e21@oracle.com> Hi Misha. This all seems okay. On 30/03/2018 12:41 PM, Mikhailo Seledtsov wrote: > While testing I discovered build errors on Mac and Solaris. The > following statement " BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exesigtest := > -ljvm" was added to a Linux-only block. I have updated the make file to > add this for any platform w/o conditions; the " exesigtest.c" is > excluded from Windows anyway down below in the make file. I am not 100% > sure this is the correct way to modify the make file; if not please > advise the correct way. That works for me. I'm not sure how Magnus envisaged this being used though. An alternative would be: ifeq ($(OPENJDK_TARGET_OS), windows) BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT + BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c + else + BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exesigtest := -ljvm endif but I think your version is more future-proof. Thanks, David > With this fix all 4 builds pass. > > Here is the updated webrev: > http://cr.openjdk.java.net/~mseledtsov/8200126.02.open/index.html > > Thank you, > Misha > > > On 3/29/18, 4:00 PM, mikhailo wrote: >> I have addressed feedback from Christian, David and Magnus. Here is >> the updated webrev: >> >> http://cr.openjdk.java.net/~mseledtsov/8200126.01.open/index.html >> >> >> I have also confirmed that output from exesigtest.c printf() is logged >> into .jtr files. >> >> ????? Grepped for "signal", I can see the output such as: >> ????????? TestSigxfsz.jtr:SIGXFSZ: signal handler using function >> 'sigset' has been set >> ????????? TestSigxfsz.jtr:SIGXFSZ: signal handler for signal 25 has >> been processed >> ????????? TestSigxfsz.jtr:SIGXFSZ: signal has been sent successfully >> ????????? TestSigxfsz.jtr:SIGXFSZ: signal has been received >> ????? Also can see other output from the printf, such as all initVM logs. >> >> >> Thank you, >> Misha >> >> On 03/29/2018 02:49 PM, mikhailo wrote: >>> Magnus, >>> >>> Thank you for advice. I have updated the makefile accordingly. Will >>> post updated webrev shortly. >>> >>> >>> Misha >>> >>> >>> On 03/28/2018 03:26 PM, Magnus Ihse Bursie wrote: >>>> Yes, you seem to have based this off an old version of >>>> JtregNativeHotspot.gmk. >>>> >>>> If you update the file I think you see how you should do it, but >>>> I'll give you some help: >>>> >>>> ifeq ($(OPENJDK_TARGET_OS), windows) >>>> ? BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT >>>> ? BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c >>>> endif >>> >> From dangersd at gmail.com Sat Mar 31 07:50:42 2018 From: dangersd at gmail.com (Alireza Mohamadi) Date: Sat, 31 Mar 2018 12:20:42 +0430 Subject: Problem building openjdk using cygwin In-Reply-To: References: Message-ID: Hi Volker, gratitude for answering my question. After reading Q&A link you provided I realized how to make junctions but I don't know which source should be attached to the target? As you've mentioned `:/cygdrive/c/progra~2/microsoft: No such file or directory` means there are no links available for "C:\Program Files (x86)\Microsoft Visual Studio", so I tried ``` C:\WINDOWS\system32>mklink /j "C:\progra~2\microsoft~7" "C:\Program Files (x86)\Microsoft Visual Studio" Junction created for C:\progra~2\microsoft~7 <<===>> C:\Program Files (x86)\Microsoft Visual Studio ``` but it seems not working because I get the same error. Can you give some tips please? Sorry if I'm newbie, I'm just interested in some JEPs and want to test them in a project to see if I can deploy it later. Many thanks. On Thu, Mar 29, 2018 at 11:55 AM, Volker Simonis wrote: > Hi Alireza, > > it seems you don?t have short file names enabled for the ?Program Files? > directory. Notice that you have short file names enabled for ?c:\? (i.e. > you have ?progra~2?). > > You have to first enable short file names for the ?Program Files? > directory (see for example > https://superuser.com/questions/681330/how-to-force- > short-name-8dot3-generation). > > Afterwards you must copy ?microsoft visual studio? to a temporary > directory and finally copy it back to ?microsoft visual studio?. This > should create a short name for that directory. > > Regards, > Volker > > Alireza Mohamadi schrieb am Do. 29. M?rz 2018 um > 06:08: > >> Hi. I wanted to build OpenJDK in windows using cygwin, and I set VC >> compiler path, but due to whitespaces in the path I can't build, with the >> following error: >> ``` >> configure: Rewriting CC to "/cygdrive/c/progra~2/microsoft visual >> studio/2017/community/vc/tools/msvc/14.13.26128/bin/hostx86/x64/cl" >> checking resolved symbolic links for CC... no symlink >> configure: The C compiler (located as /cygdrive/c/progra~2/microsoft >> visual >> studio/2017/community/vc/tools/msvc/14.13.26128/bin/hostx86/x64/cl) does >> not seem to be the required microsoft compiler.configure: error: A >> microsoft compiler is reconfigure: The result from running it was: >> "/home/SuNova/jdk/build/.configure-support/generated-configure.sh: line >> 35050: /cygdrive/c/progra~2/microsoft: No such file or directory" >> configure exiting with result code 1 >> ``` >> Well it's not in my hands to set compiler path while installing VS2017 and >> it does this automatically, so what can I do in this case? >> >> >> -- >> Sometimes the best results can be achieved in the worst conditions >> Wish you the bests :) >> Alireza >> > -- Sometimes the best results can be achieved in the worst conditions Wish you the bests :) Alireza From david.holmes at oracle.com Sat Mar 31 02:53:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 31 Mar 2018 12:53:02 +1000 Subject: space.inline.hpp build failure In-Reply-To: References: Message-ID: <8d453d26-4f9b-d872-4175-fa6b3f2e1dbe@oracle.com> Moving discussion to hotspot-gc-dev David On 30/03/2018 4:36 PM, Peter Johnson wrote: > When cross compiling either 9 or 10 to ARM with gcc 5.5.0, I get the > following linker error: > /tmp/cc7TKVtK.ltrans2.ltrans.o: In function > `OffsetTableContigSpace::block_start_const(void const*) const': > :(.text+0x26e4): undefined reference to > `BlockOffsetTable::block_start(void const*) const' > /tmp/cc7TKVtK.ltrans13.ltrans.o: In function > `OffsetTableContigSpace::verify() const': > :(.text+0x2ca6): undefined reference to > `BlockOffsetTable::block_start(void const*) const' > collect2: error: ld returned 1 exit status > > This appears to be due to a missing include in space.inline.hpp. Applying > the following patch fixes the build for me. > > Thanks, > Peter > > diff -r 5ab7a67bc155 src/share/vm/gc/shared/space.inline.hpp > --- a/src/share/vm/gc/shared/space.inline.hpp Fri Sep 08 18:24:18 2017 > +0000 > +++ b/src/share/vm/gc/shared/space.inline.hpp Thu Mar 29 23:25:25 2018 > -0700 > @@ -26,6 +26,7 @@ > #define SHARE_VM_GC_SHARED_SPACE_INLINE_HPP > > #include "gc/serial/markSweep.inline.hpp" > +#include "gc/shared/blockOffsetTable.inline.hpp" > #include "gc/shared/collectedHeap.hpp" > #include "gc/shared/generation.hpp" > #include "gc/shared/space.hpp" >