From erik.joelsson at oracle.com Tue Sep 1 09:58:16 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 01 Sep 2015 11:58:16 +0200 Subject: RFR: JDK-8062618 Create a build failure summary at end of build log In-Reply-To: <55E44FC5.7090900@oracle.com> References: <55E44FC5.7090900@oracle.com> Message-ID: <55E576B8.4060105@oracle.com> Looks ok to me. Without actually putting too much thought into it so I might be wrong, but shouldn't it be possible to combine LogFailures and HandleFailure into one call? The calling convention for using them now is quite particular. /Erik On 2015-08-31 14:59, Magnus Ihse Bursie wrote: > When building with multiple parallel jobs, it can be hard to track > down the actual error causing the build to fail. > > This patch addresses this in two parts. Firstly, it tries to locate a > sequence of failing make targets, where the first is the initial > failing target, which is usually very specific, and repeats these at > the end of the build. (This will work only on GNU Make 4) > > Secondly, if the failure occured during compilation or linking, the > actual output of the failing compilation/link command is repeated. > Since the most likely build failure a common developer will encounter > are compilation or link failures, this will hopefully help to make > most build errors quick to resolve. (This will unfortunately not work > for hotspot code until the new Hotspot build system is integrated.) > > An example on how this looks: > ----8<----- > make4[2]: *** Waiting for unfinished jobs.... > > ERROR: Build failed for target 'default' in configuration 'make4' > (exit code 2) > === Output from failing command(s) repeated here === > * For target BUILD_LIBINSTRUMENT_Utilities.c: > /localhome/hg/jdk9-dev-DOH/jdk/src/java.instrument/share/native/libinstrument/Utilities.c:37:1: > error: unknown type name ?intt? > intt apa2; > ^ > === End of repeated output === > === Make failure sequence repeated here === > Lib-java.instrument.gmk:59: recipe for target > '/localhome/hg/jdk9-dev-DOH/build/make4/support/native/java.instrument/libinstrument/Utilities.o' > failed > make/Main.gmk:171: recipe for target 'java.instrument-libs' failed > === End of repeated output === > Hint: Try searching the build log for the name of the first failed > target. > Hint: If caused by a warning, try configure --disable-warnings-as-errors. > ----8<----- > > In case no failed targets were found, at least some assistance is > printed: > ----8<----- > make[2]: *** Waiting for unfinished jobs.... > > ERROR: Build failed for target 'default' in configuration > 'linux-x86_64-normal-server-release' (exit code 2) > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: If caused by a warning, try configure --disable-warnings-as-errors. > ----8<----- > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8062618 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8062618-failure-summary/webrev.01 > > /Magnus > From david.dehaven at oracle.com Tue Sep 1 16:46:38 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 1 Sep 2015 09:46:38 -0700 Subject: Change in hotspot causing build issues on OSX 10.8.5 In-Reply-To: <55DBD107.1030102@oracle.com> References: <55DA9AF9.6010709@oracle.com> <3087F32A-93FC-4D96-9068-D71DAB5DE866@oracle.com> <55DBD107.1030102@oracle.com> Message-ID: <5A62D4EA-5291-416D-B8D5-6EBF9F8F451A@oracle.com> >> and now get the warnings: >> >> --------- >> Compiling 13 files for jdk.policytool >> clang: error: unknown warning option >> '-Wno-tautological-constant-out-of-range-compare'; did you mean >> '-Wno-tautological-compare'? >> make[3]: *** >> [/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/native/java.desktop/libfontmanager/AlternateSubstSubtables.o] >> Error 1 >> make[2]: *** [java.desktop-libs] Error 2 >> -------- >> >> Also see a lot of these messages which I do not recall before > > New warnings are expected when you bump up the compiler version as the compiler gets more and more pedantic. I don't build on OSX so haven't encountered them directly. Yes, clang is very chatty compared to gcc :) When's the next warning cleanup day? -DrD- From peter.brunet at oracle.com Tue Sep 1 17:02:44 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 1 Sep 2015 12:02:44 -0500 Subject: How to make install images Message-ID: <55E5DA34.5060405@oracle.com> Hi, How do I make an install image (not just the binary trees I see with make images)? I need to do a 32 bit build on 64 bit W7 and then install on a 32 bit W7 VM. In my case the 32 bit install meant for 64 bit W7 isn't suitable for install on a 32 bit W7. Pete From philip.race at oracle.com Tue Sep 1 17:09:19 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 01 Sep 2015 10:09:19 -0700 Subject: How to make install images In-Reply-To: <55E5DA34.5060405@oracle.com> References: <55E5DA34.5060405@oracle.com> Message-ID: <55E5DBBF.9030503@oracle.com> Pete, The windows installer is not part of OpenJDK so you should redirect this question to a different list. -phil. On 09/01/2015 10:02 AM, Pete Brunet wrote: > Hi, How do I make an install image (not just the binary trees I see with > make images)? I need to do a 32 bit build on 64 bit W7 and then install > on a 32 bit W7 VM. In my case the 32 bit install meant for 64 bit W7 > isn't suitable for install on a 32 bit W7. > > Pete From philip.race at oracle.com Tue Sep 1 19:02:00 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 01 Sep 2015 12:02:00 -0700 Subject: Change in hotspot causing build issues on OSX 10.8.5 In-Reply-To: <5A62D4EA-5291-416D-B8D5-6EBF9F8F451A@oracle.com> References: <55DA9AF9.6010709@oracle.com> <3087F32A-93FC-4D96-9068-D71DAB5DE866@oracle.com> <55DBD107.1030102@oracle.com> <5A62D4EA-5291-416D-B8D5-6EBF9F8F451A@oracle.com> Message-ID: <55E5F628.40900@oracle.com> The problem with this specific warning is it is in a 3rd party library. I generally opt for just disabling those until upstream resolves it. -phil. On 09/01/2015 09:46 AM, David DeHaven wrote: >>> and now get the warnings: >>> >>> --------- >>> Compiling 13 files for jdk.policytool >>> clang: error: unknown warning option >>> '-Wno-tautological-constant-out-of-range-compare'; did you mean >>> '-Wno-tautological-compare'? >>> make[3]: *** >>> [/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/native/java.desktop/libfontmanager/AlternateSubstSubtables.o] >>> Error 1 >>> make[2]: *** [java.desktop-libs] Error 2 >>> -------- >>> >>> Also see a lot of these messages which I do not recall before >> New warnings are expected when you bump up the compiler version as the compiler gets more and more pedantic. I don't build on OSX so haven't encountered them directly. > Yes, clang is very chatty compared to gcc :) > > When's the next warning cleanup day? > > -DrD- > From peter.brunet at oracle.com Wed Sep 2 02:02:47 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 1 Sep 2015 21:02:47 -0500 Subject: RfR JDK-8134453,JAWS crashes in WindowsAccessBridge.DLL on 32 bit 8u60 running on 32 bit Win 7 Message-ID: <55E658C7.3040604@oracle.com> Hi I need two reviewers for http://cr.openjdk.java.net/~ptbrunet/JDK-8134453/webrev.00/ This problem started in 8u60 b20 and is due to JDK-8078649 which is a backport of JDK-8043160. In this fix the text "LEGACY" in file jdk/make/lib/PlatformLibraries.gmk was changed to "legacy". The lower case legacy is used in a -D compiler flag and as a result doesn't activate lines like this in the source code: #ifdef ACCESSBRIDGE_ARCH_LEGACY This causes problems with 32 bit builds for 32 bit Win. I tested the fix by doing a 32 bit Win build and then installing and testing that build on a 32 bit Win 7 VM. Pete From erik.joelsson at oracle.com Wed Sep 2 07:38:42 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 02 Sep 2015 09:38:42 +0200 Subject: RfR JDK-8134453,JAWS crashes in WindowsAccessBridge.DLL on 32 bit 8u60 running on 32 bit Win 7 In-Reply-To: <55E658C7.3040604@oracle.com> References: <55E658C7.3040604@oracle.com> Message-ID: <55E6A782.7020707@oracle.com> Hello Pete, While this may work, I would not like to rely on case insensitivity in the directory name for the headers. I would like that you also change legacy->LEGACY in CompileJavaClasses.gmk where the headers are generated. /Erik On 2015-09-02 04:02, Pete Brunet wrote: > Hi I need two reviewers for > http://cr.openjdk.java.net/~ptbrunet/JDK-8134453/webrev.00/ > > This problem started in 8u60 b20 and is due to JDK-8078649 which is a > backport of JDK-8043160. In this fix the text "LEGACY" in file > jdk/make/lib/PlatformLibraries.gmk was changed to "legacy". The lower > case legacy is used in a -D compiler flag and as a result doesn't > activate lines like this in the source code: > > #ifdef ACCESSBRIDGE_ARCH_LEGACY > > This causes problems with 32 bit builds for 32 bit Win. > > I tested the fix by doing a 32 bit Win build and then installing and > testing that build on a 32 bit Win 7 VM. > > Pete > From peter.brunet at oracle.com Thu Sep 3 01:51:40 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 2 Sep 2015 20:51:40 -0500 Subject: RfR JDK-8134453, JAWS crashes in WindowsAccessBridge.DLL on 32 bit 8u60 running on 32 bit Win 7 In-Reply-To: <55E6A782.7020707@oracle.com> References: <55E658C7.3040604@oracle.com> <55E6A782.7020707@oracle.com> Message-ID: <55E7A7AC.6090504@oracle.com> Thanks Erik, The new webrev is at http://cr.openjdk.java.net/~ptbrunet/JDK-8134453/webrev.01/ Do you (and Tim) approve? Pete On 9/2/15 2:38 AM, Erik Joelsson wrote: > Hello Pete, > > While this may work, I would not like to rely on case insensitivity in > the directory name for the headers. I would like that you also change > legacy->LEGACY in CompileJavaClasses.gmk where the headers are generated. > > /Erik > > On 2015-09-02 04:02, Pete Brunet wrote: >> Hi I need two reviewers for >> http://cr.openjdk.java.net/~ptbrunet/JDK-8134453/webrev.00/ >> >> This problem started in 8u60 b20 and is due to JDK-8078649 which is a >> backport of JDK-8043160. In this fix the text "LEGACY" in file >> jdk/make/lib/PlatformLibraries.gmk was changed to "legacy". The lower >> case legacy is used in a -D compiler flag and as a result doesn't >> activate lines like this in the source code: >> >> #ifdef ACCESSBRIDGE_ARCH_LEGACY >> >> This causes problems with 32 bit builds for 32 bit Win. >> >> I tested the fix by doing a 32 bit Win build and then installing and >> testing that build on a 32 bit Win 7 VM. >> >> Pete >> > From tim.bell at oracle.com Thu Sep 3 04:46:09 2015 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 02 Sep 2015 21:46:09 -0700 Subject: RfR JDK-8134453, JAWS crashes in WindowsAccessBridge.DLL on 32 bit 8u60 running on 32 bit Win 7 In-Reply-To: <55E7A7AC.6090504@oracle.com> References: <55E658C7.3040604@oracle.com> <55E6A782.7020707@oracle.com> <55E7A7AC.6090504@oracle.com> Message-ID: <55E7D091.10103@oracle.com> Hi Pete- Looks good to me. Tim On 09/02/15 18:51, Pete Brunet wrote: > Thanks Erik, The new webrev is at > http://cr.openjdk.java.net/~ptbrunet/JDK-8134453/webrev.01/ > > Do you (and Tim) approve? > > Pete > > On 9/2/15 2:38 AM, Erik Joelsson wrote: >> Hello Pete, >> >> While this may work, I would not like to rely on case insensitivity in >> the directory name for the headers. I would like that you also change >> legacy->LEGACY in CompileJavaClasses.gmk where the headers are generated. >> >> /Erik >> >> On 2015-09-02 04:02, Pete Brunet wrote: >>> Hi I need two reviewers for >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134453/webrev.00/ >>> >>> This problem started in 8u60 b20 and is due to JDK-8078649 which is a >>> backport of JDK-8043160. In this fix the text "LEGACY" in file >>> jdk/make/lib/PlatformLibraries.gmk was changed to "legacy". The lower >>> case legacy is used in a -D compiler flag and as a result doesn't >>> activate lines like this in the source code: >>> >>> #ifdef ACCESSBRIDGE_ARCH_LEGACY >>> >>> This causes problems with 32 bit builds for 32 bit Win. >>> >>> I tested the fix by doing a 32 bit Win build and then installing and >>> testing that build on a 32 bit Win 7 VM. >>> >>> Pete >>> From erik.joelsson at oracle.com Thu Sep 3 07:39:14 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 03 Sep 2015 09:39:14 +0200 Subject: RfR JDK-8134453, JAWS crashes in WindowsAccessBridge.DLL on 32 bit 8u60 running on 32 bit Win 7 In-Reply-To: <55E7D091.10103@oracle.com> References: <55E658C7.3040604@oracle.com> <55E6A782.7020707@oracle.com> <55E7A7AC.6090504@oracle.com> <55E7D091.10103@oracle.com> Message-ID: <55E7F922.2010709@oracle.com> Looks good, thanks. /Erik On 2015-09-03 06:46, Tim Bell wrote: > Hi Pete- > > Looks good to me. > > Tim > > > On 09/02/15 18:51, Pete Brunet wrote: >> Thanks Erik, The new webrev is at >> http://cr.openjdk.java.net/~ptbrunet/JDK-8134453/webrev.01/ >> >> Do you (and Tim) approve? >> >> Pete >> >> On 9/2/15 2:38 AM, Erik Joelsson wrote: >>> Hello Pete, >>> >>> While this may work, I would not like to rely on case insensitivity in >>> the directory name for the headers. I would like that you also change >>> legacy->LEGACY in CompileJavaClasses.gmk where the headers are >>> generated. >>> >>> /Erik >>> >>> On 2015-09-02 04:02, Pete Brunet wrote: >>>> Hi I need two reviewers for >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134453/webrev.00/ >>>> >>>> This problem started in 8u60 b20 and is due to JDK-8078649 which is a >>>> backport of JDK-8043160. In this fix the text "LEGACY" in file >>>> jdk/make/lib/PlatformLibraries.gmk was changed to "legacy". The lower >>>> case legacy is used in a -D compiler flag and as a result doesn't >>>> activate lines like this in the source code: >>>> >>>> #ifdef ACCESSBRIDGE_ARCH_LEGACY >>>> >>>> This causes problems with 32 bit builds for 32 bit Win. >>>> >>>> I tested the fix by doing a 32 bit Win build and then installing and >>>> testing that build on a 32 bit Win 7 VM. >>>> >>>> Pete >>>> > From magnus.ihse.bursie at oracle.com Thu Sep 3 07:48:05 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 Sep 2015 09:48:05 +0200 Subject: RFR: JDK-8062618 Create a build failure summary at end of build log In-Reply-To: <55E576B8.4060105@oracle.com> References: <55E44FC5.7090900@oracle.com> <55E576B8.4060105@oracle.com> Message-ID: <55E7FB35.3030802@oracle.com> On 2015-09-01 11:58, Erik Joelsson wrote: > Looks ok to me. > > Without actually putting too much thought into it so I might be wrong, > but shouldn't it be possible to combine LogFailures and HandleFailure > into one call? The calling convention for using them now is quite > particular. I didn't think it was possible due to the pecularities of the Windows call, but it turned out I was wrong. :) Thanks for making me try harder converting this into a sane API. :) New webrev: http://cr.openjdk.java.net/~ihse/JDK-8062618-failure-summary/webrev.02 /Magnus > > /Erik > > On 2015-08-31 14:59, Magnus Ihse Bursie wrote: >> When building with multiple parallel jobs, it can be hard to track >> down the actual error causing the build to fail. >> >> This patch addresses this in two parts. Firstly, it tries to locate a >> sequence of failing make targets, where the first is the initial >> failing target, which is usually very specific, and repeats these at >> the end of the build. (This will work only on GNU Make 4) >> >> Secondly, if the failure occured during compilation or linking, the >> actual output of the failing compilation/link command is repeated. >> Since the most likely build failure a common developer will encounter >> are compilation or link failures, this will hopefully help to make >> most build errors quick to resolve. (This will unfortunately not work >> for hotspot code until the new Hotspot build system is integrated.) >> >> An example on how this looks: >> ----8<----- >> make4[2]: *** Waiting for unfinished jobs.... >> >> ERROR: Build failed for target 'default' in configuration 'make4' >> (exit code 2) >> === Output from failing command(s) repeated here === >> * For target BUILD_LIBINSTRUMENT_Utilities.c: >> /localhome/hg/jdk9-dev-DOH/jdk/src/java.instrument/share/native/libinstrument/Utilities.c:37:1: >> error: unknown type name ?intt? >> intt apa2; >> ^ >> === End of repeated output === >> === Make failure sequence repeated here === >> Lib-java.instrument.gmk:59: recipe for target >> '/localhome/hg/jdk9-dev-DOH/build/make4/support/native/java.instrument/libinstrument/Utilities.o' >> failed >> make/Main.gmk:171: recipe for target 'java.instrument-libs' failed >> === End of repeated output === >> Hint: Try searching the build log for the name of the first failed >> target. >> Hint: If caused by a warning, try configure >> --disable-warnings-as-errors. >> ----8<----- >> >> In case no failed targets were found, at least some assistance is >> printed: >> ----8<----- >> make[2]: *** Waiting for unfinished jobs.... >> >> ERROR: Build failed for target 'default' in configuration >> 'linux-x86_64-normal-server-release' (exit code 2) >> No indication of failed target found. >> Hint: Try searching the build log for '] Error'. >> Hint: If caused by a warning, try configure >> --disable-warnings-as-errors. >> ----8<----- >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8062618 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8062618-failure-summary/webrev.01 >> >> /Magnus >> > From erik.joelsson at oracle.com Thu Sep 3 07:55:56 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 03 Sep 2015 09:55:56 +0200 Subject: RFR: JDK-8062618 Create a build failure summary at end of build log In-Reply-To: <55E7FB35.3030802@oracle.com> References: <55E44FC5.7090900@oracle.com> <55E576B8.4060105@oracle.com> <55E7FB35.3030802@oracle.com> Message-ID: <55E7FD0C.9000504@oracle.com> That looks better, thanks! /Erik On 2015-09-03 09:48, Magnus Ihse Bursie wrote: > On 2015-09-01 11:58, Erik Joelsson wrote: >> Looks ok to me. >> >> Without actually putting too much thought into it so I might be >> wrong, but shouldn't it be possible to combine LogFailures and >> HandleFailure into one call? The calling convention for using them >> now is quite particular. > > I didn't think it was possible due to the pecularities of the Windows > call, but it turned out I was wrong. :) Thanks for making me try > harder converting this into a sane API. :) > > New webrev: > http://cr.openjdk.java.net/~ihse/JDK-8062618-failure-summary/webrev.02 > > /Magnus > >> >> /Erik >> >> On 2015-08-31 14:59, Magnus Ihse Bursie wrote: >>> When building with multiple parallel jobs, it can be hard to track >>> down the actual error causing the build to fail. >>> >>> This patch addresses this in two parts. Firstly, it tries to locate >>> a sequence of failing make targets, where the first is the initial >>> failing target, which is usually very specific, and repeats these at >>> the end of the build. (This will work only on GNU Make 4) >>> >>> Secondly, if the failure occured during compilation or linking, the >>> actual output of the failing compilation/link command is repeated. >>> Since the most likely build failure a common developer will >>> encounter are compilation or link failures, this will hopefully help >>> to make most build errors quick to resolve. (This will unfortunately >>> not work for hotspot code until the new Hotspot build system is >>> integrated.) >>> >>> An example on how this looks: >>> ----8<----- >>> make4[2]: *** Waiting for unfinished jobs.... >>> >>> ERROR: Build failed for target 'default' in configuration 'make4' >>> (exit code 2) >>> === Output from failing command(s) repeated here === >>> * For target BUILD_LIBINSTRUMENT_Utilities.c: >>> /localhome/hg/jdk9-dev-DOH/jdk/src/java.instrument/share/native/libinstrument/Utilities.c:37:1: >>> error: unknown type name ?intt? >>> intt apa2; >>> ^ >>> === End of repeated output === >>> === Make failure sequence repeated here === >>> Lib-java.instrument.gmk:59: recipe for target >>> '/localhome/hg/jdk9-dev-DOH/build/make4/support/native/java.instrument/libinstrument/Utilities.o' >>> failed >>> make/Main.gmk:171: recipe for target 'java.instrument-libs' failed >>> === End of repeated output === >>> Hint: Try searching the build log for the name of the first failed >>> target. >>> Hint: If caused by a warning, try configure >>> --disable-warnings-as-errors. >>> ----8<----- >>> >>> In case no failed targets were found, at least some assistance is >>> printed: >>> ----8<----- >>> make[2]: *** Waiting for unfinished jobs.... >>> >>> ERROR: Build failed for target 'default' in configuration >>> 'linux-x86_64-normal-server-release' (exit code 2) >>> No indication of failed target found. >>> Hint: Try searching the build log for '] Error'. >>> Hint: If caused by a warning, try configure >>> --disable-warnings-as-errors. >>> ----8<----- >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8062618 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8062618-failure-summary/webrev.01 >>> >>> /Magnus >>> >> > From maurizio.cimadamore at oracle.com Thu Sep 3 10:20:59 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 3 Sep 2015 11:20:59 +0100 Subject: CCACHE build error Message-ID: <55E81F0B.7070600@oracle.com> Hi, I'm getting a build failure containing the following error (there are more - but all similar to this): /w/lt/9/dev/common/bin/logger.sh: line 44: CCACHE_COMPRESS=1: command not found I have --enable-ccache in my configure - if I disable it, everything is fine; started to happen very recently. I'm on Ubuntu 14.04 (x64). Maurizio From erik.joelsson at oracle.com Thu Sep 3 10:34:44 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 03 Sep 2015 12:34:44 +0200 Subject: CCACHE build error In-Reply-To: <55E81F0B.7070600@oracle.com> References: <55E81F0B.7070600@oracle.com> Message-ID: <55E82244.7090800@oracle.com> This looks like it's caused by JDK-8062618. For now disabling ccache is the best option. Thanks for the report! /Erik On 2015-09-03 12:20, Maurizio Cimadamore wrote: > Hi, > I'm getting a build failure containing the following error (there are > more - but all similar to this): > > /w/lt/9/dev/common/bin/logger.sh: line 44: CCACHE_COMPRESS=1: command > not found > > I have --enable-ccache in my configure - if I disable it, everything > is fine; started to happen very recently. I'm on Ubuntu 14.04 (x64). > > Maurizio > From magnus.ihse.bursie at oracle.com Thu Sep 3 12:54:33 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 Sep 2015 14:54:33 +0200 Subject: CCACHE build error In-Reply-To: <55E82244.7090800@oracle.com> References: <55E81F0B.7070600@oracle.com> <55E82244.7090800@oracle.com> Message-ID: <55E84309.1000303@oracle.com> On 2015-09-03 12:34, Erik Joelsson wrote: > This looks like it's caused by JDK-8062618. For now disabling ccache > is the best option. Thanks for the report! I've opened https://bugs.openjdk.java.net/browse/JDK-8135014 and will post a fix shortly. /Magnus > > /Erik > > On 2015-09-03 12:20, Maurizio Cimadamore wrote: >> Hi, >> I'm getting a build failure containing the following error (there are >> more - but all similar to this): >> >> /w/lt/9/dev/common/bin/logger.sh: line 44: CCACHE_COMPRESS=1: command >> not found >> >> I have --enable-ccache in my configure - if I disable it, everything >> is fine; started to happen very recently. I'm on Ubuntu 14.04 (x64). >> >> Maurizio >> > From magnus.ihse.bursie at oracle.com Thu Sep 3 12:56:19 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 Sep 2015 14:56:19 +0200 Subject: RFR: JDK-8135014 logger.sh needs to handle commands with variable assignment prefixes Message-ID: <55E84373.80409@oracle.com> JDK-8062618 introduced a regression for running ccache. It turned out that logger.sh, which is now used when compiling, could not handle command lines such as "VAR1=val1 /usr/bin/cmd VAR2=val2". For ccache, variable prefixes such as CCACHE_COMPRESS=1 was used, which caused build failures. Bug: https://bugs.openjdk.java.net/browse/JDK-8135014 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8135014-logger-sh-variable-prefixes/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Sep 3 13:00:11 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 03 Sep 2015 15:00:11 +0200 Subject: RFR: JDK-8135014 logger.sh needs to handle commands with variable assignment prefixes In-Reply-To: <55E84373.80409@oracle.com> References: <55E84373.80409@oracle.com> Message-ID: <55E8445B.1090104@oracle.com> Looks like it should work. /Erik On 2015-09-03 14:56, Magnus Ihse Bursie wrote: > JDK-8062618 introduced a regression for running ccache. It turned out > that logger.sh, which is now used when compiling, could not handle > command lines such as "VAR1=val1 /usr/bin/cmd VAR2=val2". For ccache, > variable prefixes such as CCACHE_COMPRESS=1 was used, which caused > build failures. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135014 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8135014-logger-sh-variable-prefixes/webrev.01 > > /Magnus > From maurizio.cimadamore at oracle.com Thu Sep 3 22:55:40 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 3 Sep 2015 23:55:40 +0100 Subject: CCACHE build error In-Reply-To: <55E84309.1000303@oracle.com> References: <55E81F0B.7070600@oracle.com> <55E82244.7090800@oracle.com> <55E84309.1000303@oracle.com> Message-ID: <55E8CFEC.4020501@oracle.com> Thanks for the quick turnaround! Maurizio On 03/09/15 13:54, Magnus Ihse Bursie wrote: > On 2015-09-03 12:34, Erik Joelsson wrote: >> This looks like it's caused by JDK-8062618. For now disabling ccache >> is the best option. Thanks for the report! > I've opened https://bugs.openjdk.java.net/browse/JDK-8135014 and will > post a fix shortly. > > /Magnus > >> >> /Erik >> >> On 2015-09-03 12:20, Maurizio Cimadamore wrote: >>> Hi, >>> I'm getting a build failure containing the following error (there >>> are more - but all similar to this): >>> >>> /w/lt/9/dev/common/bin/logger.sh: line 44: CCACHE_COMPRESS=1: >>> command not found >>> >>> I have --enable-ccache in my configure - if I disable it, everything >>> is fine; started to happen very recently. I'm on Ubuntu 14.04 (x64). >>> >>> Maurizio >>> >> > From huzaifanazir89 at yahoo.com Fri Sep 4 11:35:56 2015 From: huzaifanazir89 at yahoo.com (Huzaifa Nazir) Date: Fri, 4 Sep 2015 11:35:56 +0000 (UTC) Subject: Can icedtea's web browser plugin be ported to windows ? Message-ID: <169462635.1579631.1441366556458.JavaMail.yahoo@mail.yahoo.com> Hi, - I have used windows unofficial openjdk port from here?https://github.com/alexkasko/openjdk-unofficial-builds - Tried porting icedtea's web plugin under cygwin from here?http://icedtea.wildebeest.org/download/source/icedtea-web-1.5.tar.gz but it failed with following Errors: - ?initially it was failing to find X11.EmbeddedFrame class in OpenJDK ?["configure: error: sun.awt.X11.XEmbeddedFrame not found"] - upon skipping the class check, it started requiring some methods related to applets within OpenJDK to be public which in the used OpenJDK were private How can icedtea's web plugin component be ported to windows??is it even possible? Regards,Xaifee From mail at alexkasko.com Fri Sep 4 12:23:18 2015 From: mail at alexkasko.com (Alex Kashchenko) Date: Fri, 04 Sep 2015 13:23:18 +0100 Subject: Can icedtea's web browser plugin be ported to windows ? In-Reply-To: <169462635.1579631.1441366556458.JavaMail.yahoo@mail.yahoo.com> References: <169462635.1579631.1441366556458.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55E98D36.9080902@alexkasko.com> Hi, On 09/04/2015 12:35 PM, Huzaifa Nazir wrote: > > Hi, > - I have used windows unofficial openjdk port from here https://github.com/alexkasko/openjdk-unofficial-builds > - Tried porting icedtea's web plugin under cygwin from here http://icedtea.wildebeest.org/download/source/icedtea-web-1.5.tar.gz > but it failed with following Errors: > - initially it was failing to find X11.EmbeddedFrame class in OpenJDK ["configure: error: sun.awt.X11.XEmbeddedFrame not found"] > - upon skipping the class check, it started requiring some methods related to applets within OpenJDK to be public which in the used OpenJDK were private > > How can icedtea's web plugin component be ported to windows? is it even possible? I know there were discussions about Windows support in IcedTea Web browser plugin [1] on distro-pkg-dev list (CC'ing it), but I don't know whether there were any results. Also WebStart module from IcedTea Web should work fine on all platforms running as following (from the command line, outside of the browser): java -Xbootclasspath/a:netx.jar net.sourceforge.jnlp.runtime.Boot some.jnlp [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-September/029509.html -- -Alex From magnus.ihse.bursie at oracle.com Tue Sep 8 12:45:31 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 8 Sep 2015 14:45:31 +0200 Subject: RFR: JDK-8135180 Print configure arguments using make print-configuration Message-ID: <55EED86B.8030703@oracle.com> A common need when working with complex configure argument lists is to figure out what configuration that's currently being used. This patch introduces a new make target "print-configuration" which will just print the arguments used to run configure. Bug: https://bugs.openjdk.java.net/browse/JDK-8135180 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8135180-make-print-configuration/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Sep 8 18:53:12 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 8 Sep 2015 20:53:12 +0200 Subject: RFR: JDK-8065912 Better handling of classpath in build-infra Message-ID: <55EF2E98.9090007@oracle.com> It is tricky to get correct handling on all platforms of class paths containing more than one entry. This logic should be encapsulated in a global function instead. A new helper function PathList will format claspaths correctly. A new argument CLASSPATH to SetupJavaCompilation will facilitate giving an explicit classpath to compilations. Bug: https://bugs.openjdk.java.net/browse/JDK-8065912 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065912-better-classpath-handling/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Sep 9 07:25:19 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 09 Sep 2015 09:25:19 +0200 Subject: RFR: JDK-8065912 Better handling of classpath in build-infra In-Reply-To: <55EF2E98.9090007@oracle.com> References: <55EF2E98.9090007@oracle.com> Message-ID: <55EFDEDF.4010803@oracle.com> In JavaCompilation.gmk, could you add the new CLASSPATH parameter to the documentation comment? Otherwise, very nice! /Erik On 2015-09-08 20:53, Magnus Ihse Bursie wrote: > It is tricky to get correct handling on all platforms of class paths > containing more than one entry. This logic should be encapsulated in a > global function instead. > > A new helper function PathList will format claspaths correctly. A new > argument CLASSPATH to SetupJavaCompilation will facilitate giving an > explicit classpath to compilations. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065912 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8065912-better-classpath-handling/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Wed Sep 9 07:35:40 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 9 Sep 2015 09:35:40 +0200 Subject: RFR: JDK-8065912 Better handling of classpath in build-infra In-Reply-To: <55EFDEDF.4010803@oracle.com> References: <55EF2E98.9090007@oracle.com> <55EFDEDF.4010803@oracle.com> Message-ID: <55EFE14C.5090303@oracle.com> On 2015-09-09 09:25, Erik Joelsson wrote: > In JavaCompilation.gmk, could you add the new CLASSPATH parameter to > the documentation comment? Of course. diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk --- a/make/common/JavaCompilation.gmk +++ b/make/common/JavaCompilation.gmk @@ -403,6 +403,7 @@ # SRC:=one or more directories to search for sources. The order of the source roots # is significant. The first found file of a certain name has priority. # BIN:=store classes here +# CLASSPATH:=a list of additional entries to set as classpath to javac # INCLUDES:=myapp.foo means will only compile java files in myapp.foo or any of its sub-packages. # EXCLUDES:=myapp.foo means will do not compile java files in myapp.foo or any of its sub-packages. # COPY:=.prp means copy all prp files to the corresponding package in BIN. > Otherwise, very nice! Thanks! /Magnus From erik.joelsson at oracle.com Wed Sep 9 07:41:20 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 09 Sep 2015 09:41:20 +0200 Subject: RFR: JDK-8065912 Better handling of classpath in build-infra In-Reply-To: <55EFE14C.5090303@oracle.com> References: <55EF2E98.9090007@oracle.com> <55EFDEDF.4010803@oracle.com> <55EFE14C.5090303@oracle.com> Message-ID: <55EFE2A0.3060101@oracle.com> Thanks, looks good. /Erik On 2015-09-09 09:35, Magnus Ihse Bursie wrote: > On 2015-09-09 09:25, Erik Joelsson wrote: >> In JavaCompilation.gmk, could you add the new CLASSPATH parameter to >> the documentation comment? > Of course. > > diff --git a/make/common/JavaCompilation.gmk > b/make/common/JavaCompilation.gmk > --- a/make/common/JavaCompilation.gmk > +++ b/make/common/JavaCompilation.gmk > @@ -403,6 +403,7 @@ > # SRC:=one or more directories to search for sources. The order of > the source roots > # is significant. The first found file of a certain name has > priority. > # BIN:=store classes here > +# CLASSPATH:=a list of additional entries to set as classpath to javac > # INCLUDES:=myapp.foo means will only compile java files in > myapp.foo or any of its sub-packages. > # EXCLUDES:=myapp.foo means will do not compile java files in > myapp.foo or any of its sub-packages. > # COPY:=.prp means copy all prp files to the corresponding package > in BIN. > >> Otherwise, very nice! > Thanks! > > /Magnus From erik.joelsson at oracle.com Wed Sep 9 07:44:08 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 09 Sep 2015 09:44:08 +0200 Subject: RFR: JDK-8135180 Print configure arguments using make print-configuration In-Reply-To: <55EED86B.8030703@oracle.com> References: <55EED86B.8030703@oracle.com> Message-ID: <55EFE348.5040905@oracle.com> Looks good. /Erik On 2015-09-08 14:45, Magnus Ihse Bursie wrote: > A common need when working with complex configure argument lists is to > figure out what configuration that's currently being used. > > This patch introduces a new make target "print-configuration" which > will just print the arguments used to run configure. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135180 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8135180-make-print-configuration/webrev.01 > > /Magnus From daniil.x.titov at oracle.com Wed Sep 9 21:12:05 2015 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 9 Sep 2015 14:12:05 -0700 (PDT) Subject: RFR: 8135083 Product version string for DLLs and EXEs should not include trailing zeros Message-ID: This review request is a part of the work for JEP-223 that adjusts the changes in RC_FLAGS implemented in the initial patch "JDK-8085822 JEP 223: New Version-String Scheme (initial integration)" to ensure that the product version string for Windows DLL/EXEs consists of dot-separated digits WITHOUT trailing zeros. Bug: https://bugs.openjdk.java.net/browse/JDK-8135083 The changes are in one line only (please see inline diff below, changes in generated common/autoconf/generated-configure.sh are omitted). diff -r 35e118e5bcb4 common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 Tue Sep 08 10:24:22 2015 -0700 +++ b/common/autoconf/flags.m4 Wed Sep 09 13:52:54 2015 -0700 @@ -102,7 +102,7 @@ -D\"JDK_VERSION_STRING=\$(VERSION_STRING)\" \ -D\"JDK_COMPANY=\$(COMPANY_NAME)\" \ -D\"JDK_COMPONENT=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) binary\" \ - -D\"JDK_VER=\$(VERSION_NUMBER_FOUR_POSITIONS)\" \ + -D\"JDK_VER=\$(VERSION_NUMBER)\" \ -D\"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \ -D\"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) \$(VERSION_MAJOR)\" \ -D\"JDK_FVER=\$(subst .,\$(COMMA),\$(VERSION_NUMBER_FOUR_POSITIONS))\"" [1] http://openjdk.java.net/jeps/223 Thanks! Best regards, Daniil From iris.clark at oracle.com Wed Sep 9 21:17:57 2015 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 9 Sep 2015 14:17:57 -0700 (PDT) Subject: RFR: 8135083 Product version string for DLLs and EXEs should not include trailing zeros In-Reply-To: References: Message-ID: <777c42e8-03e6-4e50-8d8c-f997e9592e04@default> Hi, Daniil. You change looks good to me. Thanks for tracking down this issue. Regards, iris (not a Reviewer) -----Original Message----- From: Daniil Titov Sent: Wednesday, September 09, 2015 2:12 PM To: build-dev at openjdk.java.net Cc: verona-dev at openjdk.java.net Subject: RFR: 8135083 Product version string for DLLs and EXEs should not include trailing zeros This review request is a part of the work for JEP-223 that adjusts the changes in RC_FLAGS implemented in the initial patch "JDK-8085822 JEP 223: New Version-String Scheme (initial integration)" to ensure that the product version string for Windows DLL/EXEs consists of dot-separated digits WITHOUT trailing zeros. Bug: https://bugs.openjdk.java.net/browse/JDK-8135083 The changes are in one line only (please see inline diff below, changes in generated common/autoconf/generated-configure.sh are omitted). diff -r 35e118e5bcb4 common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 Tue Sep 08 10:24:22 2015 -0700 +++ b/common/autoconf/flags.m4 Wed Sep 09 13:52:54 2015 -0700 @@ -102,7 +102,7 @@ -D\"JDK_VERSION_STRING=\$(VERSION_STRING)\" \ -D\"JDK_COMPANY=\$(COMPANY_NAME)\" \ -D\"JDK_COMPONENT=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) binary\" \ - -D\"JDK_VER=\$(VERSION_NUMBER_FOUR_POSITIONS)\" \ + -D\"JDK_VER=\$(VERSION_NUMBER)\" \ -D\"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \ -D\"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) \$(VERSION_MAJOR)\" \ -D\"JDK_FVER=\$(subst .,\$(COMMA),\$(VERSION_NUMBER_FOUR_POSITIONS))\"" [1] http://openjdk.java.net/jeps/223 Thanks! Best regards, Daniil From david.katleman at oracle.com Wed Sep 9 21:24:09 2015 From: david.katleman at oracle.com (David Katleman) Date: Wed, 9 Sep 2015 14:24:09 -0700 Subject: RFR: 8135083 Product version string for DLLs and EXEs should not include trailing zeros In-Reply-To: References: Message-ID: <55F0A379.2070209@oracle.com> Change looks correct Daniil and I don't see any other instances where VERSION_NUMBER_FOUR_POSITIONS is incorrectly used. Approved. Dave On 9/9/2015 2:12 PM, Daniil Titov wrote: > This review request is a part of the work for JEP-223 that adjusts the changes in RC_FLAGS implemented in the initial patch "JDK-8085822 JEP 223: New Version-String Scheme (initial integration)" to ensure that the product version string for Windows DLL/EXEs consists of dot-separated digits WITHOUT trailing zeros. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135083 > > > > The changes are in one line only (please see inline diff below, changes in generated common/autoconf/generated-configure.sh are omitted). > > > > diff -r 35e118e5bcb4 common/autoconf/flags.m4 > > --- a/common/autoconf/flags.m4 Tue Sep 08 10:24:22 2015 -0700 > > +++ b/common/autoconf/flags.m4 Wed Sep 09 13:52:54 2015 -0700 > > @@ -102,7 +102,7 @@ > > -D\"JDK_VERSION_STRING=\$(VERSION_STRING)\" \ > > -D\"JDK_COMPANY=\$(COMPANY_NAME)\" \ > > -D\"JDK_COMPONENT=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) binary\" \ > > - -D\"JDK_VER=\$(VERSION_NUMBER_FOUR_POSITIONS)\" \ > > + -D\"JDK_VER=\$(VERSION_NUMBER)\" \ > > -D\"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \ > > -D\"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) \$(VERSION_MAJOR)\" \ > > -D\"JDK_FVER=\$(subst .,\$(COMMA),\$(VERSION_NUMBER_FOUR_POSITIONS))\"" > > > > [1] http://openjdk.java.net/jeps/223 > > > > Thanks! > > > > Best regards, > > Daniil > > From magnus.ihse.bursie at oracle.com Thu Sep 10 07:01:31 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 10 Sep 2015 09:01:31 +0200 Subject: RFR: 8135083 Product version string for DLLs and EXEs should not include trailing zeros In-Reply-To: References: Message-ID: <55F12ACB.2030907@oracle.com> On 2015-09-09 23:12, Daniil Titov wrote: > This review request is a part of the work for JEP-223 that adjusts the changes in RC_FLAGS implemented in the initial patch "JDK-8085822 JEP 223: New Version-String Scheme (initial integration)" to ensure that the product version string for Windows DLL/EXEs consists of dot-separated digits WITHOUT trailing zeros. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135083 > > > > The changes are in one line only (please see inline diff below, changes in generated common/autoconf/generated-configure.sh are omitted). > > > > diff -r 35e118e5bcb4 common/autoconf/flags.m4 > > --- a/common/autoconf/flags.m4 Tue Sep 08 10:24:22 2015 -0700 > > +++ b/common/autoconf/flags.m4 Wed Sep 09 13:52:54 2015 -0700 > > @@ -102,7 +102,7 @@ > > -D\"JDK_VERSION_STRING=\$(VERSION_STRING)\" \ > > -D\"JDK_COMPANY=\$(COMPANY_NAME)\" \ > > -D\"JDK_COMPONENT=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) binary\" \ > > - -D\"JDK_VER=\$(VERSION_NUMBER_FOUR_POSITIONS)\" \ > > + -D\"JDK_VER=\$(VERSION_NUMBER)\" \ > > -D\"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \ > > -D\"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) \$(VERSION_MAJOR)\" \ > > -D\"JDK_FVER=\$(subst .,\$(COMMA),\$(VERSION_NUMBER_FOUR_POSITIONS))\"" > > > > [1] http://openjdk.java.net/jeps/223 Looks good to me. I'll sponsor the fix for you. /Magnus From david.dehaven at oracle.com Thu Sep 10 17:31:47 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 10 Sep 2015 10:31:47 -0700 Subject: RFR: JDK-8135180 Print configure arguments using make print-configuration In-Reply-To: <55EED86B.8030703@oracle.com> References: <55EED86B.8030703@oracle.com> Message-ID: > A common need when working with complex configure argument lists is to figure out what configuration that's currently being used. > > This patch introduces a new make target "print-configuration" which will just print the arguments used to run configure. Thank you! Now I don't have to chase config.log around :) -DrD- From magnus.ihse.bursie at oracle.com Thu Sep 10 21:41:44 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 10 Sep 2015 23:41:44 +0200 Subject: RFR: JDK-8064808 Disable use of broken objcopy on Solaris, remove adhoc helper tools Message-ID: <27341205-E740-4244-8BCE-F2A7F66AD4BE@oracle.com> Objcopy on Solaris prior to 2.21.1 is broken and will either crash during runtime or produce an incorrect result. We have traditionally handled this using two helper binaries that does the work of objcopy, but this has been error prone and is not a really nice solution. And by now, a fixed version of objcopy has been long time available in Solaris. We should implement the same solution in configure as the fix for JDK-8033602 in hotspot, that is, to check the version of objcopy on solaris, and just disable use if it is old and broken. This will allow us to remove the cumbersome helper tools that were developed to work around these limitations. Bug: https://bugs.openjdk.java.net/browse/JDK-8064808 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8064808-disable-broken-objcopy-on-solaris/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Sep 11 07:32:46 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 11 Sep 2015 09:32:46 +0200 Subject: RFR: JDK-8064808 Disable use of broken objcopy on Solaris, remove adhoc helper tools In-Reply-To: <27341205-E740-4244-8BCE-F2A7F66AD4BE@oracle.com> References: <27341205-E740-4244-8BCE-F2A7F66AD4BE@oracle.com> Message-ID: <55F2839E.6070400@oracle.com> On 2015-09-10 23:41, Magnus Ihse Bursie wrote: > Objcopy on Solaris prior to 2.21.1 is broken and will either crash during runtime or produce an incorrect result. We have traditionally handled this using two helper binaries that does the work of objcopy, but this has been error prone and is not a really nice solution. And by now, a fixed version of objcopy has been long time available in Solaris. > > We should implement the same solution in configure as the fix for JDK-8033602 in hotspot, that is, to check the version of objcopy on solaris, and just disable use if it is old and broken. > > This will allow us to remove the cumbersome helper tools that were developed to work around these limitations. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8064808 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8064808-disable-broken-objcopy-on-solaris/webrev.01 I noticed that I left some debug code in toolchain.m4, and also didn't use variables like $SED for the commands. I might also add that the compex sed expression is copied from the corresponding check in the hotspot makefiles. Updated webrev: (only changed in toolchain.m4) http://cr.openjdk.java.net/~ihse/JDK-8064808-disable-broken-objcopy-on-solaris/webrev.02 /Magnus From erik.joelsson at oracle.com Fri Sep 11 07:56:39 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 Sep 2015 09:56:39 +0200 Subject: RFR: JDK-8064808 Disable use of broken objcopy on Solaris, remove adhoc helper tools In-Reply-To: <55F2839E.6070400@oracle.com> References: <27341205-E740-4244-8BCE-F2A7F66AD4BE@oracle.com> <55F2839E.6070400@oracle.com> Message-ID: <55F28937.6040706@oracle.com> Thanks for the update. Looks good! This change is very nice. I verified on an old Solaris machine that OBJCOPY is empty when the version is 2.15. /Erik On 2015-09-11 09:32, Magnus Ihse Bursie wrote: > On 2015-09-10 23:41, Magnus Ihse Bursie wrote: >> Objcopy on Solaris prior to 2.21.1 is broken and will either crash >> during runtime or produce an incorrect result. We have traditionally >> handled this using two helper binaries that does the work of objcopy, >> but this has been error prone and is not a really nice solution. And >> by now, a fixed version of objcopy has been long time available in >> Solaris. >> >> We should implement the same solution in configure as the fix for >> JDK-8033602 in hotspot, that is, to check the version of objcopy on >> solaris, and just disable use if it is old and broken. >> >> This will allow us to remove the cumbersome helper tools that were >> developed to work around these limitations. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8064808 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8064808-disable-broken-objcopy-on-solaris/webrev.01 > I noticed that I left some debug code in toolchain.m4, and also didn't > use variables like $SED for the commands. > > I might also add that the compex sed expression is copied from the > corresponding check in the hotspot makefiles. > > Updated webrev: (only changed in toolchain.m4) > http://cr.openjdk.java.net/~ihse/JDK-8064808-disable-broken-objcopy-on-solaris/webrev.02 > > > /Magnus From magnus.ihse.bursie at oracle.com Fri Sep 11 13:16:06 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 11 Sep 2015 15:16:06 +0200 Subject: RFR: JDK-8136378 Build test libs using properly integrated makefile Message-ID: <55F2D416.3020305@oracle.com> Currently there is a (broken) ad-hoc solution to build wb.jar and test-lib.jar from sources in $TOP/test/lib. This should be replaced by a proper make target and using the build-infra framework. Bug: https://bugs.openjdk.java.net/browse/JDK-8136378 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8136378-use-proper-make-for-testlibs/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Sep 11 13:36:42 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 11 Sep 2015 15:36:42 +0200 Subject: RFR: JDK-8136378 Build test libs using properly integrated makefile In-Reply-To: <55F2D416.3020305@oracle.com> References: <55F2D416.3020305@oracle.com> Message-ID: <55F2D8EA.2050207@oracle.com> On 2015-09-11 15:16, Magnus Ihse Bursie wrote: > Currently there is a (broken) ad-hoc solution to build wb.jar and > test-lib.jar from sources in $TOP/test/lib. > > This should be replaced by a proper make target and using the > build-infra framework. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136378 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8136378-use-proper-make-for-testlibs/webrev.01 > > /Magnus > .. and here's a new version that use our new coding style as well in SetupJavaCompiler :-) http://cr.openjdk.java.net/~ihse/JDK-8136378-use-proper-make-for-testlibs/webrev.02 /Magnus From erik.joelsson at oracle.com Fri Sep 11 13:38:21 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 Sep 2015 15:38:21 +0200 Subject: RFR: JDK-8136378 Build test libs using properly integrated makefile In-Reply-To: <55F2D8EA.2050207@oracle.com> References: <55F2D416.3020305@oracle.com> <55F2D8EA.2050207@oracle.com> Message-ID: <55F2D94D.4010200@oracle.com> Looks good. /Erik On 2015-09-11 15:36, Magnus Ihse Bursie wrote: > On 2015-09-11 15:16, Magnus Ihse Bursie wrote: >> Currently there is a (broken) ad-hoc solution to build wb.jar and >> test-lib.jar from sources in $TOP/test/lib. >> >> This should be replaced by a proper make target and using the >> build-infra framework. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8136378 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8136378-use-proper-make-for-testlibs/webrev.01 >> >> /Magnus >> > .. and here's a new version that use our new coding style as well in > SetupJavaCompiler :-) > > http://cr.openjdk.java.net/~ihse/JDK-8136378-use-proper-make-for-testlibs/webrev.02 > > > /Magnus From erik.joelsson at oracle.com Fri Sep 11 14:11:10 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 Sep 2015 16:11:10 +0200 Subject: RFR: JDK-8136383: Improve make utilities containing and not-containing Message-ID: <55F2E0FE.20703@oracle.com> In MakeBase, we have a couple of convenience macros which complement the built in functions in make. Two of these are containing and not-containing. The current implementation only accepts 1 substring to look for. I have found it useful to support finding any of a set of substrings. I have such an implementation with tests to verify the functionality and would like to commit this to JDK 9. Bug: https://bugs.openjdk.java.net/browse/JDK-8136383 Webrev: http://cr.openjdk.java.net/~erikj/8136383/webrev.01/ /Erik From erik.joelsson at oracle.com Fri Sep 11 14:46:29 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 Sep 2015 16:46:29 +0200 Subject: RFR: JDK-8136385: Various build speed improvements for windows Message-ID: <55F2E945.6060400@oracle.com> Hello, In the build-infra project, I have made various minor build speed improvements for Windows. These mostly affect incremental build performance, but in certain cases normal builds are also greatly affected. I find these worth committing to JDK 9 separately. List of improvements: * Rewrote DependOnVariable to use "-include" instead of $(shell $(CAT) ...) to read the old variable value from the last make invocation. This has a pretty big impact on incremental build performance on Windows. Also started using the file function in make when available (in make 4.0) instead of $(shell $(PRINTF) ...) when writing these files. * Implemented ListPathsSafely using the file function when available. Since we require make 4.0 in cygwin, this will usually be the case when it matters. * Reduced the number of shell execution in the compiler and link recipes by joining them together with "; \". When compiling a lot of native code, this tends to get quite expensive. Bug: https://bugs.openjdk.java.net/browse/JDK-8136385 Webrev: http://cr.openjdk.java.net/~erikj/8136385/webrev.01/ /Erik From attila.szegedi at oracle.com Fri Sep 11 16:00:14 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 11 Sep 2015 18:00:14 +0200 Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code Message-ID: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> Please review the revised changes for JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code? The revision incorporates the following changes: - the feature can be disabled by setting the "nashorn.disableVmAnonymousClasses system property? - jdk9 root-level modules.xml explicitly exports sun.misc to jdk.scripting.nashorn - the changes to the CodeInstaller and Compiler API have since been separately committed, so they are no longer part of this issue, making its surface area smaller. Webrevs are found at: http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn The fist webrev is for jdk9/modules.xml; the change simply adds an export of sun.misc to jdk.scripting.nashorn; it is also the reason why I included build-dev on this review. The second webrev is the changes to the Nashorn code. Thanks, Attila. From philip.race at oracle.com Fri Sep 11 16:24:10 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 11 Sep 2015 09:24:10 -0700 Subject: RFR: 8136397: Build should recognise .cc file extension Message-ID: <55F3002A.30306@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8136397 I have code under a JEP which will be merged into JDK 9 at some point which uses C++ code in .cc files and I have had to maintain a patch to get the JDK build to recognise these. I'd like to get this patch into JDK 9 ahead of the files that need it so that I don't have to deal with the merges anymore. I did do a full jprt build of all platforms to confirm it is harmless .. -phil. diff -r 57f3134853ec make/common/NativeCompilation.gmk --- a/make/common/NativeCompilation.gmk +++ b/make/common/NativeCompilation.gmk @@ -102,7 +102,7 @@ ################################################################################ # Extensions of files handled by this macro. -NATIVE_SOURCE_EXTENSIONS := %.s %.c %.cpp %.m %.mm +NATIVE_SOURCE_EXTENSIONS := %.s %.c %.cpp %.cc %.m %.mm # Replaces native source extensions with the object file extension in a string. # Param 1: the string containing source file names with extensions @@ -167,7 +167,7 @@ $1_$2_FLAGS=$8 -DTHIS_FILE='"$$( References: <55F2E0FE.20703@oracle.com> Message-ID: <154B0C24-D02B-4BA2-98A9-A7EC4C2CA88D@oracle.com> Looks good to me. /Magnus > 11 sep 2015 kl. 16:11 skrev Erik Joelsson : > > In MakeBase, we have a couple of convenience macros which complement the built in functions in make. Two of these are containing and not-containing. The current implementation only accepts 1 substring to look for. I have found it useful to support finding any of a set of substrings. > > I have such an implementation with tests to verify the functionality and would like to commit this to JDK 9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136383 > Webrev: http://cr.openjdk.java.net/~erikj/8136383/webrev.01/ > > /Erik From magnus.ihse.bursie at oracle.com Fri Sep 11 17:38:36 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 11 Sep 2015 19:38:36 +0200 Subject: RFR: 8136397: Build should recognise .cc file extension In-Reply-To: <55F3002A.30306@oracle.com> References: <55F3002A.30306@oracle.com> Message-ID: <49038B8F-72EB-4758-B48A-719B12553E46@oracle.com> Looks good to me. /Magnus > 11 sep 2015 kl. 18:24 skrev Phil Race : > > https://bugs.openjdk.java.net/browse/JDK-8136397 > > I have code under a JEP which will be merged into JDK 9 at some > point which uses C++ code in .cc files and I have had to maintain > a patch to get the JDK build to recognise these. > I'd like to get this patch into JDK 9 ahead of the files that need it > so that I don't have to deal with the merges anymore. > I did do a full jprt build of all platforms to confirm it is harmless .. > > -phil. > > diff -r 57f3134853ec make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk > +++ b/make/common/NativeCompilation.gmk > @@ -102,7 +102,7 @@ > ################################################################################ > > # Extensions of files handled by this macro. > -NATIVE_SOURCE_EXTENSIONS := %.s %.c %.cpp %.m %.mm > +NATIVE_SOURCE_EXTENSIONS := %.s %.c %.cpp %.cc %.m %.mm > > # Replaces native source extensions with the object file extension in a string. > # Param 1: the string containing source file names with extensions > @@ -167,7 +167,7 @@ > $1_$2_FLAGS=$8 -DTHIS_FILE='"$$( $1_$2_COMP=$(AS) > $1_$2_DEP_FLAG:= > - else ifneq (,$$(filter %.cpp,$2)$$(filter %.mm,$2)) > + else ifneq (,$$(filter %.cpp,$2)$$(filter %.cc,$2)$$(filter %.mm,$2)) > # Compile as a C++ or Objective-C++ file > $1_$2_FLAGS=$(CFLAGS_CCACHE) $6 $$($1_$(notdir $2)_CXXFLAGS) -DTHIS_FILE='"$$( $1_$2_COMP=$7 > From attila.szegedi at oracle.com Mon Sep 14 07:54:05 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 14 Sep 2015 09:54:05 +0200 Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code In-Reply-To: <1966C2A9-6460-4529-8879-932ABFE65EDD@lagergren.net> References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> <1966C2A9-6460-4529-8879-932ABFE65EDD@lagergren.net> Message-ID: What do you mean by ?unsafe warning?? > On Sep 13, 2015, at 12:47 PM, Marcus Lagergren wrote: > > +1. Nicely done. > > Does this compile without unsafe warnings, though? > > /M > >> On 11 Sep 2015, at 18:00, Attila Szegedi > wrote: >> >> e > From maurizio.cimadamore at oracle.com Mon Sep 14 11:03:26 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 14 Sep 2015 12:03:26 +0100 Subject: build concurrency Message-ID: <55F6A97E.4030507@oracle.com> Hi, I realized that the concurrency factor inferred by the JDK build might be too high; on a 16 core machine, concurrency is set to 14 - which then leads to absurd load averages (50-ish) when building/running tests. High load when building is not a big issue, but when running test this almost always turns into spurious failures due to timeouts. I know I can override the concurrency factor with --with-jobs - but I was curious as to why the default parameter is set to such aggressive value? Thanks Maurizio From aph at redhat.com Mon Sep 14 11:06:34 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Sep 2015 12:06:34 +0100 Subject: build concurrency In-Reply-To: <55F6A97E.4030507@oracle.com> References: <55F6A97E.4030507@oracle.com> Message-ID: <55F6AA3A.8060609@redhat.com> On 09/14/2015 12:03 PM, Maurizio Cimadamore wrote: > why the default parameter is set to such aggressive value? It works great when compiling, as long as your memory interface is fast enough. Andrew. From maurizio.cimadamore at oracle.com Mon Sep 14 11:10:26 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 14 Sep 2015 12:10:26 +0100 Subject: build concurrency In-Reply-To: <55F6A97E.4030507@oracle.com> References: <55F6A97E.4030507@oracle.com> Message-ID: <55F6AB22.5020108@oracle.com> The information I posted was slightly incorrect, sorry - my machine has 8 cores (and 16 virtual processors) - so you see why choosing concurrency factor of 14 is particularly bad in this setup. Maurizio On 14/09/15 12:03, Maurizio Cimadamore wrote: > Hi, > I realized that the concurrency factor inferred by the JDK build might > be too high; on a 16 core machine, concurrency is set to 14 - which > then leads to absurd load averages (50-ish) when building/running > tests. High load when building is not a big issue, but when running > test this almost always turns into spurious failures due to timeouts. > I know I can override the concurrency factor with --with-jobs - but I > was curious as to why the default parameter is set to such aggressive > value? > > Thanks > Maurizio From maurizio.cimadamore at oracle.com Mon Sep 14 11:49:19 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 14 Sep 2015 12:49:19 +0100 Subject: build concurrency In-Reply-To: <55F6AA3A.8060609@redhat.com> References: <55F6A97E.4030507@oracle.com> <55F6AA3A.8060609@redhat.com> Message-ID: <55F6B43F.1030504@oracle.com> As I said, building/compiling is not the issue - but when running CPU intensive tests you are bound to see spurious failures (I see at least 2 regular ones in langtools tests). Maurizio On 14/09/15 12:06, Andrew Haley wrote: > On 09/14/2015 12:03 PM, Maurizio Cimadamore wrote: >> why the default parameter is set to such aggressive value? > It works great when compiling, as long as your memory interface is > fast enough. > > Andrew. > From Sergey.Bylokhov at oracle.com Mon Sep 14 14:06:42 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 Sep 2015 17:06:42 +0300 Subject: [9] Review Request: 8079965 Stop ignoring warnings for libawt_lwawt Message-ID: <55F6D472.7000405@oracle.com> Hello. Please review the fix for jdk9. In the fix I remove WARNINGS_AS_ERRORS_clang option from the libawt_lwawt library, and fix some of the issues: - jlong_md.h:69:9: warning: 'ptr_to_jlong' macro redefined. This is because the "jni_util.h" and "JavaNativeFoundation.framework/Headers/JNFJNI.h" both define this macro. I cleared our headers to eliminate this warning. - PrinterView.m:207:21: warning: implicit conversion from enumeration type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to different enumeration type 'NSPrintingOrientation'. The problem is that the Apple changed the returned type of [NSPrintInfo orientation] from NSPrintingOrientation to NSPaperOrientation. Note that the NSPaperOrientation is available since OSX 10.9, which means that this change break the build on 10.8. Is it acceptable or should I suppress this warning? [1] - CGraphicsDevice.m:336:41: warning: comparison between pointer and integer ('void *' and 'jint' (aka 'int')) if ([screenID pointerValue] == displayID). I have changed the type from pointerValue to unsignedIntValue. Also I added "enum-conversion" to the DISABLED_WARNINGS_clang to suppress some warnings to fix them later, because it should be investigated how to fix it properly (ImageSurfaceData.m:1090:93: warning: implicit conversion from enumeration type 'CGImageAlphaInfo' (aka 'enum CGImageAlphaInfo') to different enumeration type 'CGBitmapInfo') After the fix all new warnings will break the build. The currently disabled warnings will be fixed as part of JDK-8074825 [2]. jprt build passed. [1] https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/AppKit.html [2] https://bugs.openjdk.java.net/browse/JDK-8074825 Bug: https://bugs.openjdk.java.net/browse/JDK-8079965 Webrev: http://cr.openjdk.java.net/~serb/8079965/webrev.01 -- Best regards, Sergey. From erik.joelsson at oracle.com Mon Sep 14 16:05:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 14 Sep 2015 09:05:06 -0700 Subject: build concurrency In-Reply-To: <55F6AB22.5020108@oracle.com> References: <55F6A97E.4030507@oracle.com> <55F6AB22.5020108@oracle.com> Message-ID: <55F6F032.4090803@oracle.com> Hello, When I implemented the heuristic to choose a suitable default concurrency, I only ever worried about the build. I think having tests use the same concurrency setting must be a new feature? In any case, it seems like there is a case for reducing concurrency when running tests. Another note. It at least used to be quite tricky to get correct information about cores vs hyperthreading from the OS. I know today we aren't even consistent with this across platforms. Perhaps we should revisit this heuristic and take hyperthreading into consideration too. The current implemenation uses 100% of number of virtual cpus when 1 to 4 of them, then 90% at 5 to 16. After that it caps out at 16. (I might remember some detail wrong here) /Erik On 2015-09-14 04:10, Maurizio Cimadamore wrote: > The information I posted was slightly incorrect, sorry - my machine > has 8 cores (and 16 virtual processors) - so you see why choosing > concurrency factor of 14 is particularly bad in this setup. > > Maurizio > > On 14/09/15 12:03, Maurizio Cimadamore wrote: >> Hi, >> I realized that the concurrency factor inferred by the JDK build >> might be too high; on a 16 core machine, concurrency is set to 14 - >> which then leads to absurd load averages (50-ish) when >> building/running tests. High load when building is not a big issue, >> but when running test this almost always turns into spurious failures >> due to timeouts. I know I can override the concurrency factor with >> --with-jobs - but I was curious as to why the default parameter is >> set to such aggressive value? >> >> Thanks >> Maurizio > From Alan.Bateman at oracle.com Mon Sep 14 18:10:41 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Sep 2015 19:10:41 +0100 Subject: build concurrency In-Reply-To: <55F6F032.4090803@oracle.com> References: <55F6A97E.4030507@oracle.com> <55F6AB22.5020108@oracle.com> <55F6F032.4090803@oracle.com> Message-ID: <55F70DA1.8000301@oracle.com> On 14/09/2015 17:05, Erik Joelsson wrote: > Hello, > > When I implemented the heuristic to choose a suitable default > concurrency, I only ever worried about the build. I think having tests > use the same concurrency setting must be a new feature? In any case, > it seems like there is a case for reducing concurrency when running > tests. I think this is where the change was discussed: http://mail.openjdk.java.net/pipermail/build-dev/2013-June/009297.html From maurizio.cimadamore at oracle.com Tue Sep 15 09:53:07 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Sep 2015 10:53:07 +0100 Subject: build concurrency In-Reply-To: <55F6F032.4090803@oracle.com> References: <55F6A97E.4030507@oracle.com> <55F6AB22.5020108@oracle.com> <55F6F032.4090803@oracle.com> Message-ID: <55F7EA83.6080602@oracle.com> Hi Erik, thanks for the explanation. Regarding build times, the current heuristics scores ok on my high-end machine (I get more or less same time as with JDK 8 build) - but with a lower spec machine (i.e. laptop with dual core intel i5) it gets much much worse - i.e. I used to be able to build in 7 minutes on my laptop (using ccache) - now build time is at least double that figure. I know it's an hard problem to decide how many cores to use but there seem to be a pattern emerging: * low-end machines get completely swamped by the build load * CPU bound tests run into troubles when reusing same concurrency settings, even on high-end hardware. Without playing with timeouts it's impossible to get a clean test sheet. * on relatively high-end HW, current build concurrency settings seem to be doing ok. Realistically, I believe anything that uses more than n/2 virtual processors is going to face troubles sooner or later; the build might be ok since there's so much IO going on (reading/writing files) - but the more the build will become CPU intensive (and sjavac might help with that) the more current settings could become a bottleneck. Maurizio On 14/09/15 17:05, Erik Joelsson wrote: > Hello, > > When I implemented the heuristic to choose a suitable default > concurrency, I only ever worried about the build. I think having tests > use the same concurrency setting must be a new feature? In any case, > it seems like there is a case for reducing concurrency when running > tests. > > Another note. It at least used to be quite tricky to get correct > information about cores vs hyperthreading from the OS. I know today we > aren't even consistent with this across platforms. Perhaps we should > revisit this heuristic and take hyperthreading into consideration too. > > The current implemenation uses 100% of number of virtual cpus when 1 > to 4 of them, then 90% at 5 to 16. After that it caps out at 16. (I > might remember some detail wrong here) > > /Erik > > On 2015-09-14 04:10, Maurizio Cimadamore wrote: >> The information I posted was slightly incorrect, sorry - my machine >> has 8 cores (and 16 virtual processors) - so you see why choosing >> concurrency factor of 14 is particularly bad in this setup. >> >> Maurizio >> >> On 14/09/15 12:03, Maurizio Cimadamore wrote: >>> Hi, >>> I realized that the concurrency factor inferred by the JDK build >>> might be too high; on a 16 core machine, concurrency is set to 14 - >>> which then leads to absurd load averages (50-ish) when >>> building/running tests. High load when building is not a big issue, >>> but when running test this almost always turns into spurious >>> failures due to timeouts. I know I can override the concurrency >>> factor with --with-jobs - but I was curious as to why the default >>> parameter is set to such aggressive value? >>> >>> Thanks >>> Maurizio >> > From erik.joelsson at oracle.com Tue Sep 15 15:43:42 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 15 Sep 2015 08:43:42 -0700 Subject: build concurrency In-Reply-To: <55F7EA83.6080602@oracle.com> References: <55F6A97E.4030507@oracle.com> <55F6AB22.5020108@oracle.com> <55F6F032.4090803@oracle.com> <55F7EA83.6080602@oracle.com> Message-ID: <55F83CAE.1000800@oracle.com> On 2015-09-15 02:53, Maurizio Cimadamore wrote: > Hi Erik, > thanks for the explanation. > > Regarding build times, the current heuristics scores ok on my > high-end machine (I get more or less same time as with JDK 8 build) - > but with a lower spec machine (i.e. laptop with dual core intel i5) it > gets much much worse - i.e. I used to be able to build in 7 minutes on > my laptop (using ccache) - now build time is at least double that figure. > I believe the major reason for your degradation of build performance in JDK 9 vs JDK 8 on a low end machine is caused by us splitting the java compilation into a per module model. In JDK 8, all java code was compiled in one chunk. On a high end machine, splitting doesn't cause as much degradation as many modules are compiled in parallel, making up for the lost time of restarting the JVM each time. I think most of this loss will be made up when we introduce server javac, where the jvm will be warmed up and reused for all java compilations. Have you tested reducing the number of jobs (make JOBS=2) on your i5? If that does indeed improve build times on JDK 9, I would be surprised, but then we definitely need to change the heuristics. In my experience lowering the JOBS number does not have a positive impact on build times any system. /Erik > I know it's an hard problem to decide how many cores to use but there > seem to be a pattern emerging: > > * low-end machines get completely swamped by the build load > * CPU bound tests run into troubles when reusing same concurrency > settings, even on high-end hardware. Without playing with timeouts > it's impossible to get a clean test sheet. > * on relatively high-end HW, current build concurrency settings seem > to be doing ok. > > Realistically, I believe anything that uses more than n/2 virtual > processors is going to face troubles sooner or later; the build might > be ok since there's so much IO going on (reading/writing files) - but > the more the build will become CPU intensive (and sjavac might help > with that) the more current settings could become a bottleneck. > > Maurizio > > On 14/09/15 17:05, Erik Joelsson wrote: >> Hello, >> >> When I implemented the heuristic to choose a suitable default >> concurrency, I only ever worried about the build. I think having >> tests use the same concurrency setting must be a new feature? In any >> case, it seems like there is a case for reducing concurrency when >> running tests. >> >> Another note. It at least used to be quite tricky to get correct >> information about cores vs hyperthreading from the OS. I know today >> we aren't even consistent with this across platforms. Perhaps we >> should revisit this heuristic and take hyperthreading into >> consideration too. >> >> The current implemenation uses 100% of number of virtual cpus when 1 >> to 4 of them, then 90% at 5 to 16. After that it caps out at 16. (I >> might remember some detail wrong here) >> >> /Erik >> >> On 2015-09-14 04:10, Maurizio Cimadamore wrote: >>> The information I posted was slightly incorrect, sorry - my machine >>> has 8 cores (and 16 virtual processors) - so you see why choosing >>> concurrency factor of 14 is particularly bad in this setup. >>> >>> Maurizio >>> >>> On 14/09/15 12:03, Maurizio Cimadamore wrote: >>>> Hi, >>>> I realized that the concurrency factor inferred by the JDK build >>>> might be too high; on a 16 core machine, concurrency is set to 14 - >>>> which then leads to absurd load averages (50-ish) when >>>> building/running tests. High load when building is not a big issue, >>>> but when running test this almost always turns into spurious >>>> failures due to timeouts. I know I can override the concurrency >>>> factor with --with-jobs - but I was curious as to why the default >>>> parameter is set to such aggressive value? >>>> >>>> Thanks >>>> Maurizio >>> >> > From david.dehaven at oracle.com Tue Sep 15 21:28:30 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 15 Sep 2015 14:28:30 -0700 Subject: build concurrency In-Reply-To: <55F7EA83.6080602@oracle.com> References: <55F6A97E.4030507@oracle.com> <55F6AB22.5020108@oracle.com> <55F6F032.4090803@oracle.com> <55F7EA83.6080602@oracle.com> Message-ID: To determine the number of physical cores: On Mac: sysctl -n hw.physicalcpu_max Or, if that's not available: sysctl -n hw.ncpu On Linux, you could parse /proc/cpuinfo (look at "physical id" and "cpu cores") using awk/grep/sed/sort/whatever Or: for cpudir in /sys/devices/system/cpu/cpu[0-9]*; do PHYS=`cat $cpudir/topology/physical_package_id` CORE=`cat $cpudir/topology/core_id` echo "$PHYS:$CORE" done On my quad core i7 (8 virtual processors) it outputs: 0:0 0:0 0:1 0:1 0:2 0:2 0:3 0:3 Ideally you'd build an array in the for loop and store the highest core id + 1 (to get core count). Then just add up the array entries as there should be one for each physical processor and you have the total number of physical cores. No idea how to solve that on Windows or Solaris. -DrD- > Hi Erik, > thanks for the explanation. > > Regarding build times, the current heuristics scores ok on my high-end machine (I get more or less same time as with JDK 8 build) - but with a lower spec machine (i.e. laptop with dual core intel i5) it gets much much worse - i.e. I used to be able to build in 7 minutes on my laptop (using ccache) - now build time is at least double that figure. > > I know it's an hard problem to decide how many cores to use but there seem to be a pattern emerging: > > * low-end machines get completely swamped by the build load > * CPU bound tests run into troubles when reusing same concurrency settings, even on high-end hardware. Without playing with timeouts it's impossible to get a clean test sheet. > * on relatively high-end HW, current build concurrency settings seem to be doing ok. > > Realistically, I believe anything that uses more than n/2 virtual processors is going to face troubles sooner or later; the build might be ok since there's so much IO going on (reading/writing files) - but the more the build will become CPU intensive (and sjavac might help with that) the more current settings could become a bottleneck. > > Maurizio > > On 14/09/15 17:05, Erik Joelsson wrote: >> Hello, >> >> When I implemented the heuristic to choose a suitable default concurrency, I only ever worried about the build. I think having tests use the same concurrency setting must be a new feature? In any case, it seems like there is a case for reducing concurrency when running tests. >> >> Another note. It at least used to be quite tricky to get correct information about cores vs hyperthreading from the OS. I know today we aren't even consistent with this across platforms. Perhaps we should revisit this heuristic and take hyperthreading into consideration too. >> >> The current implemenation uses 100% of number of virtual cpus when 1 to 4 of them, then 90% at 5 to 16. After that it caps out at 16. (I might remember some detail wrong here) >> >> /Erik >> >> On 2015-09-14 04:10, Maurizio Cimadamore wrote: >>> The information I posted was slightly incorrect, sorry - my machine has 8 cores (and 16 virtual processors) - so you see why choosing concurrency factor of 14 is particularly bad in this setup. >>> >>> Maurizio >>> >>> On 14/09/15 12:03, Maurizio Cimadamore wrote: >>>> Hi, >>>> I realized that the concurrency factor inferred by the JDK build might be too high; on a 16 core machine, concurrency is set to 14 - which then leads to absurd load averages (50-ish) when building/running tests. High load when building is not a big issue, but when running test this almost always turns into spurious failures due to timeouts. I know I can override the concurrency factor with --with-jobs - but I was curious as to why the default parameter is set to such aggressive value? >>>> >>>> Thanks >>>> Maurizio >>> >> > From magnus.ihse.bursie at oracle.com Wed Sep 16 09:37:46 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Sep 2015 11:37:46 +0200 Subject: RFR: JDK-8136385: Various build speed improvements for windows In-Reply-To: <55F2E945.6060400@oracle.com> References: <55F2E945.6060400@oracle.com> Message-ID: <55F9386A.20808@oracle.com> On 2015-09-11 16:46, Erik Joelsson wrote: > Hello, > > In the build-infra project, I have made various minor build speed > improvements for Windows. These mostly affect incremental build > performance, but in certain cases normal builds are also greatly > affected. I find these worth committing to JDK 9 separately. > > List of improvements: > > * Rewrote DependOnVariable to use "-include" instead of $(shell $(CAT) > ...) to read the old variable value from the last make invocation. > This has a pretty big impact on incremental build performance on > Windows. Also started using the file function in make when available > (in make 4.0) instead of $(shell $(PRINTF) ...) when writing these files. > > * Implemented ListPathsSafely using the file function when available. > Since we require make 4.0 in cygwin, this will usually be the case > when it matters. > > * Reduced the number of shell execution in the compiler and link > recipes by joining them together with "; \". When compiling a lot of > native code, this tends to get quite expensive. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136385 > Webrev: http://cr.openjdk.java.net/~erikj/8136385/webrev.01/ As a general comment, I've experimented a bit with using .ONESHELL, which will automatically concatenate separate lines in a recipe and execute them by a single shell. When it works, it improves performance significantly, especially in Windows. Having it enabled all over the board would also let us avoid those "&& \" constructs. However, a lot of recipes needs to be updated to work properly with .ONESHELL. Also, it was also introduced in GNU Make 3.82 so we would need to bump our lowest supported platform number. Nevertheless, I think it is the proper way forward, but it will take some time. So changes such as this will be needed in the meantime. I have a few questions: In JavaCompilation.gmk, you replace $1_GREP_INCLUDE_OUTPUT := with $1_GREP_INCLUDE_OUTPUT =. Any specific reason to drop the : or just a typo? (And so also for $1_GREP_EXCLUDE_OUTPUT) The ListPathsSafely function is really horrible and hard to read. :-/ (I'm not blaming you; the version using "file" is excellent). I have a hard time figuring out that the legacy version (without "file") is still correct. Maybe we should have a test for it? The indentation on DependOnVariableHelper looks weird. It might be the patch but I'm not sure. In NativeCompilation, I'm trying to figure out how the "ifneq ($$($1_$2_DEP),)" is supposed to work. This is old code and I wouldn't have reacted to it if it were not for the fact that you removed this checked for the microsoft toolchain path. As I can see, the $1_$2_DEP variable will be empty for .s files. But if we're compiling .s files in solstudio, we'll still end up calling "$$($1_$2_COMP) $$($1_$2_FLAGS) $$($1_$2_DEP_FLAG) $$($1_$2_DEP) ...". How could that possibly work? And what happens for the microsoft case with your patch? Now we're going to do the "$(SED) $(DEPENDENCY_TARGET_SED_PATTERN) $$($1_$2_DEP) > $$($1_$2_DEP_TARGETS)" operation, which we previously didn't do. Do we actually compile any .s files? I can't understand how that would work. *checking* No, we don't. In the jdk project, there's just a single .s file (./jdk/src/java.desktop/unix/native/libawt/awt/medialib/mlib_v_ImageCopy_blk.s) and it's excluded from compilation. On the other hand, there *are* .s files in the Hotspot project which we will need to be able to handle at some point. Urgh. Messy. You'll have to decide if you want to clean this up. /Magnus > > /Erik From magnus.ihse.bursie at oracle.com Wed Sep 16 12:25:24 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Sep 2015 14:25:24 +0200 Subject: [9] Review Request: 8079965 Stop ignoring warnings for libawt_lwawt In-Reply-To: <55F6D472.7000405@oracle.com> References: <55F6D472.7000405@oracle.com> Message-ID: <55F95FB4.9090704@oracle.com> On 2015-09-14 16:06, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > In the fix I remove WARNINGS_AS_ERRORS_clang option from the > libawt_lwawt library, and fix some of the issues: > > - jlong_md.h:69:9: warning: 'ptr_to_jlong' macro redefined. This is > because the "jni_util.h" and > "JavaNativeFoundation.framework/Headers/JNFJNI.h" both define this > macro. I cleared our headers to eliminate this warning. > > - PrinterView.m:207:21: warning: implicit conversion from enumeration > type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to different > enumeration type 'NSPrintingOrientation'. The problem is that the > Apple changed the returned type of [NSPrintInfo orientation] from > NSPrintingOrientation to NSPaperOrientation. Note that the > NSPaperOrientation is available since OSX 10.9, which means that this > change break the build on 10.8. Is it acceptable or should I suppress > this warning? [1] > > - CGraphicsDevice.m:336:41: warning: comparison between pointer and > integer ('void *' and 'jint' (aka 'int')) if ([screenID pointerValue] > == displayID). I have changed the type from pointerValue to > unsignedIntValue. > > Also I added "enum-conversion" to the DISABLED_WARNINGS_clang to > suppress some warnings to fix them later, because it should be > investigated how to fix it properly (ImageSurfaceData.m:1090:93: > warning: implicit conversion from enumeration type 'CGImageAlphaInfo' > (aka 'enum CGImageAlphaInfo') to different enumeration type > 'CGBitmapInfo') > > After the fix all new warnings will break the build. The currently > disabled warnings will be fixed as part of JDK-8074825 [2]. > > jprt build passed. > > [1] > https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/AppKit.html > [2] https://bugs.openjdk.java.net/browse/JDK-8074825 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079965 > Webrev: http://cr.openjdk.java.net/~serb/8079965/webrev.01 > Hi Sergey, Build changes look good. Thank you for addressing this! /Magnus From magnus.ihse.bursie at oracle.com Wed Sep 16 12:28:27 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Sep 2015 14:28:27 +0200 Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code In-Reply-To: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> Message-ID: <55F9606B.2060701@oracle.com> On 2015-09-11 18:00, Attila Szegedi wrote: > Please review the revised changes for JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code? > > The revision incorporates the following changes: > - the feature can be disabled by setting the "nashorn.disableVmAnonymousClasses system property? > - jdk9 root-level modules.xml explicitly exports sun.misc to jdk.scripting.nashorn > - the changes to the CodeInstaller and Compiler API have since been separately committed, so they are no longer part of this issue, making its surface area smaller. > > Webrevs are found at: > http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 > http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn > > The fist webrev is for jdk9/modules.xml; the change simply adds an export of sun.misc to jdk.scripting.nashorn; it is also the reason why I included build-dev on this review. Actually, I think it's a better idea to direct module.xml related changes to jigsaw-dev. (Cc:ing them). /Magnus > The second webrev is the changes to the Nashorn code. > > Thanks, > Attila. > From magnus.ihse.bursie at oracle.com Wed Sep 16 12:34:41 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Sep 2015 14:34:41 +0200 Subject: build concurrency In-Reply-To: <55F7EA83.6080602@oracle.com> References: <55F6A97E.4030507@oracle.com> <55F6AB22.5020108@oracle.com> <55F6F032.4090803@oracle.com> <55F7EA83.6080602@oracle.com> Message-ID: <55F961E1.3090309@oracle.com> On 2015-09-15 11:53, Maurizio Cimadamore wrote: > Hi Erik, > thanks for the explanation. > > Regarding build times, the current heuristics scores ok on my > high-end machine (I get more or less same time as with JDK 8 build) - > but with a lower spec machine (i.e. laptop with dual core intel i5) it > gets much much worse - i.e. I used to be able to build in 7 minutes on > my laptop (using ccache) - now build time is at least double that figure. > > I know it's an hard problem to decide how many cores to use but there > seem to be a pattern emerging: I'd like to expand that statement by saying that it's a hard problem to optimize the build for all kinds of platforms out of the box. We make no claims that the default configuration should be optimal for any specific setup. Hopefully, it will be "good enough" for most settings, but if you really need optimal performance, you will need to perform experiments on your specific setting, and choose number of jobs, ccache and precompiled headers that suits your particular hardware and type of build. Our internal build system at Oracle uses long configure lines to achieve (what we believe) are best performance for that setup, for instance. That said, if we can make sane changes that improves performance for most users and degrades performance for none, or very few, out of the box, we will of couse try to do so. /Magnus > > * low-end machines get completely swamped by the build load > * CPU bound tests run into troubles when reusing same concurrency > settings, even on high-end hardware. Without playing with timeouts > it's impossible to get a clean test sheet. > * on relatively high-end HW, current build concurrency settings seem > to be doing ok. > > Realistically, I believe anything that uses more than n/2 virtual > processors is going to face troubles sooner or later; the build might > be ok since there's so much IO going on (reading/writing files) - but > the more the build will become CPU intensive (and sjavac might help > with that) the more current settings could become a bottleneck. > > Maurizio > > On 14/09/15 17:05, Erik Joelsson wrote: >> Hello, >> >> When I implemented the heuristic to choose a suitable default >> concurrency, I only ever worried about the build. I think having >> tests use the same concurrency setting must be a new feature? In any >> case, it seems like there is a case for reducing concurrency when >> running tests. >> >> Another note. It at least used to be quite tricky to get correct >> information about cores vs hyperthreading from the OS. I know today >> we aren't even consistent with this across platforms. Perhaps we >> should revisit this heuristic and take hyperthreading into >> consideration too. >> >> The current implemenation uses 100% of number of virtual cpus when 1 >> to 4 of them, then 90% at 5 to 16. After that it caps out at 16. (I >> might remember some detail wrong here) >> >> /Erik >> >> On 2015-09-14 04:10, Maurizio Cimadamore wrote: >>> The information I posted was slightly incorrect, sorry - my machine >>> has 8 cores (and 16 virtual processors) - so you see why choosing >>> concurrency factor of 14 is particularly bad in this setup. >>> >>> Maurizio >>> >>> On 14/09/15 12:03, Maurizio Cimadamore wrote: >>>> Hi, >>>> I realized that the concurrency factor inferred by the JDK build >>>> might be too high; on a 16 core machine, concurrency is set to 14 - >>>> which then leads to absurd load averages (50-ish) when >>>> building/running tests. High load when building is not a big issue, >>>> but when running test this almost always turns into spurious >>>> failures due to timeouts. I know I can override the concurrency >>>> factor with --with-jobs - but I was curious as to why the default >>>> parameter is set to such aggressive value? >>>> >>>> Thanks >>>> Maurizio >>> >> > From Alan.Bateman at oracle.com Wed Sep 16 12:51:34 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Sep 2015 13:51:34 +0100 Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code In-Reply-To: <55F9606B.2060701@oracle.com> References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> <55F9606B.2060701@oracle.com> Message-ID: <55F965D6.1080709@oracle.com> On 16/09/2015 13:28, Magnus Ihse Bursie wrote: > On 2015-09-11 18:00, Attila Szegedi wrote: >> Please review the revised changes for JDK-8135251 "Use >> Unsafe.defineAnonymousClass for loading Nashorn script code? >> >> >> The revision incorporates the following changes: >> - the feature can be disabled by setting the >> "nashorn.disableVmAnonymousClasses system property? >> - jdk9 root-level modules.xml explicitly exports sun.misc to >> jdk.scripting.nashorn >> - the changes to the CodeInstaller and Compiler API have since been >> separately committed, so they are no longer part of this issue, >> making its surface area smaller. >> >> Webrevs are found at: >> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 >> >> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn >> >> >> The fist webrev is for jdk9/modules.xml; the change simply adds an >> export of sun.misc to jdk.scripting.nashorn; it is also the reason >> why I included build-dev on this review. > > Actually, I think it's a better idea to direct module.xml related > changes to jigsaw-dev. (Cc:ing them). The changes to modules.xml looks fine. Also just to say that modules.xml has been removed in the jigsaw/jake forest as it was just a temporary document to maintain the module graph until the module system came along. -Alan. From magnus.ihse.bursie at oracle.com Wed Sep 16 12:57:00 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Sep 2015 14:57:00 +0200 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> Message-ID: <55F9671C.4000208@oracle.com> On 2015-09-14 09:24, Christian Thalinger wrote: > The JEP itself can be found here: > > https://bugs.openjdk.java.net/browse/JDK-8062493 > > Here are the webrevs: > > http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ > http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ > > The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: > > https://bugs.openjdk.java.net/browse/JDK-8134994 > > SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. > > The integration will happen under the bug number: > > https://bugs.openjdk.java.net/browse/JDK-8136421 > Hi Christian, (Adding build-dev since this review includes some major build changes.) The makefile changes looks good in general to me. I have not reviewed the source code changes. Some comments: * modules.xml: Make sure you get sign-off from a Jigsaw developer for modifying this file. * hotspot/make/linux/makefiles/gcc.make: Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. /Magnus From magnus.ihse.bursie at oracle.com Wed Sep 16 13:04:03 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Sep 2015 15:04:03 +0200 Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code In-Reply-To: <55F965D6.1080709@oracle.com> References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> <55F9606B.2060701@oracle.com> <55F965D6.1080709@oracle.com> Message-ID: <55F968C3.6030509@oracle.com> On 2015-09-16 14:51, Alan Bateman wrote: > > > On 16/09/2015 13:28, Magnus Ihse Bursie wrote: >> On 2015-09-11 18:00, Attila Szegedi wrote: >>> Please review the revised changes for JDK-8135251 "Use >>> Unsafe.defineAnonymousClass for loading Nashorn script code? >>> >>> >>> The revision incorporates the following changes: >>> - the feature can be disabled by setting the >>> "nashorn.disableVmAnonymousClasses system property? >>> - jdk9 root-level modules.xml explicitly exports sun.misc to >>> jdk.scripting.nashorn >>> - the changes to the CodeInstaller and Compiler API have since been >>> separately committed, so they are no longer part of this issue, >>> making its surface area smaller. >>> >>> Webrevs are found at: >>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 >>> >>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn >>> >>> >>> The fist webrev is for jdk9/modules.xml; the change simply adds an >>> export of sun.misc to jdk.scripting.nashorn; it is also the reason >>> why I included build-dev on this review. >> >> Actually, I think it's a better idea to direct module.xml related >> changes to jigsaw-dev. (Cc:ing them). > The changes to modules.xml looks fine. Also just to say that > modules.xml has been removed in the jigsaw/jake forest as it was just > a temporary document to maintain the module graph until the module > system came along. Does this mean that updates to modules.xml between now and the integration-to-come of jigsaw/jake do not anymore need specific approval? /Magnus > > -Alan. From david.lloyd at redhat.com Wed Sep 16 13:06:34 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 16 Sep 2015 08:06:34 -0500 Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code In-Reply-To: <55F965D6.1080709@oracle.com> References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> <55F9606B.2060701@oracle.com> <55F965D6.1080709@oracle.com> Message-ID: <55F9695A.60205@redhat.com> On 09/16/2015 07:51 AM, Alan Bateman wrote: > > > On 16/09/2015 13:28, Magnus Ihse Bursie wrote: >> On 2015-09-11 18:00, Attila Szegedi wrote: >>> Please review the revised changes for JDK-8135251 "Use >>> Unsafe.defineAnonymousClass for loading Nashorn script code? >>> >>> >>> The revision incorporates the following changes: >>> - the feature can be disabled by setting the >>> "nashorn.disableVmAnonymousClasses system property? >>> - jdk9 root-level modules.xml explicitly exports sun.misc to >>> jdk.scripting.nashorn >>> - the changes to the CodeInstaller and Compiler API have since been >>> separately committed, so they are no longer part of this issue, >>> making its surface area smaller. >>> >>> Webrevs are found at: >>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 >>> >>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn >>> >>> >>> The fist webrev is for jdk9/modules.xml; the change simply adds an >>> export of sun.misc to jdk.scripting.nashorn; it is also the reason >>> why I included build-dev on this review. >> >> Actually, I think it's a better idea to direct module.xml related >> changes to jigsaw-dev. (Cc:ing them). > The changes to modules.xml looks fine. Also just to say that modules.xml > has been removed in the jigsaw/jake forest as it was just a temporary > document to maintain the module graph until the module system came along. Also I could be wrong but it looks to me like the jigsaw/jake forest's equivalent module graph has evolved somewhat, and thus doesn't quite match this file anyway. -- - DML From magnus.ihse.bursie at oracle.com Wed Sep 16 13:11:14 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Sep 2015 15:11:14 +0200 Subject: build concurrency In-Reply-To: <55F6F032.4090803@oracle.com> References: <55F6A97E.4030507@oracle.com> <55F6AB22.5020108@oracle.com> <55F6F032.4090803@oracle.com> Message-ID: <55F96A72.4080403@oracle.com> On 2015-09-14 18:05, Erik Joelsson wrote: > Hello, > > When I implemented the heuristic to choose a suitable default > concurrency, I only ever worried about the build. I think having tests > use the same concurrency setting must be a new feature? In any case, > it seems like there is a case for reducing concurrency when running > tests. Just so we don't drop this part of the discussion. Maurizio, what do you think would be a good number for your machine when running tests? /Magnus > > Another note. It at least used to be quite tricky to get correct > information about cores vs hyperthreading from the OS. I know today we > aren't even consistent with this across platforms. Perhaps we should > revisit this heuristic and take hyperthreading into consideration too. > > The current implemenation uses 100% of number of virtual cpus when 1 > to 4 of them, then 90% at 5 to 16. After that it caps out at 16. (I > might remember some detail wrong here) > > /Erik > > On 2015-09-14 04:10, Maurizio Cimadamore wrote: >> The information I posted was slightly incorrect, sorry - my machine >> has 8 cores (and 16 virtual processors) - so you see why choosing >> concurrency factor of 14 is particularly bad in this setup. >> >> Maurizio >> >> On 14/09/15 12:03, Maurizio Cimadamore wrote: >>> Hi, >>> I realized that the concurrency factor inferred by the JDK build >>> might be too high; on a 16 core machine, concurrency is set to 14 - >>> which then leads to absurd load averages (50-ish) when >>> building/running tests. High load when building is not a big issue, >>> but when running test this almost always turns into spurious >>> failures due to timeouts. I know I can override the concurrency >>> factor with --with-jobs - but I was curious as to why the default >>> parameter is set to such aggressive value? >>> >>> Thanks >>> Maurizio >> > From Alan.Bateman at oracle.com Wed Sep 16 13:12:21 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Sep 2015 14:12:21 +0100 Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code In-Reply-To: <55F968C3.6030509@oracle.com> References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> <55F9606B.2060701@oracle.com> <55F965D6.1080709@oracle.com> <55F968C3.6030509@oracle.com> Message-ID: <55F96AB5.7000702@oracle.com> On 16/09/2015 14:04, Magnus Ihse Bursie wrote: > > Does this mean that updates to modules.xml between now and the > integration-to-come of jigsaw/jake do not anymore need specific approval? I think we should keep the status quo and CC jigsaw-dev when there are changes to modules.xml. If nothing else, it creates aware of the changes because they require adjustment when jigsaw/jake is sync'ed up from jdk9/jdk9. These sync ups are non-trivial at times. Aside from merging almost every repo, then often require looking at the changes to modules.xml in the promoted build to ensure that the equivalent changes are make to the module declarations. -Alan From Alan.Bateman at oracle.com Wed Sep 16 13:23:58 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Sep 2015 14:23:58 +0100 Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code In-Reply-To: <55F9695A.60205@redhat.com> References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> <55F9606B.2060701@oracle.com> <55F965D6.1080709@oracle.com> <55F9695A.60205@redhat.com> Message-ID: <55F96D6E.5040506@oracle.com> On 16/09/2015 14:06, David M. Lloyd wrote: > > Also I could be wrong but it looks to me like the jigsaw/jake forest's > equivalent module graph has evolved somewhat, and thus doesn't quite > match this file anyway. jigsaw/jake is currently at jdk9-b81. There may be changes backed up in jdk9/dev that aren't in jake yet, we'll get those once those changes get to master and there is a sync up. As I mentioned in the reply to Magnus then these sync ups often require changes to the module declarations. Other than the pipeline there is one new module in jigsaw/jake (jdk.jlink), a few additional exports, and a few adjustments to qualified exports to take account of the wide changes in the jake forest. The nice thing about working in jake is that it will catch a lot more at compile time compared to working in jdk9/dev. -Alan. From attila.szegedi at oracle.com Wed Sep 16 14:05:57 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 16 Sep 2015 16:05:57 +0200 Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code In-Reply-To: <55F965D6.1080709@oracle.com> References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> <55F9606B.2060701@oracle.com> <55F965D6.1080709@oracle.com> Message-ID: > On Sep 16, 2015, at 2:51 PM, Alan Bateman wrote: > > > > On 16/09/2015 13:28, Magnus Ihse Bursie wrote: >> On 2015-09-11 18:00, Attila Szegedi wrote: >>> Please review the revised changes for JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code? >>> >>> The revision incorporates the following changes: >>> - the feature can be disabled by setting the "nashorn.disableVmAnonymousClasses system property? >>> - jdk9 root-level modules.xml explicitly exports sun.misc to jdk.scripting.nashorn >>> - the changes to the CodeInstaller and Compiler API have since been separately committed, so they are no longer part of this issue, making its surface area smaller. >>> >>> Webrevs are found at: >>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 >>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn >>> >>> The fist webrev is for jdk9/modules.xml; the change simply adds an export of sun.misc to jdk.scripting.nashorn; it is also the reason why I included build-dev on this review. >> >> Actually, I think it's a better idea to direct module.xml related changes to jigsaw-dev. (Cc:ing them). > The changes to modules.xml looks fine. Also just to say that modules.xml has been removed in the jigsaw/jake forest as it was just a temporary document to maintain the module graph until the module system came along. Alan, can I cite you in "Reviewed-by? line as a reviewer for the modules.xml change? Thanks, Attila. From sundararajan.athijegannathan at oracle.com Wed Sep 16 14:28:01 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 16 Sep 2015 19:58:01 +0530 Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code In-Reply-To: References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com> <55F9606B.2060701@oracle.com> <55F965D6.1080709@oracle.com> Message-ID: <55F97C71.8060806@oracle.com> +1 Nashorn changes and modules.xml changes look good to me. -Sundar On 9/16/2015 7:35 PM, Attila Szegedi wrote: >> On Sep 16, 2015, at 2:51 PM, Alan Bateman wrote: >> >> >> >> On 16/09/2015 13:28, Magnus Ihse Bursie wrote: >>> On 2015-09-11 18:00, Attila Szegedi wrote: >>>> Please review the revised changes for JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code? >>>> >>>> The revision incorporates the following changes: >>>> - the feature can be disabled by setting the "nashorn.disableVmAnonymousClasses system property? >>>> - jdk9 root-level modules.xml explicitly exports sun.misc to jdk.scripting.nashorn >>>> - the changes to the CodeInstaller and Compiler API have since been separately committed, so they are no longer part of this issue, making its surface area smaller. >>>> >>>> Webrevs are found at: >>>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 >>>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn >>>> >>>> The fist webrev is for jdk9/modules.xml; the change simply adds an export of sun.misc to jdk.scripting.nashorn; it is also the reason why I included build-dev on this review. >>> Actually, I think it's a better idea to direct module.xml related changes to jigsaw-dev. (Cc:ing them). >> The changes to modules.xml looks fine. Also just to say that modules.xml has been removed in the jigsaw/jake forest as it was just a temporary document to maintain the module graph until the module system came along. > Alan, can I cite you in "Reviewed-by? line as a reviewer for the modules.xml change? > > Thanks, > Attila. From christian.thalinger at oracle.com Wed Sep 16 16:52:01 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Sep 2015 06:52:01 -1000 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <55F9671C.4000208@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> Message-ID: > On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie wrote: > > On 2015-09-14 09:24, Christian Thalinger wrote: >> The JEP itself can be found here: >> >> https://bugs.openjdk.java.net/browse/JDK-8062493 >> >> Here are the webrevs: >> >> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >> >> The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: >> >> https://bugs.openjdk.java.net/browse/JDK-8134994 >> >> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. >> >> The integration will happen under the bug number: >> >> https://bugs.openjdk.java.net/browse/JDK-8136421 >> > Hi Christian, > > (Adding build-dev since this review includes some major build changes.) > > The makefile changes looks good in general to me. I have not reviewed the source code changes. > > Some comments: > > * modules.xml: > Make sure you get sign-off from a Jigsaw developer for modifying this file. I?ve asked Alan to take a look. > > * hotspot/make/linux/makefiles/gcc.make: > Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? We had this question before. It?s not obvious because you can?t see it in the regular diff views but this is under: ifeq ($(USE_CLANG), true) > > * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: > I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. Thanks for the heads up. > > Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. Ok, thanks. > > /Magnus From Alan.Bateman at oracle.com Wed Sep 16 16:52:37 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Sep 2015 17:52:37 +0100 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <55F9671C.4000208@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> Message-ID: <55F99E55.9080206@oracle.com> On 16/09/2015 13:57, Magnus Ihse Bursie wrote: > : > > * modules.xml: > Make sure you get sign-off from a Jigsaw developer for modifying this > file. The update to modules.xml looks fine. -Alan. From magnus.ihse.bursie at oracle.com Wed Sep 16 20:11:52 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Sep 2015 22:11:52 +0200 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> Message-ID: <55F9CD08.8010406@oracle.com> On 2015-09-16 18:52, Christian Thalinger wrote: >> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie wrote: >> >> On 2015-09-14 09:24, Christian Thalinger wrote: >>> The JEP itself can be found here: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8062493 >>> >>> Here are the webrevs: >>> >>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >>> >>> The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8134994 >>> >>> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. >>> >>> The integration will happen under the bug number: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8136421 >>> >> Hi Christian, >> >> (Adding build-dev since this review includes some major build changes.) >> >> The makefile changes looks good in general to me. I have not reviewed the source code changes. >> >> Some comments: >> >> * modules.xml: >> Make sure you get sign-off from a Jigsaw developer for modifying this file. > I?ve asked Alan to take a look. > >> * hotspot/make/linux/makefiles/gcc.make: >> Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? > We had this question before. It?s not obvious because you can?t see it in the regular diff views but this is under: > > ifeq ($(USE_CLANG), true) I'm not sure I understand why that's relevant..? Isn't it just as important to try to submit warning-free code when compiling with clang as with any other compiler? Or is clang just being anal about the code in question? /Magnus > >> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: >> I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. > Thanks for the heads up. > >> Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. > Ok, thanks. > >> /Magnus From christian.thalinger at oracle.com Wed Sep 16 20:25:30 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Sep 2015 10:25:30 -1000 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <55F9CD08.8010406@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <55F9CD08.8010406@oracle.com> Message-ID: <981500C6-EA6B-4BCE-972B-4981B5C1382F@oracle.com> > On Sep 16, 2015, at 10:11 AM, Magnus Ihse Bursie wrote: > > On 2015-09-16 18:52, Christian Thalinger wrote: >>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie wrote: >>> >>> On 2015-09-14 09:24, Christian Thalinger wrote: >>>> The JEP itself can be found here: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8062493 >>>> >>>> Here are the webrevs: >>>> >>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >>>> >>>> The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8134994 >>>> >>>> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. >>>> >>>> The integration will happen under the bug number: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8136421 >>>> >>> Hi Christian, >>> >>> (Adding build-dev since this review includes some major build changes.) >>> >>> The makefile changes looks good in general to me. I have not reviewed the source code changes. >>> >>> Some comments: >>> >>> * modules.xml: >>> Make sure you get sign-off from a Jigsaw developer for modifying this file. >> I?ve asked Alan to take a look. >> >>> * hotspot/make/linux/makefiles/gcc.make: >>> Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? >> We had this question before. It?s not obvious because you can?t see it in the regular diff views but this is under: >> >> ifeq ($(USE_CLANG), true) > > I'm not sure I understand why that's relevant..? Isn't it just as important to try to submit warning-free code when compiling with clang as with any other compiler? Or is clang just being anal about the code in question? I don?t have a Clang compiler at hand but Clang is anal about everything. Do you want that suppression to be removed? > > /Magnus > >> >>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: >>> I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. >> Thanks for the heads up. >> >>> Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. >> Ok, thanks. >> >>> /Magnus From christian.thalinger at oracle.com Wed Sep 16 21:28:04 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Sep 2015 11:28:04 -1000 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> Message-ID: <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> > On Sep 16, 2015, at 6:52 AM, Christian Thalinger wrote: > > >> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie wrote: >> >> On 2015-09-14 09:24, Christian Thalinger wrote: >>> The JEP itself can be found here: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8062493 >>> >>> Here are the webrevs: >>> >>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >>> >>> The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8134994 >>> >>> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. >>> >>> The integration will happen under the bug number: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8136421 >>> >> Hi Christian, >> >> (Adding build-dev since this review includes some major build changes.) >> >> The makefile changes looks good in general to me. I have not reviewed the source code changes. >> >> Some comments: >> >> * modules.xml: >> Make sure you get sign-off from a Jigsaw developer for modifying this file. > > I?ve asked Alan to take a look. > >> >> * hotspot/make/linux/makefiles/gcc.make: >> Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? > > We had this question before. It?s not obvious because you can?t see it in the regular diff views but this is under: > > ifeq ($(USE_CLANG), true) > >> >> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: >> I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. > > Thanks for the heads up. Erik sent me a patch to avoid merge conflicts. I?ve integrated two changesets: http://hg.openjdk.java.net/graal/graal-jvmci-9/rev/ddedccc5c0ab http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/fee6b89199c9 > >> >> Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. > > Ok, thanks. > >> >> /Magnus > From vladimir.kozlov at oracle.com Wed Sep 16 22:43:26 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Sep 2015 15:43:26 -0700 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> Message-ID: <55F9F08E.8010506@oracle.com> I updated top and hotspot webrev with latest (build) changes. Vladimir On 9/16/15 2:28 PM, Christian Thalinger wrote: > >> On Sep 16, 2015, at 6:52 AM, Christian Thalinger wrote: >> >> >>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie wrote: >>> >>> On 2015-09-14 09:24, Christian Thalinger wrote: >>>> The JEP itself can be found here: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8062493 >>>> >>>> Here are the webrevs: >>>> >>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >>>> >>>> The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8134994 >>>> >>>> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. >>>> >>>> The integration will happen under the bug number: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8136421 >>>> >>> Hi Christian, >>> >>> (Adding build-dev since this review includes some major build changes.) >>> >>> The makefile changes looks good in general to me. I have not reviewed the source code changes. >>> >>> Some comments: >>> >>> * modules.xml: >>> Make sure you get sign-off from a Jigsaw developer for modifying this file. >> >> I?ve asked Alan to take a look. >> >>> >>> * hotspot/make/linux/makefiles/gcc.make: >>> Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? >> >> We had this question before. It?s not obvious because you can?t see it in the regular diff views but this is under: >> >> ifeq ($(USE_CLANG), true) >> >>> >>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: >>> I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. >> >> Thanks for the heads up. > > Erik sent me a patch to avoid merge conflicts. I?ve integrated two changesets: > > http://hg.openjdk.java.net/graal/graal-jvmci-9/rev/ddedccc5c0ab > http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/fee6b89199c9 > >> >>> >>> Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. >> >> Ok, thanks. >> >>> >>> /Magnus >> > From erik.joelsson at oracle.com Thu Sep 17 00:27:01 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 Sep 2015 17:27:01 -0700 Subject: RFR: JDK-8135060: Stop building Xcode projects in install build Message-ID: <55FA08D5.8030500@oracle.com> Hello, Here is a patch to the top repo with some functional improvements to the common functionality in the makefiles. This is currently needed for the porting the build of some Oracle specific parts to using build-infra style makefiles. The changes include: * Ability to strip binaries at link time in SetupNativeCompilation. * Supply a custom macro to SetupCopyFiles to perform some kind of transformation when copying files. * A new flag to the compare script, --strip, which causes all native binaries to be stripped before being compared. Bug: https://bugs.openjdk.java.net/browse/JDK-8135060 Webrev: http://cr.openjdk.java.net/~erikj/8135060/webrev.01/ /Erik From christian.thalinger at oracle.com Thu Sep 17 01:05:18 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Sep 2015 15:05:18 -1000 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <55F9F08E.8010506@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> Message-ID: <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com> I would like to add this change: diff -r 2134e08cc132 src/share/vm/utilities/vmError.cpp --- a/src/share/vm/utilities/vmError.cpp Wed Sep 16 14:28:33 2015 -1000 +++ b/src/share/vm/utilities/vmError.cpp Wed Sep 16 15:04:02 2015 -1000 @@ -517,6 +517,10 @@ void VMError::report(outputStream* st) { Abstract_VM_Version::vm_release(), Abstract_VM_Version::vm_info_string(), TieredCompilation ? ", tiered" : "", +#if INCLUDE_JVMCI + EnableJVMCI ? ", jvmci" : "", + UseJVMCICompiler ? ", jvmci compiler" : "", +#endif UseCompressedOops ? ", compressed oops" : "", gc_mode(), Abstract_VM_Version::vm_platform_string() It would be useful to see in the crash logs if this experimental feature was turned on. > On Sep 16, 2015, at 12:43 PM, Vladimir Kozlov wrote: > > I updated top and hotspot webrev with latest (build) changes. > > Vladimir > > On 9/16/15 2:28 PM, Christian Thalinger wrote: >> >>> On Sep 16, 2015, at 6:52 AM, Christian Thalinger wrote: >>> >>> >>>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie wrote: >>>> >>>> On 2015-09-14 09:24, Christian Thalinger wrote: >>>>> The JEP itself can be found here: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8062493 >>>>> >>>>> Here are the webrevs: >>>>> >>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >>>>> >>>>> The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8134994 >>>>> >>>>> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. >>>>> >>>>> The integration will happen under the bug number: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8136421 >>>>> >>>> Hi Christian, >>>> >>>> (Adding build-dev since this review includes some major build changes.) >>>> >>>> The makefile changes looks good in general to me. I have not reviewed the source code changes. >>>> >>>> Some comments: >>>> >>>> * modules.xml: >>>> Make sure you get sign-off from a Jigsaw developer for modifying this file. >>> >>> I?ve asked Alan to take a look. >>> >>>> >>>> * hotspot/make/linux/makefiles/gcc.make: >>>> Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? >>> >>> We had this question before. It?s not obvious because you can?t see it in the regular diff views but this is under: >>> >>> ifeq ($(USE_CLANG), true) >>> >>>> >>>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: >>>> I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. >>> >>> Thanks for the heads up. >> >> Erik sent me a patch to avoid merge conflicts. I?ve integrated two changesets: >> >> http://hg.openjdk.java.net/graal/graal-jvmci-9/rev/ddedccc5c0ab > >> http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/fee6b89199c9 > >> >>> >>>> >>>> Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. >>> >>> Ok, thanks. >>> >>>> >>>> /Magnus From tim.bell at oracle.com Thu Sep 17 04:06:24 2015 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 16 Sep 2015 21:06:24 -0700 Subject: RFR: JDK-8135060: Stop building Xcode projects in install build In-Reply-To: <55FA08D5.8030500@oracle.com> References: <55FA08D5.8030500@oracle.com> Message-ID: <55FA3C40.8010502@oracle.com> Erik: > Here is a patch to the top repo with some functional improvements to > the common functionality in the makefiles. This is currently needed > for the porting the build of some Oracle specific parts to using > build-infra style makefiles. The changes include: > > * Ability to strip binaries at link time in SetupNativeCompilation. > * Supply a custom macro to SetupCopyFiles to perform some kind of > transformation when copying files. > * A new flag to the compare script, --strip, which causes all native > binaries to be stripped before being compared. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135060 > Webrev: http://cr.openjdk.java.net/~erikj/8135060/webrev.01 Looks good. Tim From magnus.ihse.bursie at oracle.com Thu Sep 17 07:21:16 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 17 Sep 2015 09:21:16 +0200 Subject: RFR: JDK-8135060: Stop building Xcode projects in install build In-Reply-To: <55FA08D5.8030500@oracle.com> References: <55FA08D5.8030500@oracle.com> Message-ID: <55FA69EC.2050705@oracle.com> On 2015-09-17 02:27, Erik Joelsson wrote: > Hello, > > Here is a patch to the top repo with some functional improvements to > the common functionality in the makefiles. This is currently needed > for the porting the build of some Oracle specific parts to using > build-infra style makefiles. The changes include: > > * Ability to strip binaries at link time in SetupNativeCompilation. > * Supply a custom macro to SetupCopyFiles to perform some kind of > transformation when copying files. > * A new flag to the compare script, --strip, which causes all native > binaries to be stripped before being compared. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135060 > Webrev: http://cr.openjdk.java.net/~erikj/8135060/webrev.01/ Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Thu Sep 17 07:24:51 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 17 Sep 2015 09:24:51 +0200 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <981500C6-EA6B-4BCE-972B-4981B5C1382F@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <55F9CD08.8010406@oracle.com> <981500C6-EA6B-4BCE-972B-4981B5C1382F@oracle.com> Message-ID: <55FA6AC3.2010609@oracle.com> On 2015-09-16 22:25, Christian Thalinger wrote: > >> On Sep 16, 2015, at 10:11 AM, Magnus Ihse Bursie >> > > wrote: >> >> On 2015-09-16 18:52, Christian Thalinger wrote: >>>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie >>>> >>> > wrote: >>>> >>>> On 2015-09-14 09:24, Christian Thalinger wrote: >>>>> The JEP itself can be found here: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8062493 >>>>> >>>>> >>>>> Here are the webrevs: >>>>> >>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >>>>> >>>>> >>>> > >>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >>>>> >>>>> >>>> > >>>>> >>>>> The change has already undergone a few iterations of internal >>>>> review by different people of different teams. Most comments and >>>>> suggestions were handled accordingly. Although there is one open >>>>> item we agreed we will address after the integration of JEP 243 >>>>> and that work is captured in RFE: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8134994 >>>>> >>>>> >>>>> SQE is still working on the tests and all test tasks can be seen >>>>> as sub-tasks of the JEP. >>>>> >>>>> The integration will happen under the bug number: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8136421 >>>>> >>>>> >>>> Hi Christian, >>>> >>>> (Adding build-dev since this review includes some major build changes.) >>>> >>>> The makefile changes looks good in general to me. I have not >>>> reviewed the source code changes. >>>> >>>> Some comments: >>>> >>>> * modules.xml: >>>> Make sure you get sign-off from a Jigsaw developer for modifying >>>> this file. >>> I?ve asked Alan to take a look. >>> >>>> * hotspot/make/linux/makefiles/gcc.make: >>>> Seems unfortunate to have to disable a new warning >>>> (undefined-bool-conversion) for newly incorporated code. Is it not >>>> possible to fix the code emitting this warning instead? >>> We had this question before. It?s not obvious because you can?t see >>> it in the regular diff views but this is under: >>> >>> ifeq ($(USE_CLANG), true) >> >> I'm not sure I understand why that's relevant..? Isn't it just as >> important to try to submit warning-free code when compiling with >> clang as with any other compiler? Or is clang just being anal about >> the code in question? > > I don?t have a Clang compiler at hand but Clang is anal about > everything. Do you want that suppression to be removed? It's more a hotspot code quality issue, not a build system issue, so I won't insist. I just wanted to point out that this change will start hiding a new kind of warning for all files in hotspot. Unless there was a compelling reason, I would personally rather see an effort to fix the code in question. But if no-one from Hotspot agrees on this, I'll drop it. /Magnus From volker.simonis at gmail.com Thu Sep 17 10:08:58 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 17 Sep 2015 12:08:58 +0200 Subject: RFR(XS): 8136690: AIX: libjimage should be linked with the C++ compiler Message-ID: Hi, can somebody please review the following AIX change which fixes the build on AIX after "8087181 Move native jimage code to its own library (maybe libjimage)": http://cr.openjdk.java.net/~simonis/webrevs/2015/8136690/ https://bugs.openjdk.java.net/browse/JDK-8136690 Change 8087181 moved the jimage code into its own library into the jdk repository. Although libjimage is a C++ library it is currently linked by the C compiler together with platform dependent C++ system libraries (and I'm not sure if this is done intentionally or if it is just a copy-and-paste error). On AIX linking a C++ library with the C-compiler doesn't work and we have to link the library with the C++ compiler which automatically adds all the required dependencies. Thank you and best regards, Volker From magnus.ihse.bursie at oracle.com Thu Sep 17 13:00:13 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 17 Sep 2015 15:00:13 +0200 Subject: RFR(XS): 8136690: AIX: libjimage should be linked with the C++ compiler In-Reply-To: References: Message-ID: <55FAB95D.40100@oracle.com> On 2015-09-17 12:08, Volker Simonis wrote: > Hi, > > can somebody please review the following AIX change which fixes the > build on AIX after "8087181 Move native jimage code to its own library > (maybe libjimage)": > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8136690/ > https://bugs.openjdk.java.net/browse/JDK-8136690 Looks good to me. /Magnus > > Change 8087181 moved the jimage code into its own library into the jdk > repository. Although libjimage is a C++ library it is currently linked > by the C compiler together with platform dependent C++ system > libraries (and I'm not sure if this is done intentionally or if it is > just a copy-and-paste error). > > On AIX linking a C++ library with the C-compiler doesn't work and we > have to link the library with the C++ compiler which automatically > adds all the required dependencies. > > Thank you and best regards, > Volker From denis.fokin at gmail.com Thu Sep 17 13:04:15 2015 From: denis.fokin at gmail.com (Denis Fokin) Date: Thu, 17 Sep 2015 16:04:15 +0300 Subject: Building openjdk 8u on OS X 10.11 fails In-Reply-To: <861FA87D-388F-45B8-837E-F2C86D502446@gmail.com> References: <7C29F8CD-BF8C-4748-B86C-924AB8005899@gmail.com> <861FA87D-388F-45B8-837E-F2C86D502446@gmail.com> Message-ID: Hi Alex, I have just updated to 10.11 and experienced the same problem. The solution is "export MACOSX_DEPLOYMENT_TARGET=10.9" Thank you, Denis On Fri, Jul 17, 2015 at 7:56 AM, Alex Wang wrote: > Edit for formatting. Forgot that soft wraps were a thing. My apologies. > > I?m not really sure if this is something for the jdk developers or an > upstream > issue, since the error doesn?t seem to be strictly under idk control (the > error > looks to me to be something g++ does); I just thought to check in case > there?s > an easy solution (and I?m not really sure if reporting a problem for Xcode > 4 > would really accomplish anything). If I?m in the wrong place please let me > know. > > Running OS X 10.11, JAVA_HOME is set to a 1.7 install, xcode-select is > pointing > at the right application, and I *think* the Xcode 4 command line tools were > installed. Ran xcode-select ?install after switching, and it prompted for > an > install, at least. > > ./configure ?with-xcode-path= fails with this in config.log: > > configure:28891: checking for stdio.h > configure:28891: result: yes > configure:28919: checking size of int * > configure:28924: /usr/bin/g++ -o conftest conftest.cpp >&5 > couldn't understand kern.osversion `15.0.0' > ld: library not found for -lgcc_s.10.4 > collect2: ld returned 1 exit status > configure:28924: $? = 1 > configure: program exited with status 1 > configure: failed program was: > | /* confdefs.h */ > > configure:28938: result: 0 > configure:28960: The tested number of bits in the target (0) differs from > the > number of bits expected to be found in the target (64). > configure:28962: I'll retry after setting the platforms compiler target > bits > flag to -m64 > configure:28993: checking size of int * > configure:28998: /usr/bin/g++ -o conftest -m64 -m64 conftest.cpp >&5 > couldn't understand kern.osversion `15.0.0' > ld: library not found for -lgcc_s.10.4 > collect2: ld returned 1 exit status > configure:28998: $? = 1 > configure: program exited with status 1 > configure: failed program was: > | /* confdefs.h */ > > configure:29012: result: 0 > configure:29026: error: The tested number of bits in the target (0) > differs from > the number of bits expected to be found in the target (64) > > I looked around for a solution for the missing library, nothing I found > really > helped. One suggestion was to symlink it to the OS-provided one (l > Unfortunately, 10.11?s new rootless feature means that I can?t write to > that > folder, and I don?t know if disabling that feature just for a build is the > best > idea. Another was to change the library in the build scripts. I took a look > around, but the closest thing I could find in the config scripts were -lgcc > flags, so I figured something else was the cause. > > I also tried messing with symlinking bits and pieces of Xcode 7?s > toolchain into > Xcode 4 to try and replace the offending binary, but nothing seemed to > change. > Using Xcode 4?s gcc sometimes worked, and sometimes produced the same > error. I?m > not really sure what about the programs I threw at it caused it to fail or > not, > but at least it seemed consistent for any particular program. > > If I can provide more info that would be helpful, I?ll be happy to do so. > > From magnus.ihse.bursie at oracle.com Thu Sep 17 13:41:46 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 17 Sep 2015 15:41:46 +0200 Subject: RFR: JDK-8136695 Automatic build comparison with COMPARE_BUILD Message-ID: <55FAC31A.1000603@oracle.com> A common scenario in when working in the build system is to want to check if a particular change results in a change in the build output or not, or a more detailed analysis of such changes. The compare.sh tool will provide such an analysis, but only if you have a pre-built baseline to compare with. To facilitate testing changes, especially on distributed job servers, we should add a COMPARE_BUILD make control variable. If this variable is present, the build will run twice, the second time with the code that should be tested (particular make targets, configure arguments, or with a patch file applied), and then automatically run the compare script afterwards against the baseline. The suggested format allows for a very fine-grained control, by further parsing the value of COMPARE_BUILD into separate parts. The syntax looks like this: COMPARE_BUILD=CONF=:PATCH=:MAKE=:COMP_OPTS=| If neither CONF or PATCH is given, assume means CONF if it begins with "--", otherwise assume it means PATCH. Either CONF or PATCH must be given, directly specified or by using the default syntax. The rest of the key/value pairs are optional, and they may come in any order. MAKE and COMP_OPTS can only be used with CONF and/or PATCH specified. If any value contains "+", it will be replaced by space. If just a single value is specified, it can contain spaces, e.g. "COMPARE_BUILD=CONF=--enable-debug --with-special-sauce". (For technical reasons, this is not possible if using multiple, colon-separated key=value pairs). Values given in CONF and MAKE are appended to the normal configure command line and make target list, respectively, when building the second comparison round. The patch file, if specified, could be either absolute or relative to TOPDIR. COMP_OPTS is additional options to pass to compare.sh. Bug: https://bugs.openjdk.java.net/browse/JDK-8136695 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8136695-compare_build/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Sep 17 15:14:40 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Sep 2015 08:14:40 -0700 Subject: RFR: JDK-8136695 Automatic build comparison with COMPARE_BUILD In-Reply-To: <55FAC31A.1000603@oracle.com> References: <55FAC31A.1000603@oracle.com> Message-ID: <55FAD8E0.3070802@oracle.com> Nice work! I wonder what happens if you invoke this target from the build output directory? I can imagine it not working too well, but would like a graceful exit in that case. /Erik On 2015-09-17 06:41, Magnus Ihse Bursie wrote: > A common scenario in when working in the build system is to want to > check if a particular change results in a change in the build output > or not, or a more detailed analysis of such changes. > > The compare.sh tool will provide such an analysis, but only if you > have a pre-built baseline to compare with. > > To facilitate testing changes, especially on distributed job servers, > we should add a COMPARE_BUILD make control variable. If this variable > is present, the build will run twice, the second time with the code > that should be tested (particular make targets, configure arguments, > or with a patch file applied), and then automatically run the compare > script afterwards against the baseline. > > The suggested format allows for a very fine-grained control, by > further parsing the value of COMPARE_BUILD into separate parts. The > syntax looks like this: > COMPARE_BUILD=CONF=:PATCH=:MAKE= targets>:COMP_OPTS=| > > If neither CONF or PATCH is given, assume means CONF if it > begins with "--", otherwise assume it means PATCH. Either CONF or > PATCH must be given, directly specified or by using the default > syntax. The rest of the key/value pairs are optional, and they may > come in any order. > > MAKE and COMP_OPTS can only be used with CONF and/or PATCH specified. > If any value contains "+", it will be replaced by space. > If just a single value is specified, it can contain spaces, e.g. > "COMPARE_BUILD=CONF=--enable-debug --with-special-sauce". (For > technical reasons, this is not possible if using multiple, > colon-separated key=value pairs). > > Values given in CONF and MAKE are appended to the normal configure > command line and make target list, respectively, when building the > second comparison round. > > The patch file, if specified, could be either absolute or relative to > TOPDIR. > > COMP_OPTS is additional options to pass to compare.sh. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136695 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8136695-compare_build/webrev.01 > > /Magnus > From steve.drach at oracle.com Thu Sep 17 20:23:44 2015 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 17 Sep 2015 13:23:44 -0700 Subject: FYI -- Mac Xcode 7.0 (7A220) causes build failure Message-ID: <65389EA5-5247-4C19-BFA7-0ACC79BFD5C5@oracle.com> $ make all Compiling 5 files for BUILD_GENMODULESLIST Building target 'all' in configuration 'macosx-x86_64-normal-server-release' Compiling 8 files for BUILD_TOOLS_LANGTOOLS /jdk9/hotspot/make/bsd/makefiles/gcc.make:324: *** "Update compiler workarounds for Clang 7.0". Stop. This is the Xcode version that supports IOS 9 development. The previous Version 6.4 (6E35b) worked fine. From christian.thalinger at oracle.com Thu Sep 17 20:32:58 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Sep 2015 10:32:58 -1000 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com> Message-ID: Since there are no objections I?m going to push this? http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/6a6766a8cbbf > On Sep 16, 2015, at 3:05 PM, Christian Thalinger wrote: > > I would like to add this change: > > diff -r 2134e08cc132 src/share/vm/utilities/vmError.cpp > --- a/src/share/vm/utilities/vmError.cpp Wed Sep 16 14:28:33 2015 -1000 > +++ b/src/share/vm/utilities/vmError.cpp Wed Sep 16 15:04:02 2015 -1000 > @@ -517,6 +517,10 @@ void VMError::report(outputStream* st) { > Abstract_VM_Version::vm_release(), > Abstract_VM_Version::vm_info_string(), > TieredCompilation ? ", tiered" : "", > +#if INCLUDE_JVMCI > + EnableJVMCI ? ", jvmci" : "", > + UseJVMCICompiler ? ", jvmci compiler" : "", > +#endif > UseCompressedOops ? ", compressed oops" : "", > gc_mode(), > Abstract_VM_Version::vm_platform_string() > > It would be useful to see in the crash logs if this experimental feature was turned on. > >> On Sep 16, 2015, at 12:43 PM, Vladimir Kozlov wrote: >> >> I updated top and hotspot webrev with latest (build) changes. >> >> Vladimir >> >> On 9/16/15 2:28 PM, Christian Thalinger wrote: >>> >>>> On Sep 16, 2015, at 6:52 AM, Christian Thalinger wrote: >>>> >>>> >>>>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie wrote: >>>>> >>>>> On 2015-09-14 09:24, Christian Thalinger wrote: >>>>>> The JEP itself can be found here: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8062493 >>>>>> >>>>>> Here are the webrevs: >>>>>> >>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >>>>>> >>>>>> The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8134994 >>>>>> >>>>>> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. >>>>>> >>>>>> The integration will happen under the bug number: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8136421 >>>>>> >>>>> Hi Christian, >>>>> >>>>> (Adding build-dev since this review includes some major build changes.) >>>>> >>>>> The makefile changes looks good in general to me. I have not reviewed the source code changes. >>>>> >>>>> Some comments: >>>>> >>>>> * modules.xml: >>>>> Make sure you get sign-off from a Jigsaw developer for modifying this file. >>>> >>>> I?ve asked Alan to take a look. >>>> >>>>> >>>>> * hotspot/make/linux/makefiles/gcc.make: >>>>> Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? >>>> >>>> We had this question before. It?s not obvious because you can?t see it in the regular diff views but this is under: >>>> >>>> ifeq ($(USE_CLANG), true) >>>> >>>>> >>>>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: >>>>> I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. >>>> >>>> Thanks for the heads up. >>> >>> Erik sent me a patch to avoid merge conflicts. I?ve integrated two changesets: >>> >>> http://hg.openjdk.java.net/graal/graal-jvmci-9/rev/ddedccc5c0ab > >>> http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/fee6b89199c9 > >>> >>>> >>>>> >>>>> Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. >>>> >>>> Ok, thanks. >>>> >>>>> >>>>> /Magnus > From henry.jen at oracle.com Thu Sep 17 22:20:40 2015 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 17 Sep 2015 15:20:40 -0700 Subject: FYI -- Mac Xcode 7.0 (7A220) causes build failure In-Reply-To: <65389EA5-5247-4C19-BFA7-0ACC79BFD5C5@oracle.com> References: <65389EA5-5247-4C19-BFA7-0ACC79BFD5C5@oracle.com> Message-ID: <2E65A513-3FA6-45A8-819E-CD2DBD050D63@oracle.com> Looks like hotspot team wants to verify new version of clang does the right thing, I simply comment out the line to get a build. As the test is for clang older than 6.1, I suspect it should be pretty safe to do so. I?ll report back if my build have any problem, it seems fine so far. Cheers, Henry > On Sep 17, 2015, at 1:23 PM, Steve Drach wrote: > > $ make all > Compiling 5 files for BUILD_GENMODULESLIST > Building target 'all' in configuration 'macosx-x86_64-normal-server-release' > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > /jdk9/hotspot/make/bsd/makefiles/gcc.make:324: *** "Update compiler workarounds for Clang 7.0". Stop. > > This is the Xcode version that supports IOS 9 development. The previous Version 6.4 (6E35b) worked fine. From ioi.lam at oracle.com Thu Sep 17 22:44:20 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 17 Sep 2015 15:44:20 -0700 Subject: RFR (S) - 8065155 Refactor Hotspot mapfiles Message-ID: <55FB4244.4080509@oracle.com> Please review a small fix: http://cr.openjdk.java.net/~iklam/8065155-refactor-hotspot-mapfiles.00/ Bug: Refactor Hotspot mapfiles https://bugs.openjdk.java.net/browse/JDK-8065155 Summary of fix: After this fix, when you're adding a new JVM_XXX or JNI_XXX function, you no longer need to edit *9* files!! I checked the mapfiles of all platforms that are in the jdk9/hs-rt repo: [a] linux, solaris, bsd, bsd-darwin all have an identical common part that contains many JNI_ and JVM_ functions. [b] the common parts of linux, solaris and bsd are sorted in the same order. bsd-darwin is sorted differently but the contents are the same. [c] aix is slightly differently than the other platforms, probably due to code rot. So the fix is to move the common part into a separate file. I changed the makefiles of all platforms to concatenate the common part into the main mapfile. As part of the fix, I also addressed: JDK-8134783 - libjvm.so is not rebuilt after mapfile-ext is modified Note that I have not tested AIX since I don't have a build environment. However, it should be no worse than before. Tests: JPRT (passed) RBT (will do it before pushing) Thanks - Ioi From magnus.ihse.bursie at oracle.com Fri Sep 18 07:06:03 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Sep 2015 09:06:03 +0200 Subject: RFR (S) - 8065155 Refactor Hotspot mapfiles In-Reply-To: <55FB4244.4080509@oracle.com> References: <55FB4244.4080509@oracle.com> Message-ID: <55FBB7DB.9000101@oracle.com> On 2015-09-18 00:44, Ioi Lam wrote: > Please review a small fix: > > http://cr.openjdk.java.net/~iklam/8065155-refactor-hotspot-mapfiles.00/ Looks good to me. /Magnus > > Bug: Refactor Hotspot mapfiles > > https://bugs.openjdk.java.net/browse/JDK-8065155 > > Summary of fix: > > After this fix, when you're adding a new JVM_XXX or JNI_XXX function, > you no longer need to edit *9* files!! > > I checked the mapfiles of all platforms that are in the jdk9/hs-rt > repo: > > [a] linux, solaris, bsd, bsd-darwin all have an identical common > part that > contains many JNI_ and JVM_ functions. > [b] the common parts of linux, solaris and bsd are sorted in the > same order. > bsd-darwin is sorted differently but the contents are the same. > [c] aix is slightly differently than the other platforms, probably > due to > code rot. > > So the fix is to move the common part into a separate file. I > changed the makefiles of all platforms to concatenate the common > part into > the main mapfile. > > As part of the fix, I also addressed: > JDK-8134783 - libjvm.so is not rebuilt after mapfile-ext is > modified > > Note that I have not tested AIX since I don't have a build > environment. However, > it should be no worse than before. > > Tests: > > JPRT (passed) > RBT (will do it before pushing) > > Thanks > - Ioi From magnus.ihse.bursie at oracle.com Fri Sep 18 08:06:31 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Sep 2015 10:06:31 +0200 Subject: RFR: JDK-8136695 Automatic build comparison with COMPARE_BUILD In-Reply-To: <55FAD8E0.3070802@oracle.com> References: <55FAC31A.1000603@oracle.com> <55FAD8E0.3070802@oracle.com> Message-ID: <55FBC607.8000601@oracle.com> On 2015-09-17 17:14, Erik Joelsson wrote: > Nice work! > > I wonder what happens if you invoke this target from the build output > directory? I can imagine it not working too well, but would like a > graceful exit in that case. I keep forgetting about that use case, since I don't use it regularly myself. :-( It was not too bad, though. I've updated the patch slightly, to cd to topdir before moving away the old directory. It works fine on my Linux computer, but I imagine there might be problems on Windows to rename a directory if it's in use. I also noticed a problem with the MAKE= part, due to a last-minute rename of the argument, which i fixed, and I added the new make target(s) to the output so it's correct about what is to be run. Updated webrev, only changed in Init.gmk: http://cr.openjdk.java.net/~ihse/JDK-8136695-compare_build/webrev.02 /Magnus > > /Erik > > On 2015-09-17 06:41, Magnus Ihse Bursie wrote: >> A common scenario in when working in the build system is to want to >> check if a particular change results in a change in the build output >> or not, or a more detailed analysis of such changes. >> >> The compare.sh tool will provide such an analysis, but only if you >> have a pre-built baseline to compare with. >> >> To facilitate testing changes, especially on distributed job servers, >> we should add a COMPARE_BUILD make control variable. If this variable >> is present, the build will run twice, the second time with the code >> that should be tested (particular make targets, configure arguments, >> or with a patch file applied), and then automatically run the compare >> script afterwards against the baseline. >> >> The suggested format allows for a very fine-grained control, by >> further parsing the value of COMPARE_BUILD into separate parts. The >> syntax looks like this: >> COMPARE_BUILD=CONF=:PATCH=:MAKE=> targets>:COMP_OPTS=| >> >> If neither CONF or PATCH is given, assume means CONF if it >> begins with "--", otherwise assume it means PATCH. Either CONF or >> PATCH must be given, directly specified or by using the default >> syntax. The rest of the key/value pairs are optional, and they may >> come in any order. >> >> MAKE and COMP_OPTS can only be used with CONF and/or PATCH specified. >> If any value contains "+", it will be replaced by space. >> If just a single value is specified, it can contain spaces, e.g. >> "COMPARE_BUILD=CONF=--enable-debug --with-special-sauce". (For >> technical reasons, this is not possible if using multiple, >> colon-separated key=value pairs). >> >> Values given in CONF and MAKE are appended to the normal configure >> command line and make target list, respectively, when building the >> second comparison round. >> >> The patch file, if specified, could be either absolute or relative to >> TOPDIR. >> >> COMP_OPTS is additional options to pass to compare.sh. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8136695 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8136695-compare_build/webrev.01 >> >> /Magnus >> > From volker.simonis at gmail.com Fri Sep 18 08:20:17 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 18 Sep 2015 10:20:17 +0200 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com> Message-ID: For the top-level change I always get a strange error when importing it: patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh 8062493_jvmci_top_0911.v1.patch It is because of the strange path syntax of the last hunk in the patch file: --- old/./modules.xml 2015-09-16 15:11:14.000000000 -0700 +++ new/./modules.xml 2015-09-16 15:11:14.000000000 -0700 @@ -254,6 +254,14 @@ jdk.jfr + jdk.internal.jvmci.hotspot + jdk.jfr + + + jdk.internal.jvmci.hotspot.events + jdk.jfr + + sun.misc java.corba java.desktop Notice the strange syntax "old/./modules.xml" and "new/./modules.xml". If I remove the redundant './' from the path, everything works fine. For some reason only the diffs for modules.xml has this strange path syntax in the patch. Regards, Volker On Thu, Sep 17, 2015 at 10:32 PM, Christian Thalinger wrote: > Since there are no objections I?m going to push this? > > http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/6a6766a8cbbf > >> On Sep 16, 2015, at 3:05 PM, Christian Thalinger wrote: >> >> I would like to add this change: >> >> diff -r 2134e08cc132 src/share/vm/utilities/vmError.cpp >> --- a/src/share/vm/utilities/vmError.cpp Wed Sep 16 14:28:33 2015 -1000 >> +++ b/src/share/vm/utilities/vmError.cpp Wed Sep 16 15:04:02 2015 -1000 >> @@ -517,6 +517,10 @@ void VMError::report(outputStream* st) { >> Abstract_VM_Version::vm_release(), >> Abstract_VM_Version::vm_info_string(), >> TieredCompilation ? ", tiered" : "", >> +#if INCLUDE_JVMCI >> + EnableJVMCI ? ", jvmci" : "", >> + UseJVMCICompiler ? ", jvmci compiler" : "", >> +#endif >> UseCompressedOops ? ", compressed oops" : "", >> gc_mode(), >> Abstract_VM_Version::vm_platform_string() >> >> It would be useful to see in the crash logs if this experimental feature was turned on. >> >>> On Sep 16, 2015, at 12:43 PM, Vladimir Kozlov wrote: >>> >>> I updated top and hotspot webrev with latest (build) changes. >>> >>> Vladimir >>> >>> On 9/16/15 2:28 PM, Christian Thalinger wrote: >>>> >>>>> On Sep 16, 2015, at 6:52 AM, Christian Thalinger wrote: >>>>> >>>>> >>>>>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie wrote: >>>>>> >>>>>> On 2015-09-14 09:24, Christian Thalinger wrote: >>>>>>> The JEP itself can be found here: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8062493 >>>>>>> >>>>>>> Here are the webrevs: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >>>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >>>>>>> >>>>>>> The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134994 >>>>>>> >>>>>>> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. >>>>>>> >>>>>>> The integration will happen under the bug number: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8136421 >>>>>>> >>>>>> Hi Christian, >>>>>> >>>>>> (Adding build-dev since this review includes some major build changes.) >>>>>> >>>>>> The makefile changes looks good in general to me. I have not reviewed the source code changes. >>>>>> >>>>>> Some comments: >>>>>> >>>>>> * modules.xml: >>>>>> Make sure you get sign-off from a Jigsaw developer for modifying this file. >>>>> >>>>> I?ve asked Alan to take a look. >>>>> >>>>>> >>>>>> * hotspot/make/linux/makefiles/gcc.make: >>>>>> Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? >>>>> >>>>> We had this question before. It?s not obvious because you can?t see it in the regular diff views but this is under: >>>>> >>>>> ifeq ($(USE_CLANG), true) >>>>> >>>>>> >>>>>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: >>>>>> I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. >>>>> >>>>> Thanks for the heads up. >>>> >>>> Erik sent me a patch to avoid merge conflicts. I?ve integrated two changesets: >>>> >>>> http://hg.openjdk.java.net/graal/graal-jvmci-9/rev/ddedccc5c0ab > >>>> http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/fee6b89199c9 > >>>> >>>>> >>>>>> >>>>>> Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. >>>>> >>>>> Ok, thanks. >>>>> >>>>>> >>>>>> /Magnus >> > From bertrand.delsart at oracle.com Fri Sep 18 09:11:14 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Fri, 18 Sep 2015 11:11:14 +0200 Subject: RFR (S) - 8065155 Refactor Hotspot mapfiles In-Reply-To: <55FB4244.4080509@oracle.com> References: <55FB4244.4080509@oracle.com> Message-ID: <55FBD532.1060105@oracle.com> Looks good. Thanks, Bertrand (not a Reviewer). On 18/09/2015 00:44, Ioi Lam wrote: > Please review a small fix: > > http://cr.openjdk.java.net/~iklam/8065155-refactor-hotspot-mapfiles.00/ > > Bug: Refactor Hotspot mapfiles > > https://bugs.openjdk.java.net/browse/JDK-8065155 > > Summary of fix: > > After this fix, when you're adding a new JVM_XXX or JNI_XXX function, > you no longer need to edit *9* files!! > > I checked the mapfiles of all platforms that are in the jdk9/hs-rt > repo: > > [a] linux, solaris, bsd, bsd-darwin all have an identical common > part that > contains many JNI_ and JVM_ functions. > [b] the common parts of linux, solaris and bsd are sorted in the > same order. > bsd-darwin is sorted differently but the contents are the same. > [c] aix is slightly differently than the other platforms, probably > due to > code rot. > > So the fix is to move the common part into a separate file. I > changed the makefiles of all platforms to concatenate the common > part into > the main mapfile. > > As part of the fix, I also addressed: > JDK-8134783 - libjvm.so is not rebuilt after mapfile-ext is > modified > > Note that I have not tested AIX since I don't have a build > environment. However, > it should be no worse than before. > > Tests: > > JPRT (passed) > RBT (will do it before pushing) > > Thanks > - Ioi -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From magnus.ihse.bursie at oracle.com Fri Sep 18 09:29:05 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Sep 2015 11:29:05 +0200 Subject: RFR: JDK-8136695 Automatic build comparison with COMPARE_BUILD In-Reply-To: <55FBC607.8000601@oracle.com> References: <55FAC31A.1000603@oracle.com> <55FAD8E0.3070802@oracle.com> <55FBC607.8000601@oracle.com> Message-ID: <55FBD961.7070706@oracle.com> On 2015-09-18 10:06, Magnus Ihse Bursie wrote: > On 2015-09-17 17:14, Erik Joelsson wrote: >> Nice work! >> >> I wonder what happens if you invoke this target from the build output >> directory? I can imagine it not working too well, but would like a >> graceful exit in that case. > > I keep forgetting about that use case, since I don't use it regularly > myself. :-( > > It was not too bad, though. I've updated the patch slightly, to cd to > topdir before moving away the old directory. It works fine on my Linux > computer, but I imagine there might be problems on Windows to rename a > directory if it's in use. > > I also noticed a problem with the MAKE= part, due to a > last-minute rename of the argument, which i fixed, and I added the new > make target(s) to the output so it's correct about what is to be run. > > Updated webrev, only changed in Init.gmk: > http://cr.openjdk.java.net/~ihse/JDK-8136695-compare_build/webrev.02 *sigh* I found a problem when running without a PATCH file, and have updated the PATCH file check in the end in InitSupport.gmk: http://cr.openjdk.java.net/~ihse/JDK-8136695-compare_build/webrev.03 /Magnus > > /Magnus > >> >> /Erik >> >> On 2015-09-17 06:41, Magnus Ihse Bursie wrote: >>> A common scenario in when working in the build system is to want to >>> check if a particular change results in a change in the build output >>> or not, or a more detailed analysis of such changes. >>> >>> The compare.sh tool will provide such an analysis, but only if you >>> have a pre-built baseline to compare with. >>> >>> To facilitate testing changes, especially on distributed job >>> servers, we should add a COMPARE_BUILD make control variable. If >>> this variable is present, the build will run twice, the second time >>> with the code that should be tested (particular make targets, >>> configure arguments, or with a patch file applied), and then >>> automatically run the compare script afterwards against the baseline. >>> >>> The suggested format allows for a very fine-grained control, by >>> further parsing the value of COMPARE_BUILD into separate parts. The >>> syntax looks like this: >>> COMPARE_BUILD=CONF=:PATCH=:MAKE=>> targets>:COMP_OPTS=| >>> >>> If neither CONF or PATCH is given, assume means CONF if it >>> begins with "--", otherwise assume it means PATCH. Either CONF or >>> PATCH must be given, directly specified or by using the default >>> syntax. The rest of the key/value pairs are optional, and they may >>> come in any order. >>> >>> MAKE and COMP_OPTS can only be used with CONF and/or PATCH >>> specified. If any value contains "+", it will be replaced by space. >>> If just a single value is specified, it can contain spaces, e.g. >>> "COMPARE_BUILD=CONF=--enable-debug --with-special-sauce". (For >>> technical reasons, this is not possible if using multiple, >>> colon-separated key=value pairs). >>> >>> Values given in CONF and MAKE are appended to the normal configure >>> command line and make target list, respectively, when building the >>> second comparison round. >>> >>> The patch file, if specified, could be either absolute or relative >>> to TOPDIR. >>> >>> COMP_OPTS is additional options to pass to compare.sh. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136695 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8136695-compare_build/webrev.01 >>> >>> /Magnus >>> >> > From magnus.ihse.bursie at oracle.com Fri Sep 18 14:47:26 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Sep 2015 16:47:26 +0200 Subject: RFR: JDK-8136764 ORIGINAL_PATH is broken if PATH contains directory with "#" in it's name Message-ID: <55FC23FE.8090202@oracle.com> If the PATH contains a directory with a # in it's name, we will store ORIGINAL_PATH=...#... in spec.gmk. However, this will result in make cutting the line at #, believing the rest to be a comment. Unfortunately, having directories named # is not so esoteric it at first seems, since Microsoft Visual Studio typically adds it's F# implementation to the PATH. :-( Bug: https://bugs.openjdk.java.net/browse/JDK-8136764 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8136764-escape-hash-in-ORIGINAL_PATH/webrev.01 /Magnus From erik.joelsson at oracle.com Fri Sep 18 16:18:08 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Sep 2015 09:18:08 -0700 Subject: RFR: JDK-8136695 Automatic build comparison with COMPARE_BUILD In-Reply-To: <55FBD961.7070706@oracle.com> References: <55FAC31A.1000603@oracle.com> <55FAD8E0.3070802@oracle.com> <55FBC607.8000601@oracle.com> <55FBD961.7070706@oracle.com> Message-ID: <55FC3940.3070208@oracle.com> Looks good to me. /Erik On 2015-09-18 02:29, Magnus Ihse Bursie wrote: > On 2015-09-18 10:06, Magnus Ihse Bursie wrote: >> On 2015-09-17 17:14, Erik Joelsson wrote: >>> Nice work! >>> >>> I wonder what happens if you invoke this target from the build >>> output directory? I can imagine it not working too well, but would >>> like a graceful exit in that case. >> >> I keep forgetting about that use case, since I don't use it regularly >> myself. :-( >> >> It was not too bad, though. I've updated the patch slightly, to cd to >> topdir before moving away the old directory. It works fine on my >> Linux computer, but I imagine there might be problems on Windows to >> rename a directory if it's in use. >> >> I also noticed a problem with the MAKE= part, due to a >> last-minute rename of the argument, which i fixed, and I added the >> new make target(s) to the output so it's correct about what is to be >> run. >> >> Updated webrev, only changed in Init.gmk: >> http://cr.openjdk.java.net/~ihse/JDK-8136695-compare_build/webrev.02 > > *sigh* I found a problem when running without a PATCH file, and have > updated the PATCH file check in the end in InitSupport.gmk: > http://cr.openjdk.java.net/~ihse/JDK-8136695-compare_build/webrev.03 > > /Magnus > >> >> /Magnus >> >>> >>> /Erik >>> >>> On 2015-09-17 06:41, Magnus Ihse Bursie wrote: >>>> A common scenario in when working in the build system is to want to >>>> check if a particular change results in a change in the build >>>> output or not, or a more detailed analysis of such changes. >>>> >>>> The compare.sh tool will provide such an analysis, but only if you >>>> have a pre-built baseline to compare with. >>>> >>>> To facilitate testing changes, especially on distributed job >>>> servers, we should add a COMPARE_BUILD make control variable. If >>>> this variable is present, the build will run twice, the second time >>>> with the code that should be tested (particular make targets, >>>> configure arguments, or with a patch file applied), and then >>>> automatically run the compare script afterwards against the baseline. >>>> >>>> The suggested format allows for a very fine-grained control, by >>>> further parsing the value of COMPARE_BUILD into separate parts. The >>>> syntax looks like this: >>>> COMPARE_BUILD=CONF=:PATCH=>>> file>:MAKE=:COMP_OPTS=| >>>> >>>> If neither CONF or PATCH is given, assume means CONF if >>>> it begins with "--", otherwise assume it means PATCH. Either CONF >>>> or PATCH must be given, directly specified or by using the default >>>> syntax. The rest of the key/value pairs are optional, and they may >>>> come in any order. >>>> >>>> MAKE and COMP_OPTS can only be used with CONF and/or PATCH >>>> specified. If any value contains "+", it will be replaced by space. >>>> If just a single value is specified, it can contain spaces, e.g. >>>> "COMPARE_BUILD=CONF=--enable-debug --with-special-sauce". (For >>>> technical reasons, this is not possible if using multiple, >>>> colon-separated key=value pairs). >>>> >>>> Values given in CONF and MAKE are appended to the normal configure >>>> command line and make target list, respectively, when building the >>>> second comparison round. >>>> >>>> The patch file, if specified, could be either absolute or relative >>>> to TOPDIR. >>>> >>>> COMP_OPTS is additional options to pass to compare.sh. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136695 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8136695-compare_build/webrev.01 >>>> >>>> /Magnus >>>> >>> >> > From erik.joelsson at oracle.com Fri Sep 18 16:19:40 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Sep 2015 09:19:40 -0700 Subject: RFR: JDK-8136764 ORIGINAL_PATH is broken if PATH contains directory with "#" in it's name In-Reply-To: <55FC23FE.8090202@oracle.com> References: <55FC23FE.8090202@oracle.com> Message-ID: <55FC399C.3020204@oracle.com> Looks good. /Erik On 2015-09-18 07:47, Magnus Ihse Bursie wrote: > If the PATH contains a directory with a # in it's name, we will store > ORIGINAL_PATH=...#... in spec.gmk. > > However, this will result in make cutting the line at #, believing the > rest to be a comment. > > Unfortunately, having directories named # is not so esoteric it at > first seems, since Microsoft Visual Studio typically adds it's F# > implementation to the PATH. :-( > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136764 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8136764-escape-hash-in-ORIGINAL_PATH/webrev.01 > > /Magnus > From tim.bell at oracle.com Fri Sep 18 16:31:03 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 18 Sep 2015 09:31:03 -0700 Subject: RFR: JDK-8136764 ORIGINAL_PATH is broken if PATH contains directory with "#" in it's name In-Reply-To: <55FC23FE.8090202@oracle.com> References: <55FC23FE.8090202@oracle.com> Message-ID: <55FC3C47.3010808@oracle.com> Hello Magnus: > If the PATH contains a directory with a # in it's name, we will store > ORIGINAL_PATH=...#... in spec.gmk. > > However, this will result in make cutting the line at #, believing the > rest to be a comment. > > Unfortunately, having directories named # is not so esoteric it at > first seems, since Microsoft Visual Studio typically adds it's F# > implementation to the PATH. :-( Too bad. > Bug: https://bugs.openjdk.java.net/browse/JDK-8136764 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8136764-escape-hash-in-ORIGINAL_PATH/webrev.01 Looks good to me. Hopefully the issue will stay fixed this time. The previous attempt was in JDK-8009315. Tim From erik.joelsson at oracle.com Fri Sep 18 16:41:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Sep 2015 09:41:25 -0700 Subject: [8u] Request for Approval and Review: JDK-8136691: 8u65/8u66 b14 Solaris builds failed on Linking libverify.so Message-ID: <55FC3EB5.2080905@oracle.com> Hello, Please approve and review this fix for 8u. There is a discrepancy between the Solaris and Linux makefiles for Hotspot, where a source file is excluded for a certain configuration on Linux but not on Solaris. This causes the build to fail on Solaris in that configuration. Bug: https://bugs.openjdk.java.net/browse/JDK-8136691 Patch: diff --git a/make/solaris/makefiles/trace.make b/make/solaris/makefiles/trace.make --- a/make/solaris/makefiles/trace.make +++ b/make/solaris/makefiles/trace.make @@ -56,8 +56,12 @@ ifeq ($(HAS_ALT_SRC), true) TraceGeneratedNames += \ traceRequestables.hpp \ - traceEventControl.hpp \ - traceProducer.cpp + traceEventControl.hpp + +ifneq ($(INCLUDE_TRACE), false) + TraceGeneratedNames += traceProducer.cpp +endif + endif TraceGeneratedFiles = $(TraceGeneratedNames:%=$(TraceOutDir)/%) /Erik From christian.thalinger at oracle.com Fri Sep 18 16:58:38 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Sep 2015 06:58:38 -1000 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com> Message-ID: <25D9D308-0FBA-47A6-A30D-D5A672AB1AE3@oracle.com> > On Sep 17, 2015, at 10:20 PM, Volker Simonis wrote: > > For the top-level change I always get a strange error when importing it: > > patch failed, unable to continue (try -v) > patch failed, rejects left in working dir > errors during apply, please fix and refresh 8062493_jvmci_top_0911.v1.patch > > It is because of the strange path syntax of the last hunk in the patch file: > > --- old/./modules.xml 2015-09-16 15:11:14.000000000 -0700 > +++ new/./modules.xml 2015-09-16 15:11:14.000000000 -0700 > @@ -254,6 +254,14 @@ > jdk.jfr > > > + jdk.internal.jvmci.hotspot > + jdk.jfr > + > + > + jdk.internal.jvmci.hotspot.events > + jdk.jfr > + > + > sun.misc > java.corba > java.desktop > > > Notice the strange syntax "old/./modules.xml" and "new/./modules.xml". > If I remove the redundant './' from the path, everything works fine. > For some reason only the diffs for modules.xml has this strange path > syntax in the patch. That?s odd. Vladimir created the webrevs. Maybe he did something different with the top-level one. > > Regards, > Volker > > > On Thu, Sep 17, 2015 at 10:32 PM, Christian Thalinger > wrote: >> Since there are no objections I?m going to push this? >> >> http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/6a6766a8cbbf >> >>> On Sep 16, 2015, at 3:05 PM, Christian Thalinger wrote: >>> >>> I would like to add this change: >>> >>> diff -r 2134e08cc132 src/share/vm/utilities/vmError.cpp >>> --- a/src/share/vm/utilities/vmError.cpp Wed Sep 16 14:28:33 2015 -1000 >>> +++ b/src/share/vm/utilities/vmError.cpp Wed Sep 16 15:04:02 2015 -1000 >>> @@ -517,6 +517,10 @@ void VMError::report(outputStream* st) { >>> Abstract_VM_Version::vm_release(), >>> Abstract_VM_Version::vm_info_string(), >>> TieredCompilation ? ", tiered" : "", >>> +#if INCLUDE_JVMCI >>> + EnableJVMCI ? ", jvmci" : "", >>> + UseJVMCICompiler ? ", jvmci compiler" : "", >>> +#endif >>> UseCompressedOops ? ", compressed oops" : "", >>> gc_mode(), >>> Abstract_VM_Version::vm_platform_string() >>> >>> It would be useful to see in the crash logs if this experimental feature was turned on. >>> >>>> On Sep 16, 2015, at 12:43 PM, Vladimir Kozlov wrote: >>>> >>>> I updated top and hotspot webrev with latest (build) changes. >>>> >>>> Vladimir >>>> >>>> On 9/16/15 2:28 PM, Christian Thalinger wrote: >>>>> >>>>>> On Sep 16, 2015, at 6:52 AM, Christian Thalinger wrote: >>>>>> >>>>>> >>>>>>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> On 2015-09-14 09:24, Christian Thalinger wrote: >>>>>>>> The JEP itself can be found here: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8062493 >>>>>>>> >>>>>>>> Here are the webrevs: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >>>>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >>>>>>>> >>>>>>>> The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134994 >>>>>>>> >>>>>>>> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. >>>>>>>> >>>>>>>> The integration will happen under the bug number: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8136421 >>>>>>>> >>>>>>> Hi Christian, >>>>>>> >>>>>>> (Adding build-dev since this review includes some major build changes.) >>>>>>> >>>>>>> The makefile changes looks good in general to me. I have not reviewed the source code changes. >>>>>>> >>>>>>> Some comments: >>>>>>> >>>>>>> * modules.xml: >>>>>>> Make sure you get sign-off from a Jigsaw developer for modifying this file. >>>>>> >>>>>> I?ve asked Alan to take a look. >>>>>> >>>>>>> >>>>>>> * hotspot/make/linux/makefiles/gcc.make: >>>>>>> Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? >>>>>> >>>>>> We had this question before. It?s not obvious because you can?t see it in the regular diff views but this is under: >>>>>> >>>>>> ifeq ($(USE_CLANG), true) >>>>>> >>>>>>> >>>>>>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: >>>>>>> I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. >>>>>> >>>>>> Thanks for the heads up. >>>>> >>>>> Erik sent me a patch to avoid merge conflicts. I?ve integrated two changesets: >>>>> >>>>> http://hg.openjdk.java.net/graal/graal-jvmci-9/rev/ddedccc5c0ab > >>>>> http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/fee6b89199c9 > >>>>> >>>>>> >>>>>>> >>>>>>> Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. >>>>>> >>>>>> Ok, thanks. >>>>>> >>>>>>> >>>>>>> /Magnus >>> >> From sean.coffey at oracle.com Fri Sep 18 16:59:00 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 18 Sep 2015 17:59:00 +0100 Subject: [8u] Request for Approval and Review: JDK-8136691: 8u65/8u66 b14 Solaris builds failed on Linking libverify.so In-Reply-To: <55FC3EB5.2080905@oracle.com> References: <55FC3EB5.2080905@oracle.com> Message-ID: <55FC42D4.3000703@oracle.com> Approved but subject to review. Please add the noreg-build label. Add the 9-na label if it's not applicable to JDK 9. If it is applicable to JDK 9, create a backport record so that it doesn't get overlooked. Regards, Sean. On 18/09/15 17:41, Erik Joelsson wrote: > Hello, > > Please approve and review this fix for 8u. There is a discrepancy > between the Solaris and Linux makefiles for Hotspot, where a source > file is excluded for a certain configuration on Linux but not on > Solaris. This causes the build to fail on Solaris in that configuration. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136691 > Patch: > diff --git a/make/solaris/makefiles/trace.make > b/make/solaris/makefiles/trace.make > --- a/make/solaris/makefiles/trace.make > +++ b/make/solaris/makefiles/trace.make > @@ -56,8 +56,12 @@ > ifeq ($(HAS_ALT_SRC), true) > TraceGeneratedNames += \ > traceRequestables.hpp \ > - traceEventControl.hpp \ > - traceProducer.cpp > + traceEventControl.hpp > + > +ifneq ($(INCLUDE_TRACE), false) > + TraceGeneratedNames += traceProducer.cpp > +endif > + > endif > > TraceGeneratedFiles = $(TraceGeneratedNames:%=$(TraceOutDir)/%) > > > /Erik From tim.bell at oracle.com Fri Sep 18 18:16:17 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 18 Sep 2015 11:16:17 -0700 Subject: [8u] Request for Approval and Review: JDK-8136691: 8u65/8u66 b14 Solaris builds failed on Linking libverify.so In-Reply-To: <55FC42D4.3000703@oracle.com> References: <55FC3EB5.2080905@oracle.com> <55FC42D4.3000703@oracle.com> Message-ID: <55FC54F1.6030901@oracle.com> Erik- The code review part looks good. Tim On 09/18/15 09:59, Se?n Coffey wrote: > Approved but subject to review. Please add the noreg-build label. Add > the 9-na label if it's not applicable to JDK 9. If it is applicable to > JDK 9, create a backport record so that it doesn't get overlooked. > > Regards, > Sean. > > On 18/09/15 17:41, Erik Joelsson wrote: >> Hello, >> >> Please approve and review this fix for 8u. There is a discrepancy >> between the Solaris and Linux makefiles for Hotspot, where a source >> file is excluded for a certain configuration on Linux but not on >> Solaris. This causes the build to fail on Solaris in that configuration. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8136691 >> Patch: >> diff --git a/make/solaris/makefiles/trace.make >> b/make/solaris/makefiles/trace.make >> --- a/make/solaris/makefiles/trace.make >> +++ b/make/solaris/makefiles/trace.make >> @@ -56,8 +56,12 @@ >> ifeq ($(HAS_ALT_SRC), true) >> TraceGeneratedNames += \ >> traceRequestables.hpp \ >> - traceEventControl.hpp \ >> - traceProducer.cpp >> + traceEventControl.hpp >> + >> +ifneq ($(INCLUDE_TRACE), false) >> + TraceGeneratedNames += traceProducer.cpp >> +endif >> + >> endif >> >> TraceGeneratedFiles = $(TraceGeneratedNames:%=$(TraceOutDir)/%) >> >> >> /Erik > From magnus.ihse.bursie at oracle.com Mon Sep 21 08:50:35 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Sep 2015 10:50:35 +0200 Subject: RFR: JDK-8136813 Log compare.sh output automatically to file Message-ID: <55FFC4DB.1090006@oracle.com> If we use the logger.sh wrapper, we can easily store the output of the compare.sh script to a file. Bug: https://bugs.openjdk.java.net/browse/JDK-8136813 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8136813-log-compare-script-to-file/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Mon Sep 21 12:19:10 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Sep 2015 14:19:10 +0200 Subject: RFR: JDK-8136385: Various build speed improvements for windows In-Reply-To: <55F9386A.20808@oracle.com> References: <55F2E945.6060400@oracle.com> <55F9386A.20808@oracle.com> Message-ID: <55FFF5BE.9030103@oracle.com> Inte f?r att stressa dig eller s?, men du gl?mmer inte bort den h?r va? Den ?r en prereq f?r att kunna f? in Tonga, och jag h?ller p? och knyter ihop Tonga-s?cken i ?vrigt. /Magnus On 2015-09-16 11:37, Magnus Ihse Bursie wrote: > On 2015-09-11 16:46, Erik Joelsson wrote: >> Hello, >> >> In the build-infra project, I have made various minor build speed >> improvements for Windows. These mostly affect incremental build >> performance, but in certain cases normal builds are also greatly >> affected. I find these worth committing to JDK 9 separately. >> >> List of improvements: >> >> * Rewrote DependOnVariable to use "-include" instead of $(shell >> $(CAT) ...) to read the old variable value from the last make >> invocation. This has a pretty big impact on incremental build >> performance on Windows. Also started using the file function in make >> when available (in make 4.0) instead of $(shell $(PRINTF) ...) when >> writing these files. >> >> * Implemented ListPathsSafely using the file function when available. >> Since we require make 4.0 in cygwin, this will usually be the case >> when it matters. >> >> * Reduced the number of shell execution in the compiler and link >> recipes by joining them together with "; \". When compiling a lot of >> native code, this tends to get quite expensive. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8136385 >> Webrev: http://cr.openjdk.java.net/~erikj/8136385/webrev.01/ > > As a general comment, I've experimented a bit with using .ONESHELL, > which will automatically concatenate separate lines in a recipe and > execute them by a single shell. When it works, it improves performance > significantly, especially in Windows. Having it enabled all over the > board would also let us avoid those "&& \" constructs. > > However, a lot of recipes needs to be updated to work properly with > .ONESHELL. Also, it was also introduced in GNU Make 3.82 so we would > need to bump our lowest supported platform number. Nevertheless, I > think it is the proper way forward, but it will take some time. So > changes such as this will be needed in the meantime. > > I have a few questions: > > In JavaCompilation.gmk, you replace $1_GREP_INCLUDE_OUTPUT := with > $1_GREP_INCLUDE_OUTPUT =. Any specific reason to drop the : or just a > typo? (And so also for $1_GREP_EXCLUDE_OUTPUT) > > The ListPathsSafely function is really horrible and hard to read. :-/ > (I'm not blaming you; the version using "file" is excellent). I have > a hard time figuring out that the legacy version (without "file") is > still correct. Maybe we should have a test for it? > > The indentation on DependOnVariableHelper looks weird. It might be the > patch but I'm not sure. > > In NativeCompilation, I'm trying to figure out how the "ifneq > ($$($1_$2_DEP),)" is supposed to work. This is old code and I wouldn't > have reacted to it if it were not for the fact that you removed this > checked for the microsoft toolchain path. As I can see, the $1_$2_DEP > variable will be empty for .s files. But if we're compiling .s files > in solstudio, we'll still end up calling "$$($1_$2_COMP) > $$($1_$2_FLAGS) $$($1_$2_DEP_FLAG) $$($1_$2_DEP) ...". How could that > possibly work? And what happens for the microsoft case with your > patch? Now we're going to do the "$(SED) > $(DEPENDENCY_TARGET_SED_PATTERN) $$($1_$2_DEP) > > $$($1_$2_DEP_TARGETS)" operation, which we previously didn't do. Do we > actually compile any .s files? I can't understand how that would work. > *checking* No, we don't. In the jdk project, there's just a single .s > file > (./jdk/src/java.desktop/unix/native/libawt/awt/medialib/mlib_v_ImageCopy_blk.s) > and it's excluded from compilation. On the other hand, there *are* .s > files in the Hotspot project which we will need to be able to handle > at some point. Urgh. Messy. You'll have to decide if you want to clean > this up. > > /Magnus > >> >> /Erik > From magnus.ihse.bursie at oracle.com Mon Sep 21 12:20:36 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Sep 2015 14:20:36 +0200 Subject: RFR: JDK-8136385: Various build speed improvements for windows In-Reply-To: <55FFF5BE.9030103@oracle.com> References: <55F2E945.6060400@oracle.com> <55F9386A.20808@oracle.com> <55FFF5BE.9030103@oracle.com> Message-ID: <55FFF614.1040603@oracle.com> On 2015-09-21 14:19, Magnus Ihse Bursie wrote: > Inte f?r att stressa dig eller s?, men du gl?mmer inte bort den h?r > va? Den ?r en prereq f?r att kunna f? in Tonga, och jag h?ller p? och > knyter ihop Tonga-s?cken i ?vrigt. I apologize for this. It was supposed to be a private message to Erik. /Magnus > > /Magnus > > On 2015-09-16 11:37, Magnus Ihse Bursie wrote: >> On 2015-09-11 16:46, Erik Joelsson wrote: >>> Hello, >>> >>> In the build-infra project, I have made various minor build speed >>> improvements for Windows. These mostly affect incremental build >>> performance, but in certain cases normal builds are also greatly >>> affected. I find these worth committing to JDK 9 separately. >>> >>> List of improvements: >>> >>> * Rewrote DependOnVariable to use "-include" instead of $(shell >>> $(CAT) ...) to read the old variable value from the last make >>> invocation. This has a pretty big impact on incremental build >>> performance on Windows. Also started using the file function in make >>> when available (in make 4.0) instead of $(shell $(PRINTF) ...) when >>> writing these files. >>> >>> * Implemented ListPathsSafely using the file function when >>> available. Since we require make 4.0 in cygwin, this will usually be >>> the case when it matters. >>> >>> * Reduced the number of shell execution in the compiler and link >>> recipes by joining them together with "; \". When compiling a lot of >>> native code, this tends to get quite expensive. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136385 >>> Webrev: http://cr.openjdk.java.net/~erikj/8136385/webrev.01/ >> >> As a general comment, I've experimented a bit with using .ONESHELL, >> which will automatically concatenate separate lines in a recipe and >> execute them by a single shell. When it works, it improves >> performance significantly, especially in Windows. Having it enabled >> all over the board would also let us avoid those "&& \" constructs. >> >> However, a lot of recipes needs to be updated to work properly with >> .ONESHELL. Also, it was also introduced in GNU Make 3.82 so we would >> need to bump our lowest supported platform number. Nevertheless, I >> think it is the proper way forward, but it will take some time. So >> changes such as this will be needed in the meantime. >> >> I have a few questions: >> >> In JavaCompilation.gmk, you replace $1_GREP_INCLUDE_OUTPUT := with >> $1_GREP_INCLUDE_OUTPUT =. Any specific reason to drop the : or just a >> typo? (And so also for $1_GREP_EXCLUDE_OUTPUT) >> >> The ListPathsSafely function is really horrible and hard to read. :-/ >> (I'm not blaming you; the version using "file" is excellent). I have >> a hard time figuring out that the legacy version (without "file") is >> still correct. Maybe we should have a test for it? >> >> The indentation on DependOnVariableHelper looks weird. It might be >> the patch but I'm not sure. >> >> In NativeCompilation, I'm trying to figure out how the "ifneq >> ($$($1_$2_DEP),)" is supposed to work. This is old code and I >> wouldn't have reacted to it if it were not for the fact that you >> removed this checked for the microsoft toolchain path. As I can see, >> the $1_$2_DEP variable will be empty for .s files. But if we're >> compiling .s files in solstudio, we'll still end up calling >> "$$($1_$2_COMP) $$($1_$2_FLAGS) $$($1_$2_DEP_FLAG) $$($1_$2_DEP) >> ...". How could that possibly work? And what happens for the >> microsoft case with your patch? Now we're going to do the "$(SED) >> $(DEPENDENCY_TARGET_SED_PATTERN) $$($1_$2_DEP) > >> $$($1_$2_DEP_TARGETS)" operation, which we previously didn't do. Do >> we actually compile any .s files? I can't understand how that would >> work. *checking* No, we don't. In the jdk project, there's just a >> single .s file >> (./jdk/src/java.desktop/unix/native/libawt/awt/medialib/mlib_v_ImageCopy_blk.s) >> and it's excluded from compilation. On the other hand, there *are* .s >> files in the Hotspot project which we will need to be able to handle >> at some point. Urgh. Messy. You'll have to decide if you want to >> clean this up. >> >> /Magnus >> >>> >>> /Erik >> > From erik.joelsson at oracle.com Mon Sep 21 15:52:26 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Sep 2015 08:52:26 -0700 Subject: RFR: JDK-8136813 Log compare.sh output automatically to file In-Reply-To: <55FFC4DB.1090006@oracle.com> References: <55FFC4DB.1090006@oracle.com> Message-ID: <560027BA.6030900@oracle.com> Looks good. /Erik On 2015-09-21 01:50, Magnus Ihse Bursie wrote: > If we use the logger.sh wrapper, we can easily store the output of the > compare.sh script to a file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136813 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8136813-log-compare-script-to-file/webrev.01 > > /Magnus From erik.joelsson at oracle.com Mon Sep 21 16:38:01 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Sep 2015 09:38:01 -0700 Subject: [8u] Request for Approval and Review: JDK-8136691: 8u65/8u66 b14 Solaris builds failed on Linking libverify.so In-Reply-To: <55FC54F1.6030901@oracle.com> References: <55FC3EB5.2080905@oracle.com> <55FC42D4.3000703@oracle.com> <55FC54F1.6030901@oracle.com> Message-ID: <56003269.3040707@oracle.com> Thanks Tim, Since this is Hotspot I assume I need another reviewer. Any chance I could get one? /Erik On 2015-09-18 11:16, Tim Bell wrote: > Erik- > > The code review part looks good. > > Tim > > On 09/18/15 09:59, Se?n Coffey wrote: >> Approved but subject to review. Please add the noreg-build label. Add >> the 9-na label if it's not applicable to JDK 9. If it is applicable >> to JDK 9, create a backport record so that it doesn't get overlooked. >> >> Regards, >> Sean. >> >> On 18/09/15 17:41, Erik Joelsson wrote: >>> Hello, >>> >>> Please approve and review this fix for 8u. There is a discrepancy >>> between the Solaris and Linux makefiles for Hotspot, where a source >>> file is excluded for a certain configuration on Linux but not on >>> Solaris. This causes the build to fail on Solaris in that >>> configuration. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136691 >>> Patch: >>> diff --git a/make/solaris/makefiles/trace.make >>> b/make/solaris/makefiles/trace.make >>> --- a/make/solaris/makefiles/trace.make >>> +++ b/make/solaris/makefiles/trace.make >>> @@ -56,8 +56,12 @@ >>> ifeq ($(HAS_ALT_SRC), true) >>> TraceGeneratedNames += \ >>> traceRequestables.hpp \ >>> - traceEventControl.hpp \ >>> - traceProducer.cpp >>> + traceEventControl.hpp >>> + >>> +ifneq ($(INCLUDE_TRACE), false) >>> + TraceGeneratedNames += traceProducer.cpp >>> +endif >>> + >>> endif >>> >>> TraceGeneratedFiles = $(TraceGeneratedNames:%=$(TraceOutDir)/%) >>> >>> >>> /Erik >> > From emailgane at yahoo.co.in Mon Sep 21 17:24:02 2015 From: emailgane at yahoo.co.in (Ganesh) Date: Mon, 21 Sep 2015 22:54:02 +0530 Subject: Make - No rule to make target Message-ID: <56003D32.5000607@yahoo.co.in> Hi I am trying to build OpenJDK 8 64 bit in Windows 2008 server. I am using Cygwin 64 bit and Visual studio 2010 professional. I am able to successfully configure but when i run make, i am getting the following error. make: *** No rule to make target `-', needed by `/cygdrive/c/work/openjdk/openjdk8/build/windows-x86_64-normal-server-release/spec.gmk'. Stop. I tried using make from Cygwin and also i downloaded make 3.8 source, compiled and used it. With the both the make files, i am getting the same error. Could some one how to continue the make? Regards Ganesh From erik.joelsson at oracle.com Mon Sep 21 17:30:48 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Sep 2015 10:30:48 -0700 Subject: Make - No rule to make target In-Reply-To: <56003D32.5000607@yahoo.co.in> References: <56003D32.5000607@yahoo.co.in> Message-ID: <56003EC8.1050801@oracle.com> Which forest did you clone? You probably want an 8u forest rather than 8. /Erik On 2015-09-21 10:24, Ganesh wrote: > Hi > > I am trying to build OpenJDK 8 64 bit in Windows 2008 server. I am > using Cygwin 64 bit and Visual studio 2010 professional. I am able to > successfully configure but when i run make, i am getting the following > error. > > make: *** No rule to make target `-', needed by > `/cygdrive/c/work/openjdk/openjdk8/build/windows-x86_64-normal-server-release/spec.gmk'. > Stop. > > I tried using make from Cygwin and also i downloaded make 3.8 source, > compiled and used it. With the both the make files, i am getting the > same error. Could some one how to continue the make? > > Regards > Ganesh From emailgane at yahoo.co.in Mon Sep 21 17:46:14 2015 From: emailgane at yahoo.co.in (Ganesh) Date: Mon, 21 Sep 2015 23:16:14 +0530 Subject: Make - No rule to make target In-Reply-To: <56003EC8.1050801@oracle.com> References: <56003D32.5000607@yahoo.co.in> <56003EC8.1050801@oracle.com> Message-ID: <56004266.9020802@yahoo.co.in> Thanks for the quick response. I used the below command. I guess it is 8. |hg clone http://hg.openjdk.java.net/jdk8/jdk8 /YourOpenJDK Regards Ganesh/| On 9/21/2015 11:00 PM, Erik Joelsson wrote: > Which forest did you clone? You probably want an 8u forest rather than 8. > > /Erik > > On 2015-09-21 10:24, Ganesh wrote: >> Hi >> >> I am trying to build OpenJDK 8 64 bit in Windows 2008 server. I am >> using Cygwin 64 bit and Visual studio 2010 professional. I am able to >> successfully configure but when i run make, i am getting the >> following error. >> >> make: *** No rule to make target `-', needed by >> `/cygdrive/c/work/openjdk/openjdk8/build/windows-x86_64-normal-server-release/spec.gmk'. >> Stop. >> >> I tried using make from Cygwin and also i downloaded make 3.8 source, >> compiled and used it. With the both the make files, i am getting the >> same error. Could some one how to continue the make? >> >> Regards >> Ganesh > > From emailgane at yahoo.co.in Mon Sep 21 18:50:24 2015 From: emailgane at yahoo.co.in (Ganesh) Date: Tue, 22 Sep 2015 00:20:24 +0530 Subject: OpenJDK build dependencies Message-ID: <56005170.5070800@yahoo.co.in> Do we require following dependencies to build OpenJDK 8 in Windows. The OpenJDK 8 build readme didn't mention about these dependecies but OpenJDK 7 requires these. Please confirm. I have installed complete Visual Studio 2010 professional. Windows 7 SDK Direct X 9 Apache Ant While building i am getting the below error. Could not start process! Failed with error 2: The system cannot find the file specified. make[2]: *** [/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.obj] Error 1 make[1]: *** [libs-only] Error 2 /cygdrive/c/work/openjdk/openjdk-8u//make/Main.gmk:115: recipe for target 'jdk-only' failed make: *** [jdk-only] Error 2 Regards Ganesh From mikael.vidstedt at oracle.com Mon Sep 21 19:38:22 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 21 Sep 2015 12:38:22 -0700 Subject: [8u] Request for Approval and Review: JDK-8136691: 8u65/8u66 b14 Solaris builds failed on Linking libverify.so In-Reply-To: <56003269.3040707@oracle.com> References: <55FC3EB5.2080905@oracle.com> <55FC42D4.3000703@oracle.com> <55FC54F1.6030901@oracle.com> <56003269.3040707@oracle.com> Message-ID: <56005CAE.5030902@oracle.com> Looks good! Cheers, Mikael On 2015-09-21 09:38, Erik Joelsson wrote: > Thanks Tim, > > Since this is Hotspot I assume I need another reviewer. Any chance I > could get one? > > /Erik > > On 2015-09-18 11:16, Tim Bell wrote: >> Erik- >> >> The code review part looks good. >> >> Tim >> >> On 09/18/15 09:59, Se?n Coffey wrote: >>> Approved but subject to review. Please add the noreg-build label. >>> Add the 9-na label if it's not applicable to JDK 9. If it is >>> applicable to JDK 9, create a backport record so that it doesn't get >>> overlooked. >>> >>> Regards, >>> Sean. >>> >>> On 18/09/15 17:41, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please approve and review this fix for 8u. There is a discrepancy >>>> between the Solaris and Linux makefiles for Hotspot, where a source >>>> file is excluded for a certain configuration on Linux but not on >>>> Solaris. This causes the build to fail on Solaris in that >>>> configuration. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136691 >>>> Patch: >>>> diff --git a/make/solaris/makefiles/trace.make >>>> b/make/solaris/makefiles/trace.make >>>> --- a/make/solaris/makefiles/trace.make >>>> +++ b/make/solaris/makefiles/trace.make >>>> @@ -56,8 +56,12 @@ >>>> ifeq ($(HAS_ALT_SRC), true) >>>> TraceGeneratedNames += \ >>>> traceRequestables.hpp \ >>>> - traceEventControl.hpp \ >>>> - traceProducer.cpp >>>> + traceEventControl.hpp >>>> + >>>> +ifneq ($(INCLUDE_TRACE), false) >>>> + TraceGeneratedNames += traceProducer.cpp >>>> +endif >>>> + >>>> endif >>>> >>>> TraceGeneratedFiles = $(TraceGeneratedNames:%=$(TraceOutDir)/%) >>>> >>>> >>>> /Erik >>> >> > From erik.joelsson at oracle.com Mon Sep 21 21:29:42 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Sep 2015 14:29:42 -0700 Subject: OpenJDK build dependencies In-Reply-To: <56005170.5070800@yahoo.co.in> References: <56005170.5070800@yahoo.co.in> Message-ID: <560076C6.80300@oracle.com> Hello, On 2015-09-21 11:50, Ganesh wrote: > > Do we require following dependencies to build OpenJDK 8 in Windows. > The OpenJDK 8 build readme didn't mention about these dependecies but > OpenJDK 7 requires these. Please confirm. I have installed complete > Visual Studio 2010 professional. > > Windows 7 SDK > Direct X 9 > Apache Ant > None of the above are needed for JDK 8. > While building i am getting the below error. > > Could not start process! Failed with error 2: The system cannot find > the file specified. > > make[2]: *** > [/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.obj] > Error 1 > make[1]: *** [libs-only] Error 2 > /cygdrive/c/work/openjdk/openjdk-8u//make/Main.gmk:115: recipe for > target 'jdk-only' failed > make: *** [jdk-only] Error 2 > Could you rerun with "make JOBS=1 LOG=debug" so we can see the failing command line? This looks like you are missing a tool in cygwin, but I can't be sure what. /Erik > > Regards > Ganesh From emailgane at yahoo.co.in Tue Sep 22 05:25:22 2015 From: emailgane at yahoo.co.in (Ganesh) Date: Tue, 22 Sep 2015 10:55:22 +0530 Subject: OpenJDK build dependencies In-Reply-To: <560076C6.80300@oracle.com> References: <56005170.5070800@yahoo.co.in> <560076C6.80300@oracle.com> Message-ID: <5600E642.7040700@yahoo.co.in> On 9/22/2015 2:59 AM, Erik Joelsson wrote: > Hello, > > On 2015-09-21 11:50, Ganesh wrote: >> >> Do we require following dependencies to build OpenJDK 8 in Windows. >> The OpenJDK 8 build readme didn't mention about these dependecies but >> OpenJDK 7 requires these. Please confirm. I have installed complete >> Visual Studio 2010 professional. >> >> Windows 7 SDK >> Direct X 9 >> Apache Ant >> > None of the above are needed for JDK 8. >> While building i am getting the below error. >> >> Could not start process! Failed with error 2: The system cannot find >> the file specified. >> >> make[2]: *** >> [/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.obj] >> Error 1 >> make[1]: *** [libs-only] Error 2 >> /cygdrive/c/work/openjdk/openjdk-8u//make/Main.gmk:115: recipe for >> target 'jdk-only' failed >> make: *** [jdk-only] Error 2 >> > Could you rerun with "make JOBS=1 LOG=debug" so we can see the failing > command line? This looks like you are missing a tool in cygwin, but I > can't be sure what. > > /Erik >> >> Regards >> Ganesh > No Luck.. I checked all the binaries like tee, grep, cat are available from Cygwin. Below is the error description.. /usr/bin/cp -fP '/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/share/lib/net.properties' '/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/lib/net.properties' (/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/fixpath.exe -c CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=time_macros /usr/bin/ccache /cygdrive/c/progra~2/micros~2.0/vc/bin/amd64/cl -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 -D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 -D_LITTLE_ENDIAN -DWINDOWS -DNDEBUG -DARCH='"amd64"' -Damd64 -DRELEASE='"1.8.0-internal"' -I/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/include -I/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/include/windows -I/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/share/javavm/export -I/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/windows/javavm/export -I/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/share/native/common -I/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/windows/native/common -I/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/gensrc_headers -I/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/share/native/java/lang/fdlibm/include -Od -DTHIS_FILE='"e_acos.c"' -c -showIncludes -Fd/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.pdb -Fm/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.map -Fo/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.obj /cygdrive/c/work/openjdk/openjdk-8u/jdk/src/share/native/java/lang/fdlibm/src/e_acos.c ; echo $? > /cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.d.exitvalue) | /usr/bin/tee /cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.d.raw | /usr/bin/grep -v "^Note: including file:" && exit `cat /cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.d.exitvalue` Could not start process! Failed with error 2: The system cannot find the file specified. make[2]: *** [/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.obj] Error 1 make[2]: Leaving directory `/cygdrive/c/work/openjdk/openjdk-8u/jdk/make' make[1]: *** [libs-only] Error 2 make[1]: Leaving directory `/cygdrive/c/work/openjdk/openjdk-8u/jdk/make' make: *** [jdk-only] Error 2 -Ganesh From volker.simonis at gmail.com Tue Sep 22 06:25:06 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Sep 2015 08:25:06 +0200 Subject: OpenJDK build dependencies In-Reply-To: <5600E642.7040700@yahoo.co.in> References: <56005170.5070800@yahoo.co.in> <560076C6.80300@oracle.com> <5600E642.7040700@yahoo.co.in> Message-ID: You are using ccache which is not supported under windows. Just disable ccache with --disable-ccache in your configure line (actually this should happen automatically under Windows) and everything should be fine :) Regards, Volker On Tue, Sep 22, 2015 at 7:25 AM, Ganesh wrote: > On 9/22/2015 2:59 AM, Erik Joelsson wrote: >> >> Hello, >> >> On 2015-09-21 11:50, Ganesh wrote: >>> >>> >>> Do we require following dependencies to build OpenJDK 8 in Windows. The >>> OpenJDK 8 build readme didn't mention about these dependecies but OpenJDK 7 >>> requires these. Please confirm. I have installed complete Visual Studio 2010 >>> professional. >>> >>> Windows 7 SDK >>> Direct X 9 >>> Apache Ant >>> >> None of the above are needed for JDK 8. >>> >>> While building i am getting the below error. >>> >>> Could not start process! Failed with error 2: The system cannot find the >>> file specified. >>> >>> make[2]: *** >>> [/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.obj] >>> Error 1 >>> make[1]: *** [libs-only] Error 2 >>> /cygdrive/c/work/openjdk/openjdk-8u//make/Main.gmk:115: recipe for target >>> 'jdk-only' failed >>> make: *** [jdk-only] Error 2 >>> >> Could you rerun with "make JOBS=1 LOG=debug" so we can see the failing >> command line? This looks like you are missing a tool in cygwin, but I can't >> be sure what. >> >> /Erik >>> >>> >>> Regards >>> Ganesh >> >> > No Luck.. I checked all the binaries like tee, grep, cat are available from > Cygwin. Below is the error description.. > > /usr/bin/cp -fP > '/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/share/lib/net.properties' > '/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/lib/net.properties' > (/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/fixpath.exe > -c CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=time_macros /usr/bin/ccache > /cygdrive/c/progra~2/micros~2.0/vc/bin/amd64/cl -nologo -Zi -MD -Zc:wchar_t- > -W3 -wd4800 -D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB > -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE > -DWIN32 -DIAL -D_AMD64_ -Damd64 -D_LITTLE_ENDIAN -DWINDOWS -DNDEBUG > -DARCH='"amd64"' -Damd64 -DRELEASE='"1.8.0-internal"' > -I/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/include > -I/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/include/windows > -I/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/share/javavm/export > -I/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/windows/javavm/export > -I/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/share/native/common > -I/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/windows/native/common > -I/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/gensrc_headers > -I/cygdrive/c/work/openjdk/openjdk-8u/jdk/src/share/native/java/lang/fdlibm/include > -Od -DTHIS_FILE='"e_acos.c"' -c -showIncludes > -Fd/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.pdb > -Fm/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.map > -Fo/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.obj > /cygdrive/c/work/openjdk/openjdk-8u/jdk/src/share/native/java/lang/fdlibm/src/e_acos.c > ; echo $? > > /cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.d.exitvalue) > | /usr/bin/tee > /cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.d.raw > | /usr/bin/grep -v "^Note: including file:" && exit `cat > /cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.d.exitvalue` > Could not start process! Failed with error 2: The system cannot find the > file specified. > > make[2]: *** > [/cygdrive/c/work/openjdk/openjdk-8u/build/windows-x86_64-normal-server-release/jdk/objs/libfdlibm/e_acos.obj] > Error 1 > make[2]: Leaving directory `/cygdrive/c/work/openjdk/openjdk-8u/jdk/make' > make[1]: *** [libs-only] Error 2 > make[1]: Leaving directory `/cygdrive/c/work/openjdk/openjdk-8u/jdk/make' > > make: *** [jdk-only] Error 2 > > -Ganesh > From magnus.ihse.bursie at oracle.com Wed Sep 23 12:30:34 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Sep 2015 14:30:34 +0200 Subject: RFR: JDK-8137014 Various improvements in build infrastructure Message-ID: <56029B6A.9040106@oracle.com> As a result of the recent work in the build-infra sandbox, here is a batch of improvements and fixes to the build-infra structure. Some of these are needed to support the conversion of the building of an Oracle internal test framework, while other are general improvements. A list of fixes included: * Fix for LogFailures which did not work if $1 had a / in it's name. * Improved vardeps handling in JavaCompilation. * Improved LOG=info logging from SetupNativeCompilation. * Add a COMP_DIR option to COMPARE_BUILD, to allow comparison of two specific subdirectories (and not only normal images). * Improved error reporting in case of incorrect usage of paths to SetupJavaCompilation and SetupNativeCompilation. * Improvements of the compare script for build result comparisions, including two new options --strip and --sort-symbols, which will strip all binaries before comparing, and sort all native symbols (per library) before comparing them, respectively. * Properly handle Java manifest files given by MANIFEST argument even with linebreak issues * In JavaCompilation, add KEEP_DUPS argument (Do not remove duplicate file names from different source roots). Bug: https://bugs.openjdk.java.net/browse/JDK-8137014 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8137014-build-infra-improvements/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Sep 23 13:16:34 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Sep 2015 15:16:34 +0200 Subject: RFR: JDK-8137013 ar (static linker) broken since JDK-8065912 Message-ID: (I'm resending this as it does not seem to have reached build-dev; I apologize it this is a dup.) Unfortunately JDK-8065912 broke ar, at least on solaris. In spec.gmk on posix platforms, we find AR_OUT_OPTION:=rcs$(SPACE) However, in JDK-8065912, the definition of SPACE moved from spec.gmk to MakeBase.gmk. But since spec.gmk typically is included ahead of MakeBase.gmk, SPACE will be undefined when AR_OUT_OPTION is evaluated. The short-term fix is to restore the definition of SPACE to spec.gmk. Bug: https://bugs.openjdk.java.net/browse/JDK-8137013 Patch inline: diff --git a/common/autoconf/spec.gmk.in b/common/autoconf/spec.gmk.in --- a/common/autoconf/spec.gmk.in +++ b/common/autoconf/spec.gmk.in @@ -36,6 +36,11 @@ # A self-referential reference to this file. SPEC:=@SPEC@ +# SPACE is defined in MakeBase.gmk, but it is also used in := rules here for some +# toolchains, and is needed if MakeBase.gmk is not included before this file. +X:= +SPACE:=$(X) $(X) + # What make to use for main processing, after bootstrapping top-level Makefile. MAKE := @MAKE@ /Magnus From Sergey.Bylokhov at oracle.com Wed Sep 23 13:34:35 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Sep 2015 16:34:35 +0300 Subject: [9] RFR 4763438: Replace uses of @beaninfo with meta facility in core j2se In-Reply-To: <55FDD620.8040704@oracle.com> References: <5412BA7B.6000006@oracle.com> <55FDD620.8040704@oracle.com> Message-ID: <5602AA6B.2020607@oracle.com> Can somebody from the build team review the changes in the make file? Thanks. > Please review an updated version of this fix: > http://cr.openjdk.java.net/~serb/4763438/webrev.00 > ccc request will be filed after the technical review. > > In this version > - The new make file is updated > - SimpleBeanInfo.java is updated to the current state of template bean. > - AbstractColorChooserPanel.java is updated to the current state. > > Note that additional cleanup of make folder for the bean area will be > done in JDK-7179078. > > Note that this fix is a part of JEP 256: BeanInfo Annotations. -- Best regards, Sergey. From philip.race at oracle.com Wed Sep 23 20:34:49 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 23 Sep 2015 13:34:49 -0700 Subject: [9] Review Request: 8079965 Stop ignoring warnings for libawt_lwawt In-Reply-To: <55F6D472.7000405@oracle.com> References: <55F6D472.7000405@oracle.com> Message-ID: <56030CE9.5010000@oracle.com> This looks OK except that I have a suggestion with regards to Apple's (gratuitous!) enum change OpenOffice solved this with an ifdef https://svn.apache.org/viewvc/openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx?r1=1591062&r2=1633297&pathrev=1633297 -- openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/04/29 19:25:03 1591062 +++ openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/10/21 07:43:39 1633297 @@ -76,8 +76,13 @@ { mpPrintInfo = [pShared copy]; [mpPrintInfo setPrinter: mpPrinter]; +#ifdef __MAC_10_9 // code for SDK 10.9 or newer + mePageOrientation = ([mpPrintInfo orientation] == NSPaperOrientationLandscape) ? ORIENTATION_LANDSCAPE : ORIENTATION_PORTRAIT; + [mpPrintInfo setOrientation: NSPaperOrientationPortrait]; +#else // code for SDK 10.8 or older mePageOrientation = ([mpPrintInfo orientation] == NSLandscapeOrientation) ? ORIENTATION_LANDSCAPE : ORIENTATION_PORTRAIT; [mpPrintInfo setOrientation: NSPortraitOrientation]; +#endif } Can we do the same ? -phil. On 09/14/2015 07:06 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > In the fix I remove WARNINGS_AS_ERRORS_clang option from the > libawt_lwawt library, and fix some of the issues: > > - jlong_md.h:69:9: warning: 'ptr_to_jlong' macro redefined. This is > because the "jni_util.h" and > "JavaNativeFoundation.framework/Headers/JNFJNI.h" both define this > macro. I cleared our headers to eliminate this warning. > > - PrinterView.m:207:21: warning: implicit conversion from enumeration > type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to different > enumeration type 'NSPrintingOrientation'. The problem is that the > Apple changed the returned type of [NSPrintInfo orientation] from > NSPrintingOrientation to NSPaperOrientation. Note that the > NSPaperOrientation is available since OSX 10.9, which means that this > change break the build on 10.8. Is it acceptable or should I suppress > this warning? [1] > > - CGraphicsDevice.m:336:41: warning: comparison between pointer and > integer ('void *' and 'jint' (aka 'int')) if ([screenID pointerValue] > == displayID). I have changed the type from pointerValue to > unsignedIntValue. > > Also I added "enum-conversion" to the DISABLED_WARNINGS_clang to > suppress some warnings to fix them later, because it should be > investigated how to fix it properly (ImageSurfaceData.m:1090:93: > warning: implicit conversion from enumeration type 'CGImageAlphaInfo' > (aka 'enum CGImageAlphaInfo') to different enumeration type > 'CGBitmapInfo') > > After the fix all new warnings will break the build. The currently > disabled warnings will be fixed as part of JDK-8074825 [2]. > > jprt build passed. > > [1] > https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/AppKit.html > [2] https://bugs.openjdk.java.net/browse/JDK-8074825 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079965 > Webrev: http://cr.openjdk.java.net/~serb/8079965/webrev.01 > From Sergey.Bylokhov at oracle.com Wed Sep 23 20:44:38 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Sep 2015 23:44:38 +0300 Subject: [9] Review Request: 8079965 Stop ignoring warnings for libawt_lwawt In-Reply-To: <56030CE9.5010000@oracle.com> References: <55F6D472.7000405@oracle.com> <56030CE9.5010000@oracle.com> Message-ID: <56030F36.7070007@oracle.com> Yes I can change the types in CPrinterJob [1] via ifdef, but actually do we support sdk 10.8 in jdk9? [1] http://cr.openjdk.java.net/~serb/8079965/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m.sdiff.html On 23.09.15 23:34, Phil Race wrote: > This looks OK except that I have a suggestion with regards to Apple's > (gratuitous!) enum change > OpenOffice solved this with an ifdef > > https://svn.apache.org/viewvc/openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx?r1=1591062&r2=1633297&pathrev=1633297 > > > -- openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/04/29 > 19:25:03 1591062 > +++ openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/10/21 > 07:43:39 1633297 > @@ -76,8 +76,13 @@ > { > mpPrintInfo = [pShared copy]; > [mpPrintInfo setPrinter: mpPrinter]; > +#ifdef __MAC_10_9 // code for SDK 10.9 or newer > + mePageOrientation = ([mpPrintInfo orientation] == > NSPaperOrientationLandscape) ? ORIENTATION_LANDSCAPE : > ORIENTATION_PORTRAIT; > + [mpPrintInfo setOrientation: NSPaperOrientationPortrait]; > +#else // code for SDK 10.8 or older > mePageOrientation = ([mpPrintInfo orientation] == > NSLandscapeOrientation) ? ORIENTATION_LANDSCAPE : ORIENTATION_PORTRAIT; > [mpPrintInfo setOrientation: NSPortraitOrientation]; > +#endif > } > > Can we do the same ? > > -phil. > > > > On 09/14/2015 07:06 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk9. >> >> In the fix I remove WARNINGS_AS_ERRORS_clang option from the >> libawt_lwawt library, and fix some of the issues: >> >> - jlong_md.h:69:9: warning: 'ptr_to_jlong' macro redefined. This is >> because the "jni_util.h" and >> "JavaNativeFoundation.framework/Headers/JNFJNI.h" both define this >> macro. I cleared our headers to eliminate this warning. >> >> - PrinterView.m:207:21: warning: implicit conversion from enumeration >> type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to different >> enumeration type 'NSPrintingOrientation'. The problem is that the >> Apple changed the returned type of [NSPrintInfo orientation] from >> NSPrintingOrientation to NSPaperOrientation. Note that the >> NSPaperOrientation is available since OSX 10.9, which means that this >> change break the build on 10.8. Is it acceptable or should I suppress >> this warning? [1] >> >> - CGraphicsDevice.m:336:41: warning: comparison between pointer and >> integer ('void *' and 'jint' (aka 'int')) if ([screenID pointerValue] >> == displayID). I have changed the type from pointerValue to >> unsignedIntValue. >> >> Also I added "enum-conversion" to the DISABLED_WARNINGS_clang to >> suppress some warnings to fix them later, because it should be >> investigated how to fix it properly (ImageSurfaceData.m:1090:93: >> warning: implicit conversion from enumeration type 'CGImageAlphaInfo' >> (aka 'enum CGImageAlphaInfo') to different enumeration type >> 'CGBitmapInfo') >> >> After the fix all new warnings will break the build. The currently >> disabled warnings will be fixed as part of JDK-8074825 [2]. >> >> jprt build passed. >> >> [1] >> https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/AppKit.html >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8074825 >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8079965 >> Webrev: http://cr.openjdk.java.net/~serb/8079965/webrev.01 >> > -- Best regards, Sergey. From philip.race at oracle.com Wed Sep 23 20:58:50 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 23 Sep 2015 13:58:50 -0700 Subject: [9] Review Request: 8079965 Stop ignoring warnings for libawt_lwawt In-Reply-To: <56030F36.7070007@oracle.com> References: <55F6D472.7000405@oracle.com> <56030CE9.5010000@oracle.com> <56030F36.7070007@oracle.com> Message-ID: <5603128A.3010706@oracle.com> IMO we should support building JDK on as many platforms as possible. Not just the RE-blessed platform of the day which can change more often than I can - or want to - update my systems as I need to build multiple releases. -phil. On 09/23/2015 01:44 PM, Sergey Bylokhov wrote: > Yes I can change the types in CPrinterJob [1] via ifdef, but actually > do we support sdk 10.8 in jdk9? > > [1] > http://cr.openjdk.java.net/~serb/8079965/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m.sdiff.html > > On 23.09.15 23:34, Phil Race wrote: >> This looks OK except that I have a suggestion with regards to Apple's >> (gratuitous!) enum change >> OpenOffice solved this with an ifdef >> >> https://svn.apache.org/viewvc/openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx?r1=1591062&r2=1633297&pathrev=1633297 >> >> >> >> -- openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/04/29 >> 19:25:03 1591062 >> +++ openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/10/21 >> 07:43:39 1633297 >> @@ -76,8 +76,13 @@ >> { >> mpPrintInfo = [pShared copy]; >> [mpPrintInfo setPrinter: mpPrinter]; >> +#ifdef __MAC_10_9 // code for SDK 10.9 or newer >> + mePageOrientation = ([mpPrintInfo orientation] == >> NSPaperOrientationLandscape) ? ORIENTATION_LANDSCAPE : >> ORIENTATION_PORTRAIT; >> + [mpPrintInfo setOrientation: NSPaperOrientationPortrait]; >> +#else // code for SDK 10.8 or older >> mePageOrientation = ([mpPrintInfo orientation] == >> NSLandscapeOrientation) ? ORIENTATION_LANDSCAPE : ORIENTATION_PORTRAIT; >> [mpPrintInfo setOrientation: NSPortraitOrientation]; >> +#endif >> } >> >> Can we do the same ? >> >> -phil. >> >> >> >> On 09/14/2015 07:06 AM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk9. >>> >>> In the fix I remove WARNINGS_AS_ERRORS_clang option from the >>> libawt_lwawt library, and fix some of the issues: >>> >>> - jlong_md.h:69:9: warning: 'ptr_to_jlong' macro redefined. This is >>> because the "jni_util.h" and >>> "JavaNativeFoundation.framework/Headers/JNFJNI.h" both define this >>> macro. I cleared our headers to eliminate this warning. >>> >>> - PrinterView.m:207:21: warning: implicit conversion from enumeration >>> type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to different >>> enumeration type 'NSPrintingOrientation'. The problem is that the >>> Apple changed the returned type of [NSPrintInfo orientation] from >>> NSPrintingOrientation to NSPaperOrientation. Note that the >>> NSPaperOrientation is available since OSX 10.9, which means that this >>> change break the build on 10.8. Is it acceptable or should I suppress >>> this warning? [1] >>> >>> - CGraphicsDevice.m:336:41: warning: comparison between pointer and >>> integer ('void *' and 'jint' (aka 'int')) if ([screenID pointerValue] >>> == displayID). I have changed the type from pointerValue to >>> unsignedIntValue. >>> >>> Also I added "enum-conversion" to the DISABLED_WARNINGS_clang to >>> suppress some warnings to fix them later, because it should be >>> investigated how to fix it properly (ImageSurfaceData.m:1090:93: >>> warning: implicit conversion from enumeration type 'CGImageAlphaInfo' >>> (aka 'enum CGImageAlphaInfo') to different enumeration type >>> 'CGBitmapInfo') >>> >>> After the fix all new warnings will break the build. The currently >>> disabled warnings will be fixed as part of JDK-8074825 [2]. >>> >>> jprt build passed. >>> >>> [1] >>> https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/AppKit.html >>> >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8074825 >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079965 >>> Webrev: http://cr.openjdk.java.net/~serb/8079965/webrev.01 >>> >> > > From erik.joelsson at oracle.com Thu Sep 24 08:19:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Sep 2015 10:19:53 +0200 Subject: RFR: JDK-8137013 ar (static linker) broken since JDK-8065912 In-Reply-To: References: Message-ID: <5603B229.5090509@oracle.com> Looks good to me. /Erik On 2015-09-23 15:16, Magnus Ihse Bursie wrote: > (I'm resending this as it does not seem to have reached build-dev; I apologize it this is a dup.) > > Unfortunately JDK-8065912 broke ar, at least on solaris. In spec.gmk on posix platforms, we find > AR_OUT_OPTION:=rcs$(SPACE) > > However, in JDK-8065912, the definition of SPACE moved from spec.gmk to MakeBase.gmk. But since spec.gmk typically is included ahead of MakeBase.gmk, SPACE will be undefined when AR_OUT_OPTION is evaluated. > > The short-term fix is to restore the definition of SPACE to spec.gmk. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137013 > Patch inline: > > diff --git a/common/autoconf/spec.gmk.in b/common/autoconf/spec.gmk.in > --- a/common/autoconf/spec.gmk.in > +++ b/common/autoconf/spec.gmk.in > @@ -36,6 +36,11 @@ > # A self-referential reference to this file. > SPEC:=@SPEC@ > > +# SPACE is defined in MakeBase.gmk, but it is also used in := rules here for some > +# toolchains, and is needed if MakeBase.gmk is not included before this file. > +X:= > +SPACE:=$(X) $(X) > + > # What make to use for main processing, after bootstrapping top-level Makefile. > MAKE := @MAKE@ > > /Magnus From erik.joelsson at oracle.com Thu Sep 24 08:41:03 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Sep 2015 10:41:03 +0200 Subject: [9] RFR 4763438: Replace uses of @beaninfo with meta facility in core j2se In-Reply-To: <5602AA6B.2020607@oracle.com> References: <5412BA7B.6000006@oracle.com> <55FDD620.8040704@oracle.com> <5602AA6B.2020607@oracle.com> Message-ID: <5603B71F.1050102@oracle.com> Nice to see that whole gensrc step has been eliminated! Build changes look good. /Erik On 2015-09-23 15:34, Sergey Bylokhov wrote: > Can somebody from the build team review the changes in the make file? > Thanks. > >> Please review an updated version of this fix: >> http://cr.openjdk.java.net/~serb/4763438/webrev.00 >> ccc request will be filed after the technical review. >> >> In this version >> - The new make file is updated >> - SimpleBeanInfo.java is updated to the current state of template >> bean. >> - AbstractColorChooserPanel.java is updated to the current state. >> >> Note that additional cleanup of make folder for the bean area will be >> done in JDK-7179078. >> >> Note that this fix is a part of JEP 256: BeanInfo Annotations. > From erik.joelsson at oracle.com Thu Sep 24 09:29:20 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Sep 2015 11:29:20 +0200 Subject: RFR: JDK-8137014 Various improvements in build infrastructure In-Reply-To: <56029B6A.9040106@oracle.com> References: <56029B6A.9040106@oracle.com> Message-ID: <5603C270.2060405@oracle.com> Looks good to me. /Erik On 2015-09-23 14:30, Magnus Ihse Bursie wrote: > As a result of the recent work in the build-infra sandbox, here is a > batch of improvements and fixes to the build-infra structure. Some of > these are needed to support the conversion of the building of an > Oracle internal test framework, while other are general improvements. > > A list of fixes included: > > * Fix for LogFailures which did not work if $1 had a / in it's name. > > * Improved vardeps handling in JavaCompilation. > > * Improved LOG=info logging from SetupNativeCompilation. > > * Add a COMP_DIR option to COMPARE_BUILD, to allow comparison of two > specific subdirectories (and not only normal images). > > * Improved error reporting in case of incorrect usage of paths to > SetupJavaCompilation and SetupNativeCompilation. > > * Improvements of the compare script for build result comparisions, > including two new options --strip and --sort-symbols, which > will strip all binaries before comparing, and sort all native symbols > (per library) before comparing them, respectively. > > * Properly handle Java manifest files given by MANIFEST argument even > with linebreak issues > > * In JavaCompilation, add KEEP_DUPS argument (Do not remove duplicate > file names from different source roots). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137014 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8137014-build-infra-improvements/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Thu Sep 24 12:31:43 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Sep 2015 14:31:43 +0200 Subject: RFR: JDK-8136385: Various build speed improvements for windows In-Reply-To: <55F9386A.20808@oracle.com> References: <55F2E945.6060400@oracle.com> <55F9386A.20808@oracle.com> Message-ID: <5603ED2F.4090504@oracle.com> On 2015-09-16 11:37, Magnus Ihse Bursie wrote: > On 2015-09-11 16:46, Erik Joelsson wrote: >> Hello, >> >> In the build-infra project, I have made various minor build speed >> improvements for Windows. These mostly affect incremental build >> performance, but in certain cases normal builds are also greatly >> affected. I find these worth committing to JDK 9 separately. >> >> List of improvements: >> >> * Rewrote DependOnVariable to use "-include" instead of $(shell >> $(CAT) ...) to read the old variable value from the last make >> invocation. This has a pretty big impact on incremental build >> performance on Windows. Also started using the file function in make >> when available (in make 4.0) instead of $(shell $(PRINTF) ...) when >> writing these files. >> >> * Implemented ListPathsSafely using the file function when available. >> Since we require make 4.0 in cygwin, this will usually be the case >> when it matters. >> >> * Reduced the number of shell execution in the compiler and link >> recipes by joining them together with "; \". When compiling a lot of >> native code, this tends to get quite expensive. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8136385 >> Webrev: http://cr.openjdk.java.net/~erikj/8136385/webrev.01/ > > As a general comment, I've experimented a bit with using .ONESHELL, > which will automatically concatenate separate lines in a recipe and > execute them by a single shell. When it works, it improves performance > significantly, especially in Windows. Having it enabled all over the > board would also let us avoid those "&& \" constructs. > > However, a lot of recipes needs to be updated to work properly with > .ONESHELL. Also, it was also introduced in GNU Make 3.82 so we would > need to bump our lowest supported platform number. Nevertheless, I > think it is the proper way forward, but it will take some time. So > changes such as this will be needed in the meantime. > I agree that .ONESHELL would be preferable. But as you said, 3.82 would require a bump in our required make version and at least the Ubuntu I'm using still has 3.81 as default. > I have a few questions: > > In JavaCompilation.gmk, you replace $1_GREP_INCLUDE_OUTPUT := with > $1_GREP_INCLUDE_OUTPUT =. Any specific reason to drop the : or just a > typo? (And so also for $1_GREP_EXCLUDE_OUTPUT) > That was indeed intentional. Note that GREP_EXCLUDE_OUTPUT was already declared using = so unifying is one reason. More importantly though, the old ListPathsSafely only generated command lines for use in a recipe, which made it safe to evaluate at declaration time. The new ListPathsSafely evalues the writing to file as a make function, and as such, we want to delay that evaluation until recipe execution time. > The ListPathsSafely function is really horrible and hard to read. :-/ > (I'm not blaming you; the version using "file" is excellent). I have > a hard time figuring out that the legacy version (without "file") is > still correct. Maybe we should have a test for it? > I agree it needs tests. On the other hand, the build would most likely fail if it wasn't accurate. I did contemplate writing a test, but it seems like a lot of work. > The indentation on DependOnVariableHelper looks weird. It might be the > patch but I'm not sure. > It was a bit weird. I had skipped indenting for the strip call. Fixed in new webrev. > In NativeCompilation, I'm trying to figure out how the "ifneq > ($$($1_$2_DEP),)" is supposed to work. This is old code and I wouldn't > have reacted to it if it were not for the fact that you removed this > checked for the microsoft toolchain path. As I can see, the $1_$2_DEP > variable will be empty for .s files. But if we're compiling .s files > in solstudio, we'll still end up calling "$$($1_$2_COMP) > $$($1_$2_FLAGS) $$($1_$2_DEP_FLAG) $$($1_$2_DEP) ...". How could that > possibly work? And what happens for the microsoft case with your > patch? Now we're going to do the "$(SED) > $(DEPENDENCY_TARGET_SED_PATTERN) $$($1_$2_DEP) > > $$($1_$2_DEP_TARGETS)" operation, which we previously didn't do. Do we > actually compile any .s files? I can't understand how that would work. > *checking* No, we don't. In the jdk project, there's just a single .s > file > (./jdk/src/java.desktop/unix/native/libawt/awt/medialib/mlib_v_ImageCopy_blk.s) > and it's excluded from compilation. On the other hand, there *are* .s > files in the Hotspot project which we will need to be able to handle > at some point. Urgh. Messy. You'll have to decide if you want to clean > this up. > I figured this would work since we don't have .s files on Windows. Looking closer it also seems like .s files would be broken for other platforms. Not an issue in current JDK 9 though so I won't try to fix it in this patch as I couldn't verify the fix anyway. New webrev: Also, I looked at the schedule for the JEP 243 integration and it won't hit the hotspot forests until October, so I think we should go ahead with this change to ListPathsSafely in jdk9-dev now. /Erik /Erik From erik.joelsson at oracle.com Thu Sep 24 12:34:15 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Sep 2015 14:34:15 +0200 Subject: RFR: JDK-8136385: Various build speed improvements for windows In-Reply-To: <5603ED2F.4090504@oracle.com> References: <55F2E945.6060400@oracle.com> <55F9386A.20808@oracle.com> <5603ED2F.4090504@oracle.com> Message-ID: <5603EDC7.6020803@oracle.com> New webrev link: http://cr.openjdk.java.net/~erikj/8136385/webrev.02/ On 2015-09-24 14:31, Erik Joelsson wrote: > > > On 2015-09-16 11:37, Magnus Ihse Bursie wrote: >> On 2015-09-11 16:46, Erik Joelsson wrote: >>> Hello, >>> >>> In the build-infra project, I have made various minor build speed >>> improvements for Windows. These mostly affect incremental build >>> performance, but in certain cases normal builds are also greatly >>> affected. I find these worth committing to JDK 9 separately. >>> >>> List of improvements: >>> >>> * Rewrote DependOnVariable to use "-include" instead of $(shell >>> $(CAT) ...) to read the old variable value from the last make >>> invocation. This has a pretty big impact on incremental build >>> performance on Windows. Also started using the file function in make >>> when available (in make 4.0) instead of $(shell $(PRINTF) ...) when >>> writing these files. >>> >>> * Implemented ListPathsSafely using the file function when >>> available. Since we require make 4.0 in cygwin, this will usually be >>> the case when it matters. >>> >>> * Reduced the number of shell execution in the compiler and link >>> recipes by joining them together with "; \". When compiling a lot of >>> native code, this tends to get quite expensive. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136385 >>> Webrev: http://cr.openjdk.java.net/~erikj/8136385/webrev.01/ >> >> As a general comment, I've experimented a bit with using .ONESHELL, >> which will automatically concatenate separate lines in a recipe and >> execute them by a single shell. When it works, it improves >> performance significantly, especially in Windows. Having it enabled >> all over the board would also let us avoid those "&& \" constructs. >> >> However, a lot of recipes needs to be updated to work properly with >> .ONESHELL. Also, it was also introduced in GNU Make 3.82 so we would >> need to bump our lowest supported platform number. Nevertheless, I >> think it is the proper way forward, but it will take some time. So >> changes such as this will be needed in the meantime. >> > I agree that .ONESHELL would be preferable. But as you said, 3.82 > would require a bump in our required make version and at least the > Ubuntu I'm using still has 3.81 as default. >> I have a few questions: >> >> In JavaCompilation.gmk, you replace $1_GREP_INCLUDE_OUTPUT := with >> $1_GREP_INCLUDE_OUTPUT =. Any specific reason to drop the : or just a >> typo? (And so also for $1_GREP_EXCLUDE_OUTPUT) >> > That was indeed intentional. Note that GREP_EXCLUDE_OUTPUT was already > declared using = so unifying is one reason. More importantly though, > the old ListPathsSafely only generated command lines for use in a > recipe, which made it safe to evaluate at declaration time. The new > ListPathsSafely evalues the writing to file as a make function, and as > such, we want to delay that evaluation until recipe execution time. >> The ListPathsSafely function is really horrible and hard to read. :-/ >> (I'm not blaming you; the version using "file" is excellent). I have >> a hard time figuring out that the legacy version (without "file") is >> still correct. Maybe we should have a test for it? >> > I agree it needs tests. On the other hand, the build would most likely > fail if it wasn't accurate. I did contemplate writing a test, but it > seems like a lot of work. >> The indentation on DependOnVariableHelper looks weird. It might be >> the patch but I'm not sure. >> > It was a bit weird. I had skipped indenting for the strip call. Fixed > in new webrev. >> In NativeCompilation, I'm trying to figure out how the "ifneq >> ($$($1_$2_DEP),)" is supposed to work. This is old code and I >> wouldn't have reacted to it if it were not for the fact that you >> removed this checked for the microsoft toolchain path. As I can see, >> the $1_$2_DEP variable will be empty for .s files. But if we're >> compiling .s files in solstudio, we'll still end up calling >> "$$($1_$2_COMP) $$($1_$2_FLAGS) $$($1_$2_DEP_FLAG) $$($1_$2_DEP) >> ...". How could that possibly work? And what happens for the >> microsoft case with your patch? Now we're going to do the "$(SED) >> $(DEPENDENCY_TARGET_SED_PATTERN) $$($1_$2_DEP) > >> $$($1_$2_DEP_TARGETS)" operation, which we previously didn't do. Do >> we actually compile any .s files? I can't understand how that would >> work. *checking* No, we don't. In the jdk project, there's just a >> single .s file >> (./jdk/src/java.desktop/unix/native/libawt/awt/medialib/mlib_v_ImageCopy_blk.s) >> and it's excluded from compilation. On the other hand, there *are* .s >> files in the Hotspot project which we will need to be able to handle >> at some point. Urgh. Messy. You'll have to decide if you want to >> clean this up. >> > I figured this would work since we don't have .s files on Windows. > Looking closer it also seems like .s files would be broken for other > platforms. Not an issue in current JDK 9 though so I won't try to fix > it in this patch as I couldn't verify the fix anyway. > > New webrev: > > Also, I looked at the schedule for the JEP 243 integration and it > won't hit the hotspot forests until October, so I think we should go > ahead with this change to ListPathsSafely in jdk9-dev now. > > /Erik > > /Erik From Sergey.Bylokhov at oracle.com Thu Sep 24 20:05:29 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 Sep 2015 23:05:29 +0300 Subject: [9] Review Request: 8079965 Stop ignoring warnings for libawt_lwawt In-Reply-To: <5603128A.3010706@oracle.com> References: <55F6D472.7000405@oracle.com> <56030CE9.5010000@oracle.com> <56030F36.7070007@oracle.com> <5603128A.3010706@oracle.com> Message-ID: <56045789.4060606@oracle.com> On 23.09.15 23:58, Phil Race wrote: > IMO we should support building JDK on as many platforms as possible. > Not just the RE-blessed platform of the day which can change more often > than I can - or want to - update my systems as I need to build multiple > releases. Then probably it will be better to disable this warning instead of changing the code? it should be safe. > > -phil. > > On 09/23/2015 01:44 PM, Sergey Bylokhov wrote: >> Yes I can change the types in CPrinterJob [1] via ifdef, but actually >> do we support sdk 10.8 in jdk9? >> >> [1] >> http://cr.openjdk.java.net/~serb/8079965/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m.sdiff.html >> >> >> On 23.09.15 23:34, Phil Race wrote: >>> This looks OK except that I have a suggestion with regards to Apple's >>> (gratuitous!) enum change >>> OpenOffice solved this with an ifdef >>> >>> https://svn.apache.org/viewvc/openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx?r1=1591062&r2=1633297&pathrev=1633297 >>> >>> >>> >>> -- openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/04/29 >>> 19:25:03 1591062 >>> +++ openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/10/21 >>> 07:43:39 1633297 >>> @@ -76,8 +76,13 @@ >>> { >>> mpPrintInfo = [pShared copy]; >>> [mpPrintInfo setPrinter: mpPrinter]; >>> +#ifdef __MAC_10_9 // code for SDK 10.9 or newer >>> + mePageOrientation = ([mpPrintInfo orientation] == >>> NSPaperOrientationLandscape) ? ORIENTATION_LANDSCAPE : >>> ORIENTATION_PORTRAIT; >>> + [mpPrintInfo setOrientation: NSPaperOrientationPortrait]; >>> +#else // code for SDK 10.8 or older >>> mePageOrientation = ([mpPrintInfo orientation] == >>> NSLandscapeOrientation) ? ORIENTATION_LANDSCAPE : ORIENTATION_PORTRAIT; >>> [mpPrintInfo setOrientation: NSPortraitOrientation]; >>> +#endif >>> } >>> >>> Can we do the same ? >>> >>> -phil. >>> >>> >>> >>> On 09/14/2015 07:06 AM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for jdk9. >>>> >>>> In the fix I remove WARNINGS_AS_ERRORS_clang option from the >>>> libawt_lwawt library, and fix some of the issues: >>>> >>>> - jlong_md.h:69:9: warning: 'ptr_to_jlong' macro redefined. This is >>>> because the "jni_util.h" and >>>> "JavaNativeFoundation.framework/Headers/JNFJNI.h" both define this >>>> macro. I cleared our headers to eliminate this warning. >>>> >>>> - PrinterView.m:207:21: warning: implicit conversion from enumeration >>>> type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to different >>>> enumeration type 'NSPrintingOrientation'. The problem is that the >>>> Apple changed the returned type of [NSPrintInfo orientation] from >>>> NSPrintingOrientation to NSPaperOrientation. Note that the >>>> NSPaperOrientation is available since OSX 10.9, which means that this >>>> change break the build on 10.8. Is it acceptable or should I suppress >>>> this warning? [1] >>>> >>>> - CGraphicsDevice.m:336:41: warning: comparison between pointer and >>>> integer ('void *' and 'jint' (aka 'int')) if ([screenID pointerValue] >>>> == displayID). I have changed the type from pointerValue to >>>> unsignedIntValue. >>>> >>>> Also I added "enum-conversion" to the DISABLED_WARNINGS_clang to >>>> suppress some warnings to fix them later, because it should be >>>> investigated how to fix it properly (ImageSurfaceData.m:1090:93: >>>> warning: implicit conversion from enumeration type 'CGImageAlphaInfo' >>>> (aka 'enum CGImageAlphaInfo') to different enumeration type >>>> 'CGBitmapInfo') >>>> >>>> After the fix all new warnings will break the build. The currently >>>> disabled warnings will be fixed as part of JDK-8074825 [2]. >>>> >>>> jprt build passed. >>>> >>>> [1] >>>> https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/AppKit.html >>>> >>>> >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8074825 >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079965 >>>> Webrev: http://cr.openjdk.java.net/~serb/8079965/webrev.01 >>>> >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Thu Sep 24 22:57:18 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 24 Sep 2015 15:57:18 -0700 Subject: [9] Review Request: 8079965 Stop ignoring warnings for libawt_lwawt In-Reply-To: <56045789.4060606@oracle.com> References: <55F6D472.7000405@oracle.com> <56030CE9.5010000@oracle.com> <56030F36.7070007@oracle.com> <5603128A.3010706@oracle.com> <56045789.4060606@oracle.com> Message-ID: <56047FCE.2020708@oracle.com> On 9/24/2015 1:05 PM, Sergey Bylokhov wrote: > On 23.09.15 23:58, Phil Race wrote: >> IMO we should support building JDK on as many platforms as possible. >> Not just the RE-blessed platform of the day which can change more often >> than I can - or want to - update my systems as I need to build multiple >> releases. > > Then probably it will be better to disable this warning instead of > changing the code? it should be safe. hmm.. some day 10.8 really will be uninteresting to all so I would put the code in place now with an ifdef. It is more to the point than disabling the warning. -phil. > >> >> -phil. >> >> On 09/23/2015 01:44 PM, Sergey Bylokhov wrote: >>> Yes I can change the types in CPrinterJob [1] via ifdef, but actually >>> do we support sdk 10.8 in jdk9? >>> >>> [1] >>> http://cr.openjdk.java.net/~serb/8079965/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m.sdiff.html >>> >>> >>> >>> On 23.09.15 23:34, Phil Race wrote: >>>> This looks OK except that I have a suggestion with regards to Apple's >>>> (gratuitous!) enum change >>>> OpenOffice solved this with an ifdef >>>> >>>> https://svn.apache.org/viewvc/openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx?r1=1591062&r2=1633297&pathrev=1633297 >>>> >>>> >>>> >>>> >>>> -- openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/04/29 >>>> 19:25:03 1591062 >>>> +++ openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/10/21 >>>> 07:43:39 1633297 >>>> @@ -76,8 +76,13 @@ >>>> { >>>> mpPrintInfo = [pShared copy]; >>>> [mpPrintInfo setPrinter: mpPrinter]; >>>> +#ifdef __MAC_10_9 // code for SDK 10.9 or newer >>>> + mePageOrientation = ([mpPrintInfo orientation] == >>>> NSPaperOrientationLandscape) ? ORIENTATION_LANDSCAPE : >>>> ORIENTATION_PORTRAIT; >>>> + [mpPrintInfo setOrientation: NSPaperOrientationPortrait]; >>>> +#else // code for SDK 10.8 or older >>>> mePageOrientation = ([mpPrintInfo orientation] == >>>> NSLandscapeOrientation) ? ORIENTATION_LANDSCAPE : >>>> ORIENTATION_PORTRAIT; >>>> [mpPrintInfo setOrientation: NSPortraitOrientation]; >>>> +#endif >>>> } >>>> >>>> Can we do the same ? >>>> >>>> -phil. >>>> >>>> >>>> >>>> On 09/14/2015 07:06 AM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review the fix for jdk9. >>>>> >>>>> In the fix I remove WARNINGS_AS_ERRORS_clang option from the >>>>> libawt_lwawt library, and fix some of the issues: >>>>> >>>>> - jlong_md.h:69:9: warning: 'ptr_to_jlong' macro redefined. This is >>>>> because the "jni_util.h" and >>>>> "JavaNativeFoundation.framework/Headers/JNFJNI.h" both define this >>>>> macro. I cleared our headers to eliminate this warning. >>>>> >>>>> - PrinterView.m:207:21: warning: implicit conversion from enumeration >>>>> type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to >>>>> different >>>>> enumeration type 'NSPrintingOrientation'. The problem is that the >>>>> Apple changed the returned type of [NSPrintInfo orientation] from >>>>> NSPrintingOrientation to NSPaperOrientation. Note that the >>>>> NSPaperOrientation is available since OSX 10.9, which means that this >>>>> change break the build on 10.8. Is it acceptable or should I suppress >>>>> this warning? [1] >>>>> >>>>> - CGraphicsDevice.m:336:41: warning: comparison between pointer and >>>>> integer ('void *' and 'jint' (aka 'int')) if ([screenID pointerValue] >>>>> == displayID). I have changed the type from pointerValue to >>>>> unsignedIntValue. >>>>> >>>>> Also I added "enum-conversion" to the DISABLED_WARNINGS_clang to >>>>> suppress some warnings to fix them later, because it should be >>>>> investigated how to fix it properly (ImageSurfaceData.m:1090:93: >>>>> warning: implicit conversion from enumeration type 'CGImageAlphaInfo' >>>>> (aka 'enum CGImageAlphaInfo') to different enumeration type >>>>> 'CGBitmapInfo') >>>>> >>>>> After the fix all new warnings will break the build. The currently >>>>> disabled warnings will be fixed as part of JDK-8074825 [2]. >>>>> >>>>> jprt build passed. >>>>> >>>>> [1] >>>>> https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/AppKit.html >>>>> >>>>> >>>>> >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8074825 >>>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079965 >>>>> Webrev: http://cr.openjdk.java.net/~serb/8079965/webrev.01 >>>>> >>>> >>> >>> >> > > From magnus.ihse.bursie at oracle.com Fri Sep 25 10:53:06 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Sep 2015 12:53:06 +0200 Subject: RFR: JDK-8136385: Various build speed improvements for windows In-Reply-To: <5603ED2F.4090504@oracle.com> References: <55F2E945.6060400@oracle.com> <55F9386A.20808@oracle.com> <5603ED2F.4090504@oracle.com> Message-ID: <56052792.6010503@oracle.com> On 2015-09-24 14:31, Erik Joelsson wrote: > > > On 2015-09-16 11:37, Magnus Ihse Bursie wrote: >> On 2015-09-11 16:46, Erik Joelsson wrote: >>> Hello, >>> >>> In the build-infra project, I have made various minor build speed >>> improvements for Windows. These mostly affect incremental build >>> performance, but in certain cases normal builds are also greatly >>> affected. I find these worth committing to JDK 9 separately. >>> >>> List of improvements: >>> >>> * Rewrote DependOnVariable to use "-include" instead of $(shell >>> $(CAT) ...) to read the old variable value from the last make >>> invocation. This has a pretty big impact on incremental build >>> performance on Windows. Also started using the file function in make >>> when available (in make 4.0) instead of $(shell $(PRINTF) ...) when >>> writing these files. >>> >>> * Implemented ListPathsSafely using the file function when >>> available. Since we require make 4.0 in cygwin, this will usually be >>> the case when it matters. >>> >>> * Reduced the number of shell execution in the compiler and link >>> recipes by joining them together with "; \". When compiling a lot of >>> native code, this tends to get quite expensive. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136385 >>> Webrev: http://cr.openjdk.java.net/~erikj/8136385/webrev.01/ >> >> As a general comment, I've experimented a bit with using .ONESHELL, >> which will automatically concatenate separate lines in a recipe and >> execute them by a single shell. When it works, it improves >> performance significantly, especially in Windows. Having it enabled >> all over the board would also let us avoid those "&& \" constructs. >> >> However, a lot of recipes needs to be updated to work properly with >> .ONESHELL. Also, it was also introduced in GNU Make 3.82 so we would >> need to bump our lowest supported platform number. Nevertheless, I >> think it is the proper way forward, but it will take some time. So >> changes such as this will be needed in the meantime. >> > I agree that .ONESHELL would be preferable. But as you said, 3.82 > would require a bump in our required make version and at least the > Ubuntu I'm using still has 3.81 as default. >> I have a few questions: >> >> In JavaCompilation.gmk, you replace $1_GREP_INCLUDE_OUTPUT := with >> $1_GREP_INCLUDE_OUTPUT =. Any specific reason to drop the : or just a >> typo? (And so also for $1_GREP_EXCLUDE_OUTPUT) >> > That was indeed intentional. Note that GREP_EXCLUDE_OUTPUT was already > declared using = so unifying is one reason. More importantly though, > the old ListPathsSafely only generated command lines for use in a > recipe, which made it safe to evaluate at declaration time. The new > ListPathsSafely evalues the writing to file as a make function, and as > such, we want to delay that evaluation until recipe execution time. Okay. >> The ListPathsSafely function is really horrible and hard to read. :-/ >> (I'm not blaming you; the version using "file" is excellent). I have >> a hard time figuring out that the legacy version (without "file") is >> still correct. Maybe we should have a test for it? >> > I agree it needs tests. On the other hand, the build would most likely > fail if it wasn't accurate. I did contemplate writing a test, but it > seems like a lot of work. It probably is, yes. I'll let you of the hook for this one, and maybe I'll add one as a follow-up exercise. :) >> The indentation on DependOnVariableHelper looks weird. It might be >> the patch but I'm not sure. >> > It was a bit weird. I had skipped indenting for the strip call. Fixed > in new webrev. Thanks! >> In NativeCompilation, I'm trying to figure out how the "ifneq >> ($$($1_$2_DEP),)" is supposed to work. This is old code and I >> wouldn't have reacted to it if it were not for the fact that you >> removed this checked for the microsoft toolchain path. As I can see, >> the $1_$2_DEP variable will be empty for .s files. But if we're >> compiling .s files in solstudio, we'll still end up calling >> "$$($1_$2_COMP) $$($1_$2_FLAGS) $$($1_$2_DEP_FLAG) $$($1_$2_DEP) >> ...". How could that possibly work? And what happens for the >> microsoft case with your patch? Now we're going to do the "$(SED) >> $(DEPENDENCY_TARGET_SED_PATTERN) $$($1_$2_DEP) > >> $$($1_$2_DEP_TARGETS)" operation, which we previously didn't do. Do >> we actually compile any .s files? I can't understand how that would >> work. *checking* No, we don't. In the jdk project, there's just a >> single .s file >> (./jdk/src/java.desktop/unix/native/libawt/awt/medialib/mlib_v_ImageCopy_blk.s) >> and it's excluded from compilation. On the other hand, there *are* .s >> files in the Hotspot project which we will need to be able to handle >> at some point. Urgh. Messy. You'll have to decide if you want to >> clean this up. >> > I figured this would work since we don't have .s files on Windows. > Looking closer it also seems like .s files would be broken for other > platforms. Not an issue in current JDK 9 though so I won't try to fix > it in this patch as I couldn't verify the fix anyway. Good point. > > New webrev: Looks good to me now. /Magnus > > Also, I looked at the schedule for the JEP 243 integration and it > won't hit the hotspot forests until October, so I think we should go > ahead with this change to ListPathsSafely in jdk9-dev now. > > /Erik > > /Erik From erik.joelsson at oracle.com Fri Sep 25 13:08:51 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 Sep 2015 15:08:51 +0200 Subject: RFR: JDK-8137088: Drop building of interim_java.corba Message-ID: <56054763.6070901@oracle.com> Hello, Please review this change to the build of JDK 9, which drops building of interim-corba. The interim build of java.corba has historically been needed for rmic -iiop but it is no longer needed in the build since the JMX remote API dropped support for the IIOP transport (JDK-8043937). Bug: https://bugs.openjdk.java.net/browse/JDK-8137088 Webrev: http://cr.openjdk.java.net/~erikj/8137088/webrev.01/ /Erik From Alan.Bateman at oracle.com Fri Sep 25 13:13:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Sep 2015 14:13:50 +0100 Subject: RFR: JDK-8137088: Drop building of interim_java.corba In-Reply-To: <56054763.6070901@oracle.com> References: <56054763.6070901@oracle.com> Message-ID: <5605488E.10800@oracle.com> On 25/09/2015 14:08, Erik Joelsson wrote: > Hello, > > Please review this change to the build of JDK 9, which drops building > of interim-corba. > > The interim build of java.corba has historically been needed for rmic > -iiop but it is no longer needed in the build since the JMX remote API > dropped support for the IIOP transport (JDK-8043937). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137088 > Webrev: http://cr.openjdk.java.net/~erikj/8137088/webrev.01/ Looks good to me, happy to see this go as it allows for clean-up in many areas. -Alan. From chris.hegarty at oracle.com Fri Sep 25 13:16:25 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 Sep 2015 14:16:25 +0100 Subject: RFR: JDK-8137088: Drop building of interim_java.corba In-Reply-To: <56054763.6070901@oracle.com> References: <56054763.6070901@oracle.com> Message-ID: <56054929.6000009@oracle.com> On 25/09/15 14:08, Erik Joelsson wrote: > Hello, > > Please review this change to the build of JDK 9, which drops building of > interim-corba. > > The interim build of java.corba has historically been needed for rmic > -iiop but it is no longer needed in the build since the JMX remote API > dropped support for the IIOP transport (JDK-8043937). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137088 > Webrev: http://cr.openjdk.java.net/~erikj/8137088/webrev.01/ Thanks for doing this Erik. We can now statically reference JDK 9 types from corba! -Chris. From magnus.ihse.bursie at oracle.com Fri Sep 25 14:28:22 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Sep 2015 16:28:22 +0200 Subject: RFR: JDK-8137088: Drop building of interim_java.corba In-Reply-To: <56054763.6070901@oracle.com> References: <56054763.6070901@oracle.com> Message-ID: <56055A06.30305@oracle.com> On 2015-09-25 15:08, Erik Joelsson wrote: > Hello, > > Please review this change to the build of JDK 9, which drops building > of interim-corba. > > The interim build of java.corba has historically been needed for rmic > -iiop but it is no longer needed in the build since the JMX remote API > dropped support for the IIOP transport (JDK-8043937). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137088 > Webrev: http://cr.openjdk.java.net/~erikj/8137088/webrev.01/ Looks good to me. Observant of you to note that we could remove this. /Magnus From timo.kinnunen at gmail.com Fri Sep 25 15:36:09 2015 From: timo.kinnunen at gmail.com (timo.kinnunen at gmail.com) Date: Fri, 25 Sep 2015 17:36:09 +0200 Subject: Building jdk9 on Windows x64 and Visual Studio 2015 Community edition Message-ID: <56056a50.a1a1c20a.2e0cf.417f@mx.google.com> Hi, I?ve been going over the Windows build of the whole JDK for a while with VS 2015 and now I have patches that allow the build to complete. I?ve made changes in the root repository as well as in hotspot and jdk repositories. The changes fall broadly in three categories: enabling the v140 toolchain and improving freetype compilation, adding casts to where pointers are truncated and miscellaneous small-scale code changes. The patch to the root repository streamlines handling of freetype by implementing a default source directory at $HOME/freetype under Cygwin. It is checked during configure and used for compiling if ?--with-freetype-src? is not specified. A help message giving the unpacking command with the correct directory is also included. This patch is about 90 lines without counting generated-configure.sh changes. The patches to jdk and hotspot contain native code changes only and no changes to make-files. These are about 580 and 290 lines, respectively. All patches are generated with ?hg diff -g?. Would you be willing to incorporate these? How should I proceed with this? Sent from Mail for Windows 10 From timo.kinnunen at gmail.com Fri Sep 25 15:55:19 2015 From: timo.kinnunen at gmail.com (timo.kinnunen at gmail.com) Date: Fri, 25 Sep 2015 17:55:19 +0200 Subject: Building jdk9 on Windows x64 and Visual Studio 2015 Community edition Message-ID: <56056e96.a558c20a.d796d.486a@mx.google.com> Hi, I?ve been going over the Windows build of the whole JDK for a while with VS 2015 and now I have patches that allow the build to complete. I?ve made changes in the root repository as well as in hotspot and jdk repositories. The changes fall broadly in three categories: enabling the v140 toolchain and improving freetype compilation, adding casts to where pointers are truncated and miscellaneous small-scale code changes. The patch to the root repository streamlines handling of freetype by implementing a default source directory at $HOME/freetype under Cygwin. It is checked during configure and used for compiling if ?--with-freetype-src? is not specified. A help message giving the unpacking command with the correct directory is also included. This patch is about 90 lines without counting generated-configure.sh changes. The patches to jdk and hotspot contain native code changes only and no changes to make-files. These are about 580 and 290 lines, respectively. All patches are generated with ?hg diff -g?. Would you be willing to incorporate these? How should I proceed with this? Sent from Mail for Windows 10 From Sergey.Bylokhov at oracle.com Fri Sep 25 17:07:51 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Sep 2015 20:07:51 +0300 Subject: [9] Review Request: 8079965 Stop ignoring warnings for libawt_lwawt In-Reply-To: <56047FCE.2020708@oracle.com> References: <55F6D472.7000405@oracle.com> <56030CE9.5010000@oracle.com> <56030F36.7070007@oracle.com> <5603128A.3010706@oracle.com> <56045789.4060606@oracle.com> <56047FCE.2020708@oracle.com> Message-ID: <56057F67.7060306@oracle.com> Hi, Phil. Here is an updated version: http://cr.openjdk.java.net/~serb/8079965/webrev.02 The CPrinterJob.m is changed only. jprt build passed. But I cannot verify osx 10.8, I have not it. On 25.09.15 1:57, Phil Race wrote: > On 9/24/2015 1:05 PM, Sergey Bylokhov wrote: >> On 23.09.15 23:58, Phil Race wrote: >>> IMO we should support building JDK on as many platforms as possible. >>> Not just the RE-blessed platform of the day which can change more often >>> than I can - or want to - update my systems as I need to build multiple >>> releases. >> >> Then probably it will be better to disable this warning instead of >> changing the code? it should be safe. > > > hmm.. some day 10.8 really will be uninteresting to all so I would put > the code in place now > with an ifdef. It is more to the point than disabling the warning. > > -phil. > >> >>> >>> -phil. >>> >>> On 09/23/2015 01:44 PM, Sergey Bylokhov wrote: >>>> Yes I can change the types in CPrinterJob [1] via ifdef, but actually >>>> do we support sdk 10.8 in jdk9? >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~serb/8079965/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m.sdiff.html >>>> >>>> >>>> >>>> On 23.09.15 23:34, Phil Race wrote: >>>>> This looks OK except that I have a suggestion with regards to Apple's >>>>> (gratuitous!) enum change >>>>> OpenOffice solved this with an ifdef >>>>> >>>>> https://svn.apache.org/viewvc/openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx?r1=1591062&r2=1633297&pathrev=1633297 >>>>> >>>>> >>>>> >>>>> >>>>> -- openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/04/29 >>>>> 19:25:03 1591062 >>>>> +++ openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/10/21 >>>>> 07:43:39 1633297 >>>>> @@ -76,8 +76,13 @@ >>>>> { >>>>> mpPrintInfo = [pShared copy]; >>>>> [mpPrintInfo setPrinter: mpPrinter]; >>>>> +#ifdef __MAC_10_9 // code for SDK 10.9 or newer >>>>> + mePageOrientation = ([mpPrintInfo orientation] == >>>>> NSPaperOrientationLandscape) ? ORIENTATION_LANDSCAPE : >>>>> ORIENTATION_PORTRAIT; >>>>> + [mpPrintInfo setOrientation: NSPaperOrientationPortrait]; >>>>> +#else // code for SDK 10.8 or older >>>>> mePageOrientation = ([mpPrintInfo orientation] == >>>>> NSLandscapeOrientation) ? ORIENTATION_LANDSCAPE : >>>>> ORIENTATION_PORTRAIT; >>>>> [mpPrintInfo setOrientation: NSPortraitOrientation]; >>>>> +#endif >>>>> } >>>>> >>>>> Can we do the same ? >>>>> >>>>> -phil. >>>>> >>>>> >>>>> >>>>> On 09/14/2015 07:06 AM, Sergey Bylokhov wrote: >>>>>> Hello. >>>>>> Please review the fix for jdk9. >>>>>> >>>>>> In the fix I remove WARNINGS_AS_ERRORS_clang option from the >>>>>> libawt_lwawt library, and fix some of the issues: >>>>>> >>>>>> - jlong_md.h:69:9: warning: 'ptr_to_jlong' macro redefined. This is >>>>>> because the "jni_util.h" and >>>>>> "JavaNativeFoundation.framework/Headers/JNFJNI.h" both define this >>>>>> macro. I cleared our headers to eliminate this warning. >>>>>> >>>>>> - PrinterView.m:207:21: warning: implicit conversion from enumeration >>>>>> type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to >>>>>> different >>>>>> enumeration type 'NSPrintingOrientation'. The problem is that the >>>>>> Apple changed the returned type of [NSPrintInfo orientation] from >>>>>> NSPrintingOrientation to NSPaperOrientation. Note that the >>>>>> NSPaperOrientation is available since OSX 10.9, which means that this >>>>>> change break the build on 10.8. Is it acceptable or should I suppress >>>>>> this warning? [1] >>>>>> >>>>>> - CGraphicsDevice.m:336:41: warning: comparison between pointer and >>>>>> integer ('void *' and 'jint' (aka 'int')) if ([screenID pointerValue] >>>>>> == displayID). I have changed the type from pointerValue to >>>>>> unsignedIntValue. >>>>>> >>>>>> Also I added "enum-conversion" to the DISABLED_WARNINGS_clang to >>>>>> suppress some warnings to fix them later, because it should be >>>>>> investigated how to fix it properly (ImageSurfaceData.m:1090:93: >>>>>> warning: implicit conversion from enumeration type 'CGImageAlphaInfo' >>>>>> (aka 'enum CGImageAlphaInfo') to different enumeration type >>>>>> 'CGBitmapInfo') >>>>>> >>>>>> After the fix all new warnings will break the build. The currently >>>>>> disabled warnings will be fixed as part of JDK-8074825 [2]. >>>>>> >>>>>> jprt build passed. >>>>>> >>>>>> [1] >>>>>> https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/AppKit.html >>>>>> >>>>>> >>>>>> >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8074825 >>>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079965 >>>>>> Webrev: http://cr.openjdk.java.net/~serb/8079965/webrev.01 >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Fri Sep 25 17:09:25 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 Sep 2015 10:09:25 -0700 Subject: [9] Review Request: 8079965 Stop ignoring warnings for libawt_lwawt In-Reply-To: <56057F67.7060306@oracle.com> References: <55F6D472.7000405@oracle.com> <56030CE9.5010000@oracle.com> <56030F36.7070007@oracle.com> <5603128A.3010706@oracle.com> <56045789.4060606@oracle.com> <56047FCE.2020708@oracle.com> <56057F67.7060306@oracle.com> Message-ID: <56057FC5.2010804@oracle.com> Approved. -phil. On 09/25/2015 10:07 AM, Sergey Bylokhov wrote: > Hi, Phil. > Here is an updated version: > http://cr.openjdk.java.net/~serb/8079965/webrev.02 > > The CPrinterJob.m is changed only. jprt build passed. But I cannot > verify osx 10.8, I have not it. > > On 25.09.15 1:57, Phil Race wrote: >> On 9/24/2015 1:05 PM, Sergey Bylokhov wrote: >>> On 23.09.15 23:58, Phil Race wrote: >>>> IMO we should support building JDK on as many platforms as possible. >>>> Not just the RE-blessed platform of the day which can change more >>>> often >>>> than I can - or want to - update my systems as I need to build >>>> multiple >>>> releases. >>> >>> Then probably it will be better to disable this warning instead of >>> changing the code? it should be safe. >> >> >> hmm.. some day 10.8 really will be uninteresting to all so I would put >> the code in place now >> with an ifdef. It is more to the point than disabling the warning. >> >> -phil. >> >>> >>>> >>>> -phil. >>>> >>>> On 09/23/2015 01:44 PM, Sergey Bylokhov wrote: >>>>> Yes I can change the types in CPrinterJob [1] via ifdef, but actually >>>>> do we support sdk 10.8 in jdk9? >>>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~serb/8079965/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m.sdiff.html >>>>> >>>>> >>>>> >>>>> >>>>> On 23.09.15 23:34, Phil Race wrote: >>>>>> This looks OK except that I have a suggestion with regards to >>>>>> Apple's >>>>>> (gratuitous!) enum change >>>>>> OpenOffice solved this with an ifdef >>>>>> >>>>>> https://svn.apache.org/viewvc/openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx?r1=1591062&r2=1633297&pathrev=1633297 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/04/29 >>>>>> 19:25:03 1591062 >>>>>> +++ openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx 2014/10/21 >>>>>> 07:43:39 1633297 >>>>>> @@ -76,8 +76,13 @@ >>>>>> { >>>>>> mpPrintInfo = [pShared copy]; >>>>>> [mpPrintInfo setPrinter: mpPrinter]; >>>>>> +#ifdef __MAC_10_9 // code for SDK 10.9 or newer >>>>>> + mePageOrientation = ([mpPrintInfo orientation] == >>>>>> NSPaperOrientationLandscape) ? ORIENTATION_LANDSCAPE : >>>>>> ORIENTATION_PORTRAIT; >>>>>> + [mpPrintInfo setOrientation: NSPaperOrientationPortrait]; >>>>>> +#else // code for SDK 10.8 or older >>>>>> mePageOrientation = ([mpPrintInfo orientation] == >>>>>> NSLandscapeOrientation) ? ORIENTATION_LANDSCAPE : >>>>>> ORIENTATION_PORTRAIT; >>>>>> [mpPrintInfo setOrientation: NSPortraitOrientation]; >>>>>> +#endif >>>>>> } >>>>>> >>>>>> Can we do the same ? >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> >>>>>> On 09/14/2015 07:06 AM, Sergey Bylokhov wrote: >>>>>>> Hello. >>>>>>> Please review the fix for jdk9. >>>>>>> >>>>>>> In the fix I remove WARNINGS_AS_ERRORS_clang option from the >>>>>>> libawt_lwawt library, and fix some of the issues: >>>>>>> >>>>>>> - jlong_md.h:69:9: warning: 'ptr_to_jlong' macro redefined. This is >>>>>>> because the "jni_util.h" and >>>>>>> "JavaNativeFoundation.framework/Headers/JNFJNI.h" both define this >>>>>>> macro. I cleared our headers to eliminate this warning. >>>>>>> >>>>>>> - PrinterView.m:207:21: warning: implicit conversion from >>>>>>> enumeration >>>>>>> type 'NSPaperOrientation' (aka 'enum NSPaperOrientation') to >>>>>>> different >>>>>>> enumeration type 'NSPrintingOrientation'. The problem is that the >>>>>>> Apple changed the returned type of [NSPrintInfo orientation] from >>>>>>> NSPrintingOrientation to NSPaperOrientation. Note that the >>>>>>> NSPaperOrientation is available since OSX 10.9, which means that >>>>>>> this >>>>>>> change break the build on 10.8. Is it acceptable or should I >>>>>>> suppress >>>>>>> this warning? [1] >>>>>>> >>>>>>> - CGraphicsDevice.m:336:41: warning: comparison between pointer and >>>>>>> integer ('void *' and 'jint' (aka 'int')) if ([screenID >>>>>>> pointerValue] >>>>>>> == displayID). I have changed the type from pointerValue to >>>>>>> unsignedIntValue. >>>>>>> >>>>>>> Also I added "enum-conversion" to the DISABLED_WARNINGS_clang to >>>>>>> suppress some warnings to fix them later, because it should be >>>>>>> investigated how to fix it properly (ImageSurfaceData.m:1090:93: >>>>>>> warning: implicit conversion from enumeration type >>>>>>> 'CGImageAlphaInfo' >>>>>>> (aka 'enum CGImageAlphaInfo') to different enumeration type >>>>>>> 'CGBitmapInfo') >>>>>>> >>>>>>> After the fix all new warnings will break the build. The currently >>>>>>> disabled warnings will be fixed as part of JDK-8074825 [2]. >>>>>>> >>>>>>> jprt build passed. >>>>>>> >>>>>>> [1] >>>>>>> https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/AppKit.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8074825 >>>>>>> >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079965 >>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8079965/webrev.01 >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From magnus.ihse.bursie at oracle.com Mon Sep 28 12:43:27 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 28 Sep 2015 14:43:27 +0200 Subject: RFR: JDK-8137259 configure needs to parse Verona-style version strings for bootjdk Message-ID: <560935EF.30808@oracle.com> Normally, the JDK should be built by a JDK from previous version (e.g. JDK8 for JDK9). However, building with JDK9 on JDK9 is (somewhat) supported. A JDK9 bootjdk with the new Verona-style version string will currently not be recognized by configure. This fix will be pushed to verona/stage. Bug: https://bugs.openjdk.java.net/browse/JDK-8137259 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8137259-support-verona-style-bootjdk/webrev.01 /Magnus From erik.joelsson at oracle.com Mon Sep 28 13:09:03 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Sep 2015 15:09:03 +0200 Subject: RFR: JDK-8137259 configure needs to parse Verona-style version strings for bootjdk In-Reply-To: <560935EF.30808@oracle.com> References: <560935EF.30808@oracle.com> Message-ID: <56093BEF.4090101@oracle.com> Looks good. /Erik On 2015-09-28 14:43, Magnus Ihse Bursie wrote: > Normally, the JDK should be built by a JDK from previous version (e.g. > JDK8 for JDK9). However, building with JDK9 on JDK9 is (somewhat) > supported. > > A JDK9 bootjdk with the new Verona-style version string will currently > not be recognized by configure. > > This fix will be pushed to verona/stage. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137259 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8137259-support-verona-style-bootjdk/webrev.01 > > /Magnus > From iris.clark at oracle.com Mon Sep 28 17:06:57 2015 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 28 Sep 2015 10:06:57 -0700 (PDT) Subject: RFR: JDK-8137259 configure needs to parse Verona-style version strings for bootjdk In-Reply-To: <560935EF.30808@oracle.com> References: <560935EF.30808@oracle.com> Message-ID: Hi, Magnus. Thanks for taking care of this. The modified regular expression looks like it will handle Verona builds now. Regards, iris -----Original Message----- From: Magnus Ihse Bursie Sent: Monday, September 28, 2015 5:43 AM To: build-dev at openjdk.java.net Cc: jdk9-versioning_ww_grp Subject: RFR: JDK-8137259 configure needs to parse Verona-style version strings for bootjdk Normally, the JDK should be built by a JDK from previous version (e.g. JDK8 for JDK9). However, building with JDK9 on JDK9 is (somewhat) supported. A JDK9 bootjdk with the new Verona-style version string will currently not be recognized by configure. This fix will be pushed to verona/stage. Bug: https://bugs.openjdk.java.net/browse/JDK-8137259 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8137259-support-verona-style-bootjdk/webrev.01 /Magnus From philip.race at oracle.com Tue Sep 29 17:13:14 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Sep 2015 10:13:14 -0700 Subject: RFR(xxs): [windows] Build broken on VS2010 after "8046148: JEP 158: Unified JVM Logging" In-Reply-To: References: <560A9F58.2080309@oracle.com> Message-ID: <560AC6AA.2090409@oracle.com> Because lots of people do not yet have VS2013. The official compilers are not the only ones we should support. They are just the ones RE uses. I would call this a "must fix". -phil. On 09/29/2015 08:12 AM, Thomas St?fe wrote: > Ok, I did not check this. Nevermind, then. > > Kind Regards, Thomas > > On Tue, Sep 29, 2015 at 4:25 PM, Daniel D. Daugherty < > daniel.daugherty at oracle.com> wrote: > >> Ummm... VS2013 is the official compiler for JDK9 and Win*. >> Why would we want to make a change to permit VS2010 to >> continue to be used? >> >> Dan >> >> >> On 9/29/15 7:58 AM, Thomas St?fe wrote: >> >>> Hi all, >>> >>> please review this tiny change. It fixes the build on windows/Visual >>> Studio >>> 2010 after "8046148: JEP 158: Unified JVM Logging". >>> >>> strtoull() is missing from Visual Studio versions < 2013, but _strtoui64() >>> can be used instead. >>> >>> webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.00/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8137329 >>> >>> Thanks & Kind Regards, Thomas >>> >> From magnus.ihse.bursie at oracle.com Wed Sep 30 09:07:40 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Sep 2015 11:07:40 +0200 Subject: RFR: JDK-8138627 Better help message in configure for reduced builds (target-bits=32) Message-ID: <560BA65C.7030202@oracle.com> When building reduced builds on Ubuntu, gcc-multilib and g++-multilib needs to be installed. Inform the user about this if the build fails. Bug: https://bugs.openjdk.java.net/browse/JDK-8138627 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8138627-configure-help-for-reduced-build/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Sep 30 09:17:21 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Sep 2015 11:17:21 +0200 Subject: RFR: JDK-8138627 Better help message in configure for reduced builds (target-bits=32) In-Reply-To: <560BA65C.7030202@oracle.com> References: <560BA65C.7030202@oracle.com> Message-ID: <560BA8A1.9000409@oracle.com> Looks good. /Erik On 2015-09-30 11:07, Magnus Ihse Bursie wrote: > When building reduced builds on Ubuntu, gcc-multilib and g++-multilib > needs to be installed. Inform the user about this if the build fails. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138627 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8138627-configure-help-for-reduced-build/webrev.01 > > /Magnus From erik.joelsson at oracle.com Wed Sep 30 12:43:44 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Sep 2015 14:43:44 +0200 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing Message-ID: <560BD900.9000308@oracle.com> Hello, Please approve and review this fix for 8u. My last fix for this issue, JDK-8136691, was not enough. I made a mistake while verifying the fix and the problem is still there. There are more discrepancies between Solaris and the other platform makefiles. The excludeSrc.gmk file is not included anywhere when building on Solaris. The variable Src_Files_EXCLUDE is overwritten in vm.make instead of appended to, so even when including excludeSrc.gmk, it wasn't enough. The other platform specific buildtree.make files also set INCLUDE_TRACE in the generated makefile. Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ /Erik From magnus.ihse.bursie at oracle.com Wed Sep 30 13:30:38 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Sep 2015 15:30:38 +0200 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <560BD900.9000308@oracle.com> References: <560BD900.9000308@oracle.com> Message-ID: <560BE3FE.7060103@oracle.com> On 2015-09-30 14:43, Erik Joelsson wrote: > Hello, > > Please approve and review this fix for 8u. > > My last fix for this issue, JDK-8136691, was not enough. I made a > mistake while verifying the fix and the problem is still there. > > There are more discrepancies between Solaris and the other platform > makefiles. The excludeSrc.gmk file is not included anywhere when > building on Solaris. The variable Src_Files_EXCLUDE is overwritten in > vm.make instead of appended to, so even when including excludeSrc.gmk, > it wasn't enough. The other platform specific buildtree.make files > also set INCLUDE_TRACE in the generated makefile. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 > Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ > > /Erik Looks good to me. /Magnus From rob.mckenna at oracle.com Wed Sep 30 13:40:25 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 30 Sep 2015 14:40:25 +0100 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <560BE3FE.7060103@oracle.com> References: <560BD900.9000308@oracle.com> <560BE3FE.7060103@oracle.com> Message-ID: <560BE649.7080904@oracle.com> Approved. -Rob On 30/09/15 14:30, Magnus Ihse Bursie wrote: > On 2015-09-30 14:43, Erik Joelsson wrote: >> Hello, >> >> Please approve and review this fix for 8u. >> >> My last fix for this issue, JDK-8136691, was not enough. I made a >> mistake while verifying the fix and the problem is still there. >> >> There are more discrepancies between Solaris and the other platform >> makefiles. The excludeSrc.gmk file is not included anywhere when >> building on Solaris. The variable Src_Files_EXCLUDE is overwritten in >> vm.make instead of appended to, so even when including excludeSrc.gmk, >> it wasn't enough. The other platform specific buildtree.make files >> also set INCLUDE_TRACE in the generated makefile. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 >> Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ >> >> /Erik > > Looks good to me. > > /Magnus From erik.joelsson at oracle.com Wed Sep 30 14:58:07 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Sep 2015 16:58:07 +0200 Subject: RFR: JDK-8138636: bootcycle-images build fails Message-ID: <560BF87F.7080001@oracle.com> Please review this small fix for the bootcycle-build, which broke when I removed the interim-corba build. In JDK 9 then we have moved module java.corba to the extension class loader. So if code on the boot class path has a reference to types in the java.corba module then it will fail with NoClassDefFoundError. This currently happens since we add the interim rmic classes to the bootclasspath, but no longer the interim-corba classes. The fix is to not set -Xbootclasspath/p at all. It was never needed and I just did it that way originally by trying to match existing patterns. I have verified that the bug which prompted the introduction of interim-rmic is still fixed when running without -Xbootclasspath/p. Bug: https://bugs.openjdk.java.net/browse/JDK-8138636 Patch inline: diff -r 14faed4d6a50 make/rmic/RmicCommon.gmk --- a/make/rmic/RmicCommon.gmk +++ b/make/rmic/RmicCommon.gmk @@ -33,7 +33,7 @@ BTRMIC_CP := $(call PathList, \ $(BUILDTOOLS_OUTPUTDIR)/interim_rmic_classes $(INTERIM_LANGTOOLS_JAR)) -BTRMIC_ARGS := -Xbootclasspath/p:$(BTRMIC_CP) -cp $(BTRMIC_CP) +BTRMIC_ARGS := -cp $(BTRMIC_CP) RMIC := $(JAVA) $(BTRMIC_ARGS) sun.rmi.rmic.Main CLASSES_DIR := $(JDK_OUTPUTDIR)/modules /Erik From Alan.Bateman at oracle.com Wed Sep 30 15:32:51 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Sep 2015 16:32:51 +0100 Subject: RFR: JDK-8138636: bootcycle-images build fails In-Reply-To: <560BF87F.7080001@oracle.com> References: <560BF87F.7080001@oracle.com> Message-ID: <560C00A3.3080209@oracle.com> On 30/09/2015 15:58, Erik Joelsson wrote: > Please review this small fix for the bootcycle-build, which broke when > I removed the interim-corba build. > > In JDK 9 then we have moved module java.corba to the extension class > loader. So if code on the boot class path has a reference to types in > the java.corba module then it will fail with NoClassDefFoundError. > This currently happens since we add the interim rmic classes to the > bootclasspath, but no longer the interim-corba classes. > > The fix is to not set -Xbootclasspath/p at all. It was never needed > and I just did it that way originally by trying to match existing > patterns. I have verified that the bug which prompted the introduction > of interim-rmic is still fixed when running without -Xbootclasspath/p. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138636 > > Patch inline: > diff -r 14faed4d6a50 make/rmic/RmicCommon.gmk > --- a/make/rmic/RmicCommon.gmk > +++ b/make/rmic/RmicCommon.gmk > @@ -33,7 +33,7 @@ > > BTRMIC_CP := $(call PathList, \ > $(BUILDTOOLS_OUTPUTDIR)/interim_rmic_classes > $(INTERIM_LANGTOOLS_JAR)) > -BTRMIC_ARGS := -Xbootclasspath/p:$(BTRMIC_CP) -cp $(BTRMIC_CP) > +BTRMIC_ARGS := -cp $(BTRMIC_CP) > RMIC := $(JAVA) $(BTRMIC_ARGS) sun.rmi.rmic.Main > > CLASSES_DIR := $(JDK_OUTPUTDIR)/modules This looks okay for now but still somewhat fragile because rmic -iiop has a dependency on com.sun.corba classes. Also when doing a boot cycle build then you'll find that the sun.rmi.rmic.* classes are being loaded from the newly built = boot JDK and now the "new new" interim rmic. This shouldn't matter of course. -Alan