From erik.joelsson at oracle.com Wed Jan 2 08:52:03 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 2 Jan 2019 09:52:03 +0100 Subject: RFR(M): 8215902: Add support for SoftFloat-3e library In-Reply-To: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> Message-ID: <22c3e7fe-b092-bae5-39d2-2a28c96d5412@oracle.com> From a build perspective, this looks very good. I think adding a link to the github project in the doc makes sense if you want to do that. /Erik On 2018-12-25 16:19, Jakub Van?k wrote: > Hi, > > please review this webrev. It is a successor of the softfloat-3 [patch] > thread (first email > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html > ) > > Changes since the last patch (v6): > > - renamed --with-softloat* to --with-sflt* (it is more compact and it > corresponds to the old --with-sflt-lib=... option) > > - license is now obtained via --with-sflt-license switch (so it is not > included in OpenJDK source tree) > > - updated documentation (slight rewording, added the license option) > > - checks for default --with/--without behavior are in place again > (I forgot them when I changed the way the library is detected) > > - added a simple testcase - I found a disrepancy between softfloat and > system function behavior. When a float with bits 0x003FFFFF is > added to 0x00000001, the correct result is 0x00400000, but the > default software floating point implementation returns 0x00000000. > However I'm not sure where to put this test - now it is in > test/hotspot/jtreg/compiler/floatingpoint. > > - comments in code refer to CR 6757269 and newly JDK-8215902 too. > > I have created a repository with SoftFloat-3e with build configuration > specifically for OpenJDK on armel: > https://github.com/ev3dev-lang-java/softfloat-openjdk > > I can add a link to it to the documentation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 > Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ > CI build: https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ > > Cheers, > > Jakub > From Alan.Bateman at oracle.com Wed Jan 2 08:50:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jan 2019 00:50:33 -0800 (PST) Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> Message-ID: <3b6ebd28-c27c-823a-b3ab-85c55be1db76@oracle.com> On 28/12/2018 06:34, Fu Jie wrote: > Hi, > > Please review this patch for a build failure with NetBeans: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 > Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ > > Summary > The build failure is caused by an incorrect setting of preBuildCommand > in make/nb_native/nbproject/configurations.xml. > And all invalid source code items in configurations.xml have been > removed. I don't know the complete history as to why these project files are checked into the repo but doesn't it mean configuration.xml needs to be updated every time that a .c, .h, .cpp, or .hpp file is added, moved, or removed? I assume it will need to an update every week to keep it current so I wonder if you've looked at checking in a script that generates the project to avoid this ongoing maintenance. -Alan From erik.joelsson at oracle.com Wed Jan 2 08:51:08 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 2 Jan 2019 09:51:08 +0100 Subject: [PATCH] Ignore additional build/ directories In-Reply-To: References: <2be7e5e5-8fb2-549a-0f55-b2d9a5249d03@oracle.com> Message-ID: <9d8cf226-cfcb-aa8e-e4c3-a1643eccdaf5@oracle.com> Unless that rewrite is planned very soon, I would say adding another entry to .hgignore/.gitignore is a rather small and simple change. /Erik On 2018-12-31 09:14, Magnus Ihse Bursie wrote: > The hsdis build is planned for rewrite. I'd rather not make hacky fixes like this. > > /Magnus > >> 31 dec. 2018 kl. 00:42 skrev Sergei Ustimenko : >> >> Eh, please disregard the pattern from the previous mail. I mean is it worth >> ignoring something more specific like "/src/utils/hsdis/build". >> >>> On Sun, Dec 30, 2018, 23:48 Sergei Ustimenko >> >>> Hi David, >>> >>> Whoops, indeed it exists. Perhaps then something like >>> "src/utils/**/build" would be better? >>> >>> The reason I raise it is that I've eventually stumbled upon >>> quite an excessive output of `hg status`. Perhaps that is >>> something worth fixing. >>> >>> Thanks, >>> Sergei >>> >>> On Sun, 30 Dec 2018 at 22:24, David Holmes >>> wrote: >>> >>>> Hi, >>>> >>>>> On 31/12/2018 4:43 am, Sergei Ustimenko wrote: >>>>> Hi, >>>>> >>>>> I was recently building hsdis at src/utils/hsdis and found out that >>>>> the build/ directory here is not ignored. Ignore pattern in .hgignore >>>>> is "^build/" and in .gitignore it is "build/" respectively. >>>>> >>>>> I wonder if pattern could be extended to ignore at least >>>>> "src/**/build" like in the patch below: >>>> Nope because: >>>> >>>> src/utils/src/build/ >>>> >>>> exists. >>>> >>>> Cheers, >>>> David >>>> >>>>> diff --git a/.gitignore b/.gitignore >>>>> --- a/.gitignore >>>>> +++ b/.gitignore >>>>> @@ -1,4 +1,5 @@ >>>>> /build/ >>>>> +/src/**/build/** >>>>> /dist/ >>>>> /.idea/ >>>>> nbproject/private/ >>>>> diff --git a/.hgignore b/.hgignore >>>>> --- a/.hgignore >>>>> +++ b/.hgignore >>>>> @@ -1,4 +1,5 @@ >>>>> ^build/ >>>>> +^src/.*/build/.* >>>>> ^dist/ >>>>> ^.idea/ >>>>> nbproject/private/ >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Sergei From erik.joelsson at oracle.com Wed Jan 2 13:46:13 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 2 Jan 2019 14:46:13 +0100 Subject: RFR: JDK-8215991: Stop hiding exception from ArtifactResolver failures in tests Message-ID: <34368351-09d8-f91f-2594-12ac1c083518@oracle.com> In the test lib, we have an ArtifactResolver which is used by tests that need external resources. Internally at Oracle we hook Jib into this to provide such dependencies. For other users, it's possible to specify the path to such a dependency using a system property. If something goes wrong while resolving the dependencies, the ArtifactResolver currently swallows the exception and falls back on the default property based resolver, making it hard to figure out the problem. If the user provided the environment for calling Jib, I don't think we should try to revert to the default resolver on exception, but instead the exception should be propagated to the test. Webrev: http://cr.openjdk.java.net/~erikj/8215991/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215991 /Erik From tim.bell at oracle.com Wed Jan 2 17:34:07 2019 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 02 Jan 2019 09:34:07 -0800 Subject: RFR: JDK-8215991: Stop hiding exception from ArtifactResolver failures in tests In-Reply-To: <34368351-09d8-f91f-2594-12ac1c083518@oracle.com> References: <34368351-09d8-f91f-2594-12ac1c083518@oracle.com> Message-ID: <5C2CF60F.2020307@oracle.com> Erik: > In the test lib, we have an ArtifactResolver which is used by tests that > need external resources. Internally at Oracle we hook Jib into this to > provide such dependencies. For other users, it's possible to specify the > path to such a dependency using a system property. > > If something goes wrong while resolving the dependencies, the > ArtifactResolver currently swallows the exception and falls back on the > default property based resolver, making it hard to figure out the problem. > > If the user provided the environment for calling Jib, I don't think we > should try to revert to the default resolver on exception, but instead > the exception should be propagated to the test. > > Webrev: http://cr.openjdk.java.net/~erikj/8215991/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215991 Looks good. Tim From christian.tornqvist at oracle.com Thu Jan 3 00:23:19 2019 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 2 Jan 2019 16:23:19 -0800 Subject: RFR: JDK-8215991: Stop hiding exception from ArtifactResolver failures in tests In-Reply-To: <34368351-09d8-f91f-2594-12ac1c083518@oracle.com> References: <34368351-09d8-f91f-2594-12ac1c083518@oracle.com> Message-ID: Looks good. Thanks, Christian > On Jan 2, 2019, at 5:46 AM, Erik Joelsson wrote: > > In the test lib, we have an ArtifactResolver which is used by tests that need external resources. Internally at Oracle we hook Jib into this to provide such dependencies. For other users, it's possible to specify the path to such a dependency using a system property. > > If something goes wrong while resolving the dependencies, the ArtifactResolver currently swallows the exception and falls back on the default property based resolver, making it hard to figure out the problem. > > If the user provided the environment for calling Jib, I don't think we should try to revert to the default resolver on exception, but instead the exception should be propagated to the test. > > Webrev: http://cr.openjdk.java.net/~erikj/8215991/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215991 > > /Erik > From andrewluotechnologies at outlook.com Thu Jan 3 04:06:51 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Thu, 3 Jan 2019 04:06:51 +0000 Subject: [PATCH] Fix devkit creation in WSL Message-ID: Hi, I noticed that we have a few scripts checked in for creating devkits on Windows. However they only work in Cygwin. Since we recently added support for WSL, it seems like it would be nice to be able to use those scripts on WSL as well... Anyways, patch is attached. This one you do have to open a VS2017 Native Tools Command Prompt but I think that's the same as before (in Cygwin). I tested the script in WSL and everything seems to work (I did have to change some of the versions at the top since the version of VS2017 I have installed is much newer, but I reverted those changes before generating this diff), but will need someone to check Cygwin as well. I didn't update the VS2013 and VS2015 scripts. As far as I'm aware we don't (officially) support those compilers anymore: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms Thanks, -Andrew -------------- next part -------------- diff --git a/make/devkit/createWindowsDevkit2017.sh b/make/devkit/createWindowsDevkit2017.sh --- a/make/devkit/createWindowsDevkit2017.sh +++ b/make/devkit/createWindowsDevkit2017.sh @@ -25,7 +25,7 @@ # # This script copies parts of a Visual Studio installation into a devkit -# suitable for building OpenJDK and OracleJDK. Needs to run in Cygwin. +# suitable for building OpenJDK and OracleJDK. Needs to run in Cygwin or WSL. # erik.joelsson at oracle.com VS_VERSION="2017" @@ -34,6 +34,8 @@ SDK_VERSION="10" SDK_FULL_VERSION="10.0.16299.0" MSVC_DIR="Microsoft.VC141.CRT" +MSVC_FULL_VERSION="14.12.25827" +REDIST_FULL_VERSION="14.12.25810" SCRIPT_DIR="$(cd "$(dirname $0)" > /dev/null && pwd)" BUILD_DIR="${SCRIPT_DIR}/../../build/devkit" @@ -41,23 +43,44 @@ ################################################################################ # Prepare settings +UNAME_SYSTEM=`uname -s` +UNAME_RELEASE=`uname -r` + +# Detect cygwin or WSL +IS_CYGWIN=`echo $UNAME_SYSTEM | grep -i CYGWIN` +IS_WSL=`echo $UNAME_RELEASE | grep Microsoft` +if test "x$IS_CYGWIN" != "x"; then + BUILD_ENV="cygwin" +elif test "x$IS_WSL" != "x"; then + BUILD_ENV="wsl" +else + echo "Unknown environment; only Cygwin and WSL are supported." + exit 1 +fi + +if test "x$BUILD_ENV" = "xcygwin"; then + WINDOWS_PATH_TO_UNIX_PATH="cygpath -u" +elif test "x$BUILD_ENV" = "xwsl"; then + WINDOWS_PATH_TO_UNIX_PATH="wslpath -u" +fi + # Work around the insanely named ProgramFiles(x86) env variable -PROGRAMFILES_X86="$(cygpath "$(env | sed -n 's/^ProgramFiles(x86)=//p')")" +PROGRAMFILES_X86="$($WINDOWS_PATH_TO_UNIX_PATH "$(cmd.exe /c set | sed -n 's/^ProgramFiles(x86)=//p' | tr -d '\r')")" # Find Visual Studio installation dir -eval VSNNNCOMNTOOLS="\"\${VS${VS_VERSION_NUM_NODOT}COMNTOOLS}\"" +VSNNNCOMNTOOLS=`cmd.exe /c echo %VS${VS_VERSION_NUM_NODOT}COMNTOOLS% | tr -d '\r'` if [ -d "$VSNNNCOMNTOOLS" ]; then - VS_INSTALL_DIR="$(cygpath "$VSNNNCOMNTOOLS/../..")" + VS_INSTALL_DIR="$($WINDOWS_PATH_TO_UNIX_PATH "$VSNNNCOMNTOOLS/../..")" else VS_INSTALL_DIR="${PROGRAMFILES_X86}/Microsoft Visual Studio/2017" - VS_INSTALL_DIR="$(ls -d "${VS_INSTALL_DIR}/"{Community,Professional} 2>/dev/null | head -n1)" - VS_INSTALL_DIR="$(cygpath "$VS_INSTALL_DIR")" + VS_INSTALL_DIR="$(ls -d "${VS_INSTALL_DIR}/"{Community,Professional,Enterprise} 2>/dev/null | head -n1)" fi echo "VS_INSTALL_DIR: $VS_INSTALL_DIR" # Extract semantic version -POTENTIAL_INI_FILES="Common7\IDE\wdexpress.isolation.ini Common7\IDE\devenv.isolation.ini" +POTENTIAL_INI_FILES="Common7/IDE/wdexpress.isolation.ini Common7/IDE/devenv.isolation.ini" for f in $POTENTIAL_INI_FILES; do +echo "$VS_INSTALL_DIR/$f" if [ -f "$VS_INSTALL_DIR/$f" ]; then VS_VERSION_SP="$(grep ^SemanticVersion= "$VS_INSTALL_DIR/$f")" # Remove SemnaticVersion= @@ -86,8 +109,8 @@ # Copy Visual Studio files if [ ! -d $DEVKIT_ROOT/VC ]; then - VC_SUBDIR="VC/Tools/MSVC/14.12.25827" - REDIST_SUBDIR="VC/Redist/MSVC/14.12.25810" + VC_SUBDIR="VC/Tools/MSVC/$MSVC_FULL_VERSION" + REDIST_SUBDIR="VC/Redist/MSVC/$REDIST_FULL_VERSION" echo "Copying VC..." mkdir -p $DEVKIT_ROOT/VC/bin cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/x64" $DEVKIT_ROOT/VC/bin/ @@ -117,7 +140,7 @@ ################################################################################ # Copy SDK files -SDK_INSTALL_DIR="$(cygpath "$PROGRAMFILES_X86/Windows Kits/$SDK_VERSION")" +SDK_INSTALL_DIR="$PROGRAMFILES_X86/Windows Kits/$SDK_VERSION" echo "SDK_INSTALL_DIR: $SDK_INSTALL_DIR" if [ ! -d $DEVKIT_ROOT/$SDK_VERSION ]; then From fujie at loongson.cn Thu Jan 3 07:22:27 2019 From: fujie at loongson.cn (Fu Jie) Date: Thu, 3 Jan 2019 15:22:27 +0800 Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <3b6ebd28-c27c-823a-b3ab-85c55be1db76@oracle.com> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> <3b6ebd28-c27c-823a-b3ab-85c55be1db76@oracle.com> Message-ID: Thanks Alan for your review and valuable advice. I think it's worth keeping a NB project in the repo since it seems more convenient for IDE developers. And to keep configurations.xml current is also important. I made a patch to fix the issue mentioned by Alan. Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.01/ Thanks Ao Qi for posting the webrev. The main idea is that configurations.xml can be split into two parts: the manually configured part and the automatically generated part. Only the manually configured part is checked into the repo which is now less than 80 lines. And the other part will be generated automatically by NetBeans the first time when the project is opened. The complete configurations.xml would be more than 20k lines after the automatically generated part was filled in. With this patch, configurations.xml becomes source-code independent and there is no need to update it anymore. Would you please review it and give me some advice? Thanks. Best Regards, Jie On 2019/1/2 ??4:50, Alan Bateman wrote: > On 28/12/2018 06:34, Fu Jie wrote: >> Hi, >> >> Please review this patch for a build failure with NetBeans: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 >> Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ >> >> Summary >> The build failure is caused by an incorrect setting of >> preBuildCommand in make/nb_native/nbproject/configurations.xml. >> And all invalid source code items in configurations.xml have been >> removed. > I don't know the complete history as to why these project files are > checked into the repo but doesn't it mean configuration.xml needs to > be updated every time that a .c, .h, .cpp, or .hpp file is added, > moved, or removed? I assume it will need to an update every week to > keep it current so I wonder if you've looked at checking in a script > that generates the project to avoid this ongoing maintenance. > > -Alan From Alan.Bateman at oracle.com Thu Jan 3 08:07:30 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Jan 2019 08:07:30 +0000 Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> <3b6ebd28-c27c-823a-b3ab-85c55be1db76@oracle.com> Message-ID: On 03/01/2019 07:22, Fu Jie wrote: > Thanks Alan for your review and valuable advice. > > I think it's worth keeping a NB project in the repo since it seems > more convenient for IDE developers. > And to keep configurations.xml current is also important. > > I made a patch to fix the issue mentioned by Alan. > Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.01/ > Thanks Ao Qi for posting the webrev. > > The main idea is that configurations.xml can be split into two parts: > the manually configured part and the automatically generated part. > Only the manually configured part is checked into the repo which is > now less than 80 lines. > And the other part will be generated automatically by NetBeans the > first time when the project is opened. > The complete configurations.xml would be more than 20k lines after the > automatically generated part was filled in. > > With this patch, configurations.xml becomes source-code independent > and there is no need to update it anymore. > Would you please review it and give me some advice? This looks much better. Is the intent that someone using this project can edit all the sources in the JDK or just hotspot and the JNI/native code in the libraries? I ask because I don't understand how NB will locate the generated sources in gensrc, also not clear how NB will deal with java sources that are platform specific. -Alan From fujie at loongson.cn Thu Jan 3 08:46:04 2019 From: fujie at loongson.cn (Fu Jie) Date: Thu, 3 Jan 2019 16:46:04 +0800 Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> <3b6ebd28-c27c-823a-b3ab-85c55be1db76@oracle.com> Message-ID: <45d4bc67-5ee6-4f9a-a994-6cea95bdc3c9@loongson.cn> Hi Alan, With NetBeans, we can edit all the sources in the JDK just like using a vim. But I don't think that is the main intent of the NB project. For me, I found it more convenient to analyze the source code such as finding the definition and usages of a method, showing the call graph in a method, and viewing the type hierarchy. And it seems more comfortable debugging with the GUI support for some developers. NetBeans just shares the building scripts as we do in a Linux terminal. So I don't think there is any difference when building OpenJDK with NetBeans except for the GUIs. Thanks again. Best Regards, Jie On 2019/1/3 ??4:07, Alan Bateman wrote: > On 03/01/2019 07:22, Fu Jie wrote: >> Thanks Alan for your review and valuable advice. >> >> I think it's worth keeping a NB project in the repo since it seems >> more convenient for IDE developers. >> And to keep configurations.xml current is also important. >> >> I made a patch to fix the issue mentioned by Alan. >> Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.01/ >> Thanks Ao Qi for posting the webrev. >> >> The main idea is that configurations.xml can be split into two parts: >> the manually configured part and the automatically generated part. >> Only the manually configured part is checked into the repo which is >> now less than 80 lines. >> And the other part will be generated automatically by NetBeans the >> first time when the project is opened. >> The complete configurations.xml would be more than 20k lines after >> the automatically generated part was filled in. >> >> With this patch, configurations.xml becomes source-code independent >> and there is no need to update it anymore. >> Would you please review it and give me some advice? > This looks much better. Is the intent that someone using this project > can edit all the sources in the JDK or just hotspot and the JNI/native > code in the libraries? I ask because I don't understand how NB will > locate the generated sources in gensrc, also not clear how NB will > deal with java sources that are platform specific. > > -Alan From erik.joelsson at oracle.com Thu Jan 3 09:21:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 Jan 2019 10:21:48 +0100 Subject: RFR: JDK-8216048: Fix devkit creation in WSL In-Reply-To: References: Message-ID: <06509d1c-d2a3-0f39-3d41-f1f6d122dec4@oracle.com> Hello Andrew, Thanks for fixing this. The patch looks good. I have verified that it produces the same output in WSL and Cygwin. Just like in Cygwin, I did not need to be in a Tools Command Prompt to run it (because VS was installed in the default location). Regarding the hard coded dir version strings, I'm in the process of updating our kits to the latest VS2017 update, and in that patch, I chose to dynamically resolve those versions instead of putting them in the script. I would expect that to be ready for push sometime this spring. The older VS2013 and VS2015 scripts are indeed best left alone. We should probably delete them from the repo at this point. I've created https://bugs.openjdk.java.net/browse/JDK-8216048 for this and uploaded the patch as a webrev here: http://cr.openjdk.java.net/~erikj/8216048/webrev.01/ In addition to your changes, I bumped the copyright year and fixed indentation on one line. /Erik On 2019-01-03 05:06, Andrew Luo wrote: > Hi, > > I noticed that we have a few scripts checked in for creating devkits on Windows. However they only work in Cygwin. Since we recently added support for WSL, it seems like it would be nice to be able to use those scripts on WSL as well... > > Anyways, patch is attached. This one you do have to open a VS2017 Native Tools Command Prompt but I think that's the same as before (in Cygwin). I tested the script in WSL and everything seems to work (I did have to change some of the versions at the top since the version of VS2017 I have installed is much newer, but I reverted those changes before generating this diff), but will need someone to check Cygwin as well. > > I didn't update the VS2013 and VS2015 scripts. As far as I'm aware we don't (officially) support those compilers anymore: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > Thanks, > > -Andrew From erik.joelsson at oracle.com Thu Jan 3 10:30:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 Jan 2019 11:30:17 +0100 Subject: RFR: JDK-8216021: RunTest.gmk might set concurrency level to 1 on Windows Message-ID: <2ab182ae-0358-3130-346a-9f6c2f2edcfa@oracle.com> When running tests using "make run-test-prebuilt" on Windows, the calculation of available memory may fail. This only happens on certain systems, and is likely related to which version of Cygwin that is being used. The consequence is that concurrency gets set to 1. The cause of the problem is mishandling of Windows \r line endings, which Cygwin tools are known to handle differently in different versions. To fix the problem here, I've added explicit filtering of \r before trying to interpret the memory size as a number. I checked the corresponding construct in configure, and it seems to work on the same machine where RunTestsPrebuilt.gmk failed, so I left it alone. Bug: https://bugs.openjdk.java.net/browse/JDK-8216021 Webrev: http://cr.openjdk.java.net/~erikj/8216021/webrev.01/ /Erik From andrewluotechnologies at outlook.com Thu Jan 3 17:32:33 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Thu, 3 Jan 2019 17:32:33 +0000 Subject: JDK-8216048: Fix devkit creation in WSL In-Reply-To: <06509d1c-d2a3-0f39-3d41-f1f6d122dec4@oracle.com> References: <06509d1c-d2a3-0f39-3d41-f1f6d122dec4@oracle.com> Message-ID: Hi Erik, Thanks for sponsoring this. Looking at the patch, I noticed I left in an extra "echo "$VS_INSTALL_DIR/$f"". This probably could be removed. Thanks, -Andrew -----Original Message----- From: Erik Joelsson Sent: Thursday, January 3, 2019 1:22 AM To: Andrew Luo ; build-dev at openjdk.java.net Subject: RFR: JDK-8216048: Fix devkit creation in WSL Hello Andrew, Thanks for fixing this. The patch looks good. I have verified that it produces the same output in WSL and Cygwin. Just like in Cygwin, I did not need to be in a Tools Command Prompt to run it (because VS was installed in the default location). Regarding the hard coded dir version strings, I'm in the process of updating our kits to the latest VS2017 update, and in that patch, I chose to dynamically resolve those versions instead of putting them in the script. I would expect that to be ready for push sometime this spring. The older VS2013 and VS2015 scripts are indeed best left alone. We should probably delete them from the repo at this point. I've created https://bugs.openjdk.java.net/browse/JDK-8216048 for this and uploaded the patch as a webrev here: http://cr.openjdk.java.net/~erikj/8216048/webrev.01/ In addition to your changes, I bumped the copyright year and fixed indentation on one line. /Erik On 2019-01-03 05:06, Andrew Luo wrote: > Hi, > > I noticed that we have a few scripts checked in for creating devkits on Windows. However they only work in Cygwin. Since we recently added support for WSL, it seems like it would be nice to be able to use those scripts on WSL as well... > > Anyways, patch is attached. This one you do have to open a VS2017 Native Tools Command Prompt but I think that's the same as before (in Cygwin). I tested the script in WSL and everything seems to work (I did have to change some of the versions at the top since the version of VS2017 I have installed is much newer, but I reverted those changes before generating this diff), but will need someone to check Cygwin as well. > > I didn't update the VS2013 and VS2015 scripts. As far as I'm aware we > don't (officially) support those compilers anymore: > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > Thanks, > > -Andrew From christian.tornqvist at oracle.com Thu Jan 3 21:11:31 2019 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 3 Jan 2019 13:11:31 -0800 Subject: RFR: JDK-8216021: RunTest.gmk might set concurrency level to 1 on Windows In-Reply-To: <2ab182ae-0358-3130-346a-9f6c2f2edcfa@oracle.com> References: <2ab182ae-0358-3130-346a-9f6c2f2edcfa@oracle.com> Message-ID: <4C842003-54DB-4623-85E4-753F7B3F0303@oracle.com> Looks good, thanks for fixing this! Thanks, Christian > On Jan 3, 2019, at 2:30 AM, Erik Joelsson wrote: > > When running tests using "make run-test-prebuilt" on Windows, the calculation of available memory may fail. This only happens on certain systems, and is likely related to which version of Cygwin that is being used. The consequence is that concurrency gets set to 1. The cause of the problem is mishandling of Windows \r line endings, which Cygwin tools are known to handle differently in different versions. > > To fix the problem here, I've added explicit filtering of \r before trying to interpret the memory size as a number. > > I checked the corresponding construct in configure, and it seems to work on the same machine where RunTestsPrebuilt.gmk failed, so I left it alone. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216021 > > Webrev: http://cr.openjdk.java.net/~erikj/8216021/webrev.01/ > > /Erik > From tim.bell at oracle.com Fri Jan 4 06:13:41 2019 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 03 Jan 2019 22:13:41 -0800 Subject: RFR: JDK-8216021: RunTest.gmk might set concurrency level to 1 on Windows In-Reply-To: <2ab182ae-0358-3130-346a-9f6c2f2edcfa@oracle.com> References: <2ab182ae-0358-3130-346a-9f6c2f2edcfa@oracle.com> Message-ID: <5C2EF995.6020007@oracle.com> Erik: > When running tests using "make run-test-prebuilt" on Windows, the > calculation of available memory may fail. This only happens on certain > systems, and is likely related to which version of Cygwin that is being > used. The consequence is that concurrency gets set to 1. The cause of > the problem is mishandling of Windows \r line endings, which Cygwin > tools are known to handle differently in different versions. > > To fix the problem here, I've added explicit filtering of \r before > trying to interpret the memory size as a number. > > I checked the corresponding construct in configure, and it seems to work > on the same machine where RunTestsPrebuilt.gmk failed, so I left it alone. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216021 > > Webrev: http://cr.openjdk.java.net/~erikj/8216021/webrev.01/ Looks good. Tim From yasuenag at gmail.com Fri Jan 4 07:22:11 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 4 Jan 2019 16:22:11 +0900 Subject: C4819 warnings on Windows Message-ID: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> Hi all, I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + Ubuntu 18.04 LTS). However, I saw some C4819 warnings as below: ``` c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): warning C4819: ???????????? ??? (0) ??????????????????????????????????? Unicode ???????????? ``` * The locale of my laptop is set to Japanese (CP932), thanks :-) I saw this warning at 3 files as below: 1. hotspot/share/code/codeHeapState.cpp 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h 3. hotspot/share/compiler/methodMatcher.cpp We can see the problem in 1. and 2. with iconv: $ iconv -f US-ASCII -t UTF8 I've fixed them with following patch. It works fine on my environment: http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ I think we should fix them, but I don't know what component/subcomponent should we set to JBS. Could you help? Thanks, Yasumasa From david.holmes at oracle.com Fri Jan 4 07:44:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Jan 2019 17:44:47 +1000 Subject: C4819 warnings on Windows In-Reply-To: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> References: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> Message-ID: <28f13612-c657-98ff-1a91-847309ee8a26@oracle.com> Hi Yasumasa, The two hotspot issues can be filed in one bug under hotspot->compiler and reviewed on hotspot-compiler-dev as they are source code changes not build changes. The other one is a build change but probably also needs reviewing by awt-dev. Cheers, David On 4/01/2019 5:22 pm, Yasumasa Suenaga wrote: > Hi all, > > I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + > Ubuntu 18.04 LTS). > However, I saw some C4819 warnings as below: > > ``` > c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): > warning C4819: ???????????? ??? (0) ?????????? > ????????????????????????? Unicode ?????? > ?????? > ``` > > * The locale of my laptop is set to Japanese (CP932), thanks :-) > > > I saw this warning at 3 files as below: > > ? 1. hotspot/share/code/codeHeapState.cpp > ? 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h > ? 3. hotspot/share/compiler/methodMatcher.cpp > > We can see the problem in 1. and 2. with iconv: > ? $ iconv -f US-ASCII -t UTF8 > > > I've fixed them with following patch. It works fine on my environment: > ? http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ > > I think we should fix them, but I don't know what component/subcomponent > should we set to JBS. > Could you help? > > > Thanks, > > Yasumasa From yasuenag at gmail.com Fri Jan 4 08:47:22 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 4 Jan 2019 17:47:22 +0900 Subject: C4819 warnings on Windows In-Reply-To: <28f13612-c657-98ff-1a91-847309ee8a26@oracle.com> References: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> <28f13612-c657-98ff-1a91-847309ee8a26@oracle.com> Message-ID: <68cbbe62-9969-8c2a-0bc5-e5abd7c92617@gmail.com> Thanks David! I filed two issues to JBS: https://bugs.openjdk.java.net/browse/JDK-8216154 https://bugs.openjdk.java.net/browse/JDK-8216155 Patches have been pushed to submit repo. I will send RFR when I receive result from submit repo. Yasumasa On 2019/01/04 16:44, David Holmes wrote: > Hi Yasumasa, > > The two hotspot issues can be filed in one bug under hotspot->compiler and reviewed on hotspot-compiler-dev as they are source code changes not build changes. > > The other one is a build change but probably also needs reviewing by awt-dev. > > Cheers, > David > > On 4/01/2019 5:22 pm, Yasumasa Suenaga wrote: >> Hi all, >> >> I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + Ubuntu 18.04 LTS). >> However, I saw some C4819 warnings as below: >> >> ``` >> c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): warning C4819: ???????????? ??? (0) ?????????? ????????????????????????? Unicode ?????? ?????? >> ``` >> >> * The locale of my laptop is set to Japanese (CP932), thanks :-) >> >> >> I saw this warning at 3 files as below: >> >> ?? 1. hotspot/share/code/codeHeapState.cpp >> ?? 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h >> ?? 3. hotspot/share/compiler/methodMatcher.cpp >> >> We can see the problem in 1. and 2. with iconv: >> ?? $ iconv -f US-ASCII -t UTF8 >> >> >> I've fixed them with following patch. It works fine on my environment: >> ?? http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ >> >> I think we should fix them, but I don't know what component/subcomponent should we set to JBS. >> Could you help? >> >> >> Thanks, >> >> Yasumasa From erik.joelsson at oracle.com Fri Jan 4 09:09:51 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Jan 2019 10:09:51 +0100 Subject: C4819 warnings on Windows In-Reply-To: <68cbbe62-9969-8c2a-0bc5-e5abd7c92617@gmail.com> References: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> <28f13612-c657-98ff-1a91-847309ee8a26@oracle.com> <68cbbe62-9969-8c2a-0bc5-e5abd7c92617@gmail.com> Message-ID: <6c289457-ff1c-94a1-e410-7c8b78dc173b@oracle.com> Hello Yasumasa, Looking at the freetype header, the non ascii characters are all in comments, so ignoring the warning should be fine. Consider JDK-8216155 reviewed. /Erik On 2019-01-04 09:47, Yasumasa Suenaga wrote: > Thanks David! > I filed two issues to JBS: > > ? https://bugs.openjdk.java.net/browse/JDK-8216154 > ? https://bugs.openjdk.java.net/browse/JDK-8216155 > > Patches have been pushed to submit repo. I will send RFR when I > receive result from submit repo. > > > Yasumasa > > > On 2019/01/04 16:44, David Holmes wrote: >> Hi Yasumasa, >> >> The two hotspot issues can be filed in one bug under >> hotspot->compiler and reviewed on hotspot-compiler-dev as they are >> source code changes not build changes. >> >> The other one is a build change but probably also needs reviewing by >> awt-dev. >> >> Cheers, >> David >> >> On 4/01/2019 5:22 pm, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + >>> Ubuntu 18.04 LTS). >>> However, I saw some C4819 warnings as below: >>> >>> ``` >>> c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): >>> warning C4819: ???????????? ??? (0) ?????????? >>> ????????????????????????? Unicode ?????? >>> ?????? >>> ``` >>> >>> * The locale of my laptop is set to Japanese (CP932), thanks :-) >>> >>> >>> I saw this warning at 3 files as below: >>> >>> ?? 1. hotspot/share/code/codeHeapState.cpp >>> ?? 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h >>> ?? 3. hotspot/share/compiler/methodMatcher.cpp >>> >>> We can see the problem in 1. and 2. with iconv: >>> ?? $ iconv -f US-ASCII -t UTF8 >>> >>> >>> I've fixed them with following patch. It works fine on my environment: >>> ?? http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ >>> >>> I think we should fix them, but I don't know what >>> component/subcomponent should we set to JBS. >>> Could you help? >>> >>> >>> Thanks, >>> >>> Yasumasa From yasuenag at gmail.com Fri Jan 4 09:13:20 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 4 Jan 2019 18:13:20 +0900 Subject: C4819 warnings on Windows In-Reply-To: <6c289457-ff1c-94a1-e410-7c8b78dc173b@oracle.com> References: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> <28f13612-c657-98ff-1a91-847309ee8a26@oracle.com> <68cbbe62-9969-8c2a-0bc5-e5abd7c92617@gmail.com> <6c289457-ff1c-94a1-e410-7c8b78dc173b@oracle.com> Message-ID: <741fdf31-958d-4206-f59c-0c631677f0c2@gmail.com> Thanks Erik! I will push the change of 8216155 to jdk/jdk then I receive the result from submit repo. Yasumasa On 2019/01/04 18:09, Erik Joelsson wrote: > Hello Yasumasa, > > Looking at the freetype header, the non ascii characters are all in comments, so ignoring the warning should be fine. Consider JDK-8216155 reviewed. > > /Erik > > On 2019-01-04 09:47, Yasumasa Suenaga wrote: >> Thanks David! >> I filed two issues to JBS: >> >> ? https://bugs.openjdk.java.net/browse/JDK-8216154 >> ? https://bugs.openjdk.java.net/browse/JDK-8216155 >> >> Patches have been pushed to submit repo. I will send RFR when I receive result from submit repo. >> >> >> Yasumasa >> >> >> On 2019/01/04 16:44, David Holmes wrote: >>> Hi Yasumasa, >>> >>> The two hotspot issues can be filed in one bug under hotspot->compiler and reviewed on hotspot-compiler-dev as they are source code changes not build changes. >>> >>> The other one is a build change but probably also needs reviewing by awt-dev. >>> >>> Cheers, >>> David >>> >>> On 4/01/2019 5:22 pm, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + Ubuntu 18.04 LTS). >>>> However, I saw some C4819 warnings as below: >>>> >>>> ``` >>>> c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): warning C4819: ???????????? ??? (0) ?????????? ????????????????????????? Unicode ?????? ?????? >>>> ``` >>>> >>>> * The locale of my laptop is set to Japanese (CP932), thanks :-) >>>> >>>> >>>> I saw this warning at 3 files as below: >>>> >>>> ?? 1. hotspot/share/code/codeHeapState.cpp >>>> ?? 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h >>>> ?? 3. hotspot/share/compiler/methodMatcher.cpp >>>> >>>> We can see the problem in 1. and 2. with iconv: >>>> ?? $ iconv -f US-ASCII -t UTF8 >>>> >>>> >>>> I've fixed them with following patch. It works fine on my environment: >>>> ?? http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ >>>> >>>> I think we should fix them, but I don't know what component/subcomponent should we set to JBS. >>>> Could you help? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa From weijun.wang at oracle.com Fri Jan 4 09:29:49 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 4 Jan 2019 17:29:49 +0800 Subject: C4819 warnings on Windows In-Reply-To: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> References: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> Message-ID: Just curious, why were you mentioning WSL and Ubuntu? Isn't this a pure Windows build issue? Or is it possible to use WSL instead of Cygwin to launch the build process now? That's unbelievable. Thanks, Max > On Jan 4, 2019, at 3:22 PM, Yasumasa Suenaga wrote: > > Hi all, > > I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + Ubuntu 18.04 LTS). > However, I saw some C4819 warnings as below: > > ``` > c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): warning C4819: ???????????? ??? (0) ??????????????????????????????????? Unicode ???????????? > ``` > > * The locale of my laptop is set to Japanese (CP932), thanks :-) > > > I saw this warning at 3 files as below: > > 1. hotspot/share/code/codeHeapState.cpp > 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h > 3. hotspot/share/compiler/methodMatcher.cpp > > We can see the problem in 1. and 2. with iconv: > $ iconv -f US-ASCII -t UTF8 > > > I've fixed them with following patch. It works fine on my environment: > http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ > > I think we should fix them, but I don't know what component/subcomponent should we set to JBS. > Could you help? > > > Thanks, > > Yasumasa From erik.joelsson at oracle.com Fri Jan 4 09:48:42 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Jan 2019 10:48:42 +0100 Subject: C4819 warnings on Windows In-Reply-To: References: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> Message-ID: On 2019-01-04 10:29, Weijun Wang wrote: > Just curious, why were you mentioning WSL and Ubuntu? Isn't this a pure Windows build issue? Or is it possible to use WSL instead of Cygwin to launch the build process now? That's unbelievable. The OpenJDK build can be run in WSL since https://bugs.openjdk.java.net/browse/JDK-8215445. (Note that Jib does not support WSL yet) /Erik > Thanks, > Max > >> On Jan 4, 2019, at 3:22 PM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + Ubuntu 18.04 LTS). >> However, I saw some C4819 warnings as below: >> >> ``` >> c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): warning C4819: ???????????? ??? (0) ??????????????????????????????????? Unicode ???????????? >> ``` >> >> * The locale of my laptop is set to Japanese (CP932), thanks :-) >> >> >> I saw this warning at 3 files as below: >> >> 1. hotspot/share/code/codeHeapState.cpp >> 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h >> 3. hotspot/share/compiler/methodMatcher.cpp >> >> We can see the problem in 1. and 2. with iconv: >> $ iconv -f US-ASCII -t UTF8 >> >> >> I've fixed them with following patch. It works fine on my environment: >> http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ >> >> I think we should fix them, but I don't know what component/subcomponent should we set to JBS. >> Could you help? >> >> >> Thanks, >> >> Yasumasa From yasuenag at gmail.com Fri Jan 4 09:50:45 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 4 Jan 2019 18:50:45 +0900 Subject: C4819 warnings on Windows In-Reply-To: References: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> Message-ID: <877ee571-0f3a-e06f-5ae3-65bde2a51f0c@gmail.com> Hi Max, I do not have Cygwin, so I can't build on it. I guess this issue has two causes: 1. VS 2017 - I guess submit repo uses VS 2015 for Windows builds. 2. Locale - I use Windows which locale is set to Japanese, so C compiler might be hit any encoding issue(s). Anyway, these codes has characters which are out of range of us-ascii. So we might hit some issues in the future. Thanks, Yasumasa On 2019/01/04 18:29, Weijun Wang wrote: > Just curious, why were you mentioning WSL and Ubuntu? Isn't this a pure Windows build issue? Or is it possible to use WSL instead of Cygwin to launch the build process now? That's unbelievable. > > Thanks, > Max > >> On Jan 4, 2019, at 3:22 PM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + Ubuntu 18.04 LTS). >> However, I saw some C4819 warnings as below: >> >> ``` >> c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): warning C4819: ???????????? ??? (0) ??????????????????????????????????? Unicode ???????????? >> ``` >> >> * The locale of my laptop is set to Japanese (CP932), thanks :-) >> >> >> I saw this warning at 3 files as below: >> >> 1. hotspot/share/code/codeHeapState.cpp >> 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h >> 3. hotspot/share/compiler/methodMatcher.cpp >> >> We can see the problem in 1. and 2. with iconv: >> $ iconv -f US-ASCII -t UTF8 >> >> >> I've fixed them with following patch. It works fine on my environment: >> http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ >> >> I think we should fix them, but I don't know what component/subcomponent should we set to JBS. >> Could you help? >> >> >> Thanks, >> >> Yasumasa > From erik.joelsson at oracle.com Fri Jan 4 09:57:32 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Jan 2019 10:57:32 +0100 Subject: C4819 warnings on Windows In-Reply-To: <877ee571-0f3a-e06f-5ae3-65bde2a51f0c@gmail.com> References: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> <877ee571-0f3a-e06f-5ae3-65bde2a51f0c@gmail.com> Message-ID: <862aa3ec-83ce-a46b-c567-155ae43b7fe6@oracle.com> On 2019-01-04 10:50, Yasumasa Suenaga wrote: > Hi Max, > > I do not have Cygwin, so I can't build on it. > > I guess this issue has two causes: > > > ? 1. VS 2017 - I guess submit repo uses VS 2015 for Windows builds. We use VS2017 at Oracle (which includes the submit repo), but the update is 15.5.5. We are planning on bumping this for JDK 13. /Erik > ? 2. Locale - I use Windows which locale is set to Japanese, so C > compiler might be hit any encoding issue(s). > > > Anyway, these codes has characters which are out of range of us-ascii. > So we might hit some issues in the future. > > > Thanks, > > Yasumasa > > > On 2019/01/04 18:29, Weijun Wang wrote: >> Just curious, why were you mentioning WSL and Ubuntu? Isn't this a >> pure Windows build issue? Or is it possible to use WSL instead of >> Cygwin to launch the build process now? That's unbelievable. >> >> Thanks, >> Max >> >>> On Jan 4, 2019, at 3:22 PM, Yasumasa Suenaga >>> wrote: >>> >>> Hi all, >>> >>> I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + >>> Ubuntu 18.04 LTS). >>> However, I saw some C4819 warnings as below: >>> >>> ``` >>> c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): >>> warning C4819: ???????????? ??? (0) >>> ??????????????????????????????????? >>> Unicode ???????????? >>> ``` >>> >>> * The locale of my laptop is set to Japanese (CP932), thanks :-) >>> >>> >>> I saw this warning at 3 files as below: >>> >>> ? 1. hotspot/share/code/codeHeapState.cpp >>> ? 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h >>> ? 3. hotspot/share/compiler/methodMatcher.cpp >>> >>> We can see the problem in 1. and 2. with iconv: >>> ? $ iconv -f US-ASCII -t UTF8 >>> >>> >>> I've fixed them with following patch. It works fine on my environment: >>> ? http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ >>> >>> I think we should fix them, but I don't know what >>> component/subcomponent should we set to JBS. >>> Could you help? >>> >>> >>> Thanks, >>> >>> Yasumasa >> From erik.joelsson at oracle.com Fri Jan 4 10:20:26 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Jan 2019 11:20:26 +0100 Subject: JDK-8216048: Fix devkit creation in WSL In-Reply-To: References: <06509d1c-d2a3-0f39-3d41-f1f6d122dec4@oracle.com> Message-ID: <6307a7a0-e630-aa25-282e-5a5412e16a4e@oracle.com> Hello Andrew, I've pushed this now. A college eager to try this out discovered that the target "make hotspot-ide-project" does not work in WSL. Is that something you could look into? I tried a quick fix of the obvious (cygpath -> wslpath), but a more tricky problem is that the VS project we generate calls make to build, but in the case of WSL the make executable is not reachable from Windows. Perhaps we can generate some kind of wrapper script in the build dir to work around it? It depends on what kind of executables VS is able to run directly. It's also possible to put the logic in the Java source of the project generator tool. What do you think? /Erik On 2019-01-03 18:32, Andrew Luo wrote: > Hi Erik, > > Thanks for sponsoring this. Looking at the patch, I noticed I left in an extra "echo "$VS_INSTALL_DIR/$f"". This probably could be removed. > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson > Sent: Thursday, January 3, 2019 1:22 AM > To: Andrew Luo ; build-dev at openjdk.java.net > Subject: RFR: JDK-8216048: Fix devkit creation in WSL > > Hello Andrew, > > Thanks for fixing this. The patch looks good. I have verified that it produces the same output in WSL and Cygwin. Just like in Cygwin, I did not need to be in a Tools Command Prompt to run it (because VS was installed in the default location). > > Regarding the hard coded dir version strings, I'm in the process of updating our kits to the latest VS2017 update, and in that patch, I chose to dynamically resolve those versions instead of putting them in the script. I would expect that to be ready for push sometime this spring. > > The older VS2013 and VS2015 scripts are indeed best left alone. We should probably delete them from the repo at this point. > > I've created https://bugs.openjdk.java.net/browse/JDK-8216048 for this and uploaded the patch as a webrev here: > > http://cr.openjdk.java.net/~erikj/8216048/webrev.01/ > > In addition to your changes, I bumped the copyright year and fixed indentation on one line. > > /Erik > > On 2019-01-03 05:06, Andrew Luo wrote: >> Hi, >> >> I noticed that we have a few scripts checked in for creating devkits on Windows. However they only work in Cygwin. Since we recently added support for WSL, it seems like it would be nice to be able to use those scripts on WSL as well... >> >> Anyways, patch is attached. This one you do have to open a VS2017 Native Tools Command Prompt but I think that's the same as before (in Cygwin). I tested the script in WSL and everything seems to work (I did have to change some of the versions at the top since the version of VS2017 I have installed is much newer, but I reverted those changes before generating this diff), but will need someone to check Cygwin as well. >> >> I didn't update the VS2013 and VS2015 scripts. As far as I'm aware we >> don't (officially) support those compilers anymore: >> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >> >> Thanks, >> >> -Andrew From weijun.wang at oracle.com Fri Jan 4 10:50:00 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 4 Jan 2019 18:50:00 +0800 Subject: C4819 warnings on Windows In-Reply-To: References: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> Message-ID: <0DD54F92-665A-43BA-970F-AC7D90D1374B@oracle.com> Wow, very impressive. I haven't played with WSL and thought it's like a VM running Linux inside Windows. So one either logins to it and build a Linux JDK or stay outside to build a Windows JDK. Never imagined that you can mix the two to do such marvelous things. --Max > On Jan 4, 2019, at 5:48 PM, Erik Joelsson wrote: > > > On 2019-01-04 10:29, Weijun Wang wrote: >> Just curious, why were you mentioning WSL and Ubuntu? Isn't this a pure Windows build issue? Or is it possible to use WSL instead of Cygwin to launch the build process now? That's unbelievable. > > The OpenJDK build can be run in WSL since https://bugs.openjdk.java.net/browse/JDK-8215445. (Note that Jib does not support WSL yet) > > /Erik > >> Thanks, >> Max >> >>> On Jan 4, 2019, at 3:22 PM, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + Ubuntu 18.04 LTS). >>> However, I saw some C4819 warnings as below: >>> >>> ``` >>> c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): warning C4819: ???????????? ??? (0) ??????????????????????????????????? Unicode ???????????? >>> ``` >>> >>> * The locale of my laptop is set to Japanese (CP932), thanks :-) >>> >>> >>> I saw this warning at 3 files as below: >>> >>> 1. hotspot/share/code/codeHeapState.cpp >>> 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h >>> 3. hotspot/share/compiler/methodMatcher.cpp >>> >>> We can see the problem in 1. and 2. with iconv: >>> $ iconv -f US-ASCII -t UTF8 >>> >>> >>> I've fixed them with following patch. It works fine on my environment: >>> http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ >>> >>> I think we should fix them, but I don't know what component/subcomponent should we set to JBS. >>> Could you help? >>> >>> >>> Thanks, >>> >>> Yasumasa From erik.joelsson at oracle.com Fri Jan 4 10:55:22 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Jan 2019 11:55:22 +0100 Subject: RFR: JDK-8215400: Warn on usage of trampolines with gcc Message-ID: <67395554-6f81-d68b-bc01-bbb5459142f0@oracle.com> Hello, This small patch adds -Wtrampolines to the default set of warnings applied globally in the OpenJDK build. We do not trigger this warning today, but by adding it, combined with -Werror, we make sure we never will. Bug: https://bugs.openjdk.java.net/browse/JDK-8215400 Webrev: http://cr.openjdk.java.net/~erikj/8215400/webrev.01/ /Erik From siddhesh at gotplt.org Fri Jan 4 11:11:41 2019 From: siddhesh at gotplt.org (Siddhesh Poyarekar) Date: Fri, 4 Jan 2019 16:41:41 +0530 Subject: [PATCH] Request for Review: Override TESTDIRS correctly in tests Message-ID: <1fd1b157-2c5f-f681-515a-02a34c2d9e9b@gotplt.org> Hello, The TESTDIRS override method of selecting a subset of tests currently does not work because the TEST_SELECTION variable is not overridden correctly; it needs the 'override' keyword to override its value. Attached patch fixes this. Siddhesh PS: My contributions should be covered under my employer's (Linaro) copyright assignment. -------------- next part -------------- diff -r 2c8e6decb1c3 test/TestCommon.gmk --- a/test/TestCommon.gmk Mon Dec 03 14:25:00 2018 +0100 +++ b/test/TestCommon.gmk Fri Jan 04 11:00:21 2019 +0000 @@ -322,7 +322,7 @@ # The TESTDIRS variable can be used to select the jtreg tests to run ifdef TESTDIRS - TEST_SELECTION = $(TESTDIRS) + override TEST_SELECTION = $(TESTDIRS) endif ifeq ($(UNAME_S), SunOS) From erik.joelsson at oracle.com Fri Jan 4 12:27:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Jan 2019 13:27:09 +0100 Subject: [PATCH] Request for Review: Override TESTDIRS correctly in tests In-Reply-To: <1fd1b157-2c5f-f681-515a-02a34c2d9e9b@gotplt.org> References: <1fd1b157-2c5f-f681-515a-02a34c2d9e9b@gotplt.org> Message-ID: <70440300-b4e2-ce88-0386-594bdd67776a@oracle.com> Hello Siddhesh, I'm curious about what you are trying to do to end up needing this override. The old test makefiles have a very confusing UI and my guess is that you are using input variables (TESTDIRS) with a target they aren't meant for. Instead of trying to fix this, I would strongly recommend moving away from using the makefiles in test/ as those are deprecated and will be removed eventually. We have a new makefile framework for running tests. See doc/testing.md for details on how to use it. From a user perspective it's far easier to use and much more powerful, as well as reasonably well documented. /Erik On 2019-01-04 12:11, Siddhesh Poyarekar wrote: > Hello, > > The TESTDIRS override method of selecting a subset of tests currently > does not work because the TEST_SELECTION variable is not overridden > correctly; it needs the 'override' keyword to override its value. > Attached patch fixes this. > > Siddhesh > > PS: My contributions should be covered under my employer's (Linaro) > copyright assignment. From siddhesh at gotplt.org Fri Jan 4 12:36:34 2019 From: siddhesh at gotplt.org (Siddhesh Poyarekar) Date: Fri, 4 Jan 2019 18:06:34 +0530 Subject: [PATCH] Request for Review: Override TESTDIRS correctly in tests In-Reply-To: <70440300-b4e2-ce88-0386-594bdd67776a@oracle.com> References: <1fd1b157-2c5f-f681-515a-02a34c2d9e9b@gotplt.org> <70440300-b4e2-ce88-0386-594bdd67776a@oracle.com> Message-ID: On 04/01/19 5:57 PM, Erik Joelsson wrote: > I'm curious about what you are trying to do to end up needing this > override. The old test makefiles have a very confusing UI and my guess > is that you are using input variables (TESTDIRS) with a target they > aren't meant for. I was originally using this for jdk8u and that's where I had to use TESTDIRS to ensure that I was running all tests instead of a limited set that the default make test was running in hotspot. > Instead of trying to fix this, I would strongly recommend moving away > from using the makefiles in test/ as those are deprecated and will be > removed eventually. We have a new makefile framework for running tests. Thanks, I'll use this for tip. > See doc/testing.md for details on how to use it. From a user perspective > it's far easier to use and much more powerful, as well as reasonably > well documented. I posted a patch to fix this for 8u[1] and was advised[2] to fix this in tip too since the override existed there as well and then request a backport. If the fix is not required for tip, should I make a request to only fix this in jdk8u? Thanks, Siddhesh [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008340.html [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-January/008355.html From erik.joelsson at oracle.com Fri Jan 4 13:54:13 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Jan 2019 14:54:13 +0100 Subject: [PATCH] Request for Review: Override TESTDIRS correctly in tests In-Reply-To: References: <1fd1b157-2c5f-f681-515a-02a34c2d9e9b@gotplt.org> <70440300-b4e2-ce88-0386-594bdd67776a@oracle.com> Message-ID: <21aa2795-5889-eb52-afab-22bfb3fbdd1d@oracle.com> On 2019-01-04 13:36, Siddhesh Poyarekar wrote: > On 04/01/19 5:57 PM, Erik Joelsson wrote: >> I'm curious about what you are trying to do to end up needing this >> override. The old test makefiles have a very confusing UI and my >> guess is that you are using input variables (TESTDIRS) with a target >> they aren't meant for. > > I was originally using this for jdk8u and that's where I had to use > TESTDIRS to ensure that I was running all tests instead of a limited > set that the default make test was running in hotspot. > So what you want to achieve is running all the tests in hotspot/test? I doubt that's a very good idea, but you should be able to achieve that with this command line: make test TEST=jtreg_tests TESTDIRS=../hotspot/test/. The TESTDIRS parameter is only valid with the "jtreg_tests" target in test/Makefile, which you reach by setting the "TEST" variable on the command line to the top level target "test". Other targets in test/Makefile correspond to jtreg test groups. The suggested patch looks like it risks breaking other use cases. I would avoid tinkering with those makefiles unless absolutely necessary as they are brittle (which is why we rewrote them). /Erik >> Instead of trying to fix this, I would strongly recommend moving away >> from using the makefiles in test/ as those are deprecated and will be >> removed eventually. We have a new makefile framework for running tests. > > Thanks, I'll use this for tip. > >> See doc/testing.md for details on how to use it. From a user >> perspective it's far easier to use and much more powerful, as well as >> reasonably well documented. > > I posted a patch to fix this for 8u[1] and was advised[2] to fix this > in tip too since the override existed there as well and then request a > backport.? If the fix is not required for tip, should I make a request > to only fix this in jdk8u? > > Thanks, > Siddhesh > > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008340.html > [2] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-January/008355.html From siddhesh at gotplt.org Fri Jan 4 16:24:09 2019 From: siddhesh at gotplt.org (Siddhesh Poyarekar) Date: Fri, 4 Jan 2019 21:54:09 +0530 Subject: [PATCH] Request for Review: Override TESTDIRS correctly in tests In-Reply-To: <21aa2795-5889-eb52-afab-22bfb3fbdd1d@oracle.com> References: <1fd1b157-2c5f-f681-515a-02a34c2d9e9b@gotplt.org> <70440300-b4e2-ce88-0386-594bdd67776a@oracle.com> <21aa2795-5889-eb52-afab-22bfb3fbdd1d@oracle.com> Message-ID: <3f07f6f3-0248-cb73-b203-58d09c5a0770@gotplt.org> On 04/01/19 7:24 PM, Erik Joelsson wrote: > So what you want to achieve is running all the tests in hotspot/test? I > doubt that's a very good idea, but you should be able to achieve that > with this command line: > > make test TEST=jtreg_tests TESTDIRS=../hotspot/test/. > > The TESTDIRS parameter is only valid with the "jtreg_tests" target in > test/Makefile, which you reach by setting the "TEST" variable on the > command line to the top level target "test". Other targets in > test/Makefile correspond to jtreg test groups. That worked, thanks! > The suggested patch looks like it risks breaking other use cases. I > would avoid tinkering with those makefiles unless absolutely necessary > as they are brittle (which is why we rewrote them). Understood, thank you for the explanation. Siddhesh From tim.bell at oracle.com Fri Jan 4 16:35:07 2019 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 04 Jan 2019 08:35:07 -0800 Subject: RFR: JDK-8215400: Warn on usage of trampolines with gcc In-Reply-To: <67395554-6f81-d68b-bc01-bbb5459142f0@oracle.com> References: <67395554-6f81-d68b-bc01-bbb5459142f0@oracle.com> Message-ID: <5C2F8B3B.8060400@oracle.com> Erik: > This small patch adds -Wtrampolines to the default set of warnings > applied globally in the OpenJDK build. We do not trigger this warning > today, but by adding it, combined with -Werror, we make sure we never will. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215400 > > Webrev: http://cr.openjdk.java.net/~erikj/8215400/webrev.01/ Looks good. Tim From kim.barrett at oracle.com Fri Jan 4 17:56:12 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 Jan 2019 12:56:12 -0500 Subject: RFR: JDK-8215400: Warn on usage of trampolines with gcc In-Reply-To: <67395554-6f81-d68b-bc01-bbb5459142f0@oracle.com> References: <67395554-6f81-d68b-bc01-bbb5459142f0@oracle.com> Message-ID: <503A0728-72BB-420E-A0FB-97ACC40B0CDD@oracle.com> > On Jan 4, 2019, at 5:55 AM, Erik Joelsson wrote: > > Hello, > > This small patch adds -Wtrampolines to the default set of warnings applied globally in the OpenJDK build. We do not trigger this warning today, but by adding it, combined with -Werror, we make sure we never will. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215400 > > Webrev: http://cr.openjdk.java.net/~erikj/8215400/webrev.01/ > > /Erik Looks good. From andrewluotechnologies at outlook.com Fri Jan 4 19:35:07 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 4 Jan 2019 19:35:07 +0000 Subject: JDK-8216048: Fix devkit creation in WSL In-Reply-To: <6307a7a0-e630-aa25-282e-5a5412e16a4e@oracle.com> References: <06509d1c-d2a3-0f39-3d41-f1f6d122dec4@oracle.com> <6307a7a0-e630-aa25-282e-5a5412e16a4e@oracle.com> Message-ID: Sure, I can look into this. Most likely we will have to prefix unix commands with "wsl". Thanks, -Andrew -----Original Message----- From: Erik Joelsson Sent: Friday, January 4, 2019 2:20 AM To: Andrew Luo ; build-dev at openjdk.java.net Subject: Re: JDK-8216048: Fix devkit creation in WSL Hello Andrew, I've pushed this now. A college eager to try this out discovered that the target "make hotspot-ide-project" does not work in WSL. Is that something you could look into? I tried a quick fix of the obvious (cygpath -> wslpath), but a more tricky problem is that the VS project we generate calls make to build, but in the case of WSL the make executable is not reachable from Windows. Perhaps we can generate some kind of wrapper script in the build dir to work around it? It depends on what kind of executables VS is able to run directly. It's also possible to put the logic in the Java source of the project generator tool. What do you think? /Erik On 2019-01-03 18:32, Andrew Luo wrote: > Hi Erik, > > Thanks for sponsoring this. Looking at the patch, I noticed I left in an extra "echo "$VS_INSTALL_DIR/$f"". This probably could be removed. > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson > Sent: Thursday, January 3, 2019 1:22 AM > To: Andrew Luo ; > build-dev at openjdk.java.net > Subject: RFR: JDK-8216048: Fix devkit creation in WSL > > Hello Andrew, > > Thanks for fixing this. The patch looks good. I have verified that it produces the same output in WSL and Cygwin. Just like in Cygwin, I did not need to be in a Tools Command Prompt to run it (because VS was installed in the default location). > > Regarding the hard coded dir version strings, I'm in the process of updating our kits to the latest VS2017 update, and in that patch, I chose to dynamically resolve those versions instead of putting them in the script. I would expect that to be ready for push sometime this spring. > > The older VS2013 and VS2015 scripts are indeed best left alone. We should probably delete them from the repo at this point. > > I've created https://bugs.openjdk.java.net/browse/JDK-8216048 for this and uploaded the patch as a webrev here: > > http://cr.openjdk.java.net/~erikj/8216048/webrev.01/ > > In addition to your changes, I bumped the copyright year and fixed indentation on one line. > > /Erik > > On 2019-01-03 05:06, Andrew Luo wrote: >> Hi, >> >> I noticed that we have a few scripts checked in for creating devkits on Windows. However they only work in Cygwin. Since we recently added support for WSL, it seems like it would be nice to be able to use those scripts on WSL as well... >> >> Anyways, patch is attached. This one you do have to open a VS2017 Native Tools Command Prompt but I think that's the same as before (in Cygwin). I tested the script in WSL and everything seems to work (I did have to change some of the versions at the top since the version of VS2017 I have installed is much newer, but I reverted those changes before generating this diff), but will need someone to check Cygwin as well. >> >> I didn't update the VS2013 and VS2015 scripts. As far as I'm aware >> we don't (officially) support those compilers anymore: >> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >> >> Thanks, >> >> -Andrew From andrewluotechnologies at outlook.com Fri Jan 4 19:51:16 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 4 Jan 2019 19:51:16 +0000 Subject: C4819 warnings on Windows In-Reply-To: <0DD54F92-665A-43BA-970F-AC7D90D1374B@oracle.com> References: <2d1acfb5-13bc-ee9b-dea6-e4eafc170265@gmail.com> <0DD54F92-665A-43BA-970F-AC7D90D1374B@oracle.com> Message-ID: Hi Max, Take a look at the latest docs for more info on building in WSL: http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html WSL is not actually a VM, it runs "directly" on the hardware. More accurately, it is the Linux syscalls implemented on top of the NT kernel (just as Win32 is also implemented on top of the NT kernel), thus it can run unmodified Linux binaries (it uses the full Linux user mode). (Cygwin on the other hand is implemented on top of Win32 rather than directly on the NT kernel, save for a few things). One nice thing about WSL though is that you can build both a Linux JDK and a Windows JDK (see the instructions). Let us know of any feedback if you do try it out. We just added support in the past few days so there are definitely some rough edges (currently: VS IDE sln files do not work, testing does not work, but we are working on these). Thanks, -Andrew -----Original Message----- From: build-dev On Behalf Of Weijun Wang Sent: Friday, January 4, 2019 2:50 AM To: Erik Joelsson Cc: build-dev at openjdk.java.net; Yasumasa Suenaga Subject: Re: C4819 warnings on Windows Wow, very impressive. I haven't played with WSL and thought it's like a VM running Linux inside Windows. So one either logins to it and build a Linux JDK or stay outside to build a Windows JDK. Never imagined that you can mix the two to do such marvelous things. --Max > On Jan 4, 2019, at 5:48 PM, Erik Joelsson wrote: > > > On 2019-01-04 10:29, Weijun Wang wrote: >> Just curious, why were you mentioning WSL and Ubuntu? Isn't this a pure Windows build issue? Or is it possible to use WSL instead of Cygwin to launch the build process now? That's unbelievable. > > The OpenJDK build can be run in WSL since https://bugs.openjdk.java.net/browse/JDK-8215445. (Note that Jib does not support WSL yet) > > /Erik > >> Thanks, >> Max >> >>> On Jan 4, 2019, at 3:22 PM, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> I tried to build OpenJDK on WSL (Windows 10 1809 + VS2017 (15.9.4) + Ubuntu 18.04 LTS). >>> However, I saw some C4819 warnings as below: >>> >>> ``` >>> c:/OpenJDK/jdk/src/hotspot/share/compiler/methodMatcher.cpp(258): warning C4819: ???????????? ??? (0) ??????????????????????????????????? Unicode ???????????? >>> ``` >>> >>> * The locale of my laptop is set to Japanese (CP932), thanks :-) >>> >>> >>> I saw this warning at 3 files as below: >>> >>> 1. hotspot/share/code/codeHeapState.cpp >>> 2. java.desktop/share/native/libfreetype/src/autofit/afscript.h >>> 3. hotspot/share/compiler/methodMatcher.cpp >>> >>> We can see the problem in 1. and 2. with iconv: >>> $ iconv -f US-ASCII -t UTF8 >>> >>> >>> I've fixed them with following patch. It works fine on my environment: >>> http://cr.openjdk.java.net/~ysuenaga/wsl/build-warnings/ >>> >>> I think we should fix them, but I don't know what component/subcomponent should we set to JBS. >>> Could you help? >>> >>> >>> Thanks, >>> >>> Yasumasa From andrewluotechnologies at outlook.com Sat Jan 5 04:41:07 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sat, 5 Jan 2019 04:41:07 +0000 Subject: [PATCH] Fix hotspot-ide-project target on WSL Message-ID: Subject line is self-explanatory, and patch is attached :) Basically, I changed the makefiles to add support for wslpath to convert paths (when in WSL, of course. Otherwise it's cygpath). For executables we call %windir%\Sysnative\wsl.exe ... (We have to use Sysnative because of WoW64 redirection of System32). Thanks, -Andrew -------------- next part -------------- diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in --- a/make/autoconf/spec.gmk.in +++ b/make/autoconf/spec.gmk.in @@ -729,6 +729,7 @@ RC:=@FIXPATH@ @RC@ DUMPBIN:=@FIXPATH@ @DUMPBIN@ CYGPATH:=@CYGPATH@ +WSLPATH:=@WSLPATH@ LDD:=@LDD@ OTOOL:=@OTOOL@ READELF:=@READELF@ diff --git a/make/hotspot/ide/CreateVSProject.gmk b/make/hotspot/ide/CreateVSProject.gmk --- a/make/hotspot/ide/CreateVSProject.gmk +++ b/make/hotspot/ide/CreateVSProject.gmk @@ -46,8 +46,17 @@ # Helper macro to convert a unix path to a Windows path, suitable for # inclusion in a command line. - FixPath = \ - $(strip $(subst \,\\,$(shell $(CYGPATH) -w $1))) + ifeq ($(OPENJDK_BUILD_OS_ENV), windows.cygwin) + FixPath = \ + $(strip $(subst \,\\,$(shell $(CYGPATH) -w $1))) + FixLinuxExecutable = \ + $(strip $(subst \,\\,$(shell $(CYGPATH) -w $1))) + else ifeq ($(OPENJDK_BUILD_OS_ENV), windows.wsl) + FixPath = \ + $(strip $(subst \,\\,$(shell $(WSLPATH) -w $1))) + FixLinuxExecutable = \ + "%windir%\Sysnative\wsl.exe $1" + endif JVM_DEFINES_client := $(patsubst -D%,%, $(filter -D%, $(JVM_CFLAGS))) EXTRACTED_DEFINES_client := $(addprefix -define , $(JVM_DEFINES_client)) @@ -121,7 +130,7 @@ -platformName x64 \ -buildBase $(call FixPath, $(IDE_OUTPUTDIR)/vs-output) \ -buildSpace $(call FixPath, $(IDE_OUTPUTDIR)) \ - -makeBinary $(call FixPath, $(MAKE)) \ + -makeBinary $(call FixLinuxExecutable, $(MAKE)) \ -makeOutput $(call FixPath, $(JDK_OUTPUTDIR)/bin/server) \ -absoluteInclude $(call FixPath, $(HOTSPOT_OUTPUTDIR)/variant-server/gensrc) \ -absoluteSrcInclude $(call FixPath, $(HOTSPOT_OUTPUTDIR)/variant-server/gensrc) \ From andrewluotechnologies at outlook.com Sun Jan 6 19:22:42 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sun, 6 Jan 2019 19:22:42 +0000 Subject: [PATCH] Fix hotspot-ide-project target on WSL In-Reply-To: References: Message-ID: New patch, minor updates to copyright year and de-duplicating the macro code a bit. Thanks, -Andrew -----Original Message----- From: build-dev On Behalf Of Andrew Luo Sent: Friday, January 4, 2019 8:41 PM To: build-dev at openjdk.java.net Subject: [PATCH] Fix hotspot-ide-project target on WSL Subject line is self-explanatory, and patch is attached :) Basically, I changed the makefiles to add support for wslpath to convert paths (when in WSL, of course. Otherwise it's cygpath). For executables we call %windir%\Sysnative\wsl.exe ... (We have to use Sysnative because of WoW64 redirection of System32). Thanks, -Andrew -------------- next part -------------- diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in --- a/make/autoconf/spec.gmk.in +++ b/make/autoconf/spec.gmk.in @@ -1,5 +1,5 @@ # -# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -729,6 +729,7 @@ RC:=@FIXPATH@ @RC@ DUMPBIN:=@FIXPATH@ @DUMPBIN@ CYGPATH:=@CYGPATH@ +WSLPATH:=@WSLPATH@ LDD:=@LDD@ OTOOL:=@OTOOL@ READELF:=@READELF@ diff --git a/make/hotspot/ide/CreateVSProject.gmk b/make/hotspot/ide/CreateVSProject.gmk --- a/make/hotspot/ide/CreateVSProject.gmk +++ b/make/hotspot/ide/CreateVSProject.gmk @@ -1,5 +1,5 @@ # -# Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -46,8 +46,17 @@ # Helper macro to convert a unix path to a Windows path, suitable for # inclusion in a command line. - FixPath = \ - $(strip $(subst \,\\,$(shell $(CYGPATH) -w $1))) + ifeq ($(OPENJDK_BUILD_OS_ENV), windows.cygwin) + FixPath = \ + $(strip $(subst \,\\,$(shell $(CYGPATH) -w $1))) + FixLinuxExecutable = \ + $(call FixPath, $1) + else ifeq ($(OPENJDK_BUILD_OS_ENV), windows.wsl) + FixPath = \ + $(strip $(subst \,\\,$(shell $(WSLPATH) -w $1))) + FixLinuxExecutable = \ + "%windir%\Sysnative\wsl.exe $1" + endif JVM_DEFINES_client := $(patsubst -D%,%, $(filter -D%, $(JVM_CFLAGS))) EXTRACTED_DEFINES_client := $(addprefix -define , $(JVM_DEFINES_client)) @@ -121,7 +130,7 @@ -platformName x64 \ -buildBase $(call FixPath, $(IDE_OUTPUTDIR)/vs-output) \ -buildSpace $(call FixPath, $(IDE_OUTPUTDIR)) \ - -makeBinary $(call FixPath, $(MAKE)) \ + -makeBinary $(call FixLinuxExecutable, $(MAKE)) \ -makeOutput $(call FixPath, $(JDK_OUTPUTDIR)/bin/server) \ -absoluteInclude $(call FixPath, $(HOTSPOT_OUTPUTDIR)/variant-server/gensrc) \ -absoluteSrcInclude $(call FixPath, $(HOTSPOT_OUTPUTDIR)/variant-server/gensrc) \ From andrewluotechnologies at outlook.com Sun Jan 6 19:34:14 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sun, 6 Jan 2019 19:34:14 +0000 Subject: [PATCH] Fixes for running tests on WSL Message-ID: Hi Everyone, I've gotten shell tests to run on WSL with some changes to jtreg and a small change to the OpenJDK gmake files. Most of them are still not passing (I believe one or two of them did just work out of the box after these changes as failures + error count dropped; previous errors + previous failures < current failures; also "errors" dropped to zero), as the scripts themselves will need to be changed, however, at least now they can actually run... My patch with proposed changes are attached. I've sent the corresponding jtreg changes to the code-tools-dev mailing list: https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/000464.html Let me know if you have any feedback/comments. Thanks, -Andrew -------------- next part -------------- diff --git a/make/RunTests.gmk b/make/RunTests.gmk --- a/make/RunTests.gmk +++ b/make/RunTests.gmk @@ -1,5 +1,5 @@ # -# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -814,6 +814,10 @@ $1_JTREG_BASIC_OPTIONS += -e:_NT_SYMBOL_PATH endif + ifeq ($$(OPENJDK_BUILD_OS_ENV), windows.wsl) + $1_JTREG_BASIC_OPTIONS += -wslWindowsTarget + endif + $1_JTREG_BASIC_OPTIONS += \ $$(addprefix -javaoption:, $$(JTREG_JAVA_OPTIONS)) \ $$(addprefix -vmoption:, $$(JTREG_VM_OPTIONS)) \ From erik.joelsson at oracle.com Mon Jan 7 09:13:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Jan 2019 10:13:09 +0100 Subject: [PATCH] Fix hotspot-ide-project target on WSL In-Reply-To: References: Message-ID: Thanks Andrew for looking into this! Markus, could you try the patch? /Erik On 2019-01-06 20:22, Andrew Luo wrote: > New patch, minor updates to copyright year and de-duplicating the macro code a bit. > > Thanks, > > -Andrew > > -----Original Message----- > From: build-dev On Behalf Of Andrew Luo > Sent: Friday, January 4, 2019 8:41 PM > To: build-dev at openjdk.java.net > Subject: [PATCH] Fix hotspot-ide-project target on WSL > > Subject line is self-explanatory, and patch is attached :) > > Basically, I changed the makefiles to add support for wslpath to convert paths (when in WSL, of course. Otherwise it's cygpath). For executables we call %windir%\Sysnative\wsl.exe ... (We have to use Sysnative because of WoW64 redirection of System32). > > Thanks, > > -Andrew From erik.joelsson at oracle.com Mon Jan 7 09:10:38 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Jan 2019 10:10:38 +0100 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: References: Message-ID: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> Hello Andrew, If the patch gets accepted to Jtreg, this looks good. We will need to wait for Jtreg support before pushing this though. /Erik On 2019-01-06 20:34, Andrew Luo wrote: > Hi Everyone, > > I've gotten shell tests to run on WSL with some changes to jtreg and a small change to the OpenJDK gmake files. Most of them are still not passing (I believe one or two of them did just work out of the box after these changes as failures + error count dropped; previous errors + previous failures < current failures; also "errors" dropped to zero), as the scripts themselves will need to be changed, however, at least now they can actually run... My patch with proposed changes are attached. > > I've sent the corresponding jtreg changes to the code-tools-dev mailing list: https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/000464.html > > Let me know if you have any feedback/comments. > > Thanks, > > -Andrew > > From markus.gronlund at oracle.com Mon Jan 7 09:38:37 2019 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 7 Jan 2019 01:38:37 -0800 (PST) Subject: [PATCH] Fix hotspot-ide-project target on WSL In-Reply-To: References: Message-ID: <0646bc6c-3762-4137-a897-3425fa7dd1ec@default> Hi Andrew and Erik, I have just tried the patch and with it I can successfully build the make hotspot-ide-project target in WSL. I also verified the backwards compatibility that you are still able to perform this build using Cygwin. Thank you very much Andrew and Erik for your work related to WSL, much appreciated indeed. Cheers Markus -----Original Message----- From: Erik Joelsson Sent: den 7 januari 2019 10:13 To: Andrew Luo ; build-dev at openjdk.java.net; Markus Gronlund Subject: Re: [PATCH] Fix hotspot-ide-project target on WSL Thanks Andrew for looking into this! Markus, could you try the patch? /Erik On 2019-01-06 20:22, Andrew Luo wrote: > New patch, minor updates to copyright year and de-duplicating the macro code a bit. > > Thanks, > > -Andrew > > -----Original Message----- > From: build-dev On Behalf Of Andrew Luo > Sent: Friday, January 4, 2019 8:41 PM > To: build-dev at openjdk.java.net > Subject: [PATCH] Fix hotspot-ide-project target on WSL > > Subject line is self-explanatory, and patch is attached :) > > Basically, I changed the makefiles to add support for wslpath to convert paths (when in WSL, of course. Otherwise it's cygpath). For executables we call %windir%\Sysnative\wsl.exe ... (We have to use Sysnative because of WoW64 redirection of System32). > > Thanks, > > -Andrew From erik.joelsson at oracle.com Mon Jan 7 13:04:33 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Jan 2019 14:04:33 +0100 Subject: [PATCH] Fix hotspot-ide-project target on WSL In-Reply-To: <0646bc6c-3762-4137-a897-3425fa7dd1ec@default> References: <0646bc6c-3762-4137-a897-3425fa7dd1ec@default> Message-ID: Thanks! Pushed: https://bugs.openjdk.java.net/browse/JDK-8216267 /Erik On 2019-01-07 10:38, Markus Gronlund wrote: > Hi Andrew and Erik, > > I have just tried the patch and with it I can successfully build the make hotspot-ide-project target in WSL. > I also verified the backwards compatibility that you are still able to perform this build using Cygwin. > > Thank you very much Andrew and Erik for your work related to WSL, much appreciated indeed. > > Cheers > Markus > > -----Original Message----- > From: Erik Joelsson > Sent: den 7 januari 2019 10:13 > To: Andrew Luo ; build-dev at openjdk.java.net; Markus Gronlund > Subject: Re: [PATCH] Fix hotspot-ide-project target on WSL > > Thanks Andrew for looking into this! > > Markus, could you try the patch? > > /Erik > > On 2019-01-06 20:22, Andrew Luo wrote: >> New patch, minor updates to copyright year and de-duplicating the macro code a bit. >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: build-dev On Behalf Of Andrew Luo >> Sent: Friday, January 4, 2019 8:41 PM >> To: build-dev at openjdk.java.net >> Subject: [PATCH] Fix hotspot-ide-project target on WSL >> >> Subject line is self-explanatory, and patch is attached :) >> >> Basically, I changed the makefiles to add support for wslpath to convert paths (when in WSL, of course. Otherwise it's cygpath). For executables we call %windir%\Sysnative\wsl.exe ... (We have to use Sysnative because of WoW64 redirection of System32). >> >> Thanks, >> >> -Andrew From claes.redestad at oracle.com Mon Jan 7 15:02:24 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 7 Jan 2019 16:02:24 +0100 Subject: RFR: 8216275: Disable annotation processing lint warnings when building microbenchmarks Message-ID: <697ffa9b-0a0c-0bca-9021-822c54155e39@oracle.com> Hi, current use of -Xlint makes the build-microbenchmark fail if one attempts to add a microbenchmark that uses non-JMH annotations. Patch selectively disable the processing lint option without disabling other linters. Bug: https://bugs.openjdk.java.net/browse/JDK-8216275 Patch: diff -r b587ca419e2c make/test/BuildMicrobenchmark.gmk --- a/make/test/BuildMicrobenchmark.gmk Mon Jan 07 13:10:20 2019 +0100 +++ b/make/test/BuildMicrobenchmark.gmk Mon Jan 07 15:46:36 2019 +0100 @@ -78,7 +78,7 @@ # Build microbenchmark suite for the current JDK $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \ SETUP := MICROBENCHMARK_JAVA_COMPILER, \ - ADD_JAVAC_FLAGS := -cp $(MICROBENCHMARK_CLASSPATH) -Xlint -Werror, \ + ADD_JAVAC_FLAGS := -cp $(MICROBENCHMARK_CLASSPATH) -Xlint -Xlint:-processing -Werror, \ SRC := $(MICROBENCHMARK_SRC), \ BIN := $(MICROBENCHMARK_CLASSES), \ )) /Claes From erik.joelsson at oracle.com Mon Jan 7 15:52:14 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Jan 2019 16:52:14 +0100 Subject: RFR: 8216275: Disable annotation processing lint warnings when building microbenchmarks In-Reply-To: <697ffa9b-0a0c-0bca-9021-822c54155e39@oracle.com> References: <697ffa9b-0a0c-0bca-9021-822c54155e39@oracle.com> Message-ID: <977b3655-fb67-ef09-d712-5775797460fe@oracle.com> Looks good. /Erik On 2019-01-07 16:02, Claes Redestad wrote: > Hi, > > current use of -Xlint makes the build-microbenchmark fail if one > attempts to add a microbenchmark that uses non-JMH annotations. > > Patch selectively disable the processing lint option without disabling > other linters. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216275 > Patch: > > diff -r b587ca419e2c make/test/BuildMicrobenchmark.gmk > --- a/make/test/BuildMicrobenchmark.gmk??? Mon Jan 07 13:10:20 2019 +0100 > +++ b/make/test/BuildMicrobenchmark.gmk??? Mon Jan 07 15:46:36 2019 +0100 > @@ -78,7 +78,7 @@ > ?# Build microbenchmark suite for the current JDK > ?$(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \ > ???? SETUP := MICROBENCHMARK_JAVA_COMPILER, \ > -??? ADD_JAVAC_FLAGS := -cp $(MICROBENCHMARK_CLASSPATH) -Xlint -Werror, \ > +??? ADD_JAVAC_FLAGS := -cp $(MICROBENCHMARK_CLASSPATH) -Xlint > -Xlint:-processing -Werror, \ > ???? SRC := $(MICROBENCHMARK_SRC), \ > ???? BIN := $(MICROBENCHMARK_CLASSES), \ > ?)) > > > /Claes From claes.redestad at oracle.com Mon Jan 7 16:09:21 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 7 Jan 2019 17:09:21 +0100 Subject: RFR: 8216275: Disable annotation processing lint warnings when building microbenchmarks In-Reply-To: <977b3655-fb67-ef09-d712-5775797460fe@oracle.com> References: <697ffa9b-0a0c-0bca-9021-822c54155e39@oracle.com> <977b3655-fb67-ef09-d712-5775797460fe@oracle.com> Message-ID: <6425ff50-0157-9f52-76ee-1ae22d92bfa8@oracle.com> Thanks! /Claes On 2019-01-07 16:52, Erik Joelsson wrote: > Looks good. > > /Erik > > On 2019-01-07 16:02, Claes Redestad wrote: >> Hi, >> >> current use of -Xlint makes the build-microbenchmark fail if one >> attempts to add a microbenchmark that uses non-JMH annotations. >> >> Patch selectively disable the processing lint option without disabling >> other linters. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216275 >> Patch: >> >> diff -r b587ca419e2c make/test/BuildMicrobenchmark.gmk >> --- a/make/test/BuildMicrobenchmark.gmk??? Mon Jan 07 13:10:20 2019 +0100 >> +++ b/make/test/BuildMicrobenchmark.gmk??? Mon Jan 07 15:46:36 2019 +0100 >> @@ -78,7 +78,7 @@ >> ?# Build microbenchmark suite for the current JDK >> ?$(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \ >> ???? SETUP := MICROBENCHMARK_JAVA_COMPILER, \ >> -??? ADD_JAVAC_FLAGS := -cp $(MICROBENCHMARK_CLASSPATH) -Xlint -Werror, \ >> +??? ADD_JAVAC_FLAGS := -cp $(MICROBENCHMARK_CLASSPATH) -Xlint >> -Xlint:-processing -Werror, \ >> ???? SRC := $(MICROBENCHMARK_SRC), \ >> ???? BIN := $(MICROBENCHMARK_CLASSES), \ >> ?)) >> >> >> /Claes From jonathan.gibbons at oracle.com Mon Jan 7 22:33:46 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 7 Jan 2019 14:33:46 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: References: Message-ID: Andrew, Setting aside whatever changes might be needed for jtreg itself, what will need to be done to any shell tests? For example, the following pattern is common in many of the shell tests, with the general expectation that on Windows, CYGWIN will be selected. # set platform-dependent variables OS=`uname -s` case "$OS" in ? AIX | Darwin | Linux | SunOS ) ??? NULL=/dev/null ??? PS=":" ??? FS="/" ??? ;; ? CYGWIN* ) ??? NULL=/dev/null ??? PS=";" ??? FS="/" ??? ;; ? Windows* ) ??? NULL=NUL ??? PS=";" ??? FS="\\" ??? ;; ? * ) ??? echo "Unrecognized system!" ??? exit 1; ??? ;; esac KEYTOOL=${TESTJAVA}${FS}bin${FS}keytool If nothing else, what does `uname -s` return when using WSL? I think we should understand the impact on the tests before pushing any changes in this area. -- Jon On 01/06/2019 11:34 AM, Andrew Luo wrote: > Hi Everyone, > > I've gotten shell tests to run on WSL with some changes to jtreg and a small change to the OpenJDK gmake files. Most of them are still not passing (I believe one or two of them did just work out of the box after these changes as failures + error count dropped; previous errors + previous failures < current failures; also "errors" dropped to zero), as the scripts themselves will need to be changed, however, at least now they can actually run... My patch with proposed changes are attached. > > I've sent the corresponding jtreg changes to the code-tools-dev mailing list: https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/000464.html > > Let me know if you have any feedback/comments. > > Thanks, > > -Andrew > > From andrewluotechnologies at outlook.com Mon Jan 7 23:27:40 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Mon, 7 Jan 2019 23:27:40 +0000 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: References: Message-ID: Hi Jon, I had thought about this a little more earlier and I was intending to handle these changes separately. "uname -s" returns Linux on WSL. You can distinguish using "uname -r" containing "Microsoft" (this is what we do elsewhere). However, the script itself cannot determine this independently because you can target either Linux or Windows from WSL (if you target Linux from WSL, then everything already works, using the Linux code path). Most likely, gmake will need to pass in to the script (most likely via another environment variable, such as -e:WSL_WINDOWS_TARGET=1) and then the script will have to have an additional check in the "uname -s" == Linux case). Thanks, -Andrew From: Jonathan Gibbons Sent: Monday, January 7, 2019 2:34 PM To: Andrew Luo ; build-dev at openjdk.java.net Subject: Re: [PATCH] Fixes for running tests on WSL Andrew, Setting aside whatever changes might be needed for jtreg itself, what will need to be done to any shell tests? For example, the following pattern is common in many of the shell tests, with the general expectation that on Windows, CYGWIN will be selected. # set platform-dependent variables OS=`uname -s` case "$OS" in AIX | Darwin | Linux | SunOS ) NULL=/dev/null PS=":" FS="/" ;; CYGWIN* ) NULL=/dev/null PS=";" FS="/" ;; Windows* ) NULL=NUL PS=";" FS="\\" ;; * ) echo "Unrecognized system!" exit 1; ;; esac KEYTOOL=${TESTJAVA}${FS}bin${FS}keytool If nothing else, what does `uname -s` return when using WSL? I think we should understand the impact on the tests before pushing any changes in this area. -- Jon On 01/06/2019 11:34 AM, Andrew Luo wrote: Hi Everyone, I've gotten shell tests to run on WSL with some changes to jtreg and a small change to the OpenJDK gmake files. Most of them are still not passing (I believe one or two of them did just work out of the box after these changes as failures + error count dropped; previous errors + previous failures < current failures; also "errors" dropped to zero), as the scripts themselves will need to be changed, however, at least now they can actually run... My patch with proposed changes are attached. I've sent the corresponding jtreg changes to the code-tools-dev mailing list: https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/000464.html Let me know if you have any feedback/comments. Thanks, -Andrew From jonathan.gibbons at oracle.com Mon Jan 7 23:36:04 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 7 Jan 2019 15:36:04 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: References: Message-ID: <7e8ddf64-f833-d3d7-582b-43898e3efc98@oracle.com> As long as we understand/document the impact on tests, it's OK if any related changes are done separately, in a timely manner. But if the existing "Linux" case works, that's good to know. -- Jon On 01/07/2019 03:27 PM, Andrew Luo wrote: > > Hi Jon, > > I had thought about this a little more earlier and I was intending to > handle these changes separately. ??uname -s? returns Linux on WSL.? > You can distinguish using ?uname -r" containing ?Microsoft? (this is > what we do elsewhere). However, the script itself cannot determine > this independently because you can target either Linux or Windows from > WSL (if you target Linux from WSL, then everything already works, > using the Linux code path).? Most likely, gmake will need to pass in > to the script (most likely via another environment variable, such as > -e:WSL_WINDOWS_TARGET=1) and then the script will have to have an > additional check in the ?uname -s" == Linux case). > > Thanks, > > -Andrew > > *From:*Jonathan Gibbons > *Sent:* Monday, January 7, 2019 2:34 PM > *To:* Andrew Luo ; > build-dev at openjdk.java.net > *Subject:* Re: [PATCH] Fixes for running tests on WSL > > Andrew, > > Setting aside whatever changes might be needed for jtreg itself, what > will need to be done to any shell tests? > > For example, the following pattern is common in many of the shell > tests, with the general expectation that on Windows, CYGWIN will be > selected. > > # set platform-dependent variables > OS=`uname -s` > case "$OS" in > ? AIX | Darwin | Linux | SunOS ) > ??? NULL=/dev/null > ??? PS=":" > ??? FS="/" > ??? ;; > ? CYGWIN* ) > ??? NULL=/dev/null > ??? PS=";" > ??? FS="/" > ??? ;; > ? Windows* ) > ??? NULL=NUL > ??? PS=";" > ??? FS="\\" > ??? ;; > ? * ) > ??? echo "Unrecognized system!" > ??? exit 1; > ??? ;; > esac > KEYTOOL=${TESTJAVA}${FS}bin${FS}keytool > > > If nothing else, what does `uname -s` return when using WSL? > > I think we should understand the impact on the tests before pushing > any changes in this area. > > -- Jon > > On 01/06/2019 11:34 AM, Andrew Luo wrote: > > Hi Everyone, > > I've gotten shell tests to run on WSL with some changes to jtreg and a small change to the OpenJDK gmake files.? Most of them are still not passing (I believe one or two of them did just work out of the box after these changes as failures + error count dropped; previous errors + previous failures < current failures; also "errors" dropped to zero), as the scripts themselves will need to be changed, however, at least now they can actually run...? My patch with proposed changes are attached. > > I've sent the corresponding jtreg changes to the code-tools-dev mailing list:https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/000464.html > > Let me know if you have any feedback/comments. > > Thanks, > > -Andrew > From alexandre.iline at oracle.com Tue Jan 8 18:35:38 2019 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 8 Jan 2019 10:35:38 -0800 Subject: RFR 8215729: Enhance makefiles to allow collecting code coverage with JCov Message-ID: <07165F0F-789D-45F3-8422-E2B0CFA80343@oracle.com> Hi, Could you please take a look on a change which allows to run tests while collecting code coverage with JCov. This is a continuation of work done in JDK-8214309: Enhance makefiles to allow generating JCov instrumented build. This adds make targets jcov-test and others like jcov-test-tier1 etc. After running the tests, one is left with a coverage report and also a data file containing coverage, for further analysis. Part of the changes are related to increasing maximum and initial heap size, which is needed to be done because instrumented classes are bigger in size. The way it is done for JTReg tests is by setting both _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variables. As it stands now, not all tests pass while running with code coverage, which pass normally. This particular enhancement is not addressing failing tests. The tests will need to be fixed separately if ever. For example, there are 35 tests which fail in open/test/jdk:jdk_core. A quick look tells that the majority of the failures are in tests which verify error output and discover an unexpected line "Picked up _JAVA_OPTIONS: -Xmx4g?. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8215729 Webrev: http://cr.openjdk.java.net/~shurailine/8215729/webrev.01/ Shura From jonathan.gibbons at oracle.com Tue Jan 8 22:11:46 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 8 Jan 2019 14:11:46 -0800 Subject: RFR: XXS: JDK-8215308: pandoc-html-manpage-filter.js does not work for [un]pack200 Message-ID: <7acdb29d-acc0-8bb5-c2b9-e442c45547b7@oracle.com> Please review a small edit to a regular expression used to detect the name of a tool in a man page. Here's the inline version of the patch: $ hg diff -R open diff -r 28ec06beb091 make/scripts/pandoc-html-manpage-filter.js --- a/make/scripts/pandoc-html-manpage-filter.js Tue Jan 08 13:04:04 2019 -0800 +++ b/make/scripts/pandoc-html-manpage-filter.js Tue Jan 08 14:03:09 2019 -0800 @@ -86,7 +86,7 @@ ?function change_title(type, value) { ?????if (type === 'MetaInlines') { ?????????if (value[0].t === 'Str') { - var match = value[0].c.match(/^([A-Z]+)\([0-9]+\)$/); + var match = value[0].c.match(/^([A-Z0-9]+)\([0-9]+\)$/); ?????????????if (match) { ?????????????????return MetaInlines([ ?????????????????????????Str("The"), Space(), -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8215308 Webrev: http://cr.openjdk.java.net/~jjg/8215308/webrev.00/ From david.holmes at oracle.com Wed Jan 9 02:15:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Jan 2019 12:15:01 +1000 Subject: RFR 8215729: Enhance makefiles to allow collecting code coverage with JCov In-Reply-To: <07165F0F-789D-45F3-8422-E2B0CFA80343@oracle.com> References: <07165F0F-789D-45F3-8422-E2B0CFA80343@oracle.com> Message-ID: <057f2307-b659-cf3e-16e7-1a7872de303c@oracle.com> Hi Shura, Sorry not a review just a comment on one thing ... On 9/01/2019 4:35 am, Alexandre (Shura) Iline wrote: > Hi, > > Could you please take a look on a change which allows to run tests while collecting code coverage with JCov. This is a continuation of work done in > JDK-8214309: Enhance makefiles to allow generating JCov instrumented build. > > This adds make targets jcov-test and others like jcov-test-tier1 etc. After running the tests, one is left with a coverage report and also a data file containing coverage, for further analysis. > > Part of the changes are related to increasing maximum and initial heap size, which is needed to be done because instrumented classes are bigger in size. The way it is done for JTReg tests is by setting both _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variables. > > As it stands now, not all tests pass while running with code coverage, which pass normally. This particular enhancement is not addressing failing tests. The tests will need to be fixed separately if ever. For example, there are 35 tests which fail in open/test/jdk:jdk_core. A quick look tells that the majority of the failures are in tests which verify error output and discover an unexpected line "Picked up _JAVA_OPTIONS: -Xmx4g?. We've been bitten in the past with VM warnings causing tests to fail due to the unexpected output and made a conscious effort to fix all such tests. Unfortunately a few still remain. Do your 35 failures match up with the tests in the blocking issues for this bug: https://bugs.openjdk.java.net/browse/JDK-8196741 ? 35 seems a lot. I hope we haven't regressed in this area. Thanks, David > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8215729 > Webrev: http://cr.openjdk.java.net/~shurailine/8215729/webrev.01/ > > Shura > From erik.joelsson at oracle.com Wed Jan 9 16:16:45 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 9 Jan 2019 08:16:45 -0800 Subject: RFR: XXS: JDK-8215308: pandoc-html-manpage-filter.js does not work for [un]pack200 In-Reply-To: <7acdb29d-acc0-8bb5-c2b9-e442c45547b7@oracle.com> References: <7acdb29d-acc0-8bb5-c2b9-e442c45547b7@oracle.com> Message-ID: <090f9bd2-a984-8ebc-6aa3-cf2ef42f9c87@oracle.com> Looks good. /Erik On 2019-01-08 23:11, Jonathan Gibbons wrote: > Please review a small edit to a regular expression used to detect the > name of a tool in a man page. > > Here's the inline version of the patch: > > $ hg diff -R open > diff -r 28ec06beb091 make/scripts/pandoc-html-manpage-filter.js > --- a/make/scripts/pandoc-html-manpage-filter.js Tue Jan 08 13:04:04 > 2019 -0800 > +++ b/make/scripts/pandoc-html-manpage-filter.js Tue Jan 08 14:03:09 > 2019 -0800 > @@ -86,7 +86,7 @@ > ?function change_title(type, value) { > ?????if (type === 'MetaInlines') { > ?????????if (value[0].t === 'Str') { > - var match = value[0].c.match(/^([A-Z]+)\([0-9]+\)$/); > + var match = value[0].c.match(/^([A-Z0-9]+)\([0-9]+\)$/); > ?????????????if (match) { > ?????????????????return MetaInlines([ > ?????????????????????????Str("The"), Space(), > > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8215308 > Webrev: http://cr.openjdk.java.net/~jjg/8215308/webrev.00/ > From erik.joelsson at oracle.com Wed Jan 9 17:44:25 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 9 Jan 2019 09:44:25 -0800 Subject: RFR 8215729: Enhance makefiles to allow collecting code coverage with JCov In-Reply-To: <07165F0F-789D-45F3-8422-E2B0CFA80343@oracle.com> References: <07165F0F-789D-45F3-8422-E2B0CFA80343@oracle.com> Message-ID: <2b806472-6fa8-e6c2-4a88-b194f0fd5f4a@oracle.com> Looks good to me. /Erik On 2019-01-08 10:35, Alexandre (Shura) Iline wrote: > Hi, > > Could you please take a look on a change which allows to run tests while collecting code coverage with JCov. This is a continuation of work done in > JDK-8214309: Enhance makefiles to allow generating JCov instrumented build. > > This adds make targets jcov-test and others like jcov-test-tier1 etc. After running the tests, one is left with a coverage report and also a data file containing coverage, for further analysis. > > Part of the changes are related to increasing maximum and initial heap size, which is needed to be done because instrumented classes are bigger in size. The way it is done for JTReg tests is by setting both _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variables. > > As it stands now, not all tests pass while running with code coverage, which pass normally. This particular enhancement is not addressing failing tests. The tests will need to be fixed separately if ever. For example, there are 35 tests which fail in open/test/jdk:jdk_core. A quick look tells that the majority of the failures are in tests which verify error output and discover an unexpected line "Picked up _JAVA_OPTIONS: -Xmx4g?. > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8215729 > Webrev: http://cr.openjdk.java.net/~shurailine/8215729/webrev.01/ > > Shura From erik.joelsson at oracle.com Wed Jan 9 18:14:33 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 9 Jan 2019 10:14:33 -0800 Subject: RFR: JDK-8216278: Fix devkit and basic Jib support on WSL Message-ID: <84fa67ab-f1ee-1b07-fd93-5fda42f5d6a6@oracle.com> The WSL support in the build does not currently work with devkits. This prevents us from using Jib to configure a WSL build. This patch fixes configure to work with devkits when building for Windows in WSL. (For Oracle users, I also managed to get Jib working in WSL, and able to configure both Windows and Linux profiles. Note that since Jib is not WSL aware itself, you need to manually direct the data dir to a location visible from Windows. e.g --with-data-dir /mnt/c/cygwin64/var/tmp/jib-$USER). Bug: https://bugs.openjdk.java.net/browse/JDK-8216278 Webrev: http://cr.openjdk.java.net/~erikj/8216278/webrev.01/index.html /Erik From tim.bell at oracle.com Wed Jan 9 18:54:11 2019 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 09 Jan 2019 10:54:11 -0800 Subject: RFR: JDK-8216278: Fix devkit and basic Jib support on WSL In-Reply-To: <84fa67ab-f1ee-1b07-fd93-5fda42f5d6a6@oracle.com> References: <84fa67ab-f1ee-1b07-fd93-5fda42f5d6a6@oracle.com> Message-ID: <5C364353.8080706@oracle.com> Erik: Looks good to me. /Tim On 01/09/19 10:14, Erik Joelsson wrote: > The WSL support in the build does not currently work with devkits. This > prevents us from using Jib to configure a WSL build. This patch fixes > configure to work with devkits when building for Windows in WSL. > > (For Oracle users, I also managed to get Jib working in WSL, and able to > configure both Windows and Linux profiles. Note that since Jib is not > WSL aware itself, you need to manually direct the data dir to a location > visible from Windows. e.g --with-data-dir > /mnt/c/cygwin64/var/tmp/jib-$USER). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216278 > > Webrev: http://cr.openjdk.java.net/~erikj/8216278/webrev.01/index.html > > /Erik > From andrewluotechnologies at outlook.com Wed Jan 9 19:29:18 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Wed, 9 Jan 2019 19:29:18 +0000 Subject: RFR: JDK-8216278: Fix devkit and basic Jib support on WSL In-Reply-To: <5C364353.8080706@oracle.com> References: <84fa67ab-f1ee-1b07-fd93-5fda42f5d6a6@oracle.com> <5C364353.8080706@oracle.com> Message-ID: Hi Erik, Looks good to me also (not a reviewer though, thought I'd chime in since I've worked a bit with WSL) One question: This line: MAKE_EXPECTED_ENV='x86_64-.*-linux-gnu' - what other strings did you see other than -pc- - just asking out of curiosity. Thanks, -Andrew -----Original Message----- From: build-dev On Behalf Of Tim Bell Sent: Wednesday, January 9, 2019 10:54 AM To: Erik Joelsson Cc: build-dev Subject: Re: RFR: JDK-8216278: Fix devkit and basic Jib support on WSL Erik: Looks good to me. /Tim On 01/09/19 10:14, Erik Joelsson wrote: > The WSL support in the build does not currently work with devkits. > This prevents us from using Jib to configure a WSL build. This patch > fixes configure to work with devkits when building for Windows in WSL. > > (For Oracle users, I also managed to get Jib working in WSL, and able > to configure both Windows and Linux profiles. Note that since Jib is > not WSL aware itself, you need to manually direct the data dir to a > location visible from Windows. e.g --with-data-dir > /mnt/c/cygwin64/var/tmp/jib-$USER). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216278 > > Webrev: http://cr.openjdk.java.net/~erikj/8216278/webrev.01/index.html > > /Erik > From erik.joelsson at oracle.com Wed Jan 9 19:39:52 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 9 Jan 2019 11:39:52 -0800 Subject: RFR: JDK-8216278: Fix devkit and basic Jib support on WSL In-Reply-To: References: <84fa67ab-f1ee-1b07-fd93-5fda42f5d6a6@oracle.com> <5C364353.8080706@oracle.com> Message-ID: Hello, On 2019-01-09 11:29, Andrew Luo wrote: > Hi Erik, > > Looks good to me also (not a reviewer though, thought I'd chime in since I've worked a bit with WSL) Thanks, I appreciate your input! > One question: > > This line: MAKE_EXPECTED_ENV='x86_64-.*-linux-gnu' - what other strings did you see other than -pc- - just asking out of curiosity. We run our builds internally with make binaries built from source. In WSL, this ends up being the same binaries we use on Linux, which have -unknown- in the tuple. /Erik > Thanks, > > -Andrew > > -----Original Message----- > From: build-dev On Behalf Of Tim Bell > Sent: Wednesday, January 9, 2019 10:54 AM > To: Erik Joelsson > Cc: build-dev > Subject: Re: RFR: JDK-8216278: Fix devkit and basic Jib support on WSL > > Erik: > > Looks good to me. > > /Tim > > On 01/09/19 10:14, Erik Joelsson wrote: >> The WSL support in the build does not currently work with devkits. >> This prevents us from using Jib to configure a WSL build. This patch >> fixes configure to work with devkits when building for Windows in WSL. >> >> (For Oracle users, I also managed to get Jib working in WSL, and able >> to configure both Windows and Linux profiles. Note that since Jib is >> not WSL aware itself, you need to manually direct the data dir to a >> location visible from Windows. e.g --with-data-dir >> /mnt/c/cygwin64/var/tmp/jib-$USER). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216278 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8216278/webrev.01/index.html >> >> /Erik >> From alexandre.iline at oracle.com Wed Jan 9 19:46:31 2019 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 9 Jan 2019 11:46:31 -0800 Subject: RFR 8215729: Enhance makefiles to allow collecting code coverage with JCov In-Reply-To: <057f2307-b659-cf3e-16e7-1a7872de303c@oracle.com> References: <07165F0F-789D-45F3-8422-E2B0CFA80343@oracle.com> <057f2307-b659-cf3e-16e7-1a7872de303c@oracle.com> Message-ID: <8A4FEC01-F8AF-4B10-B32D-28B6B2E24D26@oracle.com> David, At least these tests appear to be failing because of extra lines in the error output (showing test names with a line or two from jtr file): java/io/File/DeleteOnExitNPE.java java.lang.RuntimeException: Failed: No output should have been received from the process java/lang/ProcessBuilder/SkipTest.java java.lang.AssertionError: header char wrong, expected: 65, actual: 80 java/lang/Runtime/exec/ArgWithSpaceAndFinalBackslash.java java.lang.Exception: Test failed: Got "Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g foo bar\\baz\\", expected "foo bar\\baz\\" java/lang/Runtime/exec/ExitValue.java java.lang.Exception: Unexpected stderr: Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g java/lang/Thread/UncaughtExceptions.sh FAIL: Expected "Exception in thread "Thread-0".*Seppuku", got Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g java/net/InetAddress/ptr/Lookup.java IPv4 lookup results: [192.0.43.7:icann.orgPicked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g ] java/net/URLConnection/ContentHandlers/ContentHandlersTest.java java.lang.RuntimeException: Expected a different kind of failure: Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g java/net/spi/URLStreamHandlerProvider/Basic.java java.lang.RuntimeException: Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java stderr: [Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g Bad response or premature EOF, bytes read: java.lang.RuntimeException: Bad response or premature EOF from service java/security/AccessController/DoPrivAccompliceTest.java java.lang.RuntimeException: stderr was not empty java/util/logging/LoggingDeadlock2.java Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g not equal to java/util/zip/EntryCount64k.java java.lang.RuntimeException: '\A\Z' missing from stderr javax/naming/spi/providers/InitialContextTest.java java.lang.RuntimeException: Expected a different kind of failure: Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g sun/rmi/runtime/Log/6409194/NoConsoleOutput.java java.lang.Error: TEST FAILED: unexpected subprocess output sun/tools/jrunscript/jrunscript-eTest.sh sun/tools/jrunscript/jrunscript-fTest.sh sun/tools/jrunscript/jrunscriptTest.sh Output of jrunscript -e differ from expected output. Failed. tools/jar/LeadingGarbage.java test LeadingGarbage.test_canListWithLeadingGarbage(): failure java.lang.RuntimeException: '\\A\\Z' missing from stderr tools/jar/modularJar/Basic.java java.lang.AssertionError: Unknown value Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g tools/jar/multiRelease/Basic.java java.lang.RuntimeException: stderr was not empty tools/jjs/jjs-fileTest.sh Output of jjs file.js differ from expected output. Failed. Other failures are: java/io/CharArrayReader/OverflowInRead.java java/lang/ProcessBuilder/InheritIO/InheritIO.sh java/lang/StackTraceElement/ModuleFrames.java java/lang/StackTraceElement/SerialTest.java java/lang/StackWalker/VerifyStackTrace.java java/lang/invoke/lambda/LogGeneratedClassesTest.java java/net/MulticastSocket/PromiscuousIPv6.java java/net/URL/JarHandlerPkgPrefix/JarHandlerPkgPrefix.java java/nio/Buffer/LimitDirectMemory.java java/nio/channels/DatagramChannel/PromiscuousIPv6.java java/util/concurrent/locks/Lock/TimedAcquireLeak.java jdk/internal/misc/VM/RuntimeArguments.java jdk/modules/etc/JdkQualifiedExportTest.java tools/jar/multiRelease/ApiValidatorTest.java Again, a thorough analysis will need to be done - here I just quickly scanned the jtr files. Shura > On Jan 8, 2019, at 6:15 PM, David Holmes wrote: > > Hi Shura, > > Sorry not a review just a comment on one thing ... > > On 9/01/2019 4:35 am, Alexandre (Shura) Iline wrote: >> Hi, >> Could you please take a look on a change which allows to run tests while collecting code coverage with JCov. This is a continuation of work done in >> JDK-8214309: Enhance makefiles to allow generating JCov instrumented build. >> This adds make targets jcov-test and others like jcov-test-tier1 etc. After running the tests, one is left with a coverage report and also a data file containing coverage, for further analysis. >> Part of the changes are related to increasing maximum and initial heap size, which is needed to be done because instrumented classes are bigger in size. The way it is done for JTReg tests is by setting both _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variables. >> As it stands now, not all tests pass while running with code coverage, which pass normally. This particular enhancement is not addressing failing tests. The tests will need to be fixed separately if ever. For example, there are 35 tests which fail in open/test/jdk:jdk_core. A quick look tells that the majority of the failures are in tests which verify error output and discover an unexpected line "Picked up _JAVA_OPTIONS: -Xmx4g?. > > We've been bitten in the past with VM warnings causing tests to fail due to the unexpected output and made a conscious effort to fix all such tests. Unfortunately a few still remain. Do your 35 failures match up with the tests in the blocking issues for this bug: > > https://bugs.openjdk.java.net/browse/JDK-8196741 > > ? 35 seems a lot. I hope we haven't regressed in this area. > > Thanks, > David > >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8215729 >> Webrev: http://cr.openjdk.java.net/~shurailine/8215729/webrev.01/ >> Shura From david.holmes at oracle.com Wed Jan 9 21:31:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jan 2019 07:31:37 +1000 Subject: RFR 8215729: Enhance makefiles to allow collecting code coverage with JCov In-Reply-To: <8A4FEC01-F8AF-4B10-B32D-28B6B2E24D26@oracle.com> References: <07165F0F-789D-45F3-8422-E2B0CFA80343@oracle.com> <057f2307-b659-cf3e-16e7-1a7872de303c@oracle.com> <8A4FEC01-F8AF-4B10-B32D-28B6B2E24D26@oracle.com> Message-ID: <9a9962a4-2c1a-fccd-607c-97c5d488dd49@oracle.com> On 10/01/2019 5:46 am, Alexandre (Shura) Iline wrote: > David, > > At least these tests appear to be failing because of extra lines in the error output (showing test names with a line or two from jtr file): Thanks. I think the difference here compared to 8196741 is that these tests fail due to extra output on stderr, while the VM warnings go to stdout. David > java/io/File/DeleteOnExitNPE.java > java.lang.RuntimeException: Failed: No output should have been received from the process > java/lang/ProcessBuilder/SkipTest.java > java.lang.AssertionError: header char wrong, expected: 65, actual: 80 > java/lang/Runtime/exec/ArgWithSpaceAndFinalBackslash.java > java.lang.Exception: Test failed: Got "Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g > Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g > foo bar\\baz\\", expected "foo bar\\baz\\" > java/lang/Runtime/exec/ExitValue.java > java.lang.Exception: Unexpected stderr: Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g > Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g > java/lang/Thread/UncaughtExceptions.sh > FAIL: Expected "Exception in thread "Thread-0".*Seppuku", got Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g > java/net/InetAddress/ptr/Lookup.java > IPv4 lookup results: [192.0.43.7:icann.orgPicked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g > Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g > ] > java/net/URLConnection/ContentHandlers/ContentHandlersTest.java > java.lang.RuntimeException: Expected a different kind of failure: Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g > Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g > java/net/spi/URLStreamHandlerProvider/Basic.java > java.lang.RuntimeException: Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g > Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g > java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java > stderr: [Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g > Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g > Bad response or premature EOF, bytes read: > java.lang.RuntimeException: Bad response or premature EOF from service > java/security/AccessController/DoPrivAccompliceTest.java > java.lang.RuntimeException: stderr was not empty > java/util/logging/LoggingDeadlock2.java > Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g > Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g > not equal to > java/util/zip/EntryCount64k.java > java.lang.RuntimeException: '\A\Z' missing from stderr > javax/naming/spi/providers/InitialContextTest.java > java.lang.RuntimeException: Expected a different kind of failure: Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g > Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g > sun/rmi/runtime/Log/6409194/NoConsoleOutput.java > java.lang.Error: TEST FAILED: unexpected subprocess output > sun/tools/jrunscript/jrunscript-eTest.sh > sun/tools/jrunscript/jrunscript-fTest.sh > sun/tools/jrunscript/jrunscriptTest.sh > Output of jrunscript -e differ from expected output. Failed. > tools/jar/LeadingGarbage.java > test LeadingGarbage.test_canListWithLeadingGarbage(): failure > java.lang.RuntimeException: '\\A\\Z' missing from stderr > tools/jar/modularJar/Basic.java > java.lang.AssertionError: Unknown value Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g > tools/jar/multiRelease/Basic.java > java.lang.RuntimeException: stderr was not empty > tools/jjs/jjs-fileTest.sh > Output of jjs file.js differ from expected output. Failed. > > > > > Other failures are: > > java/io/CharArrayReader/OverflowInRead.java > java/lang/ProcessBuilder/InheritIO/InheritIO.sh > java/lang/StackTraceElement/ModuleFrames.java > java/lang/StackTraceElement/SerialTest.java > java/lang/StackWalker/VerifyStackTrace.java > java/lang/invoke/lambda/LogGeneratedClassesTest.java > java/net/MulticastSocket/PromiscuousIPv6.java > java/net/URL/JarHandlerPkgPrefix/JarHandlerPkgPrefix.java > java/nio/Buffer/LimitDirectMemory.java > java/nio/channels/DatagramChannel/PromiscuousIPv6.java > java/util/concurrent/locks/Lock/TimedAcquireLeak.java > jdk/internal/misc/VM/RuntimeArguments.java > jdk/modules/etc/JdkQualifiedExportTest.java > tools/jar/multiRelease/ApiValidatorTest.java > > > Again, a thorough analysis will need to be done - here I just quickly scanned the jtr files. > > Shura > >> On Jan 8, 2019, at 6:15 PM, David Holmes wrote: >> >> Hi Shura, >> >> Sorry not a review just a comment on one thing ... >> >> On 9/01/2019 4:35 am, Alexandre (Shura) Iline wrote: >>> Hi, >>> Could you please take a look on a change which allows to run tests while collecting code coverage with JCov. This is a continuation of work done in >>> JDK-8214309: Enhance makefiles to allow generating JCov instrumented build. >>> This adds make targets jcov-test and others like jcov-test-tier1 etc. After running the tests, one is left with a coverage report and also a data file containing coverage, for further analysis. >>> Part of the changes are related to increasing maximum and initial heap size, which is needed to be done because instrumented classes are bigger in size. The way it is done for JTReg tests is by setting both _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variables. >>> As it stands now, not all tests pass while running with code coverage, which pass normally. This particular enhancement is not addressing failing tests. The tests will need to be fixed separately if ever. For example, there are 35 tests which fail in open/test/jdk:jdk_core. A quick look tells that the majority of the failures are in tests which verify error output and discover an unexpected line "Picked up _JAVA_OPTIONS: -Xmx4g?. >> >> We've been bitten in the past with VM warnings causing tests to fail due to the unexpected output and made a conscious effort to fix all such tests. Unfortunately a few still remain. Do your 35 failures match up with the tests in the blocking issues for this bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8196741 >> >> ? 35 seems a lot. I hope we haven't regressed in this area. >> >> Thanks, >> David >> >>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8215729 >>> Webrev: http://cr.openjdk.java.net/~shurailine/8215729/webrev.01/ >>> Shura > From jonathan.gibbons at oracle.com Wed Jan 9 21:39:11 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 9 Jan 2019 13:39:11 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> Message-ID: <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> Erik, I have pushed a version of Andrew's patch for jtreg into the jtreg repo. With regard to Andrew's proposed patch for make/RunTests.gmk, the name of the option to use for jtreg is now just "-wsl'. -- Jon On 01/07/2019 01:10 AM, Erik Joelsson wrote: > Hello Andrew, > > If the patch gets accepted to Jtreg, this looks good. We will need to > wait for Jtreg support before pushing this though. > > /Erik > > On 2019-01-06 20:34, Andrew Luo wrote: >> Hi Everyone, >> >> I've gotten shell tests to run on WSL with some changes to jtreg and >> a small change to the OpenJDK gmake files.? Most of them are still >> not passing (I believe one or two of them did just work out of the >> box after these changes as failures + error count dropped; previous >> errors + previous failures < current failures; also "errors" dropped >> to zero), as the scripts themselves will need to be changed, however, >> at least now they can actually run...? My patch with proposed changes >> are attached. >> >> I've sent the corresponding jtreg changes to the code-tools-dev >> mailing list: >> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/000464.html >> >> Let me know if you have any feedback/comments. >> >> Thanks, >> >> -Andrew >> >> From erik.joelsson at oracle.com Thu Jan 10 17:14:51 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Jan 2019 09:14:51 -0800 Subject: RFR: JDK-8216489: Issues with ModulePackages attribute generation on incremental build Message-ID: <74551b53-ec49-fe3a-bb26-c61e6ce2fb01@oracle.com> The incremental build of exploded-image-optimize is broken. This is caused by a small typo in the prerequisites declaration for the recipe. Bug: https://bugs.openjdk.java.net/browse/JDK-8216489 Webrev: http://cr.openjdk.java.net/~erikj/8216489/webrev.01/ /Erik From claes.redestad at oracle.com Thu Jan 10 17:20:20 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 10 Jan 2019 18:20:20 +0100 Subject: RFR: JDK-8216489: Issues with ModulePackages attribute generation on incremental build In-Reply-To: <74551b53-ec49-fe3a-bb26-c61e6ce2fb01@oracle.com> References: <74551b53-ec49-fe3a-bb26-c61e6ce2fb01@oracle.com> Message-ID: <53EBD06F-F6B5-437F-A809-45FFC11C3038@oracle.com> Looks good! /Claes Erik Joelsson skrev: (10 januari 2019 18:14:51 CET) >The incremental build of exploded-image-optimize is broken. This is >caused by a small typo in the prerequisites declaration for the recipe. > >Bug: https://bugs.openjdk.java.net/browse/JDK-8216489 > >Webrev: http://cr.openjdk.java.net/~erikj/8216489/webrev.01/ > >/Erik -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From Alan.Bateman at oracle.com Thu Jan 10 17:23:39 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Jan 2019 17:23:39 +0000 Subject: RFR: JDK-8216489: Issues with ModulePackages attribute generation on incremental build In-Reply-To: <74551b53-ec49-fe3a-bb26-c61e6ce2fb01@oracle.com> References: <74551b53-ec49-fe3a-bb26-c61e6ce2fb01@oracle.com> Message-ID: On 10/01/2019 17:14, Erik Joelsson wrote: > The incremental build of exploded-image-optimize is broken. This is > caused by a small typo in the prerequisites declaration for the recipe. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216489 > > Webrev: http://cr.openjdk.java.net/~erikj/8216489/webrev.01/ Looks good, I'm sure we could stare at that line for several minutes before spotting it. BTW: If it helps then the tool to add this attribute could easily be modified to update specific modules rather than all. That might help with some incremental build cases to avoid scanning all modules. -Alan From tim.bell at oracle.com Thu Jan 10 18:01:27 2019 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 10 Jan 2019 10:01:27 -0800 Subject: RFR: JDK-8216489: Issues with ModulePackages attribute generation on incremental build In-Reply-To: References: <74551b53-ec49-fe3a-bb26-c61e6ce2fb01@oracle.com> Message-ID: <5C378877.8080109@oracle.com> Erik: Looks good. I agree with Alan - that is a very subtle typo. Tim On 01/10/19 09:23, Alan Bateman wrote: > On 10/01/2019 17:14, Erik Joelsson wrote: >> The incremental build of exploded-image-optimize is broken. This is >> caused by a small typo in the prerequisites declaration for the recipe. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216489 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8216489/webrev.01/ > Looks good, I'm sure we could stare at that line for several minutes > before spotting it. > > BTW: If it helps then the tool to add this attribute could easily be > modified to update specific modules rather than all. That might help > with some incremental build cases to avoid scanning all modules. > > -Alan From erik.joelsson at oracle.com Fri Jan 11 00:46:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Jan 2019 16:46:09 -0800 Subject: Error placementdelmatch when compiling OpenJDK 11 with Oracle Developer Studio In-Reply-To: <20190108-152754.13hbpbdro-2lai@mailcc08> References: <20190108-152754.13hbpbdro-2lai@mailcc08> Message-ID: <1035ee73-87ea-0827-42ae-3b318382d5da@oracle.com> Hello Michael, Moving this question to build-dev. At Oracle we successfully build jdk11u using Oracle developer studio version 12.4. The OpenJDK Wiki [1] contains a page with known working build environments. The most up to date information for a particular set of sources is usually the doc/building.md file in the source which also lists 12.4 for Solaris. It also lists the exact package versions used at Oracle. I see that you are using studio 12.5. This is untested and so not surprising to be causing trouble. In JDK 12, we switched to 12.6 and it required changes to get it to work. /Erik [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms On 2019-01-08 06:27, Michael Kebe wrote: > Hi, > > I am trying to compile OpenJDK 11 from the hg source (http://hg.openjdk.java.net/jdk-updates/jdk11u), but I get this error: > > "..../jdk11u/src/hotspot/share/adlc/arena.cpp", line 60: Error, placementdelmatch: Placement operator new refers to non-placement operator delete. > "..../jdk11u/src/hotspot/share/adlc/arena.cpp", line 67: Error, placementdelmatch: Placement operator new refers to non-placement operator delete. > "..../jdk11u/src/hotspot/share/adlc/arena.cpp", line 97: Error, placementdelmatch: Placement operator new refers to non-placement operator delete. > > I found this issue https://bugs.openjdk.java.net/browse/JDK-8164651. > It says in a comment, that is fixed, but I used the bleeding edge from the mercurial repository. > > Is the support for Solaris dropped? > > Additional info from the configure script: > > A new configuration has been successfully created in > /..../jdk11u/build/solaris-sparcv9-normal-server-release > using configure arguments '--with-boot-jdk=../jdk-11.0.1'. > > Configuration summary: > * Debug level: release > * HS debug level: product > * JVM variants: server > * JVM features: server: 'cds cmsgc compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check jvmci jvmti management nmt parallelgc serialgc services vm-structs' > * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 64 > * Version string: 11.0.1-internal+0-adhoc.sysa.jdk11u (11.0.1-internal) > > Tools summary: > * Boot JDK: java version "11.0.1" 2018-10-16 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode) (at /..../jdk-11.0.1) > * Toolchain: solstudio (Oracle Solaris Studio) > * C Compiler: Version 5.14 (at /opt/developerstudio12.5/bin/cc) > * C++ Compiler: Version 5.14 (at /opt/developerstudio12.5/bin/CC) > > Build performance summary: > * Cores to use: 16 > * Memory limit: 20480 MB > > > Michael > > > > H?ttenwerke Krupp Mannesmann GmbH, Ehinger Str. 200, D-47259 Duisburg > Gesch?ftsf?hrung: Dr. Herbert Eichelkraut, Dr. Gerhard Erdmann, Carsten Laakmann > Vorsitzender des Aufsichtsrats: Prof. Dr.-Ing. Heinz J?rg Fuhrmann > Sitz der Gesellschaft: Duisburg > Eintragung im Handelsregister: Amtsgericht Duisburg HRB 4716 > http://www.hkm.de From andrewluotechnologies at outlook.com Fri Jan 11 05:02:07 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 11 Jan 2019 05:02:07 +0000 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> Message-ID: I've updated my patch per the latest jtreg changes. Tested this with the latest code synced from the jtreg repository, seems like shell tests do get run (but don't pass, tests will need to be changed). Thanks, -Andrew -----Original Message----- From: Jonathan Gibbons Sent: Wednesday, January 9, 2019 1:39 PM To: Erik Joelsson ; Andrew Luo ; build-dev at openjdk.java.net Subject: Re: [PATCH] Fixes for running tests on WSL Erik, I have pushed a version of Andrew's patch for jtreg into the jtreg repo. With regard to Andrew's proposed patch for make/RunTests.gmk, the name of the option to use for jtreg is now just "-wsl'. -- Jon On 01/07/2019 01:10 AM, Erik Joelsson wrote: > Hello Andrew, > > If the patch gets accepted to Jtreg, this looks good. We will need to > wait for Jtreg support before pushing this though. > > /Erik > > On 2019-01-06 20:34, Andrew Luo wrote: >> Hi Everyone, >> >> I've gotten shell tests to run on WSL with some changes to jtreg and >> a small change to the OpenJDK gmake files.? Most of them are still >> not passing (I believe one or two of them did just work out of the >> box after these changes as failures + error count dropped; previous >> errors + previous failures < current failures; also "errors" dropped >> to zero), as the scripts themselves will need to be changed, however, >> at least now they can actually run...? My patch with proposed changes >> are attached. >> >> I've sent the corresponding jtreg changes to the code-tools-dev >> mailing list: >> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/0 >> 00464.html >> >> Let me know if you have any feedback/comments. >> >> Thanks, >> >> -Andrew >> >> -------------- next part -------------- diff --git a/make/RunTests.gmk b/make/RunTests.gmk --- a/make/RunTests.gmk +++ b/make/RunTests.gmk @@ -1,5 +1,5 @@ # -# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -814,6 +814,10 @@ $1_JTREG_BASIC_OPTIONS += -e:_NT_SYMBOL_PATH endif + ifeq ($$(OPENJDK_BUILD_OS_ENV), windows.wsl) + $1_JTREG_BASIC_OPTIONS += -wsl + endif + $1_JTREG_BASIC_OPTIONS += \ $$(addprefix -javaoption:, $$(JTREG_JAVA_OPTIONS)) \ $$(addprefix -vmoption:, $$(JTREG_VM_OPTIONS)) \ From jonathan.gibbons at oracle.com Fri Jan 11 16:51:57 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 11 Jan 2019 08:51:57 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> Message-ID: <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> Erik, Can you try a test run with the latest jtreg bits, and post the results for me to look at, to see why tests are failing and what, if anything, needs to be done? -- Jon On 1/10/19 9:02 PM, Andrew Luo wrote: > I've updated my patch per the latest jtreg changes. Tested this with the latest code synced from the jtreg repository, seems like shell tests do get run (but don't pass, tests will need to be changed). > > Thanks, > > -Andrew > > -----Original Message----- > From: Jonathan Gibbons > Sent: Wednesday, January 9, 2019 1:39 PM > To: Erik Joelsson ; Andrew Luo ; build-dev at openjdk.java.net > Subject: Re: [PATCH] Fixes for running tests on WSL > > Erik, > > I have pushed a version of Andrew's patch for jtreg into the jtreg repo. > > With regard to Andrew's proposed patch for make/RunTests.gmk, the name of the option to use for jtreg is now just "-wsl'. > > -- Jon > > On 01/07/2019 01:10 AM, Erik Joelsson wrote: >> Hello Andrew, >> >> If the patch gets accepted to Jtreg, this looks good. We will need to >> wait for Jtreg support before pushing this though. >> >> /Erik >> >> On 2019-01-06 20:34, Andrew Luo wrote: >>> Hi Everyone, >>> >>> I've gotten shell tests to run on WSL with some changes to jtreg and >>> a small change to the OpenJDK gmake files.? Most of them are still >>> not passing (I believe one or two of them did just work out of the >>> box after these changes as failures + error count dropped; previous >>> errors + previous failures < current failures; also "errors" dropped >>> to zero), as the scripts themselves will need to be changed, however, >>> at least now they can actually run...? My patch with proposed changes >>> are attached. >>> >>> I've sent the corresponding jtreg changes to the code-tools-dev >>> mailing list: >>> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/0 >>> 00464.html >>> >>> Let me know if you have any feedback/comments. >>> >>> Thanks, >>> >>> -Andrew >>> >>> From erik.joelsson at oracle.com Fri Jan 11 17:44:26 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 Jan 2019 09:44:26 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> Message-ID: <725be6c5-ccad-5db7-b2eb-2bf5d0e87f54@oracle.com> Hello, With the new jtreg and the patch, normal java tests seem to work fine. I tried some simple shell tests and they fail. I took a test in langtools as an example: open/test/langtools/tools/javac/Paths/Class-Path.sh I invoked it like this: $ make test TEST=langtools/tools/javac/Paths/Class-Path.sh It fails with the following: -------------------------------------------------- TEST: tools/javac/Paths/Class-Path.sh TEST JDK: d:\erik\jdk-jib-wsl\build\windows-x64\images\jdk ACTION: shell -- Failed. Execution failed: exit code 127 REASON: User specified action: run shell Class-Path.sh TIME:?? 0.125 seconds messages: command: shell Class-Path.sh reason: User specified action: run shell Class-Path.sh elapsed time (seconds): 0.125 STDOUT: STDERR: sh: 0: Can't open /mnt/d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh It seems the translation of the path fails. Further down in the jtr file, this looks to be the command line Jtreg is trying to run: ??? wsl.exe \\ ??????? sh '/mnt/d:\\/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh' It should be noted that WSL does not understand windows paths like Cygwin does. By default it mounts every Windows drive x in /mnt/x, but this is configurable so should not be assumed. There is a tool, wslpath, similar to cygpath, which can be used to translate. It's also possible to translate environment variables by adding them to WSLENV. Perhaps using WSLENV would be a reasonable trick here. When running wsl.exe, also set something like this in the env: JTREG_TEST_PATH=d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh WSLENV=$WSLENV:JTREG_TEST_PATH/p then rewrite the command as: $ wsl.exe sh $JTREG_TEST_PATH /Erik On 2019-01-11 08:51, Jonathan Gibbons wrote: > Erik, > > Can you try a test run with the latest jtreg bits, and post the > results for me to look at, to see why tests are failing and what, if > anything, needs to be done? > > -- Jon > > On 1/10/19 9:02 PM, Andrew Luo wrote: >> I've updated my patch per the latest jtreg changes.? Tested this with >> the latest code synced from the jtreg repository, seems like shell >> tests do get run (but don't pass, tests will need to be changed). >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Jonathan Gibbons >> Sent: Wednesday, January 9, 2019 1:39 PM >> To: Erik Joelsson ; Andrew Luo >> ; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Fixes for running tests on WSL >> >> Erik, >> >> I have pushed a version of Andrew's patch for jtreg into the jtreg repo. >> >> With regard to Andrew's proposed patch for make/RunTests.gmk, the >> name of the option to use for jtreg is now just "-wsl'. >> >> -- Jon >> >> On 01/07/2019 01:10 AM, Erik Joelsson wrote: >>> Hello Andrew, >>> >>> If the patch gets accepted to Jtreg, this looks good. We will need to >>> wait for Jtreg support before pushing this though. >>> >>> /Erik >>> >>> On 2019-01-06 20:34, Andrew Luo wrote: >>>> Hi Everyone, >>>> >>>> I've gotten shell tests to run on WSL with some changes to jtreg and >>>> a small change to the OpenJDK gmake files.? Most of them are still >>>> not passing (I believe one or two of them did just work out of the >>>> box after these changes as failures + error count dropped; previous >>>> errors + previous failures < current failures; also "errors" dropped >>>> to zero), as the scripts themselves will need to be changed, however, >>>> at least now they can actually run...? My patch with proposed changes >>>> are attached. >>>> >>>> I've sent the corresponding jtreg changes to the code-tools-dev >>>> mailing list: >>>> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/0 >>>> 00464.html >>>> >>>> Let me know if you have any feedback/comments. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> From jonathan.gibbons at oracle.com Fri Jan 11 18:14:20 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 11 Jan 2019 10:14:20 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: <725be6c5-ccad-5db7-b2eb-2bf5d0e87f54@oracle.com> References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> <725be6c5-ccad-5db7-b2eb-2bf5d0e87f54@oracle.com> Message-ID: I'm pretty sure I know the problem. I'll post an update to jtreg. -- Jon On 01/11/2019 09:44 AM, Erik Joelsson wrote: > Hello, > > With the new jtreg and the patch, normal java tests seem to work fine. > > I tried some simple shell tests and they fail. I took a test in > langtools as an example: > > open/test/langtools/tools/javac/Paths/Class-Path.sh > > I invoked it like this: > > $ make test TEST=langtools/tools/javac/Paths/Class-Path.sh > > It fails with the following: > > -------------------------------------------------- > TEST: tools/javac/Paths/Class-Path.sh > TEST JDK: d:\erik\jdk-jib-wsl\build\windows-x64\images\jdk > > ACTION: shell -- Failed. Execution failed: exit code 127 > REASON: User specified action: run shell Class-Path.sh > TIME:?? 0.125 seconds > messages: > command: shell Class-Path.sh > reason: User specified action: run shell Class-Path.sh > elapsed time (seconds): 0.125 > STDOUT: > STDERR: > sh: 0: Can't open > /mnt/d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh > > It seems the translation of the path fails. Further down in the jtr > file, this looks to be the command line Jtreg is trying to run: > > ??? wsl.exe \\ > ??????? sh > '/mnt/d:\\/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh' > > It should be noted that WSL does not understand windows paths like > Cygwin does. By default it mounts every Windows drive x in /mnt/x, but > this is configurable so should not be assumed. There is a tool, > wslpath, similar to cygpath, which can be used to translate. It's also > possible to translate environment variables by adding them to WSLENV. > > Perhaps using WSLENV would be a reasonable trick here. When running > wsl.exe, also set something like this in the env: > > JTREG_TEST_PATH=d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh > > WSLENV=$WSLENV:JTREG_TEST_PATH/p > > then rewrite the command as: > > $ wsl.exe sh $JTREG_TEST_PATH > > /Erik > > On 2019-01-11 08:51, Jonathan Gibbons wrote: >> Erik, >> >> Can you try a test run with the latest jtreg bits, and post the >> results for me to look at, to see why tests are failing and what, if >> anything, needs to be done? >> >> -- Jon >> >> On 1/10/19 9:02 PM, Andrew Luo wrote: >>> I've updated my patch per the latest jtreg changes.? Tested this >>> with the latest code synced from the jtreg repository, seems like >>> shell tests do get run (but don't pass, tests will need to be changed). >>> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Jonathan Gibbons >>> Sent: Wednesday, January 9, 2019 1:39 PM >>> To: Erik Joelsson ; Andrew Luo >>> ; build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Fixes for running tests on WSL >>> >>> Erik, >>> >>> I have pushed a version of Andrew's patch for jtreg into the jtreg >>> repo. >>> >>> With regard to Andrew's proposed patch for make/RunTests.gmk, the >>> name of the option to use for jtreg is now just "-wsl'. >>> >>> -- Jon >>> >>> On 01/07/2019 01:10 AM, Erik Joelsson wrote: >>>> Hello Andrew, >>>> >>>> If the patch gets accepted to Jtreg, this looks good. We will need to >>>> wait for Jtreg support before pushing this though. >>>> >>>> /Erik >>>> >>>> On 2019-01-06 20:34, Andrew Luo wrote: >>>>> Hi Everyone, >>>>> >>>>> I've gotten shell tests to run on WSL with some changes to jtreg and >>>>> a small change to the OpenJDK gmake files.? Most of them are still >>>>> not passing (I believe one or two of them did just work out of the >>>>> box after these changes as failures + error count dropped; previous >>>>> errors + previous failures < current failures; also "errors" dropped >>>>> to zero), as the scripts themselves will need to be changed, however, >>>>> at least now they can actually run...? My patch with proposed changes >>>>> are attached. >>>>> >>>>> I've sent the corresponding jtreg changes to the code-tools-dev >>>>> mailing list: >>>>> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/0 >>>>> 00464.html >>>>> >>>>> Let me know if you have any feedback/comments. >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> From erik.joelsson at oracle.com Fri Jan 11 21:45:50 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 Jan 2019 13:45:50 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> <725be6c5-ccad-5db7-b2eb-2bf5d0e87f54@oracle.com> Message-ID: With the new jtreg, the test is launched correctly. It's now a problem with the test. When WSL launches a Windows executable, it needs to run it with the full name (including .exe). This particular test tries to run things like: /mnt/d/erik/jdk-jib-wsl/build/windows-x64/images/jdk/bin/javac -J-Xmx768m -J-XX:MaxRAMPercentage=1 -J-ea -J-esa pkg/A.java pkg/B.java Which fails because it needs to be javac.exe. To fix these tests, one thing we need to do is find a good way of identifying that the JDK under test is of Windows type and in that case add .exe to the executables. Note that checking if the execution environment happens to be WSL is not good enough. The relevant part in this case is identifying the JDK under test. /Erik On 2019-01-11 10:14, Jonathan Gibbons wrote: > I'm pretty sure I know the problem. I'll post an update to jtreg. > > -- Jon > > On 01/11/2019 09:44 AM, Erik Joelsson wrote: >> Hello, >> >> With the new jtreg and the patch, normal java tests seem to work fine. >> >> I tried some simple shell tests and they fail. I took a test in >> langtools as an example: >> >> open/test/langtools/tools/javac/Paths/Class-Path.sh >> >> I invoked it like this: >> >> $ make test TEST=langtools/tools/javac/Paths/Class-Path.sh >> >> It fails with the following: >> >> -------------------------------------------------- >> TEST: tools/javac/Paths/Class-Path.sh >> TEST JDK: d:\erik\jdk-jib-wsl\build\windows-x64\images\jdk >> >> ACTION: shell -- Failed. Execution failed: exit code 127 >> REASON: User specified action: run shell Class-Path.sh >> TIME:?? 0.125 seconds >> messages: >> command: shell Class-Path.sh >> reason: User specified action: run shell Class-Path.sh >> elapsed time (seconds): 0.125 >> STDOUT: >> STDERR: >> sh: 0: Can't open >> /mnt/d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh >> >> It seems the translation of the path fails. Further down in the jtr >> file, this looks to be the command line Jtreg is trying to run: >> >> ??? wsl.exe \\ >> ??????? sh >> '/mnt/d:\\/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh' >> >> It should be noted that WSL does not understand windows paths like >> Cygwin does. By default it mounts every Windows drive x in /mnt/x, >> but this is configurable so should not be assumed. There is a tool, >> wslpath, similar to cygpath, which can be used to translate. It's >> also possible to translate environment variables by adding them to >> WSLENV. >> >> Perhaps using WSLENV would be a reasonable trick here. When running >> wsl.exe, also set something like this in the env: >> >> JTREG_TEST_PATH=d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh >> >> WSLENV=$WSLENV:JTREG_TEST_PATH/p >> >> then rewrite the command as: >> >> $ wsl.exe sh $JTREG_TEST_PATH >> >> /Erik >> >> On 2019-01-11 08:51, Jonathan Gibbons wrote: >>> Erik, >>> >>> Can you try a test run with the latest jtreg bits, and post the >>> results for me to look at, to see why tests are failing and what, if >>> anything, needs to be done? >>> >>> -- Jon >>> >>> On 1/10/19 9:02 PM, Andrew Luo wrote: >>>> I've updated my patch per the latest jtreg changes.? Tested this >>>> with the latest code synced from the jtreg repository, seems like >>>> shell tests do get run (but don't pass, tests will need to be >>>> changed). >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Jonathan Gibbons >>>> Sent: Wednesday, January 9, 2019 1:39 PM >>>> To: Erik Joelsson ; Andrew Luo >>>> ; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Fixes for running tests on WSL >>>> >>>> Erik, >>>> >>>> I have pushed a version of Andrew's patch for jtreg into the jtreg >>>> repo. >>>> >>>> With regard to Andrew's proposed patch for make/RunTests.gmk, the >>>> name of the option to use for jtreg is now just "-wsl'. >>>> >>>> -- Jon >>>> >>>> On 01/07/2019 01:10 AM, Erik Joelsson wrote: >>>>> Hello Andrew, >>>>> >>>>> If the patch gets accepted to Jtreg, this looks good. We will need to >>>>> wait for Jtreg support before pushing this though. >>>>> >>>>> /Erik >>>>> >>>>> On 2019-01-06 20:34, Andrew Luo wrote: >>>>>> Hi Everyone, >>>>>> >>>>>> I've gotten shell tests to run on WSL with some changes to jtreg and >>>>>> a small change to the OpenJDK gmake files.? Most of them are still >>>>>> not passing (I believe one or two of them did just work out of the >>>>>> box after these changes as failures + error count dropped; previous >>>>>> errors + previous failures < current failures; also "errors" dropped >>>>>> to zero), as the scripts themselves will need to be changed, >>>>>> however, >>>>>> at least now they can actually run...? My patch with proposed >>>>>> changes >>>>>> are attached. >>>>>> >>>>>> I've sent the corresponding jtreg changes to the code-tools-dev >>>>>> mailing list: >>>>>> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/0 >>>>>> >>>>>> 00464.html >>>>>> >>>>>> Let me know if you have any feedback/comments. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> > From jonathan.gibbons at oracle.com Fri Jan 11 22:12:18 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 11 Jan 2019 14:12:18 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> <725be6c5-ccad-5db7-b2eb-2bf5d0e87f54@oracle.com> Message-ID: <956d24c3-4ac8-d0f5-89dc-fd4952ee887b@oracle.com> 3 options that come to mind are ... 1. jtreg sets new env variables for any/all JDK tools that may be invoked, including java and javac, and the scripts are updated to use the new variables 2. jtreg sets a single new env variable EXE, which is either empty or ".exe". A bit ugly for anyone not used to using WSL 3. all the magic is somehow done in the tests, with no additional change to jtreg I also note the orthogonal option, which is to continue the migration away from using shell tests as much as possible. -- Jon On 01/11/2019 01:45 PM, Erik Joelsson wrote: > With the new jtreg, the test is launched correctly. It's now a problem > with the test. When WSL launches a Windows executable, it needs to run > it with the full name (including .exe). This particular test tries to > run things like: > > /mnt/d/erik/jdk-jib-wsl/build/windows-x64/images/jdk/bin/javac > -J-Xmx768m -J-XX:MaxRAMPercentage=1 -J-ea -J-esa pkg/A.java pkg/B.java > > Which fails because it needs to be javac.exe. > > To fix these tests, one thing we need to do is find a good way of > identifying that the JDK under test is of Windows type and in that > case add .exe to the executables. Note that checking if the execution > environment happens to be WSL is not good enough. The relevant part in > this case is identifying the JDK under test. > > /Erik > > On 2019-01-11 10:14, Jonathan Gibbons wrote: >> I'm pretty sure I know the problem. I'll post an update to jtreg. >> >> -- Jon >> >> On 01/11/2019 09:44 AM, Erik Joelsson wrote: >>> Hello, >>> >>> With the new jtreg and the patch, normal java tests seem to work fine. >>> >>> I tried some simple shell tests and they fail. I took a test in >>> langtools as an example: >>> >>> open/test/langtools/tools/javac/Paths/Class-Path.sh >>> >>> I invoked it like this: >>> >>> $ make test TEST=langtools/tools/javac/Paths/Class-Path.sh >>> >>> It fails with the following: >>> >>> -------------------------------------------------- >>> TEST: tools/javac/Paths/Class-Path.sh >>> TEST JDK: d:\erik\jdk-jib-wsl\build\windows-x64\images\jdk >>> >>> ACTION: shell -- Failed. Execution failed: exit code 127 >>> REASON: User specified action: run shell Class-Path.sh >>> TIME:?? 0.125 seconds >>> messages: >>> command: shell Class-Path.sh >>> reason: User specified action: run shell Class-Path.sh >>> elapsed time (seconds): 0.125 >>> STDOUT: >>> STDERR: >>> sh: 0: Can't open >>> /mnt/d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh >>> >>> It seems the translation of the path fails. Further down in the jtr >>> file, this looks to be the command line Jtreg is trying to run: >>> >>> ??? wsl.exe \\ >>> ??????? sh >>> '/mnt/d:\\/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh' >>> >>> It should be noted that WSL does not understand windows paths like >>> Cygwin does. By default it mounts every Windows drive x in /mnt/x, >>> but this is configurable so should not be assumed. There is a tool, >>> wslpath, similar to cygpath, which can be used to translate. It's >>> also possible to translate environment variables by adding them to >>> WSLENV. >>> >>> Perhaps using WSLENV would be a reasonable trick here. When running >>> wsl.exe, also set something like this in the env: >>> >>> JTREG_TEST_PATH=d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh >>> >>> WSLENV=$WSLENV:JTREG_TEST_PATH/p >>> >>> then rewrite the command as: >>> >>> $ wsl.exe sh $JTREG_TEST_PATH >>> >>> /Erik >>> >>> On 2019-01-11 08:51, Jonathan Gibbons wrote: >>>> Erik, >>>> >>>> Can you try a test run with the latest jtreg bits, and post the >>>> results for me to look at, to see why tests are failing and what, >>>> if anything, needs to be done? >>>> >>>> -- Jon >>>> >>>> On 1/10/19 9:02 PM, Andrew Luo wrote: >>>>> I've updated my patch per the latest jtreg changes.? Tested this >>>>> with the latest code synced from the jtreg repository, seems like >>>>> shell tests do get run (but don't pass, tests will need to be >>>>> changed). >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Jonathan Gibbons >>>>> Sent: Wednesday, January 9, 2019 1:39 PM >>>>> To: Erik Joelsson ; Andrew Luo >>>>> ; build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Fixes for running tests on WSL >>>>> >>>>> Erik, >>>>> >>>>> I have pushed a version of Andrew's patch for jtreg into the jtreg >>>>> repo. >>>>> >>>>> With regard to Andrew's proposed patch for make/RunTests.gmk, the >>>>> name of the option to use for jtreg is now just "-wsl'. >>>>> >>>>> -- Jon >>>>> >>>>> On 01/07/2019 01:10 AM, Erik Joelsson wrote: >>>>>> Hello Andrew, >>>>>> >>>>>> If the patch gets accepted to Jtreg, this looks good. We will >>>>>> need to >>>>>> wait for Jtreg support before pushing this though. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2019-01-06 20:34, Andrew Luo wrote: >>>>>>> Hi Everyone, >>>>>>> >>>>>>> I've gotten shell tests to run on WSL with some changes to jtreg >>>>>>> and >>>>>>> a small change to the OpenJDK gmake files.? Most of them are still >>>>>>> not passing (I believe one or two of them did just work out of the >>>>>>> box after these changes as failures + error count dropped; previous >>>>>>> errors + previous failures < current failures; also "errors" >>>>>>> dropped >>>>>>> to zero), as the scripts themselves will need to be changed, >>>>>>> however, >>>>>>> at least now they can actually run...? My patch with proposed >>>>>>> changes >>>>>>> are attached. >>>>>>> >>>>>>> I've sent the corresponding jtreg changes to the code-tools-dev >>>>>>> mailing list: >>>>>>> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/0 >>>>>>> >>>>>>> 00464.html >>>>>>> >>>>>>> Let me know if you have any feedback/comments. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> >> From erik.joelsson at oracle.com Fri Jan 11 22:24:22 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 Jan 2019 14:24:22 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: <956d24c3-4ac8-d0f5-89dc-fd4952ee887b@oracle.com> References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> <725be6c5-ccad-5db7-b2eb-2bf5d0e87f54@oracle.com> <956d24c3-4ac8-d0f5-89dc-fd4952ee887b@oracle.com> Message-ID: <94853ab1-3d3e-0b85-fd85-73204c8bf48c@oracle.com> On 2019-01-11 14:12, Jonathan Gibbons wrote: > 3 options that come to mind are ... > > 1. jtreg sets new env variables for any/all JDK tools that may be > invoked, including java and javac, and the scripts are updated to use > the new variables > > 2. jtreg sets a single new env variable EXE, which is either empty or > ".exe". A bit ugly for anyone not used to using WSL > > 3. all the magic is somehow done in the tests, with no additional > change to jtreg > I think 1 or 2 is preferable to 3. There will be a lot of duplication of this logic in the tests otherwise. > I also note the orthogonal option, which is to continue the migration > away from using shell tests as much as possible. > I certainly agree that we need to move away from shell tests long term! /Erik > -- Jon > > > On 01/11/2019 01:45 PM, Erik Joelsson wrote: >> With the new jtreg, the test is launched correctly. It's now a >> problem with the test. When WSL launches a Windows executable, it >> needs to run it with the full name (including .exe). This particular >> test tries to run things like: >> >> /mnt/d/erik/jdk-jib-wsl/build/windows-x64/images/jdk/bin/javac >> -J-Xmx768m -J-XX:MaxRAMPercentage=1 -J-ea -J-esa pkg/A.java pkg/B.java >> >> Which fails because it needs to be javac.exe. >> >> To fix these tests, one thing we need to do is find a good way of >> identifying that the JDK under test is of Windows type and in that >> case add .exe to the executables. Note that checking if the execution >> environment happens to be WSL is not good enough. The relevant part >> in this case is identifying the JDK under test. >> >> /Erik >> >> On 2019-01-11 10:14, Jonathan Gibbons wrote: >>> I'm pretty sure I know the problem. I'll post an update to jtreg. >>> >>> -- Jon >>> >>> On 01/11/2019 09:44 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> With the new jtreg and the patch, normal java tests seem to work fine. >>>> >>>> I tried some simple shell tests and they fail. I took a test in >>>> langtools as an example: >>>> >>>> open/test/langtools/tools/javac/Paths/Class-Path.sh >>>> >>>> I invoked it like this: >>>> >>>> $ make test TEST=langtools/tools/javac/Paths/Class-Path.sh >>>> >>>> It fails with the following: >>>> >>>> -------------------------------------------------- >>>> TEST: tools/javac/Paths/Class-Path.sh >>>> TEST JDK: d:\erik\jdk-jib-wsl\build\windows-x64\images\jdk >>>> >>>> ACTION: shell -- Failed. Execution failed: exit code 127 >>>> REASON: User specified action: run shell Class-Path.sh >>>> TIME:?? 0.125 seconds >>>> messages: >>>> command: shell Class-Path.sh >>>> reason: User specified action: run shell Class-Path.sh >>>> elapsed time (seconds): 0.125 >>>> STDOUT: >>>> STDERR: >>>> sh: 0: Can't open >>>> /mnt/d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh >>>> >>>> It seems the translation of the path fails. Further down in the jtr >>>> file, this looks to be the command line Jtreg is trying to run: >>>> >>>> ??? wsl.exe \\ >>>> ??????? sh >>>> '/mnt/d:\\/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh' >>>> >>>> It should be noted that WSL does not understand windows paths like >>>> Cygwin does. By default it mounts every Windows drive x in /mnt/x, >>>> but this is configurable so should not be assumed. There is a tool, >>>> wslpath, similar to cygpath, which can be used to translate. It's >>>> also possible to translate environment variables by adding them to >>>> WSLENV. >>>> >>>> Perhaps using WSLENV would be a reasonable trick here. When running >>>> wsl.exe, also set something like this in the env: >>>> >>>> JTREG_TEST_PATH=d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh >>>> >>>> WSLENV=$WSLENV:JTREG_TEST_PATH/p >>>> >>>> then rewrite the command as: >>>> >>>> $ wsl.exe sh $JTREG_TEST_PATH >>>> >>>> /Erik >>>> >>>> On 2019-01-11 08:51, Jonathan Gibbons wrote: >>>>> Erik, >>>>> >>>>> Can you try a test run with the latest jtreg bits, and post the >>>>> results for me to look at, to see why tests are failing and what, >>>>> if anything, needs to be done? >>>>> >>>>> -- Jon >>>>> >>>>> On 1/10/19 9:02 PM, Andrew Luo wrote: >>>>>> I've updated my patch per the latest jtreg changes.? Tested this >>>>>> with the latest code synced from the jtreg repository, seems like >>>>>> shell tests do get run (but don't pass, tests will need to be >>>>>> changed). >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jonathan Gibbons >>>>>> Sent: Wednesday, January 9, 2019 1:39 PM >>>>>> To: Erik Joelsson ; Andrew Luo >>>>>> ; build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Fixes for running tests on WSL >>>>>> >>>>>> Erik, >>>>>> >>>>>> I have pushed a version of Andrew's patch for jtreg into the >>>>>> jtreg repo. >>>>>> >>>>>> With regard to Andrew's proposed patch for make/RunTests.gmk, the >>>>>> name of the option to use for jtreg is now just "-wsl'. >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 01/07/2019 01:10 AM, Erik Joelsson wrote: >>>>>>> Hello Andrew, >>>>>>> >>>>>>> If the patch gets accepted to Jtreg, this looks good. We will >>>>>>> need to >>>>>>> wait for Jtreg support before pushing this though. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2019-01-06 20:34, Andrew Luo wrote: >>>>>>>> Hi Everyone, >>>>>>>> >>>>>>>> I've gotten shell tests to run on WSL with some changes to >>>>>>>> jtreg and >>>>>>>> a small change to the OpenJDK gmake files.? Most of them are still >>>>>>>> not passing (I believe one or two of them did just work out of the >>>>>>>> box after these changes as failures + error count dropped; >>>>>>>> previous >>>>>>>> errors + previous failures < current failures; also "errors" >>>>>>>> dropped >>>>>>>> to zero), as the scripts themselves will need to be changed, >>>>>>>> however, >>>>>>>> at least now they can actually run...? My patch with proposed >>>>>>>> changes >>>>>>>> are attached. >>>>>>>> >>>>>>>> I've sent the corresponding jtreg changes to the code-tools-dev >>>>>>>> mailing list: >>>>>>>> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/0 >>>>>>>> >>>>>>>> 00464.html >>>>>>>> >>>>>>>> Let me know if you have any feedback/comments. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> >>> > From magnus.ihse.bursie at oracle.com Mon Jan 14 13:52:26 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 14 Jan 2019 14:52:26 +0100 Subject: =?UTF-8?Q?Re=3a_Build_failure_=22/mnt/data/home/software/openjdk/sr?= =?UTF-8?Q?c/hotspot/share/gc/parallel/objectStartArray=2ecpp=3a106=3a56=3a_?= =?UTF-8?B?ZXJyb3I6IOKAmHZvaWQqIG1lbXNldCh2b2lkKiwgaW50LCBzaXplX3Qp4oCZIHdy?= =?UTF-8?Q?iting_to_an_object_of_type_=e2=80=98class_HeapWord=e2=80=99_with_?= =?UTF-8?B?4oCYcHJpdmF0ZeKAmSBtZW1iZXIg4oCYSGVhcFdvcmQ6OmnigJkgWy1XZXJyb3I9?= =?UTF-8?Q?class-memacc?= In-Reply-To: References: Message-ID: On 2018-12-31 23:15, Karl-Philipp Richter wrote: > Hi Andrew, > Thanks for your quick reply. > > Am 31.12.18 um 21:08 schrieb Andrew Luo: >> Can you run gcc --version and tell us the version of GCC that you are using? > My version is gcc (Ubuntu 8.2.0-7ubuntu1) 8.2.0. > >> I'm guessing this was added in a newer version of GCC (class-memaccess was added in GCC 8), and can probably be worked around using -Wno-error=class-memaccess. That's not saying I don't think we should fix this, just suggesting a workaround for now if you want to compile on GCC 8 before this is fixed. Although I believe that per the C++ standard you are allowed to memcpy/memset trivial classes (clang only warns on non-trivial classes: https://reviews.llvm.org/D45310) so GCC's warning seems to be a bit too broad. > `env MAKEFLAGS= bash ./configure > --with-extra-cflags=-Wno-error=class-memaccess > --with-extra-cxxflags=-Wno-error=class-memaccess && make` avoid the > build failure, however the build now fails because of > > ``` > /mnt/data/home/software/openjdk/src/java.base/unix/native/libjli/java_md_solinux.c: > In function ?ContinueInNewThread0?: > /mnt/data/home/software/openjdk/src/java.base/unix/native/libjli/java_md_solinux.c:747:37: > error: cast between incompatible function types from ?int (*)(void *)? > to ?void * (*)(void *)? [-Werror=cast-function-type] > if (pthread_create(&tid, &attr, (void *(*)(void*))continuation, > (void*)args) == 0) { > ^ > cc1: all warnings being treated as errors > make[3]: *** [CoreLibraries.gmk:212: > /mnt/data/home/software/openjdk/build/linux-x86_64-server-release/support/native/java.base/libjli/java_md_solinux.o] > Fehler 1 > make[3]: *** Auf noch nicht beendete Prozesse wird gewartet ? > make[2]: *** [make/Main.gmk:215: java.base-libs] Fehler 2 > > ERROR: Build failed for target 'default (exploded-image)' in > configuration 'linux-x86_64-server-release' (exit code 2) > ``` > > I agree that the issue should be fixed. > > Since Ubuntu is not among the least popular Linux distributions, I > recommend a review of your continuous integration system which might > need to include more systems. The setup on GitLab is an example to > perform these tests easily, but you probably already have already a CI > set up which you can extend. > > Since I don't need to build OpenJDK urgently, I'd rather see these build > issues detected and fixed by CI coverage of the build process than > stumbling from one to another - it's probably only these two, but afaik > that's a lot of a widely use operating system. The default behavior of the build system is to compile with warnings as errors. When your build fails, the very last message printed by the build system is: "Hint: See doc/building.html#troubleshooting for assistance." If you follow the instructions, you will find this paragraph: [1] "By default, the JDK has a strict approach where warnings from the compiler is considered errors which fail the build. For very new or very old compiler versions, this can trigger new classes of warnings, which thus fails the build. Run configure with --disable-warnings-as-errors to turn of this behavior. (The warnings will still show, but not make the build fail.)" Trying to build a system as complex as OpenJDK without reading the documentation is a very optimistic approach. /Magnus [1] http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html#troubleshooting > >> Are you interested in contributing a fix to this as well - if not I can work on this later this week as well. > I have not enough knowledge to provide a good fix. > >> (By the way, your link https://gitlab.com/krichter/openjdk/-/jobs/140219987 requires signing in). > My bad, fixed. > > -Kalle > From takiguc at linux.vnet.ibm.com Tue Jan 15 00:51:10 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 15 Jan 2019 09:51:10 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> Message-ID: <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> Hello Alan. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ I added IBM29626C charset as standard way. Please give any suggestion and question. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > Hello Alan. > > I opened JDK-8215333 for Charset filtering issue [1]. > I cannot wait until JDK-8215333 is closed. > Is it possible to put IBM-29626C charset with standard way ? > > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > > Thanks, > Ichiroh Takiguchi > > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >> Hello Roger, Magnus and Alan. >> I may need to put alias information into charsets file. >> stdcs-xxx cannot handle this information... >> >> Still AIX needs IBM-29626C charset for default encoding... >> >> I appreciate if you give me further suggestions. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-12-10 20:50, Alan Bateman wrote: >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >>>> On 2018-12-07 21:20, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> It is a nice feature that charsets are selected at build time using >>>>> the stdcs-xxx files. >>>>> This change breaks that pattern and embeds os specific information >>>>> in more than one place. >>>>> That does not seem like an improvement.? Is there any alternative? >>>> I agree. Why is it not enough just to add it to stdcs-aix? >>> My reading of the patch is that the "os" key is to avoid generating >>> it >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >>> non-AIX platforms. The general direction is welcome but I think >>> further work and discussion will be needed to get the right set of >>> changes to support filtering in the build. It can probably be >>> separated from the changes to add IBM-29626C to AIX's java.base. >>> >>> -Alan From magnus.ihse.bursie at oracle.com Tue Jan 15 11:48:27 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Jan 2019 12:48:27 +0100 Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH In-Reply-To: <9d552dc7b4224b98ae2651a17fae6da7@sap.com> References: <256a5fa8b3c4439581fdadee2e739ae5@sap.com> <9d552dc7b4224b98ae2651a17fae6da7@sap.com> Message-ID: <6e8ce6ed-195a-9e9e-4363-4027cf342c6c@oracle.com> Please do. The lib/jli remnants has been lingering on too far in too many places. Just be clear in the bug/commit title that this is not just for AIX. FWIW, your fix looks good to me. /Magnus On 2019-01-15 12:12, Lindenmaier, Goetz wrote: > Ah... a small add on: > > There is one other reference to /jli in the code I could find: > > diff -r 3d6da8a542ab -r 32af46822a7a test/hotspot/gtest/gtestMain.cpp > --- a/test/hotspot/gtest/gtestMain.cpp Mon Jan 14 17:22:23 2019 +0100 > +++ b/test/hotspot/gtest/gtestMain.cpp Tue Jan 15 10:15:39 2019 +0100 > @@ -224,9 +224,9 @@ > > // workaround for JDK-7131356 > #ifdef __APPLE__ > - size_t len = strlen(java_home) + strlen("/lib/jli/libjli.dylib") + 1; > + size_t len = strlen(java_home) + strlen("/lib/libjli.dylib") + 1; > char* path = new char[len]; > - snprintf(path, len, "%s/lib/jli/libjli.dylib", java_home); > + snprintf(path, len, "%s/lib/libjli.dylib", java_home); > dlopen(path, RTLD_NOW | RTLD_GLOBAL); > #endif // __APPLE__ > > Should I add this to this patch, too? > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Dienstag, 15. Januar 2019 12:10 >> To: hotspot-runtime-dev at openjdk.java.net >> Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to >> LIBPATH >> >> Hi, >> >> >> >> As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli >> though has been moved from lib/jli/ to lib/. The path to lib/ is added to >> LIBPATH anyways, so we can remove the special case for AIX. >> >> >> >> Please review this small cleanup. >> >> http://cr.openjdk.java.net/~goetz/wr19/8217044-aixLauncher/01/ >> >> >> >> Best regards, >> >> Goetz. From magnus.ihse.bursie at oracle.com Tue Jan 15 12:28:33 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Jan 2019 13:28:33 +0100 Subject: Review Request : JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM In-Reply-To: References: <195AC878-1B67-43E0-8FF4-D387B916E58A@oracle.com> Message-ID: <5f0b399a-197b-be61-f59e-b16cd78eeb98@oracle.com> On 2018-11-05 15:54, Alan Bateman wrote: > > > On 05/11/2018 14:21, Magnus Ihse Bursie wrote: >> Hi, >> >> Fix looks good, but maybe we should have a regression test of >> GetJREPath()? >> >> /Magnus > The fix looks okay but I'm puzzled as to how Eclipse is running into > this. Do they locate/call libjli/GetJREPath directly or is this > happening then it is called indirectly? Sorry for the necroposting, but I just noticed the following: In Info.plist, on MacOS, we actively publish this key-value data: ??????? CFBundleExecutable ??????? libjli.dylib I'm not sure what this really means or how user's are supposed to relate to this key, but if JLI is an internal-only library, we should probably not publish it like this. Perhaps this is the way that Eclipse get's hold of it..? /Magnus > > -Alan From magnus.ihse.bursie at oracle.com Tue Jan 15 13:09:10 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Jan 2019 14:09:10 +0100 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2) In-Reply-To: References: Message-ID: <01b01dba-73bf-155c-109d-11e88f0b27d6@oracle.com> Hi Andy, This is looking really sweet from a build perspective! Just a few minor nits: * In Launcher-jdk.jpackage.gmk, please indent the else clause ("$(eval $(call SetupBuildLauncher, jpackage ....") two spaces. * In Lib-jdk.jpackage.gmk, I think there's still room to prune some more unnecessary compiler flags and parameters to SetupJdkExecutable: 65 CFLAGS_linux := -fPIC, \ 66 CFLAGS_solaris := -KPIC, \ 67 CFLAGS_macosx := -fPIC, \ ?I wonder if these really are needed. Normally, only shared libraries neeed PIC code. (And for those we set it automatically.) 69 LDFLAGS_windows := -nologo, \ This should not be needed, it's incorporated in CXXFLAGS_JDKEXE. (Also in the second block, for jpackageapplauncherw). 72 LIBS_solaris := -lc, \ Same here; this should not be needed. It's in GLOBAL_LIBS on Solaris, and is always included. 75 VERSIONINFO_RESOURCE := $(GLOBAL_VERSION_INFO_RESOURCE), \ This is setup by default by SetupJdkExecutable, so you can remove it. (Also in the second block, for jpackageapplauncherw). Finally, I do believe that the setups of jpackageapplauncher and jpackageapplauncherw should be done in Launcher-jdk.jpackage.gmk, not Lib-jdk.jpackage.gmk. Since they are to be shipped as resources, they are not "really" launchers in our normal sense, but they are at least more launchers than they are libraries. As we've talked about privately, in the future I'd like to see Windows too use the SetupBuildLauncher method for creating the launcher, but this is clearly good enough for inclusion in the mainline. I also have a question about test/jdk/tools/jpackage/resources/license.txt. What is it used for? And why the odd (incorrect?) spelling of license? /Magnus On 2019-01-11 20:41, Andy Herrick wrote: > This is the second update to the Request For Review of the > implementation of the Java Packager Tool (jpackager) as described in > JEP 343: Packaging Tool > > > > This webrev corresponds to the second EA build, Build 8 (2019/1/8), > posted at http://jdk.java.net/jpackage/ > > This update renames the package used to "jdk.jpackage", removes the > Single Instance Service (and CLI option --singleton), adds several > other CLI options, adds more automated tests, and contains fixes to > the following issues (since update 1 on 11/09/2018): > > JDK-8212164???? resolve jre.list and jre.module.list > JDK-8212936???? Makefile and other improvements for jpackager > JDK-8213385???? jpackager Command-Line Argument File. > JDK-8213392???? Enhance --help and --version > JDK-8213425???? Analyze output from Source code scanner and fix where > needed. > JDK-8213747???? Makefile Improvements to Lib-jdk.packager.gmk > JDK-8213748???? jpackager native launcher for macosx, linux. > JDK-8213756???? SingleInstance runtime improvements > JDK-8213962???? JPackageCreateImageRuntimeModuleTest fails > JDK-8213963???? Flatten out jpackager packages and resources. > JDK-8214021???? Create additional automated tests for jpackager > JDK-8214051???? rename jpackager tool to jpackage > JDK-8214070???? Analyze and Fix issues reported by Parfait > JDK-8214143???? Reduce Resource files > JDK-8214495???? Change behavior of --license-file > JDK-8214575???? Exe installers will install application over existing > installation > JDK-8214899???? rename papplauncher and it's library and move src to > appropriate places > JDK-8214982???? jpackage causes failures in existing HelpFlagsTest and > VersionCheck tests > JDK-8215020???? create-jre-installer exe fails when --runtime-image is > specified. > JDK-8215036???? Create initial set of tests for jpackage > create-installer mode > JDK-8215453???? remove unused BundlerParams and fix misleading messages > JDK-8215515???? Add a command line option to override internal resources. > JDK-8215900???? Without --files args, only jars in the top level of > --input are added to class-path > JDK-8215903???? modify behavior of retaining temporary output dir > JDK-8216190???? Remove Single Instance Service support from jpackage > JDK-8216313???? Add ToolProvider information to jdk.jpackage API docs > JDK-8216373???? temporary build-root left behind when using secondary > launcher(s) > JDK-8216492???? Update copyright of all new jpackage files to 2019 > > Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.03 > > Note: SingleInstanceService API was removed (see > https://bugs.openjdk.java.net/browse/JDK-8216190). > An example stand alone implementation can be found at: > http://cr.openjdk.java.net/~herrick/jpackage/Singleton.java > > please send feedback to core-libs-dev at openjdk.java.net > > /Andy Herrick > From magnus.ihse.bursie at oracle.com Tue Jan 15 13:18:51 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Jan 2019 14:18:51 +0100 Subject: RFR: JDK-8216278: Fix devkit and basic Jib support on WSL In-Reply-To: <84fa67ab-f1ee-1b07-fd93-5fda42f5d6a6@oracle.com> References: <84fa67ab-f1ee-1b07-fd93-5fda42f5d6a6@oracle.com> Message-ID: <2398493e-7277-1dfb-337c-a41a0cdeb3a8@oracle.com> In the future, we should probably consider to make a support function for those "convert a list of paths between windows and unix" blocks; I think we have roughly the same code in say 5 or 6 locations now... /Magnus On 2019-01-09 19:14, Erik Joelsson wrote: > The WSL support in the build does not currently work with devkits. > This prevents us from using Jib to configure a WSL build. This patch > fixes configure to work with devkits when building for Windows in WSL. > > (For Oracle users, I also managed to get Jib working in WSL, and able > to configure both Windows and Linux profiles. Note that since Jib is > not WSL aware itself, you need to manually direct the data dir to a > location visible from Windows. e.g --with-data-dir > /mnt/c/cygwin64/var/tmp/jib-$USER). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216278 > > Webrev: http://cr.openjdk.java.net/~erikj/8216278/webrev.01/index.html > > /Erik > From magnus.ihse.bursie at oracle.com Tue Jan 15 13:35:22 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Jan 2019 14:35:22 +0100 Subject: RFR 8215729: Enhance makefiles to allow collecting code coverage with JCov In-Reply-To: <07165F0F-789D-45F3-8422-E2B0CFA80343@oracle.com> References: <07165F0F-789D-45F3-8422-E2B0CFA80343@oracle.com> Message-ID: Hi Shura, I see that this is pushed already, but I still have some questions and/or follow-up requests: 1) Do you expect the jcov-test-* targets to be used often? We've recently ran into problems with having too many top-level targets, and the large amount of targets generated for the jcov-test-* targets worries me. Before Christmas, I pushed a change which drastically cut down on the number of these auto-generated target names, and now this fix causes a partial regression on that front. To me, running jcov is such a special case, that the general solution using make jcov-test TEST="..." would suffice. 2) I try hard to keep the doc/testing.md documentation relevant and up to date. Can you please write something in that document about what jcov-test does, and how to use it? 3) What is the reasoning for removing the ?598?? $1: run-test-$1 parse-test-$1 ?599 ?600?? TARGETS += $1 construct? This created a "meta" rule that included both running and parsing tests, for each test. I don't think it's used right now (otherwise testing would have broke), I think it's a sane abstraction to have, and in line with what we have elsewhere in the build system. /Magnus On 2019-01-08 19:35, Alexandre (Shura) Iline wrote: > Hi, > > Could you please take a look on a change which allows to run tests while collecting code coverage with JCov. This is a continuation of work done in > JDK-8214309: Enhance makefiles to allow generating JCov instrumented build. > > This adds make targets jcov-test and others like jcov-test-tier1 etc. After running the tests, one is left with a coverage report and also a data file containing coverage, for further analysis. > > Part of the changes are related to increasing maximum and initial heap size, which is needed to be done because instrumented classes are bigger in size. The way it is done for JTReg tests is by setting both _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variables. > > As it stands now, not all tests pass while running with code coverage, which pass normally. This particular enhancement is not addressing failing tests. The tests will need to be fixed separately if ever. For example, there are 35 tests which fail in open/test/jdk:jdk_core. A quick look tells that the majority of the failures are in tests which verify error output and discover an unexpected line "Picked up _JAVA_OPTIONS: -Xmx4g?. > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8215729 > Webrev: http://cr.openjdk.java.net/~shurailine/8215729/webrev.01/ > > Shura From magnus.ihse.bursie at oracle.com Tue Jan 15 13:48:57 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Jan 2019 14:48:57 +0100 Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> <3b6ebd28-c27c-823a-b3ab-85c55be1db76@oracle.com> Message-ID: On 2019-01-03 08:22, Fu Jie wrote: > Thanks Alan for your review and valuable advice. > > I think it's worth keeping a NB project in the repo since it seems > more convenient for IDE developers. > And to keep configurations.xml current is also important. > > I made a patch to fix the issue mentioned by Alan. > Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.01/ It looks much cleaner. I'm just worried, like Alan, that this actually means a loss of functionality. Is NetBeans scanning all files under the specified root, and will automatically find generated files in build/**/gensrc? On the other hand, there are few NetBeans users left out there, and you might very well represent a majority of them. :-) So if this works for you, I'm OK with the change. Please just be ready to assist if this breaks the usage for some other NB users. /Magnus > Thanks Ao Qi for posting the webrev. > > The main idea is that configurations.xml can be split into two parts: > the manually configured part and the automatically generated part. > Only the manually configured part is checked into the repo which is > now less than 80 lines. > And the other part will be generated automatically by NetBeans the > first time when the project is opened. > The complete configurations.xml would be more than 20k lines after the > automatically generated part was filled in. > > With this patch, configurations.xml becomes source-code independent > and there is no need to update it anymore. > Would you please review it and give me some advice? > Thanks. > > Best Regards, > Jie > > On 2019/1/2 ??4:50, Alan Bateman wrote: >> On 28/12/2018 06:34, Fu Jie wrote: >>> Hi, >>> >>> Please review this patch for a build failure with NetBeans: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 >>> Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ >>> >>> Summary >>> The build failure is caused by an incorrect setting of >>> preBuildCommand in make/nb_native/nbproject/configurations.xml. >>> And all invalid source code items in configurations.xml have been >>> removed. >> I don't know the complete history as to why these project files are >> checked into the repo but doesn't it mean configuration.xml needs to >> be updated every time that a .c, .h, .cpp, or .hpp file is added, >> moved, or removed? I assume it will need to an update every week to >> keep it current so I wonder if you've looked at checking in a script >> that generates the project to avoid this ongoing maintenance. >> >> -Alan > From magnus.ihse.bursie at oracle.com Tue Jan 15 14:05:23 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Jan 2019 15:05:23 +0100 Subject: RFR(M): 8215902: Add support for SoftFloat-3e library In-Reply-To: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> Message-ID: <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> On 2018-12-25 16:19, Jakub Van?k wrote: > Hi, > > please review this webrev. It is a successor of the softfloat-3 [patch] > thread (first email > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html > ) > > Changes since the last patch (v6): > > - renamed --with-softloat* to --with-sflt* (it is more compact and it > corresponds to the old --with-sflt-lib=... option) > > - license is now obtained via --with-sflt-license switch (so it is not > included in OpenJDK source tree) > > - updated documentation (slight rewording, added the license option) > > - checks for default --with/--without behavior are in place again > (I forgot them when I changed the way the library is detected) > > - added a simple testcase - I found a disrepancy between softfloat and > system function behavior. When a float with bits 0x003FFFFF is > added to 0x00000001, the correct result is 0x00400000, but the > default software floating point implementation returns 0x00000000. > However I'm not sure where to put this test - now it is in > test/hotspot/jtreg/compiler/floatingpoint. > > - comments in code refer to CR 6757269 and newly JDK-8215902 too. > > I have created a repository with SoftFloat-3e with build configuration > specifically for OpenJDK on armel: > https://github.com/ev3dev-lang-java/softfloat-openjdk > > I can add a link to it to the documentation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 > Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ Hi Jakub, In general this looks good. Some comments: I agree with Erik that you can add a link to your github project; compiling SoftFloat is outside the scope of the OpenJDK build instructions, but it can sure be helpful to lower the bar for users wanting to do that. Just one question: any particular reason you didn't create your github repo by forking the official https://github.com/ucb-bar/berkeley-softfloat-3? That way, it would have been easy for users to see that you were not adding any malicious or suspicious code to the original SoftFloat distribution. On the other hand, I think the link to http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html is unnecessary and just creates clutter in the documentation. Please remove it. /Magnus > CI build: https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ > > Cheers, > > Jakub > From Alan.Bateman at oracle.com Tue Jan 15 15:43:24 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2019 15:43:24 +0000 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> Message-ID: <3eb1adab-7740-8f1b-a4d8-2796d91ee04d@oracle.com> On 15/01/2019 00:51, Ichiroh Takiguchi wrote: > Hello Alan. > > Could you review the fix again ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8214533 > Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ > > I added IBM29626C charset as standard way. > Please give any suggestion and question. This looks okay, assuming it's `hg copy` of EUR_JP.template to create IBM29626C.java.template rather than a `hg mv` (the webrev makes it look like a move/rename). -Alan From linuxtardis at gmail.com Tue Jan 15 16:31:52 2019 From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=) Date: Tue, 15 Jan 2019 17:31:52 +0100 Subject: RFR(M)(round 2): 8215902: Add support for SoftFloat-3e library In-Reply-To: <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> Message-ID: Hi Magnus and Erik, I have added the link to the repository to README and I have removed the link to the mailing list thread. I have also recreated the GitHub repository. Now it is a fork of the mentioned repository with two extra commits containing README and the build scripts. New webrev URL: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.04/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 Regards, Jakub On 2019-01-15 at 15:05 +0100, Magnus Ihse Bursie wrote: > On 2018-12-25 16:19, Jakub Van?k wrote: > > Hi, > > > > please review this webrev. It is a successor of the softfloat-3 > > [patch] > > thread (first email > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html > > ) > > > > Changes since the last patch (v6): > > > > - renamed --with-softloat* to --with-sflt* (it is more compact and > > it > > corresponds to the old --with-sflt-lib=... option) > > > > - license is now obtained via --with-sflt-license switch (so it is > > not > > included in OpenJDK source tree) > > > > - updated documentation (slight rewording, added the license > > option) > > > > - checks for default --with/--without behavior are in place again > > (I forgot them when I changed the way the library is detected) > > > > - added a simple testcase - I found a disrepancy between softfloat > > and > > system function behavior. When a float with bits 0x003FFFFF is > > added to 0x00000001, the correct result is 0x00400000, but the > > default software floating point implementation returns > > 0x00000000. > > However I'm not sure where to put this test - now it is in > > test/hotspot/jtreg/compiler/floatingpoint. > > > > - comments in code refer to CR 6757269 and newly JDK-8215902 too. > > > > I have created a repository with SoftFloat-3e with build > > configuration > > specifically for OpenJDK on armel: > > https://github.com/ev3dev-lang-java/softfloat-openjdk > > > > I can add a link to it to the documentation. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 > > Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ > > Hi Jakub, > > In general this looks good. > > Some comments: > > I agree with Erik that you can add a link to your github project; > compiling SoftFloat is outside the scope of the OpenJDK build > instructions, but it can sure be helpful to lower the bar for users > wanting to do that. Just one question: any particular reason you > didn't > create your github repo by forking the official > https://github.com/ucb-bar/berkeley-softfloat-3? That way, it would > have > been easy for users to see that you were not adding any malicious or > suspicious code to the original SoftFloat distribution. > > On the other hand, I think the link to > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > is unnecessary and just creates clutter in the documentation. Please > remove it. > > /Magnus > > CI build: > > https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ > > > > Cheers, > > > > Jakub > > > > From erik.joelsson at oracle.com Tue Jan 15 17:09:49 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 15 Jan 2019 09:09:49 -0800 Subject: RFR: JDK-8216278: Fix devkit and basic Jib support on WSL In-Reply-To: <2398493e-7277-1dfb-337c-a41a0cdeb3a8@oracle.com> References: <84fa67ab-f1ee-1b07-fd93-5fda42f5d6a6@oracle.com> <2398493e-7277-1dfb-337c-a41a0cdeb3a8@oracle.com> Message-ID: <7bbcb1a2-f43c-c6f2-9cf4-9274027c2b83@oracle.com> I agree, though, they aren't quite the same, they convert in different directions. /Erik On 2019-01-15 05:18, Magnus Ihse Bursie wrote: > In the future, we should probably consider to make a support function > for those "convert a list of paths between windows and unix" blocks; I > think we have roughly the same code in say 5 or 6 locations now... > > /Magnus > > On 2019-01-09 19:14, Erik Joelsson wrote: >> The WSL support in the build does not currently work with devkits. >> This prevents us from using Jib to configure a WSL build. This patch >> fixes configure to work with devkits when building for Windows in WSL. >> >> (For Oracle users, I also managed to get Jib working in WSL, and able >> to configure both Windows and Linux profiles. Note that since Jib is >> not WSL aware itself, you need to manually direct the data dir to a >> location visible from Windows. e.g --with-data-dir >> /mnt/c/cygwin64/var/tmp/jib-$USER). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216278 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8216278/webrev.01/index.html >> >> /Erik >> > From alexandre.iline at oracle.com Tue Jan 15 17:13:35 2019 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 15 Jan 2019 09:13:35 -0800 Subject: RFR 8215729: Enhance makefiles to allow collecting code coverage with JCov In-Reply-To: References: <07165F0F-789D-45F3-8422-E2B0CFA80343@oracle.com> Message-ID: <604B88B4-82DC-45A4-912D-45FC85A40D7B@oracle.com> > On Jan 15, 2019, at 5:35 AM, Magnus Ihse Bursie wrote: > > Hi Shura, > > I see that this is pushed already, but I still have some questions and/or follow-up requests: > > 1) Do you expect the jcov-test-* targets to be used often? We've recently ran into problems with having too many top-level targets, and the large amount of targets generated for the jcov-test-* targets worries me. Before Christmas, I pushed a change which drastically cut down on the number of these auto-generated target names, and now this fix causes a partial regression on that front. To me, running jcov is such a special case, that the general solution using make jcov-test TEST="..." would suffice. I mainly added those for consistency originally, but I see a value in them. That is, when you want to collect code coverage, you want to do that for a particular set of tests. If I want to run tier1 tests with coverage, then, I would be more comfortable running make jcov-test-tier1 that make TEST=:tier1 run-test. That said, I do not think the targets will be used ?often?. Definitely much less often that the test-* counterparts. > > 2) I try hard to keep the doc/testing.md documentation relevant and up to date. Can you please write something in that document about what jcov-test does, and how to use it? Oh, sure. I will do that as a follow-on fix. > > 3) What is the reasoning for removing the > > 598 $1: run-test-$1 parse-test-$1 > 599 > 600 TARGETS += $1 > > construct? This is because jcov grabber needs to be started upfront: $(TARGETS): jcov-start-grabber Shura > This created a "meta" rule that included both running and parsing tests, for each test. I don't think it's used right now (otherwise testing would have broke), I think it's a sane abstraction to have, and in line with what we have elsewhere in the build system. > > /Magnus > > On 2019-01-08 19:35, Alexandre (Shura) Iline wrote: >> Hi, >> >> Could you please take a look on a change which allows to run tests while collecting code coverage with JCov. This is a continuation of work done in >> JDK-8214309: Enhance makefiles to allow generating JCov instrumented build. >> >> This adds make targets jcov-test and others like jcov-test-tier1 etc. After running the tests, one is left with a coverage report and also a data file containing coverage, for further analysis. >> >> Part of the changes are related to increasing maximum and initial heap size, which is needed to be done because instrumented classes are bigger in size. The way it is done for JTReg tests is by setting both _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variables. >> >> As it stands now, not all tests pass while running with code coverage, which pass normally. This particular enhancement is not addressing failing tests. The tests will need to be fixed separately if ever. For example, there are 35 tests which fail in open/test/jdk:jdk_core. A quick look tells that the majority of the failures are in tests which verify error output and discover an unexpected line "Picked up _JAVA_OPTIONS: -Xmx4g?. >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8215729 >> Webrev: http://cr.openjdk.java.net/~shurailine/8215729/webrev.01/ >> >> Shura > From fujie at loongson.cn Wed Jan 16 05:56:46 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 16 Jan 2019 13:56:46 +0800 Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> <3b6ebd28-c27c-823a-b3ab-85c55be1db76@oracle.com> Message-ID: Hi Magnus, Thanks a lot for your review and helpful comments. The patch[1] had been tested with Apache NetBeans IDE 9.0 (Build incubator-netbeans-release-334-on-20180708) on a Linux_64 (amd64) machine. I've noticed that all files under the specified root will be scanned automatically when the nb_project is opened in NetBeans. And all automatically generated files in build/**/gensrc can be found properly by NetBeans. I compared the configurations-old.xml (the original NB-config file) with configurations-new.xml (the new fully generated one after applying the patch). -------------------------------------------------------------------------- fool at fool-OptiPlex-7060:~$ grep build configurations-old.xml | grep gensrc | grep macosx -v | wc -l 44 fool at fool-OptiPlex-7060:~$ grep build configurations-new.xml | grep gensrc | grep macosx -v | wc -l 91 -------------------------------------------------------------------------- More items of build/**/gensrc in configurations-new.xml. -------------------------------------------------------------------------- fool at fool-OptiPlex-7060:~$ grep build configurations-old.xml | grep gensrc | grep x86 | grep macosx -v | wc -l 27 fool at fool-OptiPlex-7060:~$ grep build configurations-new.xml | grep gensrc | grep x86 | grep macosx -v | wc -l 91 -------------------------------------------------------------------------- More items of build/**/gensrc/**/*x86* in configurations-new.xml too. -------------------------------------------------------------------------- fool at fool-OptiPlex-7060:~$ grep x86_64 configurations-old.xml | grep macosx -v | grep build | wc -l 45 fool at fool-OptiPlex-7060:~$ grep x86_64 configurations-new.xml | grep macosx -v | grep build | wc -l 332 -------------------------------------------------------------------------- Also more items of build/**/*x86_64* in configurations-new.xml. It seems that the src-dependent part of the new config file which was generated automatically is more complete and reliable (without invalid items). And I guess most of the original config file was also automatically generated by NetBeans based on a relatively old version of OpenJDK. I'm very sorry that it's really difficult and probably uncomfortable to review such a huge patch. But it would be worth making the NB-config file independent of the source code. Compared with the original NB-config file, I couldn't find any loss of functionality with the new one. Could you please tell me what functionality will be lost? Thanks. [1] http://cr.openjdk.java.net/~aoqi/8215952/webrev.01/ Best regards, Jie On 2019/1/15 ??9:48, Magnus Ihse Bursie wrote: > On 2019-01-03 08:22, Fu Jie wrote: >> Thanks Alan for your review and valuable advice. >> >> I think it's worth keeping a NB project in the repo since it seems >> more convenient for IDE developers. >> And to keep configurations.xml current is also important. >> >> I made a patch to fix the issue mentioned by Alan. >> Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.01/ > > It looks much cleaner. I'm just worried, like Alan, that this actually > means a loss of functionality. Is NetBeans scanning all files under > the specified root, and will automatically find generated files in > build/**/gensrc? > > On the other hand, there are few NetBeans users left out there, and > you might very well represent a majority of them. :-) So if this works > for you, I'm OK with the change. Please just be ready to assist if > this breaks the usage for some other NB users. > > /Magnus From thomas.stuefe at gmail.com Wed Jan 16 08:49:08 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 16 Jan 2019 09:49:08 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: References: <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> <953ff1ff-3921-1888-44b8-f61018df904f@oracle.com> <18d0347f-b8cf-b384-fd47-f3f8b27f9ffd@oracle.com> <1f0ffff1-8ffa-02d5-57e0-925705329e02@oracle.com> Message-ID: Hi guys, Just wanted to know what the state is. Did you already add the support for WSL or is this still WIP? If it should work, is there a documentation somewhere I could follow? Thank you! Thomas On Sat, Dec 22, 2018 at 4:55 AM Andrew Luo < andrewluotechnologies at outlook.com> wrote: > Just wanted to update the thread with the issues we discovered with WSL > while adding support to the OpenJDK build system. I reported these issues > to the WSL team for all except for one of the bugs, which I'm still > investigating. > > GenerateCurrencyData.java - issue with Properties.load(System.in): > https://github.com/Microsoft/WSL/issues/3723 > Issue with directly calling cmd.exe to transform long path to short path: > https://github.com/Microsoft/WSL/issues/3724 > Calling from Linux to Win32 with untransformable Linux paths in a WSLENV > path environment variable causes extra output: > https://github.com/Microsoft/WSL/issues/3725 > Spp.java - still investigating this > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson > Sent: Thursday, December 20, 2018 1:51 AM > To: Andrew Luo ; Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> > Cc: build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for > Linux) on Windows > > I've updated and two builds in a row have now succeeded. I will keep > running, but it does seem likely that the new version has fixed the issue. > > /Erik > > On 2018-12-20 09:44, Erik Joelsson wrote: > > Hello, > > > > On 2018-12-19 19:40, Andrew Luo wrote: > >> Hi Erik, > >> > >> Which target are you using (make exploded-image?)? I never saw this > >> error while building on my machine (I've built about 10 times now, > >> I'm on Windows 10 1809 for what it's worth). Perhaps I can try to > >> reproduce this on my system as well... > > > > The target doesn't really matter that much, it's failing when building > > java modules, so exploded-image should reproduce it. I have built > > successfully as well, so this only happens intermittently. Here is the > > environment string from my system: > > > > WSL version Ubuntu 16.04.4 LTS #471-Microsoft Fri Dec 07 20:04:00 PST > > 2018 4.4.0-17134-Microsoft (on Windows build 10.0.17134.471) > > > > In System about, it identifies itself as Windows 10 Pro 1803, so that > > looks older than yours. I will see if I can update. > > > > I should also note that deleting build output is not necessary (and > > probably not affecting) success or failure on rebuild. From what I can > > see what happens is: make runs the find command to find all java > > source files and puts that list of files as prerequisites to the java > > compile rule, then when evaluating the rule, it sometimes fails to > > resolve a file. This would seem like a bug in the filesystem to me. > > > > /Erik > > > >> Thanks, > >> > >> -Andrew > >> > >> -----Original Message----- > >> From: Erik Joelsson > >> Sent: Wednesday, December 19, 2018 8:28 AM > >> To: Andrew Luo ; Magnus Ihse > >> Bursie > >> Cc: build-dev at openjdk.java.net > >> Subject: Re: [PATCH] Support for building using WSL (Windows > >> Subsystem for Linux) on Windows > >> > >> I'm now seeing intermittent build failures that look like this: > >> > >> make[3]: *** No rule to make target > >> '/mnt/d/erik/jdk-sandbox/open/src/java.security.jgss/share/classes/su > >> n/security/krb5/internal/TGSReq.java', > >> > >> needed by > >> > '/mnt/d/erik/jdk-sandbox/build/windows-x86_64-server-release/jdk/modules/java.security.jgss/_the.java.security.jgss_batch'. > > >> > >> Stop. > >> > >> The particular file that's missing varies, and deleting the output > >> dir for that module and rebuild works. The common pattern seems to be > >> upper case letters in the file name of the source file. > >> > >> I will investigate some more. > >> > >> /Erik > >> > >> On 2018-12-19 06:18, Erik Joelsson wrote: > >>> I can also report that on the Windows 10 machine I'm testing this > >>> on, "make bundles" on Cygwin took 12m56s and in WSL 8m39s, so a > >>> pretty big improvement! > >>> > >>> /Erik > >>> > >>> On 2018-12-19 03:45, Erik Joelsson wrote: > >>>> Hello, > >>>> > >>>> On 2018-12-19 00:19, Erik Joelsson wrote: > >>>>> Hello Andrew, > >>>>> > >>>>> On 2018-12-18 12:45, Andrew Luo wrote: > >>>>>> Hi Erik/Magnus, > >>>>>> > >>>>>> I've attached my latest changes: > >>>>>> > >>>>>> 1. Fixed a file I forgot to revert in my previous change while > >>>>>> trying something out... > >>>>>> 2. Added information about case sensitivity of the OpenJDK build > >>>>>> directory (yes, I did use the make target to generate the HTML > >>>>>> file) 3. Fixed Cygwin (hopefully, I don't have a Cygwin > >>>>>> environment to verify this) > >>>>> I will take this patch for a spin and see. > >>>>> > >>>> After applying a fix for > >>>> https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to > >>>> build everything as well. I pushed some minor adjustments to make > >>>> Cygwin work too. > >>>> > >>>> I will need to take this through more thorough testing. > >>>> > >>>> /Erik > >>>> > >>>>>> With this patch I've tested the following targets: > >>>>>> exploded-image (default): Works > >>>>>> images: Works > >>>>>> bundles: Works > >>>>>> test: Completes, but some tests fail. > >>>>>> > >>>>>> I didn't go through the test failures completely, but all of the > >>>>>> ones I did see are due to attempting to call CreateProcess with > >>>>>> "sh" as the argument (in jtreg: > >>>>>> > http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). > > >>>>>> > >>>>>> This isn't supported in Windows, perhaps using a Linux boot JDK > >>>>>> would fix this (but might break other things). I can look into > >>>>>> fixing it (on WSL you can call "wsl sh", for example), but I > >>>>>> think since it's a completely separate repo anyways, it would be > >>>>>> best to take up those changes separately. Let me know your > >>>>>> thoughts on this. > >>>>> Ah, if a Java process is launched from a Cygwin environment, it > >>>>> will have the unix/cygwin tools in the path so those can be > >>>>> launched directly. When running in WSL, it will launch the Windows > >>>>> binary java.exe in the Windows environment so there is no trace of > >>>>> WSL. I agree that we can look into this later, but we need to note > >>>>> that running tests is not completely supported in WSL. > >>>>> > >>>>> /Erik > >>>>> > >>>>>> Otherwise, let me know if there is any other comments/suggestions > >>>>>> before we can merge this into the main repository. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> -Andrew > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Erik Joelsson > >>>>>> Sent: Monday, December 17, 2018 9:52 AM > >>>>>> To: Andrew Luo ; Magnus Ihse > >>>>>> Bursie > >>>>>> Cc: build-dev at openjdk.java.net > >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows > >>>>>> Subsystem for Linux) on Windows > >>>>>> > >>>>>> Hello Andrew, > >>>>>> > >>>>>> On 2018-12-16 00:01, Andrew Luo wrote: > >>>>>>> For me, /mnt/c was already mounted case insensitive. Maybe this > >>>>>>> is only the default for the C:\ drive though (or perhaps depends > >>>>>>> on your Windows/WSL version?) > >>>>>> I think the default is "dir", which will cause any new directory > >>>>>> created from WSL to be case sensitive, so I would say this needs > >>>>>> to be documented in building.md. > >>>>>>> Anyways, I've synced down the sandbox and added a new patch to > >>>>>>> address some of the feedback (and some of my own minor > >>>>>>> enhancements): > >>>>>>> > >>>>>>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which > >>>>>>> had to move earlier in the sequence 2. Use $EXE_SUFFIX instead > >>>>>>> of .exe literal per Magnus' feedback 3. Added information about > >>>>>>> WSL versioning to build, similar to Cygwin 4. Updated > >>>>>>> building.md and building.html with WSL build instructions > >>>>>> Nice! I've applied and pushed this patch to the sandbox. Just to > >>>>>> be sure, did you generate the html version with pandoc using > >>>>>> "make update-build-docs"? If not, we will need to make sure that > >>>>>> is done before the final push. > >>>>>> > >>>>>> I noticed trailing whitespace in some files. Jcheck will reject > >>>>>> that in most types of files but in the build, we are a bit on our > >>>>>> own trying to avoid it. > >>>>>> > >>>>>>> (By the way, you misspelled my name in your sandbox commit): > >>>>>>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e > >>>>>> Terribly sorry about that! The combination of u and o is a common > >>>>>> slip for me on the keyboard. It's correct in the new commit at > >>>>>> least, and in the final commit, contributors are attributed with > >>>>>> email addresses. > >>>>>>> I will work on fixing the Cygwin path extraction in my next patch. > >>>>>>> Most likely I will just restore the old code for Cygwin while > >>>>>>> using the new code for WSL, unless there are other suggestions... > >>>>>>> Aside from this, is there any other feedback that I should take > >>>>>>> into account before we can merge this into the main repository? > >>>>>> That may be the best solution. > >>>>>> > >>>>>> I tried to build some more targets and failed. Please make sure > >>>>>> you can do "make bundles". That will build docs and tests in > >>>>>> addition to just the product and also do the packaging into > >>>>>> zip/tar.gz. It would also be nice if "make test" worked. > >>>>>> > >>>>>> Note that Magnus is now on vacation and I will be traveling, so > >>>>>> you will not hear from me until Wednesday. > >>>>>> > >>>>>> /Erik > >>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> -Andrew > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Erik Joelsson > >>>>>>> Sent: Friday, December 14, 2018 5:42 PM > >>>>>>> To: Andrew Luo ; Magnus Ihse > >>>>>>> Bursie > >>>>>>> Cc: build-dev at openjdk.java.net > >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows > >>>>>>> Subsystem for Linux) on Windows > >>>>>>> > >>>>>>> After having configured my WSL to mount using case=off, I was > >>>>>>> able to successfully build images using the latest patch as > >>>>>>> applied in the sandbox. > >>>>>>> > >>>>>>> /Erik > >>>>>>> > >>>>>>> On 2018-12-14 17:23, Erik Joelsson wrote: > >>>>>>>> Hello again, > >>>>>>>> > >>>>>>>> I took the liberty of creating a bug for this and also a > >>>>>>>> sandbox branch where I've applied your latest patch. If you > >>>>>>>> clone that you can send further patches based on a known state > >>>>>>>> in the sandbox. This will make it easier to see what you are > >>>>>>>> actually doing in each update, as well as give us better > >>>>>>>> references when discussing them. It also gives me the ability > >>>>>>>> to directly change things so we can keep Cygwin/msys working. > >>>>>>>> > >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8215445 > >>>>>>>> > >>>>>>>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e > >>>>>>>> > >>>>>>>> /Erik > >>>>>>>> > >>>>>>>> On 2018-12-14 16:47, Erik Joelsson wrote: > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> You beat me to it. I just found the rc.exe problem was that > >>>>>>>>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates > >>>>>>>>> quotes verbatim, so then fixpath.c would create a path > >>>>>>>>> variable like; > >>>>>>>>> > >>>>>>>>> $PATH;"$FIXPATH_PATH" > >>>>>>>>> > >>>>>>>>> Which is why link.exe could not find rc.exe. > >>>>>>>>> > >>>>>>>>> /Erik > >>>>>>>>> > >>>>>>>>> On 2018-12-14 16:32, Andrew Luo wrote: > >>>>>>>>>> Ok, here's my latest patch (I didn't add your case > >>>>>>>>>> sensitivity fix yet, but will do next patch). I believe this > >>>>>>>>>> should get you past the rc.exe issues. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> -Andrew > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Erik Joelsson > >>>>>>>>>> Sent: Friday, December 14, 2018 4:15 PM > >>>>>>>>>> To: Magnus Ihse Bursie > >>>>>>>>>> Cc: Andrew Luo ; > >>>>>>>>>> build-dev at openjdk.java.net > >>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows > >>>>>>>>>> Subsystem for Linux) on Windows > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: > >>>>>>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson > >>>>>>>>>>>> : > >>>>>>>>>>>> > >>>>>>>>>>>> I found the reason it's not failing make. It returns "1" > >>>>>>>>>>>> and NativeCompilation.gmk currently ignores 1 explicitly > >>>>>>>>>>>> for Visual Studio. I added that back in 2014 in > >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I > >>>>>>>>>>>> can't figure out why. Nothing mentioned in either comment or > review. > >>>>>>>>>>> Sounds like it's ripe for removal then. :) I wonder what > >>>>>>>>>>> kind of issue you might have run into that caused a returned > >>>>>>>>>>> 1 to happen and yet we didn't want to consider it a failure... > >>>>>>>>>> If I'm to guess, I think it's one of the commands we pipe the > >>>>>>>>>> output to when the output is zero. This would explain why it > >>>>>>>>>> was added together with pipefail. > >>>>>>>>>> > >>>>>>>>>> /Erik > >>>>>>>>>> > >>>>>>>>>>> /Magnus > >>>>>>>>>>> > >>>>>>>>>>>> /Erik > >>>>>>>>>>>> > >>>>>>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: > >>>>>>>>>>>>>> I get the same error for pch and it still continues, but > >>>>>>>>>>>>>> this time I let it run until it eventually fails for real > >>>>>>>>>>>>>> when it can't link. Perhaps it's simply cl.exe that isn't > >>>>>>>>>>>>>> returning non zero for this error? When the linker fails, > >>>>>>>>>>>>>> make fails, so propagation doesn't seem broken. > >>>>>>>>>>>>> That does also seem really weird, considering that it > >>>>>>>>>>>>> claims it to be a "fatal error". Can you repeat the > >>>>>>>>>>>>> command at the command line and get the failure again, and > >>>>>>>>>>>>> then check the return value? > >>>>>>>>>>>>> Can you rewrite the command line and run it from the > >>>>>>>>>>>>> devenv prompt? That is, is there any indication that the > >>>>>>>>>>>>> pch file itself is messed up, or can it be used if running > >>>>>>>>>>>>> the compilation that should use it from an "ok" prompt? > >>>>>>>>>>>>> > >>>>>>>>>>>>> /Magnus > >>>>>>>>>>>>>> /Erik > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: > >>>>>>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much > >>>>>>>>>>>>>>> later down the line... Still investigating... > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -Andrew > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: Andrew Luo > >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM > >>>>>>>>>>>>>>> To: 'Andrew Luo' ; > >>>>>>>>>>>>>>> Magnus Ihse Bursie ; Erik > >>>>>>>>>>>>>>> Joelsson > >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL > >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Try this updated patch with some fixes... > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -Andrew > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: build-dev On > >>>>>>>>>>>>>>> Behalf Of Andrew Luo > >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM > >>>>>>>>>>>>>>> To: Magnus Ihse Bursie ; > >>>>>>>>>>>>>>> Erik Joelsson > >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL > >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think I have a fix for it. Give me a minute (or a few > >>>>>>>>>>>>>>> hours depending on if it works). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -Andrew > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: Magnus Ihse Bursie > >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM > >>>>>>>>>>>>>>> To: Erik Joelsson > >>>>>>>>>>>>>>> Cc: Andrew Luo ; > >>>>>>>>>>>>>>> build-dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL > >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson > >>>>>>>>>>>>>>>> : > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: > >>>>>>>>>>>>>>>>>>>> Hello, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I took your patch for a spin, and configure passes, > >>>>>>>>>>>>>>>>>>>> but I get the same build error I got with my patch: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler > >>>>>>>>>>>>>>>>>>>> intermediate > >>>>>>>>>>>>>>>>>>>> file: > >>>>>>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-releas > >>>>>>>>>>>>>>>>>>>> e\ > >>>>>>>>>>>>>>>>>>>> hotsp > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> ot\ > >>>>>>>>>>>>>>>>>>>> varia > >>>>>>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such > >>>>>>>>>>>>>>>>>>>> file or directory > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I > >>>>>>>>>>>>>>>>>>>> see two issues here. First of all, I need to figure > >>>>>>>>>>>>>>>>>>>> out why the compiler will not find the file, which > >>>>>>>>>>>>>>>>>>>> is clearly there. > >>>>>>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? > >>>>>>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. > >>>>>>>>>>>>>>>>>>> Can you build without errors if you disable PCH? > >>>>>>>>>>>>>>>>> Could you? That is, is it only the PCH that is > >>>>>>>>>>>>>>>>> problematic? > >>>>>>>>>>>>>>>> Trying that now. > >>>>>>>>>>>>>>>>>>> Also, a wild guess: can it be related to file > >>>>>>>>>>>>>>>>>>> permissions? > >>>>>>>>>>>>>>>>>>> Can you read the file properly from both WSL and > >>>>>>>>>>>>>>>>>>> Windows? > >>>>>>>>>>>>>>>>>> It is readable, but it could be something with case. > >>>>>>>>>>>>>>>>>> The file is actually called BUILD_LIBJVM.pch, but > >>>>>>>>>>>>>>>>>> that is also how it's given to the compiler command > line. > >>>>>>>>>>>>>>>>>> Here is the output from DEBUG_FIXPATH: > >>>>>>>>>>>>>>>>> Weird. What if you, after a failed build, rename it to > >>>>>>>>>>>>>>>>> build_libjvm.pch? > >>>>>>>>>>>>>>>> Doing that causes a new error: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> cpp : fatal error C1382: the PCH file > >>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ho > >>>>>>>>>>>>>>>> ts > >>>>>>>>>>>>>>>> pot\v > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been > >>>>>>>>>>>>>>>> rebuilt since > >>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ho > >>>>>>>>>>>>>>>> ts > >>>>>>>>>>>>>>>> pot\v > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' > >>>>>>>>>>>>>>>> was generated. > >>>>>>>>>>>>>>>> Please rebuild this object > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> But I think even more important is that make is not > >>>>>>>>>>>>>>>> getting the error. The build just continues until > >>>>>>>>>>>>>>>> interrupted. > >>>>>>>>>>>>>>> Agree, that's bad. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Does fixpath_debug print exit code? If so, what does it > >>>>>>>>>>>>>>> say? If not, we should add that instrumentation. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> /Magnus > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath > >>>>>>>>>>>>>>>>>> input line > >>>>>>>>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-s > >>>>>>>>>>>>>>>>>>> up > >>>>>>>>>>>>>>>>>>> port\ > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> bin > >>>>>>>>>>>>>>>>>>> \fixp > >>>>>>>>>>>>>>>>>> ath.exe -w > >>>>>>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? > >>>>>>>>>>>>>>>> I agree, didn't look into that part. > >>>>>>>>>>>>>>>>>> > /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 270 > >>>>>>>>>>>>>>>>>> /bin/ > >>>>>>>>>>>>>>>>>> Hostx86/x64/cl.exe > >>>>>>>>>>>>>>>>> Also, FWIW, this seems not to have been properly case > >>>>>>>>>>>>>>>>> treated. Which version of the patch are you using? > >>>>>>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> /Erik > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> /Magnus > >>>>>>>>>>>>>>>>>> -showIncludes > >>>>>>>>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-re > >>>>>>>>>>>>>>>>>> le > >>>>>>>>>>>>>>>>>> ase/h > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch > >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS > >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP > >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 > >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT > >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows > >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 > >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP > >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP > >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 > >>>>>>>>>>>>>>>>>> -DCOMPILER2 > >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel > >>>>>>>>>>>>>>>>>> ea > >>>>>>>>>>>>>>>>>> se/ho > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> tsp > >>>>>>>>>>>>>>>>>> ot/va > >>>>>>>>>>>>>>>>>> riant-server/gensrc/adfiles > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows > >>>>>>>>>>>>>>>>>> _x > >>>>>>>>>>>>>>>>>> 86 > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel > >>>>>>>>>>>>>>>>>> ea > >>>>>>>>>>>>>>>>>> se/ho > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> tsp > >>>>>>>>>>>>>>>>>> ot/va > >>>>>>>>>>>>>>>>>> riant-server/gensrc > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompi > >>>>>>>>>>>>>>>>>> le d > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/inc > >>>>>>>>>>>>>>>>>> lu > >>>>>>>>>>>>>>>>>> de > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel > >>>>>>>>>>>>>>>>>> ea > >>>>>>>>>>>>>>>>>> se/su > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ppo > >>>>>>>>>>>>>>>>>> rt/mo > >>>>>>>>>>>>>>>>>> dules_include/java.base > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel > >>>>>>>>>>>>>>>>>> ea > >>>>>>>>>>>>>>>>>> se/su > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ppo > >>>>>>>>>>>>>>>>>> rt/mo > >>>>>>>>>>>>>>>>>> dules_include/java.base/win32 > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native > >>>>>>>>>>>>>>>>>> /l > >>>>>>>>>>>>>>>>>> ibjim > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> age > >>>>>>>>>>>>>>>>>> -Z7 > >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX > >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSV > >>>>>>>>>>>>>>>>>> C/ > >>>>>>>>>>>>>>>>>> 1416~ > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 1.2 > >>>>>>>>>>>>>>>>>> 70/at > >>>>>>>>>>>>>>>>>> lmfc/include > >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSV > >>>>>>>>>>>>>>>>>> C/ > >>>>>>>>>>>>>>>>>> 1416~ > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 1.2 > >>>>>>>>>>>>>>>>>> 70/in clude > >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt > >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shar > >>>>>>>>>>>>>>>>>> ed > >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um > >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winr > >>>>>>>>>>>>>>>>>> t > >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppw > >>>>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>> rt > >>>>>>>>>>>>>>>>>> -O2 > >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c > >>>>>>>>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-re > >>>>>>>>>>>>>>>>>> le > >>>>>>>>>>>>>>>>>> ase/h > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj > >>>>>>>>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea > >>>>>>>>>>>>>>>>>> se > >>>>>>>>>>>>>>>>>> /hots > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> pot /vari > >>>>>>>>>>>>>>>>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< > >>>>>>>>>>>>>>>>>> fixpath using wsl mode, with path list: > >>>>>>>>>>>>>>>>>> fixpath converted line > >>>>>>>>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/141 > >>>>>>>>>>>>>>>>>>> 6~ > >>>>>>>>>>>>>>>>>>> 1.270 > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> /bi > >>>>>>>>>>>>>>>>>>> n/Hos > >>>>>>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes > >>>>>>>>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-releas > >>>>>>>>>>>>>>>>>> e/ > >>>>>>>>>>>>>>>>>> hotsp > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch > >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS > >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP > >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 > >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT > >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows > >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 > >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP > >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP > >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 > >>>>>>>>>>>>>>>>>> -DCOMPILER2 > >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release > >>>>>>>>>>>>>>>>>> /h > >>>>>>>>>>>>>>>>>> otspo > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release > >>>>>>>>>>>>>>>>>> /h > >>>>>>>>>>>>>>>>>> otspo > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> t/v > >>>>>>>>>>>>>>>>>> arian t-server/gensrc > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release > >>>>>>>>>>>>>>>>>> /s > >>>>>>>>>>>>>>>>>> uppor > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> t/m > >>>>>>>>>>>>>>>>>> odule > >>>>>>>>>>>>>>>>>> s_include/java.base > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release > >>>>>>>>>>>>>>>>>> /s > >>>>>>>>>>>>>>>>>> uppor > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> t/m > >>>>>>>>>>>>>>>>>> odule > >>>>>>>>>>>>>>>>>> s_include/java.base/win32 > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/lib > >>>>>>>>>>>>>>>>>> ji > >>>>>>>>>>>>>>>>>> mage > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -Z7 > >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/14 > >>>>>>>>>>>>>>>>>> 16 > >>>>>>>>>>>>>>>>>> ~1.27 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 0/a > >>>>>>>>>>>>>>>>>> tlmfc > >>>>>>>>>>>>>>>>>> /include > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/14 > >>>>>>>>>>>>>>>>>> 16 > >>>>>>>>>>>>>>>>>> ~1.27 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 0/i nclud e > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt > >>>>>>>>>>>>>>>>>> -O2 > >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c > >>>>>>>>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-releas > >>>>>>>>>>>>>>>>>> e/ > >>>>>>>>>>>>>>>>>> hotsp > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj > >>>>>>>>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/h > >>>>>>>>>>>>>>>>>> ot > >>>>>>>>>>>>>>>>>> spot/ > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> var > >>>>>>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> An interesting note is that make is rebuilding the > >>>>>>>>>>>>>>>>>> pch file on every invocation so it too has trouble > >>>>>>>>>>>>>>>>>> finding the file. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> /Erik > From matthias.baesken at sap.com Wed Jan 16 09:26:09 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 16 Jan 2019 09:26:09 +0000 Subject: RFR [XS] 8217233: Update build settings for AIX/xlc Message-ID: Hello, please review this small fix . It adds stack protection compile flags for xlc/AIX . See : https://www.ibm.com/support/knowledgecenter/SSGH2K_12.1.0/com.ibm.xlc121.aix.doc/compiler_ref/opt_stackprotect.html "Provides protection against malicious code or programming errors that overwrite or corrupt the stack." The patch will set the stack protection flags . ( Similar changes have been done for Linux : 8199552: Update to build scripts https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8b060cdf0251 Introduced stack protection compile flags for Linux/gcc ( -fstack-protector ) . ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8217233 http://cr.openjdk.java.net/~mbaesken/webrevs/8217233.0/ Thanks, Matthias From GROEGES at uk.ibm.com Wed Jan 16 09:49:04 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 16 Jan 2019 09:49:04 +0000 Subject: RFR [XS] 8217233: Update build settings for AIX/xlc In-Reply-To: References: Message-ID: Hi Matthias, The change looks OK. The docs state: "This option is disabled by default because it can cause performance degradation." Do you know whether using this option actually causes any performance degradation on AIX? Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges 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: "Baesken, Matthias" To: "'build-dev at openjdk.java.net'" , "ppc-aix-port-dev at openjdk.java.net" Date: 16/01/2019 09:26 Subject: RFR [XS] 8217233: Update build settings for AIX/xlc Sent by: "ppc-aix-port-dev" Hello, please review this small fix . It adds stack protection compile flags for xlc/AIX . See : https://www.ibm.com/support/knowledgecenter/SSGH2K_12.1.0/com.ibm.xlc121.aix.doc/compiler_ref/opt_stackprotect.html "Provides protection against malicious code or programming errors that overwrite or corrupt the stack." The patch will set the stack protection flags . ( Similar changes have been done for Linux : 8199552: Update to build scripts https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8b060cdf0251 Introduced stack protection compile flags for Linux/gcc ( -fstack-protector ) . ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8217233 http://cr.openjdk.java.net/~mbaesken/webrevs/8217233.0/ Thanks, Matthias Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From matthias.baesken at sap.com Wed Jan 16 10:07:56 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 16 Jan 2019 10:07:56 +0000 Subject: RFR [XS] 8217233: Update build settings for AIX/xlc In-Reply-To: References: Message-ID: Hi Steve, from my experience the situation is similar to Linux (small performance change). Best regards, Matthias From: Steve Groeger Sent: Mittwoch, 16. Januar 2019 10:49 To: Baesken, Matthias Cc: 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; ppc-aix-port-dev Subject: Re: RFR [XS] 8217233: Update build settings for AIX/xlc Hi Matthias, The change looks OK. The docs state: "This option is disabled by default because it can cause performance degradation." Do you know whether using this option actually causes any performance degradation on AIX? Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges 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: "Baesken, Matthias" > To: "'build-dev at openjdk.java.net'" >, "ppc-aix-port-dev at openjdk.java.net" > Date: 16/01/2019 09:26 Subject: RFR [XS] 8217233: Update build settings for AIX/xlc Sent by: "ppc-aix-port-dev" > ________________________________ Hello, please review this small fix . It adds stack protection compile flags for xlc/AIX . See : https://www.ibm.com/support/knowledgecenter/SSGH2K_12.1.0/com.ibm.xlc121.aix.doc/compiler_ref/opt_stackprotect.html "Provides protection against malicious code or programming errors that overwrite or corrupt the stack." The patch will set the stack protection flags . ( Similar changes have been done for Linux : 8199552: Update to build scripts https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8b060cdf0251 Introduced stack protection compile flags for Linux/gcc ( -fstack-protector ) . ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8217233 http://cr.openjdk.java.net/~mbaesken/webrevs/8217233.0/ Thanks, Matthias 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 Wed Jan 16 16:41:39 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 Jan 2019 08:41:39 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: References: <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> <953ff1ff-3921-1888-44b8-f61018df904f@oracle.com> <18d0347f-b8cf-b384-fd47-f3f8b27f9ffd@oracle.com> <1f0ffff1-8ffa-02d5-57e0-925705329e02@oracle.com> Message-ID: Build support is in and you should be able to follow the documentation in doc/building.md. Test support is still waiting on a jtreg release and a patch to use it, but even with that, there are tests (at least shell tests) that will not work properly. /Erik On 2019-01-16 00:49, Thomas St?fe wrote: > Hi guys, > > Just wanted to know what the state is. Did you already add the support > for WSL or is this still WIP??If it should work, is there a > documentation somewhere I could follow? > > Thank you! > > Thomas > > > On Sat, Dec 22, 2018 at 4:55 AM Andrew Luo > > wrote: > > Just wanted to update the thread with the issues we discovered > with WSL while adding support to the OpenJDK build system.? I > reported these issues to the WSL team for all except for one of > the bugs, which I'm still investigating. > > GenerateCurrencyData.java - issue with Properties.load(System.in): > https://github.com/Microsoft/WSL/issues/3723 > Issue with directly calling cmd.exe to transform long path to > short path: https://github.com/Microsoft/WSL/issues/3724 > Calling from Linux to Win32 with untransformable Linux paths in a > WSLENV path environment variable causes extra output: > https://github.com/Microsoft/WSL/issues/3725 > Spp.java - still investigating this > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson > > Sent: Thursday, December 20, 2018 1:51 AM > To: Andrew Luo >; Magnus Ihse Bursie > > > Cc: build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows > Subsystem for Linux) on Windows > > I've updated and two builds in a row have now succeeded. I will > keep running, but it does seem likely that the new version has > fixed the issue. > > /Erik > > On 2018-12-20 09:44, Erik Joelsson wrote: > > Hello, > > > > On 2018-12-19 19:40, Andrew Luo wrote: > >> Hi Erik, > >> > >> Which target are you using (make exploded-image?)?? I never saw > this > >> error while building on my machine (I've built about 10 times now, > >> I'm on Windows 10 1809 for what it's worth).? Perhaps I can try to > >> reproduce this on my system as well... > > > > The target doesn't really matter that much, it's failing when > building > > java modules, so exploded-image should reproduce it. I have built > > successfully as well, so this only happens intermittently. Here > is the > > environment string from my system: > > > > WSL version Ubuntu 16.04.4 LTS #471-Microsoft Fri Dec 07 > 20:04:00 PST > > 2018 4.4.0-17134-Microsoft (on Windows build 10.0.17134.471) > > > > In System about, it identifies itself as Windows 10 Pro 1803, so > that > > looks older than yours. I will see if I can update. > > > > I should also note that deleting build output is not necessary (and > > probably not affecting) success or failure on rebuild. From what > I can > > see what happens is: make runs the find command to find all java > > source files and puts that list of files as prerequisites to the > java > > compile rule, then when evaluating the rule, it sometimes fails to > > resolve a file. This would seem like a bug in the filesystem to me. > > > > /Erik > > > >> Thanks, > >> > >> -Andrew > >> > >> -----Original Message----- > >> From: Erik Joelsson > > >> Sent: Wednesday, December 19, 2018 8:28 AM > >> To: Andrew Luo >; Magnus Ihse > >> Bursie > > >> Cc: build-dev at openjdk.java.net > >> Subject: Re: [PATCH] Support for building using WSL (Windows > >> Subsystem for Linux) on Windows > >> > >> I'm now seeing intermittent build failures that look like this: > >> > >> make[3]: *** No rule to make target > >> > '/mnt/d/erik/jdk-sandbox/open/src/java.security.jgss/share/classes/su > >> n/security/krb5/internal/TGSReq.java', > >> > >> needed by > >> > '/mnt/d/erik/jdk-sandbox/build/windows-x86_64-server-release/jdk/modules/java.security.jgss/_the.java.security.jgss_batch'. > > >> > >> Stop. > >> > >> The particular file that's missing varies, and deleting the output > >> dir for that module and rebuild works. The common pattern seems > to be > >> upper case letters in the file name of the source file. > >> > >> I will investigate some more. > >> > >> /Erik > >> > >> On 2018-12-19 06:18, Erik Joelsson wrote: > >>> I can also report that on the Windows 10 machine I'm testing this > >>> on, "make bundles" on Cygwin took 12m56s and in WSL 8m39s, so a > >>> pretty big improvement! > >>> > >>> /Erik > >>> > >>> On 2018-12-19 03:45, Erik Joelsson wrote: > >>>> Hello, > >>>> > >>>> On 2018-12-19 00:19, Erik Joelsson wrote: > >>>>> Hello Andrew, > >>>>> > >>>>> On 2018-12-18 12:45, Andrew Luo wrote: > >>>>>> Hi Erik/Magnus, > >>>>>> > >>>>>> I've attached my latest changes: > >>>>>> > >>>>>> 1. Fixed a file I forgot to revert in my previous change while > >>>>>> trying something out... > >>>>>> 2. Added information about case sensitivity of the OpenJDK > build > >>>>>> directory (yes, I did use the make target to generate the HTML > >>>>>> file) 3. Fixed Cygwin (hopefully, I don't have a Cygwin > >>>>>> environment to verify this) > >>>>> I will take this patch for a spin and see. > >>>>> > >>>> After applying a fix for > >>>> https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to > >>>> build everything as well. I pushed some minor adjustments to > make > >>>> Cygwin work too. > >>>> > >>>> I will need to take this through more thorough testing. > >>>> > >>>> /Erik > >>>> > >>>>>> With this patch I've tested the following targets: > >>>>>> exploded-image (default): Works > >>>>>> images: Works > >>>>>> bundles: Works > >>>>>> test: Completes, but some tests fail. > >>>>>> > >>>>>> I didn't go through the test failures completely, but all > of the > >>>>>> ones I did see are due to attempting to call CreateProcess > with > >>>>>> "sh" as the argument (in jtreg: > >>>>>> > http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). > > >>>>>> > >>>>>> This isn't supported in Windows, perhaps using a Linux boot > JDK > >>>>>> would fix this (but might break other things).? I can look > into > >>>>>> fixing it (on WSL you can call "wsl sh", for example), but I > >>>>>> think since it's a completely separate repo anyways, it > would be > >>>>>> best to take up those changes separately.? Let me know your > >>>>>> thoughts on this. > >>>>> Ah, if a Java process is launched from a Cygwin environment, it > >>>>> will have the unix/cygwin tools in the path so those can be > >>>>> launched directly. When running in WSL, it will launch the > Windows > >>>>> binary java.exe in the Windows environment so there is no > trace of > >>>>> WSL. I agree that we can look into this later, but we need > to note > >>>>> that running tests is not completely supported in WSL. > >>>>> > >>>>> /Erik > >>>>> > >>>>>> Otherwise, let me know if there is any other > comments/suggestions > >>>>>> before we can merge this into the main repository. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> -Andrew > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Erik Joelsson > > >>>>>> Sent: Monday, December 17, 2018 9:52 AM > >>>>>> To: Andrew Luo >; Magnus Ihse > >>>>>> Bursie > > >>>>>> Cc: build-dev at openjdk.java.net > > >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows > >>>>>> Subsystem for Linux) on Windows > >>>>>> > >>>>>> Hello Andrew, > >>>>>> > >>>>>> On 2018-12-16 00:01, Andrew Luo wrote: > >>>>>>> For me, /mnt/c was already mounted case insensitive.? > Maybe this > >>>>>>> is only the default for the C:\ drive though (or perhaps > depends > >>>>>>> on your Windows/WSL version?) > >>>>>> I think the default is "dir", which will cause any new > directory > >>>>>> created from WSL to be case sensitive, so I would say this > needs > >>>>>> to be documented in building.md. > >>>>>>> Anyways, I've synced down the sandbox and added a new > patch to > >>>>>>> address some of the feedback (and some of my own minor > >>>>>>> enhancements): > >>>>>>> > >>>>>>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which > >>>>>>> had to move earlier in the sequence 2. Use $EXE_SUFFIX > instead > >>>>>>> of .exe literal per Magnus' feedback 3. Added information > about > >>>>>>> WSL versioning to build, similar to Cygwin 4. Updated > >>>>>>> building.md and building.html with WSL build instructions > >>>>>> Nice! I've applied and pushed this patch to the sandbox. > Just to > >>>>>> be sure, did you generate the html version with pandoc using > >>>>>> "make update-build-docs"? If not, we will need to make sure > that > >>>>>> is done before the final push. > >>>>>> > >>>>>> I noticed trailing whitespace in some files. Jcheck will > reject > >>>>>> that in most types of files but in the build, we are a bit > on our > >>>>>> own trying to avoid it. > >>>>>> > >>>>>>> (By the way, you misspelled my name in your sandbox commit): > >>>>>>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e > >>>>>> Terribly sorry about that! The combination of u and o is a > common > >>>>>> slip for me on the keyboard. It's correct in the new commit at > >>>>>> least, and in the final commit, contributors are attributed > with > >>>>>> email addresses. > >>>>>>> I will work on fixing the Cygwin path extraction in my > next patch. > >>>>>>> Most likely I will just restore the old code for Cygwin while > >>>>>>> using the new code for WSL, unless there are other > suggestions... > >>>>>>> Aside from this, is there any other feedback that I should > take > >>>>>>> into account before we can merge this into the main > repository? > >>>>>> That may be the best solution. > >>>>>> > >>>>>> I tried to build some more targets and failed. Please make > sure > >>>>>> you can do "make bundles". That will build docs and tests in > >>>>>> addition to just the product and also do the packaging into > >>>>>> zip/tar.gz. It would also be nice if "make test" worked. > >>>>>> > >>>>>> Note that Magnus is now on vacation and I will be > traveling, so > >>>>>> you will not hear from me until Wednesday. > >>>>>> > >>>>>> /Erik > >>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> -Andrew > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Erik Joelsson > > >>>>>>> Sent: Friday, December 14, 2018 5:42 PM > >>>>>>> To: Andrew Luo >; Magnus Ihse > >>>>>>> Bursie > > >>>>>>> Cc: build-dev at openjdk.java.net > > >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows > >>>>>>> Subsystem for Linux) on Windows > >>>>>>> > >>>>>>> After having configured my WSL to mount using case=off, I was > >>>>>>> able to successfully build images using the latest patch as > >>>>>>> applied in the sandbox. > >>>>>>> > >>>>>>> /Erik > >>>>>>> > >>>>>>> On 2018-12-14 17:23, Erik Joelsson wrote: > >>>>>>>> Hello again, > >>>>>>>> > >>>>>>>> I took the liberty of creating a bug for this and also a > >>>>>>>> sandbox branch where I've applied your latest patch. If you > >>>>>>>> clone that you can send further patches based on a known > state > >>>>>>>> in the sandbox. This will make it easier to see what you are > >>>>>>>> actually doing in each update, as well as give us better > >>>>>>>> references when discussing them. It also gives me the > ability > >>>>>>>> to directly change things so we can keep Cygwin/msys working. > >>>>>>>> > >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8215445 > >>>>>>>> > >>>>>>>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e > >>>>>>>> > >>>>>>>> /Erik > >>>>>>>> > >>>>>>>> On 2018-12-14 16:47, Erik Joelsson wrote: > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> You beat me to it. I just found the rc.exe problem was that > >>>>>>>>> FIXPATH_PATH in spec.gmk.in was > quoted. Make just propagates > >>>>>>>>> quotes verbatim, so then fixpath.c would create a path > >>>>>>>>> variable like; > >>>>>>>>> > >>>>>>>>> $PATH;"$FIXPATH_PATH" > >>>>>>>>> > >>>>>>>>> Which is why link.exe could not find rc.exe. > >>>>>>>>> > >>>>>>>>> /Erik > >>>>>>>>> > >>>>>>>>> On 2018-12-14 16:32, Andrew Luo wrote: > >>>>>>>>>> Ok, here's my latest patch (I didn't add your case > >>>>>>>>>> sensitivity fix yet, but will do next patch).? I > believe this > >>>>>>>>>> should get you past the rc.exe issues. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> -Andrew > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Erik Joelsson > > >>>>>>>>>> Sent: Friday, December 14, 2018 4:15 PM > >>>>>>>>>> To: Magnus Ihse Bursie > > >>>>>>>>>> Cc: Andrew Luo >; > >>>>>>>>>> build-dev at openjdk.java.net > > >>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL > (Windows > >>>>>>>>>> Subsystem for Linux) on Windows > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: > >>>>>>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson > >>>>>>>>>>>> >: > >>>>>>>>>>>> > >>>>>>>>>>>> I found the reason it's not failing make. It returns "1" > >>>>>>>>>>>> and NativeCompilation.gmk currently ignores 1 explicitly > >>>>>>>>>>>> for Visual Studio. I added that back in 2014 in > >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I > >>>>>>>>>>>> can't figure out why. Nothing mentioned in either > comment or review. > >>>>>>>>>>> Sounds like it's ripe for removal then. :) I wonder what > >>>>>>>>>>> kind of issue you might have run into that caused a > returned > >>>>>>>>>>> 1 to happen and yet we didn't want to consider it a > failure... > >>>>>>>>>> If I'm to guess, I think it's one of the commands we > pipe the > >>>>>>>>>> output to when the output is zero. This would explain > why it > >>>>>>>>>> was added together with pipefail. > >>>>>>>>>> > >>>>>>>>>> /Erik > >>>>>>>>>> > >>>>>>>>>>> /Magnus > >>>>>>>>>>> > >>>>>>>>>>>> /Erik > >>>>>>>>>>>> > >>>>>>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: > >>>>>>>>>>>>>> I get the same error for pch and it still > continues, but > >>>>>>>>>>>>>> this time I let it run until it eventually fails > for real > >>>>>>>>>>>>>> when it can't link. Perhaps it's simply cl.exe that > isn't > >>>>>>>>>>>>>> returning non zero for this error? When the linker > fails, > >>>>>>>>>>>>>> make fails, so propagation doesn't seem broken. > >>>>>>>>>>>>> That does also seem really weird, considering that it > >>>>>>>>>>>>> claims it to be a "fatal error". Can you repeat the > >>>>>>>>>>>>> command at the command line and get the failure > again, and > >>>>>>>>>>>>> then check the return value? > >>>>>>>>>>>>> Can you rewrite the command line and run it from the > >>>>>>>>>>>>> devenv prompt? That is, is there any indication that > the > >>>>>>>>>>>>> pch file itself is messed up, or can it be used if > running > >>>>>>>>>>>>> the compilation that should use it from an "ok" prompt? > >>>>>>>>>>>>> > >>>>>>>>>>>>> /Magnus > >>>>>>>>>>>>>> /Erik > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: > >>>>>>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is > much > >>>>>>>>>>>>>>> later down the line... Still investigating... > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -Andrew > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: Andrew Luo > >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM > >>>>>>>>>>>>>>> To: 'Andrew Luo' > >; > >>>>>>>>>>>>>>> Magnus Ihse Bursie >; Erik > >>>>>>>>>>>>>>> Joelsson > > >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net > > >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL > >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Try this updated patch with some fixes... > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -Andrew > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: build-dev > > On > >>>>>>>>>>>>>>> Behalf Of Andrew Luo > >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM > >>>>>>>>>>>>>>> To: Magnus Ihse Bursie > >; > >>>>>>>>>>>>>>> Erik Joelsson > > >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net > > >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL > >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think I have a fix for it.? Give me a minute (or > a few > >>>>>>>>>>>>>>> hours depending on if it works). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -Andrew > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: Magnus Ihse Bursie > > > >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM > >>>>>>>>>>>>>>> To: Erik Joelsson > > >>>>>>>>>>>>>>> Cc: Andrew Luo >; > >>>>>>>>>>>>>>> build-dev at openjdk.java.net > > >>>>>>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL > >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson > >>>>>>>>>>>>>>>> >: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: > >>>>>>>>>>>>>>>>>>>> Hello, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I took your patch for a spin, and configure > passes, > >>>>>>>>>>>>>>>>>>>> but I get the same build error I got with my > patch: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler > >>>>>>>>>>>>>>>>>>>> intermediate > >>>>>>>>>>>>>>>>>>>> file: > >>>>>>>>>>>>>>>>>>>> > 'd:\erik\jdk-wsl\build\windows-x86_64-server-releas > >>>>>>>>>>>>>>>>>>>> e\ > >>>>>>>>>>>>>>>>>>>> hotsp > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> ot\ > >>>>>>>>>>>>>>>>>>>> varia > >>>>>>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such > >>>>>>>>>>>>>>>>>>>> file or directory > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> This is repeated for every C++ file in > Hotspot. I > >>>>>>>>>>>>>>>>>>>> see two issues here. First of all, I need to > figure > >>>>>>>>>>>>>>>>>>>> out why the compiler will not find the file, > which > >>>>>>>>>>>>>>>>>>>> is clearly there. > >>>>>>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? > >>>>>>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is > disappearing. > >>>>>>>>>>>>>>>>>>> Can you build without errors if you disable PCH? > >>>>>>>>>>>>>>>>> Could you? That is, is it only the PCH that is > >>>>>>>>>>>>>>>>> problematic? > >>>>>>>>>>>>>>>> Trying that now. > >>>>>>>>>>>>>>>>>>> Also, a wild guess: can it be related to file > >>>>>>>>>>>>>>>>>>> permissions? > >>>>>>>>>>>>>>>>>>> Can you read the file properly from both WSL and > >>>>>>>>>>>>>>>>>>> Windows? > >>>>>>>>>>>>>>>>>> It is readable, but it could be something with > case. > >>>>>>>>>>>>>>>>>> The file is actually called BUILD_LIBJVM.pch, but > >>>>>>>>>>>>>>>>>> that is also how it's given to the compiler > command line. > >>>>>>>>>>>>>>>>>> Here is the output from DEBUG_FIXPATH: > >>>>>>>>>>>>>>>>> Weird. What if you, after a failed build, rename > it to > >>>>>>>>>>>>>>>>> build_libjvm.pch? > >>>>>>>>>>>>>>>> Doing that causes a new error: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. > > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> cpp : fatal error C1382: the PCH file > >>>>>>>>>>>>>>>> > 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ho > >>>>>>>>>>>>>>>> ts > >>>>>>>>>>>>>>>> pot\v > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has > been > >>>>>>>>>>>>>>>> rebuilt since > >>>>>>>>>>>>>>>> > 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ho > >>>>>>>>>>>>>>>> ts > >>>>>>>>>>>>>>>> pot\v > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> ari ant-s > erver\libjvm\objs\accessBarrierSupport.obj' > >>>>>>>>>>>>>>>> was generated. > >>>>>>>>>>>>>>>> Please rebuild this object > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> But I think even more important is that make is not > >>>>>>>>>>>>>>>> getting the error. The build just continues until > >>>>>>>>>>>>>>>> interrupted. > >>>>>>>>>>>>>>> Agree, that's bad. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Does fixpath_debug print exit code? If so, what > does it > >>>>>>>>>>>>>>> say? If not, we should add that instrumentation. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> /Magnus > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath > >>>>>>>>>>>>>>>>>> input line > >>>>>>>>>>>>>>>>>>> > -wsl\build\windows-x86_64-server-release\configure-s > >>>>>>>>>>>>>>>>>>> up > >>>>>>>>>>>>>>>>>>> port\ > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> bin > >>>>>>>>>>>>>>>>>>> \fixp > >>>>>>>>>>>>>>>>>> ath.exe -w > >>>>>>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? > >>>>>>>>>>>>>>>> I agree, didn't look into that part. > >>>>>>>>>>>>>>>>>> > /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 270 > >>>>>>>>>>>>>>>>>> /bin/ > >>>>>>>>>>>>>>>>>> Hostx86/x64/cl.exe > >>>>>>>>>>>>>>>>> Also, FWIW, this seems not to have been properly > case > >>>>>>>>>>>>>>>>> treated. Which version of the patch are you using? > >>>>>>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> /Erik > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> /Magnus > >>>>>>>>>>>>>>>>>> -showIncludes > >>>>>>>>>>>>>>>>>> > -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-re > >>>>>>>>>>>>>>>>>> le > >>>>>>>>>>>>>>>>>> ase/h > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ots pot/v > ariant-server/libjvm/objs/BUILD_LIBJVM.pch > >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS > >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP > >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 > >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT > >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows > >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 > >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP > >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP > >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 > >>>>>>>>>>>>>>>>>> -DCOMPILER2 > >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 > >>>>>>>>>>>>>>>>>> > -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel > >>>>>>>>>>>>>>>>>> ea > >>>>>>>>>>>>>>>>>> se/ho > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> tsp > >>>>>>>>>>>>>>>>>> ot/va > >>>>>>>>>>>>>>>>>> riant-server/gensrc/adfiles > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows > >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 > >>>>>>>>>>>>>>>>>> > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows > >>>>>>>>>>>>>>>>>> _x > >>>>>>>>>>>>>>>>>> 86 > >>>>>>>>>>>>>>>>>> > -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel > >>>>>>>>>>>>>>>>>> ea > >>>>>>>>>>>>>>>>>> se/ho > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> tsp > >>>>>>>>>>>>>>>>>> ot/va > >>>>>>>>>>>>>>>>>> riant-server/gensrc > >>>>>>>>>>>>>>>>>> > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompi > >>>>>>>>>>>>>>>>>> le d > >>>>>>>>>>>>>>>>>> > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include > >>>>>>>>>>>>>>>>>> > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/inc > >>>>>>>>>>>>>>>>>> lu > >>>>>>>>>>>>>>>>>> de > >>>>>>>>>>>>>>>>>> > -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel > >>>>>>>>>>>>>>>>>> ea > >>>>>>>>>>>>>>>>>> se/su > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ppo > >>>>>>>>>>>>>>>>>> rt/mo > >>>>>>>>>>>>>>>>>> dules_include/java.base > >>>>>>>>>>>>>>>>>> > -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel > >>>>>>>>>>>>>>>>>> ea > >>>>>>>>>>>>>>>>>> se/su > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ppo > >>>>>>>>>>>>>>>>>> rt/mo > >>>>>>>>>>>>>>>>>> dules_include/java.base/win32 > >>>>>>>>>>>>>>>>>> > -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native > >>>>>>>>>>>>>>>>>> /l > >>>>>>>>>>>>>>>>>> ibjim > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> age > >>>>>>>>>>>>>>>>>> -Z7 > >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX > >>>>>>>>>>>>>>>>>> > -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSV > >>>>>>>>>>>>>>>>>> C/ > >>>>>>>>>>>>>>>>>> 1416~ > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 1.2 > >>>>>>>>>>>>>>>>>> 70/at > >>>>>>>>>>>>>>>>>> lmfc/include > >>>>>>>>>>>>>>>>>> > -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSV > >>>>>>>>>>>>>>>>>> C/ > >>>>>>>>>>>>>>>>>> 1416~ > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 1.2 > >>>>>>>>>>>>>>>>>> 70/in clude > >>>>>>>>>>>>>>>>>> > -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt > >>>>>>>>>>>>>>>>>> > -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shar > >>>>>>>>>>>>>>>>>> ed > >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um > >>>>>>>>>>>>>>>>>> > -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winr > >>>>>>>>>>>>>>>>>> t > >>>>>>>>>>>>>>>>>> > -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppw > >>>>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>> rt > >>>>>>>>>>>>>>>>>> -O2 > >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c > >>>>>>>>>>>>>>>>>> > -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-re > >>>>>>>>>>>>>>>>>> le > >>>>>>>>>>>>>>>>>> ase/h > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ots pot/v > ariant-server/libjvm/objs/ad_x86_expand.obj > >>>>>>>>>>>>>>>>>> > /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea > >>>>>>>>>>>>>>>>>> se > >>>>>>>>>>>>>>>>>> /hots > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> pot /vari > >>>>>>>>>>>>>>>>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< > >>>>>>>>>>>>>>>>>> fixpath using wsl mode, with path list: > >>>>>>>>>>>>>>>>>> fixpath converted line > >>>>>>>>>>>>>>>>>>> > c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/141 > >>>>>>>>>>>>>>>>>>> 6~ > >>>>>>>>>>>>>>>>>>> 1.270 > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> /bi > >>>>>>>>>>>>>>>>>>> n/Hos > >>>>>>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes > >>>>>>>>>>>>>>>>>> > -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-releas > >>>>>>>>>>>>>>>>>> e/ > >>>>>>>>>>>>>>>>>> hotsp > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch > >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS > >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP > >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 > >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT > >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows > >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 > >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP > >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP > >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 > >>>>>>>>>>>>>>>>>> -DCOMPILER2 > >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 > >>>>>>>>>>>>>>>>>> > -Id:/erik/jdk-wsl/build/windows-x86_64-server-release > >>>>>>>>>>>>>>>>>> /h > >>>>>>>>>>>>>>>>>> otspo > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 > >>>>>>>>>>>>>>>>>> > -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 > >>>>>>>>>>>>>>>>>> > -Id:/erik/jdk-wsl/build/windows-x86_64-server-release > >>>>>>>>>>>>>>>>>> /h > >>>>>>>>>>>>>>>>>> otspo > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> t/v > >>>>>>>>>>>>>>>>>> arian t-server/gensrc > >>>>>>>>>>>>>>>>>> > -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled > >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include > >>>>>>>>>>>>>>>>>> > -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include > >>>>>>>>>>>>>>>>>> > -Id:/erik/jdk-wsl/build/windows-x86_64-server-release > >>>>>>>>>>>>>>>>>> /s > >>>>>>>>>>>>>>>>>> uppor > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> t/m > >>>>>>>>>>>>>>>>>> odule > >>>>>>>>>>>>>>>>>> s_include/java.base > >>>>>>>>>>>>>>>>>> > -Id:/erik/jdk-wsl/build/windows-x86_64-server-release > >>>>>>>>>>>>>>>>>> /s > >>>>>>>>>>>>>>>>>> uppor > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> t/m > >>>>>>>>>>>>>>>>>> odule > >>>>>>>>>>>>>>>>>> s_include/java.base/win32 > >>>>>>>>>>>>>>>>>> > -Id:/erik/jdk-wsl/open/src/java.base/share/native/lib > >>>>>>>>>>>>>>>>>> ji > >>>>>>>>>>>>>>>>>> mage > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -Z7 > >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX > >>>>>>>>>>>>>>>>>> > -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/14 > >>>>>>>>>>>>>>>>>> 16 > >>>>>>>>>>>>>>>>>> ~1.27 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 0/a > >>>>>>>>>>>>>>>>>> tlmfc > >>>>>>>>>>>>>>>>>> /include > >>>>>>>>>>>>>>>>>> > -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/14 > >>>>>>>>>>>>>>>>>> 16 > >>>>>>>>>>>>>>>>>> ~1.27 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 0/i nclud e > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um > >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt > >>>>>>>>>>>>>>>>>> > -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt > >>>>>>>>>>>>>>>>>> -O2 > >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c > >>>>>>>>>>>>>>>>>> > -Fod:/erik/jdk-wsl/build/windows-x86_64-server-releas > >>>>>>>>>>>>>>>>>> e/ > >>>>>>>>>>>>>>>>>> hotsp > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj > >>>>>>>>>>>>>>>>>> > d:/erik/jdk-wsl/build/windows-x86_64-server-release/h > >>>>>>>>>>>>>>>>>> ot > >>>>>>>>>>>>>>>>>> spot/ > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> var > >>>>>>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> An interesting note is that make is rebuilding the > >>>>>>>>>>>>>>>>>> pch file on every invocation so it too has trouble > >>>>>>>>>>>>>>>>>> finding the file. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> /Erik > From jonathan.gibbons at oracle.com Wed Jan 16 17:47:55 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Jan 2019 09:47:55 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: References: <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> <953ff1ff-3921-1888-44b8-f61018df904f@oracle.com> <18d0347f-b8cf-b384-fd47-f3f8b27f9ffd@oracle.com> <1f0ffff1-8ffa-02d5-57e0-925705329e02@oracle.com> Message-ID: <6ff09785-becf-57fe-d799-f67b4c4f0abb@oracle.com> Erik, I can push/promote what we have so far for jtreg, but it would be good to decide what (if anything) we are going to do with the shell tests. -- Jon On 1/16/19 8:41 AM, Erik Joelsson wrote: > Build support is in and you should be able to follow the documentation > in doc/building.md. Test support is still waiting on a jtreg release > and a patch to use it, but even with that, there are tests (at least > shell tests) that will not work properly. > > /Erik > > On 2019-01-16 00:49, Thomas St?fe wrote: >> Hi guys, >> >> Just wanted to know what the state is. Did you already add the >> support for WSL or is this still WIP??If it should work, is there a >> documentation somewhere I could follow? >> >> Thank you! >> >> Thomas >> >> >> On Sat, Dec 22, 2018 at 4:55 AM Andrew Luo >> > > wrote: >> >> ??? Just wanted to update the thread with the issues we discovered >> ??? with WSL while adding support to the OpenJDK build system. I >> ??? reported these issues to the WSL team for all except for one of >> ??? the bugs, which I'm still investigating. >> >> ??? GenerateCurrencyData.java - issue with Properties.load(System.in): >> ??? https://github.com/Microsoft/WSL/issues/3723 >> ??? Issue with directly calling cmd.exe to transform long path to >> ??? short path: https://github.com/Microsoft/WSL/issues/3724 >> ??? Calling from Linux to Win32 with untransformable Linux paths in a >> ??? WSLENV path environment variable causes extra output: >> ??? https://github.com/Microsoft/WSL/issues/3725 >> ??? Spp.java - still investigating this >> >> ??? Thanks, >> >> ??? -Andrew >> >> ??? -----Original Message----- >> ??? From: Erik Joelsson > ??? > >> ??? Sent: Thursday, December 20, 2018 1:51 AM >> ??? To: Andrew Luo > ??? >; Magnus Ihse Bursie >> ??? > > >> ??? Cc: build-dev at openjdk.java.net >> ??? Subject: Re: [PATCH] Support for building using WSL (Windows >> ??? Subsystem for Linux) on Windows >> >> ??? I've updated and two builds in a row have now succeeded. I will >> ??? keep running, but it does seem likely that the new version has >> ??? fixed the issue. >> >> ??? /Erik >> >> ??? On 2018-12-20 09:44, Erik Joelsson wrote: >> ??? > Hello, >> ??? > >> ??? > On 2018-12-19 19:40, Andrew Luo wrote: >> ??? >> Hi Erik, >> ??? >> >> ??? >> Which target are you using (make exploded-image?)? I never saw >> ??? this >> ??? >> error while building on my machine (I've built about 10 times >> now, >> ??? >> I'm on Windows 10 1809 for what it's worth). Perhaps I can try to >> ??? >> reproduce this on my system as well... >> ??? > >> ??? > The target doesn't really matter that much, it's failing when >> ??? building >> ??? > java modules, so exploded-image should reproduce it. I have built >> ??? > successfully as well, so this only happens intermittently. Here >> ??? is the >> ??? > environment string from my system: >> ??? > >> ??? > WSL version Ubuntu 16.04.4 LTS #471-Microsoft Fri Dec 07 >> ??? 20:04:00 PST >> ??? > 2018 4.4.0-17134-Microsoft (on Windows build 10.0.17134.471) >> ??? > >> ??? > In System about, it identifies itself as Windows 10 Pro 1803, so >> ??? that >> ??? > looks older than yours. I will see if I can update. >> ??? > >> ??? > I should also note that deleting build output is not necessary >> (and >> ??? > probably not affecting) success or failure on rebuild. From what >> ??? I can >> ??? > see what happens is: make runs the find command to find all java >> ??? > source files and puts that list of files as prerequisites to the >> ??? java >> ??? > compile rule, then when evaluating the rule, it sometimes fails to >> ??? > resolve a file. This would seem like a bug in the filesystem to >> me. >> ??? > >> ??? > /Erik >> ??? > >> ??? >> Thanks, >> ??? >> >> ??? >> -Andrew >> ??? >> >> ??? >> -----Original Message----- >> ??? >> From: Erik Joelsson > ??? > >> ??? >> Sent: Wednesday, December 19, 2018 8:28 AM >> ??? >> To: Andrew Luo > ??? >; Magnus Ihse >> ??? >> Bursie > ??? > >> ??? >> Cc: build-dev at openjdk.java.net >> >> ??? >> Subject: Re: [PATCH] Support for building using WSL (Windows >> ??? >> Subsystem for Linux) on Windows >> ??? >> >> ??? >> I'm now seeing intermittent build failures that look like this: >> ??? >> >> ??? >> make[3]: *** No rule to make target >> ??? >> >> '/mnt/d/erik/jdk-sandbox/open/src/java.security.jgss/share/classes/su >> ??? >> n/security/krb5/internal/TGSReq.java', >> ??? >> >> ??? >> needed by >> ??? >> >> '/mnt/d/erik/jdk-sandbox/build/windows-x86_64-server-release/jdk/modules/java.security.jgss/_the.java.security.jgss_batch'. >> >> ??? >> >> ??? >> Stop. >> ??? >> >> ??? >> The particular file that's missing varies, and deleting the >> output >> ??? >> dir for that module and rebuild works. The common pattern seems >> ??? to be >> ??? >> upper case letters in the file name of the source file. >> ??? >> >> ??? >> I will investigate some more. >> ??? >> >> ??? >> /Erik >> ??? >> >> ??? >> On 2018-12-19 06:18, Erik Joelsson wrote: >> ??? >>> I can also report that on the Windows 10 machine I'm testing >> this >> ??? >>> on, "make bundles" on Cygwin took 12m56s and in WSL 8m39s, so a >> ??? >>> pretty big improvement! >> ??? >>> >> ??? >>> /Erik >> ??? >>> >> ??? >>> On 2018-12-19 03:45, Erik Joelsson wrote: >> ??? >>>> Hello, >> ??? >>>> >> ??? >>>> On 2018-12-19 00:19, Erik Joelsson wrote: >> ??? >>>>> Hello Andrew, >> ??? >>>>> >> ??? >>>>> On 2018-12-18 12:45, Andrew Luo wrote: >> ??? >>>>>> Hi Erik/Magnus, >> ??? >>>>>> >> ??? >>>>>> I've attached my latest changes: >> ??? >>>>>> >> ??? >>>>>> 1. Fixed a file I forgot to revert in my previous change >> while >> ??? >>>>>> trying something out... >> ??? >>>>>> 2. Added information about case sensitivity of the OpenJDK >> ??? build >> ??? >>>>>> directory (yes, I did use the make target to generate the >> HTML >> ??? >>>>>> file) 3. Fixed Cygwin (hopefully, I don't have a Cygwin >> ??? >>>>>> environment to verify this) >> ??? >>>>> I will take this patch for a spin and see. >> ??? >>>>> >> ??? >>>> After applying a fix for >> ??? >>>> https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to >> ??? >>>> build everything as well. I pushed some minor adjustments to >> ??? make >> ??? >>>> Cygwin work too. >> ??? >>>> >> ??? >>>> I will need to take this through more thorough testing. >> ??? >>>> >> ??? >>>> /Erik >> ??? >>>> >> ??? >>>>>> With this patch I've tested the following targets: >> ??? >>>>>> exploded-image (default): Works >> ??? >>>>>> images: Works >> ??? >>>>>> bundles: Works >> ??? >>>>>> test: Completes, but some tests fail. >> ??? >>>>>> >> ??? >>>>>> I didn't go through the test failures completely, but all >> ??? of the >> ??? >>>>>> ones I did see are due to attempting to call CreateProcess >> ??? with >> ??? >>>>>> "sh" as the argument (in jtreg: >> ??? >>>>>> >> http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). >> >> ??? >>>>>> >> ??? >>>>>> This isn't supported in Windows, perhaps using a Linux boot >> ??? JDK >> ??? >>>>>> would fix this (but might break other things).? I can look >> ??? into >> ??? >>>>>> fixing it (on WSL you can call "wsl sh", for example), but I >> ??? >>>>>> think since it's a completely separate repo anyways, it >> ??? would be >> ??? >>>>>> best to take up those changes separately.? Let me know your >> ??? >>>>>> thoughts on this. >> ??? >>>>> Ah, if a Java process is launched from a Cygwin >> environment, it >> ??? >>>>> will have the unix/cygwin tools in the path so those can be >> ??? >>>>> launched directly. When running in WSL, it will launch the >> ??? Windows >> ??? >>>>> binary java.exe in the Windows environment so there is no >> ??? trace of >> ??? >>>>> WSL. I agree that we can look into this later, but we need >> ??? to note >> ??? >>>>> that running tests is not completely supported in WSL. >> ??? >>>>> >> ??? >>>>> /Erik >> ??? >>>>> >> ??? >>>>>> Otherwise, let me know if there is any other >> ??? comments/suggestions >> ??? >>>>>> before we can merge this into the main repository. >> ??? >>>>>> >> ??? >>>>>> Thanks, >> ??? >>>>>> >> ??? >>>>>> -Andrew >> ??? >>>>>> >> ??? >>>>>> -----Original Message----- >> ??? >>>>>> From: Erik Joelsson > ??? > >> ??? >>>>>> Sent: Monday, December 17, 2018 9:52 AM >> ??? >>>>>> To: Andrew Luo > ??? >; Magnus Ihse >> ??? >>>>>> Bursie > ??? > >> ??? >>>>>> Cc: build-dev at openjdk.java.net >> ??? >> ??? >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >> ??? >>>>>> Subsystem for Linux) on Windows >> ??? >>>>>> >> ??? >>>>>> Hello Andrew, >> ??? >>>>>> >> ??? >>>>>> On 2018-12-16 00:01, Andrew Luo wrote: >> ??? >>>>>>> For me, /mnt/c was already mounted case insensitive. >> ??? Maybe this >> ??? >>>>>>> is only the default for the C:\ drive though (or perhaps >> ??? depends >> ??? >>>>>>> on your Windows/WSL version?) >> ??? >>>>>> I think the default is "dir", which will cause any new >> ??? directory >> ??? >>>>>> created from WSL to be case sensitive, so I would say this >> ??? needs >> ??? >>>>>> to be documented in building.md. >> ??? >>>>>>> Anyways, I've synced down the sandbox and added a new >> ??? patch to >> ??? >>>>>>> address some of the feedback (and some of my own minor >> ??? >>>>>>> enhancements): >> ??? >>>>>>> >> ??? >>>>>>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, >> which >> ??? >>>>>>> had to move earlier in the sequence 2. Use $EXE_SUFFIX >> ??? instead >> ??? >>>>>>> of .exe literal per Magnus' feedback 3. Added information >> ??? about >> ??? >>>>>>> WSL versioning to build, similar to Cygwin 4. Updated >> ??? >>>>>>> building.md and building.html with WSL build instructions >> ??? >>>>>> Nice! I've applied and pushed this patch to the sandbox. >> ??? Just to >> ??? >>>>>> be sure, did you generate the html version with pandoc using >> ??? >>>>>> "make update-build-docs"? If not, we will need to make sure >> ??? that >> ??? >>>>>> is done before the final push. >> ??? >>>>>> >> ??? >>>>>> I noticed trailing whitespace in some files. Jcheck will >> ??? reject >> ??? >>>>>> that in most types of files but in the build, we are a bit >> ??? on our >> ??? >>>>>> own trying to avoid it. >> ??? >>>>>> >> ??? >>>>>>> (By the way, you misspelled my name in your sandbox commit): >> ??? >>>>>>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e >> ??? >>>>>> Terribly sorry about that! The combination of u and o is a >> ??? common >> ??? >>>>>> slip for me on the keyboard. It's correct in the new >> commit at >> ??? >>>>>> least, and in the final commit, contributors are attributed >> ??? with >> ??? >>>>>> email addresses. >> ??? >>>>>>> I will work on fixing the Cygwin path extraction in my >> ??? next patch. >> ??? >>>>>>> Most likely I will just restore the old code for Cygwin >> while >> ??? >>>>>>> using the new code for WSL, unless there are other >> ??? suggestions... >> ??? >>>>>>> Aside from this, is there any other feedback that I should >> ??? take >> ??? >>>>>>> into account before we can merge this into the main >> ??? repository? >> ??? >>>>>> That may be the best solution. >> ??? >>>>>> >> ??? >>>>>> I tried to build some more targets and failed. Please make >> ??? sure >> ??? >>>>>> you can do "make bundles". That will build docs and tests in >> ??? >>>>>> addition to just the product and also do the packaging into >> ??? >>>>>> zip/tar.gz. It would also be nice if "make test" worked. >> ??? >>>>>> >> ??? >>>>>> Note that Magnus is now on vacation and I will be >> ??? traveling, so >> ??? >>>>>> you will not hear from me until Wednesday. >> ??? >>>>>> >> ??? >>>>>> /Erik >> ??? >>>>>> >> ??? >>>>>>> Thanks, >> ??? >>>>>>> >> ??? >>>>>>> -Andrew >> ??? >>>>>>> >> ??? >>>>>>> -----Original Message----- >> ??? >>>>>>> From: Erik Joelsson > ??? > >> ??? >>>>>>> Sent: Friday, December 14, 2018 5:42 PM >> ??? >>>>>>> To: Andrew Luo > ??? >; Magnus Ihse >> ??? >>>>>>> Bursie > ??? > >> ??? >>>>>>> Cc: build-dev at openjdk.java.net >> ??? >> ??? >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >> ??? >>>>>>> Subsystem for Linux) on Windows >> ??? >>>>>>> >> ??? >>>>>>> After having configured my WSL to mount using case=off, I >> was >> ??? >>>>>>> able to successfully build images using the latest patch as >> ??? >>>>>>> applied in the sandbox. >> ??? >>>>>>> >> ??? >>>>>>> /Erik >> ??? >>>>>>> >> ??? >>>>>>> On 2018-12-14 17:23, Erik Joelsson wrote: >> ??? >>>>>>>> Hello again, >> ??? >>>>>>>> >> ??? >>>>>>>> I took the liberty of creating a bug for this and also a >> ??? >>>>>>>> sandbox branch where I've applied your latest patch. If you >> ??? >>>>>>>> clone that you can send further patches based on a known >> ??? state >> ??? >>>>>>>> in the sandbox. This will make it easier to see what you >> are >> ??? >>>>>>>> actually doing in each update, as well as give us better >> ??? >>>>>>>> references when discussing them. It also gives me the >> ??? ability >> ??? >>>>>>>> to directly change things so we can keep Cygwin/msys >> working. >> ??? >>>>>>>> >> ??? >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8215445 >> ??? >>>>>>>> >> ??? >>>>>>>> >> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >> ??? >>>>>>>> >> ??? >>>>>>>> /Erik >> ??? >>>>>>>> >> ??? >>>>>>>> On 2018-12-14 16:47, Erik Joelsson wrote: >> ??? >>>>>>>>> Hello, >> ??? >>>>>>>>> >> ??? >>>>>>>>> You beat me to it. I just found the rc.exe problem was >> that >> ??? >>>>>>>>> FIXPATH_PATH in spec.gmk.in was >> ??? quoted. Make just propagates >> ??? >>>>>>>>> quotes verbatim, so then fixpath.c would create a path >> ??? >>>>>>>>> variable like; >> ??? >>>>>>>>> >> ??? >>>>>>>>> $PATH;"$FIXPATH_PATH" >> ??? >>>>>>>>> >> ??? >>>>>>>>> Which is why link.exe could not find rc.exe. >> ??? >>>>>>>>> >> ??? >>>>>>>>> /Erik >> ??? >>>>>>>>> >> ??? >>>>>>>>> On 2018-12-14 16:32, Andrew Luo wrote: >> ??? >>>>>>>>>> Ok, here's my latest patch (I didn't add your case >> ??? >>>>>>>>>> sensitivity fix yet, but will do next patch).? I >> ??? believe this >> ??? >>>>>>>>>> should get you past the rc.exe issues. >> ??? >>>>>>>>>> >> ??? >>>>>>>>>> Thanks, >> ??? >>>>>>>>>> >> ??? >>>>>>>>>> -Andrew >> ??? >>>>>>>>>> >> ??? >>>>>>>>>> -----Original Message----- >> ??? >>>>>>>>>> From: Erik Joelsson > ??? > >> ??? >>>>>>>>>> Sent: Friday, December 14, 2018 4:15 PM >> ??? >>>>>>>>>> To: Magnus Ihse Bursie > ??? > >> ??? >>>>>>>>>> Cc: Andrew Luo > ??? >; >> ??? >>>>>>>>>> build-dev at openjdk.java.net >> ??? >> ??? >>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL >> ??? (Windows >> ??? >>>>>>>>>> Subsystem for Linux) on Windows >> ??? >>>>>>>>>> >> ??? >>>>>>>>>> >> ??? >>>>>>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >> ??? >>>>>>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >> ??? >>>>>>>>>>>> > ??? >: >> ??? >>>>>>>>>>>> >> ??? >>>>>>>>>>>> I found the reason it's not failing make. It returns >> "1" >> ??? >>>>>>>>>>>> and NativeCompilation.gmk currently ignores 1 >> explicitly >> ??? >>>>>>>>>>>> for Visual Studio. I added that back in 2014 in >> ??? >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I >> ??? >>>>>>>>>>>> can't figure out why. Nothing mentioned in either >> ??? comment or review. >> ??? >>>>>>>>>>> Sounds like it's ripe for removal then. :) I wonder what >> ??? >>>>>>>>>>> kind of issue you might have run into that caused a >> ??? returned >> ??? >>>>>>>>>>> 1 to happen and yet we didn't want to consider it a >> ??? failure... >> ??? >>>>>>>>>> If I'm to guess, I think it's one of the commands we >> ??? pipe the >> ??? >>>>>>>>>> output to when the output is zero. This would explain >> ??? why it >> ??? >>>>>>>>>> was added together with pipefail. >> ??? >>>>>>>>>> >> ??? >>>>>>>>>> /Erik >> ??? >>>>>>>>>> >> ??? >>>>>>>>>>> /Magnus >> ??? >>>>>>>>>>> >> ??? >>>>>>>>>>>> /Erik >> ??? >>>>>>>>>>>> >> ??? >>>>>>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >> ??? >>>>>>>>>>>>> >> ??? >>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >> ??? >>>>>>>>>>>>>> I get the same error for pch and it still >> ??? continues, but >> ??? >>>>>>>>>>>>>> this time I let it run until it eventually fails >> ??? for real >> ??? >>>>>>>>>>>>>> when it can't link. Perhaps it's simply cl.exe that >> ??? isn't >> ??? >>>>>>>>>>>>>> returning non zero for this error? When the linker >> ??? fails, >> ??? >>>>>>>>>>>>>> make fails, so propagation doesn't seem broken. >> ??? >>>>>>>>>>>>> That does also seem really weird, considering that it >> ??? >>>>>>>>>>>>> claims it to be a "fatal error". Can you repeat the >> ??? >>>>>>>>>>>>> command at the command line and get the failure >> ??? again, and >> ??? >>>>>>>>>>>>> then check the return value? >> ??? >>>>>>>>>>>>> Can you rewrite the command line and run it from the >> ??? >>>>>>>>>>>>> devenv prompt? That is, is there any indication that >> ??? the >> ??? >>>>>>>>>>>>> pch file itself is messed up, or can it be used if >> ??? running >> ??? >>>>>>>>>>>>> the compilation that should use it from an "ok" >> prompt? >> ??? >>>>>>>>>>>>> >> ??? >>>>>>>>>>>>> /Magnus >> ??? >>>>>>>>>>>>>> /Erik >> ??? >>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >> ??? >>>>>>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is >> ??? much >> ??? >>>>>>>>>>>>>>> later down the line... Still investigating... >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> Thanks, >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> -Andrew >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> -----Original Message----- >> ??? >>>>>>>>>>>>>>> From: Andrew Luo >> ??? >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >> ??? >>>>>>>>>>>>>>> To: 'Andrew Luo' >> ??? > ??? >; >> ??? >>>>>>>>>>>>>>> Magnus Ihse Bursie > ??? >; Erik >> ??? >>>>>>>>>>>>>>> Joelsson > ??? > >> ??? >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >> ??? >> ??? >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >> ??? >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> Try this updated patch with some fixes... >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> Thanks, >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> -Andrew >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> -----Original Message----- >> ??? >>>>>>>>>>>>>>> From: build-dev >> ??? > ??? > On >> ??? >>>>>>>>>>>>>>> Behalf Of Andrew Luo >> ??? >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >> ??? >>>>>>>>>>>>>>> To: Magnus Ihse Bursie >> ??? > ??? >; >> ??? >>>>>>>>>>>>>>> Erik Joelsson > ??? > >> ??? >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >> ??? >> ??? >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >> ??? >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> I think I have a fix for it.? Give me a minute (or >> ??? a few >> ??? >>>>>>>>>>>>>>> hours depending on if it works). >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> Thanks, >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> -Andrew >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> -----Original Message----- >> ??? >>>>>>>>>>>>>>> From: Magnus Ihse Bursie >> ??? > > >> ??? >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >> ??? >>>>>>>>>>>>>>> To: Erik Joelsson > ??? > >> ??? >>>>>>>>>>>>>>> Cc: Andrew Luo > ??? >; >> ??? >>>>>>>>>>>>>>> build-dev at openjdk.java.net >> ??? >> ??? >>>>>>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL >> ??? >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >> >>>>>>>>>>>>>>>> > ??? >: >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >> >>>>>>>>>>>>>>>>>>>> Hello, >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> I took your patch for a spin, and configure >> ??? passes, >> >>>>>>>>>>>>>>>>>>>> but I get the same build error I got with my >> ??? patch: >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler >> >>>>>>>>>>>>>>>>>>>> intermediate >> >>>>>>>>>>>>>>>>>>>> file: >> >>>>>>>>>>>>>>>>>>>> >> ??? 'd:\erik\jdk-wsl\build\windows-x86_64-server-releas >> >>>>>>>>>>>>>>>>>>>> e\ >> >>>>>>>>>>>>>>>>>>>> hotsp >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> ot\ >> >>>>>>>>>>>>>>>>>>>> varia >> >>>>>>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such >> >>>>>>>>>>>>>>>>>>>> file or directory >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> This is repeated for every C++ file in >> ??? Hotspot. I >> >>>>>>>>>>>>>>>>>>>> see two issues here. First of all, I need to >> ??? figure >> >>>>>>>>>>>>>>>>>>>> out why the compiler will not find the file, >> ??? which >> >>>>>>>>>>>>>>>>>>>> is clearly there. >> >>>>>>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >> >>>>>>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is >> ??? disappearing. >> >>>>>>>>>>>>>>>>>>> Can you build without errors if you disable PCH? >> >>>>>>>>>>>>>>>>> Could you? That is, is it only the PCH that is >> >>>>>>>>>>>>>>>>> problematic? >> >>>>>>>>>>>>>>>> Trying that now. >> >>>>>>>>>>>>>>>>>>> Also, a wild guess: can it be related to file >> >>>>>>>>>>>>>>>>>>> permissions? >> >>>>>>>>>>>>>>>>>>> Can you read the file properly from both WSL and >> >>>>>>>>>>>>>>>>>>> Windows? >> >>>>>>>>>>>>>>>>>> It is readable, but it could be something with >> ??? case. >> >>>>>>>>>>>>>>>>>> The file is actually called BUILD_LIBJVM.pch, but >> >>>>>>>>>>>>>>>>>> that is also how it's given to the compiler >> ??? command line. >> >>>>>>>>>>>>>>>>>> Here is the output from DEBUG_FIXPATH: >> >>>>>>>>>>>>>>>>> Weird. What if you, after a failed build, rename >> ??? it to >> >>>>>>>>>>>>>>>>> build_libjvm.pch? >> >>>>>>>>>>>>>>>> Doing that causes a new error: >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> cpp : fatal error C1382: the PCH file >> >>>>>>>>>>>>>>>> >> ??? 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ho >> >>>>>>>>>>>>>>>> ts >> >>>>>>>>>>>>>>>> pot\v >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has >> ??? been >> >>>>>>>>>>>>>>>> rebuilt since >> >>>>>>>>>>>>>>>> >> ??? 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ho >> >>>>>>>>>>>>>>>> ts >> >>>>>>>>>>>>>>>> pot\v >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> ari ant-s >> ??? erver\libjvm\objs\accessBarrierSupport.obj' >> >>>>>>>>>>>>>>>> was generated. >> >>>>>>>>>>>>>>>> Please rebuild this object >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> But I think even more important is that make is not >> >>>>>>>>>>>>>>>> getting the error. The build just continues until >> >>>>>>>>>>>>>>>> interrupted. >> ??? >>>>>>>>>>>>>>> Agree, that's bad. >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> Does fixpath_debug print exit code? If so, what >> ??? does it >> ??? >>>>>>>>>>>>>>> say? If not, we should add that instrumentation. >> ??? >>>>>>>>>>>>>>> >> ??? >>>>>>>>>>>>>>> /Magnus >> ??? >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath >> >>>>>>>>>>>>>>>>>> input line >> >>>>>>>>>>>>>>>>>>> >> ??? -wsl\build\windows-x86_64-server-release\configure-s >> >>>>>>>>>>>>>>>>>>> up >> >>>>>>>>>>>>>>>>>>> port\ >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> bin >> >>>>>>>>>>>>>>>>>>> \fixp >> >>>>>>>>>>>>>>>>>> ath.exe -w >> >>>>>>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >> >>>>>>>>>>>>>>>> I agree, didn't look into that part. >> >>>>>>>>>>>>>>>>>> >> ??? /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 270 >> >>>>>>>>>>>>>>>>>> /bin/ >> >>>>>>>>>>>>>>>>>> Hostx86/x64/cl.exe >> >>>>>>>>>>>>>>>>> Also, FWIW, this seems not to have been properly >> ??? case >> >>>>>>>>>>>>>>>>> treated. Which version of the patch are you using? >> >>>>>>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> /Erik >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> /Magnus >> >>>>>>>>>>>>>>>>>> -showIncludes >> >>>>>>>>>>>>>>>>>> >> ??? -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-re >> >>>>>>>>>>>>>>>>>> le >> >>>>>>>>>>>>>>>>>> ase/h >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ots pot/v >> ??? ariant-server/libjvm/objs/BUILD_LIBJVM.pch >> >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >> >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >> >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >> >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >> >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >> >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >> >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >> >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >> >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >> >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >> >>>>>>>>>>>>>>>>>> -DCOMPILER2 >> >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >> >>>>>>>>>>>>>>>>>> ea >> >>>>>>>>>>>>>>>>>> se/ho >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> tsp >> >>>>>>>>>>>>>>>>>> ot/va >> >>>>>>>>>>>>>>>>>> riant-server/gensrc/adfiles >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows >> >>>>>>>>>>>>>>>>>> _x >> >>>>>>>>>>>>>>>>>> 86 >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >> >>>>>>>>>>>>>>>>>> ea >> >>>>>>>>>>>>>>>>>> se/ho >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> tsp >> >>>>>>>>>>>>>>>>>> ot/va >> >>>>>>>>>>>>>>>>>> riant-server/gensrc >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompi >> >>>>>>>>>>>>>>>>>> le d >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/inc >> >>>>>>>>>>>>>>>>>> lu >> >>>>>>>>>>>>>>>>>> de >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >> >>>>>>>>>>>>>>>>>> ea >> >>>>>>>>>>>>>>>>>> se/su >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ppo >> >>>>>>>>>>>>>>>>>> rt/mo >> >>>>>>>>>>>>>>>>>> dules_include/java.base >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >> >>>>>>>>>>>>>>>>>> ea >> >>>>>>>>>>>>>>>>>> se/su >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ppo >> >>>>>>>>>>>>>>>>>> rt/mo >> >>>>>>>>>>>>>>>>>> dules_include/java.base/win32 >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native >> >>>>>>>>>>>>>>>>>> /l >> >>>>>>>>>>>>>>>>>> ibjim >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> age >> >>>>>>>>>>>>>>>>>> -Z7 >> >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSV >> >>>>>>>>>>>>>>>>>> C/ >> >>>>>>>>>>>>>>>>>> 1416~ >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 1.2 >> >>>>>>>>>>>>>>>>>> 70/at >> >>>>>>>>>>>>>>>>>> lmfc/include >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSV >> >>>>>>>>>>>>>>>>>> C/ >> >>>>>>>>>>>>>>>>>> 1416~ >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 1.2 >> >>>>>>>>>>>>>>>>>> 70/in clude >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shar >> >>>>>>>>>>>>>>>>>> ed >> >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winr >> >>>>>>>>>>>>>>>>>> t >> >>>>>>>>>>>>>>>>>> >> ??? -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppw >> >>>>>>>>>>>>>>>>>> in >> >>>>>>>>>>>>>>>>>> rt >> >>>>>>>>>>>>>>>>>> -O2 >> >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >> >>>>>>>>>>>>>>>>>> >> ??? -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-re >> >>>>>>>>>>>>>>>>>> le >> >>>>>>>>>>>>>>>>>> ase/h >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ots pot/v >> ??? ariant-server/libjvm/objs/ad_x86_expand.obj >> >>>>>>>>>>>>>>>>>> >> ??? /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >> >>>>>>>>>>>>>>>>>> se >> >>>>>>>>>>>>>>>>>> /hots >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> pot /vari >> >>>>>>>>>>>>>>>>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >> >>>>>>>>>>>>>>>>>> fixpath using wsl mode, with path list: >> >>>>>>>>>>>>>>>>>> fixpath converted line >> >>>>>>>>>>>>>>>>>>> >> ??? c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/141 >> >>>>>>>>>>>>>>>>>>> 6~ >> >>>>>>>>>>>>>>>>>>> 1.270 >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> /bi >> >>>>>>>>>>>>>>>>>>> n/Hos >> >>>>>>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >> >>>>>>>>>>>>>>>>>> >> ??? -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-releas >> >>>>>>>>>>>>>>>>>> e/ >> >>>>>>>>>>>>>>>>>> hotsp >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >> >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >> >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >> >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >> >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >> >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >> >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >> >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >> >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >> >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >> >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >> >>>>>>>>>>>>>>>>>> -DCOMPILER2 >> >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >> >>>>>>>>>>>>>>>>>> >> ??? -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >> >>>>>>>>>>>>>>>>>> /h >> >>>>>>>>>>>>>>>>>> otspo >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >> >>>>>>>>>>>>>>>>>> >> ??? -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >> >>>>>>>>>>>>>>>>>> >> ??? -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >> >>>>>>>>>>>>>>>>>> /h >> >>>>>>>>>>>>>>>>>> otspo >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> t/v >> >>>>>>>>>>>>>>>>>> arian t-server/gensrc >> >>>>>>>>>>>>>>>>>> >> ??? -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >> >>>>>>>>>>>>>>>>>> >> ??? -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >> >>>>>>>>>>>>>>>>>> >> ??? -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >> >>>>>>>>>>>>>>>>>> /s >> >>>>>>>>>>>>>>>>>> uppor >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> t/m >> >>>>>>>>>>>>>>>>>> odule >> >>>>>>>>>>>>>>>>>> s_include/java.base >> >>>>>>>>>>>>>>>>>> >> ??? -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >> >>>>>>>>>>>>>>>>>> /s >> >>>>>>>>>>>>>>>>>> uppor >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> t/m >> >>>>>>>>>>>>>>>>>> odule >> >>>>>>>>>>>>>>>>>> s_include/java.base/win32 >> >>>>>>>>>>>>>>>>>> >> ??? -Id:/erik/jdk-wsl/open/src/java.base/share/native/lib >> >>>>>>>>>>>>>>>>>> ji >> >>>>>>>>>>>>>>>>>> mage >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> -Z7 >> >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >> >>>>>>>>>>>>>>>>>> >> ??? -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/14 >> >>>>>>>>>>>>>>>>>> 16 >> >>>>>>>>>>>>>>>>>> ~1.27 >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 0/a >> >>>>>>>>>>>>>>>>>> tlmfc >> >>>>>>>>>>>>>>>>>> /include >> >>>>>>>>>>>>>>>>>> >> ??? -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/14 >> >>>>>>>>>>>>>>>>>> 16 >> >>>>>>>>>>>>>>>>>> ~1.27 >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 0/i nclud e >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >> >>>>>>>>>>>>>>>>>> >> ??? -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >> >>>>>>>>>>>>>>>>>> -O2 >> >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >> >>>>>>>>>>>>>>>>>> >> ??? -Fod:/erik/jdk-wsl/build/windows-x86_64-server-releas >> >>>>>>>>>>>>>>>>>> e/ >> >>>>>>>>>>>>>>>>>> hotsp >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >> >>>>>>>>>>>>>>>>>> >> ??? d:/erik/jdk-wsl/build/windows-x86_64-server-release/h >> >>>>>>>>>>>>>>>>>> ot >> >>>>>>>>>>>>>>>>>> spot/ >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> var >> >>>>>>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> An interesting note is that make is rebuilding the >> >>>>>>>>>>>>>>>>>> pch file on every invocation so it too has trouble >> >>>>>>>>>>>>>>>>>> finding the file. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> /Erik >> From jonathan.gibbons at oracle.com Wed Jan 16 18:45:42 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Jan 2019 10:45:42 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: <94853ab1-3d3e-0b85-fd85-73204c8bf48c@oracle.com> References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> <725be6c5-ccad-5db7-b2eb-2bf5d0e87f54@oracle.com> <956d24c3-4ac8-d0f5-89dc-fd4952ee887b@oracle.com> <94853ab1-3d3e-0b85-fd85-73204c8bf48c@oracle.com> Message-ID: <32b5254f-c9f9-b5a1-c52e-a99bab43f440@oracle.com> On 01/11/2019 02:24 PM, Erik Joelsson wrote: > > On 2019-01-11 14:12, Jonathan Gibbons wrote: >> 3 options that come to mind are ... >> >> 1. jtreg sets new env variables for any/all JDK tools that may be >> invoked, including java and javac, and the scripts are updated to use >> the new variables >> >> 2. jtreg sets a single new env variable EXE, which is either empty or >> ".exe". A bit ugly for anyone not used to using WSL >> >> 3. all the magic is somehow done in the tests, with no additional >> change to jtreg >> > I think 1 or 2 is preferable to 3. There will be a lot of duplication > of this logic in the tests otherwise. I think 2 is preferable to 1, since it is only a single env variable instead of many. I'll update jtreg to set EXE in WSL mode.? Then, we just have to figure what to do with the tests. -- Jon >> I also note the orthogonal option, which is to continue the migration >> away from using shell tests as much as possible. >> > I certainly agree that we need to move away from shell tests long term! > > /Erik > >> -- Jon >> >> >> On 01/11/2019 01:45 PM, Erik Joelsson wrote: >>> With the new jtreg, the test is launched correctly. It's now a >>> problem with the test. When WSL launches a Windows executable, it >>> needs to run it with the full name (including .exe). This particular >>> test tries to run things like: >>> >>> /mnt/d/erik/jdk-jib-wsl/build/windows-x64/images/jdk/bin/javac >>> -J-Xmx768m -J-XX:MaxRAMPercentage=1 -J-ea -J-esa pkg/A.java pkg/B.java >>> >>> Which fails because it needs to be javac.exe. >>> >>> To fix these tests, one thing we need to do is find a good way of >>> identifying that the JDK under test is of Windows type and in that >>> case add .exe to the executables. Note that checking if the >>> execution environment happens to be WSL is not good enough. The >>> relevant part in this case is identifying the JDK under test. >>> >>> /Erik >>> >>> On 2019-01-11 10:14, Jonathan Gibbons wrote: >>>> I'm pretty sure I know the problem. I'll post an update to jtreg. >>>> >>>> -- Jon >>>> >>>> On 01/11/2019 09:44 AM, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> With the new jtreg and the patch, normal java tests seem to work >>>>> fine. >>>>> >>>>> I tried some simple shell tests and they fail. I took a test in >>>>> langtools as an example: >>>>> >>>>> open/test/langtools/tools/javac/Paths/Class-Path.sh >>>>> >>>>> I invoked it like this: >>>>> >>>>> $ make test TEST=langtools/tools/javac/Paths/Class-Path.sh >>>>> >>>>> It fails with the following: >>>>> >>>>> -------------------------------------------------- >>>>> TEST: tools/javac/Paths/Class-Path.sh >>>>> TEST JDK: d:\erik\jdk-jib-wsl\build\windows-x64\images\jdk >>>>> >>>>> ACTION: shell -- Failed. Execution failed: exit code 127 >>>>> REASON: User specified action: run shell Class-Path.sh >>>>> TIME:?? 0.125 seconds >>>>> messages: >>>>> command: shell Class-Path.sh >>>>> reason: User specified action: run shell Class-Path.sh >>>>> elapsed time (seconds): 0.125 >>>>> STDOUT: >>>>> STDERR: >>>>> sh: 0: Can't open >>>>> /mnt/d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh >>>>> >>>>> It seems the translation of the path fails. Further down in the >>>>> jtr file, this looks to be the command line Jtreg is trying to run: >>>>> >>>>> ??? wsl.exe \\ >>>>> ??????? sh >>>>> '/mnt/d:\\/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh' >>>>> >>>>> It should be noted that WSL does not understand windows paths like >>>>> Cygwin does. By default it mounts every Windows drive x in /mnt/x, >>>>> but this is configurable so should not be assumed. There is a >>>>> tool, wslpath, similar to cygpath, which can be used to translate. >>>>> It's also possible to translate environment variables by adding >>>>> them to WSLENV. >>>>> >>>>> Perhaps using WSLENV would be a reasonable trick here. When >>>>> running wsl.exe, also set something like this in the env: >>>>> >>>>> JTREG_TEST_PATH=d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh >>>>> >>>>> WSLENV=$WSLENV:JTREG_TEST_PATH/p >>>>> >>>>> then rewrite the command as: >>>>> >>>>> $ wsl.exe sh $JTREG_TEST_PATH >>>>> >>>>> /Erik >>>>> >>>>> On 2019-01-11 08:51, Jonathan Gibbons wrote: >>>>>> Erik, >>>>>> >>>>>> Can you try a test run with the latest jtreg bits, and post the >>>>>> results for me to look at, to see why tests are failing and what, >>>>>> if anything, needs to be done? >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 1/10/19 9:02 PM, Andrew Luo wrote: >>>>>>> I've updated my patch per the latest jtreg changes.? Tested this >>>>>>> with the latest code synced from the jtreg repository, seems >>>>>>> like shell tests do get run (but don't pass, tests will need to >>>>>>> be changed). >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jonathan Gibbons >>>>>>> Sent: Wednesday, January 9, 2019 1:39 PM >>>>>>> To: Erik Joelsson ; Andrew Luo >>>>>>> ; build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Fixes for running tests on WSL >>>>>>> >>>>>>> Erik, >>>>>>> >>>>>>> I have pushed a version of Andrew's patch for jtreg into the >>>>>>> jtreg repo. >>>>>>> >>>>>>> With regard to Andrew's proposed patch for make/RunTests.gmk, >>>>>>> the name of the option to use for jtreg is now just "-wsl'. >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> On 01/07/2019 01:10 AM, Erik Joelsson wrote: >>>>>>>> Hello Andrew, >>>>>>>> >>>>>>>> If the patch gets accepted to Jtreg, this looks good. We will >>>>>>>> need to >>>>>>>> wait for Jtreg support before pushing this though. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> On 2019-01-06 20:34, Andrew Luo wrote: >>>>>>>>> Hi Everyone, >>>>>>>>> >>>>>>>>> I've gotten shell tests to run on WSL with some changes to >>>>>>>>> jtreg and >>>>>>>>> a small change to the OpenJDK gmake files.? Most of them are >>>>>>>>> still >>>>>>>>> not passing (I believe one or two of them did just work out of >>>>>>>>> the >>>>>>>>> box after these changes as failures + error count dropped; >>>>>>>>> previous >>>>>>>>> errors + previous failures < current failures; also "errors" >>>>>>>>> dropped >>>>>>>>> to zero), as the scripts themselves will need to be changed, >>>>>>>>> however, >>>>>>>>> at least now they can actually run...? My patch with proposed >>>>>>>>> changes >>>>>>>>> are attached. >>>>>>>>> >>>>>>>>> I've sent the corresponding jtreg changes to the code-tools-dev >>>>>>>>> mailing list: >>>>>>>>> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/0 >>>>>>>>> >>>>>>>>> 00464.html >>>>>>>>> >>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> >>>> >> From andrewluotechnologies at outlook.com Wed Jan 16 18:52:15 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Wed, 16 Jan 2019 18:52:15 +0000 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: <32b5254f-c9f9-b5a1-c52e-a99bab43f440@oracle.com> References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> <725be6c5-ccad-5db7-b2eb-2bf5d0e87f54@oracle.com> <956d24c3-4ac8-d0f5-89dc-fd4952ee887b@oracle.com> <94853ab1-3d3e-0b85-fd85-73204c8bf48c@oracle.com> <32b5254f-c9f9-b5a1-c52e-a99bab43f440@oracle.com> Message-ID: Sounds good to me. I had been a bit busy recently so hadn't yet had a chance to respond. I do recommend naming the variable EXE_SUFFIX though, since that's what we call it in the build scripts. Although if you do strongly prefer EXE instead, it doesn't matter to me that much. Obviously this approach will require modification to many of the tests. I can probably handle a good portion of the tier 1 test cases - less than ~100 test cases are failing (on my system that is - not all of which are shell scripts anyways). But I don't know how many shell scripts we have in total. Perhaps if we find some common patterns we can just use a regex to find/replace what needs to be changed... Thanks, -Andrew -----Original Message----- From: Jonathan Gibbons Sent: Wednesday, January 16, 2019 10:46 AM To: Erik Joelsson ; Andrew Luo ; build-dev at openjdk.java.net Subject: Re: [PATCH] Fixes for running tests on WSL On 01/11/2019 02:24 PM, Erik Joelsson wrote: > > On 2019-01-11 14:12, Jonathan Gibbons wrote: >> 3 options that come to mind are ... >> >> 1. jtreg sets new env variables for any/all JDK tools that may be >> invoked, including java and javac, and the scripts are updated to use >> the new variables >> >> 2. jtreg sets a single new env variable EXE, which is either empty or >> ".exe". A bit ugly for anyone not used to using WSL >> >> 3. all the magic is somehow done in the tests, with no additional >> change to jtreg >> > I think 1 or 2 is preferable to 3. There will be a lot of duplication > of this logic in the tests otherwise. I think 2 is preferable to 1, since it is only a single env variable instead of many. I'll update jtreg to set EXE in WSL mode.? Then, we just have to figure what to do with the tests. -- Jon >> I also note the orthogonal option, which is to continue the migration >> away from using shell tests as much as possible. >> > I certainly agree that we need to move away from shell tests long term! > > /Erik > >> -- Jon >> >> >> On 01/11/2019 01:45 PM, Erik Joelsson wrote: >>> With the new jtreg, the test is launched correctly. It's now a >>> problem with the test. When WSL launches a Windows executable, it >>> needs to run it with the full name (including .exe). This particular >>> test tries to run things like: >>> >>> /mnt/d/erik/jdk-jib-wsl/build/windows-x64/images/jdk/bin/javac >>> -J-Xmx768m -J-XX:MaxRAMPercentage=1 -J-ea -J-esa pkg/A.java >>> pkg/B.java >>> >>> Which fails because it needs to be javac.exe. >>> >>> To fix these tests, one thing we need to do is find a good way of >>> identifying that the JDK under test is of Windows type and in that >>> case add .exe to the executables. Note that checking if the >>> execution environment happens to be WSL is not good enough. The >>> relevant part in this case is identifying the JDK under test. >>> >>> /Erik >>> >>> On 2019-01-11 10:14, Jonathan Gibbons wrote: >>>> I'm pretty sure I know the problem. I'll post an update to jtreg. >>>> >>>> -- Jon >>>> >>>> On 01/11/2019 09:44 AM, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> With the new jtreg and the patch, normal java tests seem to work >>>>> fine. >>>>> >>>>> I tried some simple shell tests and they fail. I took a test in >>>>> langtools as an example: >>>>> >>>>> open/test/langtools/tools/javac/Paths/Class-Path.sh >>>>> >>>>> I invoked it like this: >>>>> >>>>> $ make test TEST=langtools/tools/javac/Paths/Class-Path.sh >>>>> >>>>> It fails with the following: >>>>> >>>>> -------------------------------------------------- >>>>> TEST: tools/javac/Paths/Class-Path.sh TEST JDK: >>>>> d:\erik\jdk-jib-wsl\build\windows-x64\images\jdk >>>>> >>>>> ACTION: shell -- Failed. Execution failed: exit code 127 >>>>> REASON: User specified action: run shell Class-Path.sh >>>>> TIME:?? 0.125 seconds >>>>> messages: >>>>> command: shell Class-Path.sh >>>>> reason: User specified action: run shell Class-Path.sh elapsed >>>>> time (seconds): 0.125 >>>>> STDOUT: >>>>> STDERR: >>>>> sh: 0: Can't open >>>>> /mnt/d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Cla >>>>> ss-Path.sh >>>>> >>>>> It seems the translation of the path fails. Further down in the >>>>> jtr file, this looks to be the command line Jtreg is trying to run: >>>>> >>>>> ??? wsl.exe \\ >>>>> ??????? sh >>>>> '/mnt/d:\\/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh' >>>>> >>>>> It should be noted that WSL does not understand windows paths like >>>>> Cygwin does. By default it mounts every Windows drive x in /mnt/x, >>>>> but this is configurable so should not be assumed. There is a >>>>> tool, wslpath, similar to cygpath, which can be used to translate. >>>>> It's also possible to translate environment variables by adding >>>>> them to WSLENV. >>>>> >>>>> Perhaps using WSLENV would be a reasonable trick here. When >>>>> running wsl.exe, also set something like this in the env: >>>>> >>>>> JTREG_TEST_PATH=d:/erik/jdk-jib-wsl/open/test/langtools/tools/java >>>>> c/Paths/Class-Path.sh >>>>> >>>>> WSLENV=$WSLENV:JTREG_TEST_PATH/p >>>>> >>>>> then rewrite the command as: >>>>> >>>>> $ wsl.exe sh $JTREG_TEST_PATH >>>>> >>>>> /Erik >>>>> >>>>> On 2019-01-11 08:51, Jonathan Gibbons wrote: >>>>>> Erik, >>>>>> >>>>>> Can you try a test run with the latest jtreg bits, and post the >>>>>> results for me to look at, to see why tests are failing and what, >>>>>> if anything, needs to be done? >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 1/10/19 9:02 PM, Andrew Luo wrote: >>>>>>> I've updated my patch per the latest jtreg changes.? Tested this >>>>>>> with the latest code synced from the jtreg repository, seems >>>>>>> like shell tests do get run (but don't pass, tests will need to >>>>>>> be changed). >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jonathan Gibbons >>>>>>> Sent: Wednesday, January 9, 2019 1:39 PM >>>>>>> To: Erik Joelsson ; Andrew Luo >>>>>>> ; build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Fixes for running tests on WSL >>>>>>> >>>>>>> Erik, >>>>>>> >>>>>>> I have pushed a version of Andrew's patch for jtreg into the >>>>>>> jtreg repo. >>>>>>> >>>>>>> With regard to Andrew's proposed patch for make/RunTests.gmk, >>>>>>> the name of the option to use for jtreg is now just "-wsl'. >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> On 01/07/2019 01:10 AM, Erik Joelsson wrote: >>>>>>>> Hello Andrew, >>>>>>>> >>>>>>>> If the patch gets accepted to Jtreg, this looks good. We will >>>>>>>> need to wait for Jtreg support before pushing this though. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> On 2019-01-06 20:34, Andrew Luo wrote: >>>>>>>>> Hi Everyone, >>>>>>>>> >>>>>>>>> I've gotten shell tests to run on WSL with some changes to >>>>>>>>> jtreg and a small change to the OpenJDK gmake files.? Most of >>>>>>>>> them are still not passing (I believe one or two of them did >>>>>>>>> just work out of the box after these changes as failures + >>>>>>>>> error count dropped; previous errors + previous failures < >>>>>>>>> current failures; also "errors" >>>>>>>>> dropped >>>>>>>>> to zero), as the scripts themselves will need to be changed, >>>>>>>>> however, at least now they can actually run...? My patch with >>>>>>>>> proposed changes are attached. >>>>>>>>> >>>>>>>>> I've sent the corresponding jtreg changes to the >>>>>>>>> code-tools-dev mailing list: >>>>>>>>> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-Ja >>>>>>>>> nuary/0 >>>>>>>>> >>>>>>>>> 00464.html >>>>>>>>> >>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> >>>> >> From thomas.stuefe at gmail.com Wed Jan 16 19:06:10 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 16 Jan 2019 20:06:10 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: References: <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> <953ff1ff-3921-1888-44b8-f61018df904f@oracle.com> <18d0347f-b8cf-b384-fd47-f3f8b27f9ffd@oracle.com> <1f0ffff1-8ffa-02d5-57e0-925705329e02@oracle.com> Message-ID: Neat! Thank you. ..Thomas On Wed, Jan 16, 2019 at 5:36 PM Erik Joelsson wrote: > Build support is in and you should be able to follow the documentation in > doc/building.md. Test support is still waiting on a jtreg release and a > patch to use it, but even with that, there are tests (at least shell tests) > that will not work properly. > > /Erik > On 2019-01-16 00:49, Thomas St?fe wrote: > > Hi guys, > > Just wanted to know what the state is. Did you already add the support for > WSL or is this still WIP? If it should work, is there a documentation > somewhere I could follow? > > Thank you! > > Thomas > > > On Sat, Dec 22, 2018 at 4:55 AM Andrew Luo < > andrewluotechnologies at outlook.com> wrote: > >> Just wanted to update the thread with the issues we discovered with WSL >> while adding support to the OpenJDK build system. I reported these issues >> to the WSL team for all except for one of the bugs, which I'm still >> investigating. >> >> GenerateCurrencyData.java - issue with Properties.load(System.in): >> https://github.com/Microsoft/WSL/issues/3723 >> Issue with directly calling cmd.exe to transform long path to short path: >> https://github.com/Microsoft/WSL/issues/3724 >> Calling from Linux to Win32 with untransformable Linux paths in a WSLENV >> path environment variable causes extra output: >> https://github.com/Microsoft/WSL/issues/3725 >> Spp.java - still investigating this >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson >> Sent: Thursday, December 20, 2018 1:51 AM >> To: Andrew Luo ; Magnus Ihse Bursie < >> magnus.ihse.bursie at oracle.com> >> Cc: build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem >> for Linux) on Windows >> >> I've updated and two builds in a row have now succeeded. I will keep >> running, but it does seem likely that the new version has fixed the issue. >> >> /Erik >> >> On 2018-12-20 09:44, Erik Joelsson wrote: >> > Hello, >> > >> > On 2018-12-19 19:40, Andrew Luo wrote: >> >> Hi Erik, >> >> >> >> Which target are you using (make exploded-image?)? I never saw this >> >> error while building on my machine (I've built about 10 times now, >> >> I'm on Windows 10 1809 for what it's worth). Perhaps I can try to >> >> reproduce this on my system as well... >> > >> > The target doesn't really matter that much, it's failing when building >> > java modules, so exploded-image should reproduce it. I have built >> > successfully as well, so this only happens intermittently. Here is the >> > environment string from my system: >> > >> > WSL version Ubuntu 16.04.4 LTS #471-Microsoft Fri Dec 07 20:04:00 PST >> > 2018 4.4.0-17134-Microsoft (on Windows build 10.0.17134.471) >> > >> > In System about, it identifies itself as Windows 10 Pro 1803, so that >> > looks older than yours. I will see if I can update. >> > >> > I should also note that deleting build output is not necessary (and >> > probably not affecting) success or failure on rebuild. From what I can >> > see what happens is: make runs the find command to find all java >> > source files and puts that list of files as prerequisites to the java >> > compile rule, then when evaluating the rule, it sometimes fails to >> > resolve a file. This would seem like a bug in the filesystem to me. >> > >> > /Erik >> > >> >> Thanks, >> >> >> >> -Andrew >> >> >> >> -----Original Message----- >> >> From: Erik Joelsson >> >> Sent: Wednesday, December 19, 2018 8:28 AM >> >> To: Andrew Luo ; Magnus Ihse >> >> Bursie >> >> Cc: build-dev at openjdk.java.net >> >> Subject: Re: [PATCH] Support for building using WSL (Windows >> >> Subsystem for Linux) on Windows >> >> >> >> I'm now seeing intermittent build failures that look like this: >> >> >> >> make[3]: *** No rule to make target >> >> '/mnt/d/erik/jdk-sandbox/open/src/java.security.jgss/share/classes/su >> >> n/security/krb5/internal/TGSReq.java', >> >> >> >> needed by >> >> >> '/mnt/d/erik/jdk-sandbox/build/windows-x86_64-server-release/jdk/modules/java.security.jgss/_the.java.security.jgss_batch'. >> >> >> >> >> Stop. >> >> >> >> The particular file that's missing varies, and deleting the output >> >> dir for that module and rebuild works. The common pattern seems to be >> >> upper case letters in the file name of the source file. >> >> >> >> I will investigate some more. >> >> >> >> /Erik >> >> >> >> On 2018-12-19 06:18, Erik Joelsson wrote: >> >>> I can also report that on the Windows 10 machine I'm testing this >> >>> on, "make bundles" on Cygwin took 12m56s and in WSL 8m39s, so a >> >>> pretty big improvement! >> >>> >> >>> /Erik >> >>> >> >>> On 2018-12-19 03:45, Erik Joelsson wrote: >> >>>> Hello, >> >>>> >> >>>> On 2018-12-19 00:19, Erik Joelsson wrote: >> >>>>> Hello Andrew, >> >>>>> >> >>>>> On 2018-12-18 12:45, Andrew Luo wrote: >> >>>>>> Hi Erik/Magnus, >> >>>>>> >> >>>>>> I've attached my latest changes: >> >>>>>> >> >>>>>> 1. Fixed a file I forgot to revert in my previous change while >> >>>>>> trying something out... >> >>>>>> 2. Added information about case sensitivity of the OpenJDK build >> >>>>>> directory (yes, I did use the make target to generate the HTML >> >>>>>> file) 3. Fixed Cygwin (hopefully, I don't have a Cygwin >> >>>>>> environment to verify this) >> >>>>> I will take this patch for a spin and see. >> >>>>> >> >>>> After applying a fix for >> >>>> https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to >> >>>> build everything as well. I pushed some minor adjustments to make >> >>>> Cygwin work too. >> >>>> >> >>>> I will need to take this through more thorough testing. >> >>>> >> >>>> /Erik >> >>>> >> >>>>>> With this patch I've tested the following targets: >> >>>>>> exploded-image (default): Works >> >>>>>> images: Works >> >>>>>> bundles: Works >> >>>>>> test: Completes, but some tests fail. >> >>>>>> >> >>>>>> I didn't go through the test failures completely, but all of the >> >>>>>> ones I did see are due to attempting to call CreateProcess with >> >>>>>> "sh" as the argument (in jtreg: >> >>>>>> >> http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). >> >> >>>>>> >> >>>>>> This isn't supported in Windows, perhaps using a Linux boot JDK >> >>>>>> would fix this (but might break other things). I can look into >> >>>>>> fixing it (on WSL you can call "wsl sh", for example), but I >> >>>>>> think since it's a completely separate repo anyways, it would be >> >>>>>> best to take up those changes separately. Let me know your >> >>>>>> thoughts on this. >> >>>>> Ah, if a Java process is launched from a Cygwin environment, it >> >>>>> will have the unix/cygwin tools in the path so those can be >> >>>>> launched directly. When running in WSL, it will launch the Windows >> >>>>> binary java.exe in the Windows environment so there is no trace of >> >>>>> WSL. I agree that we can look into this later, but we need to note >> >>>>> that running tests is not completely supported in WSL. >> >>>>> >> >>>>> /Erik >> >>>>> >> >>>>>> Otherwise, let me know if there is any other comments/suggestions >> >>>>>> before we can merge this into the main repository. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> >> >>>>>> -Andrew >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Erik Joelsson >> >>>>>> Sent: Monday, December 17, 2018 9:52 AM >> >>>>>> To: Andrew Luo ; Magnus Ihse >> >>>>>> Bursie >> >>>>>> Cc: build-dev at openjdk.java.net >> >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >> >>>>>> Subsystem for Linux) on Windows >> >>>>>> >> >>>>>> Hello Andrew, >> >>>>>> >> >>>>>> On 2018-12-16 00:01, Andrew Luo wrote: >> >>>>>>> For me, /mnt/c was already mounted case insensitive. Maybe this >> >>>>>>> is only the default for the C:\ drive though (or perhaps depends >> >>>>>>> on your Windows/WSL version?) >> >>>>>> I think the default is "dir", which will cause any new directory >> >>>>>> created from WSL to be case sensitive, so I would say this needs >> >>>>>> to be documented in building.md. >> >>>>>>> Anyways, I've synced down the sandbox and added a new patch to >> >>>>>>> address some of the feedback (and some of my own minor >> >>>>>>> enhancements): >> >>>>>>> >> >>>>>>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which >> >>>>>>> had to move earlier in the sequence 2. Use $EXE_SUFFIX instead >> >>>>>>> of .exe literal per Magnus' feedback 3. Added information about >> >>>>>>> WSL versioning to build, similar to Cygwin 4. Updated >> >>>>>>> building.md and building.html with WSL build instructions >> >>>>>> Nice! I've applied and pushed this patch to the sandbox. Just to >> >>>>>> be sure, did you generate the html version with pandoc using >> >>>>>> "make update-build-docs"? If not, we will need to make sure that >> >>>>>> is done before the final push. >> >>>>>> >> >>>>>> I noticed trailing whitespace in some files. Jcheck will reject >> >>>>>> that in most types of files but in the build, we are a bit on our >> >>>>>> own trying to avoid it. >> >>>>>> >> >>>>>>> (By the way, you misspelled my name in your sandbox commit): >> >>>>>>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e >> >>>>>> Terribly sorry about that! The combination of u and o is a common >> >>>>>> slip for me on the keyboard. It's correct in the new commit at >> >>>>>> least, and in the final commit, contributors are attributed with >> >>>>>> email addresses. >> >>>>>>> I will work on fixing the Cygwin path extraction in my next patch. >> >>>>>>> Most likely I will just restore the old code for Cygwin while >> >>>>>>> using the new code for WSL, unless there are other suggestions... >> >>>>>>> Aside from this, is there any other feedback that I should take >> >>>>>>> into account before we can merge this into the main repository? >> >>>>>> That may be the best solution. >> >>>>>> >> >>>>>> I tried to build some more targets and failed. Please make sure >> >>>>>> you can do "make bundles". That will build docs and tests in >> >>>>>> addition to just the product and also do the packaging into >> >>>>>> zip/tar.gz. It would also be nice if "make test" worked. >> >>>>>> >> >>>>>> Note that Magnus is now on vacation and I will be traveling, so >> >>>>>> you will not hear from me until Wednesday. >> >>>>>> >> >>>>>> /Erik >> >>>>>> >> >>>>>>> Thanks, >> >>>>>>> >> >>>>>>> -Andrew >> >>>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: Erik Joelsson >> >>>>>>> Sent: Friday, December 14, 2018 5:42 PM >> >>>>>>> To: Andrew Luo ; Magnus Ihse >> >>>>>>> Bursie >> >>>>>>> Cc: build-dev at openjdk.java.net >> >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >> >>>>>>> Subsystem for Linux) on Windows >> >>>>>>> >> >>>>>>> After having configured my WSL to mount using case=off, I was >> >>>>>>> able to successfully build images using the latest patch as >> >>>>>>> applied in the sandbox. >> >>>>>>> >> >>>>>>> /Erik >> >>>>>>> >> >>>>>>> On 2018-12-14 17:23, Erik Joelsson wrote: >> >>>>>>>> Hello again, >> >>>>>>>> >> >>>>>>>> I took the liberty of creating a bug for this and also a >> >>>>>>>> sandbox branch where I've applied your latest patch. If you >> >>>>>>>> clone that you can send further patches based on a known state >> >>>>>>>> in the sandbox. This will make it easier to see what you are >> >>>>>>>> actually doing in each update, as well as give us better >> >>>>>>>> references when discussing them. It also gives me the ability >> >>>>>>>> to directly change things so we can keep Cygwin/msys working. >> >>>>>>>> >> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8215445 >> >>>>>>>> >> >>>>>>>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >> >>>>>>>> >> >>>>>>>> /Erik >> >>>>>>>> >> >>>>>>>> On 2018-12-14 16:47, Erik Joelsson wrote: >> >>>>>>>>> Hello, >> >>>>>>>>> >> >>>>>>>>> You beat me to it. I just found the rc.exe problem was that >> >>>>>>>>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates >> >>>>>>>>> quotes verbatim, so then fixpath.c would create a path >> >>>>>>>>> variable like; >> >>>>>>>>> >> >>>>>>>>> $PATH;"$FIXPATH_PATH" >> >>>>>>>>> >> >>>>>>>>> Which is why link.exe could not find rc.exe. >> >>>>>>>>> >> >>>>>>>>> /Erik >> >>>>>>>>> >> >>>>>>>>> On 2018-12-14 16:32, Andrew Luo wrote: >> >>>>>>>>>> Ok, here's my latest patch (I didn't add your case >> >>>>>>>>>> sensitivity fix yet, but will do next patch). I believe this >> >>>>>>>>>> should get you past the rc.exe issues. >> >>>>>>>>>> >> >>>>>>>>>> Thanks, >> >>>>>>>>>> >> >>>>>>>>>> -Andrew >> >>>>>>>>>> >> >>>>>>>>>> -----Original Message----- >> >>>>>>>>>> From: Erik Joelsson >> >>>>>>>>>> Sent: Friday, December 14, 2018 4:15 PM >> >>>>>>>>>> To: Magnus Ihse Bursie >> >>>>>>>>>> Cc: Andrew Luo ; >> >>>>>>>>>> build-dev at openjdk.java.net >> >>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >> >>>>>>>>>> Subsystem for Linux) on Windows >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >> >>>>>>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >> >>>>>>>>>>>> : >> >>>>>>>>>>>> >> >>>>>>>>>>>> I found the reason it's not failing make. It returns "1" >> >>>>>>>>>>>> and NativeCompilation.gmk currently ignores 1 explicitly >> >>>>>>>>>>>> for Visual Studio. I added that back in 2014 in >> >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I >> >>>>>>>>>>>> can't figure out why. Nothing mentioned in either comment or >> review. >> >>>>>>>>>>> Sounds like it's ripe for removal then. :) I wonder what >> >>>>>>>>>>> kind of issue you might have run into that caused a returned >> >>>>>>>>>>> 1 to happen and yet we didn't want to consider it a failure... >> >>>>>>>>>> If I'm to guess, I think it's one of the commands we pipe the >> >>>>>>>>>> output to when the output is zero. This would explain why it >> >>>>>>>>>> was added together with pipefail. >> >>>>>>>>>> >> >>>>>>>>>> /Erik >> >>>>>>>>>> >> >>>>>>>>>>> /Magnus >> >>>>>>>>>>> >> >>>>>>>>>>>> /Erik >> >>>>>>>>>>>> >> >>>>>>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >> >>>>>>>>>>>>>> I get the same error for pch and it still continues, but >> >>>>>>>>>>>>>> this time I let it run until it eventually fails for real >> >>>>>>>>>>>>>> when it can't link. Perhaps it's simply cl.exe that isn't >> >>>>>>>>>>>>>> returning non zero for this error? When the linker fails, >> >>>>>>>>>>>>>> make fails, so propagation doesn't seem broken. >> >>>>>>>>>>>>> That does also seem really weird, considering that it >> >>>>>>>>>>>>> claims it to be a "fatal error". Can you repeat the >> >>>>>>>>>>>>> command at the command line and get the failure again, and >> >>>>>>>>>>>>> then check the return value? >> >>>>>>>>>>>>> Can you rewrite the command line and run it from the >> >>>>>>>>>>>>> devenv prompt? That is, is there any indication that the >> >>>>>>>>>>>>> pch file itself is messed up, or can it be used if running >> >>>>>>>>>>>>> the compilation that should use it from an "ok" prompt? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> /Magnus >> >>>>>>>>>>>>>> /Erik >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >> >>>>>>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much >> >>>>>>>>>>>>>>> later down the line... Still investigating... >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Thanks, >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> -Andrew >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> -----Original Message----- >> >>>>>>>>>>>>>>> From: Andrew Luo >> >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >> >>>>>>>>>>>>>>> To: 'Andrew Luo' ; >> >>>>>>>>>>>>>>> Magnus Ihse Bursie ; Erik >> >>>>>>>>>>>>>>> Joelsson >> >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >> >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >> >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Try this updated patch with some fixes... >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Thanks, >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> -Andrew >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> -----Original Message----- >> >>>>>>>>>>>>>>> From: build-dev On >> >>>>>>>>>>>>>>> Behalf Of Andrew Luo >> >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >> >>>>>>>>>>>>>>> To: Magnus Ihse Bursie ; >> >>>>>>>>>>>>>>> Erik Joelsson >> >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >> >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >> >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> I think I have a fix for it. Give me a minute (or a few >> >>>>>>>>>>>>>>> hours depending on if it works). >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Thanks, >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> -Andrew >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> -----Original Message----- >> >>>>>>>>>>>>>>> From: Magnus Ihse Bursie >> >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >> >>>>>>>>>>>>>>> To: Erik Joelsson >> >>>>>>>>>>>>>>> Cc: Andrew Luo ; >> >>>>>>>>>>>>>>> build-dev at openjdk.java.net >> >>>>>>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL >> >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >> >>>>>>>>>>>>>>>> : >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >> >>>>>>>>>>>>>>>>>>>> Hello, >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> I took your patch for a spin, and configure passes, >> >>>>>>>>>>>>>>>>>>>> but I get the same build error I got with my patch: >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler >> >>>>>>>>>>>>>>>>>>>> intermediate >> >>>>>>>>>>>>>>>>>>>> file: >> >>>>>>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-releas >> >>>>>>>>>>>>>>>>>>>> e\ >> >>>>>>>>>>>>>>>>>>>> hotsp >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> ot\ >> >>>>>>>>>>>>>>>>>>>> varia >> >>>>>>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such >> >>>>>>>>>>>>>>>>>>>> file or directory >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I >> >>>>>>>>>>>>>>>>>>>> see two issues here. First of all, I need to figure >> >>>>>>>>>>>>>>>>>>>> out why the compiler will not find the file, which >> >>>>>>>>>>>>>>>>>>>> is clearly there. >> >>>>>>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >> >>>>>>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >> >>>>>>>>>>>>>>>>>>> Can you build without errors if you disable PCH? >> >>>>>>>>>>>>>>>>> Could you? That is, is it only the PCH that is >> >>>>>>>>>>>>>>>>> problematic? >> >>>>>>>>>>>>>>>> Trying that now. >> >>>>>>>>>>>>>>>>>>> Also, a wild guess: can it be related to file >> >>>>>>>>>>>>>>>>>>> permissions? >> >>>>>>>>>>>>>>>>>>> Can you read the file properly from both WSL and >> >>>>>>>>>>>>>>>>>>> Windows? >> >>>>>>>>>>>>>>>>>> It is readable, but it could be something with case. >> >>>>>>>>>>>>>>>>>> The file is actually called BUILD_LIBJVM.pch, but >> >>>>>>>>>>>>>>>>>> that is also how it's given to the compiler command >> line. >> >>>>>>>>>>>>>>>>>> Here is the output from DEBUG_FIXPATH: >> >>>>>>>>>>>>>>>>> Weird. What if you, after a failed build, rename it to >> >>>>>>>>>>>>>>>>> build_libjvm.pch? >> >>>>>>>>>>>>>>>> Doing that causes a new error: >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> cpp : fatal error C1382: the PCH file >> >>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ho >> >>>>>>>>>>>>>>>> ts >> >>>>>>>>>>>>>>>> pot\v >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been >> >>>>>>>>>>>>>>>> rebuilt since >> >>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ho >> >>>>>>>>>>>>>>>> ts >> >>>>>>>>>>>>>>>> pot\v >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' >> >>>>>>>>>>>>>>>> was generated. >> >>>>>>>>>>>>>>>> Please rebuild this object >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> But I think even more important is that make is not >> >>>>>>>>>>>>>>>> getting the error. The build just continues until >> >>>>>>>>>>>>>>>> interrupted. >> >>>>>>>>>>>>>>> Agree, that's bad. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Does fixpath_debug print exit code? If so, what does it >> >>>>>>>>>>>>>>> say? If not, we should add that instrumentation. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> /Magnus >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath >> >>>>>>>>>>>>>>>>>> input line >> >>>>>>>>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-s >> >>>>>>>>>>>>>>>>>>> up >> >>>>>>>>>>>>>>>>>>> port\ >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> bin >> >>>>>>>>>>>>>>>>>>> \fixp >> >>>>>>>>>>>>>>>>>> ath.exe -w >> >>>>>>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >> >>>>>>>>>>>>>>>> I agree, didn't look into that part. >> >>>>>>>>>>>>>>>>>> >> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 270 >> >>>>>>>>>>>>>>>>>> /bin/ >> >>>>>>>>>>>>>>>>>> Hostx86/x64/cl.exe >> >>>>>>>>>>>>>>>>> Also, FWIW, this seems not to have been properly case >> >>>>>>>>>>>>>>>>> treated. Which version of the patch are you using? >> >>>>>>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> /Erik >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> /Magnus >> >>>>>>>>>>>>>>>>>> -showIncludes >> >>>>>>>>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-re >> >>>>>>>>>>>>>>>>>> le >> >>>>>>>>>>>>>>>>>> ase/h >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >> >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >> >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >> >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >> >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >> >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >> >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >> >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >> >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >> >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >> >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >> >>>>>>>>>>>>>>>>>> -DCOMPILER2 >> >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >> >>>>>>>>>>>>>>>>>> ea >> >>>>>>>>>>>>>>>>>> se/ho >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> tsp >> >>>>>>>>>>>>>>>>>> ot/va >> >>>>>>>>>>>>>>>>>> riant-server/gensrc/adfiles >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows >> >>>>>>>>>>>>>>>>>> _x >> >>>>>>>>>>>>>>>>>> 86 >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >> >>>>>>>>>>>>>>>>>> ea >> >>>>>>>>>>>>>>>>>> se/ho >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> tsp >> >>>>>>>>>>>>>>>>>> ot/va >> >>>>>>>>>>>>>>>>>> riant-server/gensrc >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompi >> >>>>>>>>>>>>>>>>>> le d >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/inc >> >>>>>>>>>>>>>>>>>> lu >> >>>>>>>>>>>>>>>>>> de >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >> >>>>>>>>>>>>>>>>>> ea >> >>>>>>>>>>>>>>>>>> se/su >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ppo >> >>>>>>>>>>>>>>>>>> rt/mo >> >>>>>>>>>>>>>>>>>> dules_include/java.base >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >> >>>>>>>>>>>>>>>>>> ea >> >>>>>>>>>>>>>>>>>> se/su >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ppo >> >>>>>>>>>>>>>>>>>> rt/mo >> >>>>>>>>>>>>>>>>>> dules_include/java.base/win32 >> >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native >> >>>>>>>>>>>>>>>>>> /l >> >>>>>>>>>>>>>>>>>> ibjim >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> age >> >>>>>>>>>>>>>>>>>> -Z7 >> >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >> >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSV >> >>>>>>>>>>>>>>>>>> C/ >> >>>>>>>>>>>>>>>>>> 1416~ >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 1.2 >> >>>>>>>>>>>>>>>>>> 70/at >> >>>>>>>>>>>>>>>>>> lmfc/include >> >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSV >> >>>>>>>>>>>>>>>>>> C/ >> >>>>>>>>>>>>>>>>>> 1416~ >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 1.2 >> >>>>>>>>>>>>>>>>>> 70/in clude >> >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >> >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shar >> >>>>>>>>>>>>>>>>>> ed >> >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >> >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winr >> >>>>>>>>>>>>>>>>>> t >> >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppw >> >>>>>>>>>>>>>>>>>> in >> >>>>>>>>>>>>>>>>>> rt >> >>>>>>>>>>>>>>>>>> -O2 >> >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >> >>>>>>>>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-re >> >>>>>>>>>>>>>>>>>> le >> >>>>>>>>>>>>>>>>>> ase/h >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >> >>>>>>>>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >> >>>>>>>>>>>>>>>>>> se >> >>>>>>>>>>>>>>>>>> /hots >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> pot /vari >> >>>>>>>>>>>>>>>>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >> >>>>>>>>>>>>>>>>>> fixpath using wsl mode, with path list: >> >>>>>>>>>>>>>>>>>> fixpath converted line >> >>>>>>>>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/141 >> >>>>>>>>>>>>>>>>>>> 6~ >> >>>>>>>>>>>>>>>>>>> 1.270 >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> /bi >> >>>>>>>>>>>>>>>>>>> n/Hos >> >>>>>>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >> >>>>>>>>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-releas >> >>>>>>>>>>>>>>>>>> e/ >> >>>>>>>>>>>>>>>>>> hotsp >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >> >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >> >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >> >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >> >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >> >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >> >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >> >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >> >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >> >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >> >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >> >>>>>>>>>>>>>>>>>> -DCOMPILER2 >> >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >> >>>>>>>>>>>>>>>>>> /h >> >>>>>>>>>>>>>>>>>> otspo >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >> >>>>>>>>>>>>>>>>>> /h >> >>>>>>>>>>>>>>>>>> otspo >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> t/v >> >>>>>>>>>>>>>>>>>> arian t-server/gensrc >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >> >>>>>>>>>>>>>>>>>> /s >> >>>>>>>>>>>>>>>>>> uppor >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> t/m >> >>>>>>>>>>>>>>>>>> odule >> >>>>>>>>>>>>>>>>>> s_include/java.base >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >> >>>>>>>>>>>>>>>>>> /s >> >>>>>>>>>>>>>>>>>> uppor >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> t/m >> >>>>>>>>>>>>>>>>>> odule >> >>>>>>>>>>>>>>>>>> s_include/java.base/win32 >> >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/lib >> >>>>>>>>>>>>>>>>>> ji >> >>>>>>>>>>>>>>>>>> mage >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> -Z7 >> >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/14 >> >>>>>>>>>>>>>>>>>> 16 >> >>>>>>>>>>>>>>>>>> ~1.27 >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 0/a >> >>>>>>>>>>>>>>>>>> tlmfc >> >>>>>>>>>>>>>>>>>> /include >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/14 >> >>>>>>>>>>>>>>>>>> 16 >> >>>>>>>>>>>>>>>>>> ~1.27 >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 0/i nclud e >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >> >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >> >>>>>>>>>>>>>>>>>> -O2 >> >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >> >>>>>>>>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-releas >> >>>>>>>>>>>>>>>>>> e/ >> >>>>>>>>>>>>>>>>>> hotsp >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >> >>>>>>>>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/h >> >>>>>>>>>>>>>>>>>> ot >> >>>>>>>>>>>>>>>>>> spot/ >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> var >> >>>>>>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> An interesting note is that make is rebuilding the >> >>>>>>>>>>>>>>>>>> pch file on every invocation so it too has trouble >> >>>>>>>>>>>>>>>>>> finding the file. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> /Erik >> > From jonathan.gibbons at oracle.com Wed Jan 16 19:07:00 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Jan 2019 11:07:00 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> <725be6c5-ccad-5db7-b2eb-2bf5d0e87f54@oracle.com> <956d24c3-4ac8-d0f5-89dc-fd4952ee887b@oracle.com> <94853ab1-3d3e-0b85-fd85-73204c8bf48c@oracle.com> <32b5254f-c9f9-b5a1-c52e-a99bab43f440@oracle.com> Message-ID: I am a big fan of precedent and clarity, but that being said, using ${EXE_SUFFIX} is a bit more clunky at each use site in each shell test.? But, I guess a test that uses the suffix a lot could define EXE=${EXE_SUFFIX} and use the shorter form. My scripts currently show the following counts for shell tests: test/langtools: 6 ... this is believable, even though it is higher than expected test/jdk: 243 ... this seems credible test/hotspot/jtreg: 15 ... this number seems way low; I may need to figure a better static analysis for this repo. We would need to get buy-in from the various component teams before doing any mass-update to shell tests. -- Jon On 1/16/19 10:52 AM, Andrew Luo wrote: > Sounds good to me. I had been a bit busy recently so hadn't yet had a chance to respond. > > I do recommend naming the variable EXE_SUFFIX though, since that's what we call it in the build scripts. Although if you do strongly prefer EXE instead, it doesn't matter to me that much. Obviously this approach will require modification to many of the tests. I can probably handle a good portion of the tier 1 test cases - less than ~100 test cases are failing (on my system that is - not all of which are shell scripts anyways). But I don't know how many shell scripts we have in total. Perhaps if we find some common patterns we can just use a regex to find/replace what needs to be changed... > > Thanks, > > -Andrew > > -----Original Message----- > From: Jonathan Gibbons > Sent: Wednesday, January 16, 2019 10:46 AM > To: Erik Joelsson ; Andrew Luo ; build-dev at openjdk.java.net > Subject: Re: [PATCH] Fixes for running tests on WSL > > > > On 01/11/2019 02:24 PM, Erik Joelsson wrote: >> On 2019-01-11 14:12, Jonathan Gibbons wrote: >>> 3 options that come to mind are ... >>> >>> 1. jtreg sets new env variables for any/all JDK tools that may be >>> invoked, including java and javac, and the scripts are updated to use >>> the new variables >>> >>> 2. jtreg sets a single new env variable EXE, which is either empty or >>> ".exe". A bit ugly for anyone not used to using WSL >>> >>> 3. all the magic is somehow done in the tests, with no additional >>> change to jtreg >>> >> I think 1 or 2 is preferable to 3. There will be a lot of duplication >> of this logic in the tests otherwise. > I think 2 is preferable to 1, since it is only a single env variable instead of many. I'll update jtreg to set EXE in WSL mode.? Then, we just have to figure what to do with the tests. > > -- Jon > > >>> I also note the orthogonal option, which is to continue the migration >>> away from using shell tests as much as possible. >>> >> I certainly agree that we need to move away from shell tests long term! >> >> /Erik >> >>> -- Jon >>> >>> >>> On 01/11/2019 01:45 PM, Erik Joelsson wrote: >>>> With the new jtreg, the test is launched correctly. It's now a >>>> problem with the test. When WSL launches a Windows executable, it >>>> needs to run it with the full name (including .exe). This particular >>>> test tries to run things like: >>>> >>>> /mnt/d/erik/jdk-jib-wsl/build/windows-x64/images/jdk/bin/javac >>>> -J-Xmx768m -J-XX:MaxRAMPercentage=1 -J-ea -J-esa pkg/A.java >>>> pkg/B.java >>>> >>>> Which fails because it needs to be javac.exe. >>>> >>>> To fix these tests, one thing we need to do is find a good way of >>>> identifying that the JDK under test is of Windows type and in that >>>> case add .exe to the executables. Note that checking if the >>>> execution environment happens to be WSL is not good enough. The >>>> relevant part in this case is identifying the JDK under test. >>>> >>>> /Erik >>>> >>>> On 2019-01-11 10:14, Jonathan Gibbons wrote: >>>>> I'm pretty sure I know the problem. I'll post an update to jtreg. >>>>> >>>>> -- Jon >>>>> >>>>> On 01/11/2019 09:44 AM, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> With the new jtreg and the patch, normal java tests seem to work >>>>>> fine. >>>>>> >>>>>> I tried some simple shell tests and they fail. I took a test in >>>>>> langtools as an example: >>>>>> >>>>>> open/test/langtools/tools/javac/Paths/Class-Path.sh >>>>>> >>>>>> I invoked it like this: >>>>>> >>>>>> $ make test TEST=langtools/tools/javac/Paths/Class-Path.sh >>>>>> >>>>>> It fails with the following: >>>>>> >>>>>> -------------------------------------------------- >>>>>> TEST: tools/javac/Paths/Class-Path.sh TEST JDK: >>>>>> d:\erik\jdk-jib-wsl\build\windows-x64\images\jdk >>>>>> >>>>>> ACTION: shell -- Failed. Execution failed: exit code 127 >>>>>> REASON: User specified action: run shell Class-Path.sh >>>>>> TIME:?? 0.125 seconds >>>>>> messages: >>>>>> command: shell Class-Path.sh >>>>>> reason: User specified action: run shell Class-Path.sh elapsed >>>>>> time (seconds): 0.125 >>>>>> STDOUT: >>>>>> STDERR: >>>>>> sh: 0: Can't open >>>>>> /mnt/d:/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Cla >>>>>> ss-Path.sh >>>>>> >>>>>> It seems the translation of the path fails. Further down in the >>>>>> jtr file, this looks to be the command line Jtreg is trying to run: >>>>>> >>>>>> ??? wsl.exe \\ >>>>>> ??????? sh >>>>>> '/mnt/d:\\/erik/jdk-jib-wsl/open/test/langtools/tools/javac/Paths/Class-Path.sh' >>>>>> >>>>>> It should be noted that WSL does not understand windows paths like >>>>>> Cygwin does. By default it mounts every Windows drive x in /mnt/x, >>>>>> but this is configurable so should not be assumed. There is a >>>>>> tool, wslpath, similar to cygpath, which can be used to translate. >>>>>> It's also possible to translate environment variables by adding >>>>>> them to WSLENV. >>>>>> >>>>>> Perhaps using WSLENV would be a reasonable trick here. When >>>>>> running wsl.exe, also set something like this in the env: >>>>>> >>>>>> JTREG_TEST_PATH=d:/erik/jdk-jib-wsl/open/test/langtools/tools/java >>>>>> c/Paths/Class-Path.sh >>>>>> >>>>>> WSLENV=$WSLENV:JTREG_TEST_PATH/p >>>>>> >>>>>> then rewrite the command as: >>>>>> >>>>>> $ wsl.exe sh $JTREG_TEST_PATH >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2019-01-11 08:51, Jonathan Gibbons wrote: >>>>>>> Erik, >>>>>>> >>>>>>> Can you try a test run with the latest jtreg bits, and post the >>>>>>> results for me to look at, to see why tests are failing and what, >>>>>>> if anything, needs to be done? >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> On 1/10/19 9:02 PM, Andrew Luo wrote: >>>>>>>> I've updated my patch per the latest jtreg changes.? Tested this >>>>>>>> with the latest code synced from the jtreg repository, seems >>>>>>>> like shell tests do get run (but don't pass, tests will need to >>>>>>>> be changed). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jonathan Gibbons >>>>>>>> Sent: Wednesday, January 9, 2019 1:39 PM >>>>>>>> To: Erik Joelsson ; Andrew Luo >>>>>>>> ; build-dev at openjdk.java.net >>>>>>>> Subject: Re: [PATCH] Fixes for running tests on WSL >>>>>>>> >>>>>>>> Erik, >>>>>>>> >>>>>>>> I have pushed a version of Andrew's patch for jtreg into the >>>>>>>> jtreg repo. >>>>>>>> >>>>>>>> With regard to Andrew's proposed patch for make/RunTests.gmk, >>>>>>>> the name of the option to use for jtreg is now just "-wsl'. >>>>>>>> >>>>>>>> -- Jon >>>>>>>> >>>>>>>> On 01/07/2019 01:10 AM, Erik Joelsson wrote: >>>>>>>>> Hello Andrew, >>>>>>>>> >>>>>>>>> If the patch gets accepted to Jtreg, this looks good. We will >>>>>>>>> need to wait for Jtreg support before pushing this though. >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> On 2019-01-06 20:34, Andrew Luo wrote: >>>>>>>>>> Hi Everyone, >>>>>>>>>> >>>>>>>>>> I've gotten shell tests to run on WSL with some changes to >>>>>>>>>> jtreg and a small change to the OpenJDK gmake files.? Most of >>>>>>>>>> them are still not passing (I believe one or two of them did >>>>>>>>>> just work out of the box after these changes as failures + >>>>>>>>>> error count dropped; previous errors + previous failures < >>>>>>>>>> current failures; also "errors" >>>>>>>>>> dropped >>>>>>>>>> to zero), as the scripts themselves will need to be changed, >>>>>>>>>> however, at least now they can actually run...? My patch with >>>>>>>>>> proposed changes are attached. >>>>>>>>>> >>>>>>>>>> I've sent the corresponding jtreg changes to the >>>>>>>>>> code-tools-dev mailing list: >>>>>>>>>> https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-Ja >>>>>>>>>> nuary/0 >>>>>>>>>> >>>>>>>>>> 00464.html >>>>>>>>>> >>>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> >>>>>>>>>> From jonathan.gibbons at oracle.com Wed Jan 16 19:12:45 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Jan 2019 11:12:45 -0800 Subject: [PATCH] Fixes for running tests on WSL In-Reply-To: References: <265dd47b-9cb5-6c88-767e-ec862b50d96c@oracle.com> <0657f8c2-4e92-d6fd-aaed-159ca926320a@oracle.com> <1a9ed049-f6e3-22fc-6534-af5cae5ae024@oracle.com> <725be6c5-ccad-5db7-b2eb-2bf5d0e87f54@oracle.com> <956d24c3-4ac8-d0f5-89dc-fd4952ee887b@oracle.com> <94853ab1-3d3e-0b85-fd85-73204c8bf48c@oracle.com> <32b5254f-c9f9-b5a1-c52e-a99bab43f440@oracle.com> Message-ID: <10c8b7b1-ec2d-4ffe-c77b-072249a4c363@oracle.com> On 1/16/19 11:07 AM, Jonathan Gibbons wrote: > I am a big fan of precedent and clarity, but that being said, using > ${EXE_SUFFIX} is a bit more clunky at each use site in each shell > test.? But, I guess a test that uses the suffix a lot could define > EXE=${EXE_SUFFIX} and use the shorter form. For the langtools shell tests, the tests already declare variables for $java, $javac, $jar and $jimage, so it is no big deal to update the definitions to use ${EXE_SUFFIX} It seems like a good precedent for retaining unobtrusive clarity in shell tests, to use variables for the paths for the JDK tools. -- Jon From matthias.baesken at sap.com Thu Jan 17 06:41:09 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 17 Jan 2019 06:41:09 +0000 Subject: RFR [XS] 8217233: Update build settings for AIX/xlc In-Reply-To: References: Message-ID: May I have a second review please ? Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 16. Januar 2019 11:08 To: 'Steve Groeger' Cc: 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; ppc-aix-port-dev Subject: RE: RFR [XS] 8217233: Update build settings for AIX/xlc Hi Steve, from my experience the situation is similar to Linux (small performance change). Best regards, Matthias From: Steve Groeger > Sent: Mittwoch, 16. Januar 2019 10:49 To: Baesken, Matthias > Cc: 'build-dev at openjdk.java.net' >; ppc-aix-port-dev at openjdk.java.net; ppc-aix-port-dev > Subject: Re: RFR [XS] 8217233: Update build settings for AIX/xlc Hi Matthias, The change looks OK. The docs state: "This option is disabled by default because it can cause performance degradation." Do you know whether using this option actually causes any performance degradation on AIX? Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges 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: "Baesken, Matthias" > To: "'build-dev at openjdk.java.net'" >, "ppc-aix-port-dev at openjdk.java.net" > Date: 16/01/2019 09:26 Subject: RFR [XS] 8217233: Update build settings for AIX/xlc Sent by: "ppc-aix-port-dev" > ________________________________ Hello, please review this small fix . It adds stack protection compile flags for xlc/AIX . See : https://www.ibm.com/support/knowledgecenter/SSGH2K_12.1.0/com.ibm.xlc121.aix.doc/compiler_ref/opt_stackprotect.html "Provides protection against malicious code or programming errors that overwrite or corrupt the stack." The patch will set the stack protection flags . ( Similar changes have been done for Linux : 8199552: Update to build scripts https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8b060cdf0251 Introduced stack protection compile flags for Linux/gcc ( -fstack-protector ) . ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8217233 http://cr.openjdk.java.net/~mbaesken/webrevs/8217233.0/ Thanks, Matthias 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 christoph.langer at sap.com Thu Jan 17 08:15:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Jan 2019 08:15:27 +0000 Subject: RFR [XS] 8217233: Update build settings for AIX/xlc In-Reply-To: References: Message-ID: <0cdba8af728d484db51a56dcaa8be487@sap.com> Hi Matthias, looks good to me. Best regards Christoph > -----Original Message----- > From: build-dev On Behalf Of > Baesken, Matthias > Sent: Donnerstag, 17. Januar 2019 07:41 > To: Steve Groeger > Cc: 'build-dev at openjdk.java.net' ; ppc-aix- > port-dev at openjdk.java.net; ppc-aix-port-dev bounces at openjdk.java.net> > Subject: [CAUTION] RE: RFR [XS] 8217233: Update build settings for AIX/xlc > > May I have a second review please ? > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Mittwoch, 16. Januar 2019 11:08 > To: 'Steve Groeger' > Cc: 'build-dev at openjdk.java.net' ; ppc-aix- > port-dev at openjdk.java.net; ppc-aix-port-dev bounces at openjdk.java.net> > Subject: RE: RFR [XS] 8217233: Update build settings for AIX/xlc > > Hi Steve, > from my experience the situation is similar to Linux (small performance > change). > > Best regards, Matthias > > > From: Steve Groeger > > > Sent: Mittwoch, 16. Januar 2019 10:49 > To: Baesken, Matthias > > > Cc: 'build-dev at openjdk.java.net' dev at openjdk.java.net>; ppc-aix-port- > dev at openjdk.java.net; ppc- > aix-port-dev port-dev-bounces at openjdk.java.net>> > Subject: Re: RFR [XS] 8217233: Update build settings for AIX/xlc > > Hi Matthias, > > The change looks OK. > > The docs state: "This option is disabled by default because it can cause > performance degradation." > Do you know whether using this option actually causes any performance > degradation on AIX? > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges 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: "Baesken, Matthias" > > > To: "'build-dev at openjdk.java.net'" dev at openjdk.java.net>, "ppc-aix- > port-dev at openjdk.java.net" > dev at openjdk.java.net>> > Date: 16/01/2019 09:26 > Subject: RFR [XS] 8217233: Update build settings for AIX/xlc > Sent by: "ppc-aix-port-dev" bounces at openjdk.java.net bounces at openjdk.java.net>> > ________________________________ > > > > Hello, please review this small fix . > > It adds stack protection compile flags for xlc/AIX . > > See : > > https://www.ibm.com/support/knowledgecenter/SSGH2K_12.1.0/com.ibm. > xlc121.aix.doc/compiler_ref/opt_stackprotect.html > > > "Provides protection against malicious code or programming errors that > overwrite or corrupt the stack." > The patch will set the stack protection flags . > > > ( Similar changes have been done for Linux : 8199552: Update to build > scripts > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8b060cdf0251 > Introduced stack protection compile flags for Linux/gcc ( -fstack-protector ) . > ) > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8217233 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217233.0/ > > > Thanks, Matthias > > > 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 jbvernee at xs4all.nl Thu Jan 17 14:42:57 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Thu, 17 Jan 2019 15:42:57 +0100 Subject: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows Message-ID: <254b4b94abcb9f1cd5274f25f1cac0bb@xs4all.nl> Hello, I'm updating some documentation for the panama repo foreign branch [1]. When running `make update-build-docs` I get the following output: ``` $ make update-build-docs Building target 'update-build-docs' in configuration 'windows-x86_64-server-release' fixpath Unknown argument: --toc fixpath Unknown argument: --toc fixpath Unknown argument: --toc make[3]: *** [UpdateBuildDocs.gmk:50: /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/building.html] Error 127 make[3]: *** Waiting for unfinished jobs.... make[3]: *** [UpdateBuildDocs.gmk:58: /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/testing.html] Error 127 make[3]: *** [UpdateBuildDocs.gmk:66: /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/panama_foreign.html] Error 127 make[2]: *** [make/Main.gmk:417: update-build-docs] Error 2 ERROR: Build failed for target 'update-build-docs' in configuration 'windows-x86_64-server-release' (exit code 2) === Output from failing command(s) repeated here === * For target support_markdown_building_building.md: fixpath Unknown argument: --toc * For target support_markdown_panama_foreign_panama_foreign.md: fixpath Unknown argument: --toc * For target support_markdown_testing_testing.md: fixpath Unknown argument: --toc * All command lines available in /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/make-support/failure-logs. === End of repeated output === No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: See doc/building.html#troubleshooting for assistance. make[1]: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:310: main] Error 2 make: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:186: update-build-docs] Error 2 ``` Is this a know issue? Is this supported on Windows? Thanks, Jorn [1] : http://hg.openjdk.java.net/panama/dev/shortlog/b981c23cb71e From erik.joelsson at oracle.com Thu Jan 17 16:46:37 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Jan 2019 08:46:37 -0800 Subject: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows In-Reply-To: <254b4b94abcb9f1cd5274f25f1cac0bb@xs4all.nl> References: <254b4b94abcb9f1cd5274f25f1cac0bb@xs4all.nl> Message-ID: <32abb1d2-cc41-a367-7ddb-48d0fc2fc454@oracle.com> You need pandoc to generate the html files from md. We also use pandoc to generate files for the actual product documentation. It seems the build only checks that pandoc is available for the product documentation targets and for update-build-docs, it just tries and fails with this rather uninformative error message. I'm pretty sure the target works if you provide pandoc to configure on Windows. There is a script in make/devkit/createPandocBundle.sh that can help you get the pandoc you need. /Erik On 2019-01-17 06:42, Jorn Vernee wrote: > Hello, > > I'm updating some documentation for the panama repo foreign branch [1]. > > When running `make update-build-docs` I get the following output: > > ``` > $ make update-build-docs > Building target 'update-build-docs' in configuration > 'windows-x86_64-server-release' > fixpath Unknown argument: --toc > fixpath Unknown argument: --toc > fixpath Unknown argument: --toc > make[3]: *** [UpdateBuildDocs.gmk:50: > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/building.html] > Error 127 > make[3]: *** Waiting for unfinished jobs.... > make[3]: *** [UpdateBuildDocs.gmk:58: > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/testing.html] > Error 127 > make[3]: *** [UpdateBuildDocs.gmk:66: > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/panama_foreign.html] > Error 127 > make[2]: *** [make/Main.gmk:417: update-build-docs] Error 2 > > ERROR: Build failed for target 'update-build-docs' in configuration > 'windows-x86_64-server-release' (exit code 2) > > === Output from failing command(s) repeated here === > * For target support_markdown_building_building.md: > fixpath Unknown argument: --toc > * For target support_markdown_panama_foreign_panama_foreign.md: > fixpath Unknown argument: --toc > * For target support_markdown_testing_testing.md: > fixpath Unknown argument: --toc > > * All command lines available in > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/make-support/failure-logs. > === End of repeated output === > > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: See doc/building.html#troubleshooting for assistance. > > make[1]: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:310: > main] Error 2 > make: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:186: > update-build-docs] Error 2 > ``` > > Is this a know issue? Is this supported on Windows? > > Thanks, > Jorn > > [1] : http://hg.openjdk.java.net/panama/dev/shortlog/b981c23cb71e From jbvernee at xs4all.nl Thu Jan 17 17:07:12 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Thu, 17 Jan 2019 18:07:12 +0100 Subject: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows In-Reply-To: <32abb1d2-cc41-a367-7ddb-48d0fc2fc454@oracle.com> References: <254b4b94abcb9f1cd5274f25f1cac0bb@xs4all.nl> <32abb1d2-cc41-a367-7ddb-48d0fc2fc454@oracle.com> Message-ID: <836683a97cda660848fb73278df6ed54@xs4all.nl> Hi Erik, Thanks for the insights. The make/devkit/createPandocBundle.sh seems to try to install the linux version of pandoc. I have installed pandoc 2.5 through chocolatey instead. I'm trying to pas the exe path through the PANDOC environment variable, but this produces a configure warning: configure: WARNING: Ignoring value of PANDOC from the environment. Use command line variables instead. I'm not sure what is meant here by 'command line variable' there. I've tried the following: $ PANDOC=/cygdrive/j/ChocolateyInstall/bin/pandoc.exe $ make reconfigure But this gives the same warning. I've also tried: $ make reconfigure PANDOC=/cygdrive/j/ChocolateyInstall/bin/pandoc.exe But this gives a warning that I'm using a non-control variable. How should I pass the value to configure? Thanks, Jorn Erik Joelsson schreef op 2019-01-17 17:46: > You need pandoc to generate the html files from md. We also use pandoc > to generate files for the actual product documentation. It seems the > build only checks that pandoc is available for the product > documentation targets and for update-build-docs, it just tries and > fails with this rather uninformative error message. I'm pretty sure > the target works if you provide pandoc to configure on Windows. > > There is a script in make/devkit/createPandocBundle.sh that can help > you get the pandoc you need. > > /Erik > > On 2019-01-17 06:42, Jorn Vernee wrote: >> Hello, >> >> I'm updating some documentation for the panama repo foreign branch >> [1]. >> >> When running `make update-build-docs` I get the following output: >> >> ``` >> $ make update-build-docs >> Building target 'update-build-docs' in configuration >> 'windows-x86_64-server-release' >> fixpath Unknown argument: --toc >> fixpath Unknown argument: --toc >> fixpath Unknown argument: --toc >> make[3]: *** [UpdateBuildDocs.gmk:50: >> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/building.html] >> Error 127 >> make[3]: *** Waiting for unfinished jobs.... >> make[3]: *** [UpdateBuildDocs.gmk:58: >> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/testing.html] >> Error 127 >> make[3]: *** [UpdateBuildDocs.gmk:66: >> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/panama_foreign.html] >> Error 127 >> make[2]: *** [make/Main.gmk:417: update-build-docs] Error 2 >> >> ERROR: Build failed for target 'update-build-docs' in configuration >> 'windows-x86_64-server-release' (exit code 2) >> >> === Output from failing command(s) repeated here === >> * For target support_markdown_building_building.md: >> fixpath Unknown argument: --toc >> * For target support_markdown_panama_foreign_panama_foreign.md: >> fixpath Unknown argument: --toc >> * For target support_markdown_testing_testing.md: >> fixpath Unknown argument: --toc >> >> * All command lines available in >> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/make-support/failure-logs. >> === End of repeated output === >> >> No indication of failed target found. >> Hint: Try searching the build log for '] Error'. >> Hint: See doc/building.html#troubleshooting for assistance. >> >> make[1]: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:310: >> main] Error 2 >> make: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:186: >> update-build-docs] Error 2 >> ``` >> >> Is this a know issue? Is this supported on Windows? >> >> Thanks, >> Jorn >> >> [1] : http://hg.openjdk.java.net/panama/dev/shortlog/b981c23cb71e From jbvernee at xs4all.nl Thu Jan 17 17:25:29 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Thu, 17 Jan 2019 18:25:29 +0100 Subject: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows In-Reply-To: <836683a97cda660848fb73278df6ed54@xs4all.nl> References: <254b4b94abcb9f1cd5274f25f1cac0bb@xs4all.nl> <32abb1d2-cc41-a367-7ddb-48d0fc2fc454@oracle.com> <836683a97cda660848fb73278df6ed54@xs4all.nl> Message-ID: <3beb529d2c93e6a9ef2efd2a153b4eea@xs4all.nl> Never mind, this works: bash configure PANDOC=/cygdrive/j/ChocolateyInstall/bin/pandoc.exe I should have tried that first. Sorry, Jorn Jorn Vernee schreef op 2019-01-17 18:07: > Hi Erik, > > Thanks for the insights. The make/devkit/createPandocBundle.sh seems > to try to install the linux version of pandoc. I have installed pandoc > 2.5 through chocolatey instead. > > I'm trying to pas the exe path through the PANDOC environment > variable, but this produces a configure warning: > > configure: WARNING: Ignoring value of PANDOC from the environment. > Use command line variables instead. > > I'm not sure what is meant here by 'command line variable' there. I've > tried the following: > > $ PANDOC=/cygdrive/j/ChocolateyInstall/bin/pandoc.exe > $ make reconfigure > > But this gives the same warning. I've also tried: > > $ make reconfigure > PANDOC=/cygdrive/j/ChocolateyInstall/bin/pandoc.exe > > But this gives a warning that I'm using a non-control variable. > > How should I pass the value to configure? > > Thanks, > Jorn > > Erik Joelsson schreef op 2019-01-17 17:46: >> You need pandoc to generate the html files from md. We also use pandoc >> to generate files for the actual product documentation. It seems the >> build only checks that pandoc is available for the product >> documentation targets and for update-build-docs, it just tries and >> fails with this rather uninformative error message. I'm pretty sure >> the target works if you provide pandoc to configure on Windows. >> >> There is a script in make/devkit/createPandocBundle.sh that can help >> you get the pandoc you need. >> >> /Erik >> >> On 2019-01-17 06:42, Jorn Vernee wrote: >>> Hello, >>> >>> I'm updating some documentation for the panama repo foreign branch >>> [1]. >>> >>> When running `make update-build-docs` I get the following output: >>> >>> ``` >>> $ make update-build-docs >>> Building target 'update-build-docs' in configuration >>> 'windows-x86_64-server-release' >>> fixpath Unknown argument: --toc >>> fixpath Unknown argument: --toc >>> fixpath Unknown argument: --toc >>> make[3]: *** [UpdateBuildDocs.gmk:50: >>> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/building.html] >>> Error 127 >>> make[3]: *** Waiting for unfinished jobs.... >>> make[3]: *** [UpdateBuildDocs.gmk:58: >>> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/testing.html] >>> Error 127 >>> make[3]: *** [UpdateBuildDocs.gmk:66: >>> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/panama_foreign.html] >>> Error 127 >>> make[2]: *** [make/Main.gmk:417: update-build-docs] Error 2 >>> >>> ERROR: Build failed for target 'update-build-docs' in configuration >>> 'windows-x86_64-server-release' (exit code 2) >>> >>> === Output from failing command(s) repeated here === >>> * For target support_markdown_building_building.md: >>> fixpath Unknown argument: --toc >>> * For target support_markdown_panama_foreign_panama_foreign.md: >>> fixpath Unknown argument: --toc >>> * For target support_markdown_testing_testing.md: >>> fixpath Unknown argument: --toc >>> >>> * All command lines available in >>> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/make-support/failure-logs. >>> === End of repeated output === >>> >>> No indication of failed target found. >>> Hint: Try searching the build log for '] Error'. >>> Hint: See doc/building.html#troubleshooting for assistance. >>> >>> make[1]: *** >>> [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:310: main] Error >>> 2 >>> make: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:186: >>> update-build-docs] Error 2 >>> ``` >>> >>> Is this a know issue? Is this supported on Windows? >>> >>> Thanks, >>> Jorn >>> >>> [1] : http://hg.openjdk.java.net/panama/dev/shortlog/b981c23cb71e From andrew at dcs.bbk.ac.uk Thu Jan 17 20:45:51 2019 From: andrew at dcs.bbk.ac.uk (Andrew Watkins) Date: Thu, 17 Jan 2019 20:45:51 +0000 Subject: Building OpenJDK10 with Solaris 11.4 x86_64 Message-ID: <37d87c8b-a9ce-b40a-b3c5-7eb543ff8125@dcs.bbk.ac.uk> Hi, Just wondered if anyone has tried building OpenJDK10 under Solaris 11.4 x86_64 yet? Trying to build it on an solaris-x86_64 and not getting very far. 1) "os_solaris.cpp", line 1666: Error: EM_486 is not defined. Ref: https://bugs.openjdk.java.net/browse/JDK-8182035?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel ??? Solaris 11.4 has removed EM_486, but that a quick fix is in os_solaris.cpp: ??? #ifndef EM_486 ??? #define EM_486????????? 6?????????????? /* Intel 80486 */ ??? #endif 2) But then I get tons of the following: "/opt/developerstudio124/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 165: Error: __pad is not a member of const __FILE. "/opt/developerstudio124/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 167: Error: __pad is not a member of const __FILE. "/opt/developerstudio124/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 170: Error: __pad is not a member of __FILE. "/opt/developerstudio124/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 170: Error: __pad is not a member of __FILE. Guess need to keep a Solaris 11.3 to compile OpenJDK! Cheers, Andrew -- Andrew Watkins * Birkbeck, University of London * Computer Science * * http://notallmicrosoft.blogspot.com * * UKOUG Systems SIG Chair * * UKOUG Tech committee * * tel: 020 7631 6720 * From erik.joelsson at oracle.com Thu Jan 17 21:39:53 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Jan 2019 13:39:53 -0800 Subject: Building OpenJDK10 with Solaris 11.4 x86_64 In-Reply-To: <37d87c8b-a9ce-b40a-b3c5-7eb543ff8125@dcs.bbk.ac.uk> References: <37d87c8b-a9ce-b40a-b3c5-7eb543ff8125@dcs.bbk.ac.uk> Message-ID: <4d7b2310-f9f3-f7dd-2346-3041b47013b7@oracle.com> Hello Andrew, JDK 10 is not longer being maintained AFAIK so would be surprised if anyone would try to fix this there. Regarding Solaris 11.4, we at Oracle have not tried building any version of the JDK there. We have to stick to the oldest version of Solaris that we support to produce binaries that are compatible, and for JDK 12 and 13 that is (at least for now) 11.3. I don't remember exactly which version it was for JDK 11. /Erik On 2019-01-17 12:45, Andrew Watkins wrote: > Hi, > > Just wondered if anyone has tried building OpenJDK10 under Solaris > 11.4 x86_64 yet? > > Trying to build it on an solaris-x86_64 and not getting very far. > > 1) "os_solaris.cpp", line 1666: Error: EM_486 is not defined. Ref: > https://bugs.openjdk.java.net/browse/JDK-8182035?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel > > > ??? Solaris 11.4 has removed EM_486, but that a quick fix is in > os_solaris.cpp: > > ??? #ifndef EM_486 > ??? #define EM_486????????? 6?????????????? /* Intel 80486 */ > ??? #endif > > 2) But then I get tons of the following: > > "/opt/developerstudio124/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 165: Error: __pad is not a member of const __FILE. > "/opt/developerstudio124/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 167: Error: __pad is not a member of const __FILE. > "/opt/developerstudio124/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 170: Error: __pad is not a member of __FILE. > "/opt/developerstudio124/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 170: Error: __pad is not a member of __FILE. > > Guess need to keep a Solaris 11.3 to compile OpenJDK! > > Cheers, > > Andrew > From rob.petti at gmail.com Thu Jan 17 21:57:20 2019 From: rob.petti at gmail.com (Rob Petti) Date: Thu, 17 Jan 2019 21:57:20 +0000 Subject: OpenJDK 11.0.2 cannot build on Solaris 11.4 Message-ID: Hey Folks, I've discovered that OpenJDK 11 cannot be built on Solaris 11.4. Normally we would just try to rebuild our system as 11.1, but that's not possible since media for that base release is no longer available. Are there plans to support compilation on Oracle's latest and greatest, or at least provide a proper method of building in such an environment? For the record, here are the errors I'm getting. This is with solarisstudio 12.4 (which BTW wouldn't install on Solaris 11.4 without unfreezing the python version): # bash configure --with-boot-jdk= --with-devkit=/opt/solarisstudio12.4 # gmake bootcycle-images ... Compiling 163 files for jdk.jfr "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1580: Error: EM_486 is not defined. "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1618: Error: The type "const arch_t[]" is incomplete. 2 Error(s) detected. gmake[3]: *** [lib/CompileJvm.gmk:151: /root/jdk11/jdk11u/build/solaris-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/os_solaris.o] Error 2 After patching with http://robpetti.com/files/jdk11-sol114.patch to fix https://bugs.openjdk.java.net/browse/JDK-8182035, it gets a bit further, but still fails: Compiling 64 files for jdk.jconsole "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 161: Error: __pad is not a member of const __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 163: Error: __pad is not a member of const __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 165: Error: __pad is not a member of const __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 165: Error: __pad is not a member of const __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 167: Error: __pad is not a member of const __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 170: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 170: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 172: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 172: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 174: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 174: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 176: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 176: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 178: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 178: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 182: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 183: Error: __pad is not a member of __FILE. "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", line 184: Error: __pad is not a member of __FILE. 18 Error(s) detected. It seems the "right" way to do this would be to create a sysroot with older 11.1 headers and libraries, and compile against that. Unfortunately the --with-sysroot configure option does not completely work correctly. The compiler still tries to include /usr/include instead of the sysroot headers, and that just results in more build errors. The only way it seems to truly get it to use the sysroot was to physically replace /usr/include on the machine with the version from the sysroot. This is obviously less than ideal. Is the --with-sysroot issue already known? Is there any other way around it aside from manually replacing headers in the system just to compile the JDK? -- Rob Petti about.me/robpetti From magnus.ihse.bursie at oracle.com Fri Jan 18 12:59:28 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Jan 2019 13:59:28 +0100 Subject: RFR: JDK-8217335: Add a script to generate --release data In-Reply-To: <5C40CEBE.9090300@oracle.com> References: <5C40CEBE.9090300@oracle.com> Message-ID: On 2019-01-17 19:51, Jan Lahoda wrote: > Hi, > > As suggested here: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012876.html > > > This is a separate patch that adds a script to generate --release N data. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8217335 > > Jan Hi Jan, I would recommend that you place the generate-data script in make/scripts; it's the default location for scripts -- make/data is reserved for, eh, data. :) But a bit more descriptive name would be suitable when moving it away from make/data/symbols -- perhaps generate-symbol-data? Also, the update to the README file does not seem correct. I assume you want to point to the new generate-data script, but the path is wrong (even for the location in your current patch). Finally, we in the build team always appreciates if you cc build-dev for changes in the make directory, even if it's not strictly part of the build system. /Magnus From magnus.ihse.bursie at oracle.com Fri Jan 18 13:29:26 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Jan 2019 14:29:26 +0100 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2) In-Reply-To: <293257d2-a998-0837-fc0a-d491098078d0@oracle.com> References: <01b01dba-73bf-155c-109d-11e88f0b27d6@oracle.com> <293257d2-a998-0837-fc0a-d491098078d0@oracle.com> Message-ID: <59337a52-7247-e28a-b448-8e23f12fdec4@oracle.com> On 2019-01-17 16:06, Andy Herrick wrote: > > If I remove the line -nologo from lib-jdk.jpackage.gmk: > >> 69 LDFLAGS_windows := -nologo, \ > I get the logo during build (same with console andnon-console version): >> Microsoft (R) Incremental Linker Version 14.12.25835.0 >> Copyright (C) Microsoft Corporation.? All rights reserved. > do I need something to include CXXFLAGS_JDKEXE into LDFLAGS ? (there > is no other LDFLAGS line...) Ah, good catch. You should add LDFLAGS := $(LDFLAGS_JDKEXE), \ to your setup. /Magnus > here's the non-console APPLAUNCHERWEXE case: > >> # Build non-console version of launcher >> ifeq ($(OPENJDK_TARGET_OS), windows) >> >> ? $(eval $(call SetupJdkExecutable, BUILD_JPACKAGE_APPLAUNCHERWEXE, \ >> ????? NAME := jpackageapplauncherw, \ >> ????? OUTPUT_DIR := >> $(JDK_OUTPUTDIR)/modules/$(MODULE)/jdk/jpackage/internal/resources, \ >> ????? SYMBOLS_DIR := >> $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/jpackageapplauncherw, \ >> ????? SRC := $(JPACKAGE_APPLAUNCHEREXE_SRC), \ >> ????? TOOLCHAIN := TOOLCHAIN_LINK_CXX, \ >> ????? OPTIMIZATION := LOW, \ >> ????? CFLAGS := $(CXXFLAGS_JDKEXE), \ >> ????? CFLAGS_windows := -EHsc -DUNICODE -D_UNICODE, \ >> ????? LDFLAGS_windows := -nologo, \ >> <------------------------------------- >> ????? LIBS := $(LIBCXX), \ >> ????? LIBS_windows :=? user32.lib shell32.lib advapi32.lib, \ >> ? )) >> >> ? TARGETS += $(BUILD_JPACKAGE_APPLAUNCHERWEXE) >> endif > > /Andy > > > On 1/15/2019 8:09 AM, Magnus Ihse Bursie wrote: >> Hi Andy, >> >> This is looking really sweet from a build perspective! >> >> Just a few minor nits: >> >> * In Launcher-jdk.jpackage.gmk, please indent the else clause >> ("$(eval $(call SetupBuildLauncher, jpackage ....") two spaces. >> >> * In Lib-jdk.jpackage.gmk, I think there's still room to prune some >> more unnecessary compiler flags and parameters to SetupJdkExecutable: >> 65 CFLAGS_linux := -fPIC, \ >> 66 CFLAGS_solaris := -KPIC, \ >> 67 CFLAGS_macosx := -fPIC, \ >> ?I wonder if these really are needed. Normally, only shared libraries >> neeed PIC code. (And for those we set it automatically.) >> >> 69 LDFLAGS_windows := -nologo, \ >> This should not be needed, it's incorporated in CXXFLAGS_JDKEXE. >> (Also in the second block, for jpackageapplauncherw). >> >> 72 LIBS_solaris := -lc, \ >> Same here; this should not be needed. It's in GLOBAL_LIBS on Solaris, >> and is always included. >> >> 75 VERSIONINFO_RESOURCE := $(GLOBAL_VERSION_INFO_RESOURCE), \ >> This is setup by default by SetupJdkExecutable, so you can remove it. >> (Also in the second block, for jpackageapplauncherw). >> >> Finally, I do believe that the setups of jpackageapplauncher and >> jpackageapplauncherw should be done in Launcher-jdk.jpackage.gmk, not >> Lib-jdk.jpackage.gmk. Since they are to be shipped as resources, they >> are not "really" launchers in our normal sense, but they are at least >> more launchers than they are libraries. >> >> As we've talked about privately, in the future I'd like to see >> Windows too use the SetupBuildLauncher method for creating the >> launcher, but this is clearly good enough for inclusion in the mainline. >> >> I also have a question about >> test/jdk/tools/jpackage/resources/license.txt. What is it used for? >> And why the odd (incorrect?) spelling of license? >> >> /Magnus >> >> On 2019-01-11 20:41, Andy Herrick wrote: >>> This is the second update to the Request For Review of the >>> implementation of the Java Packager Tool (jpackager) as described in >>> JEP 343: Packaging Tool >>> >>> >>> >>> This webrev corresponds to the second EA build, Build 8 (2019/1/8), >>> posted at http://jdk.java.net/jpackage/ >>> >>> This update renames the package used to "jdk.jpackage", removes the >>> Single Instance Service (and CLI option --singleton), adds several >>> other CLI options, adds more automated tests, and contains fixes to >>> the following issues (since update 1 on 11/09/2018): >>> >>> JDK-8212164???? resolve jre.list and jre.module.list >>> JDK-8212936???? Makefile and other improvements for jpackager >>> JDK-8213385???? jpackager Command-Line Argument File. >>> JDK-8213392???? Enhance --help and --version >>> JDK-8213425???? Analyze output from Source code scanner and fix >>> where needed. >>> JDK-8213747???? Makefile Improvements to Lib-jdk.packager.gmk >>> JDK-8213748???? jpackager native launcher for macosx, linux. >>> JDK-8213756???? SingleInstance runtime improvements >>> JDK-8213962???? JPackageCreateImageRuntimeModuleTest fails >>> JDK-8213963???? Flatten out jpackager packages and resources. >>> JDK-8214021???? Create additional automated tests for jpackager >>> JDK-8214051???? rename jpackager tool to jpackage >>> JDK-8214070???? Analyze and Fix issues reported by Parfait >>> JDK-8214143???? Reduce Resource files >>> JDK-8214495???? Change behavior of --license-file >>> JDK-8214575???? Exe installers will install application over >>> existing installation >>> JDK-8214899???? rename papplauncher and it's library and move src to >>> appropriate places >>> JDK-8214982???? jpackage causes failures in existing HelpFlagsTest >>> and VersionCheck tests >>> JDK-8215020???? create-jre-installer exe fails when --runtime-image >>> is specified. >>> JDK-8215036???? Create initial set of tests for jpackage >>> create-installer mode >>> JDK-8215453???? remove unused BundlerParams and fix misleading messages >>> JDK-8215515???? Add a command line option to override internal >>> resources. >>> JDK-8215900???? Without --files args, only jars in the top level of >>> --input are added to class-path >>> JDK-8215903???? modify behavior of retaining temporary output dir >>> JDK-8216190???? Remove Single Instance Service support from jpackage >>> JDK-8216313???? Add ToolProvider information to jdk.jpackage API docs >>> JDK-8216373???? temporary build-root left behind when using >>> secondary launcher(s) >>> JDK-8216492???? Update copyright of all new jpackage files to 2019 >>> >>> Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.03 >>> >>> Note: SingleInstanceService API was removed (see >>> https://bugs.openjdk.java.net/browse/JDK-8216190). >>> An example stand alone implementation can be found at: >>> http://cr.openjdk.java.net/~herrick/jpackage/Singleton.java >>> >>> please send feedback to core-libs-dev at openjdk.java.net >>> >>> /Andy Herrick >>> >> > From jan.lahoda at oracle.com Fri Jan 18 17:05:59 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 Jan 2019 18:05:59 +0100 Subject: RFR: JDK-8217335: Add a script to generate --release data In-Reply-To: References: <5C40CEBE.9090300@oracle.com> Message-ID: <5C420777.6080007@oracle.com> Hi Magnus, Thanks for the comments, an updated webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.01/ (Includes changes suggested by Joe was well). Jan On 18.1.2019 13:59, Magnus Ihse Bursie wrote: > On 2019-01-17 19:51, Jan Lahoda wrote: >> Hi, >> >> As suggested here: >> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012876.html >> >> >> This is a separate patch that adds a script to generate --release N data. >> >> Webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8217335 >> >> Jan > Hi Jan, > > I would recommend that you place the generate-data script in > make/scripts; it's the default location for scripts -- make/data is > reserved for, eh, data. :) But a bit more descriptive name would be > suitable when moving it away from make/data/symbols -- perhaps > generate-symbol-data? > > Also, the update to the README file does not seem correct. I assume you > want to point to the new generate-data script, but the path is wrong > (even for the location in your current patch). > > Finally, we in the build team always appreciates if you cc build-dev for > changes in the make directory, even if it's not strictly part of the > build system. > > /Magnus From jan.lahoda at oracle.com Fri Jan 18 17:06:44 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 Jan 2019 18:06:44 +0100 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <5C40CF23.4050608@oracle.com> References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com> <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com> <5C40B289.7070408@oracle.com> <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com> <5C40CF23.4050608@oracle.com> Message-ID: <5C4207A4.1040203@oracle.com> Adding build-dev. Jan On 17.1.2019 19:53, Jan Lahoda wrote: > On 17.1.2019 17:58, Jonathan Gibbons wrote: >> Re: >> >> 36 # The checkout must not have any local changes that could >> interfere with the new data. In particular, >> 37 # there must be absolutely no changed, new or removed files >> under the ${JDK_CHECKOUT}/make/data/symbols >> 38 # directory. >> >> That seems like a simple check that could be incorporated into the >> script itself. >> >> But, it also seems reasonable to separate enhancements like that from >> the specific issue here, to add historical data for 12. > > Ok. Sent as: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html > > > And limited this patch to the historical data only: > http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/ > > Thanks, > Jan > >> >> -- Jon >> >> On 1/17/19 8:51 AM, Jan Lahoda wrote: >>> Hi Joe, >>> >>> On 17.1.2019 02:13, Joseph D. Darcy wrote: >>>> Hi Jan, >>>> >>>> On 1/8/2019 2:13 AM, Jan Lahoda wrote: >>>>> Hi Joe, >>>>> >>>>> Thanks for the comments, some responses inline. Updated webrev: >>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/ >>>>> >>>>> On 7.1.2019 23:51, Joseph D. Darcy wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> To make --release 12 work, we need to add historical data for JDK >>>>>>> 12. >>>>>>> The current historical data is based on: >>>>>>> $ javac -fullversion >>>>>>> javac full version "12-ea+26" >>>>>>> >>>>>>> We may need to update the data once JDK 12 is out to cover any >>>>>>> changes >>>>>>> to the APIs that might happen. >>>>>>> >>>>>>> The patch also adds a simple (shell) script to generate the data, so >>>>>>> all that was needed to generate the data was: >>>>>>> $ cd make/data/symbols >>>>>>> $ sh generate-data >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 >>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >>>>>>> >>>>>>> How does this look? >>>>>> >>>>>> If the overhead is small enough and we don't mind a few updates to >>>>>> the >>>>>> JDK N+1 data, than perhaps the generation of this information >>>>>> could be >>>>>> included as part of the start of JDK N+1 activities. >>>>> >>>>> That would be perfect! >>>>> >>>>>> >>>>>> I suggest a more extensive description of how to >>>>>> make/data/symbols/generate-data. For example, this builds the data >>>>>> for >>>>>> the current release independent of whether or not the current release >>>>>> has already had its data generated, correct? >>>>> >>>>> Yes. >>>>> >>>>>> >>>>>> Concretely, if JDK N+1 has already forked, what is the proper way >>>>>> to get >>>>>> data for JDK N? Likewise, how should a re-build of the data for JDK >>>>>> N be >>>>>> done? >>>>> >>>>> What exactly should be there? To the existing description: >>>>> # to generate (add) data for JDK N, do: >>>>> # cd make/data/symbols >>>>> # sh generate-data >>>>> >>>>> I've added (in .01): >>>>> # to regenerate the data for JDK N, run the above commands again >>>>> >>>>> What more should be there? >>>>> >>>> >>>> I'd appreciate somewhere to have a textual discussion of how >>>> make/data/symbols/symbols should be updated, the A = 10, B = 11, etc. >>>> convention, what else need to be done to generate the contents of this >>>> changeset. >>>> >>>> The is the contents of the build directory? >>>> >>>> In general, a description of how the data of JDK N should be added to >>>> JDK (N+1). >>> >>> I've added more textual description to the script, an updated webrev >>> is here: >>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/ >>> >>> Jan >>> >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> From erik.joelsson at oracle.com Fri Jan 18 17:23:36 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Jan 2019 09:23:36 -0800 Subject: OpenJDK 11.0.2 cannot build on Solaris 11.4 In-Reply-To: References: Message-ID: Hello Rob, On 2019-01-17 13:57, Rob Petti wrote: > Hey Folks, > > I've discovered that OpenJDK 11 cannot be built on Solaris 11.4. Normally > we would just try to rebuild our system as 11.1, but that's not possible > since media for that base release is no longer available. > > Are there plans to support compilation on Oracle's latest and greatest, or > at least provide a proper method of building in such an environment? I can't speak for all OpenJDK contributors, but Oracle has no current plans for this. We are required to build on the oldest supported Solaris version to produce binaries that are compatible with that version. We do not produce different binaries for different versions of an OS. Also, as I understand it, Oracle is no longer involved in open support of 11u. Perhaps the new maintainer will accept contributions for fixing the issue. > For the record, here are the errors I'm getting. This is with solarisstudio > 12.4 (which BTW wouldn't install on Solaris 11.4 without unfreezing the > python version): > > # bash configure --with-boot-jdk= > --with-devkit=/opt/solarisstudio12.4 > # gmake bootcycle-images > ... > Compiling 163 files for jdk.jfr > "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1580: > Error: EM_486 is not defined. > "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1618: > Error: The type "const arch_t[]" is incomplete. > 2 Error(s) detected. > gmake[3]: *** [lib/CompileJvm.gmk:151: > /root/jdk11/jdk11u/build/solaris-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/os_solaris.o] > Error 2 > > After patching with http://robpetti.com/files/jdk11-sol114.patch to fix > https://bugs.openjdk.java.net/browse/JDK-8182035, it gets a bit further, > but still fails: > > Compiling 64 files for jdk.jconsole > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 161: Error: __pad is not a member of const __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 163: Error: __pad is not a member of const __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 165: Error: __pad is not a member of const __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 165: Error: __pad is not a member of const __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 167: Error: __pad is not a member of const __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 170: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 170: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 172: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 172: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 174: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 174: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 176: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 176: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 178: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 178: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 182: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 183: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 184: Error: __pad is not a member of __FILE. > 18 Error(s) detected. > > It seems the "right" way to do this would be to create a sysroot with older > 11.1 headers and libraries, and compile against that. Unfortunately the > --with-sysroot configure option does not completely work correctly. The > compiler still tries to include /usr/include instead of the sysroot > headers, and that just results in more build errors. The only way it seems > to truly get it to use the sysroot was to physically replace /usr/include > on the machine with the version from the sysroot. This is obviously less > than ideal. We have tried to get sysroot working on Solaris, and we are using it internally, against the recommendation of the Solaris team. It's not working perfectly though. According to the Solaris team, Solaris Studio does not support the concept of a sysroot. Their recommendation is to create zones with the OS version you need and build in those, which I find incredibly annoying. 11u should build fine on either 11.2 or 11.3 though. > Is the --with-sysroot issue already known? Is there any other way around it > aside from manually replacing headers in the system just to compile the JDK? > For includes, I thought we had sysroot working pretty OK at this point. We use -I-xbuiltin to fool CC into thinking our $SYSROOT/usr/include is the actual /usr/include. Though, I have only tried it and seen it work with certain combinations of host OS versions and sysroots, and 11.4 is not in that list. You could try the open/make/devkit/createSolarisDevkit12.4.sh script and see if that helps you build something that works better. That's what we use at Oracle. /Erik From rob.petti at gmail.com Fri Jan 18 18:17:06 2019 From: rob.petti at gmail.com (Rob Petti) Date: Fri, 18 Jan 2019 11:17:06 -0700 Subject: OpenJDK 11.0.2 cannot build on Solaris 11.4 In-Reply-To: References: Message-ID: Thanks, Erik! I tried the createSolarisDevkit12.4.sh script, but none of the packages in that list exist in the package manager at those specific versions, so it just fails. I basically had to make my own list of packages from scratch using the existing one as a guideline. Zones sound like a cleaner solution to me, but I don't know enough about them to know how to install a specific base OS version. All the docs I find just install the same version as the 'host'. I'll need to do a bunch more research, it seems... On Fri, Jan 18, 2019 at 5:17 PM Erik Joelsson wrote: > Hello Rob, > > On 2019-01-17 13:57, Rob Petti wrote: > > Hey Folks, > > > > I've discovered that OpenJDK 11 cannot be built on Solaris 11.4. Normally > > we would just try to rebuild our system as 11.1, but that's not possible > > since media for that base release is no longer available. > > > > Are there plans to support compilation on Oracle's latest and greatest, > or > > at least provide a proper method of building in such an environment? > > I can't speak for all OpenJDK contributors, but Oracle has no current > plans for this. We are required to build on the oldest supported Solaris > version to produce binaries that are compatible with that version. We do > not produce different binaries for different versions of an OS. Also, as > I understand it, Oracle is no longer involved in open support of 11u. > Perhaps the new maintainer will accept contributions for fixing the issue. > > > For the record, here are the errors I'm getting. This is with > solarisstudio > > 12.4 (which BTW wouldn't install on Solaris 11.4 without unfreezing the > > python version): > > > > # bash configure --with-boot-jdk= > > --with-devkit=/opt/solarisstudio12.4 > > # gmake bootcycle-images > > ... > > Compiling 163 files for jdk.jfr > > "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1580: > > Error: EM_486 is not defined. > > "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1618: > > Error: The type "const arch_t[]" is incomplete. > > 2 Error(s) detected. > > gmake[3]: *** [lib/CompileJvm.gmk:151: > > > /root/jdk11/jdk11u/build/solaris-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/os_solaris.o] > > Error 2 > > > > After patching with http://robpetti.com/files/jdk11-sol114.patch to fix > > https://bugs.openjdk.java.net/browse/JDK-8182035, it gets a bit further, > > but still fails: > > > > Compiling 64 files for jdk.jconsole > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 161: Error: __pad is not a member of const __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 163: Error: __pad is not a member of const __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 165: Error: __pad is not a member of const __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 165: Error: __pad is not a member of const __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 167: Error: __pad is not a member of const __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 170: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 170: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 172: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 172: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 174: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 174: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 176: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 176: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 178: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 178: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 182: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 183: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 184: Error: __pad is not a member of __FILE. > > 18 Error(s) detected. > > > > It seems the "right" way to do this would be to create a sysroot with > older > > 11.1 headers and libraries, and compile against that. Unfortunately the > > --with-sysroot configure option does not completely work correctly. The > > compiler still tries to include /usr/include instead of the sysroot > > headers, and that just results in more build errors. The only way it > seems > > to truly get it to use the sysroot was to physically replace /usr/include > > on the machine with the version from the sysroot. This is obviously less > > than ideal. > We have tried to get sysroot working on Solaris, and we are using it > internally, against the recommendation of the Solaris team. It's not > working perfectly though. According to the Solaris team, Solaris Studio > does not support the concept of a sysroot. Their recommendation is to > create zones with the OS version you need and build in those, which I > find incredibly annoying. 11u should build fine on either 11.2 or 11.3 > though. > > Is the --with-sysroot issue already known? Is there any other way around > it > > aside from manually replacing headers in the system just to compile the > JDK? > > > For includes, I thought we had sysroot working pretty OK at this point. > We use -I-xbuiltin to fool CC into thinking our $SYSROOT/usr/include is > the actual /usr/include. Though, I have only tried it and seen it work > with certain combinations of host OS versions and sysroots, and 11.4 is > not in that list. > > You could try the open/make/devkit/createSolarisDevkit12.4.sh script and > see if that helps you build something that works better. That's what we > use at Oracle. > > /Erik > > -- Rob Petti about.me/robpetti From erik.joelsson at oracle.com Fri Jan 18 19:09:41 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Jan 2019 11:09:41 -0800 Subject: OpenJDK 11.0.2 cannot build on Solaris 11.4 In-Reply-To: References: Message-ID: <741c5234-f531-3485-cb45-947294805360@oracle.com> On 2019-01-18 10:17, Rob Petti wrote: > Thanks, Erik! > > I tried the createSolarisDevkit12.4.sh > script, but none of the packages > in that list exist in the package manager at those specific versions, > so it just fails. I basically had to make my own list of packages from > scratch using the existing one as a guideline. > > Zones sound like a cleaner solution to me, but I don't know enough > about them to know how to install a specific base OS version. All the > docs I find just install the same version as the 'host'. I'll need to > do a bunch more research, it seems... > I know there is a difference between zones running the same OS version and those that run a different. I believe you need what's called a kernel zone to run a different version. /Erik > On Fri, Jan 18, 2019 at 5:17 PM Erik Joelsson > > wrote: > > Hello Rob, > > On 2019-01-17 13:57, Rob Petti wrote: > > Hey Folks, > > > > I've discovered that OpenJDK 11 cannot be built on Solaris 11.4. > Normally > > we would just try to rebuild our system as 11.1, but that's not > possible > > since media for that base release is no longer available. > > > > Are there plans to support compilation on Oracle's latest and > greatest, or > > at least provide a proper method of building in such an environment? > > I can't speak for all OpenJDK contributors, but Oracle has no current > plans for this. We are required to build on the oldest supported > Solaris > version to produce binaries that are compatible with that version. > We do > not produce different binaries for different versions of an OS. > Also, as > I understand it, Oracle is no longer involved in open support of 11u. > Perhaps the new maintainer will accept contributions for fixing > the issue. > > > For the record, here are the errors I'm getting. This is with > solarisstudio > > 12.4 (which BTW wouldn't install on Solaris 11.4 without > unfreezing the > > python version): > > > > # bash configure --with-boot-jdk= > > --with-devkit=/opt/solarisstudio12.4 > > # gmake bootcycle-images > > ... > > Compiling 163 files for jdk.jfr > > "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line > 1580: > > Error: EM_486 is not defined. > > "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line > 1618: > > Error: The type "const arch_t[]" is incomplete. > > 2 Error(s) detected. > > gmake[3]: *** [lib/CompileJvm.gmk:151: > > > /root/jdk11/jdk11u/build/solaris-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/os_solaris.o] > > Error 2 > > > > After patching with http://robpetti.com/files/jdk11-sol114.patch > to fix > > https://bugs.openjdk.java.net/browse/JDK-8182035, it gets a bit > further, > > but still fails: > > > > Compiling 64 files for jdk.jconsole > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 161: Error: __pad is not a member of const __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 163: Error: __pad is not a member of const __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 165: Error: __pad is not a member of const __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 165: Error: __pad is not a member of const __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 167: Error: __pad is not a member of const __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 170: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 170: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 172: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 172: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 174: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 174: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 176: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 176: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 178: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 178: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 182: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 183: Error: __pad is not a member of __FILE. > > > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > > line 184: Error: __pad is not a member of __FILE. > > 18 Error(s) detected. > > > > It seems the "right" way to do this would be to create a sysroot > with older > > 11.1 headers and libraries, and compile against that. > Unfortunately the > > --with-sysroot configure option does not completely work > correctly. The > > compiler still tries to include /usr/include instead of the sysroot > > headers, and that just results in more build errors. The only > way it seems > > to truly get it to use the sysroot was to physically replace > /usr/include > > on the machine with the version from the sysroot. This is > obviously less > > than ideal. > We have tried to get sysroot working on Solaris, and we are using it > internally, against the recommendation of the Solaris team. It's not > working perfectly though. According to the Solaris team, Solaris > Studio > does not support the concept of a sysroot. Their recommendation is to > create zones with the OS version you need and build in those, which I > find incredibly annoying. 11u should build fine on either 11.2 or > 11.3 > though. > > Is the --with-sysroot issue already known? Is there any other > way around it > > aside from manually replacing headers in the system just to > compile the JDK? > > > For includes, I thought we had sysroot working pretty OK at this > point. > We use -I-xbuiltin to fool CC into thinking our > $SYSROOT/usr/include is > the actual /usr/include. Though, I have only tried it and seen it > work > with certain combinations of host OS versions and sysroots, and > 11.4 is > not in that list. > > You could try the open/make/devkit/createSolarisDevkit12.4.sh > script and > see if that helps you build something that works better. That's > what we > use at Oracle. > > /Erik > > > > -- > > > Rob Petti > about.me/robpetti > > > From alexandre.iline at oracle.com Fri Jan 18 23:09:29 2019 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 18 Jan 2019 15:09:29 -0800 Subject: RFR 8217357: Implement JCov jib profiles Message-ID: Hi. Please take a look on a change which is adding new jib profiles to support make changes introduced by JDK-8214309. Bug: https://bugs.openjdk.java.net/browse/JDK-8217357 Webrev: http://cr.openjdk.java.net/~shurailine/8217357/webrev.02/ Thank you. Shura From vladimir.x.ivanov at oracle.com Fri Jan 18 23:33:31 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Jan 2019 15:33:31 -0800 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled Message-ID: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8217404 --with-jvm-features doesn't work properly when multiple features are explicitly disabled: $ bash configure --with-jvm-features="-aot -jvmci -graal" ... checking if jvmci module jdk.internal.vm.ci should be built... yes checking if graal module jdk.internal.vm.compiler should be built... yes checking if aot should be enabled... yes ... The problem in the following code: DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot` if test "x$DISABLE_AOT" = "xaot"; then ENABLE_AOT="false" fi Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of explicitly disabled features, grep over it returns the whole list when there's a match. The subsequent check fails because there's no exact match, though DISABLE_AOT contains "aot" . Proposed fix is to check there's no match instead. After the fix it works as expected: $ bash configure --with-jvm-features="-aot -jvmci -graal" ... checking if jvmci module jdk.internal.vm.ci should be built... no, forced checking if graal module jdk.internal.vm.compiler should be built... no, forced checking if aot should be enabled... no, forced ... (The fix doesn't address the case when one feature has a name which is a proper substring of another feature, but there are no such cases at the moment.) Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Fri Jan 18 23:44:19 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jan 2019 15:44:19 -0800 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> Message-ID: I usually used --with-jvm-features=-aot,-jvmci,-graal Did not work in this case too? Anyway your fix is good. Thanks, Vladimir On 1/18/19 3:33 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8217404 > > --with-jvm-features doesn't work properly when multiple features are explicitly disabled: > > $ bash configure --with-jvm-features="-aot -jvmci -graal" > ... > checking if jvmci module jdk.internal.vm.ci should be built... yes > checking if graal module jdk.internal.vm.compiler should be built... yes > checking if aot should be enabled... yes > ... > > The problem in the following code: > > ? DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot` > ? if test "x$DISABLE_AOT" = "xaot"; then > ??? ENABLE_AOT="false" > ? fi > > Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of explicitly disabled features, grep over it returns > the whole list when there's a match. The subsequent check fails because there's no exact match, though DISABLE_AOT > contains "aot" . > > Proposed fix is to check there's no match instead. > > After the fix it works as expected: > > $ bash configure --with-jvm-features="-aot -jvmci -graal" > ... > checking if jvmci module jdk.internal.vm.ci should be built... no, forced > checking if graal module jdk.internal.vm.compiler should be built... no, forced > checking if aot should be enabled... no, forced > ... > > (The fix doesn't address the case when one feature has a name which is a proper substring of another feature, but there > are no such cases at the moment.) > > Best regards, > Vladimir Ivanov From igor.ignatyev at oracle.com Fri Jan 18 23:45:52 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Jan 2019 15:45:52 -0800 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> Message-ID: Hi Vladimir, overall your fix looks reasonable, but w/ it we can get unintentionally disabled features (b/c grep doesn't do full word match). although this problem wasn't really introduced by your fix, I think it's be better to fix it as a part of your patch. I see two possible solutions: - add "-w" to grep, but I am not sure if "-w" is supported by all grep implementations - use $XARGS instead of $ECHO when we get DISABLE_X. in this case you will need to revert your changes in 'if test ...' lines Thanks, -- Igor > On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8217404 > > --with-jvm-features doesn't work properly when multiple features are explicitly disabled: > > $ bash configure --with-jvm-features="-aot -jvmci -graal" > ... > checking if jvmci module jdk.internal.vm.ci should be built... yes > checking if graal module jdk.internal.vm.compiler should be built... yes > checking if aot should be enabled... yes > ... > > The problem in the following code: > > DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot` > if test "x$DISABLE_AOT" = "xaot"; then > ENABLE_AOT="false" > fi > > Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of explicitly disabled features, grep over it returns the whole list when there's a match. The subsequent check fails because there's no exact match, though DISABLE_AOT contains "aot" . > > Proposed fix is to check there's no match instead. > > After the fix it works as expected: > > $ bash configure --with-jvm-features="-aot -jvmci -graal" > ... > checking if jvmci module jdk.internal.vm.ci should be built... no, forced > checking if graal module jdk.internal.vm.compiler should be built... no, forced > checking if aot should be enabled... no, forced > ... > > (The fix doesn't address the case when one feature has a name which is a proper substring of another feature, but there are no such cases at the moment.) > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Sat Jan 19 00:31:03 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Jan 2019 16:31:03 -0800 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> Message-ID: <095dc325-6e6b-7112-56dc-8514c58ad0b7@oracle.com> Thanks, Vladimir. > I usually used --with-jvm-features=-aot,-jvmci,-graal > > Did not work in this case too? I didn't know it supports comma-separated list, but it doesn't work as well: $ bash configure --with-jvm-features="-aot,-jvmci,-graal" checking if jvmci module jdk.internal.vm.ci should be built... yes checking if graal module jdk.internal.vm.compiler should be built... yes checking if aot should be enabled... yes Best regards, Vladimir Ivanov > On 1/18/19 3:33 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8217404 >> >> --with-jvm-features doesn't work properly when multiple features are >> explicitly disabled: >> >> $ bash configure --with-jvm-features="-aot -jvmci -graal" >> ... >> checking if jvmci module jdk.internal.vm.ci should be built... yes >> checking if graal module jdk.internal.vm.compiler should be built... yes >> checking if aot should be enabled... yes >> ... >> >> The problem in the following code: >> >> ?? DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot` >> ?? if test "x$DISABLE_AOT" = "xaot"; then >> ???? ENABLE_AOT="false" >> ?? fi >> >> Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of >> explicitly disabled features, grep over it returns the whole list when >> there's a match. The subsequent check fails because there's no exact >> match, though DISABLE_AOT contains "aot" . >> >> Proposed fix is to check there's no match instead. >> >> After the fix it works as expected: >> >> $ bash configure --with-jvm-features="-aot -jvmci -graal" >> ... >> checking if jvmci module jdk.internal.vm.ci should be built... no, forced >> checking if graal module jdk.internal.vm.compiler should be built... >> no, forced >> checking if aot should be enabled... no, forced >> ... >> >> (The fix doesn't address the case when one feature has a name which is >> a proper substring of another feature, but there are no such cases at >> the moment.) >> >> Best regards, >> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Sat Jan 19 00:39:45 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Jan 2019 16:39:45 -0800 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> Message-ID: <93c9b305-292d-5779-7afe-bb21d7cd9672@oracle.com> Thanks, Igor. > overall your fix looks reasonable, but w/ it we can get unintentionally disabled features (b/c grep doesn't do full word match). although this problem wasn't really introduced by your fix, I think it's be better to fix it as a part of your patch. I see two possible solutions: I was aware of such drawback, but decided to leave it as is, since it doesn't affect existing features. > - add "-w" to grep, but I am not sure if "-w" is supported by all grep implementations > - use $XARGS instead of $ECHO when we get DISABLE_X. in this case you will need to revert your changes in 'if test ...' lines I'm in favor of using "-w" and I see different grep flags being used already, but would like somebody from Build team confirm they are OK with such solution. Best regards, Vladimir Ivanov >> On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov wrote: >> >> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8217404 >> >> --with-jvm-features doesn't work properly when multiple features are explicitly disabled: >> >> $ bash configure --with-jvm-features="-aot -jvmci -graal" >> ... >> checking if jvmci module jdk.internal.vm.ci should be built... yes >> checking if graal module jdk.internal.vm.compiler should be built... yes >> checking if aot should be enabled... yes >> ... >> >> The problem in the following code: >> >> DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot` >> if test "x$DISABLE_AOT" = "xaot"; then >> ENABLE_AOT="false" >> fi >> >> Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of explicitly disabled features, grep over it returns the whole list when there's a match. The subsequent check fails because there's no exact match, though DISABLE_AOT contains "aot" . >> >> Proposed fix is to check there's no match instead. >> >> After the fix it works as expected: >> >> $ bash configure --with-jvm-features="-aot -jvmci -graal" >> ... >> checking if jvmci module jdk.internal.vm.ci should be built... no, forced >> checking if graal module jdk.internal.vm.compiler should be built... no, forced >> checking if aot should be enabled... no, forced >> ... >> >> (The fix doesn't address the case when one feature has a name which is a proper substring of another feature, but there are no such cases at the moment.) >> >> Best regards, >> Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Sat Jan 19 01:26:03 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Jan 2019 17:26:03 -0800 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: <93c9b305-292d-5779-7afe-bb21d7cd9672@oracle.com> References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> <93c9b305-292d-5779-7afe-bb21d7cd9672@oracle.com> Message-ID: <0b40d58e-8267-5a89-5ce5-684b7bb67b1d@oracle.com> Updated webrev: http://cr.openjdk.java.net/~vlivanov/8217404/webrev.01 Verified that it works as expected on Linux, Windows, MacOS, and Solaris. Best regards, Vladimir Ivanov On 18/01/2019 16:39, Vladimir Ivanov wrote: > Thanks, Igor. > >> overall your fix looks reasonable, but w/ it we can get >> unintentionally disabled features (b/c grep doesn't do full word >> match). although this problem wasn't really introduced by your fix, I >> think it's be better to fix it as a part of your patch. I see two >> possible solutions: > > I was aware of such drawback, but decided to leave it as is, since it > doesn't affect existing features. > >> ? -? add "-w" to grep, but I am not sure if "-w" is supported by all >> grep implementations >> ? - use $XARGS instead of $ECHO when we get DISABLE_X. in this case >> you will need to revert your changes in 'if test ...' lines > > I'm in favor of using "-w" and I see different grep flags being used > already, but would like somebody from Build team confirm they are OK > with such solution. > > Best regards, > Vladimir Ivanov > >>> On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov >>> wrote: >>> >>> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8217404 >>> >>> --with-jvm-features doesn't work properly when multiple features are >>> explicitly disabled: >>> >>> $ bash configure --with-jvm-features="-aot -jvmci -graal" >>> ... >>> checking if jvmci module jdk.internal.vm.ci should be built... yes >>> checking if graal module jdk.internal.vm.compiler should be built... yes >>> checking if aot should be enabled... yes >>> ... >>> >>> The problem in the following code: >>> >>> ? DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot` >>> ? if test "x$DISABLE_AOT" = "xaot"; then >>> ??? ENABLE_AOT="false" >>> ? fi >>> >>> Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of >>> explicitly disabled features, grep over it returns the whole list >>> when there's a match. The subsequent check fails because there's no >>> exact match, though DISABLE_AOT contains "aot" . >>> >>> Proposed fix is to check there's no match instead. >>> >>> After the fix it works as expected: >>> >>> $ bash configure --with-jvm-features="-aot -jvmci -graal" >>> ... >>> checking if jvmci module jdk.internal.vm.ci should be built... no, >>> forced >>> checking if graal module jdk.internal.vm.compiler should be built... >>> no, forced >>> checking if aot should be enabled... no, forced >>> ... >>> >>> (The fix doesn't address the case when one feature has a name which >>> is a proper substring of another feature, but there are no such cases >>> at the moment.) >>> >>> Best regards, >>> Vladimir Ivanov >> From igor.ignatyev at oracle.com Sat Jan 19 01:29:05 2019 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Fri, 18 Jan 2019 17:29:05 -0800 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: <0b40d58e-8267-5a89-5ce5-684b7bb67b1d@oracle.com> References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> <93c9b305-292d-5779-7afe-bb21d7cd9672@oracle.com> <0b40d58e-8267-5a89-5ce5-684b7bb67b1d@oracle.com> Message-ID: <431EEFF8-A81A-4D2E-812A-AE47CD01C098@oracle.com> Still looks good to me. ? Igor > On Jan 18, 2019, at 5:26 PM, Vladimir Ivanov wrote: > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8217404/webrev.01 > > Verified that it works as expected on Linux, Windows, MacOS, and Solaris. > > Best regards, > Vladimir Ivanov > >> On 18/01/2019 16:39, Vladimir Ivanov wrote: >> Thanks, Igor. >>> overall your fix looks reasonable, but w/ it we can get unintentionally disabled features (b/c grep doesn't do full word match). although this problem wasn't really introduced by your fix, I think it's be better to fix it as a part of your patch. I see two possible solutions: >> I was aware of such drawback, but decided to leave it as is, since it doesn't affect existing features. >>> - add "-w" to grep, but I am not sure if "-w" is supported by all grep implementations >>> - use $XARGS instead of $ECHO when we get DISABLE_X. in this case you will need to revert your changes in 'if test ...' lines >> I'm in favor of using "-w" and I see different grep flags being used already, but would like somebody from Build team confirm they are OK with such solution. >> Best regards, >> Vladimir Ivanov >>>> On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov wrote: >>>> >>>> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8217404 >>>> >>>> --with-jvm-features doesn't work properly when multiple features are explicitly disabled: >>>> >>>> $ bash configure --with-jvm-features="-aot -jvmci -graal" >>>> ... >>>> checking if jvmci module jdk.internal.vm.ci should be built... yes >>>> checking if graal module jdk.internal.vm.compiler should be built... yes >>>> checking if aot should be enabled... yes >>>> ... >>>> >>>> The problem in the following code: >>>> >>>> DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot` >>>> if test "x$DISABLE_AOT" = "xaot"; then >>>> ENABLE_AOT="false" >>>> fi >>>> >>>> Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of explicitly disabled features, grep over it returns the whole list when there's a match. The subsequent check fails because there's no exact match, though DISABLE_AOT contains "aot" . >>>> >>>> Proposed fix is to check there's no match instead. >>>> >>>> After the fix it works as expected: >>>> >>>> $ bash configure --with-jvm-features="-aot -jvmci -graal" >>>> ... >>>> checking if jvmci module jdk.internal.vm.ci should be built... no, forced >>>> checking if graal module jdk.internal.vm.compiler should be built... no, forced >>>> checking if aot should be enabled... no, forced >>>> ... >>>> >>>> (The fix doesn't address the case when one feature has a name which is a proper substring of another feature, but there are no such cases at the moment.) >>>> >>>> Best regards, >>>> Vladimir Ivanov >>> From vladimir.kozlov at oracle.com Sat Jan 19 01:45:48 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jan 2019 17:45:48 -0800 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: <431EEFF8-A81A-4D2E-812A-AE47CD01C098@oracle.com> References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> <93c9b305-292d-5779-7afe-bb21d7cd9672@oracle.com> <0b40d58e-8267-5a89-5ce5-684b7bb67b1d@oracle.com> <431EEFF8-A81A-4D2E-812A-AE47CD01C098@oracle.com> Message-ID: <96E54E87-7E1C-44FC-8623-330483A66CC9@oracle.com> +1 Thanks Vladimir > On Jan 18, 2019, at 5:29 PM, Igor Ignatev wrote: > > Still looks good to me. > > ? Igor > >> On Jan 18, 2019, at 5:26 PM, Vladimir Ivanov wrote: >> >> Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.01 >> >> Verified that it works as expected on Linux, Windows, MacOS, and Solaris. >> >> Best regards, >> Vladimir Ivanov >> >>>> On 18/01/2019 16:39, Vladimir Ivanov wrote: >>>> Thanks, Igor. >>>> overall your fix looks reasonable, but w/ it we can get unintentionally disabled features (b/c grep doesn't do full word match). although this problem wasn't really introduced by your fix, I think it's be better to fix it as a part of your patch. I see two possible solutions: >>> I was aware of such drawback, but decided to leave it as is, since it doesn't affect existing features. >>>> - add "-w" to grep, but I am not sure if "-w" is supported by all grep implementations >>>> - use $XARGS instead of $ECHO when we get DISABLE_X. in this case you will need to revert your changes in 'if test ...' lines >>> I'm in favor of using "-w" and I see different grep flags being used already, but would like somebody from Build team confirm they are OK with such solution. >>> Best regards, >>> Vladimir Ivanov >>>>> On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov wrote: >>>>> >>>>> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8217404 >>>>> >>>>> --with-jvm-features doesn't work properly when multiple features are explicitly disabled: >>>>> >>>>> $ bash configure --with-jvm-features="-aot -jvmci -graal" >>>>> ... >>>>> checking if jvmci module jdk.internal.vm.ci should be built... yes >>>>> checking if graal module jdk.internal.vm.compiler should be built... yes >>>>> checking if aot should be enabled... yes >>>>> ... >>>>> >>>>> The problem in the following code: >>>>> >>>>> DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot` >>>>> if test "x$DISABLE_AOT" = "xaot"; then >>>>> ENABLE_AOT="false" >>>>> fi >>>>> >>>>> Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of explicitly disabled features, grep over it returns the whole list when there's a match. The subsequent check fails because there's no exact match, though DISABLE_AOT contains "aot" . >>>>> >>>>> Proposed fix is to check there's no match instead. >>>>> >>>>> After the fix it works as expected: >>>>> >>>>> $ bash configure --with-jvm-features="-aot -jvmci -graal" >>>>> ... >>>>> checking if jvmci module jdk.internal.vm.ci should be built... no, forced >>>>> checking if graal module jdk.internal.vm.compiler should be built... no, forced >>>>> checking if aot should be enabled... no, forced >>>>> ... >>>>> >>>>> (The fix doesn't address the case when one feature has a name which is a proper substring of another feature, but there are no such cases at the moment.) >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>> > From kim.barrett at oracle.com Sun Jan 20 08:45:46 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 20 Jan 2019 03:45:46 -0500 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: <095dc325-6e6b-7112-56dc-8514c58ad0b7@oracle.com> References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> <095dc325-6e6b-7112-56dc-8514c58ad0b7@oracle.com> Message-ID: > On Jan 18, 2019, at 7:31 PM, Vladimir Ivanov wrote: > > Thanks, Vladimir. > >> I usually used --with-jvm-features=-aot,-jvmci,-graal >> Did not work in this case too? > > I didn't know it supports comma-separated list, but it doesn't work as well: > > $ bash configure --with-jvm-features="-aot,-jvmci,-graal" > > checking if jvmci module jdk.internal.vm.ci should be built... yes > checking if graal module jdk.internal.vm.compiler should be built... yes > checking if aot should be enabled? yes Isn?t the problem here simply incorrect syntax in that command line? Drop the quotes around the ?with-jvm-features argument and I think it should work fine. From magnus.ihse.bursie at oracle.com Mon Jan 21 08:35:36 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 09:35:36 +0100 Subject: Fwd: Enhancing jaotc to automatically find VS2017 linker In-Reply-To: References: Message-ID: I've completely missed vswhere. It's years and years overdue, but it's nice that Microsoft is finally shipping something like this. :-) We should support using vswhere as the primary way to detect a Visual Studio installation, if it is present, and the user do not override the default selection on the command line. /Magnus -------- Forwarded Message -------- Subject: Enhancing jaotc to automatically find VS2017 linker Date: Fri, 18 Jan 2019 22:16:51 +0000 From: Andrew Luo To: hotspot-compiler-dev at openjdk.java.net Hi, Has there been any plans to enhance jaotc to support automatically finding the link.exe in VS2017?? If not, I am interested in contributing some work to support this. I see that in Linker.java (src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Linker.java) we find link.exe using the environment variables VS?COMNTOOLS, but since in VS2017 and forward, this is not defined, it seems another approach is necessary.? Microsoft suggests that you use vswhere (https://github.com/Microsoft/vswhere, BSD licensed, included with Visual Studio 2017 15.2 and forward) or their COM API to find the latest VS2017 toolset. Anyways, if everyone agrees we should add VS2017 support, there are a few ways to do this (in order of simplest/easiest to most complex): 1.Check that vswhere exists on the system, if it does, call vswhere (out of process ? not sure this is acceptable?) and use that to find the VS2017 link.exe 2.Ship vswhere with the JDK and call it out of process 3.Statically link a copy of vswhere (BSD licensed ? is this okay?) into our code and add a JNI stub to call it 4.Call the COM API in a JNI function to get the latest version of VS2017 Personally I prefer (1), but if out-of-process isn?t acceptable I?m fine with doing (4) or (3). Let me know if you have any comments/feedback on this proposal. Thanks, -Andrew From magnus.ihse.bursie at oracle.com Mon Jan 21 10:00:59 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 11:00:59 +0100 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> <095dc325-6e6b-7112-56dc-8514c58ad0b7@oracle.com> Message-ID: <287fdbad-1daa-e2ef-7618-c63924b77363@oracle.com> On 2019-01-20 09:45, Kim Barrett wrote: >> On Jan 18, 2019, at 7:31 PM, Vladimir Ivanov wrote: >> >> Thanks, Vladimir. >> >>> I usually used --with-jvm-features=-aot,-jvmci,-graal >>> Did not work in this case too? >> I didn't know it supports comma-separated list, but it doesn't work as well: >> >> $ bash configure --with-jvm-features="-aot,-jvmci,-graal" >> >> checking if jvmci module jdk.internal.vm.ci should be built... yes >> checking if graal module jdk.internal.vm.compiler should be built... yes >> checking if aot should be enabled? yes > Isn?t the problem here simply incorrect syntax in that command line? > > Drop the quotes around the ?with-jvm-features argument and I think it should work fine. Let me bring some clarity in the syntax here. For --with-jvm-features, if you want to list multiple features, you can separate them by either space or comma. Both are valid and officially supported. My recommendation, though, is to use comma, to avoid the problem with spaces in command line options. If you want to use spaces, you *must* use quotes. A command line like: bash configure --with-jvm-features=-aot -jvmci would be interpreted as "-jvmci" was a flag for configure, which it is not. There are multiple ways of quoting, you could use ' or ", and include the flag name like "--with-jvm-features=aot graal", or just the argument list. My preference, if I need to use quotes, is to use the style Vladimir uses in his example; I believe that maximizes readability. But, as I said, for --with-jvm-features, I recommend using comma instead, to avoid the quoting issue completely. Internally, the list of enabled/disabled features are treated as lists of space-separated words; but that is an implementation detail and not part of the command-line interface. /Magnus From magnus.ihse.bursie at oracle.com Mon Jan 21 10:06:40 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 11:06:40 +0100 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: <93c9b305-292d-5779-7afe-bb21d7cd9672@oracle.com> References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> <93c9b305-292d-5779-7afe-bb21d7cd9672@oracle.com> Message-ID: On 2019-01-19 01:39, Vladimir Ivanov wrote: > Thanks, Igor. > >> overall your fix looks reasonable, but w/ it we can get >> unintentionally disabled features (b/c grep doesn't do full word >> match). although this problem wasn't really introduced by your fix, I >> think it's be better to fix it as a part of your patch. I see two >> possible solutions: > > I was aware of such drawback, but decided to leave it as is, since it > doesn't affect existing features. > >> ? -? add "-w" to grep, but I am not sure if "-w" is supported by all >> grep implementations >> ? - use $XARGS instead of $ECHO when we get DISABLE_X. in this case >> you will need to revert your changes in 'if test ...' lines > > I'm in favor of using "-w" and I see different grep flags being used > already, but would like somebody from Build team confirm they are OK > with such solution. I think an even better solution is to use the pattern of HOTSPOT_CHECK_JVM_FEATURE. This should solve all potential problems, and is moving the abstraction level up slightly. I've been working for some time now on better structure for handling the JVM feature testing. While we are using the feature testing as I intended it, the underlying support for doing this in a good way has never been put into place. Unfortunately, this fix has been on low priority and been mostly idling on my disk, half done, for several months now. So we need to have an interim solution to this problem. But I'd like to see that the fix takes at least a step towards a better abstraction. Vladimir, if you're okay with it I'd like to propose this as a patch to the problem instead: http://cr.openjdk.java.net/~ihse/JDK-8217404-fix-multiple-disabled-jvm-features/webrev.01 /Magnus > > Best regards, > Vladimir Ivanov > >>> On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov >>> wrote: >>> >>> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8217404 >>> >>> --with-jvm-features doesn't work properly when multiple features are >>> explicitly disabled: >>> >>> $ bash configure --with-jvm-features="-aot -jvmci -graal" >>> ... >>> checking if jvmci module jdk.internal.vm.ci should be built... yes >>> checking if graal module jdk.internal.vm.compiler should be built... >>> yes >>> checking if aot should be enabled... yes >>> ... >>> >>> The problem in the following code: >>> >>> ? DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot` >>> ? if test "x$DISABLE_AOT" = "xaot"; then >>> ??? ENABLE_AOT="false" >>> ? fi >>> >>> Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of >>> explicitly disabled features, grep over it returns the whole list >>> when there's a match. The subsequent check fails because there's no >>> exact match, though DISABLE_AOT contains "aot" . >>> >>> Proposed fix is to check there's no match instead. >>> >>> After the fix it works as expected: >>> >>> $ bash configure --with-jvm-features="-aot -jvmci -graal" >>> ... >>> checking if jvmci module jdk.internal.vm.ci should be built... no, >>> forced >>> checking if graal module jdk.internal.vm.compiler should be built... >>> no, forced >>> checking if aot should be enabled... no, forced >>> ... >>> >>> (The fix doesn't address the case when one feature has a name which >>> is a proper substring of another feature, but there are no such >>> cases at the moment.) >>> >>> Best regards, >>> Vladimir Ivanov >> From magnus.ihse.bursie at oracle.com Mon Jan 21 10:14:23 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 11:14:23 +0100 Subject: RFR: JDK-8217335: Add a script to generate --release data In-Reply-To: <5C420777.6080007@oracle.com> References: <5C40CEBE.9090300@oracle.com> <5C420777.6080007@oracle.com> Message-ID: <55467651-7090-0c6b-fbf3-7bbde0119b65@oracle.com> On 2019-01-18 18:05, Jan Lahoda wrote: > Hi Magnus, > > Thanks for the comments, an updated webrev: > http://cr.openjdk.java.net/~jlahoda/8217335/webrev.01/ > > (Includes changes suggested by Joe was well). Looks good to me! /Magnus > > Jan > > On 18.1.2019 13:59, Magnus Ihse Bursie wrote: >> On 2019-01-17 19:51, Jan Lahoda wrote: >>> Hi, >>> >>> As suggested here: >>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012876.html >>> >>> >>> >>> This is a separate patch that adds a script to generate --release N >>> data. >>> >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217335 >>> >>> Jan >> Hi Jan, >> >> I would recommend that you place the generate-data script in >> make/scripts; it's the default location for scripts -- make/data is >> reserved for, eh, data. :) But a bit more descriptive name would be >> suitable when moving it away from make/data/symbols -- perhaps >> generate-symbol-data? >> >> Also, the update to the README file does not seem correct. I assume you >> want to point to the new generate-data script, but the path is wrong >> (even for the location in your current patch). >> >> Finally, we in the build team always appreciates if you cc build-dev for >> changes in the make directory, even if it's not strictly part of the >> build system. >> >> /Magnus From magnus.ihse.bursie at oracle.com Mon Jan 21 10:41:10 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 11:41:10 +0100 Subject: RFR: JDK-8217269: jpackage Makefile improvments In-Reply-To: References: Message-ID: <6e7cb4f1-be9a-8d6f-a348-be3adfa78af1@oracle.com> On 2019-01-18 15:18, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > The webrev includes all the jpackage Makefile Improvements listed in > [1], other than what is covered by [4], and also includes fix for > white space errors requested in [3]. Looks good to me! Thanks for fixing this. In the future, please cc build-dev for build related fixes. /Magnus > > [1] https://bugs.openjdk.java.net/browse/JDK-8217269 > > [2] http://cr.openjdk.java.net/~herrick/8217269/webrev.01/ > > [3] https://bugs.openjdk.java.net/browse/JDK-8216521 > > [4] https://bugs.openjdk.java.net/browse/JDK-8217317 > > /Andy > From magnus.ihse.bursie at oracle.com Mon Jan 21 10:54:42 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 11:54:42 +0100 Subject: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows In-Reply-To: <3beb529d2c93e6a9ef2efd2a153b4eea@xs4all.nl> References: <254b4b94abcb9f1cd5274f25f1cac0bb@xs4all.nl> <32abb1d2-cc41-a367-7ddb-48d0fc2fc454@oracle.com> <836683a97cda660848fb73278df6ed54@xs4all.nl> <3beb529d2c93e6a9ef2efd2a153b4eea@xs4all.nl> Message-ID: <02c6b105-77c5-3f87-7a7b-3bfc76248e66@oracle.com> On 2019-01-17 18:25, Jorn Vernee wrote: > Never mind, this works: > > ??? bash configure PANDOC=/cygdrive/j/ChocolateyInstall/bin/pandoc.exe > > I should have tried that first. Yes, that is the recommended way to override individual tools. "make reconfigure" is just re-running the last "bash configure" invocation, with the same command line. At that point, no changes can be made to the configuration. And while "PANDOC=foo bash configure" works, we recommend against it (and warn), since we are unable to catch an error such as "PANDCO=foo bash configure" -- but in contrast "bash configure PANDCO=foo" will result in a warning (but it really should be an error). /Magnus > > Sorry, > Jorn > > Jorn Vernee schreef op 2019-01-17 18:07: >> Hi Erik, >> >> Thanks for the insights. The make/devkit/createPandocBundle.sh seems >> to try to install the linux version of pandoc. I have installed pandoc >> 2.5 through chocolatey instead. >> >> I'm trying to pas the exe path through the PANDOC environment >> variable, but this produces a configure warning: >> >> ??? configure: WARNING: Ignoring value of PANDOC from the environment. >> Use command line variables instead. >> >> I'm not sure what is meant here by 'command line variable' there. I've >> tried the following: >> >> ??? $ PANDOC=/cygdrive/j/ChocolateyInstall/bin/pandoc.exe >> ??? $ make reconfigure >> >> But this gives the same warning. I've also tried: >> >> ?? $ make reconfigure >> PANDOC=/cygdrive/j/ChocolateyInstall/bin/pandoc.exe >> >> But this gives a warning that I'm using a non-control variable. >> >> How should I pass the value to configure? >> >> Thanks, >> Jorn >> >> Erik Joelsson schreef op 2019-01-17 17:46: >>> You need pandoc to generate the html files from md. We also use pandoc >>> to generate files for the actual product documentation. It seems the >>> build only checks that pandoc is available for the product >>> documentation targets and for update-build-docs, it just tries and >>> fails with this rather uninformative error message. I'm pretty sure >>> the target works if you provide pandoc to configure on Windows. >>> >>> There is a script in make/devkit/createPandocBundle.sh that can help >>> you get the pandoc you need. >>> >>> /Erik >>> >>> On 2019-01-17 06:42, Jorn Vernee wrote: >>>> Hello, >>>> >>>> I'm updating some documentation for the panama repo foreign branch >>>> [1]. >>>> >>>> When running `make update-build-docs` I get the following output: >>>> >>>> ``` >>>> $ make update-build-docs >>>> Building target 'update-build-docs' in configuration >>>> 'windows-x86_64-server-release' >>>> fixpath Unknown argument: --toc >>>> fixpath Unknown argument: --toc >>>> fixpath Unknown argument: --toc >>>> make[3]: *** [UpdateBuildDocs.gmk:50: >>>> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/building.html] >>>> Error 127 >>>> make[3]: *** Waiting for unfinished jobs.... >>>> make[3]: *** [UpdateBuildDocs.gmk:58: >>>> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/testing.html] >>>> Error 127 >>>> make[3]: *** [UpdateBuildDocs.gmk:66: >>>> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/panama_foreign.html] >>>> Error 127 >>>> make[2]: *** [make/Main.gmk:417: update-build-docs] Error 2 >>>> >>>> ERROR: Build failed for target 'update-build-docs' in configuration >>>> 'windows-x86_64-server-release' (exit code 2) >>>> >>>> === Output from failing command(s) repeated here === >>>> * For target support_markdown_building_building.md: >>>> fixpath Unknown argument: --toc >>>> * For target support_markdown_panama_foreign_panama_foreign.md: >>>> fixpath Unknown argument: --toc >>>> * For target support_markdown_testing_testing.md: >>>> fixpath Unknown argument: --toc >>>> >>>> * All command lines available in >>>> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/make-support/failure-logs. >>>> === End of repeated output === >>>> >>>> No indication of failed target found. >>>> Hint: Try searching the build log for '] Error'. >>>> Hint: See doc/building.html#troubleshooting for assistance. >>>> >>>> make[1]: *** >>>> [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:310: main] >>>> Error 2 >>>> make: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:186: >>>> update-build-docs] Error 2 >>>> ``` >>>> >>>> Is this a know issue? Is this supported on Windows? >>>> >>>> Thanks, >>>> Jorn >>>> >>>> [1] : http://hg.openjdk.java.net/panama/dev/shortlog/b981c23cb71e From magnus.ihse.bursie at oracle.com Mon Jan 21 10:58:15 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 11:58:15 +0100 Subject: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows In-Reply-To: <254b4b94abcb9f1cd5274f25f1cac0bb@xs4all.nl> References: <254b4b94abcb9f1cd5274f25f1cac0bb@xs4all.nl> Message-ID: <84ab839a-6cf7-b5e0-a339-848f9f265a2c@oracle.com> On 2019-01-17 15:42, Jorn Vernee wrote: > Hello, > > I'm updating some documentation for the panama repo foreign branch [1]. > > When running `make update-build-docs` I get the following output: > > ``` > $ make update-build-docs > Building target 'update-build-docs' in configuration > 'windows-x86_64-server-release' > fixpath Unknown argument: --toc > fixpath Unknown argument: --toc > fixpath Unknown argument: --toc > make[3]: *** [UpdateBuildDocs.gmk:50: > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/building.html] > Error 127 > make[3]: *** Waiting for unfinished jobs.... > make[3]: *** [UpdateBuildDocs.gmk:58: > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/testing.html] > Error 127 > make[3]: *** [UpdateBuildDocs.gmk:66: > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/panama_foreign.html] > Error 127 > make[2]: *** [make/Main.gmk:417: update-build-docs] Error 2 Can you please verify if the fix for JDK-8215635 is included in the source you're trying to build? I thought that this should not happen after that fix, but instead no markdown files should be processed if pandoc is missing from the configuration. However, if you have that fix and still see the above error without a proper pandoc, then the fix for JDK-8215635 is not complete. /Magnus > > ERROR: Build failed for target 'update-build-docs' in configuration > 'windows-x86_64-server-release' (exit code 2) > > === Output from failing command(s) repeated here === > * For target support_markdown_building_building.md: > fixpath Unknown argument: --toc > * For target support_markdown_panama_foreign_panama_foreign.md: > fixpath Unknown argument: --toc > * For target support_markdown_testing_testing.md: > fixpath Unknown argument: --toc > > * All command lines available in > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/make-support/failure-logs. > === End of repeated output === > > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: See doc/building.html#troubleshooting for assistance. > > make[1]: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:310: > main] Error 2 > make: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:186: > update-build-docs] Error 2 > ``` > > Is this a know issue? Is this supported on Windows? > > Thanks, > Jorn > > [1] : http://hg.openjdk.java.net/panama/dev/shortlog/b981c23cb71e From jbvernee at xs4all.nl Mon Jan 21 11:31:10 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Mon, 21 Jan 2019 12:31:10 +0100 Subject: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows In-Reply-To: <84ab839a-6cf7-b5e0-a339-848f9f265a2c@oracle.com> References: <254b4b94abcb9f1cd5274f25f1cac0bb@xs4all.nl> <84ab839a-6cf7-b5e0-a339-848f9f265a2c@oracle.com> Message-ID: I'm downstream from JDK-8215635, I can see it in the revision history. I've also checked the files that were updated, and the changes are still there as well. Jorn Magnus Ihse Bursie schreef op 2019-01-21 11:58: > On 2019-01-17 15:42, Jorn Vernee wrote: > >> Hello, >> >> I'm updating some documentation for the panama repo foreign branch >> [1]. >> >> When running `make update-build-docs` I get the following output: >> >> ``` >> $ make update-build-docs >> Building target 'update-build-docs' in configuration >> 'windows-x86_64-server-release' >> fixpath Unknown argument: --toc >> fixpath Unknown argument: --toc >> fixpath Unknown argument: --toc >> make[3]: *** [UpdateBuildDocs.gmk:50: >> > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/building.html] >> Error 127 >> make[3]: *** Waiting for unfinished jobs.... >> make[3]: *** [UpdateBuildDocs.gmk:58: >> > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/testing.html] >> Error 127 >> make[3]: *** [UpdateBuildDocs.gmk:66: >> > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/panama_foreign.html] >> Error 127 >> make[2]: *** [make/Main.gmk:417: update-build-docs] Error 2 > > Can you please verify if the fix for JDK-8215635 is included in the > source you're trying to build? I thought that this should not happen > after that fix, but instead no markdown files should be processed if > pandoc is missing from the configuration. However, if you have that > fix and still see the above error without a proper pandoc, then the > fix for JDK-8215635 is not complete. > > /Magnus > >> ERROR: Build failed for target 'update-build-docs' in configuration >> 'windows-x86_64-server-release' (exit code 2) >> >> === Output from failing command(s) repeated here === >> * For target support_markdown_building_building.md: >> fixpath Unknown argument: --toc >> * For target support_markdown_panama_foreign_panama_foreign.md: >> fixpath Unknown argument: --toc >> * For target support_markdown_testing_testing.md: >> fixpath Unknown argument: --toc >> >> * All command lines available in >> > /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/make-support/failure-logs. >> === End of repeated output === >> >> No indication of failed target found. >> Hint: Try searching the build log for '] Error'. >> Hint: See doc/building.html#troubleshooting for assistance. >> >> make[1]: *** >> [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:310: main] >> Error 2 >> make: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:186: >> update-build-docs] Error 2 >> ``` >> >> Is this a know issue? Is this supported on Windows? >> >> Thanks, >> Jorn >> >> [1] : http://hg.openjdk.java.net/panama/dev/shortlog/b981c23cb71e From magnus.ihse.bursie at oracle.com Mon Jan 21 13:02:59 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 14:02:59 +0100 Subject: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows In-Reply-To: References: <254b4b94abcb9f1cd5274f25f1cac0bb@xs4all.nl> <84ab839a-6cf7-b5e0-a339-848f9f265a2c@oracle.com> Message-ID: <4758f833-b985-5f70-0490-024fd93232ba@oracle.com> On 2019-01-21 12:31, Jorn Vernee wrote: > I'm downstream from JDK-8215635, I can see it in the revision history. > > I've also checked the files that were updated, and the changes are > still there as well. Thank you. Then we need to provide additional checks to handle pandoc on Windows. I've filed https://bugs.openjdk.java.net/browse/JDK-8217448. /Magnus > > Jorn > > Magnus Ihse Bursie schreef op 2019-01-21 11:58: >> On 2019-01-17 15:42, Jorn Vernee wrote: >> >>> Hello, >>> >>> I'm updating some documentation for the panama repo foreign branch >>> [1]. >>> >>> When running `make update-build-docs` I get the following output: >>> >>> ``` >>> $ make update-build-docs >>> Building target 'update-build-docs' in configuration >>> 'windows-x86_64-server-release' >>> fixpath Unknown argument: --toc >>> fixpath Unknown argument: --toc >>> fixpath Unknown argument: --toc >>> make[3]: *** [UpdateBuildDocs.gmk:50: >>> >> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/building.html] >> >>> Error 127 >>> make[3]: *** Waiting for unfinished jobs.... >>> make[3]: *** [UpdateBuildDocs.gmk:58: >>> >> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/testing.html] >> >>> Error 127 >>> make[3]: *** [UpdateBuildDocs.gmk:66: >>> >> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/doc/panama_foreign.html] >> >>> Error 127 >>> make[2]: *** [make/Main.gmk:417: update-build-docs] Error 2 >> >> Can you please verify if the fix for JDK-8215635 is included in the >> source you're trying to build? I thought that this should not happen >> after that fix, but instead no markdown files should be processed if >> pandoc is missing from the configuration. However, if you have that >> fix and still see the above error without a proper pandoc, then the >> fix for JDK-8215635 is not complete. >> >> /Magnus >> >>> ERROR: Build failed for target 'update-build-docs' in configuration >>> 'windows-x86_64-server-release' (exit code 2) >>> >>> === Output from failing command(s) repeated here === >>> * For target support_markdown_building_building.md: >>> fixpath Unknown argument: --toc >>> * For target support_markdown_panama_foreign_panama_foreign.md: >>> fixpath Unknown argument: --toc >>> * For target support_markdown_testing_testing.md: >>> fixpath Unknown argument: --toc >>> >>> * All command lines available in >>> >> /cygdrive/h/cygwin64/home/Jorn/cygwin-projects-new/panama/build/windows-x86_64-server-release/make-support/failure-logs. >> >>> === End of repeated output === >>> >>> No indication of failed target found. >>> Hint: Try searching the build log for '] Error'. >>> Hint: See doc/building.html#troubleshooting for assistance. >>> >>> make[1]: *** >>> [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:310: main] >>> Error 2 >>> make: *** [/home/Jorn/cygwin-projects-new/panama/make/Init.gmk:186: >>> update-build-docs] Error 2 >>> ``` >>> >>> Is this a know issue? Is this supported on Windows? >>> >>> Thanks, >>> Jorn >>> >>> [1] : http://hg.openjdk.java.net/panama/dev/shortlog/b981c23cb71e From magnus.ihse.bursie at oracle.com Mon Jan 21 13:08:45 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 14:08:45 +0100 Subject: RFR: JDK-8217448 Check for pandoc availability using ENABLE_PANDOC and not PANDOC Message-ID: In some places, we have checked if we have pandoc available by comparing $(PANDOC) with the empty string, assuming that non-empty means that we've found pandoc. However, on Windows, PANDOC will always contain $(FIXPATH), so this is not a valid test. Instead we should use ENABLE_PANDOC. Bug: https://bugs.openjdk.java.net/browse/JDK-8217448 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8217448-fix-pandoc-on-windows/webrev.01 /Magnus From andy.herrick at oracle.com Mon Jan 21 13:17:12 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 21 Jan 2019 08:17:12 -0500 Subject: RFR: JDK-8217269: jpackage Makefile improvments Message-ID: <8ccd8865-77be-be09-0477-62cc9ee8b373@oracle.com> re-sending this to build-dev: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). The webrev includes all the jpackage Makefile Improvements listed in [1], other than what is covered by [4], and also includes fix for white space errors requested in [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8217269 [2] http://cr.openjdk.java.net/~herrick/8217269/webrev.01/ [3] https://bugs.openjdk.java.net/browse/JDK-8216521 [4] https://bugs.openjdk.java.net/browse/JDK-8217317 /Andy From tim.bell at oracle.com Mon Jan 21 16:43:56 2019 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 21 Jan 2019 08:43:56 -0800 Subject: RFR: JDK-8217448 Check for pandoc availability using ENABLE_PANDOC and not PANDOC In-Reply-To: References: Message-ID: <5C45F6CC.7000900@oracle.com> Magnus: > Bug: https://bugs.openjdk.java.net/browse/JDK-8217448 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8217448-fix-pandoc-on-windows/webrev.01 Looks good. Tim From vladimir.x.ivanov at oracle.com Mon Jan 21 17:35:16 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 21 Jan 2019 09:35:16 -0800 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> <93c9b305-292d-5779-7afe-bb21d7cd9672@oracle.com> Message-ID: <7ac843a0-ddfd-df85-588b-753701fe3b93@oracle.com> > Vladimir, if you're okay with it I'd like to propose this as a patch to > the problem instead: > > http://cr.openjdk.java.net/~ihse/JDK-8217404-fix-multiple-disabled-jvm-features/webrev.01 Looks good! I verified that it fixes the bug. Best regards, Vladimir Ivanov >>>> On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov >>>> wrote: >>>> >>>> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8217404 >>>> >>>> --with-jvm-features doesn't work properly when multiple features are >>>> explicitly disabled: >>>> >>>> $ bash configure --with-jvm-features="-aot -jvmci -graal" >>>> ... >>>> checking if jvmci module jdk.internal.vm.ci should be built... yes >>>> checking if graal module jdk.internal.vm.compiler should be built... >>>> yes >>>> checking if aot should be enabled... yes >>>> ... >>>> >>>> The problem in the following code: >>>> >>>> ? DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot` >>>> ? if test "x$DISABLE_AOT" = "xaot"; then >>>> ??? ENABLE_AOT="false" >>>> ? fi >>>> >>>> Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of >>>> explicitly disabled features, grep over it returns the whole list >>>> when there's a match. The subsequent check fails because there's no >>>> exact match, though DISABLE_AOT contains "aot" . >>>> >>>> Proposed fix is to check there's no match instead. >>>> >>>> After the fix it works as expected: >>>> >>>> $ bash configure --with-jvm-features="-aot -jvmci -graal" >>>> ... >>>> checking if jvmci module jdk.internal.vm.ci should be built... no, >>>> forced >>>> checking if graal module jdk.internal.vm.compiler should be built... >>>> no, forced >>>> checking if aot should be enabled... no, forced >>>> ... >>>> >>>> (The fix doesn't address the case when one feature has a name which >>>> is a proper substring of another feature, but there are no such >>>> cases at the moment.) >>>> >>>> Best regards, >>>> Vladimir Ivanov >>> > From kim.barrett at oracle.com Mon Jan 21 18:49:02 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Jan 2019 13:49:02 -0500 Subject: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled In-Reply-To: References: <5a505bea-ca69-3dd0-6748-e2391005b574@oracle.com> <93c9b305-292d-5779-7afe-bb21d7cd9672@oracle.com> Message-ID: > On Jan 21, 2019, at 5:06 AM, Magnus Ihse Bursie wrote: > Vladimir, if you're okay with it I'd like to propose this as a patch to the problem instead: > > http://cr.openjdk.java.net/~ihse/JDK-8217404-fix-multiple-disabled-jvm-features/webrev.01 Looks good! From erik.joelsson at oracle.com Tue Jan 22 16:47:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Jan 2019 08:47:48 -0800 Subject: RFR 8217357: Implement JCov jib profiles In-Reply-To: References: Message-ID: <5192da61-8e7d-630c-d6b3-0a3041a081b4@oracle.com> Looks good. /Erik On 2019-01-18 15:09, Alexandre (Shura) Iline wrote: > Hi. > > Please take a look on a change which is adding new jib profiles to support make changes introduced by JDK-8214309. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217357 > Webrev: http://cr.openjdk.java.net/~shurailine/8217357/webrev.02/ > > Thank you. > > Shura From andrewluotechnologies at outlook.com Wed Jan 23 00:47:32 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Wed, 23 Jan 2019 00:47:32 +0000 Subject: Enhancing jaotc to automatically find VS2017 linker In-Reply-To: References: Message-ID: Right, that's a good idea. I had thought about this a bit previously, but since what we have right now already works, I haven't spent much time on it. (Right now I'm still looking to get WSL tests working first, but if this isn't done after that I might be able to look into it further) Thanks, -Andrew From: Magnus Ihse Bursie Sent: Monday, January 21, 2019 12:36 AM To: build-dev Cc: Andrew Luo Subject: Fwd: Enhancing jaotc to automatically find VS2017 linker I've completely missed vswhere. It's years and years overdue, but it's nice that Microsoft is finally shipping something like this. :-) We should support using vswhere as the primary way to detect a Visual Studio installation, if it is present, and the user do not override the default selection on the command line. /Magnus -------- Forwarded Message -------- Subject: Enhancing jaotc to automatically find VS2017 linker Date: Fri, 18 Jan 2019 22:16:51 +0000 From: Andrew Luo To: hotspot-compiler-dev at openjdk.java.net Hi, Has there been any plans to enhance jaotc to support automatically finding the link.exe in VS2017? If not, I am interested in contributing some work to support this. I see that in Linker.java (src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Linker.java) we find link.exe using the environment variables VS...COMNTOOLS, but since in VS2017 and forward, this is not defined, it seems another approach is necessary. Microsoft suggests that you use vswhere (https://github.com/Microsoft/vswhere, BSD licensed, included with Visual Studio 2017 15.2 and forward) or their COM API to find the latest VS2017 toolset. Anyways, if everyone agrees we should add VS2017 support, there are a few ways to do this (in order of simplest/easiest to most complex): 1. Check that vswhere exists on the system, if it does, call vswhere (out of process - not sure this is acceptable...) and use that to find the VS2017 link.exe 2. Ship vswhere with the JDK and call it out of process 3. Statically link a copy of vswhere (BSD licensed - is this okay?) into our code and add a JNI stub to call it 4. Call the COM API in a JNI function to get the latest version of VS2017 Personally I prefer (1), but if out-of-process isn't acceptable I'm fine with doing (4) or (3). Let me know if you have any comments/feedback on this proposal. Thanks, -Andrew From magnus.ihse.bursie at oracle.com Wed Jan 23 10:08:39 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Jan 2019 11:08:39 +0100 Subject: RFR: JDK-8217626 Add setup/teardown functionality to RunTest Message-ID: Recently, jcov support was added to RunTest. This highlighted the need to have a structured way to run environment setup/teardown code before and after running all tests. This fix will also back out the additional creation oj jcov-test-* targets from JDK-8215729, which goes contrary to the current effort of reducing the number of generated targets. Bug: https://bugs.openjdk.java.net/browse/JDK-8217626 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8217626-rework-jcov-runtest-integration/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 23 12:39:21 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Jan 2019 13:39:21 +0100 Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> <3b6ebd28-c27c-823a-b3ab-85c55be1db76@oracle.com> Message-ID: On 2019-01-16 06:56, Jie Fu wrote: > Hi Magnus, > > Thanks a lot for your review and helpful comments. > > The patch[1] had been tested with Apache NetBeans IDE 9.0 (Build > incubator-netbeans-release-334-on-20180708) on a Linux_64 (amd64) > machine. > I've noticed that all files under the specified root will be scanned > automatically when the nb_project is opened in NetBeans. > And all automatically generated files in build/**/gensrc can be found > properly by NetBeans. > > I compared the configurations-old.xml (the original NB-config file) > with configurations-new.xml (the new fully generated one after > applying the patch). > -------------------------------------------------------------------------- > > fool at fool-OptiPlex-7060:~$ grep build configurations-old.xml | grep > gensrc | grep macosx -v | wc -l > 44 > fool at fool-OptiPlex-7060:~$ grep build configurations-new.xml | grep > gensrc | grep macosx -v | wc -l > 91 > -------------------------------------------------------------------------- > > More items of build/**/gensrc in configurations-new.xml. > > -------------------------------------------------------------------------- > > fool at fool-OptiPlex-7060:~$ grep build configurations-old.xml | grep > gensrc | grep x86 | grep macosx -v | wc -l > 27 > fool at fool-OptiPlex-7060:~$ grep build configurations-new.xml | grep > gensrc | grep x86 | grep macosx -v | wc -l > 91 > -------------------------------------------------------------------------- > > More items of build/**/gensrc/**/*x86* in configurations-new.xml too. > > -------------------------------------------------------------------------- > > fool at fool-OptiPlex-7060:~$ grep x86_64 configurations-old.xml | grep > macosx -v | grep build | wc -l > 45 > fool at fool-OptiPlex-7060:~$ grep x86_64 configurations-new.xml | grep > macosx -v | grep build | wc -l > 332 > -------------------------------------------------------------------------- > > Also more items of build/**/*x86_64* in configurations-new.xml. > > It seems that the src-dependent part of the new config file which was > generated automatically is more complete and reliable (without invalid > items). > And I guess most of the original config file was also automatically > generated by NetBeans based on a relatively old version of OpenJDK. > > I'm very sorry that it's really difficult and probably uncomfortable > to review such a huge patch. > But it would be worth making the NB-config file independent of the > source code. > > Compared with the original NB-config file, I couldn't find any loss of > functionality with the new one. > Could you please tell me what functionality will be lost? It was just a worry without any real basis. :-) > Thanks. > > [1] http://cr.openjdk.java.net/~aoqi/8215952/webrev.01/ This looks good. I'm sponsoring this patch; I just pushed it. Thank you for your contribution to OpenJDK! /Magnus > > Best regards, > Jie > > > On 2019/1/15 ??9:48, Magnus Ihse Bursie wrote: >> On 2019-01-03 08:22, Fu Jie wrote: >>> Thanks Alan for your review and valuable advice. >>> >>> I think it's worth keeping a NB project in the repo since it seems >>> more convenient for IDE developers. >>> And to keep configurations.xml current is also important. >>> >>> I made a patch to fix the issue mentioned by Alan. >>> Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.01/ >> >> It looks much cleaner. I'm just worried, like Alan, that this >> actually means a loss of functionality. Is NetBeans scanning all >> files under the specified root, and will automatically find generated >> files in build/**/gensrc? >> >> On the other hand, there are few NetBeans users left out there, and >> you might very well represent a majority of them. :-) So if this >> works for you, I'm OK with the change. Please just be ready to assist >> if this breaks the usage for some other NB users. >> >> /Magnus > From magnus.ihse.bursie at oracle.com Wed Jan 23 12:55:58 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Jan 2019 13:55:58 +0100 Subject: RFR(M)(round 2): 8215902: Add support for SoftFloat-3e library In-Reply-To: References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> Message-ID: <3f62f15e-ac5f-94d4-9744-c9cef796a3fa@oracle.com> Hi Jakub, On 2019-01-15 17:31, Jakub Van?k wrote: > Hi Magnus and Erik, > > I have added the link to the repository to README and I have removed > the link to the mailing list thread. I have also recreated the GitHub > repository. Now it is a fork of the mentioned repository with two extra > commits containing README and the build scripts. > > New webrev URL: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.04/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 Sorry for the late reply. This looks very good! Thank you for fixing this, including rebasing the github repo. I'm not sure if you've gotten reviews from the hotspot team for the hotspot source changes, but from a build perspective, this is good to go. /Magnus > > Regards, > > Jakub > > On 2019-01-15 at 15:05 +0100, Magnus Ihse Bursie wrote: >> On 2018-12-25 16:19, Jakub Van?k wrote: >>> Hi, >>> >>> please review this webrev. It is a successor of the softfloat-3 >>> [patch] >>> thread (first email >>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html >>> ) >>> >>> Changes since the last patch (v6): >>> >>> - renamed --with-softloat* to --with-sflt* (it is more compact and >>> it >>> corresponds to the old --with-sflt-lib=... option) >>> >>> - license is now obtained via --with-sflt-license switch (so it is >>> not >>> included in OpenJDK source tree) >>> >>> - updated documentation (slight rewording, added the license >>> option) >>> >>> - checks for default --with/--without behavior are in place again >>> (I forgot them when I changed the way the library is detected) >>> >>> - added a simple testcase - I found a disrepancy between softfloat >>> and >>> system function behavior. When a float with bits 0x003FFFFF is >>> added to 0x00000001, the correct result is 0x00400000, but the >>> default software floating point implementation returns >>> 0x00000000. >>> However I'm not sure where to put this test - now it is in >>> test/hotspot/jtreg/compiler/floatingpoint. >>> >>> - comments in code refer to CR 6757269 and newly JDK-8215902 too. >>> >>> I have created a repository with SoftFloat-3e with build >>> configuration >>> specifically for OpenJDK on armel: >>> https://github.com/ev3dev-lang-java/softfloat-openjdk >>> >>> I can add a link to it to the documentation. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 >>> Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ >> Hi Jakub, >> >> In general this looks good. >> >> Some comments: >> >> I agree with Erik that you can add a link to your github project; >> compiling SoftFloat is outside the scope of the OpenJDK build >> instructions, but it can sure be helpful to lower the bar for users >> wanting to do that. Just one question: any particular reason you >> didn't >> create your github repo by forking the official >> https://github.com/ucb-bar/berkeley-softfloat-3? That way, it would >> have >> been easy for users to see that you were not adding any malicious or >> suspicious code to the original SoftFloat distribution. >> >> On the other hand, I think the link to >> > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html >> >> is unnecessary and just creates clutter in the documentation. Please >> remove it. >> >> /Magnus >>> CI build: >>> https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ >>> >>> Cheers, >>> >>> Jakub >>> >> From magnus.ihse.bursie at oracle.com Wed Jan 23 13:25:24 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Jan 2019 14:25:24 +0100 Subject: RFR: JDK-8217634 RunTest documentation and usability update Message-ID: The RunTest documentation (doc/testing.md) has not been properly updated with the latest changes. Also, some newly added keywords were not classified as STRING, but as SINGLE to ParseKeywordVariable, which means that the user would not have the quoting support that should have been available. I also added in some whitespace fixes, for good measure. Bug: https://bugs.openjdk.java.net/browse/JDK-8217634 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8217634-runtest-love-and-care/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 23 13:43:37 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Jan 2019 14:43:37 +0100 Subject: RFR: JDK-8217638 Remove old way of running tests (test/Makefile) Message-ID: <779f6a90-060a-e756-c06a-fc34326727cd@oracle.com> The new RunTest method has been used by both developers and CI systems for quite some time. In JDK-8210958, the old method was deprecated and a warning was printed to stop using it. Now the time has come to finally remove the old cruft. Bug: https://bugs.openjdk.java.net/browse/JDK-8217638 The webrev or hg diff would not make much sense, here's a "hg status" of the removed files instead: $ hg status R test/Makefile R test/TestCommon.gmk R test/hotspot/jtreg/Makefile R test/jaxp/Makefile R test/jdk/Makefile R test/nashorn/Makefile /Magnus From jonathan.gibbons at oracle.com Wed Jan 23 16:43:01 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 23 Jan 2019 08:43:01 -0800 Subject: RFR: JDK-8217638 Remove old way of running tests (test/Makefile) In-Reply-To: <779f6a90-060a-e756-c06a-fc34326727cd@oracle.com> References: <779f6a90-060a-e756-c06a-fc34326727cd@oracle.com> Message-ID: <991354cb-bae0-d4fb-d544-500550f88a46@oracle.com> There's test/langtools/Makefile as well; is there a reason why it is not included here? -- Jon On 1/23/19 5:43 AM, Magnus Ihse Bursie wrote: > The new RunTest method has been used by both developers and CI systems > for quite some time. In data-issue-key="JDK-8210958">JDK-8210958, the old > method was deprecated and a warning was printed to stop using it. Now > the time has come to finally remove the old cruft. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217638 > > The webrev or hg diff would not make much sense, here's a "hg status" > of the removed files instead: > > $ hg status > R test/Makefile > R test/TestCommon.gmk > R test/hotspot/jtreg/Makefile > R test/jaxp/Makefile > R test/jdk/Makefile > R test/nashorn/Makefile > > /Magnus From erik.joelsson at oracle.com Wed Jan 23 17:25:59 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Jan 2019 09:25:59 -0800 Subject: RFR: JDK-8217626 Add setup/teardown functionality to RunTest In-Reply-To: References: Message-ID: Looks good. /Erik On 2019-01-23 02:08, Magnus Ihse Bursie wrote: > Recently, jcov support was added to RunTest. This highlighted the need > to have a structured way to run environment setup/teardown code before > and after running all tests. > > This fix will also back out the additional creation oj jcov-test-* > targets from JDK-8215729, which goes contrary to the current effort of > reducing the number of generated targets. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217626 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8217626-rework-jcov-runtest-integration/webrev.01 > > /Magnus From erik.joelsson at oracle.com Wed Jan 23 17:33:51 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Jan 2019 09:33:51 -0800 Subject: RFR: JDK-8217634 RunTest documentation and usability update In-Reply-To: References: Message-ID: <3bfd6845-7034-a33d-f905-77f8b7fa9aa4@oracle.com> Hello, This looks good. Just one note, the example "configure --with-jcov=.../jcov.jar" is incorrect. The configure parameter expects a jcov home dir with lib/jcov.jar in it. For a better user experience, perhaps the configure arg should be changed to accept both? /Erik On 2019-01-23 05:25, Magnus Ihse Bursie wrote: > The RunTest documentation (doc/testing.md) has not been properly > updated with the latest changes. > > Also, some newly added keywords were not classified as STRING, but as > SINGLE to ParseKeywordVariable, which means that the user would not > have the quoting support that should have been available. > > I also added in some whitespace fixes, for good measure. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217634 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8217634-runtest-love-and-care/webrev.01 > > /Magnus From erik.joelsson at oracle.com Wed Jan 23 20:03:55 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Jan 2019 12:03:55 -0800 Subject: RFR: JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac Message-ID: The TEST_OPTS=AOT_MODULES option does not work when running tests locally on Macosx. This is because jaot expects the linker to be "ld", while we define the linker (LD) to be clang on Macosx. When running tests on already built JDKs using run-test-prebuilt, we already setup LD to point to "ld" rather than "clang", so the same should be done when running local tests. This patch rewrites LD for jaotc, on Macosx and Linux. Though we did not have a problem on Linux, the run-test-prebuilt case does set LD to "ld" on Linux so better have it consistent. I also added -XX:+UnlockDiagnosticVMOptions to the verification command to make it work on release builds where this flag is default off, as well as cleaned up some whitespace. Bug: https://bugs.openjdk.java.net/browse/JDK-8217613 Webrev: http://cr.openjdk.java.net/~erikj/8217613/webrev.01/ /Erik From alexandre.iline at oracle.com Wed Jan 23 20:23:19 2019 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 23 Jan 2019 12:23:19 -0800 Subject: RFR: JDK-8217626 Add setup/teardown functionality to RunTest In-Reply-To: References: Message-ID: Looks good. pre-run-test target is a much cleaner way to achieve the same result. Thank you. Shura > On Jan 23, 2019, at 2:08 AM, Magnus Ihse Bursie wrote: > > Recently, jcov support was added to RunTest. This highlighted the need to have a structured way to run environment setup/teardown code before and after running all tests. > > This fix will also back out the additional creation oj jcov-test-* targets from JDK-8215729, which goes contrary to the current effort of reducing the number of generated targets. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217626 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8217626-rework-jcov-runtest-integration/webrev.01 > > /Magnus From tim.bell at oracle.com Wed Jan 23 20:29:36 2019 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 23 Jan 2019 12:29:36 -0800 Subject: RFR: JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac In-Reply-To: References: Message-ID: <5C48CEB0.2050103@oracle.com> Erik: > Bug: https://bugs.openjdk.java.net/browse/JDK-8217613 > > Webrev: http://cr.openjdk.java.net/~erikj/8217613/webrev.01/ Loogs good. Tim From vladimir.kozlov at oracle.com Wed Jan 23 21:18:48 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2019 13:18:48 -0800 Subject: RFR: JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac In-Reply-To: References: Message-ID: Looks good. Thanks, Vladimir On 1/23/19 12:03 PM, Erik Joelsson wrote: > The TEST_OPTS=AOT_MODULES option does not work when running tests locally on Macosx. This is because jaot expects the > linker to be "ld", while we define the linker (LD) to be clang on Macosx. When running tests on already built JDKs using > run-test-prebuilt, we already setup LD to point to "ld" rather than "clang", so the same should be done when running > local tests. > > This patch rewrites LD for jaotc, on Macosx and Linux. Though we did not have a problem on Linux, the run-test-prebuilt > case does set LD to "ld" on Linux so better have it consistent. > > I also added -XX:+UnlockDiagnosticVMOptions to the verification command to make it work on release builds where this > flag is default off, as well as cleaned up some whitespace. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217613 > > Webrev: http://cr.openjdk.java.net/~erikj/8217613/webrev.01/ > > /Erik > From igor.ignatyev at oracle.com Wed Jan 23 21:38:40 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 Jan 2019 13:38:40 -0800 Subject: RFR: JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac In-Reply-To: References: Message-ID: <213F0110-7F7F-4B1E-805E-8E4BA20E458B@oracle.com> Hi Erik, I don't like that it's based on the assumption that ld and clang/gcc are in the same directory, but this assumption seems to be always true for now. so unless there is an easy way to get ld path, I'm fine w/ this fix. -- Igor > On Jan 23, 2019, at 1:18 PM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 1/23/19 12:03 PM, Erik Joelsson wrote: >> The TEST_OPTS=AOT_MODULES option does not work when running tests locally on Macosx. This is because jaot expects the linker to be "ld", while we define the linker (LD) to be clang on Macosx. When running tests on already built JDKs using run-test-prebuilt, we already setup LD to point to "ld" rather than "clang", so the same should be done when running local tests. >> This patch rewrites LD for jaotc, on Macosx and Linux. Though we did not have a problem on Linux, the run-test-prebuilt case does set LD to "ld" on Linux so better have it consistent. >> I also added -XX:+UnlockDiagnosticVMOptions to the verification command to make it work on release builds where this flag is default off, as well as cleaned up some whitespace. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217613 >> Webrev: http://cr.openjdk.java.net/~erikj/8217613/webrev.01/ >> /Erik From erik.joelsson at oracle.com Wed Jan 23 23:10:08 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Jan 2019 15:10:08 -0800 Subject: RFR: JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac In-Reply-To: <213F0110-7F7F-4B1E-805E-8E4BA20E458B@oracle.com> References: <213F0110-7F7F-4B1E-805E-8E4BA20E458B@oracle.com> Message-ID: <9dbf2f84-c258-3f04-2012-dff62410fc34@oracle.com> On 2019-01-23 13:38, Igor Ignatyev wrote: > Hi Erik, > > I don't like that it's based on the assumption that ld and clang/gcc are in the same directory, but this assumption seems to be always true for now. so unless there is an easy way to get ld path, I'm fine w/ this fix. I don't either, and I was in a bit of a hurry so didn't think further. It would of course be cleaner to have configure find ld for us in a separate variable since this is only a problem in the local/configured case. /Erik > -- Igor > >> On Jan 23, 2019, at 1:18 PM, Vladimir Kozlov wrote: >> >> Looks good. >> >> Thanks, >> Vladimir >> >> On 1/23/19 12:03 PM, Erik Joelsson wrote: >>> The TEST_OPTS=AOT_MODULES option does not work when running tests locally on Macosx. This is because jaot expects the linker to be "ld", while we define the linker (LD) to be clang on Macosx. When running tests on already built JDKs using run-test-prebuilt, we already setup LD to point to "ld" rather than "clang", so the same should be done when running local tests. >>> This patch rewrites LD for jaotc, on Macosx and Linux. Though we did not have a problem on Linux, the run-test-prebuilt case does set LD to "ld" on Linux so better have it consistent. >>> I also added -XX:+UnlockDiagnosticVMOptions to the verification command to make it work on release builds where this flag is default off, as well as cleaned up some whitespace. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217613 >>> Webrev: http://cr.openjdk.java.net/~erikj/8217613/webrev.01/ >>> /Erik From magnus.ihse.bursie at oracle.com Wed Jan 23 23:49:35 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 00:49:35 +0100 Subject: RFR: JDK-8217638 Remove old way of running tests (test/Makefile) In-Reply-To: <991354cb-bae0-d4fb-d544-500550f88a46@oracle.com> References: <779f6a90-060a-e756-c06a-fc34326727cd@oracle.com> <991354cb-bae0-d4fb-d544-500550f88a46@oracle.com> Message-ID: <1A29C72B-73C7-478E-844E-BC66150CEE6E@oracle.com> > 23 jan. 2019 kl. 17:43 skrev Jonathan Gibbons : > > There's test/langtools/Makefile as well; is there a reason why it is not included here? Yes, there is! :-) It's just not a very good reason: I missed it. :-( Thank you for your diligence! I'll remove it as well. /Magnus > > -- Jon > >> On 1/23/19 5:43 AM, Magnus Ihse Bursie wrote: >> The new RunTest method has been used by both developers and CI systems for quite some time. In JDK-8210958, the old method was deprecated and a warning was printed to stop using it. Now the time has come to finally remove the old cruft. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217638 >> >> The webrev or hg diff would not make much sense, here's a "hg status" of the removed files instead: >> >> $ hg status >> R test/Makefile >> R test/TestCommon.gmk >> R test/hotspot/jtreg/Makefile >> R test/jaxp/Makefile >> R test/jdk/Makefile >> R test/nashorn/Makefile >> >> /Magnus From igor.ignatyev at oracle.com Wed Jan 23 23:55:04 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 Jan 2019 15:55:04 -0800 Subject: RFR: JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac In-Reply-To: <9dbf2f84-c258-3f04-2012-dff62410fc34@oracle.com> References: <213F0110-7F7F-4B1E-805E-8E4BA20E458B@oracle.com> <9dbf2f84-c258-3f04-2012-dff62410fc34@oracle.com> Message-ID: <1C470274-8261-4947-B1E5-BA91B7C8FBD9@oracle.com> so far it has affected only my local runs, so we are in no hurry to get this fixed ;) you can work on a better fix, I, meanwhile, will apply your patch to my local ws as a workaround. -- Igor > On Jan 23, 2019, at 3:10 PM, Erik Joelsson wrote: > > On 2019-01-23 13:38, Igor Ignatyev wrote: >> Hi Erik, >> >> I don't like that it's based on the assumption that ld and clang/gcc are in the same directory, but this assumption seems to be always true for now. so unless there is an easy way to get ld path, I'm fine w/ this fix. > > I don't either, and I was in a bit of a hurry so didn't think further. It would of course be cleaner to have configure find ld for us in a separate variable since this is only a problem in the local/configured case. > > /Erik > >> -- Igor >> >>> On Jan 23, 2019, at 1:18 PM, Vladimir Kozlov wrote: >>> >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/23/19 12:03 PM, Erik Joelsson wrote: >>>> The TEST_OPTS=AOT_MODULES option does not work when running tests locally on Macosx. This is because jaot expects the linker to be "ld", while we define the linker (LD) to be clang on Macosx. When running tests on already built JDKs using run-test-prebuilt, we already setup LD to point to "ld" rather than "clang", so the same should be done when running local tests. >>>> This patch rewrites LD for jaotc, on Macosx and Linux. Though we did not have a problem on Linux, the run-test-prebuilt case does set LD to "ld" on Linux so better have it consistent. >>>> I also added -XX:+UnlockDiagnosticVMOptions to the verification command to make it work on release builds where this flag is default off, as well as cleaned up some whitespace. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217613 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8217613/webrev.01/ >>>> /Erik From erik.joelsson at oracle.com Thu Jan 24 00:16:57 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Jan 2019 16:16:57 -0800 Subject: RFR: JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac In-Reply-To: <1C470274-8261-4947-B1E5-BA91B7C8FBD9@oracle.com> References: <213F0110-7F7F-4B1E-805E-8E4BA20E458B@oracle.com> <9dbf2f84-c258-3f04-2012-dff62410fc34@oracle.com> <1C470274-8261-4947-B1E5-BA91B7C8FBD9@oracle.com> Message-ID: Hello again, Here is a better fix as described below. Configure finds and sets LD_JAOTC specifically tailored for the needs of jaotc for each platform. http://cr.openjdk.java.net/~erikj/8217613/webrev.02/index.html Verified with local test using TEST_OPTS=AOT_MODULES=java.base on Macosx, Linux and Windows, as well as mach5 run of the same. /Erik On 2019-01-23 15:55, Igor Ignatyev wrote: > so far it has affected only my local runs, so we are in no hurry to get this fixed ;) you can work on a better fix, I, meanwhile, will apply your patch to my local ws as a workaround. > > -- Igor > >> On Jan 23, 2019, at 3:10 PM, Erik Joelsson wrote: >> >> On 2019-01-23 13:38, Igor Ignatyev wrote: >>> Hi Erik, >>> >>> I don't like that it's based on the assumption that ld and clang/gcc are in the same directory, but this assumption seems to be always true for now. so unless there is an easy way to get ld path, I'm fine w/ this fix. >> I don't either, and I was in a bit of a hurry so didn't think further. It would of course be cleaner to have configure find ld for us in a separate variable since this is only a problem in the local/configured case. >> >> /Erik >> >>> -- Igor >>> >>>> On Jan 23, 2019, at 1:18 PM, Vladimir Kozlov wrote: >>>> >>>> Looks good. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/23/19 12:03 PM, Erik Joelsson wrote: >>>>> The TEST_OPTS=AOT_MODULES option does not work when running tests locally on Macosx. This is because jaot expects the linker to be "ld", while we define the linker (LD) to be clang on Macosx. When running tests on already built JDKs using run-test-prebuilt, we already setup LD to point to "ld" rather than "clang", so the same should be done when running local tests. >>>>> This patch rewrites LD for jaotc, on Macosx and Linux. Though we did not have a problem on Linux, the run-test-prebuilt case does set LD to "ld" on Linux so better have it consistent. >>>>> I also added -XX:+UnlockDiagnosticVMOptions to the verification command to make it work on release builds where this flag is default off, as well as cleaned up some whitespace. >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217613 >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8217613/webrev.01/ >>>>> /Erik From erik.joelsson at oracle.com Thu Jan 24 00:19:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Jan 2019 16:19:17 -0800 Subject: RFR: JDK-8217638 Remove old way of running tests (test/Makefile) In-Reply-To: <1A29C72B-73C7-478E-844E-BC66150CEE6E@oracle.com> References: <779f6a90-060a-e756-c06a-fc34326727cd@oracle.com> <991354cb-bae0-d4fb-d544-500550f88a46@oracle.com> <1A29C72B-73C7-478E-844E-BC66150CEE6E@oracle.com> Message-ID: <373212b0-40bc-d308-eee3-fe21802e30bc@oracle.com> If Jon is ok with the langtools test makefile removal, then this looks good to me. /Erik On 2019-01-23 15:49, Magnus Ihse Bursie wrote: >> 23 jan. 2019 kl. 17:43 skrev Jonathan Gibbons : >> >> There's test/langtools/Makefile as well; is there a reason why it is not included here? > Yes, there is! :-) It's just not a very good reason: I missed it. :-( > > Thank you for your diligence! I'll remove it as well. > > /Magnus > > >> -- Jon >> >>> On 1/23/19 5:43 AM, Magnus Ihse Bursie wrote: >>> The new RunTest method has been used by both developers and CI systems for quite some time. In JDK-8210958, the old method was deprecated and a warning was printed to stop using it. Now the time has come to finally remove the old cruft. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217638 >>> >>> The webrev or hg diff would not make much sense, here's a "hg status" of the removed files instead: >>> >>> $ hg status >>> R test/Makefile >>> R test/TestCommon.gmk >>> R test/hotspot/jtreg/Makefile >>> R test/jaxp/Makefile >>> R test/jdk/Makefile >>> R test/nashorn/Makefile >>> >>> /Magnus From vladimir.kozlov at oracle.com Thu Jan 24 00:23:32 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2019 16:23:32 -0800 Subject: RFR: JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac In-Reply-To: References: <213F0110-7F7F-4B1E-805E-8E4BA20E458B@oracle.com> <9dbf2f84-c258-3f04-2012-dff62410fc34@oracle.com> <1C470274-8261-4947-B1E5-BA91B7C8FBD9@oracle.com> Message-ID: <9e71a180-6c7d-5281-008f-9b239b91bf59@oracle.com> Thank you, Erik This looks good. Vladimir On 1/23/19 4:16 PM, Erik Joelsson wrote: > Hello again, > > Here is a better fix as described below. Configure finds and sets LD_JAOTC specifically tailored for the needs of jaotc > for each platform. > > http://cr.openjdk.java.net/~erikj/8217613/webrev.02/index.html > > Verified with local test using TEST_OPTS=AOT_MODULES=java.base on Macosx, Linux and Windows, as well as mach5 run of the > same. > > /Erik > > On 2019-01-23 15:55, Igor Ignatyev wrote: >> so far it has affected only my local runs, so we are in no hurry to get this fixed ;) you can work on a better fix, I, >> meanwhile, will apply your patch to my local ws as a workaround. >> >> -- Igor >> >>> On Jan 23, 2019, at 3:10 PM, Erik Joelsson wrote: >>> >>> On 2019-01-23 13:38, Igor Ignatyev wrote: >>>> Hi Erik, >>>> >>>> I don't like that it's based on the assumption that ld and clang/gcc are in the same directory, but this assumption >>>> seems to be always true for now. so unless there is an easy way to get ld path, I'm fine w/ this fix. >>> I don't either, and I was in a bit of a hurry so didn't think further. It would of course be cleaner to have >>> configure find ld for us in a separate variable since this is only a problem in the local/configured case. >>> >>> /Erik >>> >>>> -- Igor >>>> >>>>> On Jan 23, 2019, at 1:18 PM, Vladimir Kozlov wrote: >>>>> >>>>> Looks good. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/23/19 12:03 PM, Erik Joelsson wrote: >>>>>> The TEST_OPTS=AOT_MODULES option does not work when running tests locally on Macosx. This is because jaot expects >>>>>> the linker to be "ld", while we define the linker (LD) to be clang on Macosx. When running tests on already built >>>>>> JDKs using run-test-prebuilt, we already setup LD to point to "ld" rather than "clang", so the same should be done >>>>>> when running local tests. >>>>>> This patch rewrites LD for jaotc, on Macosx and Linux. Though we did not have a problem on Linux, the >>>>>> run-test-prebuilt case does set LD to "ld" on Linux so better have it consistent. >>>>>> I also added -XX:+UnlockDiagnosticVMOptions to the verification command to make it work on release builds where >>>>>> this flag is default off, as well as cleaned up some whitespace. >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217613 >>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8217613/webrev.01/ >>>>>> /Erik From igor.ignatyev at oracle.com Thu Jan 24 00:23:23 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 Jan 2019 16:23:23 -0800 Subject: RFR: JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac In-Reply-To: References: <213F0110-7F7F-4B1E-805E-8E4BA20E458B@oracle.com> <9dbf2f84-c258-3f04-2012-dff62410fc34@oracle.com> <1C470274-8261-4947-B1E5-BA91B7C8FBD9@oracle.com> Message-ID: <5E9151ED-5BE1-451D-BB40-145908D527BE@oracle.com> LGTM! -- Igor > On Jan 23, 2019, at 4:16 PM, Erik Joelsson wrote: > > Hello again, > > Here is a better fix as described below. Configure finds and sets LD_JAOTC specifically tailored for the needs of jaotc for each platform. > > http://cr.openjdk.java.net/~erikj/8217613/webrev.02/index.html > > Verified with local test using TEST_OPTS=AOT_MODULES=java.base on Macosx, Linux and Windows, as well as mach5 run of the same. > > /Erik > > On 2019-01-23 15:55, Igor Ignatyev wrote: >> so far it has affected only my local runs, so we are in no hurry to get this fixed ;) you can work on a better fix, I, meanwhile, will apply your patch to my local ws as a workaround. >> >> -- Igor >> >>> On Jan 23, 2019, at 3:10 PM, Erik Joelsson wrote: >>> >>> On 2019-01-23 13:38, Igor Ignatyev wrote: >>>> Hi Erik, >>>> >>>> I don't like that it's based on the assumption that ld and clang/gcc are in the same directory, but this assumption seems to be always true for now. so unless there is an easy way to get ld path, I'm fine w/ this fix. >>> I don't either, and I was in a bit of a hurry so didn't think further. It would of course be cleaner to have configure find ld for us in a separate variable since this is only a problem in the local/configured case. >>> >>> /Erik >>> >>>> -- Igor >>>> >>>>> On Jan 23, 2019, at 1:18 PM, Vladimir Kozlov wrote: >>>>> >>>>> Looks good. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/23/19 12:03 PM, Erik Joelsson wrote: >>>>>> The TEST_OPTS=AOT_MODULES option does not work when running tests locally on Macosx. This is because jaot expects the linker to be "ld", while we define the linker (LD) to be clang on Macosx. When running tests on already built JDKs using run-test-prebuilt, we already setup LD to point to "ld" rather than "clang", so the same should be done when running local tests. >>>>>> This patch rewrites LD for jaotc, on Macosx and Linux. Though we did not have a problem on Linux, the run-test-prebuilt case does set LD to "ld" on Linux so better have it consistent. >>>>>> I also added -XX:+UnlockDiagnosticVMOptions to the verification command to make it work on release builds where this flag is default off, as well as cleaned up some whitespace. >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217613 >>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8217613/webrev.01/ >>>>>> /Erik From tim.bell at oracle.com Thu Jan 24 00:29:08 2019 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 23 Jan 2019 16:29:08 -0800 Subject: RFR: JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac In-Reply-To: <9e71a180-6c7d-5281-008f-9b239b91bf59@oracle.com> References: <213F0110-7F7F-4B1E-805E-8E4BA20E458B@oracle.com> <9dbf2f84-c258-3f04-2012-dff62410fc34@oracle.com> <1C470274-8261-4947-B1E5-BA91B7C8FBD9@oracle.com> <9e71a180-6c7d-5281-008f-9b239b91bf59@oracle.com> Message-ID: <5C4906D4.80208@oracle.com> Erik: The improved version looks good to me as well. Tim On 01/23/19 16:23, Vladimir Kozlov wrote: > Thank you, Erik > > This looks good. > > Vladimir > > On 1/23/19 4:16 PM, Erik Joelsson wrote: >> Hello again, >> >> Here is a better fix as described below. Configure finds and sets >> LD_JAOTC specifically tailored for the needs of jaotc for each platform. >> >> http://cr.openjdk.java.net/~erikj/8217613/webrev.02/index.html >> >> Verified with local test using TEST_OPTS=AOT_MODULES=java.base on >> Macosx, Linux and Windows, as well as mach5 run of the same. >> >> /Erik >> >> On 2019-01-23 15:55, Igor Ignatyev wrote: >>> so far it has affected only my local runs, so we are in no hurry to >>> get this fixed ;) you can work on a better fix, I, meanwhile, will >>> apply your patch to my local ws as a workaround. >>> >>> -- Igor >>> >>>> On Jan 23, 2019, at 3:10 PM, Erik Joelsson >>>> wrote: >>>> >>>> On 2019-01-23 13:38, Igor Ignatyev wrote: >>>>> Hi Erik, >>>>> >>>>> I don't like that it's based on the assumption that ld and >>>>> clang/gcc are in the same directory, but this assumption seems to >>>>> be always true for now. so unless there is an easy way to get ld >>>>> path, I'm fine w/ this fix. >>>> I don't either, and I was in a bit of a hurry so didn't think >>>> further. It would of course be cleaner to have configure find ld for >>>> us in a separate variable since this is only a problem in the >>>> local/configured case. >>>> >>>> /Erik >>>> >>>>> -- Igor >>>>> >>>>>> On Jan 23, 2019, at 1:18 PM, Vladimir Kozlov >>>>>> wrote: >>>>>> >>>>>> Looks good. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 1/23/19 12:03 PM, Erik Joelsson wrote: >>>>>>> The TEST_OPTS=AOT_MODULES option does not work when running tests >>>>>>> locally on Macosx. This is because jaot expects the linker to be >>>>>>> "ld", while we define the linker (LD) to be clang on Macosx. When >>>>>>> running tests on already built JDKs using run-test-prebuilt, we >>>>>>> already setup LD to point to "ld" rather than "clang", so the >>>>>>> same should be done when running local tests. >>>>>>> This patch rewrites LD for jaotc, on Macosx and Linux. Though we >>>>>>> did not have a problem on Linux, the run-test-prebuilt case does >>>>>>> set LD to "ld" on Linux so better have it consistent. >>>>>>> I also added -XX:+UnlockDiagnosticVMOptions to the verification >>>>>>> command to make it work on release builds where this flag is >>>>>>> default off, as well as cleaned up some whitespace. >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217613 >>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8217613/webrev.01/ >>>>>>> /Erik From fujie at loongson.cn Thu Jan 24 00:53:07 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 24 Jan 2019 08:53:07 +0800 Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> <3b6ebd28-c27c-823a-b3ab-85c55be1db76@oracle.com> Message-ID: <5f19a187-9098-cc55-7b3b-159a7b5a4bdb@loongson.cn> Thanks Magnus. On 2019/1/23 ??8:39, Magnus Ihse Bursie wrote: > > > On 2019-01-16 06:56, Jie Fu wrote: >> Hi Magnus, >> >> Thanks a lot for your review and helpful comments. >> >> The patch[1] had been tested with Apache NetBeans IDE 9.0 (Build >> incubator-netbeans-release-334-on-20180708) on a Linux_64 (amd64) >> machine. >> I've noticed that all files under the specified root will be scanned >> automatically when the nb_project is opened in NetBeans. >> And all automatically generated files in build/**/gensrc can be found >> properly by NetBeans. >> >> I compared the configurations-old.xml (the original NB-config file) >> with configurations-new.xml (the new fully generated one after >> applying the patch). >> -------------------------------------------------------------------------- >> >> fool at fool-OptiPlex-7060:~$ grep build configurations-old.xml | grep >> gensrc | grep macosx -v | wc -l >> 44 >> fool at fool-OptiPlex-7060:~$ grep build configurations-new.xml | grep >> gensrc | grep macosx -v | wc -l >> 91 >> -------------------------------------------------------------------------- >> >> More items of build/**/gensrc in configurations-new.xml. >> >> -------------------------------------------------------------------------- >> >> fool at fool-OptiPlex-7060:~$ grep build configurations-old.xml | grep >> gensrc | grep x86 | grep macosx -v | wc -l >> 27 >> fool at fool-OptiPlex-7060:~$ grep build configurations-new.xml | grep >> gensrc | grep x86 | grep macosx -v | wc -l >> 91 >> -------------------------------------------------------------------------- >> >> More items of build/**/gensrc/**/*x86* in configurations-new.xml too. >> >> -------------------------------------------------------------------------- >> >> fool at fool-OptiPlex-7060:~$ grep x86_64 configurations-old.xml | grep >> macosx -v | grep build | wc -l >> 45 >> fool at fool-OptiPlex-7060:~$ grep x86_64 configurations-new.xml | grep >> macosx -v | grep build | wc -l >> 332 >> -------------------------------------------------------------------------- >> >> Also more items of build/**/*x86_64* in configurations-new.xml. >> >> It seems that the src-dependent part of the new config file which was >> generated automatically is more complete and reliable (without >> invalid items). >> And I guess most of the original config file was also automatically >> generated by NetBeans based on a relatively old version of OpenJDK. >> >> I'm very sorry that it's really difficult and probably uncomfortable >> to review such a huge patch. >> But it would be worth making the NB-config file independent of the >> source code. >> >> Compared with the original NB-config file, I couldn't find any loss >> of functionality with the new one. >> Could you please tell me what functionality will be lost? > > It was just a worry without any real basis. :-) > >> Thanks. >> >> [1] http://cr.openjdk.java.net/~aoqi/8215952/webrev.01/ > This looks good. I'm sponsoring this patch; I just pushed it. > > Thank you for your contribution to OpenJDK! > > /Magnus > >> >> Best regards, >> Jie >> >> >> On 2019/1/15 ??9:48, Magnus Ihse Bursie wrote: >>> On 2019-01-03 08:22, Fu Jie wrote: >>>> Thanks Alan for your review and valuable advice. >>>> >>>> I think it's worth keeping a NB project in the repo since it seems >>>> more convenient for IDE developers. >>>> And to keep configurations.xml current is also important. >>>> >>>> I made a patch to fix the issue mentioned by Alan. >>>> Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.01/ >>> >>> It looks much cleaner. I'm just worried, like Alan, that this >>> actually means a loss of functionality. Is NetBeans scanning all >>> files under the specified root, and will automatically find >>> generated files in build/**/gensrc? >>> >>> On the other hand, there are few NetBeans users left out there, and >>> you might very well represent a majority of them. :-) So if this >>> works for you, I'm OK with the change. Please just be ready to >>> assist if this breaks the usage for some other NB users. >>> >>> /Magnus >> > From jonathan.gibbons at oracle.com Thu Jan 24 01:16:04 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 23 Jan 2019 17:16:04 -0800 Subject: RFR: JDK-8217638 Remove old way of running tests (test/Makefile) In-Reply-To: <373212b0-40bc-d308-eee3-fe21802e30bc@oracle.com> References: <779f6a90-060a-e756-c06a-fc34326727cd@oracle.com> <991354cb-bae0-d4fb-d544-500550f88a46@oracle.com> <1A29C72B-73C7-478E-844E-BC66150CEE6E@oracle.com> <373212b0-40bc-d308-eee3-fe21802e30bc@oracle.com> Message-ID: <925c5a08-a864-fe14-8936-8101e1d6cf84@oracle.com> I'm OK.? Old friends fade away ... -- Jon On 1/23/19 4:19 PM, Erik Joelsson wrote: > If Jon is ok with the langtools test makefile removal, then this looks > good to me. > > /Erik > > On 2019-01-23 15:49, Magnus Ihse Bursie wrote: >>> 23 jan. 2019 kl. 17:43 skrev Jonathan Gibbons >>> : >>> >>> There's test/langtools/Makefile as well; is there a reason why it is >>> not included here? >> Yes, there is! :-) It's just not a very good reason: I missed it. :-( >> >> Thank you for your diligence! I'll remove it as well. >> >> /Magnus >> >> >>> -- Jon >>> >>>> On 1/23/19 5:43 AM, Magnus Ihse Bursie wrote: >>>> The new RunTest method has been used by both developers and CI >>>> systems for quite some time. In >>> title="Rename "make run-test" to "make test"" class="issue-link" >>>> data-issue-key="JDK-8210958">JDK-8210958, the >>>> old method was deprecated and a warning was printed to stop using >>>> it. Now the time has come to finally remove the old cruft. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217638 >>>> >>>> The webrev or hg diff would not make much sense, here's a "hg >>>> status" of the removed files instead: >>>> >>>> $ hg status >>>> R test/Makefile >>>> R test/TestCommon.gmk >>>> R test/hotspot/jtreg/Makefile >>>> R test/jaxp/Makefile >>>> R test/jdk/Makefile >>>> R test/nashorn/Makefile >>>> >>>> /Magnus From zhaixiang at loongson.cn Thu Jan 24 02:28:18 2019 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Thu, 24 Jan 2019 10:28:18 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target Message-ID: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> Hi Erik, Because the flags' macro of MIPS is different from other targets[1], it will effect the `UnixConstants` of src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, for example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different from other targets.? Then failed[2] to cross compiling jdk12 for mips64el-linux-gnu target by following the document[3]. Workaround 1: Only make hotspot, then scp build/linux-mips64el-normal-server-fastdebug/jdk/lib/server/libjvm.so to mips64el target machine, java version is able to work[4], but it needs to make images on mips64el target machine at first. Workaround 2: Just change[5] the flags' macro of MIPS to keep same with other targets.? Even if succeed to cross compiling, and java version is able to work on target machine, but jmod[6], javac, etc. failed to work.? Because buildjdk/jdk/bin/jmod is x86-64, but images/jdk/bin/jmod is mips64el target, the flags' macro is still different in X86 host and MIPS target machine. Please give me some advice about how to fix the root cause, thanks a lot! Regards, Leslie Zhai 1. $ diff -Naur sysdeps/unix/sysv/linux/x86/bits/fcntl.h sysdeps/unix/sysv/linux/mips/bits/fcntl.h --- sysdeps/unix/sysv/linux/x86/bits/fcntl.h??? 2019-01-23 11:46:18.712301739 +0800 +++ sysdeps/unix/sysv/linux/mips/bits/fcntl.h??? 2019-01-23 11:46:18.540304458 +0800 @@ -1,5 +1,5 @@ -/* O_*, F_*, FD_* bit values for Linux/x86. -?? Copyright (C) 2001-2017 Free Software Foundation, Inc. +/* O_*, F_*, FD_* bit values for Linux. +?? Copyright (C) 1995-2017 Free Software Foundation, Inc. ??? This file is part of the GNU C Library. ??? The GNU C Library is free software; you can redistribute it and/or @@ -13,24 +13,56 @@ ??? Lesser General Public License for more details. ??? You should have received a copy of the GNU Lesser General Public -?? License along with the GNU C Library; if not, see +?? License along with the GNU C Library.? If not, see ??? .? */ -#ifndef _FCNTL_H +#ifndef??? _FCNTL_H ?# error "Never use directly; include instead." ?#endif -#ifdef __x86_64__ -# define __O_LARGEFILE??? 0 +#include + +#define O_APPEND??? ?0x0008 +#define O_SYNC??? ??? ?0x4010 +#define O_NONBLOCK??? ?0x0080 +#define O_CREAT??? ??? ?0x0100??? /* not fcntl */ +#define O_TRUNC??? ??? ?0x0200??? /* not fcntl */ +#define O_EXCL??? ??? ?0x0400??? /* not fcntl */ +#define O_NOCTTY??? ?0x0800??? /* not fcntl */ +#define O_ASYNC??? ??? ?0x1000 + +#define __O_DIRECT??? ?0x8000??? /* Direct disk access hint.? */ +#define __O_DSYNC??? ?0x0010??? /* Synchronize data.? */ + +#if _MIPS_SIM == _ABI64 +/* Not necessary, files are always with 64bit off_t.? */ +# define __O_LARGEFILE? 0 +#else +# define __O_LARGEFILE??? 0x2000??? /* Allow large file opens. */ ?#endif -#ifdef __x86_64__ -/* Not necessary, we always have 64-bit offsets.? */ -# define F_GETLK64??? 5??? /* Get record locking info.? */ -# define F_SETLK64??? 6??? /* Set record locking info (non-blocking).? */ -# define F_SETLKW64??? 7??? /* Set record locking info (blocking).??? */ +#ifndef __USE_FILE_OFFSET64 +# define F_GETLK??? 14??? /* Get record locking info.? */ +# define F_SETLK??? 6??? /* Set record locking info (non-blocking).? */ +# define F_SETLKW??? 7??? /* Set record locking info (blocking).??? */ +#else +# define F_GETLK??? F_GETLK64? /* Get record locking info.??? */ +# define F_SETLK??? F_SETLK64? /* Set record locking info (non-blocking).*/ +# define F_SETLKW??? F_SETLKW64 /* Set record locking info (blocking).? */ ?#endif +#if _MIPS_SIM != _ABI64 +# define F_GETLK64??? 33??? /* Get record locking info.? */ +# define F_SETLK64??? 34??? /* Set record locking info (non-blocking).? */ +# define F_SETLKW64??? 35??? /* Set record locking info (blocking).??? */ +#else +# define F_GETLK64??? 14??? /* Get record locking info.??? */ +# define F_SETLK64??? 6??? /* Set record locking info (non-blocking).*/ +# define F_SETLKW64??? 7??? /* Set record locking info (blocking).? */ +#endif + +#define __F_SETOWN??? 24??? /* Get owner (process receiving SIGIO).? */ +#define __F_GETOWN??? 23??? /* Set owner (process receiving SIGIO).? */ ?struct flock ?? { @@ -39,12 +71,23 @@ ?#ifndef __USE_FILE_OFFSET64 ???? __off_t l_start;??? /* Offset where the lock begins.? */ ???? __off_t l_len;??? /* Size of the locked area; zero means until EOF.? */ +#if _MIPS_SIM != _ABI64 +??? /* The 64-bit flock structure, used by the n64 ABI, and for 64-bit +?????? fcntls in o32 and n32, never has this field.? */ +??? long int l_sysid; +#endif ?#else ???? __off64_t l_start;??? /* Offset where the lock begins.? */ ???? __off64_t l_len;??? /* Size of the locked area; zero means until EOF.? */ ?#endif ???? __pid_t l_pid;??? /* Process holding the lock.? */ +#if ! defined __USE_FILE_OFFSET64 && _MIPS_SIM != _ABI64 +??? /* The 64-bit flock structure, used by the n64 ABI, and for 64-bit +?????? flock in o32 and n32, never has this field.? */ +??? long int __glibc_reserved0[4]; +#endif ?? }; +typedef struct flock flock_t; ?#ifdef __USE_LARGEFILE64 ?struct flock64 ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- 2. /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/jdk/bin/jmod -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 create --module-version 12-internal --target-platform 'linux-mips64el' --module-path /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/interim-jmods --libs /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_libs/java.base --cmds /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_cmds/java.base --config /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_conf/java.base --class-path /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/jdk/modules/java.base --header-files /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_include/java.base --legal-notices "/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_legal/common:/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_legal/java.base" --exclude '**{_the.*,_*.marker,*.diz,*.debuginfo,*.dSYM/**,*.dSYM,*.pdb,*.map}' /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/interim-jmods/temp/java.base.jmod > >(/usr/bin/tee -a /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/jmods/java.base.jmod.log) 2> >(/usr/bin/tee -a /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/jmods/java.base.jmod.log >&2) || ( exitcode=$? && /bin/cp /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/jmods/java.base.jmod.log /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/make-support/failure-logs/buildjdk_support_jmods_java.base.jmod.log && /bin/cp /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/jmods/java.base.jmod.cmdline /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/make-support/failure-logs/buildjdk_support_jmods_java.base.jmod.cmdline && exit $exitcode ) ) Error: /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/interim-jmods/temp/.java.base.jmod.tmp java.nio.file.NoSuchFileException: /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/interim-jmods/temp/.java.base.jmod.tmp ??? at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) ??? at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ??? at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ??? at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:215) ??? at java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:478) ??? at java.base/java.nio.file.Files.newOutputStream(Files.java:219) ??? at jdk.jlink/jdk.tools.jmod.JmodOutputStream.newOutputStream(JmodOutputStream.java:52) ??? at jdk.jlink/jdk.tools.jmod.JmodTask.create(JmodTask.java:437) ??? at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:208) ??? at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34) CreateJmods.gmk:162: recipe for target '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/interim-jmods/java.base.jmod' failed ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- 3. https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html#cross-compiling 4. $ ./build/linux-mips64el-normal-server-fastdebug/images/jdk/bin/java -version openjdk version "12-internal" 2019-03-19 OpenJDK Runtime Environment (fastdebug build 12-internal+0-adhoc.loongson.jdk-mips) OpenJDK 64-Bit Server VM (fastdebug build 12-internal+0-adhoc.loongson.jdk-mips, mixed mode) 5. diff -r 294c0bb90976 src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template --- a/src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template Wed Jan 09 15:39:04 2019 +0800 +++ b/src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template Thu Jan 24 10:19:04 2019 +0800 @@ -28,7 +28,11 @@ ?#include ?#include ?#include +#ifdef MIPS_SYSROOT +#include +#else ?#include +#endif ?#include ?/* On Solaris, "sun" is defined as a macro. Undefine to make package 6. $ file build/linux-mips64el-normal-server-fastdebug/buildjdk/jdk/bin/jmod build/linux-mips64el-normal-server-fastdebug/buildjdk/jdk/bin/jmod: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=7095b74502322b08957f0b4aaa3b9c5c8ceba5b6, not stripped $ file build/linux-mips64el-normal-server-fastdebug/images/jdk/bin/jmod build/linux-mips64el-normal-server-fastdebug/images/jdk/bin/jmod: ELF 64-bit LSB shared object, MIPS, MIPS64 rel2 version 1 (SYSV), dynamically linked, interpreter /lib64/ld.so.1, BuildID[sha1]=4dd81abf1b06d9bc90063b53a50549dd15434232, for GNU/Linux 3.2.0, not stripped From david.holmes at oracle.com Thu Jan 24 02:47:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2019 12:47:41 +1000 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> Message-ID: <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> Hi Leslie, I'm not Erik :) however .... On 24/01/2019 12:28 pm, Leslie Zhai wrote: > Hi Erik, > > Because the flags' macro of MIPS is different from other targets[1], it > will effect the `UnixConstants` of > src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, for > example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different > from other targets.? Then failed[2] to cross compiling jdk12 for > mips64el-linux-gnu target by following the document[3]. It's been quite a while since we built for a platform where the flags had different values, but it is supposed to work. I suspect that the way we build now with the module system may not be quite correct in this regard - but that is just supposition on my part. Because compile-time constants are stored directly into class files that use them, we have to generate UnixConstants.java before compiling any class that needs to use it, then we must compile all classes that do use it. Those classes must only be executed in conjunction with a tool executing on the target platform (javac, jmod etc). My suspicion is that we may be executing a tool on the build platform using the newly compiled classes for the target platform - and that would be wrong. David ----- > Workaround 1: > > Only make hotspot, then scp > build/linux-mips64el-normal-server-fastdebug/jdk/lib/server/libjvm.so to > mips64el target machine, java version is able to work[4], but it needs > to make images on mips64el target machine at first. > > Workaround 2: > > Just change[5] the flags' macro of MIPS to keep same with other > targets.? Even if succeed to cross compiling, and java version is able > to work on target machine, but jmod[6], javac, etc. failed to work. > Because buildjdk/jdk/bin/jmod is x86-64, but images/jdk/bin/jmod is > mips64el target, the flags' macro is still different in X86 host and > MIPS target machine. > > Please give me some advice about how to fix the root cause, thanks a lot! > > Regards, > > Leslie Zhai > > > 1. > > $ diff -Naur sysdeps/unix/sysv/linux/x86/bits/fcntl.h > sysdeps/unix/sysv/linux/mips/bits/fcntl.h > --- sysdeps/unix/sysv/linux/x86/bits/fcntl.h??? 2019-01-23 > 11:46:18.712301739 +0800 > +++ sysdeps/unix/sysv/linux/mips/bits/fcntl.h??? 2019-01-23 > 11:46:18.540304458 +0800 > @@ -1,5 +1,5 @@ > -/* O_*, F_*, FD_* bit values for Linux/x86. > -?? Copyright (C) 2001-2017 Free Software Foundation, Inc. > +/* O_*, F_*, FD_* bit values for Linux. > +?? Copyright (C) 1995-2017 Free Software Foundation, Inc. > ??? This file is part of the GNU C Library. > > ??? The GNU C Library is free software; you can redistribute it and/or > @@ -13,24 +13,56 @@ > ??? Lesser General Public License for more details. > > ??? You should have received a copy of the GNU Lesser General Public > -?? License along with the GNU C Library; if not, see > +?? License along with the GNU C Library.? If not, see > ??? .? */ > > -#ifndef _FCNTL_H > +#ifndef??? _FCNTL_H > ?# error "Never use directly; include instead." > ?#endif > > -#ifdef __x86_64__ > -# define __O_LARGEFILE??? 0 > +#include > + > +#define O_APPEND??? ?0x0008 > +#define O_SYNC??? ??? ?0x4010 > +#define O_NONBLOCK??? ?0x0080 > +#define O_CREAT??? ??? ?0x0100??? /* not fcntl */ > +#define O_TRUNC??? ??? ?0x0200??? /* not fcntl */ > +#define O_EXCL??? ??? ?0x0400??? /* not fcntl */ > +#define O_NOCTTY??? ?0x0800??? /* not fcntl */ > +#define O_ASYNC??? ??? ?0x1000 > + > +#define __O_DIRECT??? ?0x8000??? /* Direct disk access hint.? */ > +#define __O_DSYNC??? ?0x0010??? /* Synchronize data.? */ > + > +#if _MIPS_SIM == _ABI64 > +/* Not necessary, files are always with 64bit off_t.? */ > +# define __O_LARGEFILE? 0 > +#else > +# define __O_LARGEFILE??? 0x2000??? /* Allow large file opens. */ > ?#endif > > -#ifdef __x86_64__ > -/* Not necessary, we always have 64-bit offsets.? */ > -# define F_GETLK64??? 5??? /* Get record locking info.? */ > -# define F_SETLK64??? 6??? /* Set record locking info (non-blocking).? */ > -# define F_SETLKW64??? 7??? /* Set record locking info (blocking).??? */ > +#ifndef __USE_FILE_OFFSET64 > +# define F_GETLK??? 14??? /* Get record locking info.? */ > +# define F_SETLK??? 6??? /* Set record locking info (non-blocking).? */ > +# define F_SETLKW??? 7??? /* Set record locking info (blocking).??? */ > +#else > +# define F_GETLK??? F_GETLK64? /* Get record locking info.??? */ > +# define F_SETLK??? F_SETLK64? /* Set record locking info > (non-blocking).*/ > +# define F_SETLKW??? F_SETLKW64 /* Set record locking info (blocking).? */ > ?#endif > > +#if _MIPS_SIM != _ABI64 > +# define F_GETLK64??? 33??? /* Get record locking info.? */ > +# define F_SETLK64??? 34??? /* Set record locking info (non-blocking).? */ > +# define F_SETLKW64??? 35??? /* Set record locking info (blocking).??? */ > +#else > +# define F_GETLK64??? 14??? /* Get record locking info.??? */ > +# define F_SETLK64??? 6??? /* Set record locking info (non-blocking).*/ > +# define F_SETLKW64??? 7??? /* Set record locking info (blocking).? */ > +#endif > + > +#define __F_SETOWN??? 24??? /* Get owner (process receiving SIGIO).? */ > +#define __F_GETOWN??? 23??? /* Set owner (process receiving SIGIO).? */ > > ?struct flock > ?? { > @@ -39,12 +71,23 @@ > ?#ifndef __USE_FILE_OFFSET64 > ???? __off_t l_start;??? /* Offset where the lock begins.? */ > ???? __off_t l_len;??? /* Size of the locked area; zero means until > EOF.? */ > +#if _MIPS_SIM != _ABI64 > +??? /* The 64-bit flock structure, used by the n64 ABI, and for 64-bit > +?????? fcntls in o32 and n32, never has this field.? */ > +??? long int l_sysid; > +#endif > ?#else > ???? __off64_t l_start;??? /* Offset where the lock begins.? */ > ???? __off64_t l_len;??? /* Size of the locked area; zero means until > EOF.? */ > ?#endif > ???? __pid_t l_pid;??? /* Process holding the lock.? */ > +#if ! defined __USE_FILE_OFFSET64 && _MIPS_SIM != _ABI64 > +??? /* The 64-bit flock structure, used by the n64 ABI, and for 64-bit > +?????? flock in o32 and n32, never has this field.? */ > +??? long int __glibc_reserved0[4]; > +#endif > ?? }; > +typedef struct flock flock_t; > > ?#ifdef __USE_LARGEFILE64 > ?struct flock64 > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > 2. > > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/jdk/bin/jmod > -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 create > --module-version 12-internal --target-platform 'linux-mips64el' > --module-path > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/interim-jmods > --libs > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_libs/java.base > --cmds > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_cmds/java.base > --config > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_conf/java.base > --class-path > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/jdk/modules/java.base > --header-files > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_include/java.base > --legal-notices > "/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_legal/common:/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/modules_legal/java.base" > --exclude > '**{_the.*,_*.marker,*.diz,*.debuginfo,*.dSYM/**,*.dSYM,*.pdb,*.map}' > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/interim-jmods/temp/java.base.jmod > > >(/usr/bin/tee -a > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/jmods/java.base.jmod.log) > 2> >(/usr/bin/tee -a > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/jmods/java.base.jmod.log > >&2) || ( exitcode=$? && /bin/cp > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/jmods/java.base.jmod.log > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/make-support/failure-logs/buildjdk_support_jmods_java.base.jmod.log > && /bin/cp > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/buildjdk/support/jmods/java.base.jmod.cmdline > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/make-support/failure-logs/buildjdk_support_jmods_java.base.jmod.cmdline > && exit $exitcode ) ) > Error: > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/interim-jmods/temp/.java.base.jmod.tmp > > java.nio.file.NoSuchFileException: > /home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/interim-jmods/temp/.java.base.jmod.tmp > > ??? at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > > ??? at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > > ??? at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > > ??? at > java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:215) > > ??? at > java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:478) > > ??? at java.base/java.nio.file.Files.newOutputStream(Files.java:219) > ??? at > jdk.jlink/jdk.tools.jmod.JmodOutputStream.newOutputStream(JmodOutputStream.java:52) > > ??? at jdk.jlink/jdk.tools.jmod.JmodTask.create(JmodTask.java:437) > ??? at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:208) > ??? at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34) > CreateJmods.gmk:162: recipe for target > '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/interim-jmods/java.base.jmod' > failed > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > 3. > > https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html#cross-compiling > > > 4. > > $ ./build/linux-mips64el-normal-server-fastdebug/images/jdk/bin/java > -version > openjdk version "12-internal" 2019-03-19 > OpenJDK Runtime Environment (fastdebug build > 12-internal+0-adhoc.loongson.jdk-mips) > OpenJDK 64-Bit Server VM (fastdebug build > 12-internal+0-adhoc.loongson.jdk-mips, mixed mode) > > 5. > > diff -r 294c0bb90976 > src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template > --- a/src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template > Wed Jan 09 15:39:04 2019 +0800 > +++ b/src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template > Thu Jan 24 10:19:04 2019 +0800 > @@ -28,7 +28,11 @@ > ?#include > ?#include > ?#include > +#ifdef MIPS_SYSROOT > +#include > +#else > ?#include > +#endif > ?#include > > ?/* On Solaris, "sun" is defined as a macro. Undefine to make package > > 6. > > $ file build/linux-mips64el-normal-server-fastdebug/buildjdk/jdk/bin/jmod > build/linux-mips64el-normal-server-fastdebug/buildjdk/jdk/bin/jmod: ELF > 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, > interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, > BuildID[sha1]=7095b74502322b08957f0b4aaa3b9c5c8ceba5b6, not stripped > > $ file build/linux-mips64el-normal-server-fastdebug/images/jdk/bin/jmod > build/linux-mips64el-normal-server-fastdebug/images/jdk/bin/jmod: ELF > 64-bit LSB shared object, MIPS, MIPS64 rel2 version 1 (SYSV), > dynamically linked, interpreter /lib64/ld.so.1, > BuildID[sha1]=4dd81abf1b06d9bc90063b53a50549dd15434232, for GNU/Linux > 3.2.0, not stripped > > From zhaixiang at loongson.cn Thu Jan 24 03:21:05 2019 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Thu, 24 Jan 2019 11:21:05 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> References: <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> Message-ID: <1619344a-79c2-9d56-1aa6-c832d86e87cd@loongson.cn> Hi David, Thanks for your kind response! You point out the root cause: executing a tool on the build platform (X86 host) using the newly compiled classes for the target platform (MIPS target) especially when the flags' macro is different. I will use workaround 1 before fix the root cause. Regards, Leslie Zhai From aoqi at loongson.cn Thu Jan 24 03:51:43 2019 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 24 Jan 2019 11:51:43 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> Message-ID: Hi David, On Thu, Jan 24, 2019 at 10:47 AM David Holmes wrote: > > Hi Leslie, > > I'm not Erik :) however .... > > On 24/01/2019 12:28 pm, Leslie Zhai wrote: > > Hi Erik, > > > > Because the flags' macro of MIPS is different from other targets[1], it > > will effect the `UnixConstants` of > > src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, for > > example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different > > from other targets. Then failed[2] to cross compiling jdk12 for > > mips64el-linux-gnu target by following the document[3]. > > It's been quite a while since we built for a platform where the flags > had different values, but it is supposed to work. I suspect that the way > we build now with the module system may not be quite correct in this > regard - but that is just supposition on my part. Because compile-time > constants are stored directly into class files that use them, we have to > generate UnixConstants.java before compiling any class that needs to use > it, then we must compile all classes that do use it. Those classes must > only be executed in conjunction with a tool executing on the target > platform (javac, jmod etc). My suspicion is that we may be executing a > tool on the build platform using the newly compiled classes for the > target platform - and that would be wrong. > Yes. Some variables in UnixConstants.java is defined according to the target (fcntl.h of mips in this case), but would be executed on host (x86 in this case) during "make images". These variables of ppc64le, aarch64 and s390x are the same as x86, but the ones of mips are not. However, mips is not an official supported target and I did not find other targets have similar issue, I am not sure if this is a bug or if this is the right mailing list :) For example: jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: static final int O_APPEND = ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- 02000 -- ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: static final int O_APPEND = ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- 02000 -- ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: static final int O_APPEND = ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- 02000 -- ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: static final int O_APPEND = ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- 02000 -- ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: static final int O_APPEND = ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- 02000 -- ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: static final int O_APPEND = ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- 0x0008 -- ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: static final int O_APPEND = ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- 02000 log.mips:2of path: /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 log.ppc:2of path: /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 Cheers, Ao Qi From david.holmes at oracle.com Thu Jan 24 04:45:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2019 14:45:41 +1000 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> Message-ID: <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> On 24/01/2019 1:51 pm, Ao Qi wrote: > Hi David, > > On Thu, Jan 24, 2019 at 10:47 AM David Holmes wrote: >> >> Hi Leslie, >> >> I'm not Erik :) however .... >> >> On 24/01/2019 12:28 pm, Leslie Zhai wrote: >>> Hi Erik, >>> >>> Because the flags' macro of MIPS is different from other targets[1], it >>> will effect the `UnixConstants` of >>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, for >>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different >>> from other targets. Then failed[2] to cross compiling jdk12 for >>> mips64el-linux-gnu target by following the document[3]. >> >> It's been quite a while since we built for a platform where the flags >> had different values, but it is supposed to work. I suspect that the way >> we build now with the module system may not be quite correct in this >> regard - but that is just supposition on my part. Because compile-time >> constants are stored directly into class files that use them, we have to >> generate UnixConstants.java before compiling any class that needs to use >> it, then we must compile all classes that do use it. Those classes must >> only be executed in conjunction with a tool executing on the target >> platform (javac, jmod etc). My suspicion is that we may be executing a >> tool on the build platform using the newly compiled classes for the >> target platform - and that would be wrong. >> > > Yes. Some variables in UnixConstants.java is defined according to the > target (fcntl.h of mips in this case), but would be executed on host > (x86 in this case) during "make images". These variables of ppc64le, > aarch64 and s390x are the same as x86, but the ones of mips are not. > However, mips is not an official supported target and I did not find > other targets have similar issue, I am not sure if this is a bug or if > this is the right mailing list :) This is the right mailing list to discuss. :) So I went back to find when this happened in the past and I mis-remembered how we solved it. We previously had a problem with the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 platforms defined a different value for the O_NOFOLLOW and O_DIRECT flags. The solution then was to commit a platform specific version of UnixConstants.java and change the build system to only use the template file if there was not a pre-existing .java file. But that platform and the SE Embedded support was all removed. (SocketOptions.java had a similar problem.) Further that build logic is completely different to what we had back then (JDK 6/7). This is definitely a bug in our build logic IMHO as we specifically use the build platform c-pre-processor to process the template file based on the target header files, but then use the resulting class when running tools on the build platform. This was not something that happened in 6/7 or even 8 and I think the module system tools are where the issue now lies. I think Erik and/or Magnus will have to give advice on how this may be properly fixed. I can't see any simple solution. David ----- > For example: > > jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND > ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > static final int O_APPEND = > ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > 02000 > -- > ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > static final int O_APPEND = > ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > 02000 > -- > ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > static final int O_APPEND = > ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > 02000 > -- > ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > static final int O_APPEND = > ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > 02000 > -- > ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > static final int O_APPEND = > ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > 02000 > -- > ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > static final int O_APPEND = > ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > 0x0008 > -- > ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > static final int O_APPEND = > ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > 02000 > > log.mips:2of path: > /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp > oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 > log.ppc:2of path: > /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp > oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 > > Cheers, > Ao Qi > From magnus.ihse.bursie at oracle.com Thu Jan 24 10:11:31 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 11:11:31 +0100 Subject: RFR: JDK-8217634 RunTest documentation and usability update In-Reply-To: <3bfd6845-7034-a33d-f905-77f8b7fa9aa4@oracle.com> References: <3bfd6845-7034-a33d-f905-77f8b7fa9aa4@oracle.com> Message-ID: <88a99206-df0c-66d0-debb-5352c0edc353@oracle.com> On 2019-01-23 18:33, Erik Joelsson wrote: > Hello, > > This looks good. Just one note, the example "configure > --with-jcov=.../jcov.jar" is incorrect. The configure parameter > expects a jcov home dir with lib/jcov.jar in it. For a better user > experience, perhaps the configure arg should be changed to accept both? Ah, I see. No, we can't change the behavior of the configure flag; I checked the code and we also assume that $(JCOV_HOME)/lib/jcov_network_saver.jar exists. (In fact, maybe we should verify this in configure...) I'll update the example to be correct. /Magnus > > /Erik > > On 2019-01-23 05:25, Magnus Ihse Bursie wrote: >> The RunTest documentation (doc/testing.md) has not been properly >> updated with the latest changes. >> >> Also, some newly added keywords were not classified as STRING, but as >> SINGLE to ParseKeywordVariable, which means that the user would not >> have the quoting support that should have been available. >> >> I also added in some whitespace fixes, for good measure. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217634 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8217634-runtest-love-and-care/webrev.01 >> >> /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 24 12:05:47 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 13:05:47 +0100 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> Message-ID: <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> On 2019-01-24 05:45, David Holmes wrote: > On 24/01/2019 1:51 pm, Ao Qi wrote: >> Hi David, >> >> On Thu, Jan 24, 2019 at 10:47 AM David Holmes >> wrote: >>> >>> Hi Leslie, >>> >>> I'm not Erik :) however .... >>> >>> On 24/01/2019 12:28 pm, Leslie Zhai wrote: >>>> Hi Erik, >>>> >>>> Because the flags' macro of MIPS is different from other >>>> targets[1], it >>>> will effect the `UnixConstants` of >>>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, for >>>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different >>>> from other targets.? Then failed[2] to cross compiling jdk12 for >>>> mips64el-linux-gnu target by following the document[3]. >>> >>> It's been quite a while since we built for a platform where the flags >>> had different values, but it is supposed to work. I suspect that the >>> way >>> we build now with the module system may not be quite correct in this >>> regard - but that is just supposition on my part. Because compile-time >>> constants are stored directly into class files that use them, we >>> have to >>> generate UnixConstants.java before compiling any class that needs to >>> use >>> it, then we must compile all classes that do use it. Those classes must >>> only be executed in conjunction with a tool executing on the target >>> platform (javac, jmod etc). My suspicion is that we may be executing a >>> tool on the build platform using the newly compiled classes for the >>> target platform - and that would be wrong. >>> >> >> Yes. Some variables in UnixConstants.java is defined according to the >> target (fcntl.h of mips in this case), but would be executed on host >> (x86 in this case) during "make images". These variables of ppc64le, >> aarch64 and s390x are the same as x86, but the ones of mips are not. >> However, mips is not an official supported target and I did not find >> other targets have similar issue, I am not sure if this is a bug or if >> this is the right mailing list :) > > This is the right mailing list to discuss. :) > > So I went back to find when this happened in the past and I > mis-remembered how we solved it. We previously had a problem with the > Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 platforms > defined a different value for the O_NOFOLLOW and O_DIRECT flags. The > solution then was to commit a platform specific version of > UnixConstants.java and change the build system to only use the > template file if there was not a pre-existing .java file. But that > platform and the SE Embedded support was all removed. > (SocketOptions.java had a similar problem.) Further that build logic > is completely different to what we had back then (JDK 6/7). > > This is definitely a bug in our build logic IMHO as we specifically > use the build platform c-pre-processor to process the template file > based on the target header files, but then use the resulting class > when running tools on the build platform. I agree with David. This is a bug in the build system; arguably even a regression. > This was not something that happened in 6/7 or even 8 and I think the > module system tools are where the issue now lies. > > I think Erik and/or Magnus will have to give advice on how this may be > properly fixed. I can't see any simple solution. Unfortunately, I also agree that there is no simple solution. :-( The proper way to handle this is to generate two versions of UnixConstants and friends, one for the build platform, and one for the target platform. But as far as I know, there is no simple way to handle such complications in our current structure. Erik knows more about this, he was the one who designed the current solution for handling cross-compilation in the modularized world. However, I can at least help you with a relatively simple workaround. First some background: When we cross-compile, we need not only a Boot JDK (of version current N-1) running on the build host platform, but we also need a Build JDK, based on the current source code, running on the build host. (This is for running jmod/jlink; it needs to be up to date). If we have no Build JDK present, we start by creating one ourselves. This is more or less the same output as running a normal, non-cross compiled, build on the build host. (But Erik found some ways to cut a few corners to save time.) Your problem is that the Build JDK is broken, since UnixConstants has the wrong values. - But you can supply your own working Build JDK to configure! So, your workflow for cross-compiling to MIPS should be: 1) create a Build JDK, e.g. like this: "bash configure --with-conf-name=buildjdk && make jdk CONF=buildjdk" 2) create your cross-compilation JDK like this: "bash configure --openjdk-target=mipsel-unknown-linux-gnu --with-build-jdk=build/buildjdk/jdk" ... or something like that. Then you can build your cross-compiled jdk with "make images CONF=mips". In theory, you should rebuild your buildjdk for each and every change ("make jdk CONF=buildjdk && make images CONF=mips"); but in reality, I don't believe there is really any need to rebuild the buildjdk (unless major changes in jlink/jmod happens). /Magnus > > David > ----- > >> ? For example: >> >> jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND >> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >> >> ??? static final int O_APPEND = >> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ????????????????????????????????????? 02000 >> -- >> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >> >> ??? static final int O_APPEND = >> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ????????????????????????????????????? 02000 >> -- >> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >> >> ??? static final int O_APPEND = >> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ????????????????????????????????????? 02000 >> -- >> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >> >> ??? static final int O_APPEND = >> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ????????????????????????????????????? 02000 >> -- >> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >> >> ??? static final int O_APPEND = >> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ????????????????????????????????????? 02000 >> -- >> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >> >> ??? static final int O_APPEND = >> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ????????????????????????????????????? 0x0008 >> -- >> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >> >> ??? static final int O_APPEND = >> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >> >> ????????????????????????????????????? 02000 >> >> log.mips:2of path: >> /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >> >> oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 >> log.ppc:2of path: >> /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >> >> oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 >> >> Cheers, >> Ao Qi >> From zhaixiang at loongson.cn Thu Jan 24 12:22:18 2019 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Thu, 24 Jan 2019 20:22:18 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> Message-ID: <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> Hi Magnus, Thanks for your kind response! ? 2019/1/24 ??8:05, Magnus Ihse Bursie ??: > > > On 2019-01-24 05:45, David Holmes wrote: >> On 24/01/2019 1:51 pm, Ao Qi wrote: >>> Hi David, >>> >>> On Thu, Jan 24, 2019 at 10:47 AM David Holmes >>> wrote: >>>> >>>> Hi Leslie, >>>> >>>> I'm not Erik :) however .... >>>> >>>> On 24/01/2019 12:28 pm, Leslie Zhai wrote: >>>>> Hi Erik, >>>>> >>>>> Because the flags' macro of MIPS is different from other >>>>> targets[1], it >>>>> will effect the `UnixConstants` of >>>>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, >>>>> for >>>>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is >>>>> different >>>>> from other targets.? Then failed[2] to cross compiling jdk12 for >>>>> mips64el-linux-gnu target by following the document[3]. >>>> >>>> It's been quite a while since we built for a platform where the flags >>>> had different values, but it is supposed to work. I suspect that >>>> the way >>>> we build now with the module system may not be quite correct in this >>>> regard - but that is just supposition on my part. Because compile-time >>>> constants are stored directly into class files that use them, we >>>> have to >>>> generate UnixConstants.java before compiling any class that needs >>>> to use >>>> it, then we must compile all classes that do use it. Those classes >>>> must >>>> only be executed in conjunction with a tool executing on the target >>>> platform (javac, jmod etc). My suspicion is that we may be executing a >>>> tool on the build platform using the newly compiled classes for the >>>> target platform - and that would be wrong. >>>> >>> >>> Yes. Some variables in UnixConstants.java is defined according to the >>> target (fcntl.h of mips in this case), but would be executed on host >>> (x86 in this case) during "make images". These variables of ppc64le, >>> aarch64 and s390x are the same as x86, but the ones of mips are not. >>> However, mips is not an official supported target and I did not find >>> other targets have similar issue, I am not sure if this is a bug or if >>> this is the right mailing list :) >> >> This is the right mailing list to discuss. :) >> >> So I went back to find when this happened in the past and I >> mis-remembered how we solved it. We previously had a problem with the >> Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 >> platforms defined a different value for the O_NOFOLLOW and O_DIRECT >> flags. The solution then was to commit a platform specific version of >> UnixConstants.java and change the build system to only use the >> template file if there was not a pre-existing .java file. But that >> platform and the SE Embedded support was all removed. >> (SocketOptions.java had a similar problem.) Further that build logic >> is completely different to what we had back then (JDK 6/7). >> >> This is definitely a bug in our build logic IMHO as we specifically >> use the build platform c-pre-processor to process the template file >> based on the target header files, but then use the resulting class >> when running tools on the build platform. > I agree with David. This is a bug in the build system; arguably even a > regression. > >> This was not something that happened in 6/7 or even 8 and I think the >> module system tools are where the issue now lies. >> >> I think Erik and/or Magnus will have to give advice on how this may >> be properly fixed. I can't see any simple solution. > Unfortunately, I also agree that there is no simple solution. :-( > > The proper way to handle this is to generate two versions of > UnixConstants and friends, one for the build platform, and one for the > target platform. But as far as I know, there is no simple way to > handle such complications in our current structure. Erik knows more > about this, he was the one who designed the current solution for > handling cross-compilation in the modularized world. > > However, I can at least help you with a relatively simple workaround. > First some background: When we cross-compile, we need not only a Boot > JDK (of version current N-1) running on the build host platform, but > we also need a Build JDK, based on the current source code, running on > the build host. (This is for running jmod/jlink; it needs to be up to > date). If we have no Build JDK present, we start by creating one > ourselves. This is more or less the same output as running a normal, > non-cross compiled, build on the build host. (But Erik found some ways > to cut a few corners to save time.) Your problem is that the Build JDK > is broken, since UnixConstants has the wrong values. > - > But you can supply your own working Build JDK to configure! > > So, your workflow for cross-compiling to MIPS should be: > 1) create a Build JDK, e.g. like this: "bash configure > --with-conf-name=buildjdk && make jdk CONF=buildjdk" > 2) create your cross-compilation JDK like this: "bash configure > --openjdk-target=mipsel-unknown-linux-gnu > --with-build-jdk=build/buildjdk/jdk" > ... or something like that. > Then you can build your cross-compiled jdk with "make images CONF=mips". I will try that, thanks a lot for your teaching! Regards, Leslie Zhai > > > In theory, you should rebuild your buildjdk for each and every change > ("make jdk CONF=buildjdk && make images CONF=mips"); but in reality, I > don't believe there is really any need to rebuild the buildjdk (unless > major changes in jlink/jmod happens). > > /Magnus >> >> David >> ----- >> >>> ? For example: >>> >>> jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND >>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>> >>> ??? static final int O_APPEND = >>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ????????????????????????????????????? 02000 >>> -- >>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>> >>> ??? static final int O_APPEND = >>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ????????????????????????????????????? 02000 >>> -- >>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>> >>> ??? static final int O_APPEND = >>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ????????????????????????????????????? 02000 >>> -- >>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>> >>> ??? static final int O_APPEND = >>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ????????????????????????????????????? 02000 >>> -- >>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>> >>> ??? static final int O_APPEND = >>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ????????????????????????????????????? 02000 >>> -- >>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>> >>> ??? static final int O_APPEND = >>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ????????????????????????????????????? 0x0008 >>> -- >>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>> >>> ??? static final int O_APPEND = >>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>> >>> ????????????????????????????????????? 02000 >>> >>> log.mips:2of path: >>> /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>> >>> oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 >>> log.ppc:2of path: >>> /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>> >>> oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 >>> >>> Cheers, >>> Ao Qi >>> > From magnus.ihse.bursie at oracle.com Thu Jan 24 13:11:19 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 14:11:19 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain Message-ID: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> The default binutils linker used by gcc, the bfd linker, is slow. The new replacement, gold, has been distributed alongside gcc for several years now, and is a well mature, and much faster, replacement. This issue is about replacing ld.bfd with ld.gold for our gcc toolchain. In general, this cuts linking times by half or more. As a future improvement, gold also allows for incremental linking. Turning on that is outside the scope of this issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8217723 Patch inline: diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4 --- a/make/autoconf/flags-ldflags.m4 +++ b/make/autoconf/flags-ldflags.m4 @@ -70,7 +70,7 @@ ???? fi ???? # Add -z defs, to forbid undefined symbols in object files. -??? BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs" +??? BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -fuse-ld=gold" ???? BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro" /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 24 13:15:53 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 14:15:53 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> Message-ID: I see now on Wikipedia that gold was added to binutils 2.19.[1] (I thought it was older still...) We currently have this check: TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18" As part of this fix, I ought to bump it to 2.19, so we know for sure that gold is included. Volker, would that be a problem for you? /Magnus [1] https://en.wikipedia.org/wiki/Gold_(linker) On 2019-01-24 14:11, Magnus Ihse Bursie wrote: > The default binutils linker used by gcc, the bfd linker, is slow. The > new replacement, gold, has been distributed alongside gcc for several > years now, and is a well mature, and much faster, replacement. > > This issue is about replacing ld.bfd with ld.gold for our gcc > toolchain. In general, this cuts linking times by half or more. > > As a future improvement, gold also allows for incremental linking. > Turning on that is outside the scope of this issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217723 > Patch inline: > diff --git a/make/autoconf/flags-ldflags.m4 > b/make/autoconf/flags-ldflags.m4 > --- a/make/autoconf/flags-ldflags.m4 > +++ b/make/autoconf/flags-ldflags.m4 > @@ -70,7 +70,7 @@ > ???? fi > > ???? # Add -z defs, to forbid undefined symbols in object files. > -??? BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs" > +??? BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -fuse-ld=gold" > > ???? BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro" > > /Magnus From glaubitz at physik.fu-berlin.de Thu Jan 24 13:20:42 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Jan 2019 14:20:42 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> Message-ID: <2192c601-5aaa-8251-ec58-2f6d5ba58ce0@physik.fu-berlin.de> On 1/24/19 2:11 PM, Magnus Ihse Bursie wrote: > The default binutils linker used by gcc, the bfd linker, is slow. > The new replacement, gold, has been distributed alongside gcc for > several years now, and is a well mature, and much faster, replacement. I would recommend testing this change on all supported targets. Gold is definitely not as mature on all targets as bfd in my experience. There are still some cases where it can cause issues. 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 shade at redhat.com Thu Jan 24 13:25:00 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 24 Jan 2019 14:25:00 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> Message-ID: On 1/24/19 2:15 PM, Magnus Ihse Bursie wrote: > I see now on Wikipedia that gold was added to binutils 2.19.[1] (I thought it was older still...) > We currently have this check: > TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18" > > As part of this fix, I ought to bump it to 2.19, so we know for sure that gold is included. Not sure it would be compatible with all current build environments. I asked Red Hat people if this would be problematic for them. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217723 >> Patch inline: >> diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4 >> --- a/make/autoconf/flags-ldflags.m4 >> +++ b/make/autoconf/flags-ldflags.m4 >> @@ -70,7 +70,7 @@ >> ???? fi >> >> ???? # Add -z defs, to forbid undefined symbols in object files. >> -??? BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs" >> +??? BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -fuse-ld=gold" >> >> ???? BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro" That'd be nice. Maybe we should check for the presence of ld.gold, though, and override LD when it is available? That would also allow the fallback when ld.gold is misbehaving, but setting LD forcefully. -Aleksey From magnus.ihse.bursie at oracle.com Thu Jan 24 13:28:41 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 14:28:41 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <2192c601-5aaa-8251-ec58-2f6d5ba58ce0@physik.fu-berlin.de> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <2192c601-5aaa-8251-ec58-2f6d5ba58ce0@physik.fu-berlin.de> Message-ID: <0516f7cb-98e7-f07f-d066-7f79cdade89d@oracle.com> On 2019-01-24 14:20, John Paul Adrian Glaubitz wrote: > On 1/24/19 2:11 PM, Magnus Ihse Bursie wrote: >> The default binutils linker used by gcc, the bfd linker, is slow. >> The new replacement, gold, has been distributed alongside gcc for >> several years now, and is a well mature, and much faster, replacement. > I would recommend testing this change on all supported targets. Gold is > definitely not as mature on all targets as bfd in my experience. There > are still some cases where it can cause issues. Good point. I was mainly considering x86_64 here. It might be safest to limit the use of gold to this platform. From the developer point of view, it's the one that counts most. But even if I change this to only use gold on x86_64, I'd still like to bump the binutils version globally. There's no good way to express different version requirements on different platforms for the same toolchain. Do you see a problem with that? /Magnus > > Adrian > From magnus.ihse.bursie at oracle.com Thu Jan 24 13:30:53 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 14:30:53 +0100 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> Message-ID: On 2019-01-24 13:22, Leslie Zhai wrote: > Hi Magnus, > > Thanks for your kind response! > > ? 2019/1/24 ??8:05, Magnus Ihse Bursie ??: >> >> >> On 2019-01-24 05:45, David Holmes wrote: >>> On 24/01/2019 1:51 pm, Ao Qi wrote: >>>> Hi David, >>>> >>>> On Thu, Jan 24, 2019 at 10:47 AM David Holmes >>>> wrote: >>>>> >>>>> Hi Leslie, >>>>> >>>>> I'm not Erik :) however .... >>>>> >>>>> On 24/01/2019 12:28 pm, Leslie Zhai wrote: >>>>>> Hi Erik, >>>>>> >>>>>> Because the flags' macro of MIPS is different from other >>>>>> targets[1], it >>>>>> will effect the `UnixConstants` of >>>>>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, >>>>>> for >>>>>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is >>>>>> different >>>>>> from other targets.? Then failed[2] to cross compiling jdk12 for >>>>>> mips64el-linux-gnu target by following the document[3]. >>>>> >>>>> It's been quite a while since we built for a platform where the flags >>>>> had different values, but it is supposed to work. I suspect that >>>>> the way >>>>> we build now with the module system may not be quite correct in this >>>>> regard - but that is just supposition on my part. Because >>>>> compile-time >>>>> constants are stored directly into class files that use them, we >>>>> have to >>>>> generate UnixConstants.java before compiling any class that needs >>>>> to use >>>>> it, then we must compile all classes that do use it. Those classes >>>>> must >>>>> only be executed in conjunction with a tool executing on the target >>>>> platform (javac, jmod etc). My suspicion is that we may be >>>>> executing a >>>>> tool on the build platform using the newly compiled classes for the >>>>> target platform - and that would be wrong. >>>>> >>>> >>>> Yes. Some variables in UnixConstants.java is defined according to the >>>> target (fcntl.h of mips in this case), but would be executed on host >>>> (x86 in this case) during "make images". These variables of ppc64le, >>>> aarch64 and s390x are the same as x86, but the ones of mips are not. >>>> However, mips is not an official supported target and I did not find >>>> other targets have similar issue, I am not sure if this is a bug or if >>>> this is the right mailing list :) >>> >>> This is the right mailing list to discuss. :) >>> >>> So I went back to find when this happened in the past and I >>> mis-remembered how we solved it. We previously had a problem with >>> the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 >>> platforms defined a different value for the O_NOFOLLOW and O_DIRECT >>> flags. The solution then was to commit a platform specific version >>> of UnixConstants.java and change the build system to only use the >>> template file if there was not a pre-existing .java file. But that >>> platform and the SE Embedded support was all removed. >>> (SocketOptions.java had a similar problem.) Further that build logic >>> is completely different to what we had back then (JDK 6/7). >>> >>> This is definitely a bug in our build logic IMHO as we specifically >>> use the build platform c-pre-processor to process the template file >>> based on the target header files, but then use the resulting class >>> when running tools on the build platform. >> I agree with David. This is a bug in the build system; arguably even >> a regression. >> >>> This was not something that happened in 6/7 or even 8 and I think >>> the module system tools are where the issue now lies. >>> >>> I think Erik and/or Magnus will have to give advice on how this may >>> be properly fixed. I can't see any simple solution. >> Unfortunately, I also agree that there is no simple solution. :-( >> >> The proper way to handle this is to generate two versions of >> UnixConstants and friends, one for the build platform, and one for >> the target platform. But as far as I know, there is no simple way to >> handle such complications in our current structure. Erik knows more >> about this, he was the one who designed the current solution for >> handling cross-compilation in the modularized world. >> >> However, I can at least help you with a relatively simple workaround. >> First some background: When we cross-compile, we need not only a Boot >> JDK (of version current N-1) running on the build host platform, but >> we also need a Build JDK, based on the current source code, running >> on the build host. (This is for running jmod/jlink; it needs to be up >> to date). If we have no Build JDK present, we start by creating one >> ourselves. This is more or less the same output as running a normal, >> non-cross compiled, build on the build host. (But Erik found some >> ways to cut a few corners to save time.) Your problem is that the >> Build JDK is broken, since UnixConstants has the wrong values. >> - >> But you can supply your own working Build JDK to configure! >> >> So, your workflow for cross-compiling to MIPS should be: >> 1) create a Build JDK, e.g. like this: "bash configure >> --with-conf-name=buildjdk && make jdk CONF=buildjdk" >> 2) create your cross-compilation JDK like this: "bash configure >> --openjdk-target=mipsel-unknown-linux-gnu >> --with-build-jdk=build/buildjdk/jdk" >> ... or something like that. >> Then you can build your cross-compiled jdk with "make images CONF=mips". > > I will try that, thanks a lot for your teaching! Please let me know if it works. I wrote the command lines out of my head, so they might need some tweaking to get right. Perhaps this is an acceptable solution to you? Unless Erik can suggest ways to fix this properly that is not too complicated, maybe this can be a good enough solution for you? (But if there is a simple solution, I'd rather have it fixed properly.) /Magnus > > Regards, > > Leslie Zhai > > >> >> >> In theory, you should rebuild your buildjdk for each and every change >> ("make jdk CONF=buildjdk && make images CONF=mips"); but in reality, >> I don't believe there is really any need to rebuild the buildjdk >> (unless major changes in jlink/jmod happens). >> >> /Magnus >>> >>> David >>> ----- >>> >>>> ? For example: >>>> >>>> jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND >>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>> >>>> ??? static final int O_APPEND = >>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ????????????????????????????????????? 02000 >>>> -- >>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>> >>>> ??? static final int O_APPEND = >>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ????????????????????????????????????? 02000 >>>> -- >>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>> >>>> ??? static final int O_APPEND = >>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ????????????????????????????????????? 02000 >>>> -- >>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>> >>>> ??? static final int O_APPEND = >>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ????????????????????????????????????? 02000 >>>> -- >>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>> >>>> ??? static final int O_APPEND = >>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ????????????????????????????????????? 02000 >>>> -- >>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>> >>>> ??? static final int O_APPEND = >>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ????????????????????????????????????? 0x0008 >>>> -- >>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>> >>>> ??? static final int O_APPEND = >>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>> >>>> ????????????????????????????????????? 02000 >>>> >>>> log.mips:2of path: >>>> /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>>> >>>> oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 >>>> log.ppc:2of path: >>>> /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>>> >>>> oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 >>>> >>>> Cheers, >>>> Ao Qi >>>> >> > From fweimer at redhat.com Thu Jan 24 13:45:26 2019 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 24 Jan 2019 14:45:26 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> (Magnus Ihse Bursie's message of "Thu, 24 Jan 2019 14:11:19 +0100") References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> Message-ID: <8736pi6ufd.fsf@oldenburg2.str.redhat.com> * Magnus Ihse Bursie: > The default binutils linker used by gcc, the bfd linker, is slow. The > new replacement, gold, has been distributed alongside gcc for several > years now, and is a well mature, and much faster, replacement. The gold linker is an optional component of binutils, not available in all builds. For example, binutils in Red Hat Enterprise Linux 7.6 does not include gold on the ppc64le architecture. The gold linker also supports a different set of features compared to BFD ld, which may or may not be what you want. But I think OpenJDK does not use many tricky ELF features, so the differences probably do not matter. Is it possible to add -fuse-ld=gold to LDFLAGS externally, outside the build system, so that the build system can use the gold linker if people prefer it over BFD ld? Or you could configure your binutils with --enable-gold=default, so that it defaults to ld.gold, again not requiring any OpenJDK changes. Thanks, Florian From magnus.ihse.bursie at oracle.com Thu Jan 24 14:04:27 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 15:04:27 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <8736pi6ufd.fsf@oldenburg2.str.redhat.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> Message-ID: <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> On 2019-01-24 14:45, Florian Weimer wrote: > * Magnus Ihse Bursie: > >> The default binutils linker used by gcc, the bfd linker, is slow. The >> new replacement, gold, has been distributed alongside gcc for several >> years now, and is a well mature, and much faster, replacement. > The gold linker is an optional component of binutils, not available in > all builds. For example, binutils in Red Hat Enterprise Linux 7.6 does > not include gold on the ppc64le architecture. > > The gold linker also supports a different set of features compared to > BFD ld, which may or may not be what you want. But I think OpenJDK does > not use many tricky ELF features, so the differences probably do not > matter. > > Is it possible to add -fuse-ld=gold to LDFLAGS externally, outside the > build system, so that the build system can use the gold linker if people > prefer it over BFD ld? > > Or you could configure your binutils with --enable-gold=default, so that > it defaults to ld.gold, again not requiring any OpenJDK changes. One of the driving forces behind this bug is the speed increase in gold by itself. You are correct that to achieve this, a solution outside the build system can be used. However, the other driving force is the ability to enable incremental linking. The build system must know if we use gold, so that it knows that those command line options are available. So to resort to the solution of changing the environment would not enable that second part. But I'm leaning more towards just enabling gold on x86_64 -- for other platforms, we might as well keep the good ol' bfd linker. Does that sound like a good solution to you? /Magnus > > Thanks, > Florian From magnus.ihse.bursie at oracle.com Thu Jan 24 14:24:59 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 15:24:59 +0100 Subject: RFR: JDK-8217730 Split up MakeBase.gmk Message-ID: <73f66605-e99f-52e0-87bc-0961b2d0155f@oracle.com> The file MakeBase.gmk, which is included by virtually all other make files in the build system, has become gradually larger and larger. It is now one of the longest files in the build system, with little to no internal structure. I propose to split it in four parts: * Utils.gmk -- here all the simple make functions go; stuff that basically do not interact with the rest of the world, but just provides "high-level" macros to make. * CopyFiles.gmk -- here the SetupCopyFiles function goes, similar to how we treat all other SetupFoo functions. * MakeIO.gmk -- here reading and writing to files from make goes. This is mostly due to the long expression of ListPathsSafely on GNU Make prior to 4.0. *MakeBase.gmk -- functions now remaining here belong to either of these groups: ?-- it is some kind of core functionality provided by the build system, like ExecuteWithLog or NamedParamsMacroTemplate. ?-- it interacts (messily) with the environment ?-- it does something else that is tricky, or just "misc" It is of course possible to break down the remaining MakeBase.gmk even further, but it's so much more manageable now, and there are no clear ways of splitting it further without getting into very small pieces (like logging), so I think I'll stop here, for now. To retain backwards compatibility with files that include MakeBase.gmk and expect all functionality, MakeBase.gmk includes the new files. It's a future question if we should keep it that way, or put the requirement of those includes on the files needing the functionality. Bug: https://bugs.openjdk.java.net/browse/JDK-8217730 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8217730-split-up-MakeBase/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 24 14:46:22 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 15:46:22 +0100 Subject: RFR: JDK-8217733 Minor RunTest fixes Message-ID: This patch covers some different minor cleanups that I accumulated after working on RunTest: ?* Do not override JDK_IMAGE_DIR for jcov testing; instead introduce JDK_UNDER_TEST (to be really explicit about which JDK we're testing). ?* Remove unconditional $(info) printout on Windows ?* Group JCov variable setup with other variable setups. Bug: https://bugs.openjdk.java.net/browse/JDK-8217733 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8217733-minor-RunTest-fixes/webrev.01 /Magnus From martinrb at google.com Thu Jan 24 14:48:49 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Jan 2019 06:48:49 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: Getting into the business of choosing the linker is big trouble. The system default toolchain may have already chosen a linker. BFD might be configured to have either bfd ld or gold. # Handle --enable-gold, --enable-ld. # --disable-gold [--enable-ld] # Build only ld. Default option. # --enable-gold [--enable-ld] # Build both gold and ld. Install gold as "ld.gold", install ld # as "ld.bfd" and "ld". # --enable-gold=default [--enable-ld] # Build both gold and ld. Install gold as "ld.gold" and "ld", # install ld as "ld.bfd". # --enable-gold[=default] --disable-ld # Build only gold, which is then installed as both "ld.gold" and "ld". # --enable-gold --enable-ld=default # Build both gold (installed as "ld.gold") and ld (installed as "ld" # and ld.bfd). # In other words, ld is default The compiler driver itself may have been configured to choose a linker. The system administrator may have used update-alternatives to choose a linker. A user might have configured openjdk to use -fuse-ld=... (we do this!) How do you resolve the conflict? There's evidence that lld is even faster than gold. The Internet says, """Liked linking 3x faster with gold? Link 10x faster with lld!""" so hardcoding gold might be a regression! So ... -fuse-ld is a flag that is perfect for a local wrapper around configure that is __not__ part of openjdk (we do this!) From magnus.ihse.bursie at oracle.com Thu Jan 24 15:45:55 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 16:45:55 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: I agree that the relationship between compiler, linker and OS is problematic. In the OpenJDK build system, we have used the concept of "toolchain", by which we mean (amongst other things) a compiler and a linker working together. For some platforms it's a perfect fit (eg Visual Studio), for others like gcc it's so-so, for yet others (solstudio) it's really bad. So, we already tacitly assume a specific linker with the gcc toolchain; we have just not made that check explicitly. As I said in a previous email, part of the reason for this switch is to allow --incremental. So for that reason, we must know that the linker supports that option. /Magnus > 24 jan. 2019 kl. 15:48 skrev Martin Buchholz : > > Getting into the business of choosing the linker is big trouble. > > The system default toolchain may have already chosen a linker. > > BFD might be configured to have either bfd ld or gold. > # Handle --enable-gold, --enable-ld. > # --disable-gold [--enable-ld] > # Build only ld. Default option. > # --enable-gold [--enable-ld] > # Build both gold and ld. Install gold as "ld.gold", install ld > # as "ld.bfd" and "ld". > # --enable-gold=default [--enable-ld] > # Build both gold and ld. Install gold as "ld.gold" and "ld", > # install ld as "ld.bfd". > # --enable-gold[=default] --disable-ld > # Build only gold, which is then installed as both "ld.gold" and "ld". > # --enable-gold --enable-ld=default > # Build both gold (installed as "ld.gold") and ld (installed as "ld" > # and ld.bfd). > # In other words, ld is default > > The compiler driver itself may have been configured to choose a linker. > > The system administrator may have used update-alternatives to choose a linker. > > A user might have configured openjdk to use -fuse-ld=... (we do this!) > How do you resolve the conflict? > > There's evidence that lld is even faster than gold. The Internet says, > """Liked linking 3x faster with gold? Link 10x faster with lld!""" > so hardcoding gold might be a regression! > > So ... -fuse-ld is a flag that is perfect for a local wrapper around > configure that is __not__ part of openjdk (we do this!) From erik.joelsson at oracle.com Thu Jan 24 17:19:21 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Jan 2019 09:19:21 -0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> Message-ID: Hello, I agree with the conclusion here, there is certainly a bug in the build logic. When creating the "Build JDK" during a cross compilation build, we are, as Magnus said, cutting a few corners for efficiency. One of those corners is assuming all the java classes are the same and can simply be reused. It has been shown here that that assumption is not always correct. I think the most reasonable solution is to assume all of java.base needs to be built specifically for the "Build JDK". I think this can be reasonably easy to implement (compared to the existing Build JDK logic, which is arguably rather hairy). Magnus' suggested workaround should work fine for now however. Filed https://bugs.openjdk.java.net/browse/JDK-8217739 /Erik On 2019-01-24 05:30, Magnus Ihse Bursie wrote: > On 2019-01-24 13:22, Leslie Zhai wrote: >> Hi Magnus, >> >> Thanks for your kind response! >> >> ? 2019/1/24 ??8:05, Magnus Ihse Bursie ??: >>> >>> >>> On 2019-01-24 05:45, David Holmes wrote: >>>> On 24/01/2019 1:51 pm, Ao Qi wrote: >>>>> Hi David, >>>>> >>>>> On Thu, Jan 24, 2019 at 10:47 AM David Holmes >>>>> wrote: >>>>>> >>>>>> Hi Leslie, >>>>>> >>>>>> I'm not Erik :) however .... >>>>>> >>>>>> On 24/01/2019 12:28 pm, Leslie Zhai wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> Because the flags' macro of MIPS is different from other >>>>>>> targets[1], it >>>>>>> will effect the `UnixConstants` of >>>>>>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, >>>>>>> for >>>>>>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is >>>>>>> different >>>>>>> from other targets.? Then failed[2] to cross compiling jdk12 for >>>>>>> mips64el-linux-gnu target by following the document[3]. >>>>>> >>>>>> It's been quite a while since we built for a platform where the >>>>>> flags >>>>>> had different values, but it is supposed to work. I suspect that >>>>>> the way >>>>>> we build now with the module system may not be quite correct in this >>>>>> regard - but that is just supposition on my part. Because >>>>>> compile-time >>>>>> constants are stored directly into class files that use them, we >>>>>> have to >>>>>> generate UnixConstants.java before compiling any class that needs >>>>>> to use >>>>>> it, then we must compile all classes that do use it. Those >>>>>> classes must >>>>>> only be executed in conjunction with a tool executing on the target >>>>>> platform (javac, jmod etc). My suspicion is that we may be >>>>>> executing a >>>>>> tool on the build platform using the newly compiled classes for the >>>>>> target platform - and that would be wrong. >>>>>> >>>>> >>>>> Yes. Some variables in UnixConstants.java is defined according to the >>>>> target (fcntl.h of mips in this case), but would be executed on host >>>>> (x86 in this case) during "make images". These variables of ppc64le, >>>>> aarch64 and s390x are the same as x86, but the ones of mips are not. >>>>> However, mips is not an official supported target and I did not find >>>>> other targets have similar issue, I am not sure if this is a bug >>>>> or if >>>>> this is the right mailing list :) >>>> >>>> This is the right mailing list to discuss. :) >>>> >>>> So I went back to find when this happened in the past and I >>>> mis-remembered how we solved it. We previously had a problem with >>>> the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 >>>> platforms defined a different value for the O_NOFOLLOW and O_DIRECT >>>> flags. The solution then was to commit a platform specific version >>>> of UnixConstants.java and change the build system to only use the >>>> template file if there was not a pre-existing .java file. But that >>>> platform and the SE Embedded support was all removed. >>>> (SocketOptions.java had a similar problem.) Further that build >>>> logic is completely different to what we had back then (JDK 6/7). >>>> >>>> This is definitely a bug in our build logic IMHO as we specifically >>>> use the build platform c-pre-processor to process the template file >>>> based on the target header files, but then use the resulting class >>>> when running tools on the build platform. >>> I agree with David. This is a bug in the build system; arguably even >>> a regression. >>> >>>> This was not something that happened in 6/7 or even 8 and I think >>>> the module system tools are where the issue now lies. >>>> >>>> I think Erik and/or Magnus will have to give advice on how this may >>>> be properly fixed. I can't see any simple solution. >>> Unfortunately, I also agree that there is no simple solution. :-( >>> >>> The proper way to handle this is to generate two versions of >>> UnixConstants and friends, one for the build platform, and one for >>> the target platform. But as far as I know, there is no simple way to >>> handle such complications in our current structure. Erik knows more >>> about this, he was the one who designed the current solution for >>> handling cross-compilation in the modularized world. >>> >>> However, I can at least help you with a relatively simple >>> workaround. First some background: When we cross-compile, we need >>> not only a Boot JDK (of version current N-1) running on the build >>> host platform, but we also need a Build JDK, based on the current >>> source code, running on the build host. (This is for running >>> jmod/jlink; it needs to be up to date). If we have no Build JDK >>> present, we start by creating one ourselves. This is more or less >>> the same output as running a normal, non-cross compiled, build on >>> the build host. (But Erik found some ways to cut a few corners to >>> save time.) Your problem is that the Build JDK is broken, since >>> UnixConstants has the wrong values. >>> - >>> But you can supply your own working Build JDK to configure! >>> >>> So, your workflow for cross-compiling to MIPS should be: >>> 1) create a Build JDK, e.g. like this: "bash configure >>> --with-conf-name=buildjdk && make jdk CONF=buildjdk" >>> 2) create your cross-compilation JDK like this: "bash configure >>> --openjdk-target=mipsel-unknown-linux-gnu >>> --with-build-jdk=build/buildjdk/jdk" >>> ... or something like that. >>> Then you can build your cross-compiled jdk with "make images >>> CONF=mips". >> >> I will try that, thanks a lot for your teaching! > Please let me know if it works. I wrote the command lines out of my > head, so they might need some tweaking to get right. > > Perhaps this is an acceptable solution to you? Unless Erik can suggest > ways to fix this properly that is not too complicated, maybe this can > be a good enough solution for you? (But if there is a simple solution, > I'd rather have it fixed properly.) > > /Magnus >> >> Regards, >> >> Leslie Zhai >> >> >>> >>> >>> In theory, you should rebuild your buildjdk for each and every >>> change ("make jdk CONF=buildjdk && make images CONF=mips"); but in >>> reality, I don't believe there is really any need to rebuild the >>> buildjdk (unless major changes in jlink/jmod happens). >>> >>> /Magnus >>>> >>>> David >>>> ----- >>>> >>>>> ? For example: >>>>> >>>>> jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND >>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> -- >>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> -- >>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> -- >>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> -- >>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> -- >>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 0x0008 >>>>> -- >>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> >>>>> log.mips:2of path: >>>>> /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>>>> >>>>> oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 >>>>> log.ppc:2of path: >>>>> /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>>>> >>>>> oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 >>>>> >>>>> Cheers, >>>>> Ao Qi >>>>> >>> >> > From erik.joelsson at oracle.com Thu Jan 24 17:25:58 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Jan 2019 09:25:58 -0800 Subject: RFR: JDK-8217730 Split up MakeBase.gmk In-Reply-To: <73f66605-e99f-52e0-87bc-0961b2d0155f@oracle.com> References: <73f66605-e99f-52e0-87bc-0961b2d0155f@oracle.com> Message-ID: Looks good. /Erik On 2019-01-24 06:24, Magnus Ihse Bursie wrote: > The file MakeBase.gmk, which is included by virtually all other make > files in the build system, has become gradually larger and larger. It > is now one of the longest files in the build system, with little to no > internal structure. > > I propose to split it in four parts: > > * Utils.gmk -- here all the simple make functions go; stuff that > basically do not interact with the rest of the world, but just > provides "high-level" macros to make. > > * CopyFiles.gmk -- here the SetupCopyFiles function goes, similar to > how we treat all other SetupFoo functions. > > * MakeIO.gmk -- here reading and writing to files from make goes. This > is mostly due to the long expression of ListPathsSafely on GNU Make > prior to 4.0. > > *MakeBase.gmk -- functions now remaining here belong to either of > these groups: > ?-- it is some kind of core functionality provided by the build > system, like ExecuteWithLog or NamedParamsMacroTemplate. > ?-- it interacts (messily) with the environment > ?-- it does something else that is tricky, or just "misc" > > It is of course possible to break down the remaining MakeBase.gmk even > further, but it's so much more manageable now, and there are no clear > ways of splitting it further without getting into very small pieces > (like logging), so I think I'll stop here, for now. > > To retain backwards compatibility with files that include MakeBase.gmk > and expect all functionality, MakeBase.gmk includes the new files. > It's a future question if we should keep it that way, or put the > requirement of those includes on the files needing the functionality. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217730 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8217730-split-up-MakeBase/webrev.01 > > /Magnus From martinrb at google.com Thu Jan 24 17:25:28 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Jan 2019 09:25:28 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: On Thu, Jan 24, 2019 at 7:46 AM Magnus Ihse Bursie wrote: > So, we already tacitly assume a specific linker with the gcc toolchain; we have just not made that check explicitly. gcc runs on almost every system, but it's harder to replace the compiler than the linker, so gcc ends up being used with many other OS default linkers. Same for clang. Meanwhile, we have 3 competing open source linkers: bfd gold lld, so linker availability is especially fluid these days. Incremental linking will only be of interest to openjdk developers (and then probably only hotspot developers) for non-release builds, so should be opt-in. From erik.joelsson at oracle.com Thu Jan 24 17:27:53 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Jan 2019 09:27:53 -0800 Subject: RFR: JDK-8217733 Minor RunTest fixes In-Reply-To: References: Message-ID: Looks good. /Erik On 2019-01-24 06:46, Magnus Ihse Bursie wrote: > This patch covers some different minor cleanups that I accumulated > after working on RunTest: > ?* Do not override JDK_IMAGE_DIR for jcov testing; instead introduce > JDK_UNDER_TEST (to be really explicit about which JDK we're testing). > ?* Remove unconditional $(info) printout on Windows > ?* Group JCov variable setup with other variable setups. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217733 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8217733-minor-RunTest-fixes/webrev.01 > > /Magnus From alexandre.iline at oracle.com Thu Jan 24 17:34:59 2019 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 24 Jan 2019 09:34:59 -0800 Subject: RFR: JDK-8217733 Minor RunTest fixes In-Reply-To: References: Message-ID: <9E352995-093C-4E79-B21D-0243A6EB712A@oracle.com> Looks good. Shura > On Jan 24, 2019, at 6:46 AM, Magnus Ihse Bursie wrote: > > This patch covers some different minor cleanups that I accumulated after working on RunTest: > * Do not override JDK_IMAGE_DIR for jcov testing; instead introduce JDK_UNDER_TEST (to be really explicit about which JDK we're testing). > * Remove unconditional $(info) printout on Windows > * Group JCov variable setup with other variable setups. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217733 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8217733-minor-RunTest-fixes/webrev.01 > > /Magnus From erik.joelsson at oracle.com Thu Jan 24 17:43:39 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Jan 2019 09:43:39 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: On 2019-01-24 06:04, Magnus Ihse Bursie wrote: > On 2019-01-24 14:45, Florian Weimer wrote: >> * Magnus Ihse Bursie: >> >>> The default binutils linker used by gcc, the bfd linker, is slow. The >>> new replacement, gold, has been distributed alongside gcc for several >>> years now, and is a well mature, and much faster, replacement. >> The gold linker is an optional component of binutils, not available in >> all builds.? For example, binutils in Red Hat Enterprise Linux 7.6 does >> not include gold on the ppc64le architecture. >> >> The gold linker also supports a different set of features compared to >> BFD ld, which may or may not be what you want.? But I think OpenJDK does >> not use many tricky ELF features, so the differences probably do not >> matter. >> >> Is it possible to add -fuse-ld=gold to LDFLAGS externally, outside the >> build system, so that the build system can use the gold linker if people >> prefer it over BFD ld? >> >> Or you could configure your binutils with --enable-gold=default, so that >> it defaults to ld.gold, again not requiring any OpenJDK changes. > One of the driving forces behind this bug is the speed increase in > gold by itself. You are correct that to achieve this, a solution > outside the build system can be used. > > However, the other driving force is the ability to enable incremental > linking. The build system must know if we use gold, so that it knows > that those command line options are available. So to resort to the > solution of changing the environment would not enable that second part. > > But I'm leaning more towards just enabling gold on x86_64 -- for other > platforms, we might as well keep the good ol' bfd linker. Does that > sound like a good solution to you? > I have been looking at this before (probably a couple of years ago now) and my take then was that this should be handled with a configure flag and be opt in (that jib would set for us). The default really should be to accept what the toolchain/admin/distribution has as default. If --enable-gold is given, configure needs to check for gold availability. I had to explicitly enable it in the devkit builds, so it's definitely not always present. We could also just make sure our internal devkit uses gold by default, and leave explicit setting of this to simply adding a linker arg with configure. By using an explicit configure argument to enable it, configure knows about it and we can enable incremental linking using that information. Incremental linking must be opt in though. We could also skip the --enable-gold flag and just do the checks if --enable-incremental-linking is set. Last I experimented with it, incremental did not have a positive effect on the time to link hotspot, but gold did. /Magnus > >> >> Thanks, >> Florian > From magnus.ihse.bursie at oracle.com Thu Jan 24 18:30:19 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Jan 2019 19:30:19 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: <3122ef7d-57f8-b5b9-d9aa-f15cbb438fde@oracle.com> On 2019-01-24 18:43, Erik Joelsson wrote: > > On 2019-01-24 06:04, Magnus Ihse Bursie wrote: >> On 2019-01-24 14:45, Florian Weimer wrote: >>> * Magnus Ihse Bursie: >>> >>>> The default binutils linker used by gcc, the bfd linker, is slow. The >>>> new replacement, gold, has been distributed alongside gcc for several >>>> years now, and is a well mature, and much faster, replacement. >>> The gold linker is an optional component of binutils, not available in >>> all builds.? For example, binutils in Red Hat Enterprise Linux 7.6 does >>> not include gold on the ppc64le architecture. >>> >>> The gold linker also supports a different set of features compared to >>> BFD ld, which may or may not be what you want.? But I think OpenJDK >>> does >>> not use many tricky ELF features, so the differences probably do not >>> matter. >>> >>> Is it possible to add -fuse-ld=gold to LDFLAGS externally, outside the >>> build system, so that the build system can use the gold linker if >>> people >>> prefer it over BFD ld? >>> >>> Or you could configure your binutils with --enable-gold=default, so >>> that >>> it defaults to ld.gold, again not requiring any OpenJDK changes. >> One of the driving forces behind this bug is the speed increase in >> gold by itself. You are correct that to achieve this, a solution >> outside the build system can be used. >> >> However, the other driving force is the ability to enable incremental >> linking. The build system must know if we use gold, so that it knows >> that those command line options are available. So to resort to the >> solution of changing the environment would not enable that second part. >> >> But I'm leaning more towards just enabling gold on x86_64 -- for >> other platforms, we might as well keep the good ol' bfd linker. Does >> that sound like a good solution to you? >> > I have been looking at this before (probably a couple of years ago > now) and my take then was that this should be handled with a configure > flag and be opt in (that jib would set for us). The default really > should be to accept what the toolchain/admin/distribution has as > default. If --enable-gold is given, configure needs to check for gold > availability. I had to explicitly enable it in the devkit builds, so > it's definitely not always present. > > We could also just make sure our internal devkit uses gold by default, > and leave explicit setting of this to simply adding a linker arg with > configure. > > By using an explicit configure argument to enable it, configure knows > about it and we can enable incremental linking using that information. > Incremental linking must be opt in though. We could also skip the > --enable-gold flag and just do the checks if > --enable-incremental-linking is set. > > Last I experimented with it, incremental did not have a positive > effect on the time to link hotspot, but gold did. Ok. I'll retract my RFR for now, and come back with a way to set this conditionally using configure flags. /Magnus > > /Magnus >> >>> >>> Thanks, >>> Florian >> From aph at redhat.com Thu Jan 24 18:44:10 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 24 Jan 2019 18:44:10 +0000 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> Message-ID: On 1/24/19 1:25 PM, Aleksey Shipilev wrote: > That'd be nice. Maybe we should check for the presence of ld.gold, > though, and override LD when it is available? That would also allow > the fallback when ld.gold is misbehaving, but setting LD forcefully. Yes, we absolutely should check. I just built the latest buinutils, and gold is not enabled by default. Apart from anything else, that means gold won't get so much testing. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martinrb at google.com Thu Jan 24 18:49:53 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Jan 2019 10:49:53 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: Here's an experiment using the 3 competing open source linkers to link hotspot. This confirms that lld is faster than gold is faster than bfd, but is the one second saving worth the engineering effort? $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile -Wl,-soname=libjvm.so -o $BUILDDIR/support/modules_libs/java.base/server/libjvm.so @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt -lm -ldl -lpthread; done) --- bfd --- /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-O1 -m6 1.31s user 0.36s system 99% cpu 1.669 total --- gold --- /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-O1 -m6 0.42s user 0.11s system 99% cpu 0.537 total --- lld --- /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-O1 -m6 0.25s user 0.20s system 145% cpu 0.310 total From erik.joelsson at oracle.com Thu Jan 24 19:06:40 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Jan 2019 11:06:40 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: <3bd96810-573e-7613-2328-ed1916930411@oracle.com> Are you actually linking libjvm.so in 1.3 seconds? A normal link time for me using bfd is about 23 seconds while gold takes it to 14.2(+-0.2). This is in line with what hotspot developers I have talked to also see (and they have similar hardware). My workstation has a few years on it, but surely machines haven't gotten 17 times faster? There must be something else at play here. /Erik On 2019-01-24 10:49, Martin Buchholz wrote: > Here's an experiment using the 3 competing open source linkers to link > hotspot. This confirms that lld is faster than gold is faster than > bfd, but is the one second saving worth the engineering effort? > > $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for > linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++ > -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack > -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared > -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile > -Wl,-soname=libjvm.so -o > $BUILDDIR/support/modules_libs/java.base/server/libjvm.so > @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt > -lm -ldl -lpthread; done) > --- bfd --- > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > -Wl,-O1 -m6 1.31s user 0.36s system 99% cpu 1.669 total > --- gold --- > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > -Wl,-O1 -m6 0.42s user 0.11s system 99% cpu 0.537 total > --- lld --- > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > -Wl,-O1 -m6 0.25s user 0.20s system 145% cpu 0.310 total From martinrb at google.com Thu Jan 24 21:18:40 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Jan 2019 13:18:40 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <3bd96810-573e-7613-2328-ed1916930411@oracle.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <3bd96810-573e-7613-2328-ed1916930411@oracle.com> Message-ID: I just copied the command out of hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_link.cmdline and lightly edited it. On my old underpowered NUC at home I see slightly worse numbers (but warmed up, files on SSD - are you I/O bound?). (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for ld in bfd gold; do time /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile -Wl,-soname=libjvm.so -o $BUILDDIR/support/modules_libs/java.base/server/libjvm.so @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt -lm -ldl -lpthread; done) /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstac 2.28s user 0.33s system 99% cpu 2.621 total /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstac 0.65s user 0.09s system 98% cpu 0.747 total On Thu, Jan 24, 2019 at 11:06 AM Erik Joelsson wrote: > > Are you actually linking libjvm.so in 1.3 seconds? A normal link time > for me using bfd is about 23 seconds while gold takes it to 14.2(+-0.2). > This is in line with what hotspot developers I have talked to also see > (and they have similar hardware). > > My workstation has a few years on it, but surely machines haven't gotten > 17 times faster? There must be something else at play here. > > /Erik > > On 2019-01-24 10:49, Martin Buchholz wrote: > > Here's an experiment using the 3 competing open source linkers to link > > hotspot. This confirms that lld is faster than gold is faster than > > bfd, but is the one second saving worth the engineering effort? > > > > $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for > > linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++ > > -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack > > -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared > > -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile > > -Wl,-soname=libjvm.so -o > > $BUILDDIR/support/modules_libs/java.base/server/libjvm.so > > @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt > > -lm -ldl -lpthread; done) > > --- bfd --- > > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > > -Wl,-O1 -m6 1.31s user 0.36s system 99% cpu 1.669 total > > --- gold --- > > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > > -Wl,-O1 -m6 0.42s user 0.11s system 99% cpu 0.537 total > > --- lld --- > > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > > -Wl,-O1 -m6 0.25s user 0.20s system 145% cpu 0.310 total From fweimer at redhat.com Thu Jan 24 22:17:37 2019 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 24 Jan 2019 23:17:37 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: (Martin Buchholz's message of "Thu, 24 Jan 2019 10:49:53 -0800") References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: <87r2d14s5a.fsf@oldenburg2.str.redhat.com> * Martin Buchholz: > Here's an experiment using the 3 competing open source linkers to link > hotspot. This confirms that lld is faster than gold is faster than > bfd, but is the one second saving worth the engineering effort? > > $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for > linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++ > -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack > -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared > -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile > -Wl,-soname=libjvm.so -o > $BUILDDIR/support/modules_libs/java.base/server/libjvm.so > @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt > -lm -ldl -lpthread; done) > --- bfd --- > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > -Wl,-O1 -m6 1.31s user 0.36s system 99% cpu 1.669 total > --- gold --- > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > -Wl,-O1 -m6 0.42s user 0.11s system 99% cpu 0.537 total > --- lld --- > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > -Wl,-O1 -m6 0.25s user 0.20s system 145% cpu 0.310 total Do the constituent object files have debugging information? Sub-second processing times for ~350 MiB of output are rather impressive. On a Sandybridge-era Xeon (probably without SSD storage), I see a change from 13 seconds to 8 seconds (BFD to gold). This is the first libjvm.so link from ?make images?, and the output includes (apparently full) debugging information. Thanks, Florian From erik.joelsson at oracle.com Thu Jan 24 22:22:39 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Jan 2019 14:22:39 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <3bd96810-573e-7613-2328-ed1916930411@oracle.com> Message-ID: Hello, On 2019-01-24 13:18, Martin Buchholz wrote: > I just copied the command out of > hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_link.cmdline > and lightly edited it. I took the .cmdline verbatim and then just added -fuse-ld=gold, so should be the same. I'm running on Ubuntu 18.04 using a devkit produced by the makefiles in make/devkit. I'm running SSDs and AFAIK they are working as they should. When running the command using /usr/bin/time, I get 99% cpu. If I instead try the native toolchain on the system, the times are better, but still miles from yours: With devkit, default linker: 23s With devkit, gold: 14.2s Native compiler, default linker: 12.5s Native compiler, gold: 8.1s The machine has 2 cpus identifying as "Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz". These are certainly not known for single threaded performance, but I'm surprised by this difference. Given our reality, I think you can understand why this change matters. Cutting off nearly 10s from incremental rebuilds is significant for developers when in an edit-build-test loop. /Erik > On my old underpowered NUC at home I see slightly worse numbers (but > warmed up, files on SSD - are you I/O bound?). > > (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for ld in > bfd gold; do time /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both > -Wl,-z,defs -Wl,-z,noexecstack -Wl,-O1 -Wl,-z,relro -m64 > -static-libstdc++ -static-libgcc -shared -m64 > -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile > -Wl,-soname=libjvm.so -o > $BUILDDIR/support/modules_libs/java.base/server/libjvm.so > @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt > -lm -ldl -lpthread; done) > /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs > -Wl,-z,noexecstac 2.28s user 0.33s system 99% cpu 2.621 total > /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs > -Wl,-z,noexecstac 0.65s user 0.09s system 98% cpu 0.747 total > > On Thu, Jan 24, 2019 at 11:06 AM Erik Joelsson wrote: >> Are you actually linking libjvm.so in 1.3 seconds? A normal link time >> for me using bfd is about 23 seconds while gold takes it to 14.2(+-0.2). >> This is in line with what hotspot developers I have talked to also see >> (and they have similar hardware). >> >> My workstation has a few years on it, but surely machines haven't gotten >> 17 times faster? There must be something else at play here. >> >> /Erik >> >> On 2019-01-24 10:49, Martin Buchholz wrote: >>> Here's an experiment using the 3 competing open source linkers to link >>> hotspot. This confirms that lld is faster than gold is faster than >>> bfd, but is the one second saving worth the engineering effort? >>> >>> $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for >>> linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++ >>> -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack >>> -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared >>> -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile >>> -Wl,-soname=libjvm.so -o >>> $BUILDDIR/support/modules_libs/java.base/server/libjvm.so >>> @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt >>> -lm -ldl -lpthread; done) >>> --- bfd --- >>> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs >>> -Wl,-O1 -m6 1.31s user 0.36s system 99% cpu 1.669 total >>> --- gold --- >>> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs >>> -Wl,-O1 -m6 0.42s user 0.11s system 99% cpu 0.537 total >>> --- lld --- >>> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs >>> -Wl,-O1 -m6 0.25s user 0.20s system 145% cpu 0.310 total From erik.joelsson at oracle.com Thu Jan 24 22:28:50 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Jan 2019 14:28:50 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <87r2d14s5a.fsf@oldenburg2.str.redhat.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <87r2d14s5a.fsf@oldenburg2.str.redhat.com> Message-ID: On 2019-01-24 14:17, Florian Weimer wrote: > * Martin Buchholz: > >> Here's an experiment using the 3 competing open source linkers to link >> hotspot. This confirms that lld is faster than gold is faster than >> bfd, but is the one second saving worth the engineering effort? >> >> $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for >> linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++ >> -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack >> -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared >> -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile >> -Wl,-soname=libjvm.so -o >> $BUILDDIR/support/modules_libs/java.base/server/libjvm.so >> @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt >> -lm -ldl -lpthread; done) >> --- bfd --- >> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs >> -Wl,-O1 -m6 1.31s user 0.36s system 99% cpu 1.669 total >> --- gold --- >> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs >> -Wl,-O1 -m6 0.42s user 0.11s system 99% cpu 0.537 total >> --- lld --- >> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs >> -Wl,-O1 -m6 0.25s user 0.20s system 145% cpu 0.310 total > Do the constituent object files have debugging information? Sub-second > processing times for ~350 MiB of output are rather impressive. Ah! That must be it. I just tried with --with-native-debug-symbols=none and then I get comparable link times. /Erik > On a Sandybridge-era Xeon (probably without SSD storage), I see a change > from 13 seconds to 8 seconds (BFD to gold). This is the first libjvm.so > link from ?make images?, and the output includes (apparently full) > debugging information. > > Thanks, > Florian From linuxtardis at gmail.com Thu Jan 24 23:17:38 2019 From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=) Date: Fri, 25 Jan 2019 00:17:38 +0100 Subject: RFR(M)(round 2): 8215902: Add support for SoftFloat-3e library In-Reply-To: <3f62f15e-ac5f-94d4-9744-c9cef796a3fa@oracle.com> References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> <3f62f15e-ac5f-94d4-9744-c9cef796a3fa@oracle.com> Message-ID: <12e1cb109842f145edf23b4ea5ef591395188de9.camel@gmail.com> Hi Magnus, thanks for the review! I haven't received a review for the hotspot source changes yet, so I will have to wait. Regards, Jakub On 2019-01-23 at 13:55 +0100, Magnus Ihse Bursie wrote: > Hi Jakub, > > On 2019-01-15 17:31, Jakub Van?k wrote: > > Hi Magnus and Erik, > > > > I have added the link to the repository to README and I have > > removed > > the link to the mailing list thread. I have also recreated the > > GitHub > > repository. Now it is a fork of the mentioned repository with two > > extra > > commits containing README and the build scripts. > > > > New webrev URL: > > http://cr.openjdk.java.net/~jakvanek/8215902/webrev.04/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 > > Sorry for the late reply. > > This looks very good! Thank you for fixing this, including rebasing > the > github repo. > > I'm not sure if you've gotten reviews from the hotspot team for the > hotspot source changes, but from a build perspective, this is good to > go. > > /Magnus > > > > Regards, > > > > Jakub > > > > On 2019-01-15 at 15:05 +0100, Magnus Ihse Bursie wrote: > > > On 2018-12-25 16:19, Jakub Van?k wrote: > > > > Hi, > > > > > > > > please review this webrev. It is a successor of the softfloat-3 > > > > [patch] > > > > thread (first email > > > > > > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html > > > > ) > > > > > > > > Changes since the last patch (v6): > > > > > > > > - renamed --with-softloat* to --with-sflt* (it is more compact > > > > and > > > > it > > > > corresponds to the old --with-sflt-lib=... option) > > > > > > > > - license is now obtained via --with-sflt-license switch (so it > > > > is > > > > not > > > > included in OpenJDK source tree) > > > > > > > > - updated documentation (slight rewording, added the license > > > > option) > > > > > > > > - checks for default --with/--without behavior are in place > > > > again > > > > (I forgot them when I changed the way the library is > > > > detected) > > > > > > > > - added a simple testcase - I found a disrepancy between > > > > softfloat > > > > and > > > > system function behavior. When a float with bits 0x003FFFFF > > > > is > > > > added to 0x00000001, the correct result is 0x00400000, but > > > > the > > > > default software floating point implementation returns > > > > 0x00000000. > > > > However I'm not sure where to put this test - now it is in > > > > test/hotspot/jtreg/compiler/floatingpoint. > > > > > > > > - comments in code refer to CR 6757269 and newly JDK-8215902 > > > > too. > > > > > > > > I have created a repository with SoftFloat-3e with build > > > > configuration > > > > specifically for OpenJDK on armel: > > > > https://github.com/ev3dev-lang-java/softfloat-openjdk > > > > > > > > I can add a link to it to the documentation. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 > > > > Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ > > > > > > Hi Jakub, > > > > > > In general this looks good. > > > > > > Some comments: > > > > > > I agree with Erik that you can add a link to your github project; > > > compiling SoftFloat is outside the scope of the OpenJDK build > > > instructions, but it can sure be helpful to lower the bar for > > > users > > > wanting to do that. Just one question: any particular reason you > > > didn't > > > create your github repo by forking the official > > > https://github.com/ucb-bar/berkeley-softfloat-3? That way, it > > > would > > > have > > > been easy for users to see that you were not adding any malicious > > > or > > > suspicious code to the original SoftFloat distribution. > > > > > > On the other hand, I think the link to > > > > > > > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > > > > > is unnecessary and just creates clutter in the documentation. > > > Please > > > remove it. > > > > > > /Magnus > > > > CI build: > > > > https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ > > > > > > > > Cheers, > > > > > > > > Jakub > > > > > > From martinrb at google.com Thu Jan 24 23:35:58 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Jan 2019 15:35:58 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <87r2d14s5a.fsf@oldenburg2.str.redhat.com> Message-ID: On Thu, Jan 24, 2019 at 2:28 PM Erik Joelsson wrote: > > Do the constituent object files have debugging information? Sub-second > > processing times for ~350 MiB of output are rather impressive. > > Ah! That must be it. I just tried with --with-native-debug-symbols=none > and then I get comparable link times. Yup! Native debug symbols - more trouble than they're worth. From zhaixiang at loongson.cn Fri Jan 25 01:47:12 2019 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Fri, 25 Jan 2019 09:47:12 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> Message-ID: Hi Magnus, Failed to make images: $ make images CONF=mips Building target 'images' in configuration 'linux-mips64el-normal-server-fastdebug' GenerateLinkOptData.gmk:61: recipe for target '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' failed make[3]: *** [/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist] Error 1 make[3]: *** Deleting file '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' make/Main.gmk:441: recipe for target 'generate-link-opt-data' failed make[2]: *** [generate-link-opt-data] Error 2 ERROR: Build failed for target 'images' in configuration 'linux-mips64el-normal-server-fastdebug' (exit code 2) === Make failed targets repeated here === GenerateLinkOptData.gmk:61: recipe for target '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' failed make/Main.gmk:441: recipe for target 'generate-link-opt-data' failed === End of repeated output === Hint: Try searching the build log for the name of the first failed target. Hint: See doc/building.html#troubleshooting for assistance. /home/loongson/zhaixiang/jdk12-mips/make/Init.gmk:300: recipe for target 'main' failed make[1]: *** [main] Error 2 /home/loongson/zhaixiang/jdk12-mips/make/Init.gmk:186: recipe for target 'images' failed make: *** [images] Error 2 ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- My cross-compile configure option: CC=mips64el-linux-gnuabi64-gcc CXX=mips64el-linux-gnuabi64-g++ sh ./configure \ ? --openjdk-target=mips64el-linux-gnuabi64 \ ? --with-sysroot=/chroots/mips64el_stretch \ ? --with-toolchain-path=/chroots/mips64el_stretch \ ? --with-boot-jdk=/home/loongson/aoqi/jdk-11.0.1 \ ? --disable-warnings-as-errors \ --with-freetype-lib=/chroots/mips64el_stretch/usr/lib/mips64el-linux-gnuabi64 \ --with-freetype-include=/chroots/mips64el_stretch/usr/include/freetype2 \ ? --with-debug-level=fastdebug \ ? --with-build-jdk=build/buildjdk/jdk ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- buildjdk is OK: $ sh configure --with-conf-name=buildjdk --with-boot-jdk=/home/loongson/aoqi/jdk-11.0.1 --disable-warnings-as-errors $ make jdk CONF=buildjdk Building target 'jdk' in configuration 'buildjdk' Finished building target 'jdk' in configuration 'buildjdk' Regards, Leslie Zhai ? 2019/1/24 ??9:30, Magnus Ihse Bursie ??: > On 2019-01-24 13:22, Leslie Zhai wrote: >> Hi Magnus, >> >> Thanks for your kind response! >> >> ? 2019/1/24 ??8:05, Magnus Ihse Bursie ??: >>> >>> >>> On 2019-01-24 05:45, David Holmes wrote: >>>> On 24/01/2019 1:51 pm, Ao Qi wrote: >>>>> Hi David, >>>>> >>>>> On Thu, Jan 24, 2019 at 10:47 AM David Holmes >>>>> wrote: >>>>>> >>>>>> Hi Leslie, >>>>>> >>>>>> I'm not Erik :) however .... >>>>>> >>>>>> On 24/01/2019 12:28 pm, Leslie Zhai wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> Because the flags' macro of MIPS is different from other >>>>>>> targets[1], it >>>>>>> will effect the `UnixConstants` of >>>>>>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, >>>>>>> for >>>>>>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is >>>>>>> different >>>>>>> from other targets.? Then failed[2] to cross compiling jdk12 for >>>>>>> mips64el-linux-gnu target by following the document[3]. >>>>>> >>>>>> It's been quite a while since we built for a platform where the >>>>>> flags >>>>>> had different values, but it is supposed to work. I suspect that >>>>>> the way >>>>>> we build now with the module system may not be quite correct in this >>>>>> regard - but that is just supposition on my part. Because >>>>>> compile-time >>>>>> constants are stored directly into class files that use them, we >>>>>> have to >>>>>> generate UnixConstants.java before compiling any class that needs >>>>>> to use >>>>>> it, then we must compile all classes that do use it. Those >>>>>> classes must >>>>>> only be executed in conjunction with a tool executing on the target >>>>>> platform (javac, jmod etc). My suspicion is that we may be >>>>>> executing a >>>>>> tool on the build platform using the newly compiled classes for the >>>>>> target platform - and that would be wrong. >>>>>> >>>>> >>>>> Yes. Some variables in UnixConstants.java is defined according to the >>>>> target (fcntl.h of mips in this case), but would be executed on host >>>>> (x86 in this case) during "make images". These variables of ppc64le, >>>>> aarch64 and s390x are the same as x86, but the ones of mips are not. >>>>> However, mips is not an official supported target and I did not find >>>>> other targets have similar issue, I am not sure if this is a bug >>>>> or if >>>>> this is the right mailing list :) >>>> >>>> This is the right mailing list to discuss. :) >>>> >>>> So I went back to find when this happened in the past and I >>>> mis-remembered how we solved it. We previously had a problem with >>>> the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 >>>> platforms defined a different value for the O_NOFOLLOW and O_DIRECT >>>> flags. The solution then was to commit a platform specific version >>>> of UnixConstants.java and change the build system to only use the >>>> template file if there was not a pre-existing .java file. But that >>>> platform and the SE Embedded support was all removed. >>>> (SocketOptions.java had a similar problem.) Further that build >>>> logic is completely different to what we had back then (JDK 6/7). >>>> >>>> This is definitely a bug in our build logic IMHO as we specifically >>>> use the build platform c-pre-processor to process the template file >>>> based on the target header files, but then use the resulting class >>>> when running tools on the build platform. >>> I agree with David. This is a bug in the build system; arguably even >>> a regression. >>> >>>> This was not something that happened in 6/7 or even 8 and I think >>>> the module system tools are where the issue now lies. >>>> >>>> I think Erik and/or Magnus will have to give advice on how this may >>>> be properly fixed. I can't see any simple solution. >>> Unfortunately, I also agree that there is no simple solution. :-( >>> >>> The proper way to handle this is to generate two versions of >>> UnixConstants and friends, one for the build platform, and one for >>> the target platform. But as far as I know, there is no simple way to >>> handle such complications in our current structure. Erik knows more >>> about this, he was the one who designed the current solution for >>> handling cross-compilation in the modularized world. >>> >>> However, I can at least help you with a relatively simple >>> workaround. First some background: When we cross-compile, we need >>> not only a Boot JDK (of version current N-1) running on the build >>> host platform, but we also need a Build JDK, based on the current >>> source code, running on the build host. (This is for running >>> jmod/jlink; it needs to be up to date). If we have no Build JDK >>> present, we start by creating one ourselves. This is more or less >>> the same output as running a normal, non-cross compiled, build on >>> the build host. (But Erik found some ways to cut a few corners to >>> save time.) Your problem is that the Build JDK is broken, since >>> UnixConstants has the wrong values. >>> - >>> But you can supply your own working Build JDK to configure! >>> >>> So, your workflow for cross-compiling to MIPS should be: >>> 1) create a Build JDK, e.g. like this: "bash configure >>> --with-conf-name=buildjdk && make jdk CONF=buildjdk" >>> 2) create your cross-compilation JDK like this: "bash configure >>> --openjdk-target=mipsel-unknown-linux-gnu >>> --with-build-jdk=build/buildjdk/jdk" >>> ... or something like that. >>> Then you can build your cross-compiled jdk with "make images >>> CONF=mips". >> >> I will try that, thanks a lot for your teaching! > Please let me know if it works. I wrote the command lines out of my > head, so they might need some tweaking to get right. > > Perhaps this is an acceptable solution to you? Unless Erik can suggest > ways to fix this properly that is not too complicated, maybe this can > be a good enough solution for you? (But if there is a simple solution, > I'd rather have it fixed properly.) > > /Magnus >> >> Regards, >> >> Leslie Zhai >> >> >>> >>> >>> In theory, you should rebuild your buildjdk for each and every >>> change ("make jdk CONF=buildjdk && make images CONF=mips"); but in >>> reality, I don't believe there is really any need to rebuild the >>> buildjdk (unless major changes in jlink/jmod happens). >>> >>> /Magnus >>>> >>>> David >>>> ----- >>>> >>>>> ? For example: >>>>> >>>>> jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND >>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> -- >>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> -- >>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> -- >>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> -- >>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> -- >>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 0x0008 >>>>> -- >>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>> >>>>> ??? static final int O_APPEND = >>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>> >>>>> ????????????????????????????????????? 02000 >>>>> >>>>> log.mips:2of path: >>>>> /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>>>> >>>>> oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 >>>>> log.ppc:2of path: >>>>> /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>>>> >>>>> oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 >>>>> >>>>> Cheers, >>>>> Ao Qi >>>>> >>> >> > From zhaixiang at loongson.cn Fri Jan 25 01:50:27 2019 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Fri, 25 Jan 2019 09:50:27 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> Message-ID: <0b6e8369-b0c7-64b5-543e-30f7a19e1bf2@loongson.cn> Hi Erik, Thanks for your kind response! ? 2019/1/25 ??1:19, Erik Joelsson ??: > Hello, > > I agree with the conclusion here, there is certainly a bug in the > build logic. When creating the "Build JDK" during a cross compilation > build, we are, as Magnus said, cutting a few corners for efficiency. > One of those corners is assuming all the java classes are the same and > can simply be reused. It has been shown here that that assumption is > not always correct. > > I think the most reasonable solution is to assume all of java.base > needs to be built specifically for the "Build JDK". I think this can > be reasonably easy to implement (compared to the existing Build JDK > logic, which is arguably rather hairy). > > Magnus' suggested workaround should work fine for now however. Failed to make images https://mail.openjdk.java.net/pipermail/build-dev/2019-January/024765.html But please point out my fault, thanks a lot! > > > Filed https://bugs.openjdk.java.net/browse/JDK-8217739 Thanks for your bug report! Regards, Leslie Zhai > > > /Erik > > On 2019-01-24 05:30, Magnus Ihse Bursie wrote: >> On 2019-01-24 13:22, Leslie Zhai wrote: >>> Hi Magnus, >>> >>> Thanks for your kind response! >>> >>> ? 2019/1/24 ??8:05, Magnus Ihse Bursie ??: >>>> >>>> >>>> On 2019-01-24 05:45, David Holmes wrote: >>>>> On 24/01/2019 1:51 pm, Ao Qi wrote: >>>>>> Hi David, >>>>>> >>>>>> On Thu, Jan 24, 2019 at 10:47 AM David Holmes >>>>>> wrote: >>>>>>> >>>>>>> Hi Leslie, >>>>>>> >>>>>>> I'm not Erik :) however .... >>>>>>> >>>>>>> On 24/01/2019 12:28 pm, Leslie Zhai wrote: >>>>>>>> Hi Erik, >>>>>>>> >>>>>>>> Because the flags' macro of MIPS is different from other >>>>>>>> targets[1], it >>>>>>>> will effect the `UnixConstants` of >>>>>>>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, >>>>>>>> for >>>>>>>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is >>>>>>>> different >>>>>>>> from other targets.? Then failed[2] to cross compiling jdk12 for >>>>>>>> mips64el-linux-gnu target by following the document[3]. >>>>>>> >>>>>>> It's been quite a while since we built for a platform where the >>>>>>> flags >>>>>>> had different values, but it is supposed to work. I suspect that >>>>>>> the way >>>>>>> we build now with the module system may not be quite correct in >>>>>>> this >>>>>>> regard - but that is just supposition on my part. Because >>>>>>> compile-time >>>>>>> constants are stored directly into class files that use them, we >>>>>>> have to >>>>>>> generate UnixConstants.java before compiling any class that >>>>>>> needs to use >>>>>>> it, then we must compile all classes that do use it. Those >>>>>>> classes must >>>>>>> only be executed in conjunction with a tool executing on the target >>>>>>> platform (javac, jmod etc). My suspicion is that we may be >>>>>>> executing a >>>>>>> tool on the build platform using the newly compiled classes for the >>>>>>> target platform - and that would be wrong. >>>>>>> >>>>>> >>>>>> Yes. Some variables in UnixConstants.java is defined according to >>>>>> the >>>>>> target (fcntl.h of mips in this case), but would be executed on host >>>>>> (x86 in this case) during "make images". These variables of ppc64le, >>>>>> aarch64 and s390x are the same as x86, but the ones of mips are not. >>>>>> However, mips is not an official supported target and I did not find >>>>>> other targets have similar issue, I am not sure if this is a bug >>>>>> or if >>>>>> this is the right mailing list :) >>>>> >>>>> This is the right mailing list to discuss. :) >>>>> >>>>> So I went back to find when this happened in the past and I >>>>> mis-remembered how we solved it. We previously had a problem with >>>>> the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 >>>>> platforms defined a different value for the O_NOFOLLOW and >>>>> O_DIRECT flags. The solution then was to commit a platform >>>>> specific version of UnixConstants.java and change the build system >>>>> to only use the template file if there was not a pre-existing >>>>> .java file. But that platform and the SE Embedded support was all >>>>> removed. (SocketOptions.java had a similar problem.) Further that >>>>> build logic is completely different to what we had back then (JDK >>>>> 6/7). >>>>> >>>>> This is definitely a bug in our build logic IMHO as we >>>>> specifically use the build platform c-pre-processor to process the >>>>> template file based on the target header files, but then use the >>>>> resulting class when running tools on the build platform. >>>> I agree with David. This is a bug in the build system; arguably >>>> even a regression. >>>> >>>>> This was not something that happened in 6/7 or even 8 and I think >>>>> the module system tools are where the issue now lies. >>>>> >>>>> I think Erik and/or Magnus will have to give advice on how this >>>>> may be properly fixed. I can't see any simple solution. >>>> Unfortunately, I also agree that there is no simple solution. :-( >>>> >>>> The proper way to handle this is to generate two versions of >>>> UnixConstants and friends, one for the build platform, and one for >>>> the target platform. But as far as I know, there is no simple way >>>> to handle such complications in our current structure. Erik knows >>>> more about this, he was the one who designed the current solution >>>> for handling cross-compilation in the modularized world. >>>> >>>> However, I can at least help you with a relatively simple >>>> workaround. First some background: When we cross-compile, we need >>>> not only a Boot JDK (of version current N-1) running on the build >>>> host platform, but we also need a Build JDK, based on the current >>>> source code, running on the build host. (This is for running >>>> jmod/jlink; it needs to be up to date). If we have no Build JDK >>>> present, we start by creating one ourselves. This is more or less >>>> the same output as running a normal, non-cross compiled, build on >>>> the build host. (But Erik found some ways to cut a few corners to >>>> save time.) Your problem is that the Build JDK is broken, since >>>> UnixConstants has the wrong values. >>>> - >>>> But you can supply your own working Build JDK to configure! >>>> >>>> So, your workflow for cross-compiling to MIPS should be: >>>> 1) create a Build JDK, e.g. like this: "bash configure >>>> --with-conf-name=buildjdk && make jdk CONF=buildjdk" >>>> 2) create your cross-compilation JDK like this: "bash configure >>>> --openjdk-target=mipsel-unknown-linux-gnu >>>> --with-build-jdk=build/buildjdk/jdk" >>>> ... or something like that. >>>> Then you can build your cross-compiled jdk with "make images >>>> CONF=mips". >>> >>> I will try that, thanks a lot for your teaching! >> Please let me know if it works. I wrote the command lines out of my >> head, so they might need some tweaking to get right. >> >> Perhaps this is an acceptable solution to you? Unless Erik can >> suggest ways to fix this properly that is not too complicated, maybe >> this can be a good enough solution for you? (But if there is a simple >> solution, I'd rather have it fixed properly.) >> >> /Magnus >>> >>> Regards, >>> >>> Leslie Zhai >>> >>> >>>> >>>> >>>> In theory, you should rebuild your buildjdk for each and every >>>> change ("make jdk CONF=buildjdk && make images CONF=mips"); but in >>>> reality, I don't believe there is really any need to rebuild the >>>> buildjdk (unless major changes in jlink/jmod happens). >>>> >>>> /Magnus >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> ? For example: >>>>>> >>>>>> jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND >>>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> -- >>>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> -- >>>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> -- >>>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> -- >>>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> -- >>>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 0x0008 >>>>>> -- >>>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> >>>>>> log.mips:2of path: >>>>>> /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>>>>> >>>>>> oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 >>>>>> log.ppc:2of path: >>>>>> /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>>>>> >>>>>> oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 >>>>>> >>>>>> Cheers, >>>>>> Ao Qi >>>>>> >>>> >>> >> From david.holmes at oracle.com Fri Jan 25 06:45:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2019 16:45:05 +1000 Subject: RFR(M)(round 2): 8215902: Add support for SoftFloat-3e library In-Reply-To: <12e1cb109842f145edf23b4ea5ef591395188de9.camel@gmail.com> References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> <3f62f15e-ac5f-94d4-9744-c9cef796a3fa@oracle.com> <12e1cb109842f145edf23b4ea5ef591395188de9.camel@gmail.com> Message-ID: Hi Jakub, On 25/01/2019 9:17 am, Jakub Van?k wrote: > Hi Magnus, > > thanks for the review! > > I haven't received a review for the hotspot source changes yet, so I > will have to wait. Not an expert on the details of the FP code but the wrapper layer appears okay to me. One nit with the test is that we don't name tests using bug numbers any more, so please rename the test to something more descriptive ... perhaps FloatPrecisionTest.java ? Also on the test, given this wraps a number of FP functions does the test need to be more elaborate to ensure they have all been covered? Thanks, David ----- > Regards, > > Jakub > > On 2019-01-23 at 13:55 +0100, Magnus Ihse Bursie wrote: >> Hi Jakub, >> >> On 2019-01-15 17:31, Jakub Van?k wrote: >>> Hi Magnus and Erik, >>> >>> I have added the link to the repository to README and I have >>> removed >>> the link to the mailing list thread. I have also recreated the >>> GitHub >>> repository. Now it is a fork of the mentioned repository with two >>> extra >>> commits containing README and the build scripts. >>> >>> New webrev URL: >>> http://cr.openjdk.java.net/~jakvanek/8215902/webrev.04/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 >> >> Sorry for the late reply. >> >> This looks very good! Thank you for fixing this, including rebasing >> the >> github repo. >> >> I'm not sure if you've gotten reviews from the hotspot team for the >> hotspot source changes, but from a build perspective, this is good to >> go. >> >> /Magnus >>> >>> Regards, >>> >>> Jakub >>> >>> On 2019-01-15 at 15:05 +0100, Magnus Ihse Bursie wrote: >>>> On 2018-12-25 16:19, Jakub Van?k wrote: >>>>> Hi, >>>>> >>>>> please review this webrev. It is a successor of the softfloat-3 >>>>> [patch] >>>>> thread (first email >>>>> >>> >>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html >>>>> ) >>>>> >>>>> Changes since the last patch (v6): >>>>> >>>>> - renamed --with-softloat* to --with-sflt* (it is more compact >>>>> and >>>>> it >>>>> corresponds to the old --with-sflt-lib=... option) >>>>> >>>>> - license is now obtained via --with-sflt-license switch (so it >>>>> is >>>>> not >>>>> included in OpenJDK source tree) >>>>> >>>>> - updated documentation (slight rewording, added the license >>>>> option) >>>>> >>>>> - checks for default --with/--without behavior are in place >>>>> again >>>>> (I forgot them when I changed the way the library is >>>>> detected) >>>>> >>>>> - added a simple testcase - I found a disrepancy between >>>>> softfloat >>>>> and >>>>> system function behavior. When a float with bits 0x003FFFFF >>>>> is >>>>> added to 0x00000001, the correct result is 0x00400000, but >>>>> the >>>>> default software floating point implementation returns >>>>> 0x00000000. >>>>> However I'm not sure where to put this test - now it is in >>>>> test/hotspot/jtreg/compiler/floatingpoint. >>>>> >>>>> - comments in code refer to CR 6757269 and newly JDK-8215902 >>>>> too. >>>>> >>>>> I have created a repository with SoftFloat-3e with build >>>>> configuration >>>>> specifically for OpenJDK on armel: >>>>> https://github.com/ev3dev-lang-java/softfloat-openjdk >>>>> >>>>> I can add a link to it to the documentation. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 >>>>> Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ >>>> >>>> Hi Jakub, >>>> >>>> In general this looks good. >>>> >>>> Some comments: >>>> >>>> I agree with Erik that you can add a link to your github project; >>>> compiling SoftFloat is outside the scope of the OpenJDK build >>>> instructions, but it can sure be helpful to lower the bar for >>>> users >>>> wanting to do that. Just one question: any particular reason you >>>> didn't >>>> create your github repo by forking the official >>>> https://github.com/ucb-bar/berkeley-softfloat-3? That way, it >>>> would >>>> have >>>> been easy for users to see that you were not adding any malicious >>>> or >>>> suspicious code to the original SoftFloat distribution. >>>> >>>> On the other hand, I think the link to >>>> >>> >>> > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html >>>> >>>> is unnecessary and just creates clutter in the documentation. >>>> Please >>>> remove it. >>>> >>>> /Magnus >>>>> CI build: >>>>> > https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ >>>>> >>>>> Cheers, >>>>> >>>>> Jakub >>>>> >> >> > From christoph.langer at sap.com Fri Jan 25 09:31:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 25 Jan 2019 09:31:16 +0000 Subject: RFR (S) [11u backport]: 8207849: Allow the addition of more number to the Java version string Message-ID: Hi, may I please get reviews for the backport of this issue to jdk11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8207849 Original Commit: http://hg.openjdk.java.net/jdk/jdk/rev/1edc62f9ba3a Original review thread: https://mail.openjdk.java.net/pipermail/build-dev/2018-July/022719.html Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207849.11u/ The patch did not apply cleanly, but only because in "make/autoconf/version-numbers" some version numbers have changed in the meanwhile and the apply tool did not find the right spot to insert the additional variables. Thanks Christoph From magnus.ihse.bursie at oracle.com Fri Jan 25 10:20:32 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Jan 2019 11:20:32 +0100 Subject: RFR (S) [11u backport]: 8207849: Allow the addition of more number to the Java version string In-Reply-To: References: Message-ID: <99cf15f7-ddb6-b080-13fb-ad028cb808b5@oracle.com> On 2019-01-25 10:31, Langer, Christoph wrote: > Hi, > > may I please get reviews for the backport of this issue to jdk11u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8207849 > Original Commit: http://hg.openjdk.java.net/jdk/jdk/rev/1edc62f9ba3a > Original review thread: https://mail.openjdk.java.net/pipermail/build-dev/2018-July/022719.html > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207849.11u/ > > The patch did not apply cleanly, but only because in "make/autoconf/version-numbers" some version numbers have changed in the meanwhile and the apply tool did not find the right spot to insert the additional variables. > > Thanks > Christoph Looks good to me. When a patch fail to apply cleanly, I regularly try with the "wiggle" tool. [1] It is much more resilient to harmless changes than "patch". The backport rule of "applies cleanly" still requires you to send a RFR, but using wiggle saves your effort, and including a note about it in the RFR will increase reviewers confidence. /Magnus [1] https://github.com/neilbrown/wiggle From christoph.langer at sap.com Fri Jan 25 10:24:23 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 25 Jan 2019 10:24:23 +0000 Subject: RFR (S) [11u backport]: 8207849: Allow the addition of more number to the Java version string In-Reply-To: <99cf15f7-ddb6-b080-13fb-ad028cb808b5@oracle.com> References: <99cf15f7-ddb6-b080-13fb-ad028cb808b5@oracle.com> Message-ID: Thanks, Magnus for the review. I shall try wiggle ? > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Freitag, 25. Januar 2019 11:21 > To: Langer, Christoph ; 'build- > dev at openjdk.java.net' > Cc: Zeller, Arno > Subject: Re: RFR (S) [11u backport]: 8207849: Allow the addition of more > number to the Java version string > > > > On 2019-01-25 10:31, Langer, Christoph wrote: > > Hi, > > > > may I please get reviews for the backport of this issue to jdk11u. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8207849 > > Original Commit: http://hg.openjdk.java.net/jdk/jdk/rev/1edc62f9ba3a > > Original review thread: https://mail.openjdk.java.net/pipermail/build- > dev/2018-July/022719.html > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207849.11u/ > > > > The patch did not apply cleanly, but only because in > "make/autoconf/version-numbers" some version numbers have changed in > the meanwhile and the apply tool did not find the right spot to insert the > additional variables. > > > > Thanks > > Christoph > > Looks good to me. > > When a patch fail to apply cleanly, I regularly try with the "wiggle" > tool. [1] It is much more resilient to harmless changes than "patch". > The backport rule of "applies cleanly" still requires you to send a RFR, > but using wiggle saves your effort, and including a note about it in the > RFR will increase reviewers confidence. > > /Magnus > > [1] https://github.com/neilbrown/wiggle From magnus.ihse.bursie at oracle.com Fri Jan 25 14:18:11 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Jan 2019 15:18:11 +0100 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> Message-ID: <71ce8229-09ef-e819-2dc0-d4e37f663c97@oracle.com> On 2019-01-25 02:47, Leslie Zhai wrote: > Hi Magnus, > > Failed to make images: > > $ make images CONF=mips > Building target 'images' in configuration > 'linux-mips64el-normal-server-fastdebug' > GenerateLinkOptData.gmk:61: recipe for target > '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' > failed > make[3]: *** > [/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist] > Error 1 > make[3]: *** Deleting file > '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' > make/Main.gmk:441: recipe for target 'generate-link-opt-data' failed > make[2]: *** [generate-link-opt-data] Error 2 This should have worked, but sounds like something that can typically fail when cross-compiling. As a workaround, disable class list generation: "configure --disable-generate-classlist", or even "configure --disable-cds". /Magnus > > ERROR: Build failed for target 'images' in configuration > 'linux-mips64el-normal-server-fastdebug' (exit code 2) > > === Make failed targets repeated here === > GenerateLinkOptData.gmk:61: recipe for target > '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' > failed > make/Main.gmk:441: recipe for target 'generate-link-opt-data' failed > === End of repeated output === > > Hint: Try searching the build log for the name of the first failed > target. > Hint: See doc/building.html#troubleshooting for assistance. > > /home/loongson/zhaixiang/jdk12-mips/make/Init.gmk:300: recipe for > target 'main' failed > make[1]: *** [main] Error 2 > /home/loongson/zhaixiang/jdk12-mips/make/Init.gmk:186: recipe for > target 'images' failed > make: *** [images] Error 2 > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > My cross-compile configure option: > > CC=mips64el-linux-gnuabi64-gcc CXX=mips64el-linux-gnuabi64-g++ sh > ./configure \ > ? --openjdk-target=mips64el-linux-gnuabi64 \ > ? --with-sysroot=/chroots/mips64el_stretch \ > ? --with-toolchain-path=/chroots/mips64el_stretch \ > ? --with-boot-jdk=/home/loongson/aoqi/jdk-11.0.1 \ > ? --disable-warnings-as-errors \ > --with-freetype-lib=/chroots/mips64el_stretch/usr/lib/mips64el-linux-gnuabi64 > \ > --with-freetype-include=/chroots/mips64el_stretch/usr/include/freetype2 \ > ? --with-debug-level=fastdebug \ > ? --with-build-jdk=build/buildjdk/jdk > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > buildjdk is OK: > > $ sh configure --with-conf-name=buildjdk > --with-boot-jdk=/home/loongson/aoqi/jdk-11.0.1 > --disable-warnings-as-errors > > $ make jdk CONF=buildjdk > > Building target 'jdk' in configuration 'buildjdk' > Finished building target 'jdk' in configuration 'buildjdk' > > Regards, > > Leslie Zhai > > > ? 2019/1/24 ??9:30, Magnus Ihse Bursie ??: >> On 2019-01-24 13:22, Leslie Zhai wrote: >>> Hi Magnus, >>> >>> Thanks for your kind response! >>> >>> ? 2019/1/24 ??8:05, Magnus Ihse Bursie ??: >>>> >>>> >>>> On 2019-01-24 05:45, David Holmes wrote: >>>>> On 24/01/2019 1:51 pm, Ao Qi wrote: >>>>>> Hi David, >>>>>> >>>>>> On Thu, Jan 24, 2019 at 10:47 AM David Holmes >>>>>> wrote: >>>>>>> >>>>>>> Hi Leslie, >>>>>>> >>>>>>> I'm not Erik :) however .... >>>>>>> >>>>>>> On 24/01/2019 12:28 pm, Leslie Zhai wrote: >>>>>>>> Hi Erik, >>>>>>>> >>>>>>>> Because the flags' macro of MIPS is different from other >>>>>>>> targets[1], it >>>>>>>> will effect the `UnixConstants` of >>>>>>>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, >>>>>>>> for >>>>>>>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is >>>>>>>> different >>>>>>>> from other targets.? Then failed[2] to cross compiling jdk12 for >>>>>>>> mips64el-linux-gnu target by following the document[3]. >>>>>>> >>>>>>> It's been quite a while since we built for a platform where the >>>>>>> flags >>>>>>> had different values, but it is supposed to work. I suspect that >>>>>>> the way >>>>>>> we build now with the module system may not be quite correct in >>>>>>> this >>>>>>> regard - but that is just supposition on my part. Because >>>>>>> compile-time >>>>>>> constants are stored directly into class files that use them, we >>>>>>> have to >>>>>>> generate UnixConstants.java before compiling any class that >>>>>>> needs to use >>>>>>> it, then we must compile all classes that do use it. Those >>>>>>> classes must >>>>>>> only be executed in conjunction with a tool executing on the target >>>>>>> platform (javac, jmod etc). My suspicion is that we may be >>>>>>> executing a >>>>>>> tool on the build platform using the newly compiled classes for the >>>>>>> target platform - and that would be wrong. >>>>>>> >>>>>> >>>>>> Yes. Some variables in UnixConstants.java is defined according to >>>>>> the >>>>>> target (fcntl.h of mips in this case), but would be executed on host >>>>>> (x86 in this case) during "make images". These variables of ppc64le, >>>>>> aarch64 and s390x are the same as x86, but the ones of mips are not. >>>>>> However, mips is not an official supported target and I did not find >>>>>> other targets have similar issue, I am not sure if this is a bug >>>>>> or if >>>>>> this is the right mailing list :) >>>>> >>>>> This is the right mailing list to discuss. :) >>>>> >>>>> So I went back to find when this happened in the past and I >>>>> mis-remembered how we solved it. We previously had a problem with >>>>> the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 >>>>> platforms defined a different value for the O_NOFOLLOW and >>>>> O_DIRECT flags. The solution then was to commit a platform >>>>> specific version of UnixConstants.java and change the build system >>>>> to only use the template file if there was not a pre-existing >>>>> .java file. But that platform and the SE Embedded support was all >>>>> removed. (SocketOptions.java had a similar problem.) Further that >>>>> build logic is completely different to what we had back then (JDK >>>>> 6/7). >>>>> >>>>> This is definitely a bug in our build logic IMHO as we >>>>> specifically use the build platform c-pre-processor to process the >>>>> template file based on the target header files, but then use the >>>>> resulting class when running tools on the build platform. >>>> I agree with David. This is a bug in the build system; arguably >>>> even a regression. >>>> >>>>> This was not something that happened in 6/7 or even 8 and I think >>>>> the module system tools are where the issue now lies. >>>>> >>>>> I think Erik and/or Magnus will have to give advice on how this >>>>> may be properly fixed. I can't see any simple solution. >>>> Unfortunately, I also agree that there is no simple solution. :-( >>>> >>>> The proper way to handle this is to generate two versions of >>>> UnixConstants and friends, one for the build platform, and one for >>>> the target platform. But as far as I know, there is no simple way >>>> to handle such complications in our current structure. Erik knows >>>> more about this, he was the one who designed the current solution >>>> for handling cross-compilation in the modularized world. >>>> >>>> However, I can at least help you with a relatively simple >>>> workaround. First some background: When we cross-compile, we need >>>> not only a Boot JDK (of version current N-1) running on the build >>>> host platform, but we also need a Build JDK, based on the current >>>> source code, running on the build host. (This is for running >>>> jmod/jlink; it needs to be up to date). If we have no Build JDK >>>> present, we start by creating one ourselves. This is more or less >>>> the same output as running a normal, non-cross compiled, build on >>>> the build host. (But Erik found some ways to cut a few corners to >>>> save time.) Your problem is that the Build JDK is broken, since >>>> UnixConstants has the wrong values. >>>> - >>>> But you can supply your own working Build JDK to configure! >>>> >>>> So, your workflow for cross-compiling to MIPS should be: >>>> 1) create a Build JDK, e.g. like this: "bash configure >>>> --with-conf-name=buildjdk && make jdk CONF=buildjdk" >>>> 2) create your cross-compilation JDK like this: "bash configure >>>> --openjdk-target=mipsel-unknown-linux-gnu >>>> --with-build-jdk=build/buildjdk/jdk" >>>> ... or something like that. >>>> Then you can build your cross-compiled jdk with "make images >>>> CONF=mips". >>> >>> I will try that, thanks a lot for your teaching! >> Please let me know if it works. I wrote the command lines out of my >> head, so they might need some tweaking to get right. >> >> Perhaps this is an acceptable solution to you? Unless Erik can >> suggest ways to fix this properly that is not too complicated, maybe >> this can be a good enough solution for you? (But if there is a simple >> solution, I'd rather have it fixed properly.) >> >> /Magnus >>> >>> Regards, >>> >>> Leslie Zhai >>> >>> >>>> >>>> >>>> In theory, you should rebuild your buildjdk for each and every >>>> change ("make jdk CONF=buildjdk && make images CONF=mips"); but in >>>> reality, I don't believe there is really any need to rebuild the >>>> buildjdk (unless major changes in jlink/jmod happens). >>>> >>>> /Magnus >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> ? For example: >>>>>> >>>>>> jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND >>>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> -- >>>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> -- >>>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> -- >>>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> -- >>>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> -- >>>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 0x0008 >>>>>> -- >>>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: >>>>>> >>>>>> ??? static final int O_APPEND = >>>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- >>>>>> >>>>>> ????????????????????????????????????? 02000 >>>>>> >>>>>> log.mips:2of path: >>>>>> /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>>>>> >>>>>> oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 >>>>>> log.ppc:2of path: >>>>>> /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp >>>>>> >>>>>> oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 >>>>>> >>>>>> Cheers, >>>>>> Ao Qi >>>>>> >>>> >>> >> > From glaubitz at physik.fu-berlin.de Fri Jan 25 14:31:41 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 25 Jan 2019 15:31:41 +0100 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> Message-ID: <7cc75b32-64cd-5df0-2f16-db9c779a69dd@physik.fu-berlin.de> Hi! On 1/24/19 3:28 AM, Leslie Zhai wrote: > Please give me some advice about how to fix the root cause, thanks a lot! Just as a heads-up: In Debian we have two patches required for OpenJDK on the mips targets: > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/mips-sigset.diff I think the stuff with sigset was being worked on upstream at some point, but it wasn't finished if I remember correctly. 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 aph at redhat.com Fri Jan 25 14:39:17 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Jan 2019 14:39:17 +0000 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: <666d7045-a72d-fc6f-d70b-f4b88ce6b180@redhat.com> Massive win for gold here, on my (very old) AArch64 system: BFD linker: $ time /home/aph/gcc-x/aarch64-trunk-install/bin/g++ -Wl,-z,defs -fuse-ld=bfd -Wl,-z,noexecstack ... real 0m26.090s user 0m24.570s sys 0m1.480s gold, single-threaded: $ time /home/aph/gcc-x/aarch64-trunk-install/bin/g++ -Wl,-z,defs -fuse-ld=gold -Wl,-z,noexecstack ... real 0m12.325s user 0m12.030s sys 0m0.280s gold, multi-threaded: $ time /home/aph/gcc-x/aarch64-trunk-install/bin/g++ -Wl,-z,defs -fuse-ld=gold -Wl,--threads -Wl,-z,noexecstack ... real 0m8.297s user 0m14.680s sys 0m1.650s I would very much like to see this change go in, with a probe to make sure that -fuse-ld=gold works. There is unfortunately one gotcha: on some systems gold is built without threading support (why, fercrineoutloud?) so it's necessary to probe for -Wl,--threads separately. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aoqi at loongson.cn Fri Jan 25 14:44:56 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 25 Jan 2019 22:44:56 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> Message-ID: Hi, FYI, if one wants to debug this issue, below is some sctripts I used to cross compile a mips zero jdk, which can trigger the bug. build machine: x86, debian testing (in a VirtualBox; an ubuntu may fail to configure) known worked targets: ppc64le/server and s390x/server (aarch64/server may fail during make images) repository: http://hg.openjdk.java.net/jdk/jdk geting a sysroot: #export arch=arm64 #export arch=ppc64el #export arch=s390x export arch=mips64el export ver=stretch apt-get install qemu-user-static sudo debootstrap binfmt-support qemu (not sure if all of them are required) sudo qemu-debootstrap --arch=${arch} --verbose \ --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng-dev,libffi-dev \ --resolve-deps ${ver} /chroots/${arch}_${ver} http://httpredir.debian.org/debian/ configure of jdk: #arch1=aarch64 ; arch2=arm64; gnuname=gnu #arch1=powerpc64le ; arch2=ppc64el; gnuname=gnu #arch1=s390x ; arch2=s390x; gnuname=gnu arch1=mips64el ; arch2=mips64el; gnuname=gnuabi64 apt install g++-${arch1}-linux-${gnuname} gcc-${arch1}-linux-${gnuname} ver=stretch CC=$arch1-linux-${gnuname}-gcc CXX=$arch1-linux-${gnuname}-g++ \ sh ./configure --openjdk-target=$arch1-linux-${gnuname} --with-sysroot=/chroots/${arch2}_${ver}/ --with-toolchain-path=/chroots/${arch2}_${ver}/ \ --with-boot-jdk=/home/loongson/aoqi/jdk-13/ --disable-warnings-as-errors \ --with-jvm-variants=zero \ --x-libraries=/chroots/${arch2}_${ver}/usr/lib/$arch1-linux-${gnuname} --x-include=/chroots/${arch2}_${ver}/usr/include/X11/ \ --with-freetype-lib=/chroots/${arch2}_${ver}/usr/lib/$arch1-linux-${gnuname}/ --with-freetype-include=/chroots/${arch2}_${ver}/usr/include/freetype2 make: do one patch [1] then make images I am trying Magnus's approach. When there are results, I will reply. [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-December/031839.html On Fri, Jan 25, 2019 at 1:19 AM Erik Joelsson wrote: > > Hello, > > I agree with the conclusion here, there is certainly a bug in the build > logic. When creating the "Build JDK" during a cross compilation build, > we are, as Magnus said, cutting a few corners for efficiency. One of > those corners is assuming all the java classes are the same and can > simply be reused. It has been shown here that that assumption is not > always correct. > > I think the most reasonable solution is to assume all of java.base needs > to be built specifically for the "Build JDK". I think this can be > reasonably easy to implement (compared to the existing Build JDK logic, > which is arguably rather hairy). > > Magnus' suggested workaround should work fine for now however. > > Filed https://bugs.openjdk.java.net/browse/JDK-8217739 > > /Erik > > On 2019-01-24 05:30, Magnus Ihse Bursie wrote: > > On 2019-01-24 13:22, Leslie Zhai wrote: > >> Hi Magnus, > >> > >> Thanks for your kind response! > >> > >> ? 2019/1/24 ??8:05, Magnus Ihse Bursie ??: > >>> > >>> > >>> On 2019-01-24 05:45, David Holmes wrote: > >>>> On 24/01/2019 1:51 pm, Ao Qi wrote: > >>>>> Hi David, > >>>>> > >>>>> On Thu, Jan 24, 2019 at 10:47 AM David Holmes > >>>>> wrote: > >>>>>> > >>>>>> Hi Leslie, > >>>>>> > >>>>>> I'm not Erik :) however .... > >>>>>> > >>>>>> On 24/01/2019 12:28 pm, Leslie Zhai wrote: > >>>>>>> Hi Erik, > >>>>>>> > >>>>>>> Because the flags' macro of MIPS is different from other > >>>>>>> targets[1], it > >>>>>>> will effect the `UnixConstants` of > >>>>>>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, > >>>>>>> for > >>>>>>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is > >>>>>>> different > >>>>>>> from other targets. Then failed[2] to cross compiling jdk12 for > >>>>>>> mips64el-linux-gnu target by following the document[3]. > >>>>>> > >>>>>> It's been quite a while since we built for a platform where the > >>>>>> flags > >>>>>> had different values, but it is supposed to work. I suspect that > >>>>>> the way > >>>>>> we build now with the module system may not be quite correct in this > >>>>>> regard - but that is just supposition on my part. Because > >>>>>> compile-time > >>>>>> constants are stored directly into class files that use them, we > >>>>>> have to > >>>>>> generate UnixConstants.java before compiling any class that needs > >>>>>> to use > >>>>>> it, then we must compile all classes that do use it. Those > >>>>>> classes must > >>>>>> only be executed in conjunction with a tool executing on the target > >>>>>> platform (javac, jmod etc). My suspicion is that we may be > >>>>>> executing a > >>>>>> tool on the build platform using the newly compiled classes for the > >>>>>> target platform - and that would be wrong. > >>>>>> > >>>>> > >>>>> Yes. Some variables in UnixConstants.java is defined according to the > >>>>> target (fcntl.h of mips in this case), but would be executed on host > >>>>> (x86 in this case) during "make images". These variables of ppc64le, > >>>>> aarch64 and s390x are the same as x86, but the ones of mips are not. > >>>>> However, mips is not an official supported target and I did not find > >>>>> other targets have similar issue, I am not sure if this is a bug > >>>>> or if > >>>>> this is the right mailing list :) > >>>> > >>>> This is the right mailing list to discuss. :) > >>>> > >>>> So I went back to find when this happened in the past and I > >>>> mis-remembered how we solved it. We previously had a problem with > >>>> the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 > >>>> platforms defined a different value for the O_NOFOLLOW and O_DIRECT > >>>> flags. The solution then was to commit a platform specific version > >>>> of UnixConstants.java and change the build system to only use the > >>>> template file if there was not a pre-existing .java file. But that > >>>> platform and the SE Embedded support was all removed. > >>>> (SocketOptions.java had a similar problem.) Further that build > >>>> logic is completely different to what we had back then (JDK 6/7). > >>>> > >>>> This is definitely a bug in our build logic IMHO as we specifically > >>>> use the build platform c-pre-processor to process the template file > >>>> based on the target header files, but then use the resulting class > >>>> when running tools on the build platform. > >>> I agree with David. This is a bug in the build system; arguably even > >>> a regression. > >>> > >>>> This was not something that happened in 6/7 or even 8 and I think > >>>> the module system tools are where the issue now lies. > >>>> > >>>> I think Erik and/or Magnus will have to give advice on how this may > >>>> be properly fixed. I can't see any simple solution. > >>> Unfortunately, I also agree that there is no simple solution. :-( > >>> > >>> The proper way to handle this is to generate two versions of > >>> UnixConstants and friends, one for the build platform, and one for > >>> the target platform. But as far as I know, there is no simple way to > >>> handle such complications in our current structure. Erik knows more > >>> about this, he was the one who designed the current solution for > >>> handling cross-compilation in the modularized world. > >>> > >>> However, I can at least help you with a relatively simple > >>> workaround. First some background: When we cross-compile, we need > >>> not only a Boot JDK (of version current N-1) running on the build > >>> host platform, but we also need a Build JDK, based on the current > >>> source code, running on the build host. (This is for running > >>> jmod/jlink; it needs to be up to date). If we have no Build JDK > >>> present, we start by creating one ourselves. This is more or less > >>> the same output as running a normal, non-cross compiled, build on > >>> the build host. (But Erik found some ways to cut a few corners to > >>> save time.) Your problem is that the Build JDK is broken, since > >>> UnixConstants has the wrong values. > >>> - > >>> But you can supply your own working Build JDK to configure! > >>> > >>> So, your workflow for cross-compiling to MIPS should be: > >>> 1) create a Build JDK, e.g. like this: "bash configure > >>> --with-conf-name=buildjdk && make jdk CONF=buildjdk" > >>> 2) create your cross-compilation JDK like this: "bash configure > >>> --openjdk-target=mipsel-unknown-linux-gnu > >>> --with-build-jdk=build/buildjdk/jdk" > >>> ... or something like that. > >>> Then you can build your cross-compiled jdk with "make images > >>> CONF=mips". > >> > >> I will try that, thanks a lot for your teaching! > > Please let me know if it works. I wrote the command lines out of my > > head, so they might need some tweaking to get right. > > > > Perhaps this is an acceptable solution to you? Unless Erik can suggest > > ways to fix this properly that is not too complicated, maybe this can > > be a good enough solution for you? (But if there is a simple solution, > > I'd rather have it fixed properly.) > > > > /Magnus > >> > >> Regards, > >> > >> Leslie Zhai > >> > >> > >>> > >>> > >>> In theory, you should rebuild your buildjdk for each and every > >>> change ("make jdk CONF=buildjdk && make images CONF=mips"); but in > >>> reality, I don't believe there is really any need to rebuild the > >>> buildjdk (unless major changes in jlink/jmod happens). > >>> > >>> /Magnus > >>>> > >>>> David > >>>> ----- > >>>> > >>>>> For example: > >>>>> > >>>>> jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND > >>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>> > >>>>> static final int O_APPEND = > >>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> 02000 > >>>>> -- > >>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>> > >>>>> static final int O_APPEND = > >>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> 02000 > >>>>> -- > >>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>> > >>>>> static final int O_APPEND = > >>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> 02000 > >>>>> -- > >>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>> > >>>>> static final int O_APPEND = > >>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> 02000 > >>>>> -- > >>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>> > >>>>> static final int O_APPEND = > >>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> 02000 > >>>>> -- > >>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>> > >>>>> static final int O_APPEND = > >>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> 0x0008 > >>>>> -- > >>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>> > >>>>> static final int O_APPEND = > >>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>> > >>>>> 02000 > >>>>> > >>>>> log.mips:2of path: > >>>>> /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp > >>>>> > >>>>> oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 > >>>>> log.ppc:2of path: > >>>>> /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp > >>>>> > >>>>> oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 > >>>>> > >>>>> Cheers, > >>>>> Ao Qi > >>>>> > >>> > >> > > From glaubitz at physik.fu-berlin.de Fri Jan 25 14:51:42 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 25 Jan 2019 15:51:42 +0100 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> Message-ID: <27e79860-7fe6-4da8-86d0-94683dfd0205@physik.fu-berlin.de> On 1/25/19 3:44 PM, Ao Qi wrote:> FYI, if one wants to debug this issue, below is some sctripts I used > to cross compile a mips zero jdk, which can trigger the bug. Native builds on Debian unstable on mips* work? > do one patch [1] then make images What about the alignment patch? Is that still required? > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff 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 aoqi at loongson.cn Fri Jan 25 14:57:48 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 25 Jan 2019 22:57:48 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: <7cc75b32-64cd-5df0-2f16-db9c779a69dd@physik.fu-berlin.de> References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <7cc75b32-64cd-5df0-2f16-db9c779a69dd@physik.fu-berlin.de> Message-ID: Hi, On Fri, Jan 25, 2019 at 10:31 PM John Paul Adrian Glaubitz wrote: > > Hi! > > On 1/24/19 3:28 AM, Leslie Zhai wrote: > > Please give me some advice about how to fix the root cause, thanks a lot! > > Just as a heads-up: In Debian we have two patches required for OpenJDK on the mips > targets: > > > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff > > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/mips-sigset.diff > > I think the stuff with sigset was being worked on upstream at some point, but it > wasn't finished if I remember correctly. > Yes, I wish to solve this problem, I tried, and it was basically the way Debian and AIX used [1]. But David Holmes wishes a POSIX version, that patch failed to be pushed. I think I will go on to work on it, however I do not have Solaris and macOS for test, I am working on preparing these OSs. What is https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff for? We build mips zero without this patch. Cheers, Ao Qi [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-December/031839.html > 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 aoqi at loongson.cn Fri Jan 25 15:10:50 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 25 Jan 2019 23:10:50 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: <27e79860-7fe6-4da8-86d0-94683dfd0205@physik.fu-berlin.de> References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> <27e79860-7fe6-4da8-86d0-94683dfd0205@physik.fu-berlin.de> Message-ID: On Fri, Jan 25, 2019 at 10:51 PM John Paul Adrian Glaubitz wrote: > > On 1/25/19 3:44 PM, Ao Qi wrote:> FYI, if one wants to debug this issue, below is some sctripts I used > > to cross compile a mips zero jdk, which can trigger the bug. > > Native builds on Debian unstable on mips* work? > Worked. We nightly native (using Loongson CPUs) build zero mips of jdk8-12 and jdk. But zero mips is not stable as boot jdk, some random crash occurs. I am not sure it is an issue of zero mips or an issue of MIPS for example maybe some memory consistency issue. > > do one patch [1] then make images > > What about the alignment patch? Is that still required? > We do not use this patch. > > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff > > 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 aoqi at loongson.cn Fri Jan 25 15:15:14 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 25 Jan 2019 23:15:14 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> <27e79860-7fe6-4da8-86d0-94683dfd0205@physik.fu-berlin.de> Message-ID: Hi John, On Fri, Jan 25, 2019 at 11:10 PM Ao Qi wrote: > > On Fri, Jan 25, 2019 at 10:51 PM John Paul Adrian Glaubitz > wrote: > > > > On 1/25/19 3:44 PM, Ao Qi wrote:> FYI, if one wants to debug this issue, below is some sctripts I used > > > to cross compile a mips zero jdk, which can trigger the bug. > > > > Native builds on Debian unstable on mips* work? > > > Correction. We use Debian stable and testing to do night build (only mips64el). We did not use Debian unstable, Is the difference big? > Worked. We nightly native (using Loongson CPUs) build zero mips of > jdk8-12 and jdk. But zero mips is not stable as boot jdk, some random > crash occurs. I am not sure it is an issue of zero mips or an issue of > MIPS for example maybe some memory consistency issue. > > > > > do one patch [1] then make images > > > > What about the alignment patch? Is that still required? > > > > We do not use this patch. > > > > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff > > > > 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 sgehwolf at redhat.com Fri Jan 25 15:27:13 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 25 Jan 2019 16:27:13 +0100 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries Message-ID: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> Hi, I'm working on an enhancement for jlink. In particular a platform specific plugin. I.e. It would only get built on unix/linux platforms. My trouble is getting some resouce properties set up properly. In my example there is two versions of plugins.properties: one in shared/classes one in unix/classes. These, need to get merged into one via the MergeProperties build tool class. So far so good. But for the cases where there is only one resource property it should just get copied to support/gensrc and that source root be used for compiling those properties into actual ListResourceBundle Java classes. The copying from the src tree to the gensrc tree doesn't seem to work. I've tried using $(CP) and SetupCopyFiles to no avail. Would anybody willing to help? WIP webrev is: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/01/webrev/ I thought I'd do the copying in an else branch in SetupPropertiesMerge, where I've put in a FIXME comment. Am I on the wrong track? Thanks, Severin From aph at redhat.com Fri Jan 25 15:39:08 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Jan 2019 15:39:08 +0000 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <666d7045-a72d-fc6f-d70b-f4b88ce6b180@redhat.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <666d7045-a72d-fc6f-d70b-f4b88ce6b180@redhat.com> Message-ID: <9e907e73-fd27-deea-da8a-05be4fd6c9f7@redhat.com> On 1/25/19 2:39 PM, Andrew Haley wrote: > Massive win for gold here, on my (very old) AArch64 system: And on another, faster AArch64 system: BFD linker: real 0m14.532s user 0m13.070s sys 0m1.419s gold, single-threaded: real 0m6.313s user 0m6.123s sys 0m0.190s gold, multi-threaded: real 0m4.129s user 0m8.724s sys 0m1.741s Verdict: yes, please! -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Jan 25 15:42:42 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Jan 2019 15:42:42 +0000 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: <9d625466-43c2-8db3-7e23-07c7c6f7d8ad@redhat.com> On 1/24/19 2:04 PM, Magnus Ihse Bursie wrote: > But I'm leaning more towards just enabling gold on x86_64 -- for other > platforms, we might as well keep the good ol' bfd linker. Does that > sound like a good solution to you? I'd love it to be an option for AArch64. -- 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 Fri Jan 25 16:45:56 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Jan 2019 17:45:56 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <9d625466-43c2-8db3-7e23-07c7c6f7d8ad@redhat.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <9d625466-43c2-8db3-7e23-07c7c6f7d8ad@redhat.com> Message-ID: On 2019-01-25 16:42, Andrew Haley wrote: > On 1/24/19 2:04 PM, Magnus Ihse Bursie wrote: >> But I'm leaning more towards just enabling gold on x86_64 -- for other >> platforms, we might as well keep the good ol' bfd linker. Does that >> sound like a good solution to you? > I'd love it to be an option for AArch64. > I hear you. My current thinking is that I'm going to introduce a configure argument, something like --with-toolchain-linker=gold, and if it is enabled, I'll verify that gold is indeed present, and if it supports --threads. It will be available on all gcc platforms. This will take some more time to write than my initial one-liner, so I'll take this back to the drawing board for awhile. /Magnus From magnus.ihse.bursie at oracle.com Fri Jan 25 16:55:12 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Jan 2019 17:55:12 +0100 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> Message-ID: <1a11e808-8df1-8c85-8beb-6a0a0061217b@oracle.com> On 2019-01-25 16:27, Severin Gehwolf wrote: > Hi, > > I'm working on an enhancement for jlink. In particular a platform > specific plugin. I.e. It would only get built on unix/linux platforms. > My trouble is getting some resouce properties set up properly. In my > example there is two versions of plugins.properties: one in > shared/classes one in unix/classes. These, need to get merged into one > via the MergeProperties build tool class. So far so good. But for the > cases where there is only one resource property it should just get > copied to support/gensrc and that source root be used for compiling > those properties into actual ListResourceBundle Java classes. > > The copying from the src tree to the gensrc tree doesn't seem to work. > I've tried using $(CP) and SetupCopyFiles to no avail. Would anybody > willing to help? SetupCopyFile should work, but in this case I think it's simplest to just use install-file. Like this perhaps: ifneq ($$($1_NUM_INPUT_FILES), 1) ? $$($1_TARGET): $$($1_INPUT_FILES) ????? $$(call LogInfo, Merging $$($1_NUM_INPUT_FILES) properties files into a single properties file for jdk.jlink) ????? $(TOOL_MERGE_PROPERTIES) \ $(GENERATED_JLINK_RESOURCES_DIR)/$$($1_PROP).properties \ ????????????? $$($1_INPUT_FILES) else ? $$($1_TARGET): $$($1_INPUT_FILES) ??? $$(install-file) endif $1 += $$($1_TARGET) /Magnus $$($1_TARGET): $$($1_DEPS) > > WIP webrev is: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/01/webrev/ > > I thought I'd do the copying in an else branch in SetupPropertiesMerge, > where I've put in a FIXME comment. Am I on the wrong track? > > Thanks, > Severin > From martinrb at google.com Fri Jan 25 17:01:56 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 25 Jan 2019 09:01:56 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: I re-ran my linker performance experiment using configure --with-native-debug-symbols="internal" lld is a big winner here: --- ld=bfd --- /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstac 7.30s user 1.26s system 99% cpu 8.559 total /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstac 6.73s user 1.18s system 99% cpu 7.908 total --- ld=gold --- /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstac 4.57s user 0.62s system 99% cpu 5.191 total /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstac 4.67s user 0.53s system 99% cpu 5.209 total --- ld=lld --- /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstac 2.61s user 1.10s system 330% cpu 1.124 total /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstac 2.72s user 1.03s system 326% cpu 1.146 total On Thu, Jan 24, 2019 at 10:49 AM Martin Buchholz wrote: > > Here's an experiment using the 3 competing open source linkers to link > hotspot. This confirms that lld is faster than gold is faster than > bfd, but is the one second saving worth the engineering effort? > > $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for > linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++ > -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack > -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared > -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile > -Wl,-soname=libjvm.so -o > $BUILDDIR/support/modules_libs/java.base/server/libjvm.so > @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt > -lm -ldl -lpthread; done) > --- bfd --- > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > -Wl,-O1 -m6 1.31s user 0.36s system 99% cpu 1.669 total > --- gold --- > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > -Wl,-O1 -m6 0.42s user 0.11s system 99% cpu 0.537 total > --- lld --- > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs > -Wl,-O1 -m6 0.25s user 0.20s system 145% cpu 0.310 total From aph at redhat.com Fri Jan 25 17:14:21 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Jan 2019 17:14:21 +0000 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <9d625466-43c2-8db3-7e23-07c7c6f7d8ad@redhat.com> Message-ID: <1574a719-b505-133f-a103-99db1724707e@redhat.com> On 1/25/19 4:45 PM, Magnus Ihse Bursie wrote: > On 2019-01-25 16:42, Andrew Haley wrote: >> On 1/24/19 2:04 PM, Magnus Ihse Bursie wrote: >>> But I'm leaning more towards just enabling gold on x86_64 -- for other >>> platforms, we might as well keep the good ol' bfd linker. Does that >>> sound like a good solution to you? >> I'd love it to be an option for AArch64. >> > I hear you. > > My current thinking is that I'm going to introduce a configure argument, > something like --with-toolchain-linker=gold, and if it is enabled, I'll > verify that gold is indeed present, and if it supports --threads. It > will be available on all gcc platforms. > > This will take some more time to write than my initial one-liner, so > I'll take this back to the drawing board for awhile. Thank you. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martinrb at google.com Fri Jan 25 17:15:27 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 25 Jan 2019 09:15:27 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <9d625466-43c2-8db3-7e23-07c7c6f7d8ad@redhat.com> Message-ID: In our own wrappers around configure, we've introduced the concept of a "developer mode". But this thread suggests there are 3 populations of users invoking configure: 1. release engineers 2. hotspot developers 3. java library developers Category 1 doesn't care about edit-compile-debug cycle - they just want to build a reliable high-performance jdk without pitfalls. This is the VAST MAJORITY of users, for whom we should design defaults in configure. Category 2 wants debug info and maybe incremental linking. They might cheat and rebuild only libjvm.so and drop that one file into a previously built jdk as part of their development cycle. Category 3 doesn't care about native debug symbols at all From erik.joelsson at oracle.com Fri Jan 25 17:17:52 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 Jan 2019 09:17:52 -0800 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> Message-ID: Hello Severin, To get the conditional running of either MergeProperties or copy, I would do something like this: $$($1_TARGET): $$($1_DEPS) $$(call MakeTargetDir) ifneq ($$($1_NUM_INPUT_FILES),1) $$(call LogInfo, Merging $$(words $$($1_INPUT_FILES)) properties files into a single properties file for jdk.jlink) $(TOOL_MERGE_PROPERTIES) \ $(GENERATED_JLINK_RESOURCES_DIR)/$$($1_PROP).properties \ $$($1_INPUT_FILES) else $$(call LogInfo, Copying $$(patsubst $(OUTPUTDIR)/%,%,$$@))) $$(call install-file) endif $1 := $$($1_TARGET) Note that the make conditional lines need to be indented with space while the recipe lines (including the $$(call )) needs to be tabbed. We still like them to align though, assuming 8 spaces tabs. Down in the call loop, the first argument to SetupPropertiesMerge must be unique. This can be achieved with MERGE_JLINK_PROPS_$(prop). Then add a line like this last in the loop: $(eval TARGETS += $(MERGE_JLINK_PROPS_$(prop))) To find all the src dirs for the jlink module, there are helper macros in make/common/Modules.gmk. JLINK_RESOURCE_DIRS := $(addsuffix /jdk/tools/jlink/resources, $(call FindModuleSrcDirs, jdk.jlink)) In the loop I would recommend reusing the already built list of all properties files instead of calling find again. Also, if all properties files in the resource dir are in the same directory with no sub directories, then please consider using $(wildcard ) to find them as that's much less taxing on Windows. Hope this helps! /Erik On 2019-01-25 07:27, Severin Gehwolf wrote: > Hi, > > I'm working on an enhancement for jlink. In particular a platform > specific plugin. I.e. It would only get built on unix/linux platforms. > My trouble is getting some resouce properties set up properly. In my > example there is two versions of plugins.properties: one in > shared/classes one in unix/classes. These, need to get merged into one > via the MergeProperties build tool class. So far so good. But for the > cases where there is only one resource property it should just get > copied to support/gensrc and that source root be used for compiling > those properties into actual ListResourceBundle Java classes. > > The copying from the src tree to the gensrc tree doesn't seem to work. > I've tried using $(CP) and SetupCopyFiles to no avail. Would anybody > willing to help? > > WIP webrev is: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/01/webrev/ > > I thought I'd do the copying in an else branch in SetupPropertiesMerge, > where I've put in a FIXME comment. Am I on the wrong track? > > Thanks, > Severin > From philip.race at oracle.com Fri Jan 25 17:21:35 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 25 Jan 2019 09:21:35 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <9d625466-43c2-8db3-7e23-07c7c6f7d8ad@redhat.com> Message-ID: <5C4B459F.6000605@oracle.com> Category 3 has to deal with plenty of native code too ... -phil On 1/25/19, 9:15 AM, Martin Buchholz wrote: > In our own wrappers around configure, we've introduced the concept of > a "developer mode". But this thread suggests there are 3 populations > of users invoking configure: > > 1. release engineers > 2. hotspot developers > 3. java library developers > > Category 1 doesn't care about edit-compile-debug cycle - they just > want to build a reliable high-performance jdk without pitfalls. This > is the VAST MAJORITY of users, for whom we should design defaults in > configure. > Category 2 wants debug info and maybe incremental linking. They might > cheat and rebuild only libjvm.so and drop that one file into a > previously built jdk as part of their development cycle. > Category 3 doesn't care about native debug symbols at all From aph at redhat.com Fri Jan 25 18:07:10 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Jan 2019 18:07:10 +0000 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> Message-ID: <7b842e3a-d512-736a-affc-eaa5cff81526@redhat.com> On 1/25/19 5:01 PM, Martin Buchholz wrote: > I re-ran my linker performance experiment using configure > --with-native-debug-symbols="internal" > lld is a big winner here: It looks to me like lld and multi-threaded gold would be a near tie. I think that lld uses multi-threading; I wonder why gold doesn't. But either is so fast linking libjvm.so that I no longer care. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martinrb at google.com Fri Jan 25 18:43:07 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 25 Jan 2019 10:43:07 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <7b842e3a-d512-736a-affc-eaa5cff81526@redhat.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <7b842e3a-d512-736a-affc-eaa5cff81526@redhat.com> Message-ID: On Fri, Jan 25, 2019 at 10:07 AM Andrew Haley wrote: > > On 1/25/19 5:01 PM, Martin Buchholz wrote: > > I re-ran my linker performance experiment using configure > > --with-native-debug-symbols="internal" > > lld is a big winner here: > > It looks to me like lld and multi-threaded gold would be a near tie. I > think that lld uses multi-threading; I wonder why gold doesn't. But > either is so fast linking libjvm.so that I no longer care. repeating my last experiment with explicit --threads: --- ld=gold --- /usr/bin/g++ -fuse-ld=$ld -Wl,--threads -Wl,--hash-style=both -Wl,-z,defs 9.18s user 4.98s system 329% cpu 4.292 total /usr/bin/g++ -fuse-ld=$ld -Wl,--threads -Wl,--hash-style=both -Wl,-z,defs 9.12s user 5.12s system 333% cpu 4.266 total --- ld=lld --- /usr/bin/g++ -fuse-ld=$ld -Wl,--threads -Wl,--hash-style=both -Wl,-z,defs 2.70s user 1.09s system 324% cpu 1.169 total /usr/bin/g++ -fuse-ld=$ld -Wl,--threads -Wl,--hash-style=both -Wl,-z,defs 2.74s user 1.00s system 328% cpu 1.141 total and with explicit --no-threads: --- ld=gold --- /usr/bin/g++ -fuse-ld=$ld -Wl,--no-threads -Wl,--hash-style=both -Wl,-z,defs 4.61s user 0.61s system 99% cpu 5.213 total /usr/bin/g++ -fuse-ld=$ld -Wl,--no-threads -Wl,--hash-style=both -Wl,-z,defs 4.60s user 0.61s system 99% cpu 5.212 total --- ld=lld --- /usr/bin/g++ -fuse-ld=$ld -Wl,--no-threads -Wl,--hash-style=both -Wl,-z,defs 1.67s user 0.60s system 99% cpu 2.289 total /usr/bin/g++ -fuse-ld=$ld -Wl,--no-threads -Wl,--hash-style=both -Wl,-z,defs 1.66s user 0.60s system 99% cpu 2.283 total From Pavel_Simonovsky at bmc.com Fri Jan 25 21:12:08 2019 From: Pavel_Simonovsky at bmc.com (Simonovsky, Pavel) Date: Fri, 25 Jan 2019 21:12:08 +0000 Subject: Failure at rung of get_source on windows with cygwin Message-ID: <26d61a8225e24836a46c6e333236d779@phx-exmbprd-02.adprod.bmc.com> Hi. I am attempting to build Open jdk 8u from sources. At Linux (RH6 it worked smoothly. At windows I am trying to build using Cygwin version 2.8... I am failing at windows build on step of running get_source.sh: nashorn: abort: stream ended unexpectedly (got 1297 bytes, expected 192443) jaxws: abort: stream ended unexpectedly (got 1957 bytes, expected 21072) jaxp: rollback completed hotspot: abort: stream ended unexpectedly (got 99623 bytes, expected 483101) jaxp: abort: stream ended unexpectedly (got 28110 bytes, expected 37505) langtools: transaction abort! langtools: rollback completed langtools: abort: stream ended unexpectedly (got 810 bytes, expected 2288) WARNING: /tmp/forest.34500/hotspot.pid.rc exited abnormally. WARNING: /tmp/forest.34500/jaxp.pid.rc exited abnormally. WARNING: /tmp/forest.34500/jaxws.pid.rc exited abnormally. WARNING: /tmp/forest.34500/langtools.pid.rc exited abnormally. WARNING: /tmp/forest.34500/nashorn.pid.rc exited abnormally. I have enough disk space: $ df -k . Filesystem 1K-blocks Used Available Use% Mounted on C: 248548552 191203664 57344888 77% /cygdrive/c And fast network connection. What have I to do to troubleshoot this problem? From magnus.ihse.bursie at oracle.com Fri Jan 25 21:34:35 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Jan 2019 22:34:35 +0100 Subject: Configure "developer mode" [was: Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain] In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <9d625466-43c2-8db3-7e23-07c7c6f7d8ad@redhat.com> Message-ID: On 2019-01-25 18:15, Martin Buchholz wrote: > In our own wrappers around configure, we've introduced the concept of > a "developer mode". But this thread suggests there are 3 populations > of users invoking configure: > > 1. release engineers > 2. hotspot developers > 3. java library developers > > Category 1 doesn't care about edit-compile-debug cycle - they just > want to build a reliable high-performance jdk without pitfalls. This > is the VAST MAJORITY of users, for whom we should design defaults in > configure. > Category 2 wants debug info and maybe incremental linking. They might > cheat and rebuild only libjvm.so and drop that one file into a > previously built jdk as part of their development cycle. > Category 3 doesn't care about native debug symbols at all I've been thinking about doing something similar in configure, for quite some time. This time I intend to finish it as part of JDK-8217722. However, my analysis has been somewhat different. Let me try to put it in your terms: 1. This sounds not like a "developer" at all, but either something like a one-shot hobbyist build, or an automated script on a build farm. 2 and 3 I consider the same. As Phil said, even JDK (as in contrast to "hotspot developers") need to tackle native code. And even if they don't, because they are blessed with a native-free module, they will not be hurt by having the binaries build using incremental linking. They will require a quick path to re-building individual modules, and to build an image usable for testing. And contrary, hotspot developers are not hurt by a fast java compilation path, and they too require a fast path to re-building an image used for testing. I'm also thinking like this: Category 1 will either be a script, which much likely already has a long and complicated configure command line; or it is a one-shot hobbyist build, where you are probably already copy-pasting configure options from the readme file, or instructions on the Internet. Category 2/3 will be creating new clones left and right, constantly rerunning configure from the command line. With this in mind, I'm proposing to make the default friendly to category 2/3, rather than 1. Scripts can easily be updated; and the hobbyist builder will need to bother with an extra argument (or possibly, they don't care). Names are tricky, though. I'm thinking maybe --with-build-mode=, --with-defaults or --with-preset. They all carry a slightly different meaning. And while category 2/3 has the relatively obvious name "develop" (or "developer"), category 1 is harder. Perhaps "release" (but that can be misinterpreted as being part of the debug/release dichotomy). Maybe somthing like "ci", "system" or "buildfarm" -- but while that comes out nicely for the build scripts, it sound odd to the hobbyist builder. If I go with --with-preset or --with-defaults, then perhaps "build" would be a suitable choice: --with-preset=develop or --with-preset=build; has a nice ring to it. And finally, I'm also thinking about "extending" the latter category into a "strict" mode, which is what we try to achieve in our CI builds in Oracle. In strict mode, configure would not pick anything up automatically from the environment, but instead all prereqs (*possibly* excluding basic unix tools, but I'm not even sure about that) would need to be pointed out by configure options. /Magnus From magnus.ihse.bursie at oracle.com Fri Jan 25 21:39:40 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Jan 2019 22:39:40 +0100 Subject: Failure at rung of get_source on windows with cygwin In-Reply-To: <26d61a8225e24836a46c6e333236d779@phx-exmbprd-02.adprod.bmc.com> References: <26d61a8225e24836a46c6e333236d779@phx-exmbprd-02.adprod.bmc.com> Message-ID: On 2019-01-25 22:12, Simonovsky, Pavel wrote: > Hi. > I am attempting to build Open jdk 8u from sources. > At Linux (RH6 it worked smoothly. > At windows I am trying to build using Cygwin version 2.8... > > I am failing at windows build on step of running get_source.sh: > > nashorn: abort: stream ended unexpectedly (got 1297 bytes, expected 192443) > jaxws: abort: stream ended unexpectedly (got 1957 bytes, expected 21072) > jaxp: rollback completed > hotspot: abort: stream ended unexpectedly (got 99623 bytes, expected 483101) > jaxp: abort: stream ended unexpectedly (got 28110 bytes, expected 37505) > langtools: transaction abort! > langtools: rollback completed > langtools: abort: stream ended unexpectedly (got 810 bytes, expected 2288) > WARNING: /tmp/forest.34500/hotspot.pid.rc exited abnormally. > WARNING: /tmp/forest.34500/jaxp.pid.rc exited abnormally. > WARNING: /tmp/forest.34500/jaxws.pid.rc exited abnormally. > WARNING: /tmp/forest.34500/langtools.pid.rc exited abnormally. > WARNING: /tmp/forest.34500/nashorn.pid.rc exited abnormally. > > I have enough disk space: > > $ df -k . > Filesystem 1K-blocks Used Available Use% Mounted on > C: 248548552 191203664 57344888 77% /cygdrive/c > > And fast network connection. > What have I to do to troubleshoot this problem? It sounds like the unfortunately well-known problems of underperforming mercurial server at hg.openjdk.java.net, combined with some issues with mercurial running on cygwin. :-( The only advice I can give is to keep re-trying. Eventually you will get a clone, and subsequent operations will go smoother. If you have a forest on a local linux machine, try starting by making a clone manually from that one. (You'll need to clone each repo individually.) /Magnus From alexandre.iline at oracle.com Fri Jan 25 23:20:40 2019 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 25 Jan 2019 15:20:40 -0800 Subject: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov Message-ID: Hi, Please take a look on a change to allow JCov test execution through jib. Please notice that this fix also changes behavior of RunTest.gmk when conflicting combination of options is used. JCOV_IMAGE_DIR is now expected to be set when TEST_OPTS_JCOV is true. Shura Bug: https://bugs.openjdk.java.net/browse/JDK-8217761 Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/ From mandy.chung at oracle.com Sat Jan 26 00:06:42 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 25 Jan 2019 16:06:42 -0800 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> Message-ID: <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com> Hi Severin, Another alternative would be to support per-jlink-plugin resource bundle to avoid merging .properties files at build time.? The plugin-specific messages should only be used by the plugin itself and it would be cleaner for each plugin to manage its resource bundle. Mandy On 1/25/19 7:27 AM, Severin Gehwolf wrote: > Hi, > > I'm working on an enhancement for jlink. In particular a platform > specific plugin. I.e. It would only get built on unix/linux platforms. > My trouble is getting some resouce properties set up properly. In my > example there is two versions of plugins.properties: one in > shared/classes one in unix/classes. These, need to get merged into one > via the MergeProperties build tool class. So far so good. But for the > cases where there is only one resource property it should just get > copied to support/gensrc and that source root be used for compiling > those properties into actual ListResourceBundle Java classes. > > The copying from the src tree to the gensrc tree doesn't seem to work. > I've tried using $(CP) and SetupCopyFiles to no avail. Would anybody > willing to help? > > WIP webrev is: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/01/webrev/ > > I thought I'd do the copying in an else branch in SetupPropertiesMerge, > where I've put in a FIXME comment. Am I on the wrong track? > > Thanks, > Severin > From shade at redhat.com Sat Jan 26 10:02:59 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 26 Jan 2019 11:02:59 +0100 Subject: Failure at rung of get_source on windows with cygwin In-Reply-To: References: <26d61a8225e24836a46c6e333236d779@phx-exmbprd-02.adprod.bmc.com> Message-ID: <3161eb0c-5534-f7e5-fa46-4eef0f73ae8d@redhat.com> On 1/25/19 10:39 PM, Magnus Ihse Bursie wrote: > On 2019-01-25 22:12, Simonovsky, Pavel wrote: >> I am failing at windows build on step of running get_source.sh: >> >> ?????????????? nashorn:?? abort: stream ended unexpectedly (got 1297 bytes, expected 192443) >> ???????????????? jaxws:?? abort: stream ended unexpectedly (got 1957 bytes, expected 21072) >> ????????????????? jaxp:?? rollback completed >> ?????????????? hotspot:?? abort: stream ended unexpectedly (got 99623 bytes, expected 483101) >> ????????????????? jaxp:?? abort: stream ended unexpectedly (got 28110 bytes, expected 37505) >> ???????????? langtools:?? transaction abort! >> ???????????? langtools:?? rollback completed >> ???????????? langtools:?? abort: stream ended unexpectedly (got 810 bytes, expected 2288) >> WARNING: /tmp/forest.34500/hotspot.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/jaxp.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/jaxws.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/langtools.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/nashorn.pid.rc exited abnormally. >> >> I have enough disk space: >> >> $ df -k . >> Filesystem???? 1K-blocks????? Used Available Use% Mounted on >> C:???????????? 248548552 191203664? 57344888? 77% /cygdrive/c >> >> And fast network connection. >> What have I to do to troubleshoot this problem? > It sounds like the unfortunately well-known problems of underperforming mercurial server at > hg.openjdk.java.net, combined with some issues with mercurial running on cygwin. :-( > > The only advice I can give is to keep re-trying. Eventually you will get a clone, and subsequent > operations will go smoother. If you have a forest on a local linux machine, try starting by making a > clone manually from that one. (You'll need to clone each repo individually.) Or take this, Pavel: https://builds.shipilev.net/workspaces/ -Aleksey From aph at redhat.com Sat Jan 26 10:18:28 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 26 Jan 2019 10:18:28 +0000 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <7b842e3a-d512-736a-affc-eaa5cff81526@redhat.com> Message-ID: <1a8bd51c-5b05-e375-cdda-ce3d642185b7@redhat.com> On 1/25/19 6:43 PM, Martin Buchholz wrote: > repeating my last experiment with explicit --threads: Weird, so you don't get the same performance improvement with threads that I do. You have fewer cores, maybe? My tests were with 8 and 48, respectively. I'm also seeing more than a factor of 2 speedup from bfd to gold. But never mind: choice is good. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sat Jan 26 13:55:36 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 26 Jan 2019 13:55:36 +0000 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <9e907e73-fd27-deea-da8a-05be4fd6c9f7@redhat.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <666d7045-a72d-fc6f-d70b-f4b88ce6b180@redhat.com> <9e907e73-fd27-deea-da8a-05be4fd6c9f7@redhat.com> Message-ID: <19a78e58-9b5e-d774-ea8d-ff70aa4c95eb@redhat.com> On 1/25/19 3:39 PM, Andrew Haley wrote: > On 1/25/19 2:39 PM, Andrew Haley wrote: >> Massive win for gold here, on my (very old) AArch64 system: > > And on another, faster AArch64 system: > > BFD linker: > > real 0m14.532s > user 0m13.070s > sys 0m1.419s > > gold, single-threaded: > > real 0m6.313s > user 0m6.123s > sys 0m0.190s > > gold, multi-threaded: > > real 0m4.129s > user 0m8.724s > sys 0m1.741s > > Verdict: yes, please! I couldn't get lld to work with any of the tools I have installed. So I built a bleeding-edge gcc and lld, and I got: lld, single-threaded real 0m3.269s user 0m3.049s sys 0m0.221s lld, multi-threaded: real 0m1.213s user 0m4.336s sys 0m0.960s Which is faster by a factor of 12! It'll be a while before this is installed everywhere, but worth having. Effectively it makes linking go away as a major component of build time. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From bsrbnd at gmail.com Sat Jan 26 15:47:48 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 26 Jan 2019 16:47:48 +0100 Subject: test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java failing with -XX:+UseShenandoahGC on x86_64 Message-ID: Hi, Maybe you're already aware of this failing test, but it seems that -XX:+UnlockExperimentalVMOptions is necessary with -XX:+UseShenandoahGC as here under. Regards, Bernard diff --git a/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java b/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java --- a/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java +++ b/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -63,7 +63,7 @@ testCompressedOopsModes(args, "-XX:+UseParallelGC"); testCompressedOopsModes(args, "-XX:+UseParallelOldGC"); if (GC.Shenandoah.isSupported()) { - testCompressedOopsModes(args, "-XX:+UseShenandoahGC"); + testCompressedOopsModes(args, "-XX:+UnlockExperimentalVMOptions", "-XX:+UseShenandoahGC"); } } From martinrb at google.com Sat Jan 26 16:59:05 2019 From: martinrb at google.com (Martin Buchholz) Date: Sat, 26 Jan 2019 08:59:05 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <19a78e58-9b5e-d774-ea8d-ff70aa4c95eb@redhat.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <666d7045-a72d-fc6f-d70b-f4b88ce6b180@redhat.com> <9e907e73-fd27-deea-da8a-05be4fd6c9f7@redhat.com> <19a78e58-9b5e-d774-ea8d-ff70aa4c95eb@redhat.com> Message-ID: Another, more productionized, version of my benchmark: processors=12 g++ (Debian 7.3.0-5) 7.3.0 --- -fuse-ld=bfd --- 6.559 user 1.180 system 7.740 total --- -fuse-ld=gold --- 4.575 user 0.600 system 5.176 total --- -fuse-ld=gold -Wl,-threads --- 9.355 user 5.062 system 4.289 total --- -fuse-ld=lld --- 2.700 user 1.058 system 1.157 total --- -fuse-ld=lld -Wl,-threads --- 2.572 user 1.128 system 1.107 total #!/bin/bash set -eu echo processors=$(nproc) read -a CMDLINE < $(find . -name BUILD_LIBJVM_link.cmdline -print) readonly DRIVER="${CMDLINE[0]}" "$DRIVER" --version | head -1 benchmark() { echo --- "$@" --- local -r TIMEFORMAT="%U user %S system %R total" time "$DRIVER" "$@" "${CMDLINE[@]:1}" } benchmark -fuse-ld=bfd benchmark -fuse-ld=gold benchmark -fuse-ld=gold -Wl,-threads benchmark -fuse-ld=lld benchmark -fuse-ld=lld -Wl,-threads From Alan.Bateman at oracle.com Sun Jan 27 08:14:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Jan 2019 08:14:33 +0000 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com> References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com> Message-ID: <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com> On 26/01/2019 00:06, Mandy Chung wrote: > Hi Severin, > > Another alternative would be to support per-jlink-plugin resource > bundle to avoid merging .properties files at build time.? The > plugin-specific messages should only be used by the plugin itself > and it would be cleaner for each plugin to manage its resource bundle. That seems a cleaner idea than the suggestion we had on jigsaw-dev to merge the properties. If Severin does this for this plugin then I assume the resources for the other plugins could be moved to their own resource files in their own time. I skimmed the current patch and I see the usability has improved since the original proposal. It would be nice to get to `--strip-native-debug-symbols` without needing the "=defaults" suffix.? There are details around the sub-options and naming that I assume will need detailed review at some point too. The current patch doesn't include any tests but I assume they will come in time. There's probably a cleanup in StripNativeDebugSymbolsPlugin.java needed too to make it easier to maintain and review going forward but that is not important now, I think the main thing is to get past the issue of being the first plugin that is platform specific. -Alan. From Pavel_Simonovsky at bmc.com Sun Jan 27 08:36:48 2019 From: Pavel_Simonovsky at bmc.com (Simonovsky, Pavel) Date: Sun, 27 Jan 2019 08:36:48 +0000 Subject: Failure at rung of get_source on windows with cygwin In-Reply-To: <3161eb0c-5534-f7e5-fa46-4eef0f73ae8d@redhat.com> References: <26d61a8225e24836a46c6e333236d779@phx-exmbprd-02.adprod.bmc.com> <3161eb0c-5534-f7e5-fa46-4eef0f73ae8d@redhat.com> Message-ID: <45cf2de3fde34be3b6b43cfae585fe6e@phx-exmbprd-02.adprod.bmc.com> 10x a lot. Will try it. I was looking for something like that - kind of tar ball with whole source... -----Original Message----- From: Aleksey Shipilev [mailto:shade at redhat.com] Sent: Saturday, January 26, 2019 12:03 PM To: Magnus Ihse Bursie ; Simonovsky, Pavel ; build-dev at openjdk.java.net Subject: Re: Failure at rung of get_source on windows with cygwin On 1/25/19 10:39 PM, Magnus Ihse Bursie wrote: > On 2019-01-25 22:12, Simonovsky, Pavel wrote: >> I am failing at windows build on step of running get_source.sh: >> >> ?????????????? nashorn:?? abort: stream ended unexpectedly (got 1297 >> bytes, expected 192443) >> ???????????????? jaxws:?? abort: stream ended unexpectedly (got 1957 >> bytes, expected 21072) >> ????????????????? jaxp:?? rollback completed >> ?????????????? hotspot:?? abort: stream ended unexpectedly (got 99623 >> bytes, expected 483101) >> ????????????????? jaxp:?? abort: stream ended unexpectedly (got 28110 >> bytes, expected 37505) >> ???????????? langtools:?? transaction abort! >> ???????????? langtools:?? rollback completed >> ???????????? langtools:?? abort: stream ended unexpectedly (got 810 >> bytes, expected 2288) >> WARNING: /tmp/forest.34500/hotspot.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/jaxp.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/jaxws.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/langtools.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/nashorn.pid.rc exited abnormally. >> >> I have enough disk space: >> >> $ df -k . >> Filesystem???? 1K-blocks????? Used Available Use% Mounted on >> C:???????????? 248548552 191203664? 57344888? 77% /cygdrive/c >> >> And fast network connection. >> What have I to do to troubleshoot this problem? > It sounds like the unfortunately well-known problems of > underperforming mercurial server at hg.openjdk.java.net, combined with > some issues with mercurial running on cygwin. :-( > > The only advice I can give is to keep re-trying. Eventually you will > get a clone, and subsequent operations will go smoother. If you have a > forest on a local linux machine, try starting by making a clone > manually from that one. (You'll need to clone each repo individually.) Or take this, Pavel: https://builds.shipilev.net/workspaces/ -Aleksey From matthias.baesken at sap.com Mon Jan 28 08:03:36 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 28 Jan 2019 08:03:36 +0000 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> Message-ID: Hello, seems 8214533 got pushed recently into jdk/jdk. Now we see build errors on AIX , are they related to this change ? /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: error: Decoder is not public in EUC_JP; cannot be accessed from outside package private static class Decoder extends EUC_JP.Decoder { ^ /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: error: Encoder is not public in EUC_JP; cannot be accessed from outside package private static class Encoder extends EUC_JP.Encoder { ^ /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: error: Decoder is not public in EUC_JP; cannot be accessed from outside package private static class Decoder extends EUC_JP.Decoder { ^ /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: error: Encoder is not public in EUC_JP; cannot be accessed from outside package private static class Encoder extends EUC_JP.Encoder { Best regards, Matthias > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Ichiroh Takiguchi > Sent: Dienstag, 15. Januar 2019 01:51 > To: Alan Bateman > Cc: build-dev ; ppc-aix-port-dev port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default charset > > Hello Alan. > > Could you review the fix again ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 > Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ > > I added IBM29626C charset as standard way. > Please give any suggestion and question. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > > Hello Alan. > > > > I opened JDK-8215333 for Charset filtering issue [1]. > > I cannot wait until JDK-8215333 is closed. > > Is it possible to put IBM-29626C charset with standard way ? > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > > > > Thanks, > > Ichiroh Takiguchi > > > > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > >> Hello Roger, Magnus and Alan. > >> I may need to put alias information into charsets file. > >> stdcs-xxx cannot handle this information... > >> > >> Still AIX needs IBM-29626C charset for default encoding... > >> > >> I appreciate if you give me further suggestions. > >> > >> Thanks, > >> Ichiroh Takiguchi > >> > >> On 2018-12-10 20:50, Alan Bateman wrote: > >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > >>>> On 2018-12-07 21:20, Roger Riggs wrote: > >>>>> Hi, > >>>>> > >>>>> It is a nice feature that charsets are selected at build time using > >>>>> the stdcs-xxx files. > >>>>> This change breaks that pattern and embeds os specific information > >>>>> in more than one place. > >>>>> That does not seem like an improvement.? Is there any alternative? > >>>> I agree. Why is it not enough just to add it to stdcs-aix? > >>> My reading of the patch is that the "os" key is to avoid generating > >>> it > >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on > >>> non-AIX platforms. The general direction is welcome but I think > >>> further work and discussion will be needed to get the right set of > >>> changes to support filtering in the build. It can probably be > >>> separated from the changes to add IBM-29626C to AIX's java.base. > >>> > >>> -Alan From aoqi at loongson.cn Mon Jan 28 08:25:23 2019 From: aoqi at loongson.cn (Ao Qi) Date: Mon, 28 Jan 2019 16:25:23 +0800 Subject: Fail to cross compiling jdk12 for mips64el-linux-gnu target In-Reply-To: <71ce8229-09ef-e819-2dc0-d4e37f663c97@oracle.com> References: <2da63f6b-86a7-716e-96e8-7f0924a19c07@loongson.cn> <10292eb2-26c1-d879-0b79-a5a2fed63bb9@oracle.com> <3c7f1634-ea65-80a6-21c9-c2913d88e4f8@oracle.com> <812ecd35-1d83-9507-5420-38c87bdd29d9@oracle.com> <4e47b28c-8aa7-2bba-1ff9-e164ec81485f@loongson.cn> <71ce8229-09ef-e819-2dc0-d4e37f663c97@oracle.com> Message-ID: Hi Magnus, On Fri, Jan 25, 2019 at 10:18 PM Magnus Ihse Bursie wrote: > > On 2019-01-25 02:47, Leslie Zhai wrote: > > Hi Magnus, > > > > Failed to make images: > > > > $ make images CONF=mips > > Building target 'images' in configuration > > 'linux-mips64el-normal-server-fastdebug' > > GenerateLinkOptData.gmk:61: recipe for target > > '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' > > failed > > make[3]: *** > > [/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist] > > Error 1 > > make[3]: *** Deleting file > > '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' > > make/Main.gmk:441: recipe for target 'generate-link-opt-data' failed > > make[2]: *** [generate-link-opt-data] Error 2 > > This should have worked, but sounds like something that can typically > fail when cross-compiling. As a workaround, disable class list > generation: "configure --disable-generate-classlist", or even "configure > --disable-cds". > I tried mips zero of http://hg.openjdk.java.net/jdk/jdk using your approach of buildjdk [1]. "make images" succeeded and javac (to test open a file) worked on a mips machine. I tried the same approach to build our jdk-mips, it failed. Then I used "configure --disable-generate-classlist --disable-cds ...", "make images" succeeded and javac worked on a mips machine. I think your approach solved our problem! Thanks a lot, Magnus! Cheers, Ao Qi [1] https://mail.openjdk.java.net/pipermail/build-dev/2019-January/024735.html > /Magnus > > > > ERROR: Build failed for target 'images' in configuration > > 'linux-mips64el-normal-server-fastdebug' (exit code 2) > > > > === Make failed targets repeated here === > > GenerateLinkOptData.gmk:61: recipe for target > > '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' > > failed > > make/Main.gmk:441: recipe for target 'generate-link-opt-data' failed > > === End of repeated output === > > > > Hint: Try searching the build log for the name of the first failed > > target. > > Hint: See doc/building.html#troubleshooting for assistance. > > > > /home/loongson/zhaixiang/jdk12-mips/make/Init.gmk:300: recipe for > > target 'main' failed > > make[1]: *** [main] Error 2 > > /home/loongson/zhaixiang/jdk12-mips/make/Init.gmk:186: recipe for > > target 'images' failed > > make: *** [images] Error 2 > > > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > > > My cross-compile configure option: > > > > CC=mips64el-linux-gnuabi64-gcc CXX=mips64el-linux-gnuabi64-g++ sh > > ./configure \ > > --openjdk-target=mips64el-linux-gnuabi64 \ > > --with-sysroot=/chroots/mips64el_stretch \ > > --with-toolchain-path=/chroots/mips64el_stretch \ > > --with-boot-jdk=/home/loongson/aoqi/jdk-11.0.1 \ > > --disable-warnings-as-errors \ > > --with-freetype-lib=/chroots/mips64el_stretch/usr/lib/mips64el-linux-gnuabi64 > > \ > > --with-freetype-include=/chroots/mips64el_stretch/usr/include/freetype2 \ > > --with-debug-level=fastdebug \ > > --with-build-jdk=build/buildjdk/jdk > > > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > > > buildjdk is OK: > > > > $ sh configure --with-conf-name=buildjdk > > --with-boot-jdk=/home/loongson/aoqi/jdk-11.0.1 > > --disable-warnings-as-errors > > > > $ make jdk CONF=buildjdk > > > > Building target 'jdk' in configuration 'buildjdk' > > Finished building target 'jdk' in configuration 'buildjdk' > > > > Regards, > > > > Leslie Zhai > > > > > > ? 2019/1/24 ??9:30, Magnus Ihse Bursie ??: > >> On 2019-01-24 13:22, Leslie Zhai wrote: > >>> Hi Magnus, > >>> > >>> Thanks for your kind response! > >>> > >>> ? 2019/1/24 ??8:05, Magnus Ihse Bursie ??: > >>>> > >>>> > >>>> On 2019-01-24 05:45, David Holmes wrote: > >>>>> On 24/01/2019 1:51 pm, Ao Qi wrote: > >>>>>> Hi David, > >>>>>> > >>>>>> On Thu, Jan 24, 2019 at 10:47 AM David Holmes > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi Leslie, > >>>>>>> > >>>>>>> I'm not Erik :) however .... > >>>>>>> > >>>>>>> On 24/01/2019 12:28 pm, Leslie Zhai wrote: > >>>>>>>> Hi Erik, > >>>>>>>> > >>>>>>>> Because the flags' macro of MIPS is different from other > >>>>>>>> targets[1], it > >>>>>>>> will effect the `UnixConstants` of > >>>>>>>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, > >>>>>>>> for > >>>>>>>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is > >>>>>>>> different > >>>>>>>> from other targets. Then failed[2] to cross compiling jdk12 for > >>>>>>>> mips64el-linux-gnu target by following the document[3]. > >>>>>>> > >>>>>>> It's been quite a while since we built for a platform where the > >>>>>>> flags > >>>>>>> had different values, but it is supposed to work. I suspect that > >>>>>>> the way > >>>>>>> we build now with the module system may not be quite correct in > >>>>>>> this > >>>>>>> regard - but that is just supposition on my part. Because > >>>>>>> compile-time > >>>>>>> constants are stored directly into class files that use them, we > >>>>>>> have to > >>>>>>> generate UnixConstants.java before compiling any class that > >>>>>>> needs to use > >>>>>>> it, then we must compile all classes that do use it. Those > >>>>>>> classes must > >>>>>>> only be executed in conjunction with a tool executing on the target > >>>>>>> platform (javac, jmod etc). My suspicion is that we may be > >>>>>>> executing a > >>>>>>> tool on the build platform using the newly compiled classes for the > >>>>>>> target platform - and that would be wrong. > >>>>>>> > >>>>>> > >>>>>> Yes. Some variables in UnixConstants.java is defined according to > >>>>>> the > >>>>>> target (fcntl.h of mips in this case), but would be executed on host > >>>>>> (x86 in this case) during "make images". These variables of ppc64le, > >>>>>> aarch64 and s390x are the same as x86, but the ones of mips are not. > >>>>>> However, mips is not an official supported target and I did not find > >>>>>> other targets have similar issue, I am not sure if this is a bug > >>>>>> or if > >>>>>> this is the right mailing list :) > >>>>> > >>>>> This is the right mailing list to discuss. :) > >>>>> > >>>>> So I went back to find when this happened in the past and I > >>>>> mis-remembered how we solved it. We previously had a problem with > >>>>> the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 > >>>>> platforms defined a different value for the O_NOFOLLOW and > >>>>> O_DIRECT flags. The solution then was to commit a platform > >>>>> specific version of UnixConstants.java and change the build system > >>>>> to only use the template file if there was not a pre-existing > >>>>> .java file. But that platform and the SE Embedded support was all > >>>>> removed. (SocketOptions.java had a similar problem.) Further that > >>>>> build logic is completely different to what we had back then (JDK > >>>>> 6/7). > >>>>> > >>>>> This is definitely a bug in our build logic IMHO as we > >>>>> specifically use the build platform c-pre-processor to process the > >>>>> template file based on the target header files, but then use the > >>>>> resulting class when running tools on the build platform. > >>>> I agree with David. This is a bug in the build system; arguably > >>>> even a regression. > >>>> > >>>>> This was not something that happened in 6/7 or even 8 and I think > >>>>> the module system tools are where the issue now lies. > >>>>> > >>>>> I think Erik and/or Magnus will have to give advice on how this > >>>>> may be properly fixed. I can't see any simple solution. > >>>> Unfortunately, I also agree that there is no simple solution. :-( > >>>> > >>>> The proper way to handle this is to generate two versions of > >>>> UnixConstants and friends, one for the build platform, and one for > >>>> the target platform. But as far as I know, there is no simple way > >>>> to handle such complications in our current structure. Erik knows > >>>> more about this, he was the one who designed the current solution > >>>> for handling cross-compilation in the modularized world. > >>>> > >>>> However, I can at least help you with a relatively simple > >>>> workaround. First some background: When we cross-compile, we need > >>>> not only a Boot JDK (of version current N-1) running on the build > >>>> host platform, but we also need a Build JDK, based on the current > >>>> source code, running on the build host. (This is for running > >>>> jmod/jlink; it needs to be up to date). If we have no Build JDK > >>>> present, we start by creating one ourselves. This is more or less > >>>> the same output as running a normal, non-cross compiled, build on > >>>> the build host. (But Erik found some ways to cut a few corners to > >>>> save time.) Your problem is that the Build JDK is broken, since > >>>> UnixConstants has the wrong values. > >>>> - > >>>> But you can supply your own working Build JDK to configure! > >>>> > >>>> So, your workflow for cross-compiling to MIPS should be: > >>>> 1) create a Build JDK, e.g. like this: "bash configure > >>>> --with-conf-name=buildjdk && make jdk CONF=buildjdk" > >>>> 2) create your cross-compilation JDK like this: "bash configure > >>>> --openjdk-target=mipsel-unknown-linux-gnu > >>>> --with-build-jdk=build/buildjdk/jdk" > >>>> ... or something like that. > >>>> Then you can build your cross-compiled jdk with "make images > >>>> CONF=mips". > >>> > >>> I will try that, thanks a lot for your teaching! > >> Please let me know if it works. I wrote the command lines out of my > >> head, so they might need some tweaking to get right. > >> > >> Perhaps this is an acceptable solution to you? Unless Erik can > >> suggest ways to fix this properly that is not too complicated, maybe > >> this can be a good enough solution for you? (But if there is a simple > >> solution, I'd rather have it fixed properly.) > >> > >> /Magnus > >>> > >>> Regards, > >>> > >>> Leslie Zhai > >>> > >>> > >>>> > >>>> > >>>> In theory, you should rebuild your buildjdk for each and every > >>>> change ("make jdk CONF=buildjdk && make images CONF=mips"); but in > >>>> reality, I don't believe there is really any need to rebuild the > >>>> buildjdk (unless major changes in jlink/jmod happens). > >>>> > >>>> /Magnus > >>>>> > >>>>> David > >>>>> ----- > >>>>> > >>>>>> For example: > >>>>>> > >>>>>> jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND > >>>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>>> > >>>>>> static final int O_APPEND = > >>>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> 02000 > >>>>>> -- > >>>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>>> > >>>>>> static final int O_APPEND = > >>>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> 02000 > >>>>>> -- > >>>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>>> > >>>>>> static final int O_APPEND = > >>>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> 02000 > >>>>>> -- > >>>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>>> > >>>>>> static final int O_APPEND = > >>>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> 02000 > >>>>>> -- > >>>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>>> > >>>>>> static final int O_APPEND = > >>>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> 02000 > >>>>>> -- > >>>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>>> > >>>>>> static final int O_APPEND = > >>>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> 0x0008 > >>>>>> -- > >>>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java: > >>>>>> > >>>>>> static final int O_APPEND = > >>>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- > >>>>>> > >>>>>> 02000 > >>>>>> > >>>>>> log.mips:2of path: > >>>>>> /home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp > >>>>>> > >>>>>> oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024 > >>>>>> log.ppc:2of path: > >>>>>> /home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp > >>>>>> > >>>>>> oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128 > >>>>>> > >>>>>> Cheers, > >>>>>> Ao Qi > >>>>>> > >>>> > >>> > >> > > > From sgehwolf at redhat.com Mon Jan 28 09:22:49 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 28 Jan 2019 10:22:49 +0100 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <1a11e808-8df1-8c85-8beb-6a0a0061217b@oracle.com> References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> <1a11e808-8df1-8c85-8beb-6a0a0061217b@oracle.com> Message-ID: On Fri, 2019-01-25 at 17:55 +0100, Magnus Ihse Bursie wrote: > > > On 2019-01-25 16:27, Severin Gehwolf wrote: > > Hi, > > > > I'm working on an enhancement for jlink. In particular a platform > > specific plugin. I.e. It would only get built on unix/linux > > platforms. > > My trouble is getting some resouce properties set up properly. In > > my > > example there is two versions of plugins.properties: one in > > shared/classes one in unix/classes. These, need to get merged into > > one > > via the MergeProperties build tool class. So far so good. But for > > the > > cases where there is only one resource property it should just get > > copied to support/gensrc and that source root be used for compiling > > those properties into actual ListResourceBundle Java classes. > > > > The copying from the src tree to the gensrc tree doesn't seem to > > work. > > I've tried using $(CP) and SetupCopyFiles to no avail. Would > > anybody > > willing to help? > SetupCopyFile should work, but in this case I think it's simplest to > just use install-file. Like this perhaps: > > ifneq ($$($1_NUM_INPUT_FILES), 1) > $$($1_TARGET): $$($1_INPUT_FILES) > $$(call LogInfo, Merging $$($1_NUM_INPUT_FILES) properties > files into a single properties file for jdk.jlink) > $(TOOL_MERGE_PROPERTIES) \ > $(GENERATED_JLINK_RESOURCES_DIR)/$$($1_PROP).properties > \ > $$($1_INPUT_FILES) > else > $$($1_TARGET): $$($1_INPUT_FILES) > $$(install-file) > endif > > $1 += $$($1_TARGET) > > /Magnus Thanks, Magnus! Cheers, Severin From sgehwolf at redhat.com Mon Jan 28 09:24:13 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 28 Jan 2019 10:24:13 +0100 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> Message-ID: On Fri, 2019-01-25 at 09:17 -0800, Erik Joelsson wrote: > Hello Severin, > To get the conditional running of either MergeProperties or copy, I > would do something like this: > $$($1_TARGET): $$($1_DEPS) > $$(call MakeTargetDir) > ifneq ($$($1_NUM_INPUT_FILES),1) > $$(call LogInfo, Merging $$(words $$($1_INPUT_FILES)) > properties files into a single properties file for jdk.jlink) > $(TOOL_MERGE_PROPERTIES) \ > $(GENERATED_JLINK_RESOURCES_DIR)/$$($1_PROP).properties > \ > $$($1_INPUT_FILES) > else > $$(call LogInfo, Copying $$(patsubst > $(OUTPUTDIR)/%,%,$$@))) > $$(call install-file) > endif > > $1 := $$($1_TARGET) > > Note that the make conditional lines need to be indented with space > while the recipe lines (including the $$(call )) needs to be tabbed. > We still like them to align though, assuming 8 spaces tabs. > Down in the call loop, the first argument to SetupPropertiesMerge > must be unique. This can be achieved with MERGE_JLINK_PROPS_$(prop). > Then add a line like this last in the loop: > $(eval TARGETS += $(MERGE_JLINK_PROPS_$(prop))) > To find all the src dirs for the jlink module, there are helper > macros in make/common/Modules.gmk. > JLINK_RESOURCE_DIRS := $(addsuffix /jdk/tools/jlink/resources, $(call > FindModuleSrcDirs, jdk.jlink)) > In the loop I would recommend reusing the already built list of all > properties files instead of calling find again. Also, if all > properties files in the resource dir are in the same directory with > no sub directories, then please consider using $(wildcard ) to find > them as that's much less taxing on Windows. > Hope this helps! > /Erik OK. Thanks very much! Looks like this might not be needed after all. Cheers, Severin > On 2019-01-25 07:27, Severin Gehwolf wrote: > > Hi, > > > > I'm working on an enhancement for jlink. In particular a platform > > specific plugin. I.e. It would only get built on unix/linux > > platforms. > > My trouble is getting some resouce properties set up properly. In > > my > > example there is two versions of plugins.properties: one in > > shared/classes one in unix/classes. These, need to get merged into > > one > > via the MergeProperties build tool class. So far so good. But for > > the > > cases where there is only one resource property it should just get > > copied to support/gensrc and that source root be used for compiling > > those properties into actual ListResourceBundle Java classes. > > > > The copying from the src tree to the gensrc tree doesn't seem to > > work. > > I've tried using $(CP) and SetupCopyFiles to no avail. Would > > anybody > > willing to help? > > > > WIP webrev is: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/01/webrev/ > > > > I thought I'd do the copying in an else branch in > > SetupPropertiesMerge, > > where I've put in a FIXME comment. Am I on the wrong track? > > > > Thanks, > > Severin > > From sgehwolf at redhat.com Mon Jan 28 09:26:39 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 28 Jan 2019 10:26:39 +0100 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com> References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com> <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com> Message-ID: <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com> Hi Alan, Mandy, On Sun, 2019-01-27 at 08:14 +0000, Alan Bateman wrote: > On 26/01/2019 00:06, Mandy Chung wrote: > > Hi Severin, > > > > Another alternative would be to support per-jlink-plugin resource > > bundle to avoid merging .properties files at build time. The > > plugin-specific messages should only be used by the plugin itself > > and it would be cleaner for each plugin to manage its resource bundle. > > That seems a cleaner idea than the suggestion we had on jigsaw-dev to > merge the properties. If Severin does this for this plugin then I assume > the resources for the other plugins could be moved to their own resource > files in their own time. Alright. I'll try this then. > I skimmed the current patch and I see the usability has improved since > the original proposal. It would be nice to get to > `--strip-native-debug-symbols` without needing the "=defaults" suffix. > There are details around the sub-options and naming that I assume will > need detailed review at some point too. This sounds like a different patch to me, I'll investigate. > The current patch doesn't include any tests but I assume they will come > in time. Sure. Thanks, Severin > There's probably a cleanup in StripNativeDebugSymbolsPlugin.java needed > too to make it easier to maintain and review going forward but that is > not important now, I think the main thing is to get past the issue of > being the first plugin that is platform specific. > > -Alan. From takiguc at linux.vnet.ibm.com Mon Jan 28 13:12:40 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 28 Jan 2019 22:12:40 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> Message-ID: Hello. I'm very sorry. It's my fault. EUC_JP class was moved to java.base module. (sun.nio.cs.EUC_JP). make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and EUC_JP_Open. Could you suggest me how I should provide new webrev files ? Thanks, Ichiroh Takiguchi On 2019-01-28 17:03, Baesken, Matthias wrote: > Hello, seems 8214533 got pushed recently into jdk/jdk. Now > we see build errors on AIX , are they related to this change ? > > > /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: > error: Decoder is not public in EUC_JP; cannot be accessed from > outside package > private static class Decoder extends EUC_JP.Decoder { > ^ > /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: > error: Encoder is not public in EUC_JP; cannot be accessed from > outside package > private static class Encoder extends EUC_JP.Encoder { > ^ > /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: > error: Decoder is not public in EUC_JP; cannot be accessed from > outside package > private static class Decoder extends EUC_JP.Decoder { > ^ > /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: > error: Encoder is not public in EUC_JP; cannot be accessed from > outside package > private static class Encoder extends EUC_JP.Encoder { > > Best regards, Matthias > > > >> -----Original Message----- >> From: ppc-aix-port-dev On >> Behalf Of Ichiroh Takiguchi >> Sent: Dienstag, 15. Januar 2019 01:51 >> To: Alan Bateman >> Cc: build-dev ; ppc-aix-port-dev > port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default >> charset >> >> Hello Alan. >> >> Could you review the fix again ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ >> >> I added IBM29626C charset as standard way. >> Please give any suggestion and question. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >> > Hello Alan. >> > >> > I opened JDK-8215333 for Charset filtering issue [1]. >> > I cannot wait until JDK-8215333 is closed. >> > Is it possible to put IBM-29626C charset with standard way ? >> > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >> > >> > Thanks, >> > Ichiroh Takiguchi >> > >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >> >> Hello Roger, Magnus and Alan. >> >> I may need to put alias information into charsets file. >> >> stdcs-xxx cannot handle this information... >> >> >> >> Still AIX needs IBM-29626C charset for default encoding... >> >> >> >> I appreciate if you give me further suggestions. >> >> >> >> Thanks, >> >> Ichiroh Takiguchi >> >> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >> >>>>> Hi, >> >>>>> >> >>>>> It is a nice feature that charsets are selected at build time using >> >>>>> the stdcs-xxx files. >> >>>>> This change breaks that pattern and embeds os specific information >> >>>>> in more than one place. >> >>>>> That does not seem like an improvement.? Is there any alternative? >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >> >>> My reading of the patch is that the "os" key is to avoid generating >> >>> it >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> >>> non-AIX platforms. The general direction is welcome but I think >> >>> further work and discussion will be needed to get the right set of >> >>> changes to support filtering in the build. It can probably be >> >>> separated from the changes to add IBM-29626C to AIX's java.base. >> >>> >> >>> -Alan From goetz.lindenmaier at sap.com Mon Jan 28 13:11:27 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 28 Jan 2019 13:11:27 +0000 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> Message-ID: <8c05b5147fa7489282d7cae04e801702@sap.com> Hi Ichiroh, just open a bug, like "Fix aix build after 8214533" and post a RFR for it. I assume the fix is quite trivial so we can review it quick. Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Ichiroh Takiguchi > Sent: Montag, 28. Januar 2019 14:13 > To: Baesken, Matthias > Cc: build-dev ; ppc-aix-port-dev dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman > > Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default charset > > Hello. > > I'm very sorry. It's my fault. > EUC_JP class was moved to java.base module. > (sun.nio.cs.EUC_JP). > > make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and > EUC_JP_Open. > > Could you suggest me how I should provide new webrev files ? > > Thanks, > Ichiroh Takiguchi > > > On 2019-01-28 17:03, Baesken, Matthias wrote: > > Hello, seems 8214533 got pushed recently into jdk/jdk. Now > > we see build errors on AIX , are they related to this change ? > > > > > > /nb/rs6000_64/nightly/output-jdk- > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: > > error: Decoder is not public in EUC_JP; cannot be accessed from > > outside package > > private static class Decoder extends EUC_JP.Decoder { > > ^ > > /nb/rs6000_64/nightly/output-jdk- > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: > > error: Encoder is not public in EUC_JP; cannot be accessed from > > outside package > > private static class Encoder extends EUC_JP.Encoder { > > ^ > > /nb/rs6000_64/nightly/output-jdk- > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: > > error: Decoder is not public in EUC_JP; cannot be accessed from > > outside package > > private static class Decoder extends EUC_JP.Decoder { > > ^ > > /nb/rs6000_64/nightly/output-jdk- > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: > > error: Encoder is not public in EUC_JP; cannot be accessed from > > outside package > > private static class Encoder extends EUC_JP.Encoder { > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: ppc-aix-port-dev On > >> Behalf Of Ichiroh Takiguchi > >> Sent: Dienstag, 15. Januar 2019 01:51 > >> To: Alan Bateman > >> Cc: build-dev ; ppc-aix-port-dev >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net > >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default > >> charset > >> > >> Hello Alan. > >> > >> Could you review the fix again ? > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 > >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ > >> > >> I added IBM29626C charset as standard way. > >> Please give any suggestion and question. > >> > >> Thanks, > >> Ichiroh Takiguchi > >> IBM Japan, Ltd. > >> > >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > >> > Hello Alan. > >> > > >> > I opened JDK-8215333 for Charset filtering issue [1]. > >> > I cannot wait until JDK-8215333 is closed. > >> > Is it possible to put IBM-29626C charset with standard way ? > >> > > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > >> > > >> > Thanks, > >> > Ichiroh Takiguchi > >> > > >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > >> >> Hello Roger, Magnus and Alan. > >> >> I may need to put alias information into charsets file. > >> >> stdcs-xxx cannot handle this information... > >> >> > >> >> Still AIX needs IBM-29626C charset for default encoding... > >> >> > >> >> I appreciate if you give me further suggestions. > >> >> > >> >> Thanks, > >> >> Ichiroh Takiguchi > >> >> > >> >> On 2018-12-10 20:50, Alan Bateman wrote: > >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: > >> >>>>> Hi, > >> >>>>> > >> >>>>> It is a nice feature that charsets are selected at build time using > >> >>>>> the stdcs-xxx files. > >> >>>>> This change breaks that pattern and embeds os specific information > >> >>>>> in more than one place. > >> >>>>> That does not seem like an improvement.? Is there any alternative? > >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? > >> >>> My reading of the patch is that the "os" key is to avoid generating > >> >>> it > >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on > >> >>> non-AIX platforms. The general direction is welcome but I think > >> >>> further work and discussion will be needed to get the right set of > >> >>> changes to support filtering in the build. It can probably be > >> >>> separated from the changes to add IBM-29626C to AIX's java.base. > >> >>> > >> >>> -Alan From takiguc at linux.vnet.ibm.com Mon Jan 28 13:49:34 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 28 Jan 2019 22:49:34 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <8c05b5147fa7489282d7cae04e801702@sap.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> Message-ID: <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> Hello Goetz. Thank you for your suggestion. I just open JDK-8217880 [1]. I just restart clean build. I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. [1] https://bugs.openjdk.java.net/browse/JDK-8217880 Thanks, Ichiroh Takiguchi On 2019-01-28 22:11, Lindenmaier, Goetz wrote: > Hi Ichiroh, > > just open a bug, like "Fix aix build after 8214533" and post a RFR for > it. > I assume the fix is quite trivial so we can review it quick. > > Best regards, > Goetz. > >> -----Original Message----- >> From: ppc-aix-port-dev On >> Behalf Of Ichiroh Takiguchi >> Sent: Montag, 28. Januar 2019 14:13 >> To: Baesken, Matthias >> Cc: build-dev ; ppc-aix-port-dev >> > dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman >> >> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default >> charset >> >> Hello. >> >> I'm very sorry. It's my fault. >> EUC_JP class was moved to java.base module. >> (sun.nio.cs.EUC_JP). >> >> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and >> EUC_JP_Open. >> >> Could you suggest me how I should provide new webrev files ? >> >> Thanks, >> Ichiroh Takiguchi >> >> >> On 2019-01-28 17:03, Baesken, Matthias wrote: >> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now >> > we see build errors on AIX , are they related to this change ? >> > >> > >> > /nb/rs6000_64/nightly/output-jdk- >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: >> > error: Decoder is not public in EUC_JP; cannot be accessed from >> > outside package >> > private static class Decoder extends EUC_JP.Decoder { >> > ^ >> > /nb/rs6000_64/nightly/output-jdk- >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: >> > error: Encoder is not public in EUC_JP; cannot be accessed from >> > outside package >> > private static class Encoder extends EUC_JP.Encoder { >> > ^ >> > /nb/rs6000_64/nightly/output-jdk- >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: >> > error: Decoder is not public in EUC_JP; cannot be accessed from >> > outside package >> > private static class Decoder extends EUC_JP.Decoder { >> > ^ >> > /nb/rs6000_64/nightly/output-jdk- >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: >> > error: Encoder is not public in EUC_JP; cannot be accessed from >> > outside package >> > private static class Encoder extends EUC_JP.Encoder { >> > >> > Best regards, Matthias >> > >> > >> > >> >> -----Original Message----- >> >> From: ppc-aix-port-dev On >> >> Behalf Of Ichiroh Takiguchi >> >> Sent: Dienstag, 15. Januar 2019 01:51 >> >> To: Alan Bateman >> >> Cc: build-dev ; ppc-aix-port-dev > >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default >> >> charset >> >> >> >> Hello Alan. >> >> >> >> Could you review the fix again ? >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 >> >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ >> >> >> >> I added IBM29626C charset as standard way. >> >> Please give any suggestion and question. >> >> >> >> Thanks, >> >> Ichiroh Takiguchi >> >> IBM Japan, Ltd. >> >> >> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >> >> > Hello Alan. >> >> > >> >> > I opened JDK-8215333 for Charset filtering issue [1]. >> >> > I cannot wait until JDK-8215333 is closed. >> >> > Is it possible to put IBM-29626C charset with standard way ? >> >> > >> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >> >> > >> >> > Thanks, >> >> > Ichiroh Takiguchi >> >> > >> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >> >> >> Hello Roger, Magnus and Alan. >> >> >> I may need to put alias information into charsets file. >> >> >> stdcs-xxx cannot handle this information... >> >> >> >> >> >> Still AIX needs IBM-29626C charset for default encoding... >> >> >> >> >> >> I appreciate if you give me further suggestions. >> >> >> >> >> >> Thanks, >> >> >> Ichiroh Takiguchi >> >> >> >> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >> >> >>>>> Hi, >> >> >>>>> >> >> >>>>> It is a nice feature that charsets are selected at build time using >> >> >>>>> the stdcs-xxx files. >> >> >>>>> This change breaks that pattern and embeds os specific information >> >> >>>>> in more than one place. >> >> >>>>> That does not seem like an improvement.? Is there any alternative? >> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >> >> >>> My reading of the patch is that the "os" key is to avoid generating >> >> >>> it >> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> >> >>> non-AIX platforms. The general direction is welcome but I think >> >> >>> further work and discussion will be needed to get the right set of >> >> >>> changes to support filtering in the build. It can probably be >> >> >>> separated from the changes to add IBM-29626C to AIX's java.base. >> >> >>> >> >> >>> -Alan From Alan.Bateman at oracle.com Mon Jan 28 14:40:44 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Jan 2019 14:40:44 +0000 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com> References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com> <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com> <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com> Message-ID: <7c42f18f-0bc7-7310-9a64-f08e6f305b9e@oracle.com> On 28/01/2019 09:26, Severin Gehwolf wrote: > : >> I skimmed the current patch and I see the usability has improved since >> the original proposal. It would be nice to get to >> `--strip-native-debug-symbols` without needing the "=defaults" suffix. >> There are details around the sub-options and naming that I assume will >> need detailed review at some point too. > This sounds like a different patch to me, I'll investigate. > If the common case is to not require any complicated options then `--strip-native-debug-symbols` would be nice and would be consistent with the existing `--strip-XXXX` options. The cross targeting case, or cases where debuginfo options are need, would of course mean a more complicated command. -Alan From sgehwolf at redhat.com Mon Jan 28 14:54:47 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 28 Jan 2019 15:54:47 +0100 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <7c42f18f-0bc7-7310-9a64-f08e6f305b9e@oracle.com> References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com> <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com> <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com> <7c42f18f-0bc7-7310-9a64-f08e6f305b9e@oracle.com> Message-ID: <58ea39e2849ed3d270a9373d49f75eb75cb57f59.camel@redhat.com> On Mon, 2019-01-28 at 14:40 +0000, Alan Bateman wrote: > On 28/01/2019 09:26, Severin Gehwolf wrote: > > : > > > I skimmed the current patch and I see the usability has improved since > > > the original proposal. It would be nice to get to > > > `--strip-native-debug-symbols` without needing the "=defaults" suffix. > > > There are details around the sub-options and naming that I assume will > > > need detailed review at some point too. > > > > This sounds like a different patch to me, I'll investigate. > > > > If the common case is to not require any complicated options then > `--strip-native-debug-symbols` would be nice and would be consistent > with the existing `--strip-XXXX` options. The cross targeting case, or > cases where debuginfo options are need, would of course mean a more > complicated command. Yes, but I was referring to the current state of the jlink plugin system. AFAIK, there is two --strip-XXX plugins: StripNativeCommandsPlugin and StripDebugPlugin. Both of these have hasArguments() == false. This new one has hasArguments() == true. Then the plugin system wants at least 1 argument. What has to be implemented first is a way for a plugin to allow both: no-args *and* 1+ args. Currently it's 1+ args XOR 0 args. This functionality doesn't seem related to this particular patch but would be generic. Thanks, Severin From bsrbnd at gmail.com Mon Jan 28 15:20:37 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 28 Jan 2019 16:20:37 +0100 Subject: test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java failing with -XX:+UseShenandoahGC on x86_64 In-Reply-To: References: Message-ID: I've seen this has just been pushed to 12 but I think we'd need this to 13 too, but: https://bugs.openjdk.java.net/browse/JDK-8217873 has been resolved as duplicate. I can help reopening it and pushing the fix to 13 if necessary? Thanks, Bernard On Sat, 26 Jan 2019 at 16:47, B. Blaser wrote: > > Hi, > > Maybe you're already aware of this failing test, but it seems that > -XX:+UnlockExperimentalVMOptions is necessary with > -XX:+UseShenandoahGC as here under. > > Regards, > Bernard > > diff --git a/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java > b/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java > --- a/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java > +++ b/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2014, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -63,7 +63,7 @@ > testCompressedOopsModes(args, "-XX:+UseParallelGC"); > testCompressedOopsModes(args, "-XX:+UseParallelOldGC"); > if (GC.Shenandoah.isSupported()) { > - testCompressedOopsModes(args, "-XX:+UseShenandoahGC"); > + testCompressedOopsModes(args, > "-XX:+UnlockExperimentalVMOptions", "-XX:+UseShenandoahGC"); > } > } From daniel.daugherty at oracle.com Mon Jan 28 15:39:08 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 28 Jan 2019 10:39:08 -0500 Subject: test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java failing with -XX:+UseShenandoahGC on x86_64 In-Reply-To: References: Message-ID: <9eb1d081-8cd5-eb13-48f0-7ea4c26fa229@oracle.com> It will get pushed to jdk/jdk (for JDK13) on Jesper's next sync from jdk/jdk12 -> jdk/jdk. Dan On 1/28/19 10:20 AM, B. Blaser wrote: > I've seen this has just been pushed to 12 but I think we'd need this > to 13 too, but: > > https://bugs.openjdk.java.net/browse/JDK-8217873 > > has been resolved as duplicate. > > I can help reopening it and pushing the fix to 13 if necessary? > > Thanks, > Bernard > > On Sat, 26 Jan 2019 at 16:47, B. Blaser wrote: >> Hi, >> >> Maybe you're already aware of this failing test, but it seems that >> -XX:+UnlockExperimentalVMOptions is necessary with >> -XX:+UseShenandoahGC as here under. >> >> Regards, >> Bernard >> >> diff --git a/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java >> b/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java >> --- a/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java >> +++ b/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2014, 2018, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -63,7 +63,7 @@ >> testCompressedOopsModes(args, "-XX:+UseParallelGC"); >> testCompressedOopsModes(args, "-XX:+UseParallelOldGC"); >> if (GC.Shenandoah.isSupported()) { >> - testCompressedOopsModes(args, "-XX:+UseShenandoahGC"); >> + testCompressedOopsModes(args, >> "-XX:+UnlockExperimentalVMOptions", "-XX:+UseShenandoahGC"); >> } >> } From rkennke at redhat.com Mon Jan 28 16:16:11 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 28 Jan 2019 17:16:11 +0100 Subject: test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java failing with -XX:+UseShenandoahGC on x86_64 In-Reply-To: References: Message-ID: Isn't anything pushed to 12 (kindof) automatically pushed to 13 too, eventually? Roman > I've seen this has just been pushed to 12 but I think we'd need this > to 13 too, but: > > https://bugs.openjdk.java.net/browse/JDK-8217873 > > has been resolved as duplicate. > > I can help reopening it and pushing the fix to 13 if necessary? > > Thanks, > Bernard > > On Sat, 26 Jan 2019 at 16:47, B. Blaser wrote: >> >> Hi, >> >> Maybe you're already aware of this failing test, but it seems that >> -XX:+UnlockExperimentalVMOptions is necessary with >> -XX:+UseShenandoahGC as here under. >> >> Regards, >> Bernard >> >> diff --git a/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java >> b/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java >> --- a/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java >> +++ b/test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2014, 2018, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -63,7 +63,7 @@ >> testCompressedOopsModes(args, "-XX:+UseParallelGC"); >> testCompressedOopsModes(args, "-XX:+UseParallelOldGC"); >> if (GC.Shenandoah.isSupported()) { >> - testCompressedOopsModes(args, "-XX:+UseShenandoahGC"); >> + testCompressedOopsModes(args, >> "-XX:+UnlockExperimentalVMOptions", "-XX:+UseShenandoahGC"); >> } >> } From erik.joelsson at oracle.com Mon Jan 28 17:47:31 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Jan 2019 09:47:31 -0800 Subject: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov In-Reply-To: References: Message-ID: <7e4fcccb-a587-b488-62fd-4a6a94b3cce1@oracle.com> Hello Shura, In RunTest.gmk, you removed the conditional, but the comment still implies that it's there. Please update the comment. Otherwise this looks good! /Erik On 2019-01-25 15:20, Alexandre (Shura) Iline wrote: > Hi, > > Please take a look on a change to allow JCov test execution through jib. > > Please notice that this fix also changes behavior of RunTest.gmk when conflicting combination of options is used. JCOV_IMAGE_DIR is now expected to be set when TEST_OPTS_JCOV is true. > > Shura > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217761 > Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/ From mandy.chung at oracle.com Mon Jan 28 21:02:33 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 28 Jan 2019 13:02:33 -0800 Subject: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com> References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com> <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com> <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com> <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com> Message-ID: On 1/28/19 1:26 AM, Severin Gehwolf wrote: > Hi Alan, Mandy, > > On Sun, 2019-01-27 at 08:14 +0000, Alan Bateman wrote: >> On 26/01/2019 00:06, Mandy Chung wrote: >>> Hi Severin, >>> >>> Another alternative would be to support per-jlink-plugin resource >>> bundle to avoid merging .properties files at build time. The >>> plugin-specific messages should only be used by the plugin itself >>> and it would be cleaner for each plugin to manage its resource bundle. >> That seems a cleaner idea than the suggestion we had on jigsaw-dev to >> merge the properties. If Severin does this for this plugin then I assume >> the resources for the other plugins could be moved to their own resource >> files in their own time. > Alright. I'll try this then. One simplest way is to have StripNativeDebugSymbolsPlugin loads its own ResourceBundle. I would add a new PluginsResourceBundle::getMessage method taking a ResourceBundle object that StripNativeDebugSymbolsPlugin can call. This is a patch for PluginsResourceBundle that you can use. diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java @@ -62,7 +62,11 @@ ???? } ???? public static String getMessage(String key, Object... args) throws MissingResourceException { -??????? String val = pluginsBundle.getString(key); +??????? return getMessage(pluginsBundle, key, args); +??? } + +??? public static String getMessage(ResourceBundle rb, String key, Object... args) throws MissingResourceException { +??????? String val = rb.getString(key); ???????? return MessageFormat.format(val, args); ???? } ?} Mandy From erik.joelsson at oracle.com Mon Jan 28 22:17:39 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Jan 2019 14:17:39 -0800 Subject: RFR: JDK-8217910: Slow linking with devkit on Linux Message-ID: <91c169ea-d200-6fb7-6a57-8b62d65a267a@oracle.com> Hello, While investigating performance with different linkers and linker configuration, we discovered that the devkit linker on Linux (both bfd and gold) was a lot slower than the native linker on Ubuntu (23s vs 12s for bfd to link libjvm.so on my machine). They are both the same version (2.30), so this was puzzling. It turned out to be a difference in how binutils was built. On Ubuntu (and I assume most major Linux vendors), they explicitly set CFLAGS="-O2" when running the build for binutils. I had naively assumed that binutils set reasonable default CFLAGS in their build so have not modified them like this before. I tried adding -O2 for our devkit, and that created a kit with comparable linking performance on par with the Ubuntu linker. Since this seems to be widely done, I assume the change to be quite safe. With this patch, I'm modifying the devkit creation makefiles to add -O2 when building binutils. I'm also adding --enable-threads so that the user may run the gold linker with --threads (as well as updating a download link which now requires https). For Oracle users, the devkit versions are bumped in jib-profiles.js so the new devkits are used. Bug: https://bugs.openjdk.java.net/browse/JDK-8217910 Webrev: http://cr.openjdk.java.net/~erikj/8217910/webrev.01/index.html /Erik From claes.redestad at oracle.com Mon Jan 28 22:24:37 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 28 Jan 2019 23:24:37 +0100 Subject: RFR: JDK-8217910: Slow linking with devkit on Linux In-Reply-To: <91c169ea-d200-6fb7-6a57-8b62d65a267a@oracle.com> References: <91c169ea-d200-6fb7-6a57-8b62d65a267a@oracle.com> Message-ID: <0cd68b16-3954-a603-225c-cd1b1047c92e@oracle.com> Looks great, thanks for fixing! Nit: I'd drop this comment "Ubuntu does this when building binutils so should be safe." /Claes On 2019-01-28 23:17, Erik Joelsson wrote: > Hello, > > While investigating performance with different linkers and linker > configuration, we discovered that the devkit linker on Linux (both bfd > and gold) was a lot slower than the native linker on Ubuntu (23s vs 12s > for bfd to link libjvm.so on my machine). They are both the same version > (2.30), so this was puzzling. > > It turned out to be a difference in how binutils was built. On Ubuntu > (and I assume most major Linux vendors), they explicitly set > CFLAGS="-O2" when running the build for binutils. I had naively assumed > that binutils set reasonable default CFLAGS in their build so have not > modified them like this before. I tried adding -O2 for our devkit, and > that created a kit with comparable linking performance on par with the > Ubuntu linker. Since this seems to be widely done, I assume the change > to be quite safe. > > With this patch, I'm modifying the devkit creation makefiles to add -O2 > when building binutils. I'm also adding --enable-threads so that the > user may run the gold linker with --threads (as well as updating a > download link which now requires https). For Oracle users, the devkit > versions are bumped in jib-profiles.js so the new devkits are used. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217910 > > Webrev: http://cr.openjdk.java.net/~erikj/8217910/webrev.01/index.html > > /Erik > From erik.joelsson at oracle.com Mon Jan 28 22:27:45 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Jan 2019 14:27:45 -0800 Subject: RFR: JDK-8217910: Slow linking with devkit on Linux In-Reply-To: <0cd68b16-3954-a603-225c-cd1b1047c92e@oracle.com> References: <91c169ea-d200-6fb7-6a57-8b62d65a267a@oracle.com> <0cd68b16-3954-a603-225c-cd1b1047c92e@oracle.com> Message-ID: <3c84eb6b-77bd-cad8-aa27-f721ad69e8a2@oracle.com> Thanks! You are right, that comment is not needed. Removed and updated in place (since it was just a comment). /Erik On 2019-01-28 14:24, Claes Redestad wrote: > Looks great, thanks for fixing! > > Nit: I'd drop this comment "Ubuntu does this when building binutils so > should be safe." > > /Claes > > On 2019-01-28 23:17, Erik Joelsson wrote: >> Hello, >> >> While investigating performance with different linkers and linker >> configuration, we discovered that the devkit linker on Linux (both >> bfd and gold) was a lot slower than the native linker on Ubuntu (23s >> vs 12s for bfd to link libjvm.so on my machine). They are both the >> same version (2.30), so this was puzzling. >> >> It turned out to be a difference in how binutils was built. On Ubuntu >> (and I assume most major Linux vendors), they explicitly set >> CFLAGS="-O2" when running the build for binutils. I had naively >> assumed that binutils set reasonable default CFLAGS in their build so >> have not modified them like this before. I tried adding -O2 for our >> devkit, and that created a kit with comparable linking performance on >> par with the Ubuntu linker. Since this seems to be widely done, I >> assume the change to be quite safe. >> >> With this patch, I'm modifying the devkit creation makefiles to add >> -O2 when building binutils. I'm also adding --enable-threads so that >> the user may run the gold linker with --threads (as well as updating >> a download link which now requires https). For Oracle users, the >> devkit versions are bumped in jib-profiles.js so the new devkits are >> used. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217910 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8217910/webrev.01/index.html >> >> /Erik >> From erik.joelsson at oracle.com Tue Jan 29 00:34:46 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Jan 2019 16:34:46 -0800 Subject: RFR: JDK-8217916: Build compare script is not comparing jmods Message-ID: <9f2b77aa-cdce-60ea-30c1-23332446f73a@oracle.com> This patch enhances the build compare script to also look at the jmod files in the JDK image. This was triggered by JDK-8217826 (linked in issue) where we see a rare intermittent comparison failure on Windows when looking at file types. That seems to be caused by the file command not knowing about jmod files (at least not the versions of the command we have). With this patch, I'm filtering out .jmod files from the file type comparison since it seems pointless. Instead I use the jmod tool to list the contents of each jmod file and verify that they contain the same file names. I don't think there is a point to comparing the contents of those files since all the same files will be in the JDK image and will be compared anyway. Doing it again would be a waste of time. Tested manually introducing differences and running the script, as well as running the build with COMPARE_BUILD=PATCH= on all relevant platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8217916 Webrev: http://cr.openjdk.java.net/~erikj/8217916/webrev.01/index.html /Erik From takiguc at linux.vnet.ibm.com Tue Jan 29 01:21:12 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 29 Jan 2019 10:21:12 +0900 Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> Message-ID: <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> Hello. Sorry about build issue for JDK-8214533. EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ Could you review the fix ? Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2019-01-28 22:49, Ichiroh Takiguchi wrote: > Hello Goetz. > > Thank you for your suggestion. > I just open JDK-8217880 [1]. > > I just restart clean build. > > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. > > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 > > Thanks, > Ichiroh Takiguchi > > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: >> Hi Ichiroh, >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for >> it. >> I assume the fix is quite trivial so we can review it quick. >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: ppc-aix-port-dev On >>> Behalf Of Ichiroh Takiguchi >>> Sent: Montag, 28. Januar 2019 14:13 >>> To: Baesken, Matthias >>> Cc: build-dev ; ppc-aix-port-dev >>> >> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman >>> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default >>> charset >>> >>> Hello. >>> >>> I'm very sorry. It's my fault. >>> EUC_JP class was moved to java.base module. >>> (sun.nio.cs.EUC_JP). >>> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and >>> EUC_JP_Open. >>> >>> Could you suggest me how I should provide new webrev files ? >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> >>> On 2019-01-28 17:03, Baesken, Matthias wrote: >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now >>> > we see build errors on AIX , are they related to this change ? >>> > >>> > >>> > /nb/rs6000_64/nightly/output-jdk- >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >>> > outside package >>> > private static class Decoder extends EUC_JP.Decoder { >>> > ^ >>> > /nb/rs6000_64/nightly/output-jdk- >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >>> > outside package >>> > private static class Encoder extends EUC_JP.Encoder { >>> > ^ >>> > /nb/rs6000_64/nightly/output-jdk- >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >>> > outside package >>> > private static class Decoder extends EUC_JP.Decoder { >>> > ^ >>> > /nb/rs6000_64/nightly/output-jdk- >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >>> > outside package >>> > private static class Encoder extends EUC_JP.Encoder { >>> > >>> > Best regards, Matthias >>> > >>> > >>> > >>> >> -----Original Message----- >>> >> From: ppc-aix-port-dev On >>> >> Behalf Of Ichiroh Takiguchi >>> >> Sent: Dienstag, 15. Januar 2019 01:51 >>> >> To: Alan Bateman >>> >> Cc: build-dev ; ppc-aix-port-dev >> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default >>> >> charset >>> >> >>> >> Hello Alan. >>> >> >>> >> Could you review the fix again ? >>> >> >>> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 >>> >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ >>> >> >>> >> I added IBM29626C charset as standard way. >>> >> Please give any suggestion and question. >>> >> >>> >> Thanks, >>> >> Ichiroh Takiguchi >>> >> IBM Japan, Ltd. >>> >> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >>> >> > Hello Alan. >>> >> > >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. >>> >> > I cannot wait until JDK-8215333 is closed. >>> >> > Is it possible to put IBM-29626C charset with standard way ? >>> >> > >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >>> >> > >>> >> > Thanks, >>> >> > Ichiroh Takiguchi >>> >> > >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >>> >> >> Hello Roger, Magnus and Alan. >>> >> >> I may need to put alias information into charsets file. >>> >> >> stdcs-xxx cannot handle this information... >>> >> >> >>> >> >> Still AIX needs IBM-29626C charset for default encoding... >>> >> >> >>> >> >> I appreciate if you give me further suggestions. >>> >> >> >>> >> >> Thanks, >>> >> >> Ichiroh Takiguchi >>> >> >> >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >>> >> >>>>> Hi, >>> >> >>>>> >>> >> >>>>> It is a nice feature that charsets are selected at build time using >>> >> >>>>> the stdcs-xxx files. >>> >> >>>>> This change breaks that pattern and embeds os specific information >>> >> >>>>> in more than one place. >>> >> >>>>> That does not seem like an improvement.? Is there any alternative? >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >>> >> >>> My reading of the patch is that the "os" key is to avoid generating >>> >> >>> it >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >>> >> >>> non-AIX platforms. The general direction is welcome but I think >>> >> >>> further work and discussion will be needed to get the right set of >>> >> >>> changes to support filtering in the build. It can probably be >>> >> >>> separated from the changes to add IBM-29626C to AIX's java.base. >>> >> >>> >>> >> >>> -Alan From Pavel_Simonovsky at bmc.com Tue Jan 29 04:50:15 2019 From: Pavel_Simonovsky at bmc.com (Simonovsky, Pavel) Date: Tue, 29 Jan 2019 04:50:15 +0000 Subject: Failure at rung of get_source on windows with cygwin In-Reply-To: <3161eb0c-5534-f7e5-fa46-4eef0f73ae8d@redhat.com> References: <26d61a8225e24836a46c6e333236d779@phx-exmbprd-02.adprod.bmc.com> <3161eb0c-5534-f7e5-fa46-4eef0f73ae8d@redhat.com> Message-ID: 10x a lot. Succeed to build JDK images! -----Original Message----- From: Aleksey Shipilev [mailto:shade at redhat.com] Sent: Saturday, January 26, 2019 12:03 PM To: Magnus Ihse Bursie ; Simonovsky, Pavel ; build-dev at openjdk.java.net Subject: Re: Failure at rung of get_source on windows with cygwin On 1/25/19 10:39 PM, Magnus Ihse Bursie wrote: > On 2019-01-25 22:12, Simonovsky, Pavel wrote: >> I am failing at windows build on step of running get_source.sh: >> >> ?????????????? nashorn:?? abort: stream ended unexpectedly (got 1297 >> bytes, expected 192443) >> ???????????????? jaxws:?? abort: stream ended unexpectedly (got 1957 >> bytes, expected 21072) >> ????????????????? jaxp:?? rollback completed >> ?????????????? hotspot:?? abort: stream ended unexpectedly (got 99623 >> bytes, expected 483101) >> ????????????????? jaxp:?? abort: stream ended unexpectedly (got 28110 >> bytes, expected 37505) >> ???????????? langtools:?? transaction abort! >> ???????????? langtools:?? rollback completed >> ???????????? langtools:?? abort: stream ended unexpectedly (got 810 >> bytes, expected 2288) >> WARNING: /tmp/forest.34500/hotspot.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/jaxp.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/jaxws.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/langtools.pid.rc exited abnormally. >> WARNING: /tmp/forest.34500/nashorn.pid.rc exited abnormally. >> >> I have enough disk space: >> >> $ df -k . >> Filesystem???? 1K-blocks????? Used Available Use% Mounted on >> C:???????????? 248548552 191203664? 57344888? 77% /cygdrive/c >> >> And fast network connection. >> What have I to do to troubleshoot this problem? > It sounds like the unfortunately well-known problems of > underperforming mercurial server at hg.openjdk.java.net, combined with > some issues with mercurial running on cygwin. :-( > > The only advice I can give is to keep re-trying. Eventually you will > get a clone, and subsequent operations will go smoother. If you have a > forest on a local linux machine, try starting by making a clone > manually from that one. (You'll need to clone each repo individually.) Or take this, Pavel: https://builds.shipilev.net/workspaces/ -Aleksey From erik.helin at oracle.com Tue Jan 29 06:09:37 2019 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 29 Jan 2019 07:09:37 +0100 Subject: RFR: JDK-8217910: Slow linking with devkit on Linux In-Reply-To: <91c169ea-d200-6fb7-6a57-8b62d65a267a@oracle.com> References: <91c169ea-d200-6fb7-6a57-8b62d65a267a@oracle.com> Message-ID: <322AAA4D-8956-4C06-AC29-38FF7875FBB5@oracle.com> > On 28 Jan 2019, at 23:17, Erik Joelsson wrote: > > Hello, > > While investigating performance with different linkers and linker configuration, we discovered that the devkit linker on Linux (both bfd and gold) was a lot slower than the native linker on Ubuntu (23s vs 12s for bfd to link libjvm.so on my machine). They are both the same version (2.30), so this was puzzling. > > It turned out to be a difference in how binutils was built. On Ubuntu (and I assume most major Linux vendors), they explicitly set CFLAGS="-O2" when running the build for binutils. I had naively assumed that binutils set reasonable default CFLAGS in their build so have not modified them like this before. I tried adding -O2 for our devkit, and that created a kit with comparable linking performance on par with the Ubuntu linker. Since this seems to be widely done, I assume the change to be quite safe. NIce catch and thanks for fixing this! > With this patch, I'm modifying the devkit creation makefiles to add -O2 when building binutils. I'm also adding --enable-threads so that the user may run the gold linker with --threads (as well as updating a download link which now requires https). For Oracle users, the devkit versions are bumped in jib-profiles.js so the new devkits are used. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217910 > > Webrev: http://cr.openjdk.java.net/~erikj/8217910/webrev.01/index.html Looks good, Reviewed. Thanks, Erik > /Erik > From goetz.lindenmaier at sap.com Tue Jan 29 10:17:21 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Jan 2019 10:17:21 +0000 Subject: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> Message-ID: <81787d1a7e0040829b628cf706564f27@sap.com> Hi, this looks good, the build works with this patch. Do you need a sponsor? Best regards, Goetz. > -----Original Message----- > From: Ichiroh Takiguchi > Sent: Dienstag, 29. Januar 2019 02:21 > To: Lindenmaier, Goetz > Cc: build-dev ; ppc-aix-port-dev dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, Matthias > > Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 > > Hello. > > Sorry about build issue for JDK-8214533. > > EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 > Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ > > Could you review the fix ? > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2019-01-28 22:49, Ichiroh Takiguchi wrote: > > Hello Goetz. > > > > Thank you for your suggestion. > > I just open JDK-8217880 [1]. > > > > I just restart clean build. > > > > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 > > > > Thanks, > > Ichiroh Takiguchi > > > > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: > >> Hi Ichiroh, > >> > >> just open a bug, like "Fix aix build after 8214533" and post a RFR for > >> it. > >> I assume the fix is quite trivial so we can review it quick. > >> > >> Best regards, > >> Goetz. > >> > >>> -----Original Message----- > >>> From: ppc-aix-port-dev On > >>> Behalf Of Ichiroh Takiguchi > >>> Sent: Montag, 28. Januar 2019 14:13 > >>> To: Baesken, Matthias > >>> Cc: build-dev ; ppc-aix-port-dev > >>> >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman > >>> > >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default > >>> charset > >>> > >>> Hello. > >>> > >>> I'm very sorry. It's my fault. > >>> EUC_JP class was moved to java.base module. > >>> (sun.nio.cs.EUC_JP). > >>> > >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and > >>> EUC_JP_Open. > >>> > >>> Could you suggest me how I should provide new webrev files ? > >>> > >>> Thanks, > >>> Ichiroh Takiguchi > >>> > >>> > >>> On 2019-01-28 17:03, Baesken, Matthias wrote: > >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now > >>> > we see build errors on AIX , are they related to this change ? > >>> > > >>> > > >>> > /nb/rs6000_64/nightly/output-jdk- > >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: > >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >>> > outside package > >>> > private static class Decoder extends EUC_JP.Decoder { > >>> > ^ > >>> > /nb/rs6000_64/nightly/output-jdk- > >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: > >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >>> > outside package > >>> > private static class Encoder extends EUC_JP.Encoder { > >>> > ^ > >>> > /nb/rs6000_64/nightly/output-jdk- > >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: > >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >>> > outside package > >>> > private static class Decoder extends EUC_JP.Decoder { > >>> > ^ > >>> > /nb/rs6000_64/nightly/output-jdk- > >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: > >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >>> > outside package > >>> > private static class Encoder extends EUC_JP.Encoder { > >>> > > >>> > Best regards, Matthias > >>> > > >>> > > >>> > > >>> >> -----Original Message----- > >>> >> From: ppc-aix-port-dev > On > >>> >> Behalf Of Ichiroh Takiguchi > >>> >> Sent: Dienstag, 15. Januar 2019 01:51 > >>> >> To: Alan Bateman > >>> >> Cc: build-dev ; ppc-aix-port-dev >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net > >>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default > >>> >> charset > >>> >> > >>> >> Hello Alan. > >>> >> > >>> >> Could you review the fix again ? > >>> >> > >>> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 > >>> >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ > >>> >> > >>> >> I added IBM29626C charset as standard way. > >>> >> Please give any suggestion and question. > >>> >> > >>> >> Thanks, > >>> >> Ichiroh Takiguchi > >>> >> IBM Japan, Ltd. > >>> >> > >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > >>> >> > Hello Alan. > >>> >> > > >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. > >>> >> > I cannot wait until JDK-8215333 is closed. > >>> >> > Is it possible to put IBM-29626C charset with standard way ? > >>> >> > > >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > >>> >> > > >>> >> > Thanks, > >>> >> > Ichiroh Takiguchi > >>> >> > > >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > >>> >> >> Hello Roger, Magnus and Alan. > >>> >> >> I may need to put alias information into charsets file. > >>> >> >> stdcs-xxx cannot handle this information... > >>> >> >> > >>> >> >> Still AIX needs IBM-29626C charset for default encoding... > >>> >> >> > >>> >> >> I appreciate if you give me further suggestions. > >>> >> >> > >>> >> >> Thanks, > >>> >> >> Ichiroh Takiguchi > >>> >> >> > >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: > >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: > >>> >> >>>>> Hi, > >>> >> >>>>> > >>> >> >>>>> It is a nice feature that charsets are selected at build time using > >>> >> >>>>> the stdcs-xxx files. > >>> >> >>>>> This change breaks that pattern and embeds os specific > information > >>> >> >>>>> in more than one place. > >>> >> >>>>> That does not seem like an improvement.? Is there any > alternative? > >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? > >>> >> >>> My reading of the patch is that the "os" key is to avoid generating > >>> >> >>> it > >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on > >>> >> >>> non-AIX platforms. The general direction is welcome but I think > >>> >> >>> further work and discussion will be needed to get the right set of > >>> >> >>> changes to support filtering in the build. It can probably be > >>> >> >>> separated from the changes to add IBM-29626C to AIX's java.base. > >>> >> >>> > >>> >> >>> -Alan From takiguc at linux.vnet.ibm.com Tue Jan 29 10:30:18 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 29 Jan 2019 19:30:18 +0900 Subject: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: <81787d1a7e0040829b628cf706564f27@sap.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> <81787d1a7e0040829b628cf706564f27@sap.com> Message-ID: Hello Goetz. Thank you for build testing. Yes, I need a sponsor. If possible, could you handle it ? Thanks, Ichiroh Takiguchi On 2019-01-29 19:17, Lindenmaier, Goetz wrote: > Hi, > > this looks good, the build works with this patch. > Do you need a sponsor? > > Best regards, > Goetz. > >> -----Original Message----- >> From: Ichiroh Takiguchi >> Sent: Dienstag, 29. Januar 2019 02:21 >> To: Lindenmaier, Goetz >> Cc: build-dev ; ppc-aix-port-dev >> > dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, >> Matthias >> >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 >> >> Hello. >> >> Sorry about build issue for JDK-8214533. >> >> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 >> Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ >> >> Could you review the fix ? >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote: >> > Hello Goetz. >> > >> > Thank you for your suggestion. >> > I just open JDK-8217880 [1]. >> > >> > I just restart clean build. >> > >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. >> > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 >> > >> > Thanks, >> > Ichiroh Takiguchi >> > >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: >> >> Hi Ichiroh, >> >> >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for >> >> it. >> >> I assume the fix is quite trivial so we can review it quick. >> >> >> >> Best regards, >> >> Goetz. >> >> >> >>> -----Original Message----- >> >>> From: ppc-aix-port-dev On >> >>> Behalf Of Ichiroh Takiguchi >> >>> Sent: Montag, 28. Januar 2019 14:13 >> >>> To: Baesken, Matthias >> >>> Cc: build-dev ; ppc-aix-port-dev >> >>> > >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman >> >>> >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default >> >>> charset >> >>> >> >>> Hello. >> >>> >> >>> I'm very sorry. It's my fault. >> >>> EUC_JP class was moved to java.base module. >> >>> (sun.nio.cs.EUC_JP). >> >>> >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and >> >>> EUC_JP_Open. >> >>> >> >>> Could you suggest me how I should provide new webrev files ? >> >>> >> >>> Thanks, >> >>> Ichiroh Takiguchi >> >>> >> >>> >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote: >> >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now >> >>> > we see build errors on AIX , are they related to this change ? >> >>> > >> >>> > >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >> >>> > outside package >> >>> > private static class Decoder extends EUC_JP.Decoder { >> >>> > ^ >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >> >>> > outside package >> >>> > private static class Encoder extends EUC_JP.Encoder { >> >>> > ^ >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >> >>> > outside package >> >>> > private static class Decoder extends EUC_JP.Decoder { >> >>> > ^ >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >> >>> > outside package >> >>> > private static class Encoder extends EUC_JP.Encoder { >> >>> > >> >>> > Best regards, Matthias >> >>> > >> >>> > >> >>> > >> >>> >> -----Original Message----- >> >>> >> From: ppc-aix-port-dev >> On >> >>> >> Behalf Of Ichiroh Takiguchi >> >>> >> Sent: Dienstag, 15. Januar 2019 01:51 >> >>> >> To: Alan Bateman >> >>> >> Cc: build-dev ; ppc-aix-port-dev > >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >> >>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default >> >>> >> charset >> >>> >> >> >>> >> Hello Alan. >> >>> >> >> >>> >> Could you review the fix again ? >> >>> >> >> >>> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 >> >>> >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ >> >>> >> >> >>> >> I added IBM29626C charset as standard way. >> >>> >> Please give any suggestion and question. >> >>> >> >> >>> >> Thanks, >> >>> >> Ichiroh Takiguchi >> >>> >> IBM Japan, Ltd. >> >>> >> >> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >> >>> >> > Hello Alan. >> >>> >> > >> >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. >> >>> >> > I cannot wait until JDK-8215333 is closed. >> >>> >> > Is it possible to put IBM-29626C charset with standard way ? >> >>> >> > >> >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >> >>> >> > >> >>> >> > Thanks, >> >>> >> > Ichiroh Takiguchi >> >>> >> > >> >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >> >>> >> >> Hello Roger, Magnus and Alan. >> >>> >> >> I may need to put alias information into charsets file. >> >>> >> >> stdcs-xxx cannot handle this information... >> >>> >> >> >> >>> >> >> Still AIX needs IBM-29626C charset for default encoding... >> >>> >> >> >> >>> >> >> I appreciate if you give me further suggestions. >> >>> >> >> >> >>> >> >> Thanks, >> >>> >> >> Ichiroh Takiguchi >> >>> >> >> >> >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >> >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >> >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >> >>> >> >>>>> Hi, >> >>> >> >>>>> >> >>> >> >>>>> It is a nice feature that charsets are selected at build time using >> >>> >> >>>>> the stdcs-xxx files. >> >>> >> >>>>> This change breaks that pattern and embeds os specific >> information >> >>> >> >>>>> in more than one place. >> >>> >> >>>>> That does not seem like an improvement.? Is there any >> alternative? >> >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >> >>> >> >>> My reading of the patch is that the "os" key is to avoid generating >> >>> >> >>> it >> >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> >>> >> >>> non-AIX platforms. The general direction is welcome but I think >> >>> >> >>> further work and discussion will be needed to get the right set of >> >>> >> >>> changes to support filtering in the build. It can probably be >> >>> >> >>> separated from the changes to add IBM-29626C to AIX's java.base. >> >>> >> >>> >> >>> >> >>> -Alan From magnus.ihse.bursie at oracle.com Tue Jan 29 11:03:49 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 29 Jan 2019 12:03:49 +0100 Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2! 360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> Message-ID: > 29 jan. 2019 kl. 02:21 skrev Ichiroh Takiguchi : > > Hello. > > Sorry about build issue for JDK-8214533. > > EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 > Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ LGTM. /Magnus > > Could you review the fix ? > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote: >> Hello Goetz. >> Thank you for your suggestion. >> I just open JDK-8217880 [1]. >> I just restart clean build. >> I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. >> [1] https://bugs.openjdk.java.net/browse/JDK-8217880 >> Thanks, >> Ichiroh Takiguchi >>> On 2019-01-28 22:11, Lindenmaier, Goetz wrote: >>> Hi Ichiroh, >>> just open a bug, like "Fix aix build after 8214533" and post a RFR for it. >>> I assume the fix is quite trivial so we can review it quick. >>> Best regards, >>> Goetz. >>>> -----Original Message----- >>>> From: ppc-aix-port-dev On >>>> Behalf Of Ichiroh Takiguchi >>>> Sent: Montag, 28. Januar 2019 14:13 >>>> To: Baesken, Matthias >>>> Cc: build-dev ; ppc-aix-port-dev >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman >>>> >>>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default charset >>>> Hello. >>>> I'm very sorry. It's my fault. >>>> EUC_JP class was moved to java.base module. >>>> (sun.nio.cs.EUC_JP). >>>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and >>>> EUC_JP_Open. >>>> Could you suggest me how I should provide new webrev files ? >>>> Thanks, >>>> Ichiroh Takiguchi >>>> On 2019-01-28 17:03, Baesken, Matthias wrote: >>>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now >>>> > we see build errors on AIX , are they related to this change ? >>>> > >>>> > >>>> > /nb/rs6000_64/nightly/output-jdk- >>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: >>>> > error: Decoder is not public in EUC_JP; cannot be accessed from >>>> > outside package >>>> > private static class Decoder extends EUC_JP.Decoder { >>>> > ^ >>>> > /nb/rs6000_64/nightly/output-jdk- >>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: >>>> > error: Encoder is not public in EUC_JP; cannot be accessed from >>>> > outside package >>>> > private static class Encoder extends EUC_JP.Encoder { >>>> > ^ >>>> > /nb/rs6000_64/nightly/output-jdk- >>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: >>>> > error: Decoder is not public in EUC_JP; cannot be accessed from >>>> > outside package >>>> > private static class Decoder extends EUC_JP.Decoder { >>>> > ^ >>>> > /nb/rs6000_64/nightly/output-jdk- >>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: >>>> > error: Encoder is not public in EUC_JP; cannot be accessed from >>>> > outside package >>>> > private static class Encoder extends EUC_JP.Encoder { >>>> > >>>> > Best regards, Matthias >>>> > >>>> > >>>> > >>>> >> -----Original Message----- >>>> >> From: ppc-aix-port-dev On >>>> >> Behalf Of Ichiroh Takiguchi >>>> >> Sent: Dienstag, 15. Januar 2019 01:51 >>>> >> To: Alan Bateman >>>> >> Cc: build-dev ; ppc-aix-port-dev >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >>>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default >>>> >> charset >>>> >> >>>> >> Hello Alan. >>>> >> >>>> >> Could you review the fix again ? >>>> >> >>>> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 >>>> >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ >>>> >> >>>> >> I added IBM29626C charset as standard way. >>>> >> Please give any suggestion and question. >>>> >> >>>> >> Thanks, >>>> >> Ichiroh Takiguchi >>>> >> IBM Japan, Ltd. >>>> >> >>>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >>>> >> > Hello Alan. >>>> >> > >>>> >> > I opened JDK-8215333 for Charset filtering issue [1]. >>>> >> > I cannot wait until JDK-8215333 is closed. >>>> >> > Is it possible to put IBM-29626C charset with standard way ? >>>> >> > >>>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >>>> >> > >>>> >> > Thanks, >>>> >> > Ichiroh Takiguchi >>>> >> > >>>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >>>> >> >> Hello Roger, Magnus and Alan. >>>> >> >> I may need to put alias information into charsets file. >>>> >> >> stdcs-xxx cannot handle this information... >>>> >> >> >>>> >> >> Still AIX needs IBM-29626C charset for default encoding... >>>> >> >> >>>> >> >> I appreciate if you give me further suggestions. >>>> >> >> >>>> >> >> Thanks, >>>> >> >> Ichiroh Takiguchi >>>> >> >> >>>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >>>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >>>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >>>> >> >>>>> Hi, >>>> >> >>>>> >>>> >> >>>>> It is a nice feature that charsets are selected at build time using >>>> >> >>>>> the stdcs-xxx files. >>>> >> >>>>> This change breaks that pattern and embeds os specific information >>>> >> >>>>> in more than one place. >>>> >> >>>>> That does not seem like an improvement. Is there any alternative? >>>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >>>> >> >>> My reading of the patch is that the "os" key is to avoid generating >>>> >> >>> it >>>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >>>> >> >>> non-AIX platforms. The general direction is welcome but I think >>>> >> >>> further work and discussion will be needed to get the right set of >>>> >> >>> changes to support filtering in the build. It can probably be >>>> >> >>> separated from the changes to add IBM-29626C to AIX's java.base. >>>> >> >>> >>>> >> >>> -Alan > From magnus.ihse.bursie at oracle.com Tue Jan 29 11:06:44 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 29 Jan 2019 12:06:44 +0100 Subject: RFR: JDK-8217910: Slow linking with devkit on Linux In-Reply-To: <91c169ea-d200-6fb7-6a57-8b62d65a267a@oracle.com> References: <91c169ea-d200-6fb7-6a57-8b62d65a267a@oracle.com> Message-ID: <9DAC055E-41CC-4D53-ABE6-E88784FC61CF@oracle.com> > 28 jan. 2019 kl. 23:17 skrev Erik Joelsson : > > Hello, > > While investigating performance with different linkers and linker configuration, we discovered that the devkit linker on Linux (both bfd and gold) was a lot slower than the native linker on Ubuntu (23s vs 12s for bfd to link libjvm.so on my machine). They are both the same version (2.30), so this was puzzling. > > It turned out to be a difference in how binutils was built. On Ubuntu (and I assume most major Linux vendors), they explicitly set CFLAGS="-O2" when running the build for binutils. I had naively assumed that binutils set reasonable default CFLAGS in their build so have not modified them like this before. I tried adding -O2 for our devkit, and that created a kit with comparable linking performance on par with the Ubuntu linker. Since this seems to be widely done, I assume the change to be quite safe. > > With this patch, I'm modifying the devkit creation makefiles to add -O2 when building binutils. I'm also adding --enable-threads so that the user may run the gold linker with --threads (as well as updating a download link which now requires https). For Oracle users, the devkit versions are bumped in jib-profiles.js so the new devkits are used. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217910 > > Webrev: http://cr.openjdk.java.net/~erikj/8217910/webrev.01/index.html Looks good. Nice catch! /Magnus > > /Erik > From matthias.baesken at sap.com Tue Jan 29 11:11:52 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 29 Jan 2019 11:11:52 +0000 Subject: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> <81787d1a7e0040829b628cf706564f27@sap.com> Message-ID: Looks good to me . The patch fixed the AIX build. Best regards, Matthias > -----Original Message----- > From: Ichiroh Takiguchi > Sent: Dienstag, 29. Januar 2019 11:30 > To: Lindenmaier, Goetz > Cc: build-dev ; ppc-aix-port-dev port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, > Matthias > Subject: RE: JDK-8217880 AIX build issue about JDK-8214533 > > Hello Goetz. > > Thank you for build testing. > > Yes, I need a sponsor. > If possible, could you handle it ? > > Thanks, > Ichiroh Takiguchi > > On 2019-01-29 19:17, Lindenmaier, Goetz wrote: > > Hi, > > > > this looks good, the build works with this patch. > > Do you need a sponsor? > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Ichiroh Takiguchi > >> Sent: Dienstag, 29. Januar 2019 02:21 > >> To: Lindenmaier, Goetz > >> Cc: build-dev ; ppc-aix-port-dev > >> >> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, > >> Matthias > >> > >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 > >> > >> Hello. > >> > >> Sorry about build issue for JDK-8214533. > >> > >> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 > >> Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ > >> > >> Could you review the fix ? > >> > >> Thanks, > >> Ichiroh Takiguchi > >> IBM Japan, Ltd. > >> > >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote: > >> > Hello Goetz. > >> > > >> > Thank you for your suggestion. > >> > I just open JDK-8217880 [1]. > >> > > >> > I just restart clean build. > >> > > >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. > >> > > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 > >> > > >> > Thanks, > >> > Ichiroh Takiguchi > >> > > >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: > >> >> Hi Ichiroh, > >> >> > >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for > >> >> it. > >> >> I assume the fix is quite trivial so we can review it quick. > >> >> > >> >> Best regards, > >> >> Goetz. > >> >> > >> >>> -----Original Message----- > >> >>> From: ppc-aix-port-dev bounces at openjdk.java.net> On > >> >>> Behalf Of Ichiroh Takiguchi > >> >>> Sent: Montag, 28. Januar 2019 14:13 > >> >>> To: Baesken, Matthias > >> >>> Cc: build-dev ; ppc-aix-port-dev > >> >>> >> >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan > Bateman > >> >>> > >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default > >> >>> charset > >> >>> > >> >>> Hello. > >> >>> > >> >>> I'm very sorry. It's my fault. > >> >>> EUC_JP class was moved to java.base module. > >> >>> (sun.nio.cs.EUC_JP). > >> >>> > >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX > and > >> >>> EUC_JP_Open. > >> >>> > >> >>> Could you suggest me how I should provide new webrev files ? > >> >>> > >> >>> Thanks, > >> >>> Ichiroh Takiguchi > >> >>> > >> >>> > >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote: > >> >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now > >> >>> > we see build errors on AIX , are they related to this change ? > >> >>> > > >> >>> > > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: > >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Decoder extends EUC_JP.Decoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: > >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Encoder extends EUC_JP.Encoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: > >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Decoder extends EUC_JP.Decoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: > >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Encoder extends EUC_JP.Encoder { > >> >>> > > >> >>> > Best regards, Matthias > >> >>> > > >> >>> > > >> >>> > > >> >>> >> -----Original Message----- > >> >>> >> From: ppc-aix-port-dev bounces at openjdk.java.net> > >> On > >> >>> >> Behalf Of Ichiroh Takiguchi > >> >>> >> Sent: Dienstag, 15. Januar 2019 01:51 > >> >>> >> To: Alan Bateman > >> >>> >> Cc: build-dev ; ppc-aix-port-dev > >> >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net > >> >>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default > >> >>> >> charset > >> >>> >> > >> >>> >> Hello Alan. > >> >>> >> > >> >>> >> Could you review the fix again ? > >> >>> >> > >> >>> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 > >> >>> >> Change: > https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ > >> >>> >> > >> >>> >> I added IBM29626C charset as standard way. > >> >>> >> Please give any suggestion and question. > >> >>> >> > >> >>> >> Thanks, > >> >>> >> Ichiroh Takiguchi > >> >>> >> IBM Japan, Ltd. > >> >>> >> > >> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > >> >>> >> > Hello Alan. > >> >>> >> > > >> >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. > >> >>> >> > I cannot wait until JDK-8215333 is closed. > >> >>> >> > Is it possible to put IBM-29626C charset with standard way ? > >> >>> >> > > >> >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > >> >>> >> > > >> >>> >> > Thanks, > >> >>> >> > Ichiroh Takiguchi > >> >>> >> > > >> >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > >> >>> >> >> Hello Roger, Magnus and Alan. > >> >>> >> >> I may need to put alias information into charsets file. > >> >>> >> >> stdcs-xxx cannot handle this information... > >> >>> >> >> > >> >>> >> >> Still AIX needs IBM-29626C charset for default encoding... > >> >>> >> >> > >> >>> >> >> I appreciate if you give me further suggestions. > >> >>> >> >> > >> >>> >> >> Thanks, > >> >>> >> >> Ichiroh Takiguchi > >> >>> >> >> > >> >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: > >> >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > >> >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: > >> >>> >> >>>>> Hi, > >> >>> >> >>>>> > >> >>> >> >>>>> It is a nice feature that charsets are selected at build time > using > >> >>> >> >>>>> the stdcs-xxx files. > >> >>> >> >>>>> This change breaks that pattern and embeds os specific > >> information > >> >>> >> >>>>> in more than one place. > >> >>> >> >>>>> That does not seem like an improvement.? Is there any > >> alternative? > >> >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? > >> >>> >> >>> My reading of the patch is that the "os" key is to avoid > generating > >> >>> >> >>> it > >> >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets > on > >> >>> >> >>> non-AIX platforms. The general direction is welcome but I > think > >> >>> >> >>> further work and discussion will be needed to get the right set > of > >> >>> >> >>> changes to support filtering in the build. It can probably be > >> >>> >> >>> separated from the changes to add IBM-29626C to AIX's > java.base. > >> >>> >> >>> > >> >>> >> >>> -Alan From magnus.ihse.bursie at oracle.com Tue Jan 29 11:12:00 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 29 Jan 2019 12:12:00 +0100 Subject: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov In-Reply-To: <7e4fcccb-a587-b488-62fd-4a6a94b3cce1@oracle.com> References: <7e4fcccb-a587-b488-62fd-4a6a94b3cce1@oracle.com> Message-ID: <9961A006-5966-44BC-884E-72D0737F1C3B@oracle.com> If you are going down this road, you'll need to verify that JCOV_IMAGE_DIR is not empty in RunTests. So keep the ifneq statement, but with an $(error ...) instead. Otherwise we'll just fail spectacularly and incomprehensible later on. /Magnus > 28 jan. 2019 kl. 18:47 skrev Erik Joelsson : > > Hello Shura, > > In RunTest.gmk, you removed the conditional, but the comment still implies that it's there. Please update the comment. Otherwise this looks good! > > /Erik > >> On 2019-01-25 15:20, Alexandre (Shura) Iline wrote: >> Hi, >> >> Please take a look on a change to allow JCov test execution through jib. >> >> Please notice that this fix also changes behavior of RunTest.gmk when conflicting combination of options is used. JCOV_IMAGE_DIR is now expected to be set when TEST_OPTS_JCOV is true. >> >> Shura >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217761 >> Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/ From goetz.lindenmaier at sap.com Tue Jan 29 11:20:38 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Jan 2019 11:20:38 +0000 Subject: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> <81787d1a7e0040829b628cf706564f27@sap.com> Message-ID: Pushed. Best regards, Goetz > -----Original Message----- > From: Ichiroh Takiguchi > Sent: Dienstag, 29. Januar 2019 11:30 > To: Lindenmaier, Goetz > Cc: build-dev ; ppc-aix-port-dev dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, Matthias > > Subject: RE: JDK-8217880 AIX build issue about JDK-8214533 > > Hello Goetz. > > Thank you for build testing. > > Yes, I need a sponsor. > If possible, could you handle it ? > > Thanks, > Ichiroh Takiguchi > > On 2019-01-29 19:17, Lindenmaier, Goetz wrote: > > Hi, > > > > this looks good, the build works with this patch. > > Do you need a sponsor? > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Ichiroh Takiguchi > >> Sent: Dienstag, 29. Januar 2019 02:21 > >> To: Lindenmaier, Goetz > >> Cc: build-dev ; ppc-aix-port-dev > >> >> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, > >> Matthias > >> > >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 > >> > >> Hello. > >> > >> Sorry about build issue for JDK-8214533. > >> > >> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 > >> Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ > >> > >> Could you review the fix ? > >> > >> Thanks, > >> Ichiroh Takiguchi > >> IBM Japan, Ltd. > >> > >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote: > >> > Hello Goetz. > >> > > >> > Thank you for your suggestion. > >> > I just open JDK-8217880 [1]. > >> > > >> > I just restart clean build. > >> > > >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. > >> > > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 > >> > > >> > Thanks, > >> > Ichiroh Takiguchi > >> > > >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: > >> >> Hi Ichiroh, > >> >> > >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for > >> >> it. > >> >> I assume the fix is quite trivial so we can review it quick. > >> >> > >> >> Best regards, > >> >> Goetz. > >> >> > >> >>> -----Original Message----- > >> >>> From: ppc-aix-port-dev > On > >> >>> Behalf Of Ichiroh Takiguchi > >> >>> Sent: Montag, 28. Januar 2019 14:13 > >> >>> To: Baesken, Matthias > >> >>> Cc: build-dev ; ppc-aix-port-dev > >> >>> >> >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman > >> >>> > >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default > >> >>> charset > >> >>> > >> >>> Hello. > >> >>> > >> >>> I'm very sorry. It's my fault. > >> >>> EUC_JP class was moved to java.base module. > >> >>> (sun.nio.cs.EUC_JP). > >> >>> > >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and > >> >>> EUC_JP_Open. > >> >>> > >> >>> Could you suggest me how I should provide new webrev files ? > >> >>> > >> >>> Thanks, > >> >>> Ichiroh Takiguchi > >> >>> > >> >>> > >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote: > >> >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now > >> >>> > we see build errors on AIX , are they related to this change ? > >> >>> > > >> >>> > > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: > >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Decoder extends EUC_JP.Decoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> > test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: > >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Encoder extends EUC_JP.Encoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: > >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Decoder extends EUC_JP.Decoder { > >> >>> > ^ > >> >>> > /nb/rs6000_64/nightly/output-jdk- > >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: > >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from > >> >>> > outside package > >> >>> > private static class Encoder extends EUC_JP.Encoder { > >> >>> > > >> >>> > Best regards, Matthias > >> >>> > > >> >>> > > >> >>> > > >> >>> >> -----Original Message----- > >> >>> >> From: ppc-aix-port-dev bounces at openjdk.java.net> > >> On > >> >>> >> Behalf Of Ichiroh Takiguchi > >> >>> >> Sent: Dienstag, 15. Januar 2019 01:51 > >> >>> >> To: Alan Bateman > >> >>> >> Cc: build-dev ; ppc-aix-port-dev aix- > >> >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net > >> >>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default > >> >>> >> charset > >> >>> >> > >> >>> >> Hello Alan. > >> >>> >> > >> >>> >> Could you review the fix again ? > >> >>> >> > >> >>> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 > >> >>> >> Change: > https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ > >> >>> >> > >> >>> >> I added IBM29626C charset as standard way. > >> >>> >> Please give any suggestion and question. > >> >>> >> > >> >>> >> Thanks, > >> >>> >> Ichiroh Takiguchi > >> >>> >> IBM Japan, Ltd. > >> >>> >> > >> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: > >> >>> >> > Hello Alan. > >> >>> >> > > >> >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. > >> >>> >> > I cannot wait until JDK-8215333 is closed. > >> >>> >> > Is it possible to put IBM-29626C charset with standard way ? > >> >>> >> > > >> >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 > >> >>> >> > > >> >>> >> > Thanks, > >> >>> >> > Ichiroh Takiguchi > >> >>> >> > > >> >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > >> >>> >> >> Hello Roger, Magnus and Alan. > >> >>> >> >> I may need to put alias information into charsets file. > >> >>> >> >> stdcs-xxx cannot handle this information... > >> >>> >> >> > >> >>> >> >> Still AIX needs IBM-29626C charset for default encoding... > >> >>> >> >> > >> >>> >> >> I appreciate if you give me further suggestions. > >> >>> >> >> > >> >>> >> >> Thanks, > >> >>> >> >> Ichiroh Takiguchi > >> >>> >> >> > >> >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: > >> >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > >> >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: > >> >>> >> >>>>> Hi, > >> >>> >> >>>>> > >> >>> >> >>>>> It is a nice feature that charsets are selected at build time > using > >> >>> >> >>>>> the stdcs-xxx files. > >> >>> >> >>>>> This change breaks that pattern and embeds os specific > >> information > >> >>> >> >>>>> in more than one place. > >> >>> >> >>>>> That does not seem like an improvement.? Is there any > >> alternative? > >> >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? > >> >>> >> >>> My reading of the patch is that the "os" key is to avoid > generating > >> >>> >> >>> it > >> >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on > >> >>> >> >>> non-AIX platforms. The general direction is welcome but I think > >> >>> >> >>> further work and discussion will be needed to get the right set of > >> >>> >> >>> changes to support filtering in the build. It can probably be > >> >>> >> >>> separated from the changes to add IBM-29626C to AIX's > java.base. > >> >>> >> >>> > >> >>> >> >>> -Alan From takiguc at linux.vnet.ibm.com Tue Jan 29 12:01:55 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 29 Jan 2019 21:01:55 +0900 Subject: JDK-8217880 AIX build issue about JDK-8214533 In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> <8e04b8584178fcea5b4a517127162ed4@linux.vnet.ibm.com> <8c05b5147fa7489282d7cae04e801702@sap.com> <71a838ee68f575ee384bdc833ab820db@linux.vnet.ibm.com> <2360ba8a6e5ce7bf580beafb377af7c4@linux.vnet.ibm.com> <81787d1a7e0040829b628cf706564f27@sap.com> Message-ID: <17a0aa2962cc11279991fd8a10b41494@linux.vnet.ibm.com> To reviewers, Thank you for reviewing in a short time. Best regards, Ichiroh Takiguchi On 2019-01-29 20:20, Lindenmaier, Goetz wrote: > Pushed. > > Best regards, > Goetz > >> -----Original Message----- >> From: Ichiroh Takiguchi >> Sent: Dienstag, 29. Januar 2019 11:30 >> To: Lindenmaier, Goetz >> Cc: build-dev ; ppc-aix-port-dev >> > dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, >> Matthias >> >> Subject: RE: JDK-8217880 AIX build issue about JDK-8214533 >> >> Hello Goetz. >> >> Thank you for build testing. >> >> Yes, I need a sponsor. >> If possible, could you handle it ? >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-01-29 19:17, Lindenmaier, Goetz wrote: >> > Hi, >> > >> > this looks good, the build works with this patch. >> > Do you need a sponsor? >> > >> > Best regards, >> > Goetz. >> > >> >> -----Original Message----- >> >> From: Ichiroh Takiguchi >> >> Sent: Dienstag, 29. Januar 2019 02:21 >> >> To: Lindenmaier, Goetz >> >> Cc: build-dev ; ppc-aix-port-dev >> >> > >> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Baesken, >> >> Matthias >> >> >> >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533 >> >> >> >> Hello. >> >> >> >> Sorry about build issue for JDK-8214533. >> >> >> >> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217880 >> >> Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ >> >> >> >> Could you review the fix ? >> >> >> >> Thanks, >> >> Ichiroh Takiguchi >> >> IBM Japan, Ltd. >> >> >> >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote: >> >> > Hello Goetz. >> >> > >> >> > Thank you for your suggestion. >> >> > I just open JDK-8217880 [1]. >> >> > >> >> > I just restart clean build. >> >> > >> >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. >> >> > >> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880 >> >> > >> >> > Thanks, >> >> > Ichiroh Takiguchi >> >> > >> >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote: >> >> >> Hi Ichiroh, >> >> >> >> >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for >> >> >> it. >> >> >> I assume the fix is quite trivial so we can review it quick. >> >> >> >> >> >> Best regards, >> >> >> Goetz. >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: ppc-aix-port-dev >> On >> >> >>> Behalf Of Ichiroh Takiguchi >> >> >>> Sent: Montag, 28. Januar 2019 14:13 >> >> >>> To: Baesken, Matthias >> >> >>> Cc: build-dev ; ppc-aix-port-dev >> >> >>> > >> >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net; Alan Bateman >> >> >>> >> >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default >> >> >>> charset >> >> >>> >> >> >>> Hello. >> >> >>> >> >> >>> I'm very sorry. It's my fault. >> >> >>> EUC_JP class was moved to java.base module. >> >> >>> (sun.nio.cs.EUC_JP). >> >> >>> >> >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and >> >> >>> EUC_JP_Open. >> >> >>> >> >> >>> Could you suggest me how I should provide new webrev files ? >> >> >>> >> >> >>> Thanks, >> >> >>> Ichiroh Takiguchi >> >> >>> >> >> >>> >> >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote: >> >> >>> > Hello, seems 8214533 got pushed recently into jdk/jdk. Now >> >> >>> > we see build errors on AIX , are they related to this change ? >> >> >>> > >> >> >>> > >> >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >> >>> >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: >> >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >> >> >>> > outside package >> >> >>> > private static class Decoder extends EUC_JP.Decoder { >> >> >>> > ^ >> >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >> >>> >> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69: >> >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >> >> >>> > outside package >> >> >>> > private static class Encoder extends EUC_JP.Encoder { >> >> >>> > ^ >> >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65: >> >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from >> >> >>> > outside package >> >> >>> > private static class Decoder extends EUC_JP.Decoder { >> >> >>> > ^ >> >> >>> > /nb/rs6000_64/nightly/output-jdk- >> >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85: >> >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from >> >> >>> > outside package >> >> >>> > private static class Encoder extends EUC_JP.Encoder { >> >> >>> > >> >> >>> > Best regards, Matthias >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> >> -----Original Message----- >> >> >>> >> From: ppc-aix-port-dev > bounces at openjdk.java.net> >> >> On >> >> >>> >> Behalf Of Ichiroh Takiguchi >> >> >>> >> Sent: Dienstag, 15. Januar 2019 01:51 >> >> >>> >> To: Alan Bateman >> >> >>> >> Cc: build-dev ; ppc-aix-port-dev > aix- >> >> >>> >> port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net >> >> >>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default >> >> >>> >> charset >> >> >>> >> >> >> >>> >> Hello Alan. >> >> >>> >> >> >> >>> >> Could you review the fix again ? >> >> >>> >> >> >> >>> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 >> >> >>> >> Change: >> https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ >> >> >>> >> >> >> >>> >> I added IBM29626C charset as standard way. >> >> >>> >> Please give any suggestion and question. >> >> >>> >> >> >> >>> >> Thanks, >> >> >>> >> Ichiroh Takiguchi >> >> >>> >> IBM Japan, Ltd. >> >> >>> >> >> >> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote: >> >> >>> >> > Hello Alan. >> >> >>> >> > >> >> >>> >> > I opened JDK-8215333 for Charset filtering issue [1]. >> >> >>> >> > I cannot wait until JDK-8215333 is closed. >> >> >>> >> > Is it possible to put IBM-29626C charset with standard way ? >> >> >>> >> > >> >> >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333 >> >> >>> >> > >> >> >>> >> > Thanks, >> >> >>> >> > Ichiroh Takiguchi >> >> >>> >> > >> >> >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote: >> >> >>> >> >> Hello Roger, Magnus and Alan. >> >> >>> >> >> I may need to put alias information into charsets file. >> >> >>> >> >> stdcs-xxx cannot handle this information... >> >> >>> >> >> >> >> >>> >> >> Still AIX needs IBM-29626C charset for default encoding... >> >> >>> >> >> >> >> >>> >> >> I appreciate if you give me further suggestions. >> >> >>> >> >> >> >> >>> >> >> Thanks, >> >> >>> >> >> Ichiroh Takiguchi >> >> >>> >> >> >> >> >>> >> >> On 2018-12-10 20:50, Alan Bateman wrote: >> >> >>> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >> >> >>> >> >>>> On 2018-12-07 21:20, Roger Riggs wrote: >> >> >>> >> >>>>> Hi, >> >> >>> >> >>>>> >> >> >>> >> >>>>> It is a nice feature that charsets are selected at build time >> using >> >> >>> >> >>>>> the stdcs-xxx files. >> >> >>> >> >>>>> This change breaks that pattern and embeds os specific >> >> information >> >> >>> >> >>>>> in more than one place. >> >> >>> >> >>>>> That does not seem like an improvement.? Is there any >> >> alternative? >> >> >>> >> >>>> I agree. Why is it not enough just to add it to stdcs-aix? >> >> >>> >> >>> My reading of the patch is that the "os" key is to avoid >> generating >> >> >>> >> >>> it >> >> >>> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> >> >>> >> >>> non-AIX platforms. The general direction is welcome but I think >> >> >>> >> >>> further work and discussion will be needed to get the right set of >> >> >>> >> >>> changes to support filtering in the build. It can probably be >> >> >>> >> >>> separated from the changes to add IBM-29626C to AIX's >> java.base. >> >> >>> >> >>> >> >> >>> >> >>> -Alan From andrew_m_leonard at uk.ibm.com Tue Jan 29 13:08:47 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 29 Jan 2019 13:08:47 +0000 Subject: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX Message-ID: Hi, Please can I get a sponsor for this build performance enhancement on AIX, by better determining the number of LCPUs on smt AIX machines: https://cr.openjdk.java.net/~aleonard/8217896/webrev.00/ My testing shows up to 30% improved build times when leveraging the available LCPUs. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From matthias.baesken at sap.com Tue Jan 29 14:24:00 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 29 Jan 2019 14:24:00 +0000 Subject: [XS] RFR : 8217979: lib-freetype related configure messages contain wrong configure flag names Message-ID: Hello, please review this small fix. It changes wrong configure output messages related to freetype . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8217979 http://cr.openjdk.java.net/~mbaesken/webrevs/8217979.0/ Thanks, Matthias From volker.simonis at gmail.com Tue Jan 29 15:23:58 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 29 Jan 2019 16:23:58 +0100 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> <8736pi6ufd.fsf@oldenburg2.str.redhat.com> <6979e4a7-2050-369b-319c-a4372584953a@oracle.com> <666d7045-a72d-fc6f-d70b-f4b88ce6b180@redhat.com> <9e907e73-fd27-deea-da8a-05be4fd6c9f7@redhat.com> <19a78e58-9b5e-d774-ea8d-ff70aa4c95eb@redhat.com> Message-ID: When I last tried gold a few years ago on ppc64 (and ia64, just for the reference :) it didn't work because it didn't support all the required relocations. However, a current experiment with "GNU gold (GNU Binutils for Ubuntu 2.26.1) 1.11" on Ubuntu 16.04/ppc64le succeeded and improved the link time of libjvm.so (with full debug info) from ~15 to ~5 seconds which is pretty nice. I'd still appreciate if the usage of gold would be guarded by a configure check. Thank you and best regards, Volker On Sat, Jan 26, 2019 at 6:00 PM Martin Buchholz wrote: > > Another, more productionized, version of my benchmark: > > processors=12 > g++ (Debian 7.3.0-5) 7.3.0 > --- -fuse-ld=bfd --- > 6.559 user 1.180 system 7.740 total > --- -fuse-ld=gold --- > 4.575 user 0.600 system 5.176 total > --- -fuse-ld=gold -Wl,-threads --- > 9.355 user 5.062 system 4.289 total > --- -fuse-ld=lld --- > 2.700 user 1.058 system 1.157 total > --- -fuse-ld=lld -Wl,-threads --- > 2.572 user 1.128 system 1.107 total > > > #!/bin/bash > set -eu > echo processors=$(nproc) > read -a CMDLINE < $(find . -name BUILD_LIBJVM_link.cmdline -print) > > readonly DRIVER="${CMDLINE[0]}" > "$DRIVER" --version | head -1 > > benchmark() { > echo --- "$@" --- > local -r TIMEFORMAT="%U user %S system %R total" > time "$DRIVER" "$@" "${CMDLINE[@]:1}" > } > > benchmark -fuse-ld=bfd > benchmark -fuse-ld=gold > benchmark -fuse-ld=gold -Wl,-threads > benchmark -fuse-ld=lld > benchmark -fuse-ld=lld -Wl,-threads From erik.joelsson at oracle.com Tue Jan 29 16:56:40 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 29 Jan 2019 08:56:40 -0800 Subject: [XS] RFR : 8217979: lib-freetype related configure messages contain wrong configure flag names In-Reply-To: References: Message-ID: <6d71f6f1-e983-5ede-82b6-1ec936ce6431@oracle.com> Looks good. /Erik On 2019-01-29 06:24, Baesken, Matthias wrote: > Hello, please review this small fix. > > It changes wrong configure output messages related to freetype . > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8217979 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217979.0/ > > > > Thanks, Matthias From erik.joelsson at oracle.com Tue Jan 29 16:55:03 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 29 Jan 2019 08:55:03 -0800 Subject: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov In-Reply-To: <9961A006-5966-44BC-884E-72D0737F1C3B@oracle.com> References: <7e4fcccb-a587-b488-62fd-4a6a94b3cce1@oracle.com> <9961A006-5966-44BC-884E-72D0737F1C3B@oracle.com> Message-ID: <86c7ae17-82a6-9a4e-b68c-5a887c46ab8b@oracle.com> Hello, On 2019-01-29 03:12, Magnus Ihse Bursie wrote: > If you are going down this road, you'll need to verify that JCOV_IMAGE_DIR is not empty in RunTests. So keep the ifneq statement, but with an $(error ...) instead. Otherwise we'll just fail spectacularly and incomprehensible later on. This has already gone in with my blessing, but to address your concern. I don't see why we need to check that it's set in RunTest.gmk? In the local case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to be set, and in the prebuilt case, it's the responsibility of RunTestPrebuilt.gmk to adjust things for the lack of a proper spec.gmk and in RunTestPrebuilt.gmk we already check that JDK_IMAGE_DIR points to an existing directory. /Erik > /Magnus > >> 28 jan. 2019 kl. 18:47 skrev Erik Joelsson : >> >> Hello Shura, >> >> In RunTest.gmk, you removed the conditional, but the comment still implies that it's there. Please update the comment. Otherwise this looks good! >> >> /Erik >> >>> On 2019-01-25 15:20, Alexandre (Shura) Iline wrote: >>> Hi, >>> >>> Please take a look on a change to allow JCov test execution through jib. >>> >>> Please notice that this fix also changes behavior of RunTest.gmk when conflicting combination of options is used. JCOV_IMAGE_DIR is now expected to be set when TEST_OPTS_JCOV is true. >>> >>> Shura >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217761 >>> Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/ From matthias.baesken at sap.com Tue Jan 29 16:54:13 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 29 Jan 2019 16:54:13 +0000 Subject: [XS] RFR : 8217979: lib-freetype related configure messages contain wrong configure flag names In-Reply-To: <6d71f6f1-e983-5ede-82b6-1ec936ce6431@oracle.com> References: <6d71f6f1-e983-5ede-82b6-1ec936ce6431@oracle.com> Message-ID: Thanks ! May I get a second review please ? Best regards, Matthias > -----Original Message----- > From: Erik Joelsson > Sent: Dienstag, 29. Januar 2019 17:57 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Subject: Re: [XS] RFR : 8217979: lib-freetype related configure messages > contain wrong configure flag names > > Looks good. > > /Erik > > On 2019-01-29 06:24, Baesken, Matthias wrote: > > Hello, please review this small fix. > > > > It changes wrong configure output messages related to freetype . > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8217979 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217979.0/ > > > > > > > > Thanks, Matthias From philip.race at oracle.com Tue Jan 29 16:54:14 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Jan 2019 08:54:14 -0800 Subject: [XS] RFR : 8217979: lib-freetype related configure messages contain wrong configure flag names In-Reply-To: References: <6d71f6f1-e983-5ede-82b6-1ec936ce6431@oracle.com> Message-ID: +1 -phil. On 1/29/19 8:54 AM, Baesken, Matthias wrote: > Thanks ! > May I get a second review please ? > > Best regards, Matthias > > >> -----Original Message----- >> From: Erik Joelsson >> Sent: Dienstag, 29. Januar 2019 17:57 >> To: Baesken, Matthias ; 'build- >> dev at openjdk.java.net' >> Subject: Re: [XS] RFR : 8217979: lib-freetype related configure messages >> contain wrong configure flag names >> >> Looks good. >> >> /Erik >> >> On 2019-01-29 06:24, Baesken, Matthias wrote: >>> Hello, please review this small fix. >>> >>> It changes wrong configure output messages related to freetype . >>> >>> >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8217979 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8217979.0/ >>> >>> >>> >>> Thanks, Matthias From erik.joelsson at oracle.com Tue Jan 29 17:05:21 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 29 Jan 2019 09:05:21 -0800 Subject: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: Hello, I'm OK with this, but since I can't verify it at all, I would be more comfortable if one of the other AIX users would review this as well. /Erik On 2019-01-29 05:08, Andrew Leonard wrote: > Hi, > Please can I get a sponsor for this build performance enhancement on AIX, > by better determining the number of LCPUs on smt AIX machines: > https://cr.openjdk.java.net/~aleonard/8217896/webrev.00/ > My testing shows up to 30% improved build times when leveraging the > available LCPUs. > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From joe.darcy at oracle.com Wed Jan 30 00:01:11 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 29 Jan 2019 16:01:11 -0800 Subject: test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java failing with -XX:+UseShenandoahGC on x86_64 In-Reply-To: References: Message-ID: <5C50E947.1060602@oracle.com> On 1/28/2019 8:16 AM, Roman Kennke wrote: > Isn't anything pushed to 12 (kindof) automatically pushed to 13 too, > eventually? Yes; Jesper regularly syncs changes from 12 into 13. At times this requires addressing merge conflicts, etc. HTH, -Joe From jonathan.gibbons at oracle.com Wed Jan 30 00:42:31 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 29 Jan 2019 16:42:31 -0800 Subject: building on WSL Message-ID: <339e853e-3517-3422-c96f-ff9d329d3689@oracle.com> This is a question for those folk that have been working on, and more importantly, using, the recently-support for WSL. I'm coming up to speed up actually using WSL myself, so that I can test the various new stuff going into jtreg. What is the typical way to build OpenJDK for Windows, with WSL? e.g. what commands, and do you get Windows binaries? Although there is support going into the build for running jtreg, if one were to run jtreg directly, what would the typical/expected command be ... would it be to run the jtreg launch script in a WSL/bash window, pointing at a Windows JDK ... or something else? -- Jon From erik.joelsson at oracle.com Wed Jan 30 00:51:19 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 29 Jan 2019 16:51:19 -0800 Subject: building on WSL In-Reply-To: <339e853e-3517-3422-c96f-ff9d329d3689@oracle.com> References: <339e853e-3517-3422-c96f-ff9d329d3689@oracle.com> Message-ID: <1a72a223-6739-5883-2461-66bfdbaf93f8@oracle.com> Hello Jon, On 2019-01-29 16:42, Jonathan Gibbons wrote: > This is a question for those folk that have been working on, and more > importantly, using, the recently-support for WSL. > > I'm coming up to speed up actually using WSL myself, so that I can > test the various new stuff going into jtreg. > > What is the typical way to build OpenJDK for Windows, with WSL? e.g. > what commands, and do you get Windows binaries? > In a WSL shell you should be able to run configure as usual and it will default to try to build for Windows. There are a few caveats as listed in doc/building.md: Windows 10 1809 or newer is supported due to a dependency on the wslpath utility and support for environment variable sharing through WSLENV. Version 1803 can work but intermittent build failures have been observed. It's possible to build both Windows and Linux binaries from WSL. To build Windows binaries, you must use a Windows boot JDK (located in a Windows-accessible directory). To build Linux binaries, you must use a Linux boot JDK. The default behavior is to build for Windows. To build for Linux, pass `--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu` to `configure`. If building Windows binaries, the source code must be located in a Windows- accessible directory. This is because Windows executables (such as Visual Studio and the boot JDK) must be able to access the source code. Also, the drive where the source is stored must be mounted as case-insensitive by changing either /etc/fstab or /etc/wsl.conf in WSL. Individual directories may be corrected using the fsutil tool in case the source was cloned before changing the mount options. > Although there is support going into the build for running jtreg, if > one were to run jtreg directly, what would the typical/expected > command be ... would it be to run the jtreg launch script in a > WSL/bash window, pointing at a Windows JDK ... or something else? > That would be my assumption yes. /Erik > -- Jon > From erik.joelsson at oracle.com Wed Jan 30 01:18:58 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 29 Jan 2019 17:18:58 -0800 Subject: RFR: JDK-8204564: Need better error output when GenerateLinkOptData fails Message-ID: Hello, Some recent build failures reminded me of this issue and increased the need to fix it ASAP to be able to diagnose them. GenerateLinkOptData.gmk runs a java tool to generate data which is later used to optimize the JDK image with jlink. The problem here is that the tool needs to print some of that data on stdout, which the build captures as one build artifact, and will print some "garbage" on stderr if things go well. So currently we just hide all that output from the build log. Because of this, if something goes wrong, we won't see the error. This patch tries to capture the stderr output and only print it (along with stdout) if the java command fails. Bug: https://bugs.openjdk.java.net/browse/JDK-8204564 Webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.01/ /Erik From jonathan.gibbons at oracle.com Wed Jan 30 01:22:02 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 29 Jan 2019 17:22:02 -0800 Subject: building on WSL In-Reply-To: <1a72a223-6739-5883-2461-66bfdbaf93f8@oracle.com> References: <339e853e-3517-3422-c96f-ff9d329d3689@oracle.com> <1a72a223-6739-5883-2461-66bfdbaf93f8@oracle.com> Message-ID: <39363404-d6cd-37ef-4611-9677fe18497a@oracle.com> Erik, Thanks for all the info. That really helps ... especially the bit about building for Linux, which I couldn't infer from the --help. FWIW, at this time, you cannot use the existing `bin/jtreg` script in WSL when using a Windows binary to run jtreg: it needs to set the .exe suffix. I'll get that fixed. -- Jon On 01/29/2019 04:51 PM, Erik Joelsson wrote: > Hello Jon, > > On 2019-01-29 16:42, Jonathan Gibbons wrote: >> This is a question for those folk that have been working on, and more >> importantly, using, the recently-support for WSL. >> >> I'm coming up to speed up actually using WSL myself, so that I can >> test the various new stuff going into jtreg. >> >> What is the typical way to build OpenJDK for Windows, with WSL? e.g. >> what commands, and do you get Windows binaries? >> > In a WSL shell you should be able to run configure as usual and it > will default to try to build for Windows. There are a few caveats as > listed in doc/building.md: > > Windows 10 1809 or newer is supported due to a dependency on the > wslpath utility > and support for environment variable sharing through WSLENV. Version > 1803 can > work but intermittent build failures have been observed. > > It's possible to build both Windows and Linux binaries from WSL. To build > Windows binaries, you must use a Windows boot JDK (located in a > Windows-accessible directory). To build Linux binaries, you must use a > Linux > boot JDK. The default behavior is to build for Windows. To build for > Linux, pass > `--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu` to > `configure`. > > If building Windows binaries, the source code must be located in a > Windows- > accessible directory. This is because Windows executables (such as > Visual Studio > and the boot JDK) must be able to access the source code. Also, the > drive where > the source is stored must be mounted as case-insensitive by changing > either > /etc/fstab or /etc/wsl.conf in WSL. Individual directories may be > corrected > using the fsutil tool in case the source was cloned before changing > the mount > options. > >> Although there is support going into the build for running jtreg, if >> one were to run jtreg directly, what would the typical/expected >> command be ... would it be to run the jtreg launch script in a >> WSL/bash window, pointing at a Windows JDK ... or something else? >> > That would be my assumption yes. > > /Erik > >> -- Jon >> From tim.bell at oracle.com Wed Jan 30 01:50:36 2019 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 29 Jan 2019 17:50:36 -0800 Subject: RFR: JDK-8204564: Need better error output when GenerateLinkOptData fails In-Reply-To: References: Message-ID: <5C5102EC.3040508@oracle.com> Erik: > Some recent build failures reminded me of this issue and increased the > need to fix it ASAP to be able to diagnose them. GenerateLinkOptData.gmk > runs a java tool to generate data which is later used to optimize the > JDK image with jlink. The problem here is that the tool needs to print > some of that data on stdout, which the build captures as one build > artifact, and will print some "garbage" on stderr if things go well. So > currently we just hide all that output from the build log. Because of > this, if something goes wrong, we won't see the error. > > This patch tries to capture the stderr output and only print it (along > with stdout) if the java command fails. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204564 > > Webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.01/ Looks good. Tim From david.holmes at oracle.com Wed Jan 30 02:23:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Jan 2019 12:23:11 +1000 Subject: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: On 30/01/2019 3:05 am, Erik Joelsson wrote: > Hello, > > I'm OK with this, but since I can't verify it at all, I would be more > comfortable if one of the other AIX users would review this as well. Ditto. I did some googling on this and pmcycles is flagged as maybe being deprecated in the future and may require privileges to execute. lparstat -i seems to be more commonly used. David ----- > /Erik > > On 2019-01-29 05:08, Andrew Leonard wrote: >> Hi, >> Please can I get a sponsor for this build performance enhancement on AIX, >> by better determining the number of LCPUs on smt AIX machines: >> ???? https://cr.openjdk.java.net/~aleonard/8217896/webrev.00/ >> My testing shows up to 30% improved build times when leveraging the >> available LCPUs. >> Many thanks >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> Phone internal: 245913, external: 01962 815913 >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU From andrew at dcs.bbk.ac.uk Wed Jan 30 09:10:09 2019 From: andrew at dcs.bbk.ac.uk (Andrew Watkins) Date: Wed, 30 Jan 2019 09:10:09 +0000 Subject: OpenJDK 11.0.2 cannot build on Solaris 11.4 In-Reply-To: References: Message-ID: <3e3fe6da-713c-6685-98e3-05335eed77b4@dcs.bbk.ac.uk> On 01/18/19 05:23 PM, Erik Joelsson wrote: > ..... > > You could try the open/make/devkit/createSolarisDevkit12.4.sh script > and see if that helps you build something that works better. That's > what we use at Oracle. > > /Erik Is there any hope of getting OpenJDK 12 to build on the Free download of? Solaris Studio 12.4 or 12.6, since for us Oracle Solaris 11 x86_64 shops we are unable to get Java 12 or above with out it. OpenJDK 12 requires latest versions of solarisstudio-124 or developerstudio-126 Of course this would not be a problem if Oracle supplied us with Solaris 11 x86_64 Java 11 or 12 and not just the SPARC version. Cheers, Andrew -- Andrew Watkins * Birkbeck, University of London * Computer Science * * http://notallmicrosoft.blogspot.com * * UKOUG Systems SIG Chair * * UKOUG Tech committee * * tel: 020 7631 6720 * ::e-mails are only read & actioned between 0900 and 1800 hours (Monday - Friday) From aoqi at loongson.cn Wed Jan 30 09:32:03 2019 From: aoqi at loongson.cn (Ao Qi) Date: Wed, 30 Jan 2019 17:32:03 +0800 Subject: OpenJDK 11.0.2 cannot build on Solaris 11.4 In-Reply-To: References: Message-ID: Hi Rob, If I recall it correctly, maybe configure with --disable-hotspot-gtest can solve your problem. Cheer, Ao Qi On Fri, Jan 18, 2019 at 5:57 AM Rob Petti wrote: > > Hey Folks, > > I've discovered that OpenJDK 11 cannot be built on Solaris 11.4. Normally > we would just try to rebuild our system as 11.1, but that's not possible > since media for that base release is no longer available. > > Are there plans to support compilation on Oracle's latest and greatest, or > at least provide a proper method of building in such an environment? > > For the record, here are the errors I'm getting. This is with solarisstudio > 12.4 (which BTW wouldn't install on Solaris 11.4 without unfreezing the > python version): > > # bash configure --with-boot-jdk= > --with-devkit=/opt/solarisstudio12.4 > # gmake bootcycle-images > ... > Compiling 163 files for jdk.jfr > "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1580: > Error: EM_486 is not defined. > "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1618: > Error: The type "const arch_t[]" is incomplete. > 2 Error(s) detected. > gmake[3]: *** [lib/CompileJvm.gmk:151: > /root/jdk11/jdk11u/build/solaris-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/os_solaris.o] > Error 2 > > After patching with http://robpetti.com/files/jdk11-sol114.patch to fix > https://bugs.openjdk.java.net/browse/JDK-8182035, it gets a bit further, > but still fails: > > Compiling 64 files for jdk.jconsole > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 161: Error: __pad is not a member of const __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 163: Error: __pad is not a member of const __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 165: Error: __pad is not a member of const __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 165: Error: __pad is not a member of const __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 167: Error: __pad is not a member of const __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 170: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 170: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 172: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 172: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 174: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 174: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 176: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 176: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 178: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 178: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 182: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 183: Error: __pad is not a member of __FILE. > "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h", > line 184: Error: __pad is not a member of __FILE. > 18 Error(s) detected. > > It seems the "right" way to do this would be to create a sysroot with older > 11.1 headers and libraries, and compile against that. Unfortunately the > --with-sysroot configure option does not completely work correctly. The > compiler still tries to include /usr/include instead of the sysroot > headers, and that just results in more build errors. The only way it seems > to truly get it to use the sysroot was to physically replace /usr/include > on the machine with the version from the sysroot. This is obviously less > than ideal. > > Is the --with-sysroot issue already known? Is there any other way around it > aside from manually replacing headers in the system just to compile the JDK? > > -- > > Rob Petti > about.me/robpetti > From aoqi at loongson.cn Wed Jan 30 09:35:52 2019 From: aoqi at loongson.cn (Ao Qi) Date: Wed, 30 Jan 2019 17:35:52 +0800 Subject: OpenJDK 11.0.2 cannot build on Solaris 11.4 In-Reply-To: <3e3fe6da-713c-6685-98e3-05335eed77b4@dcs.bbk.ac.uk> References: <3e3fe6da-713c-6685-98e3-05335eed77b4@dcs.bbk.ac.uk> Message-ID: Hi Andrew Watkins, jdk12 can be built on Solaris 11.4 x86 solarisstudio12.4, but it needs a EM_486 patch, and configure with --disable-hotspot-gtest --with-jvm-features=-shenandoahgc,-dtrace Cheers, Ao Qi On Wed, Jan 30, 2019 at 5:10 PM Andrew Watkins wrote: > > > > On 01/18/19 05:23 PM, Erik Joelsson wrote: > > ..... > > > > You could try the open/make/devkit/createSolarisDevkit12.4.sh script > > and see if that helps you build something that works better. That's > > what we use at Oracle. > > > > /Erik > > Is there any hope of getting OpenJDK 12 to build on the Free download > of Solaris Studio 12.4 or 12.6, since for us Oracle Solaris 11 x86_64 > shops we are unable to get Java 12 or above with out it. > > OpenJDK 12 requires latest versions of solarisstudio-124 or > developerstudio-126 > > Of course this would not be a problem if Oracle supplied us with Solaris > 11 x86_64 Java 11 or 12 and not just the SPARC version. > > Cheers, > > Andrew > > -- > Andrew Watkins * Birkbeck, University of London * Computer Science * > * http://notallmicrosoft.blogspot.com * > * UKOUG Systems SIG Chair * > * UKOUG Tech committee * > * tel: 020 7631 6720 * > > ::e-mails are only read & actioned between 0900 and 1800 hours (Monday - Friday) > From magnus.ihse.bursie at oracle.com Wed Jan 30 09:44:45 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Jan 2019 10:44:45 +0100 Subject: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: <68ff5113-32d3-55f7-972a-472570d19cc4@oracle.com> On 2019-01-29 18:05, Erik Joelsson wrote: > Hello, > > I'm OK with this, but since I can't verify it at all, I would be more > comfortable if one of the other AIX users would review this as well. I'm also a bit surprised by the "wc -l | awk '{print $1}" construct. The point of sending -l to wc is to only get the line number count as output, yes? So why the awk part then? /Magnus > > /Erik > > On 2019-01-29 05:08, Andrew Leonard wrote: >> Hi, >> Please can I get a sponsor for this build performance enhancement on >> AIX, >> by better determining the number of LCPUs on smt AIX machines: >> ???? https://cr.openjdk.java.net/~aleonard/8217896/webrev.00/ >> My testing shows up to 30% improved build times when leveraging the >> available LCPUs. >> Many thanks >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> Phone internal: 245913, external: 01962 815913 >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 3AU From magnus.ihse.bursie at oracle.com Wed Jan 30 09:51:54 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Jan 2019 10:51:54 +0100 Subject: RFR: JDK-8204564: Need better error output when GenerateLinkOptData fails In-Reply-To: References: Message-ID: <9902d751-8138-d75f-e084-2d28ee3b4382@oracle.com> On 2019-01-30 02:18, Erik Joelsson wrote: > Hello, > > Some recent build failures reminded me of this issue and increased the > need to fix it ASAP to be able to diagnose them. > GenerateLinkOptData.gmk runs a java tool to generate data which is > later used to optimize the JDK image with jlink. The problem here is > that the tool needs to print some of that data on stdout, which the > build captures as one build artifact, and will print some "garbage" on > stderr if things go well. So currently we just hide all that output > from the build log. Because of this, if something goes wrong, we won't > see the error. > > This patch tries to capture the stderr output and only print it (along > with stdout) if the java command fails. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204564 > > Webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.01/ Good idea, but could you please include some more information in the case of failure? The classlist data generation gets a lot of blame when the real cause is that the JDK is stillborn. Something like: ??????????? || ( exitcode=$$? && $(ECHO) "ERROR: Classlist file generation failed. This is typically a sign that the newly built JDK is broken, and not of an error in the Classlist generation." && $(ECHO) "Classlist stderr: " && $(CAT) $(LINK_OPT_DIR)/stderr && $(ECHO) "Classlist trace file:" && $(CAT) $(JLI_TRACE_FILE) \ ???????????????? && exit $$exitcode ) but with better line breaks :) /Magnus > > /Erik > From matthias.baesken at sap.com Wed Jan 30 10:08:03 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 30 Jan 2019 10:08:03 +0000 Subject: RFR : [XS] 8218046: use bundled freetype in the AIX build by default Message-ID: Hello, please review this small change . It adjusts the freetype default on AIX to "bundled" (means : use the bundled freetype if not configured otherwise) . Currently only windows and macosx use the bundled freetype, the other platforms by default use the system freetype (see lib-freetype.m4). AIX would benefit from using the bundled as well, because even when freetype is installed on the system configure runs sometimes into detection issues. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8218046 http://cr.openjdk.java.net/~mbaesken/webrevs/8218046.0/ Best regards, Matthias From andrew at dcs.bbk.ac.uk Wed Jan 30 12:21:36 2019 From: andrew at dcs.bbk.ac.uk (Andrew Watkins) Date: Wed, 30 Jan 2019 12:21:36 +0000 Subject: OpenJDK 11.0.2 cannot build on Solaris 11.4 In-Reply-To: References: <3e3fe6da-713c-6685-98e3-05335eed77b4@dcs.bbk.ac.uk> Message-ID: <002fbcb4-0679-daa5-fdd7-bc0110973a3e@dcs.bbk.ac.uk> Thanks worked like a dream! For reference to build on Solaris 11.4 # export PATH=/usr/local/openjdk/jdk11/bin:/opt/solarisstudio12.4/bin:/usr/bin:/usr/sbin:/usr/gnu/bin:/usr/sfw/bin # hg clone http://hg.openjdk.java.net/jdk/jdk12 # bash configure? --prefix=/usr/local/openjdk/jdk12 --with-devkit=/home/andrew/src/openjdk/jdk12/build/devkit --disable-hotspot-gtest --with-jvm-features=-shenandoahgc,-dtrace # gmake # gmake images Cheers, Andrew On 01/30/19 09:35 AM, Ao Qi wrote: > Hi Andrew Watkins, > > jdk12 can be built on Solaris 11.4 x86 solarisstudio12.4, but it needs > a EM_486 patch, and configure with --disable-hotspot-gtest > --with-jvm-features=-shenandoahgc,-dtrace > > Cheers, > Ao Qi > > On Wed, Jan 30, 2019 at 5:10 PM Andrew Watkins wrote: >> >> >> On 01/18/19 05:23 PM, Erik Joelsson wrote: >>> ..... >>> >>> You could try the open/make/devkit/createSolarisDevkit12.4.sh script >>> and see if that helps you build something that works better. That's >>> what we use at Oracle. >>> >>> /Erik >> Is there any hope of getting OpenJDK 12 to build on the Free download >> of Solaris Studio 12.4 or 12.6, since for us Oracle Solaris 11 x86_64 >> shops we are unable to get Java 12 or above with out it. >> >> OpenJDK 12 requires latest versions of solarisstudio-124 or >> developerstudio-126 >> >> Of course this would not be a problem if Oracle supplied us with Solaris >> 11 x86_64 Java 11 or 12 and not just the SPARC version. >> >> Cheers, >> >> Andrew >> >> -- >> Andrew Watkins * Birkbeck, University of London * Computer Science * >> * http://notallmicrosoft.blogspot.com * >> * UKOUG Systems SIG Chair * >> * UKOUG Tech committee * >> * tel: 020 7631 6720 * >> >> ::e-mails are only read & actioned between 0900 and 1800 hours (Monday - Friday) >> -- Andrew Watkins * Birkbeck, University of London * Computer Science * * http://notallmicrosoft.blogspot.com * * UKOUG Systems SIG Chair * * UKOUG Tech committee * * tel: 020 7631 6720 * ::e-mails are only read & actioned between 0900 and 1800 hours (Monday - Friday) From magnus.ihse.bursie at oracle.com Wed Jan 30 13:41:01 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Jan 2019 14:41:01 +0100 Subject: RFR: JDK-8218057 Add ppc64le and s390x profiles to jib-profiles.js Message-ID: <8593f661-3c81-ebd3-a6bc-5fcf1b7626bd@oracle.com> With Volker's fix in JDK-8213698, creating devkits for cross-compiling on linux to various other platforms was made trivial. This patch uses this functionality to add new cross-compilation targets for ppc64le and s390x to jib-profiles.js As usual; this implies no commitment from Oracle to neither build nor test on these platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8218057 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8218057-add-ppc64le-and-s390x-devkits/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 30 13:42:07 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Jan 2019 14:42:07 +0100 Subject: RFR : [XS] 8218046: use bundled freetype in the AIX build by default In-Reply-To: References: Message-ID: On 2019-01-30 11:08, Baesken, Matthias wrote: > Hello, please review this small change . > > It adjusts the freetype default on AIX to "bundled" (means : use the bundled freetype if not configured otherwise) . > > > Currently only windows and macosx use the bundled freetype, the other platforms by default use the system freetype (see lib-freetype.m4). > AIX would benefit from using the bundled as well, because even when freetype is installed on the system configure runs sometimes into detection issues. > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8218046 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218046.0/ Looks good to me. /Magnus > > > Best regards, > Matthias From matthias.baesken at sap.com Wed Jan 30 13:59:25 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 30 Jan 2019 13:59:25 +0000 Subject: RFR : [XS] 8218046: use bundled freetype in the AIX build by default In-Reply-To: References: Message-ID: Thanks Magnus ! May I get a second review please ? Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Mittwoch, 30. Januar 2019 14:42 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Subject: Re: RFR : [XS] 8218046: use bundled freetype in the AIX build by > default > > On 2019-01-30 11:08, Baesken, Matthias wrote: > > Hello, please review this small change . > > > > It adjusts the freetype default on AIX to "bundled" (means : use the > bundled freetype if not configured otherwise) . > > > > > > Currently only windows and macosx use the bundled freetype, the other > platforms by default use the system freetype (see lib-freetype.m4). > > AIX would benefit from using the bundled as well, because even when > freetype is installed on the system configure runs sometimes into detection > issues. > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8218046 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218046.0/ > Looks good to me. > > /Magnus > > > > > > Best regards, > > Matthias From magnus.ihse.bursie at oracle.com Wed Jan 30 14:26:10 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Jan 2019 15:26:10 +0100 Subject: RFR : [XS] 8218046: use bundled freetype in the AIX build by default In-Reply-To: References: Message-ID: <1c535697-347b-b108-3402-36ec186b8a58@oracle.com> On 2019-01-30 14:59, Baesken, Matthias wrote: > Thanks Magnus ! > > May I get a second review please ? For build changes a second reviewer is not needed; that's a hotspot rule. /Magnus > > Best regards, Matthias > > >> -----Original Message----- >> From: Magnus Ihse Bursie >> Sent: Mittwoch, 30. Januar 2019 14:42 >> To: Baesken, Matthias ; 'build- >> dev at openjdk.java.net' >> Subject: Re: RFR : [XS] 8218046: use bundled freetype in the AIX build by >> default >> >> On 2019-01-30 11:08, Baesken, Matthias wrote: >>> Hello, please review this small change . >>> >>> It adjusts the freetype default on AIX to "bundled" (means : use the >> bundled freetype if not configured otherwise) . >>> >>> Currently only windows and macosx use the bundled freetype, the other >> platforms by default use the system freetype (see lib-freetype.m4). >>> AIX would benefit from using the bundled as well, because even when >> freetype is installed on the system configure runs sometimes into detection >> issues. >>> >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8218046 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218046.0/ >> Looks good to me. >> >> /Magnus >>> >>> Best regards, >>> Matthias From magnus.ihse.bursie at oracle.com Wed Jan 30 14:34:29 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Jan 2019 15:34:29 +0100 Subject: RFR: JDK-8217916: Build compare script is not comparing jmods In-Reply-To: <9f2b77aa-cdce-60ea-30c1-23332446f73a@oracle.com> References: <9f2b77aa-cdce-60ea-30c1-23332446f73a@oracle.com> Message-ID: <4b081937-d620-6477-3d36-bbd7f34a69b6@oracle.com> On 2019-01-29 01:34, Erik Joelsson wrote: > This patch enhances the build compare script to also look at the jmod > files in the JDK image. This was triggered by JDK-8217826 (linked in > issue) where we see a rare intermittent comparison failure on Windows > when looking at file types. That seems to be caused by the file > command not knowing about jmod files (at least not the versions of the > command we have). > > With this patch, I'm filtering out .jmod files from the file type > comparison since it seems pointless. Instead I use the jmod tool to > list the contents of each jmod file and verify that they contain the > same file names. I don't think there is a point to comparing the > contents of those files since all the same files will be in the JDK > image and will be compared anyway. Doing it again would be a waste of > time. > > Tested manually introducing differences and running the script, as > well as running the build with COMPARE_BUILD=PATCH= on all relevant > platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217916 > > Webrev: http://cr.openjdk.java.net/~erikj/8217916/webrev.01/index.html Looks good to me. /Magnus > > /Erik > From magnus.ihse.bursie at oracle.com Wed Jan 30 14:48:15 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Jan 2019 15:48:15 +0100 Subject: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov In-Reply-To: <86c7ae17-82a6-9a4e-b68c-5a887c46ab8b@oracle.com> References: <7e4fcccb-a587-b488-62fd-4a6a94b3cce1@oracle.com> <9961A006-5966-44BC-884E-72D0737F1C3B@oracle.com> <86c7ae17-82a6-9a4e-b68c-5a887c46ab8b@oracle.com> Message-ID: On 2019-01-29 17:55, Erik Joelsson wrote: > Hello, > > On 2019-01-29 03:12, Magnus Ihse Bursie wrote: >> If you are going down this road, you'll need to verify that >> JCOV_IMAGE_DIR is not empty in RunTests. So keep the ifneq statement, >> but with an $(error ...) instead. Otherwise we'll just fail >> spectacularly and incomprehensible later on. > > This has already gone in with my blessing, but to address your concern. > > I don't see why we need to check that it's set in RunTest.gmk? In the > local case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to be > set, ... but only if we configure with --with-jcov. I'd just like the system to present a comprehensible error message if the user does something like this: "make test TEST=tier1 TEST_OPTS=JCOV=true", but has not configured using --with-jcov. Prior to this patch, we ran the tests but without coverage. This is probably not what was intended, but it didn't crash. Now we're going to get a malformed command line. "Error: Unable to access jarfile /lib/jcov.jar" is not a very helpful error message. When I test now, something is odd with the "jcov-image" target as well. Even if you have not run configure with --with-jcov, the target seemingly runs and succeeds, but no jcov image is generated. Expected behavior would be an error message stating that you need to use --with-jcov. /Magnus > and in the prebuilt case, it's the responsibility of > RunTestPrebuilt.gmk to adjust things for the lack of a proper spec.gmk > and in RunTestPrebuilt.gmk we already check that JDK_IMAGE_DIR points > to an existing directory. > > /Erik > >> /Magnus >> >>> 28 jan. 2019 kl. 18:47 skrev Erik Joelsson : >>> >>> Hello Shura, >>> >>> In RunTest.gmk, you removed the conditional, but the comment still >>> implies that it's there. Please update the comment. Otherwise this >>> looks good! >>> >>> /Erik >>> >>>> On 2019-01-25 15:20, Alexandre (Shura) Iline wrote: >>>> Hi, >>>> >>>> Please take a look on a change to allow JCov test execution through >>>> jib. >>>> >>>> Please notice that this fix also changes behavior of RunTest.gmk >>>> when conflicting combination of options is used. JCOV_IMAGE_DIR? is >>>> now expected to be set when TEST_OPTS_JCOV is true. >>>> >>>> Shura >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217761 >>>> Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/ From andrew_m_leonard at uk.ibm.com Wed Jan 30 16:37:41 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 30 Jan 2019 16:37:41 +0000 Subject: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: Thanks David, I just found the reference you mention, it is a little vague, but says maybe as you said. I've reworked and tested the following which seems better: NUM_CORES=`lparstat -m | grep -o "lcpu=[[0-9]]*" | cut -d "=" -f 2` I'll create a new webrev with this. Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: David Holmes To: Erik Joelsson , Andrew Leonard , build-dev at openjdk.java.net Date: 30/01/2019 02:25 Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX On 30/01/2019 3:05 am, Erik Joelsson wrote: > Hello, > > I'm OK with this, but since I can't verify it at all, I would be more > comfortable if one of the other AIX users would review this as well. Ditto. I did some googling on this and pmcycles is flagged as maybe being deprecated in the future and may require privileges to execute. lparstat -i seems to be more commonly used. David ----- > /Erik > > On 2019-01-29 05:08, Andrew Leonard wrote: >> Hi, >> Please can I get a sponsor for this build performance enhancement on AIX, >> by better determining the number of LCPUs on smt AIX machines: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__cr.openjdk.java.net_-7Ealeonard_8217896_webrev.00_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=FpNeQfFJBut0AAVlbC0w7o0urDCArfDb4PY1TtMVW4I&s=8vmPiiNU5P6MnXKdE-eyyBm48kgCssjH5VyWHAt5zcM&e= >> My testing shows up to 30% improved build times when leveraging the >> available LCPUs. >> Many thanks >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> Phone internal: 245913, external: 01962 815913 >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From erik.joelsson at oracle.com Wed Jan 30 16:52:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Jan 2019 08:52:09 -0800 Subject: RFR: JDK-8204564: Need better error output when GenerateLinkOptData fails In-Reply-To: <9902d751-8138-d75f-e084-2d28ee3b4382@oracle.com> References: <9902d751-8138-d75f-e084-2d28ee3b4382@oracle.com> Message-ID: <99c3c385-1141-a23c-cecf-a66eb0518961@oracle.com> Hello, On 2019-01-30 01:51, Magnus Ihse Bursie wrote: > On 2019-01-30 02:18, Erik Joelsson wrote: >> Hello, >> >> Some recent build failures reminded me of this issue and increased >> the need to fix it ASAP to be able to diagnose them. >> GenerateLinkOptData.gmk runs a java tool to generate data which is >> later used to optimize the JDK image with jlink. The problem here is >> that the tool needs to print some of that data on stdout, which the >> build captures as one build artifact, and will print some "garbage" >> on stderr if things go well. So currently we just hide all that >> output from the build log. Because of this, if something goes wrong, >> we won't see the error. >> >> This patch tries to capture the stderr output and only print it >> (along with stdout) if the java command fails. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8204564 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.01/ > > Good idea, but could you please include some more information in the > case of failure? The classlist data generation gets a lot of blame > when the real cause is that the JDK is stillborn. > > Something like: > > ??????????? || ( exitcode=$$? && $(ECHO) "ERROR: Classlist file > generation failed. This is typically a sign that the newly built JDK > is broken, and not of an error in the Classlist generation." && > $(ECHO) "Classlist stderr: " && > $(CAT) $(LINK_OPT_DIR)/stderr && $(ECHO) "Classlist trace file:" && > $(CAT) $(JLI_TRACE_FILE) \ > ???????????????? && exit $$exitcode ) > > but with better line breaks :) > Sure, but please note that this is not the first time we are running the newly built JVM in the build. To run the classlist generation, we must first create a couple of jmods and jlink them together into the interim image, so the newly built JVM/JDK cannot be completely broken for this to happen. /Erik > /Magnus >> >> /Erik >> > From erik.joelsson at oracle.com Wed Jan 30 16:53:16 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Jan 2019 08:53:16 -0800 Subject: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov In-Reply-To: References: <7e4fcccb-a587-b488-62fd-4a6a94b3cce1@oracle.com> <9961A006-5966-44BC-884E-72D0737F1C3B@oracle.com> <86c7ae17-82a6-9a4e-b68c-5a887c46ab8b@oracle.com> Message-ID: On 2019-01-30 06:48, Magnus Ihse Bursie wrote: > > > On 2019-01-29 17:55, Erik Joelsson wrote: >> Hello, >> >> On 2019-01-29 03:12, Magnus Ihse Bursie wrote: >>> If you are going down this road, you'll need to verify that >>> JCOV_IMAGE_DIR is not empty in RunTests. So keep the ifneq >>> statement, but with an $(error ...) instead. Otherwise we'll just >>> fail spectacularly and incomprehensible later on. >> >> This has already gone in with my blessing, but to address your concern. >> >> I don't see why we need to check that it's set in RunTest.gmk? In the >> local case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to >> be set, > > ... but only if we configure with --with-jcov. > > I'd just like the system to present a comprehensible error message if > the user does something like this: "make test TEST=tier1 > TEST_OPTS=JCOV=true", but has not configured using --with-jcov. Prior > to this patch, we ran the tests but without coverage. This is probably > not what was intended, but it didn't crash. Now we're going to get a > malformed command line. > > "Error: Unable to access jarfile /lib/jcov.jar" is not a very helpful > error message. > > When I test now, something is odd with the "jcov-image" target as > well. Even if you have not run configure with --with-jcov, the target > seemingly runs and succeeds, but no jcov image is generated. Expected > behavior would be an error message stating that you need to use > --with-jcov. > Ah I see, but the previously existing conditional only checked if the variable JCOV_IMAGE_DIR was set, not if the directory it pointed to existed, so it wasn't any better. We set the variable JCOV_IMAGE_DIR unconditionally in spec.gmk, so that check would always be true anyway. What you are asking for is adding a new check that JCOV_HOME is set (this is a consequence of setting --with-jcov) and that JCOV_IMAGE_DIR actually points to something valid (this is the result of building jcov-image). It would also be nice if the jcov-image target failed with a reasonable error if JCOV_HOME wasn't set. I agree that these checks would be useful. /Erik > /Magnus > >> and in the prebuilt case, it's the responsibility of >> RunTestPrebuilt.gmk to adjust things for the lack of a proper >> spec.gmk and in RunTestPrebuilt.gmk we already check that >> JDK_IMAGE_DIR points to an existing directory. >> >> /Erik >> >>> /Magnus >>> >>>> 28 jan. 2019 kl. 18:47 skrev Erik Joelsson : >>>> >>>> Hello Shura, >>>> >>>> In RunTest.gmk, you removed the conditional, but the comment still >>>> implies that it's there. Please update the comment. Otherwise this >>>> looks good! >>>> >>>> /Erik >>>> >>>>> On 2019-01-25 15:20, Alexandre (Shura) Iline wrote: >>>>> Hi, >>>>> >>>>> Please take a look on a change to allow JCov test execution >>>>> through jib. >>>>> >>>>> Please notice that this fix also changes behavior of RunTest.gmk >>>>> when conflicting combination of options is used. JCOV_IMAGE_DIR? >>>>> is now expected to be set when TEST_OPTS_JCOV is true. >>>>> >>>>> Shura >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217761 >>>>> Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/ > From alexandre.iline at oracle.com Wed Jan 30 16:55:51 2019 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 30 Jan 2019 08:55:51 -0800 Subject: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov In-Reply-To: References: <7e4fcccb-a587-b488-62fd-4a6a94b3cce1@oracle.com> <9961A006-5966-44BC-884E-72D0737F1C3B@oracle.com> <86c7ae17-82a6-9a4e-b68c-5a887c46ab8b@oracle.com> Message-ID: <11C7920B-007B-4268-82BA-54742264B0BB@oracle.com> > On Jan 30, 2019, at 8:53 AM, Erik Joelsson wrote: > > > On 2019-01-30 06:48, Magnus Ihse Bursie wrote: >> >> >> On 2019-01-29 17:55, Erik Joelsson wrote: >>> Hello, >>> >>> On 2019-01-29 03:12, Magnus Ihse Bursie wrote: >>>> If you are going down this road, you'll need to verify that JCOV_IMAGE_DIR is not empty in RunTests. So keep the ifneq statement, but with an $(error ...) instead. Otherwise we'll just fail spectacularly and incomprehensible later on. >>> >>> This has already gone in with my blessing, but to address your concern. >>> >>> I don't see why we need to check that it's set in RunTest.gmk? In the local case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to be set, >> >> ... but only if we configure with --with-jcov. >> >> I'd just like the system to present a comprehensible error message if the user does something like this: "make test TEST=tier1 TEST_OPTS=JCOV=true", but has not configured using --with-jcov. Prior to this patch, we ran the tests but without coverage. This is probably not what was intended, but it didn't crash. Now we're going to get a malformed command line. >> >> "Error: Unable to access jarfile /lib/jcov.jar" is not a very helpful error message. >> >> When I test now, something is odd with the "jcov-image" target as well. Even if you have not run configure with --with-jcov, the target seemingly runs and succeeds, but no jcov image is generated. Expected behavior would be an error message stating that you need to use --with-jcov. >> > Ah I see, but the previously existing conditional only checked if the variable JCOV_IMAGE_DIR was set, not if the directory it pointed to existed, so it wasn't any better. We set the variable JCOV_IMAGE_DIR unconditionally in spec.gmk, so that check would always be true anyway. > > What you are asking for is adding a new check that JCOV_HOME is set (this is a consequence of setting --with-jcov) and that JCOV_IMAGE_DIR actually points to something valid (this is the result of building jcov-image). It would also be nice if the jcov-image target failed with a reasonable error if JCOV_HOME wasn't set. I agree that these checks would be useful. I will fix that, unless somebody else really wants to take it. Shura. > > /Erik > >> /Magnus >> >>> and in the prebuilt case, it's the responsibility of RunTestPrebuilt.gmk to adjust things for the lack of a proper spec.gmk and in RunTestPrebuilt.gmk we already check that JDK_IMAGE_DIR points to an existing directory. >>> >>> /Erik >>> >>>> /Magnus >>>> >>>>> 28 jan. 2019 kl. 18:47 skrev Erik Joelsson : >>>>> >>>>> Hello Shura, >>>>> >>>>> In RunTest.gmk, you removed the conditional, but the comment still implies that it's there. Please update the comment. Otherwise this looks good! >>>>> >>>>> /Erik >>>>> >>>>>> On 2019-01-25 15:20, Alexandre (Shura) Iline wrote: >>>>>> Hi, >>>>>> >>>>>> Please take a look on a change to allow JCov test execution through jib. >>>>>> >>>>>> Please notice that this fix also changes behavior of RunTest.gmk when conflicting combination of options is used. JCOV_IMAGE_DIR is now expected to be set when TEST_OPTS_JCOV is true. >>>>>> >>>>>> Shura >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217761 >>>>>> Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/ >> From alexandre.iline at oracle.com Wed Jan 30 16:54:39 2019 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 30 Jan 2019 08:54:39 -0800 Subject: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov In-Reply-To: References: <7e4fcccb-a587-b488-62fd-4a6a94b3cce1@oracle.com> <9961A006-5966-44BC-884E-72D0737F1C3B@oracle.com> <86c7ae17-82a6-9a4e-b68c-5a887c46ab8b@oracle.com> Message-ID: > On Jan 30, 2019, at 6:48 AM, Magnus Ihse Bursie wrote: > > > > On 2019-01-29 17:55, Erik Joelsson wrote: >> Hello, >> >> On 2019-01-29 03:12, Magnus Ihse Bursie wrote: >>> If you are going down this road, you'll need to verify that JCOV_IMAGE_DIR is not empty in RunTests. So keep the ifneq statement, but with an $(error ...) instead. Otherwise we'll just fail spectacularly and incomprehensible later on. >> >> This has already gone in with my blessing, but to address your concern. >> >> I don't see why we need to check that it's set in RunTest.gmk? In the local case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to be set, > > ... but only if we configure with --with-jcov. > > I'd just like the system to present a comprehensible error message if the user does something like this: "make test TEST=tier1 TEST_OPTS=JCOV=true", but has not configured using --with-jcov. Prior to this patch, we ran the tests but without coverage. This is probably not what was intended, but it didn't crash. Now we're going to get a malformed command line. > > "Error: Unable to access jarfile /lib/jcov.jar" is not a very helpful error message. > > When I test now, something is odd with the "jcov-image" target as well. Even if you have not run configure with --with-jcov, the target seemingly runs and succeeds, but no jcov image is generated. Expected behavior would be an error message stating that you need to use --with-jcov. Do you have the exact command to reproduce that? > > /Magnus > >> and in the prebuilt case, it's the responsibility of RunTestPrebuilt.gmk to adjust things for the lack of a proper spec.gmk and in RunTestPrebuilt.gmk we already check that JDK_IMAGE_DIR points to an existing directory. >> >> /Erik >> >>> /Magnus >>> >>>> 28 jan. 2019 kl. 18:47 skrev Erik Joelsson : >>>> >>>> Hello Shura, >>>> >>>> In RunTest.gmk, you removed the conditional, but the comment still implies that it's there. Please update the comment. Otherwise this looks good! >>>> >>>> /Erik >>>> >>>>> On 2019-01-25 15:20, Alexandre (Shura) Iline wrote: >>>>> Hi, >>>>> >>>>> Please take a look on a change to allow JCov test execution through jib. >>>>> >>>>> Please notice that this fix also changes behavior of RunTest.gmk when conflicting combination of options is used. JCOV_IMAGE_DIR is now expected to be set when TEST_OPTS_JCOV is true. >>>>> >>>>> Shura >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217761 >>>>> Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/ > From erik.joelsson at oracle.com Wed Jan 30 16:58:39 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Jan 2019 08:58:39 -0800 Subject: RFR: JDK-8218057 Add ppc64le and s390x profiles to jib-profiles.js In-Reply-To: <8593f661-3c81-ebd3-a6bc-5fcf1b7626bd@oracle.com> References: <8593f661-3c81-ebd3-a6bc-5fcf1b7626bd@oracle.com> Message-ID: <2ff779a0-6b55-1d03-49b5-c693655484f7@oracle.com> Looks good. /Erik On 2019-01-30 05:41, Magnus Ihse Bursie wrote: > With Volker's fix in JDK-8213698, creating devkits for cross-compiling > on linux to various other platforms was made trivial. > > This patch uses this functionality to add new cross-compilation > targets for ppc64le and s390x to jib-profiles.js > > As usual; this implies no commitment from Oracle to neither build nor > test on these platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218057 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8218057-add-ppc64le-and-s390x-devkits/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Wed Jan 30 17:14:21 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Jan 2019 18:14:21 +0100 Subject: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: On 2019-01-30 17:37, Andrew Leonard wrote: > Thanks David, > I just found the reference you mention, it is a little vague, but says > maybe as you said. I've reworked and tested the following which seems > better: > NUM_CORES=`lparstat -m | grep -o "lcpu=[[0-9]]*" | cut -d "=" -f 2` > I'll create a new webrev with this. Note that you should use $GREP and $CUT; in theory we should also check for lparstat, but we've been sloppy with that for the other cpu checking methods so maybe we can be that for AIX here as well. /Magnus > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: David Holmes > To: Erik Joelsson , Andrew Leonard > , build-dev at openjdk.java.net > Date: 30/01/2019 02:25 > Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when > building on AIX > > > > On 30/01/2019 3:05 am, Erik Joelsson wrote: >> Hello, >> >> I'm OK with this, but since I can't verify it at all, I would be more >> comfortable if one of the other AIX users would review this as well. > Ditto. I did some googling on this and pmcycles is flagged as maybe > being deprecated in the future and may require privileges to execute. > lparstat -i seems to be more commonly used. > > David > ----- > >> /Erik >> >> On 2019-01-29 05:08, Andrew Leonard wrote: >>> Hi, >>> Please can I get a sponsor for this build performance enhancement on > AIX, >>> by better determining the number of LCPUs on smt AIX machines: >>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__cr.openjdk.java.net_-7Ealeonard_8217896_webrev.00_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=FpNeQfFJBut0AAVlbC0w7o0urDCArfDb4PY1TtMVW4I&s=8vmPiiNU5P6MnXKdE-eyyBm48kgCssjH5VyWHAt5zcM&e= > >>> My testing shows up to 30% improved build times when leveraging the >>> available LCPUs. >>> Many thanks >>> Andrew >>> >>> Andrew Leonard >>> Java Runtimes Development >>> IBM Hursley >>> IBM United Kingdom Ltd >>> Phone internal: 245913, external: 01962 815913 >>> internet email: andrew_m_leonard at uk.ibm.com >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with > number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From magnus.ihse.bursie at oracle.com Wed Jan 30 17:21:39 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Jan 2019 18:21:39 +0100 Subject: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov In-Reply-To: <11C7920B-007B-4268-82BA-54742264B0BB@oracle.com> References: <7e4fcccb-a587-b488-62fd-4a6a94b3cce1@oracle.com> <9961A006-5966-44BC-884E-72D0737F1C3B@oracle.com> <86c7ae17-82a6-9a4e-b68c-5a887c46ab8b@oracle.com> <11C7920B-007B-4268-82BA-54742264B0BB@oracle.com> Message-ID: <9f155cc5-f4d6-92bf-c809-dea9659f09fa@oracle.com> On 2019-01-30 17:55, Alexandre (Shura) Iline wrote: > >> On Jan 30, 2019, at 8:53 AM, Erik Joelsson wrote: >> >> >> On 2019-01-30 06:48, Magnus Ihse Bursie wrote: >>> >>> On 2019-01-29 17:55, Erik Joelsson wrote: >>>> Hello, >>>> >>>> On 2019-01-29 03:12, Magnus Ihse Bursie wrote: >>>>> If you are going down this road, you'll need to verify that JCOV_IMAGE_DIR is not empty in RunTests. So keep the ifneq statement, but with an $(error ...) instead. Otherwise we'll just fail spectacularly and incomprehensible later on. >>>> This has already gone in with my blessing, but to address your concern. >>>> >>>> I don't see why we need to check that it's set in RunTest.gmk? In the local case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to be set, >>> ... but only if we configure with --with-jcov. >>> >>> I'd just like the system to present a comprehensible error message if the user does something like this: "make test TEST=tier1 TEST_OPTS=JCOV=true", but has not configured using --with-jcov. Prior to this patch, we ran the tests but without coverage. This is probably not what was intended, but it didn't crash. Now we're going to get a malformed command line. >>> >>> "Error: Unable to access jarfile /lib/jcov.jar" is not a very helpful error message. >>> >>> When I test now, something is odd with the "jcov-image" target as well. Even if you have not run configure with --with-jcov, the target seemingly runs and succeeds, but no jcov image is generated. Expected behavior would be an error message stating that you need to use --with-jcov. >>> >> Ah I see, but the previously existing conditional only checked if the variable JCOV_IMAGE_DIR was set, not if the directory it pointed to existed, so it wasn't any better. We set the variable JCOV_IMAGE_DIR unconditionally in spec.gmk, so that check would always be true anyway. >> >> What you are asking for is adding a new check that JCOV_HOME is set (this is a consequence of setting --with-jcov) and that JCOV_IMAGE_DIR actually points to something valid (this is the result of building jcov-image). It would also be nice if the jcov-image target failed with a reasonable error if JCOV_HOME wasn't set. I agree that these checks would be useful. Yes, I think this pretty much sums up what I'm asking for. > I will fix that, unless somebody else really wants to take it. Thanks Shura! Re: the "Error: Unable to access jarfile /lib/jcov.jar" error message; I got that by running configure without --with-jcov (note that you automatically get --with-jcov if running using jib), and then running "make jcov-test TEST=tier1" (or whatever test). This tried to start the jcov reporter, but JCOV_HOME was not set. Possibly all jcov operations should be checked that the value of JCOV_HOME is non-empty, and fail with an error message otherwise. And the testing should verify that the value of JCOV_IMAGE_DIR is non-empty and contains bin/java$(EXE_SUFFIX). /Magnus > > Shura. > >> /Erik >> >>> /Magnus >>> >>>> and in the prebuilt case, it's the responsibility of RunTestPrebuilt.gmk to adjust things for the lack of a proper spec.gmk and in RunTestPrebuilt.gmk we already check that JDK_IMAGE_DIR points to an existing directory. >>>> >>>> /Erik >>>> >>>>> /Magnus >>>>> >>>>>> 28 jan. 2019 kl. 18:47 skrev Erik Joelsson : >>>>>> >>>>>> Hello Shura, >>>>>> >>>>>> In RunTest.gmk, you removed the conditional, but the comment still implies that it's there. Please update the comment. Otherwise this looks good! >>>>>> >>>>>> /Erik >>>>>> >>>>>>> On 2019-01-25 15:20, Alexandre (Shura) Iline wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please take a look on a change to allow JCov test execution through jib. >>>>>>> >>>>>>> Please notice that this fix also changes behavior of RunTest.gmk when conflicting combination of options is used. JCOV_IMAGE_DIR is now expected to be set when TEST_OPTS_JCOV is true. >>>>>>> >>>>>>> Shura >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217761 >>>>>>> Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/ From gnu.andrew at redhat.com Wed Jan 30 17:25:55 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 30 Jan 2019 17:25:55 +0000 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> Message-ID: On Thu, 24 Jan 2019 at 13:12, Magnus Ihse Bursie wrote: > > The default binutils linker used by gcc, the bfd linker, is slow. The > new replacement, gold, has been distributed alongside gcc for several > years now, and is a well mature, and much faster, replacement. > > This issue is about replacing ld.bfd with ld.gold for our gcc toolchain. > In general, this cuts linking times by half or more. > > As a future improvement, gold also allows for incremental linking. > Turning on that is outside the scope of this issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217723 > Patch inline: > diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4 > --- a/make/autoconf/flags-ldflags.m4 > +++ b/make/autoconf/flags-ldflags.m4 > @@ -70,7 +70,7 @@ > fi > > # Add -z defs, to forbid undefined symbols in object files. > - BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs" > + BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -fuse-ld=gold" > > BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro" > > /Magnus I'm aware of the benefits of using gold, and also occasional issues with it, but that's not the debate here. It's already perfectly possible to build with gold by using --with-ldflags="-fuse-ld=gold", as I've been doing for quite a while, or setting the system ld to be gold. What you're asking is that this option should be forced onto every build. My experience suggests that compiler flags should be kept to a minimum, and tested for where possible. One of the great benefits of OpenJDK finally having a configure system is that we can now check whether flags work before enabling them (e.g. my own changes to support GCC 6). What seems to work wonderfully on one's local machine often breaks in a variety of different ways when exposed to the variety of build environments out there. I guess you could add this with an --enable-gold option (on by default) and testing that the flag works in configure. I do have to wonder though if it is worth the effort and possible risks. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From erik.joelsson at oracle.com Wed Jan 30 18:45:28 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Jan 2019 10:45:28 -0800 Subject: RFR: JDK-8204564: Need better error output when GenerateLinkOptData fails In-Reply-To: <99c3c385-1141-a23c-cecf-a66eb0518961@oracle.com> References: <9902d751-8138-d75f-e084-2d28ee3b4382@oracle.com> <99c3c385-1141-a23c-cecf-a66eb0518961@oracle.com> Message-ID: <7109ef77-e260-7295-7279-9ea1723d2e12@oracle.com> Here is a new webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.02/ /Erik On 2019-01-30 08:52, Erik Joelsson wrote: > Hello, > > On 2019-01-30 01:51, Magnus Ihse Bursie wrote: >> On 2019-01-30 02:18, Erik Joelsson wrote: >>> Hello, >>> >>> Some recent build failures reminded me of this issue and increased >>> the need to fix it ASAP to be able to diagnose them. >>> GenerateLinkOptData.gmk runs a java tool to generate data which is >>> later used to optimize the JDK image with jlink. The problem here is >>> that the tool needs to print some of that data on stdout, which the >>> build captures as one build artifact, and will print some "garbage" >>> on stderr if things go well. So currently we just hide all that >>> output from the build log. Because of this, if something goes wrong, >>> we won't see the error. >>> >>> This patch tries to capture the stderr output and only print it >>> (along with stdout) if the java command fails. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204564 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.01/ >> >> Good idea, but could you please include some more information in the >> case of failure? The classlist data generation gets a lot of blame >> when the real cause is that the JDK is stillborn. >> >> Something like: >> >> ??????????? || ( exitcode=$$? && $(ECHO) "ERROR: Classlist file >> generation failed. This is typically a sign that the newly built JDK >> is broken, and not of an error in the Classlist generation." && >> $(ECHO) "Classlist stderr: " && >> $(CAT) $(LINK_OPT_DIR)/stderr && $(ECHO) "Classlist trace file:" && >> $(CAT) $(JLI_TRACE_FILE) \ >> ???????????????? && exit $$exitcode ) >> >> but with better line breaks :) >> > Sure, but please note that this is not the first time we are running > the newly built JVM in the build. To run the classlist generation, we > must first create a couple of jmods and jlink them together into the > interim image, so the newly built JVM/JDK cannot be completely broken > for this to happen. > > /Erik > >> /Magnus >>> >>> /Erik >>> >> From martinrb at google.com Wed Jan 30 20:00:36 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Jan 2019 12:00:36 -0800 Subject: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain In-Reply-To: References: <40f26cc7-2e07-dc84-41fa-2a8acd97e8d6@oracle.com> Message-ID: I agree with Andrew Hughes. On Wed, Jan 30, 2019 at 9:27 AM Andrew Hughes wrote: > > I'm aware of the benefits of using gold, and also occasional issues with > it, but that's not the debate here. It's already perfectly possible to > build with gold by using --with-ldflags="-fuse-ld=gold", as I've been > doing for quite a while, or setting the system ld to be gold. What you're > asking is that this option should be forced onto every build. > > My experience suggests that compiler flags should be kept to a minimum, > and tested for where possible. One of the great benefits of OpenJDK finally > having a configure system is that we can now check whether flags work > before enabling them (e.g. my own changes to support GCC 6). What seems > to work wonderfully on one's local machine often breaks in a variety > of different > ways when exposed to the variety of build environments out there. > > I guess you could add this with an --enable-gold option (on by default) and > testing that the flag works in configure. I do have to wonder though if it > is worth the effort and possible risks. > It's not! From erik.joelsson at oracle.com Wed Jan 30 20:47:30 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Jan 2019 12:47:30 -0800 Subject: (urgent) RFR: JDK-8218084: Revert JDK-8218057 Message-ID: The addition of new build profiles in jib-profiles.js caused our internal build and test system to break down. While we fix the resilience of that system, we need to back this change out. This patch is the result of: $ hg backout 8830bb9587c2 Bug: https://bugs.openjdk.java.net/browse/JDK-8218084 Webrev: http://cr.openjdk.java.net/~erikj/8218084/webrev.01/ /Erik From joe.darcy at oracle.com Wed Jan 30 20:50:35 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Jan 2019 12:50:35 -0800 Subject: (urgent) RFR: JDK-8218084: Revert JDK-8218057 In-Reply-To: References: Message-ID: <72dec68d-4b60-94a5-3eb5-d0b5b9ecde71@oracle.com> +1 -Joe On 1/30/2019 12:47 PM, Erik Joelsson wrote: > The addition of new build profiles in jib-profiles.js caused our > internal build and test system to break down. While we fix the > resilience of that system, we need to back this change out. This patch > is the result of: > > $ hg backout 8830bb9587c2 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218084 > > Webrev: http://cr.openjdk.java.net/~erikj/8218084/webrev.01/ > > /Erik > From christian.tornqvist at oracle.com Wed Jan 30 20:50:41 2019 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 30 Jan 2019 12:50:41 -0800 Subject: (urgent) RFR: JDK-8218084: Revert JDK-8218057 In-Reply-To: References: Message-ID: Looks good, thanks for dealing with this so quickly Thanks, Christian > On Jan 30, 2019, at 12:47 PM, Erik Joelsson wrote: > > The addition of new build profiles in jib-profiles.js caused our internal build and test system to break down. While we fix the resilience of that system, we need to back this change out. This patch is the result of: > > $ hg backout 8830bb9587c2 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218084 > > Webrev: http://cr.openjdk.java.net/~erikj/8218084/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Thu Jan 31 08:17:45 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 31 Jan 2019 09:17:45 +0100 Subject: RFR: JDK-8204564: Need better error output when GenerateLinkOptData fails In-Reply-To: <7109ef77-e260-7295-7279-9ea1723d2e12@oracle.com> References: <9902d751-8138-d75f-e084-2d28ee3b4382@oracle.com> <99c3c385-1141-a23c-cecf-a66eb0518961@oracle.com> <7109ef77-e260-7295-7279-9ea1723d2e12@oracle.com> Message-ID: <84257f6f-fe95-a60d-aa6e-0044e9625827@oracle.com> On 2019-01-30 19:45, Erik Joelsson wrote: > Here is a new webrev: > > http://cr.openjdk.java.net/~erikj/8204564/webrev.02/ Looks good to me! /Magnus > > /Erik > > On 2019-01-30 08:52, Erik Joelsson wrote: >> Hello, >> >> On 2019-01-30 01:51, Magnus Ihse Bursie wrote: >>> On 2019-01-30 02:18, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Some recent build failures reminded me of this issue and increased >>>> the need to fix it ASAP to be able to diagnose them. >>>> GenerateLinkOptData.gmk runs a java tool to generate data which is >>>> later used to optimize the JDK image with jlink. The problem here >>>> is that the tool needs to print some of that data on stdout, which >>>> the build captures as one build artifact, and will print some >>>> "garbage" on stderr if things go well. So currently we just hide >>>> all that output from the build log. Because of this, if something >>>> goes wrong, we won't see the error. >>>> >>>> This patch tries to capture the stderr output and only print it >>>> (along with stdout) if the java command fails. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204564 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.01/ >>> >>> Good idea, but could you please include some more information in the >>> case of failure? The classlist data generation gets a lot of blame >>> when the real cause is that the JDK is stillborn. >>> >>> Something like: >>> >>> ??????????? || ( exitcode=$$? && $(ECHO) "ERROR: Classlist file >>> generation failed. This is typically a sign that the newly built JDK >>> is broken, and not of an error in the Classlist generation." && >>> $(ECHO) "Classlist stderr: " && >>> $(CAT) $(LINK_OPT_DIR)/stderr && $(ECHO) "Classlist trace file:" && >>> $(CAT) $(JLI_TRACE_FILE) \ >>> ???????????????? && exit $$exitcode ) >>> >>> but with better line breaks :) >>> >> Sure, but please note that this is not the first time we are running >> the newly built JVM in the build. To run the classlist generation, we >> must first create a couple of jmods and jlink them together into the >> interim image, so the newly built JVM/JDK cannot be completely broken >> for this to happen. >> >> /Erik >> >>> /Magnus >>>> >>>> /Erik >>>> >>> From matthias.baesken at sap.com Thu Jan 31 14:50:43 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 31 Jan 2019 14:50:43 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX Message-ID: Please review this small webrev . It contains a few changes for building hotspot on AIX with xlclang++ / xlc16 . ( most likely switching to xlclang++ / xlc16 will be a must once we introduce C++11/14 features ) Some comments on the changes : - porting_aix.cpp : workaround for demangle.h (does not work with xlclang++) - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to assigning false to AllocateHeapAt which is a bad idea (and does not work with xlclang++) - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not have #error ... in this case Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8218136 http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ Thanks, Matthias From andrew_m_leonard at uk.ibm.com Thu Jan 31 15:01:31 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 31 Jan 2019 15:01:31 +0000 Subject: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: Hiya, I've created and tested a new webrev using lparstat and following your guidelines, webrev.01 is here: http://cr.openjdk.java.net/~aleonard/8217896/webrev.01/ If someone is happy to sponsor and review please? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Magnus Ihse Bursie To: Andrew Leonard , David Holmes Cc: build-dev at openjdk.java.net Date: 30/01/2019 17:16 Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX On 2019-01-30 17:37, Andrew Leonard wrote: > Thanks David, > I just found the reference you mention, it is a little vague, but says > maybe as you said. I've reworked and tested the following which seems > better: > NUM_CORES=`lparstat -m | grep -o "lcpu=[[0-9]]*" | cut -d "=" -f 2` > I'll create a new webrev with this. Note that you should use $GREP and $CUT; in theory we should also check for lparstat, but we've been sloppy with that for the other cpu checking methods so maybe we can be that for AIX here as well. /Magnus > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: David Holmes > To: Erik Joelsson , Andrew Leonard > , build-dev at openjdk.java.net > Date: 30/01/2019 02:25 > Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when > building on AIX > > > > On 30/01/2019 3:05 am, Erik Joelsson wrote: >> Hello, >> >> I'm OK with this, but since I can't verify it at all, I would be more >> comfortable if one of the other AIX users would review this as well. > Ditto. I did some googling on this and pmcycles is flagged as maybe > being deprecated in the future and may require privileges to execute. > lparstat -i seems to be more commonly used. > > David > ----- > >> /Erik >> >> On 2019-01-29 05:08, Andrew Leonard wrote: >>> Hi, >>> Please can I get a sponsor for this build performance enhancement on > AIX, >>> by better determining the number of LCPUs on smt AIX machines: >>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__cr.openjdk.java.net_-7Ealeonard_8217896_webrev.00_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=FpNeQfFJBut0AAVlbC0w7o0urDCArfDb4PY1TtMVW4I&s=8vmPiiNU5P6MnXKdE-eyyBm48kgCssjH5VyWHAt5zcM&e= > >>> My testing shows up to 30% improved build times when leveraging the >>> available LCPUs. >>> Many thanks >>> Andrew >>> >>> Andrew Leonard >>> Java Runtimes Development >>> IBM Hursley >>> IBM United Kingdom Ltd >>> Phone internal: 245913, external: 01962 815913 >>> internet email: andrew_m_leonard at uk.ibm.com >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with > number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From magnus.ihse.bursie at oracle.com Thu Jan 31 20:10:32 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 31 Jan 2019 21:10:32 +0100 Subject: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: > 31 jan. 2019 kl. 16:01 skrev Andrew Leonard : > > Hiya, > I've created and tested a new webrev using lparstat and following your guidelines, webrev.01 is here: > http://cr.openjdk.java.net/~aleonard/8217896/webrev.01/ > If someone is happy to sponsor and review please? This looks good to me. I can sponsor, but won't have time to push it until tomorrow or after the weekend, so if anyone else wants to step in feel free to do so. :) /Magnus > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Magnus Ihse Bursie > To: Andrew Leonard , David Holmes > Cc: build-dev at openjdk.java.net > Date: 30/01/2019 17:16 > Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX > > > > > > On 2019-01-30 17:37, Andrew Leonard wrote: > > Thanks David, > > I just found the reference you mention, it is a little vague, but says > > maybe as you said. I've reworked and tested the following which seems > > better: > > NUM_CORES=`lparstat -m | grep -o "lcpu=[[0-9]]*" | cut -d "=" -f 2` > > I'll create a new webrev with this. > Note that you should use $GREP and $CUT; in theory we should also check > for lparstat, but we've been sloppy with that for the other cpu checking > methods so maybe we can be that for AIX here as well. > > /Magnus > > Thanks > > Andrew > > > > Andrew Leonard > > Java Runtimes Development > > IBM Hursley > > IBM United Kingdom Ltd > > Phone internal: 245913, external: 01962 815913 > > internet email: andrew_m_leonard at uk.ibm.com > > > > > > > > > > From: David Holmes > > To: Erik Joelsson , Andrew Leonard > > , build-dev at openjdk.java.net > > Date: 30/01/2019 02:25 > > Subject: Re: Proposal: JDK-8217896: Make better use of LCPUs when > > building on AIX > > > > > > > > On 30/01/2019 3:05 am, Erik Joelsson wrote: > >> Hello, > >> > >> I'm OK with this, but since I can't verify it at all, I would be more > >> comfortable if one of the other AIX users would review this as well. > > Ditto. I did some googling on this and pmcycles is flagged as maybe > > being deprecated in the future and may require privileges to execute. > > lparstat -i seems to be more commonly used. > > > > David > > ----- > > > >> /Erik > >> > >> On 2019-01-29 05:08, Andrew Leonard wrote: > >>> Hi, > >>> Please can I get a sponsor for this build performance enhancement on > > AIX, > >>> by better determining the number of LCPUs on smt AIX machines: > >>> > > https://cr.openjdk.java.net/~aleonard/8217896/webrev.00/ > > > >>> My testing shows up to 30% improved build times when leveraging the > >>> available LCPUs. > >>> Many thanks > >>> Andrew > >>> > >>> Andrew Leonard > >>> Java Runtimes Development > >>> IBM Hursley > >>> IBM United Kingdom Ltd > >>> Phone internal: 245913, external: 01962 815913 > >>> internet email: andrew_m_leonard at uk.ibm.com > >>> > >>> > >>> Unless stated otherwise above: > >>> IBM United Kingdom Limited - Registered in England and Wales with > > number > >>> 741598. > >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > >>> 3AU > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From magnus.ihse.bursie at oracle.com Thu Jan 31 20:18:48 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 31 Jan 2019 21:18:48 +0100 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: <747D25F3-C523-439F-93FD-E20C7BFCD6B7@oracle.com> Ah, IBM is starting to use clang? That's nice! From what I understand after a quick search, this also means that gcc/clang options are available, and recommended [1] to use. It would be really nice if we could align the xlc options more closely to gcc/clang. /Magnus [1] https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/migrate/xlC_vs_xlclangpp.html > 31 jan. 2019 kl. 15:50 skrev Baesken, Matthias : > > Please review this small webrev . It contains a few changes for building hotspot on AIX with xlclang++ / xlc16 . > ( most likely switching to xlclang++ / xlc16 will be a must once we introduce C++11/14 features ) > > Some comments on the changes : > > > - porting_aix.cpp : workaround for demangle.h (does not work with xlclang++) > > - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to assigning false to AllocateHeapAt which is a bad idea (and does not work with xlclang++) > > - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not have #error ... in this case > > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8218136 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ > > > Thanks, Matthias >